Toelichting 2 bij de offerte voor de ontwikkeling van het
collectieve e-boek-platform voor de Vlaamse uitgeverijen
Nederlands/Frans
Ter attentie van: Mevrouw Goedroen Vanlerberghe Projectleider Knooppunt.net Boek.be Het Huis van het Boek Te Boelaerlei 37 B-2140 Borgerhout
Het startpunt PDF Eerst even duidelijkheid scheppen over ons voorstel en eventuele andere mogelijkheden om als startpunt te gebruiken bij het creëren van een e-boek. In ons huidige voorstel vertrekken we vanuit een PDF file die door de uitgever uit Indesign is getrokken, om een bladerbaar e-boek te maken. Belangrijk daarbij is dat we vertrekken van een ‘gestapeld’ PDF bestand, waarin dus de verschillende onderdelen, lagen van een boek zitten (in tegenstelling tot een grotendeels plat gemaakte PDF). Hieruit kunnen we alle onderdelen van een pagina halen, zodat gebruikers een foto kunnen kopiëren, een paragraaf tekst kopiëren of het boek doorzoeken op een bepaalde tekststring. Het e-boek zal voor het zichtbare gedeelte van de applicatie steeds werken met relatief snel te renderen JPG bestanden (Hi-Res en Low-Res), en dus onzichtbaar de informatie van de verschillende onderdelen uit de PDF achter deze JPG stoppen, zodat de structurele opbouw van de pagina beschikbaar is, en de tekst inhoud van de pagina (of het ganse boek) ook kopieerbaar en doorzoekbaar is. Hiervoor lijkt ons een extra ‘grab’ functie button aangeraden, om te voorkomen dat gebruikers al te dikwijls ongewild stukken van een pagina aanklikken of kopiëren.
Indesign Als jullie de expliciete wens hebben om te kunnen vertrekken vanuit de Indesign files zelf, is dit ook mogelijk. Maar dit heeft uiteraard een aantal gevolgen. Dé enige goeie manier om deze kaart te trekken is te starten met het ontwikkelen van een echte plugin voor Indesign. Deze plugin kan dan door elke uitgever gebruikt worden om boeken vanuit Indesign rechtstreeks door te sturen naar de e-boek server. Het mooie van deze plugin is dat deze alle aparte onderdelen van elke opgemaakte pagina afzonderlijk kan renderen, taggen en opslaan op de e-boek server en databank. Dus van zodra een nieuw boek via deze plugin op de e-boek server is terecht gekomen, hebben we van elke pagina in dit boek alle afzonderlijke elementen beschikbaar. Door ervoor te zorgen dat de plugin deze verschillende onderdelen ook gepast gaat taggen, kunnen we daarna bv. weblinks uit het Indesign bestand rechtstreeks klikbaar maken in het e-boek, of kunnen we de tekstinformatie van een paragraaf mee opslaan om bv. een e-boek ook doorzoekbaar te maken op pure tekst. Het zou dus in principe mogelijk zijn om elke pagina van een e-boek op een tablet steeds op te bouwen uit de verschillende onderdelen zoals deze beschikbaar zijn uit Indesign. Grote vraag blijft de performantie van een dergelijke opbouw op alle soorten tablets. Andere vraag is hoe je alle fonts uit het Indesign bestand zou gaan embedden in een e-boek om bv. tekst als tekst weer te geven. Daarom zou, ook wanneer we vertrekken vanuit Indesign, ons advies zijn om de pagina’s uit te renderen in JPG bestanden, MAAR met daarachter het volledige coördinaten-grid van de verschillende bouwstenen ; op die manier kan een leerkracht bv. één bepaalde foto kopiëren uit het boek, of een paragraaf tekst kopiëren om bv. te gebruiken in een examenvraag.. (technisch gezien kunnen we dan
vrij makkelijk aan de hand van de coördinaten opvragen welke afbeelding of tekst op het aangeklikte punt staat, en dan enkel dat afzonderlijk onderdeel opvragen uit de databank). De opbouw van een uiteindelijke pagina in een e-boek verschilt dus niet zo veel van de manier waarop we dit doen binnen de PDF oplossing. We willen eventueel ook samen met de instappende uitgeverijen (en hun uitgevers/zetterijen..) even bekijken wat hun voornaamste redenen zijn om te kiezen voor Indesign als startpunt. Enkele belangrijke waarschuwingen hierbij: Het werken met een Indesign plugin betekent dat binnen een uitgeverij alle uitgevers deze plugin moeten installeren om hun boeken als e-boek aan te bieden. En met de verschillende versies die er van de Creative Suite van Adobe bestaan, is de kans reëel dat niet elke versie ondersteund zal worden door een gloednieuwe plugin. Als dus voor deze manier gekozen wordt, betekent dit dat alle uitgeverijen die instappen in het e-boek project, deze plugin moeten gebruiken. Elke Indesign versie kan daarentegen wel publiceren naar PDF, dus bij de PDF oplossing zou zich dit probleem veel minder stellen. Een ander aandachtspunt bij het werken met Indesign bronbestanden, is dat deze door de makers meestal nooit bedoeld zijn om te gebruiken als basis voor een digitale afgeleide. Dit betekent dikwijls dat bv. afbeeldingen soms afgedekt worden met witruimte ipv ze bij te snijden, dat stukken afbeeldingen uitgeknipt zijn waar een andere onderdeel erover heen ligt enz.. De onderdelen die uit het Indesign bestand komen, zullen dus dikwijls niet helemaal stroken met het uitzicht van die pagina zoals deze gedrukt wordt. Tenslotte zal het heel moeilijk worden om álle bestaande bordboeken van de uitgeverijen te migreren in deze “indesign-applicatie”, dat zal uitgeverij per uitgeverij moeten bekeken worden.
Planning Mochten jullie kiezen om te starten vanuit Indesign, zal dit natuurlijk zijn invloed hebben op de timing (en budget, zie verder). Eerst beantwoorden we jullie vragen over onze initiële timing en releaseplanning, daarna schetsen we wat de impact zou zijn van het laten ontwikkelen van een Indesign plugin op deze timing.
Workshop Zoals tijdens onze presentatie verteld, zijn we inderdaad van plan om samen met de instappende uitgevers een workshop te organiseren om knopen door te hakken. Ik denk zelfs dat we toen reeds hadden voorgesteld om deze in te plannen de eerste week van september – dit uiteraard in het licht van de planning, en het tijdig afwerken van de projectbrief. Deze workshop maakt integraal deel uit van het voorbereidend traject, en is dus inbegrepen in het budget. Vrijdag 7 september is in onze agenda nog haalbaar.
Pilootproject Aangezien onze oplossing erin bestaat een volledige maatontwikkeling te schrijven, zou een pilootproject erin bestaan een nieuw boek aan te maken in het ontwikkelde product. Het spreekt voor zich dat daarvoor het product dus moet klaar zijn. Een volledige ‘dry run’ en End User Testing kunnen we dan ook pas inplannen zodra alle functionaliteiten beschikbaar zijn, wat volgens de planning eind december is. We kunnen het pilootproject wel opsplitsen in fasen: Van zodra de backoffice van de applicatie klaar is, stellen we één test CDS open waarin een pilootboek kan ingeladen en verrijkt worden Wanneer de desktopversie klaar is, kan dit pilootboek getest worden op de desktopversie En zodra ook de tabletversie afgewerkt is, kan dit pilootboek ook getest worden op tablet De eerste twee fasen zijn afgerond in onze Release II, wat betekent dat we tegen begin november een pilootproject kunnen starten voor wat betreft de desktopversie. We plannen dit in de week na de Allerheiligenvakantie. Midden januari kunnen we End user Testings inplannen met een deelnemende school (stond ook zo reeds vermeld in ons vorige documentje).
Knooppunt koppeling We gaan deze koppeling een heel stuk vroeger inplannen, zodat we ook onmiddellijk met de effectieve data kunnen werken voor bv. het versiebeheer van de annotaties die een leerkracht voor verschillende klassen zal maken. We verplaatsen dit naar Release I, zie bijgevoegde aangepaste Release planning. Hoe pakken we dit aan? Wanneer een gebruiker zich identificeert op Knooppunt, stuurt Knooppunt naar onze server een ge-encrypteerd request om een e-boek te openen. Deze request zal op een veilg versleutelde manier dus data bevatten waarmee onze applicatie kan bepalen wie welk boek wil openen. Op zich gaat het er dus om in onze e-boek applicatie vanuit Knooppunt een paar ID’s op een beveiligde manier te kunnen ontvangen. Het gaat dan bv. over SchoolID, leraarID, boekID, uitgeverijID, schoolID, klasID enz.. Wij overleggen bij aanvang met Knooppunt welke gegevens zij beschikbaar hebben, en spreken dan een gemeenschappelijke manier van encryptie af.
Een inschatting van hoeveel deze koppeling kost (dewelke voor alle duidelijkheid reeds vervat zit in onze globale kostprijs), is moeilijk te maken, omdat dit eigenlijk redelijk vlot kan verlopen. We schatten dit in op een 1,5 dagen werk (vooral de communicatie tussen beide partijen is hier belangrijk, deze inschatting is dus inclusief talrijke telefoontjes en e-mails tussen Knooppunt en Epyc).
14 september: Project brief klaar en aanvaard Beschrijving van alle functionaliteiten Wireframes van de front- en backoffice opbouw 12 oktober: Release I Opzetten Backoffice + CDS uitgevers Koppeling met Knoopunt operationeel GUI tabletversie goedgekeurd 2 november: Release II BO: converteerscripting boeken voor tablets Frontoffice desktopversie klaar Start tablet ontwikkeling Open en bladeren van boeken op iPad en Android Basis besturing tablet mogelijk (pinch/zoom, rotate) 30 november: Release III Navigatie in e-boek Openen media assets Ontsluiten oplossingen 21 december: Release IV Alle functies in frontoffice beschikbaar op iPad en Android* 15 januari:
eerste import script uitgeverij 1
30 januari:
import content uitgeverij 2
1 februari: Release V Windows 8 tablet versie 15 februari:
import content uitgeverij 3
28 februari:
import content uitgeverij 4-6
8 maart: Release VI HTML 5 versie: ! zoals ook vermeld in de offerte, lijkt ons een HTML5 versie op dit moment nog voorbarig, vooral omdat deze qua functionaliteiten en performantie zal moeten onderdoen voor de andere versies van de tool. Toch hebben we oor naar de wens van de uitgeverijen om deze versie te ontwikkelen. We vegen dit dus zeker niet van tafel, wel integendeel! Zodra de Desktop-versie klaar is (lees: zodra de belangrijkste hordes qua functionaliteit genomen zijn) , start EPYC immers parallel ook met het onderzoeken wat in een HTML5 versie haalbaar is met de dan gangbare hardware-devices. De uiteindelijke wishlist mét bijhorend extra budget bespreken we tijdens het project met Boek.be. De ontwikkeling van een eventuele HTML5 versie kan dan eventueel ingepland worden als een 6e release. Met dit eerste script importeren we de bestaande bordboeken van een eerste uitgeverij. 29 maart:
finale oplevering: tablet app beschikbaar in Appstore, Google Play en Windows store
Praktisch Planning & Budget @ Indesign In het geval Boek.be ervoor kiest om de Indesign piste te volgen, heeft dit zowel budgettaire gevolgen, als invloed op de vooropgestelde planning. We laten hiervoor eerst en vooral door een gespecialiseerde partij een plugin bouwen die rechtstreeks in Indesign geïnstalleerd wordt. Deze plugin wordt volledig volgens de noden en wensen van dit project ontwikkeld en stuurt de onderdelen van elke Indesign pagina naar de server op exact de manier die we nodig hebben. De externe ontwikkeling van een dergelijke plugin komt met een prijskaartje, hetgeen we begroten op 22.000 EUR. Komt daar bovenop de extra ontwikkeling dat dit voor ons meebrengt. Dit begroten we op 7.475 € Qua planning zijn we natuurlijk afhankelijk van de planning van de externe partner, maar ik denk dat je sowieso mag stellen dat de geplande releases met een 6-tal weken zullen verschuiven.
Ontwikkelteam Deze e-boek applicatie wordt ontwikkeld door een dedicated projectteam, waarbij de Flex developer die ook onze vorige 2 bordboek toepassingen ontwikkelde, heel duidelijk de projectlead is. Alle leden van ons projectteam hebben minstens 5 jaar ervaring in hun expertise gebied. De project manager zal voor Boek.be het unieke aanspreekpunt zijn. We willen nog even benadrukken dat project voor ons bedrijf ook strategisch heel belangrijk is, en dat we ook als management alles uit de kast halen om ons team te ondersteunen en sturen om dit project succesvol af te ronden.
Migratie bestaande boeken Zoals in de planning voorzien, hebben we migratie van de eerste uitgeverij gepland rond half maart. Dit was vooral met het idee om eerst de applicatie 100% klaar, getest door gebruikers enz.. te hebben alvorens de import te doen. Maar dat kan in principe ook een stuk vroeger. We wachten liefst wel met het migreren tot de Release IV, zodat we de content ook op tablet kunnen uittesten, maar qua timing kunnen we deze migratie gerust een stuk vervroegen. We hebben dit op deze manier aangepast in bovenstaande planning.
Hoe gaan we deze migratie aan pakken? In een aantal stappen: -
Inzage krijgen in de assets (bestanden, afbeeldingen, XML, databank..) van de huidige oplossing Analyse van datastructuur en mogelijk oplossingen tot conversie (indien mogelijk ook een meeting met het bedrijf die de huidige toepassing ontwikkelde) Bespreken en vastleggen van de aanpak met de uitgeverij Coderen en uitrollen van de migratie Testing van het resultaat op alle media
Kostenmodel Zoals vermeld in onze offerte, hanteert Epyc geen licentie model dat bv. per aangemaakt boek en/of per user een fee aanrekent. De enige vast kost per uitgever voor de uitbating van het platform, is 2.500 € (voor de uitgeverijen die onmiddellijk instappen, is dit pas vanaf schooljaar 14-15). Dit omvat: Het onderhoud van elke aangesloten uitgeverij haar eigen CDS Beperkte telefonische support voor de uitgeverij admins en Boek.be ½ opleiding per uitgeverij om bv. nieuwe medewerkers op te leiden Monitoring van het platform (resources, load..)
