Ontwerp e-book-systeem

[Rekcor]

Voor mijn werk ben ik aan het nadenken over een e-book-systeem. Of liever: een e-dictaat-systeem. Men heeft een aantal dictaten en wie die digitaal hebben. Natuurlijk kunnen we binnen no-time de PDF's op de website plempen, maar ik wilde toch naar iets interactievers toe.

Mijn vraag: willen jullie met me meedenken over de functionaliteit van zo'n e-boek? Wat moet er volgens jullie echt in en wat niet? O ja, het systeem wordt gebouwd in PHP/MySQL/HTML/Javascript.

De functionaliteit zoals ik tot nog toe bedacht heb:

- In de lopende tekst ( B ) staan staan links naar de glossary (vakwoordenboek). Zodra je hier op klikt, wordt de uitleg van betreffende term gegeven in C1. In de tekst in C1 kunnen ook weer glossary terms voorkomen. Zodra de gebruiker daarop klikt, wordt de uitleg gegeven in C2. Klikt de gebruiker op glossary terms in C2, dan wordt deze geladen in C1.

- De gebruiker kan - net als in Word - stukken tekst markeren en verwijderen en opmerkingen invoegen.

- De gebruiker kan zijn eigen bewerkte tekst opslaan als PDF

- De gebruiker kan (onderaan de pagina) een vraag stellen over de tekst. Deze worden na moderatie weergegeven onderaan de pagina.

- De gebruiker kan bladwijzers invoegen in de tekst. Deze worden bijgehouden in A.

- In A staan bovendien knoppen voor het markeren, verwijderen en plaatsen van opmerkingen. Een zoekveld en (uitklapbaar) een boomstructuur van de hoofdstukken/paragrafen.

code:

+-----+----------+-----+
| A   | B        |C1   |
|     |          |     |
|     |          |     |
|     |          +-----+
|     |          |C2   |
|     |          |     |
|     |          |     |
|     |          +-----+
|     |          |     |
|     |          |     |
|     |          |     |
|     |          |     |
|     |          |     |
|     |          |     |
+-----+----------+-----+

[Nvidiot]

En toen wilde ik dat even nalezen op m'n laptop zonder internet...
Denk er ook aan dat niet iedereen in 1600x1200 draait en dat het qua ruimte wel erg krap wordt met 3 kolommen in zeg 1024x768.

[Verwijderd]

Nvidiot schreef op dinsdag 10 april 2007 @ 13:58:
En toen wilde ik dat even nalezen op m'n laptop zonder internet...
Denk er ook aan dat niet iedereen in 1600x1200 draait en dat het qua ruimte wel erg krap wordt met 3 kolommen in zeg 1024x768.

Misschien is dat geen probleem als je A, C1 en C2 kunt inklappen

[Creepy]

Eeh.. gaat dit puur om features? Een feature request topic lijkt me niet helemaal de bedoeling.

Heb je misschien al een idee hoe je iets in elkaar wilt gaan zetten? Hoe heb je de structuur van je code opgezet of hoe wil je dat gaan opzetten? Dat is voor hier een stuk interresanter

[Rekcor]

Het forum om alles te bespreken dat vooraf gaat aan het daadwerkelijk programmeren. Bespreek hier je denkwijzen, modellen en programma-architectuur.

Stap 1 lijkt me de lijst met features. Over stap 2...n kom ik jullie nog wel te bevragen, wees gerust

[Creepy]

Eeh... met stap 1 bedoel je de denkwijze? Want dat gaat over de opzet van je omgeving,code e.d. (dus het hoe en het waarom je bepaalde dingen hebt opgezet zoals ze zijn of zoals je denk het te gaan doen, niet over welke features je gaat maken). Niet het wat maar het hoe dus.

Welke features je gaat bouwen is niet echt interresant. Hoe je de features zou willen gaan implementeren echter wel

Zaken als "De gebruiker kan zijn eigen bewerkte tekst opslaan als PDF" en "De gebruiker kan (onderaan de pagina) een vraag stellen over de tekst. Deze worden na moderatie weergegeven onderaan de pagina" zijn losse features die niks te maken hebben met de architectuur e.d. Dat is gewoon een domme opsomming van zaken die je software moet kunnen en dat wordt dan vrij snel een opsom topic met losse punten en dat wil ik graag voorkomen. Misschien een beetje voorbarig maar ik zie de "welke features zal ik nog maken in mijn CMS" topics alweer voorbij komen

[ Voor 41% gewijzigd door Creepy op 11-04-2007 09:34 ]

[Harm]

Rekcor schreef op dinsdag 10 april 2007 @ 13:54:
Voor mijn werk ben ik aan het nadenken over een e-book-systeem. Of liever: een e-dictaat-systeem. Men heeft een aantal dictaten en wie die digitaal hebben. Natuurlijk kunnen we binnen no-time de PDF's op de website plempen, maar ik wilde toch naar iets interactievers toe.

En willen je gebruikers dat ook? Ik ben student en ik zit echt niet te wachten op allerlei e-dictaat-systemen die me voorschrijven hoe ik een pdf'je of ander document moet lezen... geef mij maar de pdf en ik ben blij. Kortom: willen je gebruikers ook iets anders dan het losse pdf'je en ga met hen in gesprek om te horen wat de features moeten zijn. Als je dat niet doet krijg je een technisch perfect systeem dat voor ons technici werkt, maar wat voor gebruikers niet is wat ze zoeken.

[Rekcor]

Dan nu het beloofde ontwerp. Ik zou zeggen: het jachtseizoen is geopend .


De technische randvoorwaarden:

- Minimaal PHP 4
- Minimaal MySQL 4
- Javascript
- HTML

Het systeem moet het volgende kunnen:

- flexibele opbouw boeken; hiermee bedoel ik dat de paragrafen in meerdere hoofdstukken voor kunnen komen + dat nieuwe boeken eenvoudig kunnen worden samengesteld door een selectie te maken van de aanwezige paragrafen. Bijv. boek 1 bevat paragraaf 1, 2, 3, 4; boek 2 bevat paragraaf 1, 2, 5, 6; etc.

- de tekst in de paragrafen bevatten vaktermen; deze vaktermen + een korte toelichting staan in een glossary; het systeem moet de vaktermen automatisch van links voorzien naar de glossary

- gebruikers moeten stukken tekst kunnen markeren, verbergen, van opmerkingen voorzien en kunnen bookmarken; deze gegevens moeten worden opgeslagen in de database.

Opbouw van de database:

- Een tabel 'books'

code:

ID
title
startTreeLabelId

startTreeLabelId verwijst naar de tabel treelabels, en geeft de hoogste 'node' aan.

- Een tabel 'paragraphs'

code:

ID
title

De html van de verschillende paragrafen wordt opgeslagen in de map /paragraphs. De bestandsnaam is <ID>.htm. --> is dit handig?

- Een tabel 'users'

code:

ID
name
password

- Een tabel 'treelabels'

code:

ID
paragraphId
parentTreeLabelId

'paragraphId' verwijst naar een paragraaf; 'parentTreeLabelId' verwijst naar de parentNode;

- Een tabel 'userlabels'

code:

ID
userId
paragraphId
startPos
endPos
type
text

'userId' en 'paragraphId' verwijzen naar de gebruiker een de paragraaf; 'startPos' en 'endPos' verwijzen naar de begin- en eindpositie (in tekens) van de selectie; type kan 0 zijn (markering), 1 (verberging), 2 (opmerking), 3 (bookmark); 'text' is de opmerking zelf --> mn gevoel zegt dat deze ergens anders moet...

- Een tabel 'glossaryterms'

code:

ID
name
filename

[ Voor 8% gewijzigd door Rekcor op 17-04-2007 17:09 ]

[Rekcor]

Schop!

(of ben ik nu te ongeduldig, en broeden jullie allemaal op een geniaal antwoord )

[PhoneTech]

Probeer je nu gewoon een Wiki systeem te maken?
Of een eigen formaat voor e-books...Misschien moet je dan eens naar docBook kijken...

[Verwijderd]

Wat verwacht je nu dat ze het hier voor je gaan schrijven ofzo? Zo te zien heb je het aardig leuk uitgedacht...
Maar wil je weten wat voor functionalteiten er in moeten, dan zul je toch echt aan de mensen moeten vragen wat die ervan vinden als je het klaar hebt.

[Rekcor]

Voor mijn opdrachtgever ben ik (nog steeds) bezig met het ontwerpen van een e-book-systeem. Wat moet dit e-book kunnen?

• flexibele opbouw boeken; hiermee bedoel ik dat de paragrafen in meerdere hoofdstukken voor kunnen komen + dat nieuwe boeken eenvoudig kunnen worden samengesteld door een selectie te maken van de aanwezige paragrafen. Bijv. boek 1 bevat paragraaf 1, 2, 3, 4; boek 2 bevat paragraaf 1, 2, 5, 6; etc.
• beheerders moeten gemakkelijk de inhoud van de boeken kunnen aanpassen
• de tekst in de paragrafen bevatten vaktermen; deze vaktermen + een korte toelichting staan in een glossary; het systeem moet de vaktermen automatisch van links voorzien naar de glossary
• gebruikers moeten stukken tekst kunnen markeren, verbergen, van opmerkingen voorzien en kunnen bookmarken; deze gegevens moeten worden opgeslagen in een database.

Het systeem zal draaien op een website, en zal dus bestaan uit een database + serverside taal + client side taal.

Wat vinden jullie van het idee om het e-book in Flash weer te geven? Mijn intuitie zegt dat je zoiets (veel) beter in HTML kunt maken. Wat zijn de argumenten?

Wat ik al heb bedacht:

• HTML is fluide;
• HTML biedt standaard gui controls;
• HTML is gemakkelijk toegankelijk te maken voor mensen met (visuele) handicaps;
• HTML - zijnde een soort XML - is erg portable;

[RM-rf]

Rekcor schreef op maandag 23 april 2007 @ 12:18:

Wat vinden jullie van het idee om het e-book in Flash weer te geven? Mijn intuitie zegt dat je zoiets (veel) beter in HTML kunt maken. Wat zijn de argumenten?

Wat ik al heb bedacht:

• HTML is fluide;
• HTML biedt standaard gui controls;
• HTML is gemakkelijk toegankelijk te maken voor mensen met (visuele) handicaps;
• HTML - zijnde een soort XML - is erg portable;

Flash kent al deze elementen ook, kan evenzeer zeer accesible gemaakt worden, fluid, en portbaility is zeer groot, naar verschillende OSen en platformen ...

Ik denk echter wel dat de ontwikkelkosten van Flash wanneer dat soort criteria aangehouden worden, ook bij Flash snel gaan stijgen en om eenzelfde mate van gebruiksvriendelijkheid en toegankelijkheid te behalen als wat HTML zelf juist al heeft;
kan het zeer goed zijn dat de Flash-oplossing duurder wordt, wanneer daar evenveel rekening gehouden wordt met accessability (omdat je dan eigenlijk zelf die hele GUI moet opbouwen en daarin dan alle accessibility-elementen als tabindex, altteksten, bookmark-methoden, font-sizing)

wat ik zou aanraden is niet om bij voorbaat te pogen 'flash weg te redeneren' maar een dusdanig ontwerp te maken waar er een generieke basis ligt (gebaseerd op bv XML) en waaruit gekozen kan worden naar verschillende output-methodes; zowel flash of HTML, desnoods SVG of zelfs het redeneren naar downloadbare PDF's
Uiteindelijk is het dan een keuze van budget welke output methode gekozen wordt om uit te voeren en op een later moment kan men altijd kiezen hierin een uitbreiding te maken, bv een Flash-interface extra aan te bieden

[merauder]

Ik vraag me af waarom je je E-Books in PDF wil hebben, en niet mooi in ASCII-tekst in een database systeem. Voordeel van dat laatste is dat je het systeem 1 standaard lay-out hebt voor alle e-booken, dat je het idee van UBB-code kunt gebruiken voor het beargumenteren voor de teksten en dat je dataservers een stuk leger blijven. Soort van WYSIWYG systeem voor editten van artikelen zou het kunstje waarschijnlijk voor elkaar moeten krijgen.

[-RenE-]

merauder schreef op zaterdag 19 mei 2007 @ 19:55:
Ik vraag me af waarom je je E-Books in PDF wil hebben, en niet mooi in ASCII-tekst in een database systeem. Voordeel van dat laatste is dat je het systeem 1 standaard lay-out hebt voor alle e-booken, dat je het idee van UBB-code kunt gebruiken voor het beargumenteren voor de teksten en dat je dataservers een stuk leger blijven. Soort van WYSIWYG systeem voor editten van artikelen zou het kunstje waarschijnlijk voor elkaar moeten krijgen.

XML is als meta-taal bedacht voor dit soort toepassingen. Het lijkt me dus een beetje vreemd om het wiel opnieuw uit te gaan vinden.