Stageverslag. Streampaper TUDELFT. Hylke Hendriksen, Peter van Buul en Huub van der Voort 22/06/2012

Transcriptie

1 TUDELFT Stageverslag Hylke Hendriksen, Peter van Buul en Huub van der Voort 22/06/2012 Dit stageverslag is ter afsluiting van het bachelorproject voor de opleiding Technische Informatica aan de Technische Universiteit Delft. Gedurende de stage is het programma ontworpen en geïmplementeerd. is een op zichzelf staande applicatie waarin verschillende externe informatiestromen gecombineerd kunnen worden weergegeven. De gebruiker van kan gemakkelijk door pagina's met berichten uit deze bronnen bladeren. Het doel van is het vergemakkelijken van het up-to-date blijven van werknemers wat betreft bedrijfsnieuws en eventuele andere relevante nieuwsbronnen.

2 Titel Stageverslag () Auteurs In opdracht van Hylke Hendriksen Peter van Buul Huub van der Voort TU Delft en Moxio

3 TABLE OF CONTENTS Voorwoord... 4 Inleiding Probleemstelling en analyse Probleemstelling Oplossing Vooronderzoek Planning Proces Ontwerp Client Server architectuur MVC in de client Grid Templates Popups Pagina s en tijdsblokken Readability Opsplitsen cronjob Optimaal algoritme Implementatie Code kwaliteit beoordeling door SIG Aanbevelingen vanuit SIG Opsplitsen methoden Samenvoegen parameters Unit tests Conclusie Aanbevelingen Integratie met Outpost Evaluatie Verklarende woordenlijst Bijlagen... 25

4 Stageverslag VOORWOORD Dit stageverslag is ter afsluiting van het Bachelorproject voor de opleiding Technische Informatica. Het Bachelorproject bestaat uit een vooronderzoek en een stage waarin een geheel software ontwikkeltraject doorlopen wordt. Deze stageopdracht is geleverd door en uitgevoerd in opdracht van Moxio. Dit verslag is geschreven voor zowel begeleiders van de Technische Universiteit Delft als geïnteresseerde lezers met een technische achtergrond. Het project is uitgevoerd in een specifieke tak van de ICT, namelijk de web-based applicaties. De opbouw van dit verslag bestaat deels uit projectspecifieke en deels uit technische onderdelen. Getracht is om zoveel mogelijk technische termen te beschrijven. Deze omschrijvingen zijn te vinden zijn in de verklarende woordenlijst aan het einde van het verslag. Hoofdstukken uit het stageverslag zijn zo duidelijk en kort mogelijk geformuleerd. Voor meer specifiekere informatie wordt veelal verwezen naar de bijlagen welke achteraan dit verslag te vinden zijn. Wij willen graag onze stagebegeleiders bedanken: Koen Lageveen vanuit Moxio, David Tax en Peter van Nieuwenhuizen vanuit de TU Delft. Tevens gaat onze dank uit naar Moxio; Hylke van der Kolk voor het mogelijk maken van de stage en zijn visie op het project. Daarnaast willen wij alle medewerkers bij Moxio bedanken voor de fijne werkomgeving, de tafelvoetbalcompetitie en de goede hulp. Tom voor de werkplekken, Melissa voor de geweldige lunches, Dennis, Frits, Merijn en Arnout voor de technische hulp en Gilbert voor het verzorgen van de muziek. Hylke Hendriksen, Peter van Buul en Huub van der Voort Delft, 22 juni

5 Stageverslag INLEIDING Gedurende de stage is het programma ontworpen en geïmplementeerd. is een op zichzelf staande applicatie waarin verschillende externe informatiestromen gecombineerd kunnen worden weergegeven. De gebruiker van kan gemakkelijk door pagina's met berichten uit deze bronnen bladeren. Het doel van is het vergemakkelijken van het up-to-date blijven van werknemers wat betreft bedrijfsnieuws en eventuele andere relevante nieuwsbronnen. De opbouw van dit verslag is als volgt. In het eerste hoofdstuk zal het probleem uiteen worden gezet waaruit is voortgevloeid. Hiertoe wordt het probleem geanalyseerd en de oplossing die heeft gebruikt wordt gepresenteerd. Tevens worden de relevante conclusies uit het vooronderzoek kort besproken. In het tweede en derde hoofdstuk zullen de planning en het proces worden besproken. Eerst zal worden omschreven hoe de planning van het project is aangepakt. In hoofdstuk drie zal de uitvoering van het proces worden besproken. De technische beslissingen die bij de implementatie van zijn genomen zullen in het vierde hoofdstuk worden besproken. De uiteindelijke implementatie zal vervolgens in het vijfde hoofdstuk worden uitgewerkt. Het zesde hoofdstuk gaat in op de code beoordeling door de Software Improvement Group, de daaropvolgende aanpassingen en weerleggingen. In het zevende hoofdstuk zal een conclusie worden verbonden aan het geheel. Hierbij wordt bekeken of de vooraf gedefinieerde problemen zijn opgelost en in hoeverre de gegeven opdracht is uitgevoerd. Voor verdere ontwikkeling is aangegeven dat geïntegreerd zal worden met Outpost. Hiervoor zijn in het zevende hoofdstuk een aantal aanbevelingen opgenomen. Tot slot zal in de evaluatie het verloop van het bachelorproject worden besproken. Technische lezers welke op zoek zijn naar de werking van het programma worden aangeraden het ontwerp en de implementatie in respectievelijk hoofdstuk vier en vijf te lezen. Lezers die op zoek zijn naar procesmatige details van het project kunnen de planning, het proces en de evaluatie lezen in respectievelijk hoofdstuk twee, drie en negen. De lezers die op zoek zijn naar de opdracht, aanpak en uitvoering van het probleem worden aanbevolen de probleemstelling en analyse, conclusie en aanbevelingen te lezen in respectievelijk hoofdstuk een, zeven en acht. 5

6 Stageverslag 1. PROBLEEMSTELLING EN ANALYSE In dit hoofdstuk worden het probleem, de deelproblemen en de daarop gevonden oplossing uitgelegd. Hierna wordt uitgelegd hoe het vooronderzoek is uitgevoerd, welke resultaten dit heeft opgeleverd en wat de gevolgen voor waren PROBLEEMSTELLING Dagelijks komt een stroom van informatie uit verschillende bronnen op werknemers af. Al deze bronnen vechten om aandacht van de werknemer waardoor deze overspoeld wordt met informatie. Moxio heeft in de stageomschrijving, zie bijlage A, de opdracht gegeven een applicatie te ontwerpen om verschillende soorten informatiebronnen te verwerken en overzichtelijk te weergeven. Daartoe moet eerst informatie vergaard worden en vervolgens zal deze op een overzichtelijke en visueel aantrekkelijke manier weergegeven moeten worden. De formulering van de stageopdracht luid: De hoofdverantwoordelijkheid van het project is de basis van, het is de bedoeling dat de basis bestaat uit de algoritmen om de berichten op het scherm weer te geven en de uitwerking hiervan. Ook bevat de basis in ieder geval een of meerdere vormen van uit te lezen streams, zoals RSS, zodat de functionaliteit van duidelijk is. De opdrachtgever acht het belangrijker dat de uit te lezen streams zo foutloos mogelijk verwerkt worden, dan dat er zo veel mogelijk streams uitgelezen kunnen worden, kwaliteit gaat boven kwantiteit. Zie hoofdstuk 2.3 paragraaf 4 van het Plan van aanpak in bijlage B. Er zijn verschillende deelproblemen bij deze probleemstelling. Er zijn hieronder vier deelproblemen geïdentificeerd. 1. moet verschillende informatiebronnen kunnen verwerken 2. Hoe worden meerdere informatiebronnen gecombineerd? 3. Waar nodig extra informatie verzamelen 4. Hoe moet het dynamisch en overzichtelijk weergeven worden? 1.2. OPLOSSING De vier deelproblemen komen samen in het op zichzelf staande applicatie genaamd. is een applicatie waarin de gebruiker verschillende databronnen zoals RSS, Twitter en elementen van het sociale extranet in kan voeren. Vervolgens worden deze databronnen samengevoegd tot één informatiestroom en op het scherm weergegeven. De indeling voor het scherm wordt dynamisch weergeven op basis van een algoritme wat op bepaalde vooraf gedefinieerde regels de berichten in het scherm indeelt. 6

7 Stageverslag De deelproblemen zijn theoretisch onderzocht in een deel van het vooronderzoek. Tijdens het project is de praktijk vergeleken met de theorie en zijn sommige oplossingen veranderd of vervangen. Hieronder wordt kort besproken wat het onderzoek heeft kunnen bijdragen voor het vinden van de oplossingen voor de problemen VOORONDERZOEK Het vooronderzoek bestaat uit vijf hoofdstukken waarin onderzoek is gedaan naar de mogelijkheden voor zowel het verkrijgen als het weergeven van informatie. Hieronder wordt het onderzoek kort besproken. Het volledige vooronderzoek is te vinden in bijlage C. In de eerste twee hoofdstukken is onderzocht welke nieuwe state-of-the-art technieken bij de ontwikkeling van zouden kunnen worden gebruikt. Uit dit onderzoek is gebleken dat CSS Regions een interessante techniek is om te gebruiken bij de ontwikkeling van. Een belangrijk nadeel is echter dat enkel Google Chrome deze techniek ondersteund. Vanwege het voorgaande is besloten dat voor Google Chrome ontwikkeld moest worden. Met CSS Regions kunnen gemakkelijk tekstuele kolommen worden aangemaakt. Dit kan bijdragen aan, deelprobleem vier, de overzichtelijkheid en leesbaarheid van. In hoofdstuk drie zijn verschillende mogelijkheden voor, deelprobleem drie, het verkrijgen van extra informatie verkend. Er zijn twee externe programma s geanalyseerd welke artikelen uit webpagina s kunnen extraheren. Hieruit is geconcludeerd dat het best de externe partij Readability gebruikt kan worden. gebruikt hierom Readability om informatie van websites op te halen. Hoofdstuk vier betreft, deelproblemen een en twee, de verwerking en combinatie van verschillende soorten externe informatiebronnen. Hieruit is gebleken dat 85% van de RSS feeds volgens de 2.0 standaard opgebouwd zijn en dat deze standaard backward compatibel is met oudere versies. De elementen van RSS 2.0 zijn als basis gebruikt voor de structuur van berichten binnen. Het laatste deel van het vooronderzoek droeg bij aan deelprobleem vier en is een verkenning naar het gebruik van templates voor het weergeven van informatie. Hieruit is gebleken dat templates kunnen worden gebruikt om de informatie op een overzichtelijke en visueel aantrekkelijke manier weer te geven. Hoe de templates precies moeten worden ingedeeld is tijdens de ontwikkeling van verder onderzocht. 7

8 Stageverslag 2. PLANNING In dit hoofdstuk zal de planning en werkwijze van dit project beschreven worden. Dit gebeurt onder andere aan de hand van een beschrijving van de methodiek en de gebruikte software om deze methodiek toe te passen. Voorafgaand aan het project is besloten om met de software ontwikkelingsmethode scrum te werken. Met scrum wordt aan het eind van iedere sprint een werkend product afgeleverd, hierdoor garandeert het team dat er aan het einde van het project een werkend eindproduct is gemaakt. Door te werken met sprints van ongeveer een week zijn er reflectiemomenten waarbij het proces kan worden bijgesteld zodat het eindresultaat beter is afgestemd op de behoefte van de opdrachtgever. Deze kwaliteitsborging is uitgewerkt in hoofdstuk 5 van het Plan van aanpak in bijlage B. Scrum is een iteratieve vorm van software ontwikkeling. Bij scrum wordt gebruik gemaakt van sprints. Een sprint is een bepaalde tijdsperiode waarin een stuk software wordt uitgebreid met een vooraf bepaald aantal features. Iedere sprint bestaat uit de volgende vier fasen. In de eerste fase wordt de sprint opgestart door met de product owner, in dit project de begeleider van Moxio, te bespreken wat op het moment de belangrijkste features zijn. Als de features bekend zijn wordt er een planning gemaakt waarin vastgesteld is wat aan het einde van een sprint opgeleverd moet worden, de requirements. De requirements van een sprint worden in scrum termen ook wel sprint backlog genoemd. De tweede fase is het ontwerpen van de stukken software uit de sprint backlog. De onderdelen moeten in detail zijn uitgedacht. Alle delen zijn opgedeeld in taken van maximaal 4 uur. De leden van het ontwikkelteam kunnen nu iedere taak afzonderlijk oppakken zonder dat ze daarmee afhankelijk zijn van een andere taak. Deze fase wordt afgesloten door te controleren of alles geïmplementeerd kan worden in de tijd dat de sprint nog loopt. Fase drie is de implementatie of uitvoering van alle taken in de sprint backlog. Om gedurende de sprint te bepalen wanneer een feature af is wordt de Definition of Done gebruikt. Door met deze definitie te werken kan structureel worden gewerkt en voldoen taken die af zijn aan een aantal kwaliteitseisen. De volgende elementen zijn bepaald als zijnde de Definition of Done : JSLint validatie, de geschreven code mag tenzij beredeneerd geen JSLint fouten bevatten. Waar nodig zijn Unit tests geschreven, deze moeten allen slagen. Een collega heeft de code bekeken en goedgekeurd. De code is met SVN gecommit, daarbij is nuttig commentaar toegevoegd. De laatste fase is de afsluiting van de sprint. Hier wordt het eindproduct van de sprint gedemonstreerd aan de product owner. Er wordt gebruik gemaakt van verkennende tests en acceptatie tests. Er wordt gekeken of alle functionaliteiten van de sprint backlog geïmplementeerd zijn en of het product voldoet aan de wensen van de product owner. In de meeste gevallen zullen de wensen van de product owner veranderen. Met scrum is er ruimte om te bouwen wat er op dat moment de meeste waarde toevoegt. Tijdens de afsluiting is er ook een reflectie op het proces van de sprint. De ontwikkelaars kunnen op basis van de reflectie het werkproces aanpassen naar eigen wens. Met deze methodiek werken de ontwikkelaars altijd in een goede omgeving en zullen zichzelf en het werkproces continu blijven verbeteren. 8

9 Stageverslag Ter ondersteuning van het scrum proces is gebruikt gemaakt van Team Foundation Server (TFS). Dit is een tool waarin verschillende elementen van scrum gemanaged kunnen worden. Tijdens het project is gebruik gemaakt van de backlog en het scrumboard uit TFS. Voor het begin van een sprint is de planning ingevoerd in de sprint backlog. Gedurende de sprint staat op het scrumboard een duidelijk overzicht van wie waar mee bezig is, wat er nog gedaan moet worden en wat er af is. In iedere sprint is er documentatie gemaakt voor zowel het team zelf als de mensen welke direct of indirect betrokken zijn bij het product. Door iedere sprint te documenteren worden belangrijke beslissingen niet vergeten en is het mogelijk om naderhand de ontwikkeling van het project te bekijken. Er zijn een tweetal documenten geschreven iedere sprint. In de design documenten staat de technische ontwikkeling van zowel de concepten en keuzes binnen gedocumenteerd. In de sprintverslagen staat de procesmatige ontwikkeling, alles wat besproken is in de reflectie tijdens de afsluiting van de sprint staat in dit document. Deze documenten zijn te vinden in bijlage D. Er zijn in de planning 8 sprints van één week gedefinieerd met een enkele uitzondering. De eerste sprint duurt twee keer zo lang in verband met het opzetten van een ontwikkelomgeving waarin automatisch getest kan worden. Tevens moest er in de eerste sprint vanaf de grond af aan een basis gebouwd worden voor. De laatste sprint is afgezoen van kleine bugfixes niet ingevuld met het bouwen van features maar de verslaglegging van onder andere het implementatie document en het stageverslag. Om deze reden zijn er maar zeven sprintverslagen en zeven design documenten geschreven. In hoofdstuk 3 van het Plan van aanpak in bijlage B is de originele omschrijving betreft de aanpak en tijdsplanning te vinden. 9

10 Stageverslag 3. PROCES In dit hoofdstuk wordt bekeken hoe het proces van het project verlopen is. Wat voor procesmatige veranderingen hebben er plaatsgevonden gedurende het project. Er wordt ook gekeken naar de redenering achter de gemaakte beslissingen. Voor het verloop van het proces worden de sprintverslagen geanalyseerd. Aan het einde van iedere sprint is het verloop van de sprint geanalyseerd en is aan de hand daarvan het proces verbeterd. Zo zijn bijvoorbeeld de stand-up meetings gedurende de eerste sprints weinig gebruikt, toen bleek dat de meetings de productiviteit konden verhogen zijn deze meer gebruikt. Tijdens de latere sprints was meer overleg nodig, omdat de taken kleiner werden. Hierdoor werden de stand-up meetings weer onnodig en zijn deze daarom dus niet meer gebruikt. De grootste taak van de eerste sprint wat het opzetten van een werkzame ontwikkelomgeving waar automatisch getest kon worden. Daarnaast was de taak meegegeven om een basis neer te zetten. Alles is van de grond af gebouwd waardoor van te voren niet bekend was wat er allemaal moest gebeuren. De taken zijn gedurende de sprint toegevoegd in plaats van aan het begin. In de tweede sprint zijn we dat expliciet gaan verbeteren en hebben we alles aan het begin bepaald. Gedurende de eerste sprints is er veel aan pair-programming gedaan. Om de productiviteit te verhogen is geprobeerd om pair-programming te voorkomen. Door goed te overleggen over de verschillende taken werd helderheid geschept over hoe de taken moesten worden uitgevoerd. Dit had tot gevolg dat naarmate het project vorderde er minder samen is geprogrameerd. Wanneer gedurende het uitvoeren van een taak toch bleek dat er hulp nodig was is er wel bijgesprongen. De balans tussen zelf uitzoeken en hulp zoeken werdt naarmate het project vorderde steeds beter. De balans tussen pair-programming en de stand-up meetings waren goed zichtbaar. In het begin van het project moesten heel veel dingen afgestemd worden waardoor er weinig stand-up meetings gehouden werden, omdat er continu besprekingen werden gehouden. Na het opzetten van de ontwikkelomgeving moesten de teamleden goed op elkaar afstemmen en conventies betreft de code stijl etc. afspreken. Daardoor werd er veel aan pair-programming gedaan en waren de stand-up meetings niet nodig. Een belangrijke beslissing tenaanzien van het proces is dat in de zesde sprint alle features (die in de resterende sprints geïmplementeerd zouden kunnen worden) op het scrumboard zijn gezet. Vantevoren was duidelijk dat niet alle features in deze sprint geïmplementeerd konden worden. In de resterende sprints zou echter geen tijd meer zijn om features toe te voegen. was functioneel al af, iedere feature die er bij kwam zou fijn zijn. Het niet implementeren van features zou geen problemen opleveren. In sprint zeven en acht is afgeweken van de standaard methode zoals scrum wordt gebruikt. Dit is gedaan, omdat de focus in die sprints niet meer bij de implementatie lag maar bij de documentatie. Gedurende de zevende sprint zijn bugs op het scrum board gezet en opgepakt. De achtste sprint is geen gebruik meer gemaakt van het scrum board. Er hebben geen grote ontwikkelingen aan het programma meer plaatsgevonden. Er is gedurende de achtste sprint alleen aan de documentatie gewerkt. Voor de verbeteringen en veranderingen betreft het werkproces per sprint zie de sprintverslagen in bijlage D. 10

11 Stageverslag 4. ONTWERP is iteratief opgebouwd in 8 iteraties. Tijdens iedere iteratie zijn er functionaliteiten ontworpen en bijgebouwd. Dit hoofdstuk geeft een overzicht van het systeem als geheel als eindresultaat. Tijdens iedere iteratie is er een design document geschreven met alle technische stukken welke zijn toegevoegd in de betreffende iteratie. Dit hoofdstuk geeft globaal aan welke keuzes met welke argumentatie gemaakt zijn. Voor de technische details zal verwezen worden naar de design documenten. Er zijn een aantal belangrijke onderwerpen uitgekozen welke in dit hoofdstuk ter sprake zullen komen CLIENT SERVER ARCHITECTUUR is geschreven met web-based technologie in de programmeertalen JavaScript en PHP. Dit is een voorwaarde van Moxio geweest, omdat Outpost geschreven is in deze talen. Bij het ophalen van normale statische webpagina wordt gebruik gemaakt van een client server structuur, het http protocol, waarbij de gebruiker een pagina oproept welke door de server gegenereerd en gestuurd wordt naar de client. bestaat ook uit een client - server architectuur. De server biedt aan aantal publieke services aan welke gebruikt worden door de client. Deze services zijn onder andere het leveren van berichten uit de database en het opnieuw ophalen van berichten van alle aangesloten externe services. Het heeft een aantal voordelen om te kiezen voor een client server architectuur met een grote client en een server welke alleen data aanlevert. Het eerste voordeel is dat de client als geheel maar één keer wordt ingeladen waarna er alleen nog de benodigde data over de lijn gestuurd wordt. is hierdoor erg snel waardoor het programma vloeiend werkt. Ten tweede wordt de codebase gescheiden in zowel de programmeertaal als de verantwoordelijkheden. De client is geschreven in JavaScript en heeft als belangrijkste verantwoordelijkheid het ophalen en presenteren van de berichten waarbij de gebruiker daardoorheen kan navigeren. De server is geschreven in PHP en heeft als belangrijkste verantwoordelijkheid het leveren en actueel houden van de interne en externe berichten. De opdeling in client en server brengt ook nadelen met zich mee. De codebase in de client en de server hebben een andere programmeertaal. Een brede kennis is vereist om zowel de client als de server te ontwikkelen in verschillende talen. Er is in ieder geval een server nodig om alle externe berichten te cachen. Als naast het cachen ook het opzetten van de pagina s op de server geïmplementeerd wordt moet bijvoorbeeld iedere nieuwe pagina in als webpagina worden ingeladen omdat er een aanzienlijke hoeveelheid logica wordt uitgevoerd bij het indelen van het scherm. Dit zorgt voor een lange wachttijd voor iedere nieuwe pagina waar de gebruiker niet op zit te wachten. Met de client server architectuur en een gedeelde codebase kan degelijk en reactief gemaakt worden. Voor details over de client server architectuur zie Design Document 1 in bijlage E. 11

12 Stageverslag 4.2. MVC IN DE CLIENT De client heeft als verantwoordelijkheid berichten overzichtelijk en visueel aantrekkelijk op het scherm te presenteren. Hiervoor zal de code van een degelijke architectuur moeten worden voorzien om alle lagen, van het ontvangen van de data tot het representeren van de data, te scheiden van elkaar. Om die reden is er gekozen voor de MVC architectuur binnen de client. De verschillende lagen hebben zo allemaal andere verantwoordelijkheden en kunnen te allen tijde vervangen worden door een andere implementatie. De verschillende lagen van de client worden weergeven in het model uit figuur 4.1 De View, Control en Model zijn namespaces welke de lagen van de MVC structuur voorstellen. DOM View Controller (Control) Model Server FIGURE 4.1 De DOM- en Server laag zijn iets lichter gemaakt omdat deze lagen buiten de client van vallen. De DOM hoort bij de browser en de server is onderdeel van. De pijlen tussen de verschillende lagen duiden op de communicatie tussen beide lagen. De communicatie van de View naar de DOM en terug duid op de interactie tussen de gebruiker en de interface van. De eenzijdige communicatie tussen de Model laag en de Server laag zijn de aanroepen naar de verschillende services die de server te bieden heeft. Voor details over de MVC architectuur zie hoofdstuk 2 van Design Document 1 in bijlage E GRID Berichten moeten zowel overzichtelijk als dynamisch op het scherm weergeven worden. Daarbij moet het overzicht visueel aantrekkelijk zijn door middel van plaatjes. Dit waren enkele functionele eisen van. Om dit te bereiken is er een raster, hierna grid genoemd, bedacht waarmee we overzicht creëren en met simpele concepten ingewikkelde berekeningen uit kunnen voeren om de artikelen slim op het scherm in te delen. De vakken die gecreëerd worden zijn groot genoeg om een klein bericht in een enkel vak te plaatsen. Tevens kunnen combinaties van vakken een groter artikel vormen. Deze combinaties zijn vooraf gedefinieerd in de templates welke verderop dit hoofdstuk behandeld worden. Met de grid kunnen plaatsen op het scherm een bepaalde waarde krijgen. Het waarderen van vakken in de grid gebeurt op basis van wetenschappelijke rapporten. Dit wordt ook bij de templates behandeld. Voor details over grid zie hoofdstuk van Design Document 1 in bijlage E. 12

13 Stageverslag 4.4. TEMPLATES maakt gebruik van vooraf gedefinieerde templates van zowel de mogelijke indeling van een scherm als de mogelijke vorm van een artikel. Deze templates heten respectievelijk schermtemplates en artikeltemplates. Een artikeltemplate is altijd rechthoekig, omdat daar makkelijk mee kan worden gerekend en de schermtemplates zo overzichtelijk kunnen worden gemaakt en overzichtelijk kunnen worden gevisualiseerd. Een schermtemplate bestaat uit meerdere combinaties van artikeltemplates op vooraf gedefinieerde plaatsen binnen de dimensie van een schermtemplate. Deze templates zijn recursief opgezet waardoor het onderhoud op de templates wordt bevorderd en de complexiteit van het maken en onderhouden binnen de perken blijft. Een combinatie van een schermtemplate kan zo bestaan uit andere schermtemplates welke zelf verschillende mogelijkheden om in te delen hebben. Alle combinaties worden bij het starten van de applicatie eenmaal recursief uitgewerkt om zo de gehele sessie van de client gebruikt te kunnen worden. De schermtemplates en artikeltemplates zijn opgebouwd op basis van de grid en zorgen alleen voor beperkingen over de beschikbare ruimte en plaatsing van een bericht. Deze templates bepalen alleen de vorm en plaats van het artikel. Voor technische details over de verschillende templates zie hoofdstuk van Design Document 1 en hoofdstuk 2 van Design Document 2 welke beide in bijlage E te vinden zijn POPUPS Binnen wordt in twee situaties gebruik gemaakt van popups. Om de inhoud van een afgekort bericht in een detailbeeld te kunnen lezen en om iedere link binen, welke naar een externe website verwijst, in te openen. Hiertoe is besloten, omdat de gebruiker van alle functionaliteit moet kunnen gebruiken zonder de applicatie te verlaten. Mocht de gebruiker alsnog naar de externe website willen gaan kan deze binnen de popup op de titel klikken. Het is mogelijk om meerdere popups over elkaar open te hebben, hiertoe is besloten vanwege duidelijkheid, omdat detailpopups niet hoeven te verdwijnen als een websitepopup geopend wordt. De websitepopup ondersteund geen scripts binnen geopende websites. Hiervoor is gekozen vanwege veiligheidsoverwegingen. Als een website bijvoorbeeld binnen een popup JavaScript had kunnen gebruiken zou deze onder andere de mogelijkheid hebben informatie over de gebruiker van te verkrijgen. Voor details over de detail popup zie hoofdstuk 3 van Design Document 2 in bijlage E. Voor details over de website popup zie hoofdstuk 4 van Design Document 3 in bijlage E. 13

14 Stageverslag 4.6. PAGINA S EN TIJDSBLOKKEN Om door grote hoeveelheden artikelen te kunnen bladeren is besloten om tijdsblokken en pagina s binnen tijdsblokken te introduceren. De gekozen tijdsblokken zijn vandaag, gisteren, deze week en vorige week. Hiertoe is besloten omdat als vervanging van een krant tot leven is gekomen. Een krant heeft altijd pagina s binnen een dag, wil de lezer weten wat gisteren gebeurd is dan zal de krant van gisteren gezocht moeten worden. Als de gebruiker meer dan een dag terug wil kijken wordt, als de week verder dan dinsdag is, het tijdsblok deze week aangeroepen. De gebruiker ziet dan alle berichten uit die week op de huidige en vorige dag na. De mogelijkheid word niet geboden om verder als vorige week terug te kijken. Berichten ouder dan vorige week worden niet weergeven in. Hiertoe is besloten omdat nieuws ouder dan een week vrijwel nooit interessant is en in deze blokken zoveel berichten in zouden zitten dat een specifiek bericht niet te vinden is. Een andere reden is dat RSS bestanden vrijwel nooit verder dan een week terug gaan, zou in dat geval geen visualiserende dienst, maar cachende dienst worden. Deze structuur met de gekozen tijdsblokken en pagina s is dus voorspelbaar en gebruiksviendelijk. Voor verdere details zie hoofdstuk 1 uit Design Document 7 in bijlage E en hoofdstuk 1 uit Design Document 5 in bijlage E READABILITY maakt gebruik van Readability om de inhoud van websites uit te lezen. Er is gekozen om websites uit te lezen in een aantal gevallen. Als een uit een RSS feed gehaald bericht korter dan ongeveer 500 tekens is, dat is ongeveer de inhoud van één blok binnen, wordt de bijbehorende website uitgelezen en in het bericht geplaatst. Ook wordt de inhoud van een website uitgelezen als een bericht korter dan ongeveer 150 tekens is en er voornamelijk een url in staat. Hiervan wordt aangenomen dat het bericht bedoeld is om deze url aan te geven en wordt de inhoud van die website onderin het bericht geplaatst. In het vooronderzoek is onderzocht wat de beste optie was om informatie uit een website te verkrijgen. Uit het onderzoek is gekomen dat we het beste Readability konden gebruiken om deze functionaliteit binnen te realiseren. Readability maakt gebruik van Oauth en een RESTful API, om deze API te kunnen gebruiken is gekozen om gebruik te maken van een externe API. De reden hiervoor is dat het betrouwbaar implementeren van Oauth ingewikkeld bleek, en daarom teveel tijd zou kosten. Voor verdere details zie hoofdstuk 1 uit Design Document 3 in bijlage E en hoofdstuk 5 uit Design Document 6 in bijlage E. Voor details over Readability zie hoofdstuk 3 van het vooronderzoek in bijlage C. 14

15 Stageverslag 4.8. OPSPLITSEN CRONJOB Na het implementeren van de Cronjob, een automatisch script welke op vaste tijden RSS bestanden uitleest en als nodig websites uitleest met behulp van Readability, bleek deze te veel looptijd te kosten. Na het analyseren van dit probleem is geconcludeerd dat een oplossng bedacht moet worden. Het gevolg van de lange looptijd is dat bij het toevoegen van veel bronnen de looptijd zo lang kan worden dat niet alle berichten opgehaald worden. Ook kunnen daardoor verschillende Cronjobs tegelijk bezig zijn waardoor berichten dubbel opgehaald worden of de Cronjob fout gaat waarvan de gevolgen niet voorspelbaar zijn. Om dit probleem op te lossen is besloten de Cronjob op te splitsen in een deel dat de RSS feeds ophaalt en opslaat, en een deel dat de websites ophaalt en de inhoud van de berichten vervangt. De eerste Cronjob is relatief snel en zal alle op te halen berichten opslaan, hierdoor verdwijnen geen berichten. De Cronjob welke de websites uitleest is afhankelijk van de snelheid waarmee Readability berichten verwerkt. Hierdoor kan deze Cronjob lang duren. De lange looptijd is hier echter geen probleem omdat de berichten vanaf de nieuwste wordt verwerkt. Mocht deze Cronjob niet alle berichten kunnen verwerken dan zullen in de database korte berichten afkomstig uit RSS bestanden voorkomen. Dit heeft geen grote gevolgen voor de werking van. Voor verdere details over de eerste opzet van de cron handler zie hoofdstuk 4 uit Design Document 4 in bijlage E. Voor de details over het opsplitsen van de cron zie hoofdstuk 1 uit Design Document 6 in bijlage E OPTIMAAL ALGORITME Onder de kop optimaal algoritme is uitgewerkt hoe de optimale schermindeling binnen benaderd word. Dit idee is gebaseerd op de volgende drie waarden. 1. De opgeslagen belangrijkheid van een artikel. 2. De mate in hoe een artikel past in een bepaald formaat artikeltemplate. 3. De positie van een artikel op het scherm. Voor de details van de waarden zie hoofdstuk van Implementatie Document in bijlage F. Deze waarden zijn gekozen om op basis van de combinatie van de drie sets regels een schermtemplate te kiezen. De eerste set houdt rekening met voorkeuren van de gebruiker. Deze waarde is gekozen omdat de berichten van verschillende bronnen ook met verschillende prioriteiten behandeld worden. De tweede set voorkomt dat grote artikelen in kleine vakken komen en vice versa. Deze waarde is gekozen omdat dit verzekerd dat wanneer het mogelijk is het scherm rijkelijk gevuld is met informatie. De derde set verzekert de gebruiker dat belangrijke plaatsen op het scherm belangrijkere informatie bevatten. Dit is gebaseerd op wetenschappelijke onderzoeken, zie hoofdstuk van het vooronderzoek in bijlage C. 15

16 Stageverslag De combinatie van de drie verschillende waarden combineert de voorkeur van de gebruiker en de optimale lay-out. Met behulp van deze waarden worden schermtemplates gewaardeerd. Om de waarde van een schermtemplate te bepalen wordt deze eerst ingevult. De invulling wordt gedaan door per artikeltemplate het beste artikel te kiezen. De bovengenoemde waarden worden per artikel opgeteld, de waarde van alle artikelen samen bepaalt de waarde van de schermtemplate. Deze waarde wordt voor ieder schermtemplate bepaald, vervolgens wordt de schermtemplate met de hoogste waarde gekozen. Voor een uitgebreide beschrijving van het optimale algoritme zie hoofdstuk 3 van Design Document 3. Dit algoritme benadert de optimale schermindeling, het berekent de optimale schermindeling niet. Hier is voor gekozen, omdat alle combinaties en permutaties doorrekenen te veel rekenkracht en tijd kost. De benadering geeft goede resultaten, waardoor het niet nodig is om een zwaarder algoritme te gebruiken. Het algoritme is in een later stadium versneld, voor die details zie hoofdstuk 2 van Design Document 6 in bijlage E. 16

17 Stageverslag 5. IMPLEMENTATIE In dit hoofdstuk zal worden omschreven hoe de verschillende delen van samenhangen. Dit hoofdstuk zal een korte verwijzing naar het implementatie document zijn, omdat dit document alle informatie betreft de implementatie bevat. Hieronder wordt de structuur van het document kort omschreven. Het implementatie document bestaat uit twee hoofdstukken, de client en de server. In hoofdstuk 4.1 van dit stageverslag is uitgelegd waarom er gekozen is voor de client server structuur. De client is geïmplementeerd in JavaScript en de server in PHP. In hoofdstuk 1, de client, wordt per laag van de MVC architectuur de belangrijkste modules beschreven. Er wordt beschreven hoe ze in elkaar zitten en hoe ze werken. Een overzicht van alle klassen binnen de verschillende lagen van de client is te vinden in het UML diagram client static model in de bijlagen van het Implementatie Document. Een overzicht van de interactie tussen de belangrijkste klassen is te vinden in het UML diagram client interaction model in de bijlagen van het Implementatie Document welke te vinden is in bijlage F. In hoofdstuk 2, de server, worden de vier services in technisch detail besproken. Er zal worden uitgelegd welke klassen en methoden er gebruikt worden voor de betreffende service. De server verleent vier services, waarvan twee services door de client van kunnen worden gebruikt. De eerste service wordt gebruikt om artikelen van een stream uit de database op te vragen. De tweede service kan verschillende streams toevoegen aan een bepaalde streamset. Een stream is gedefinieerd als een chronologische lijst van informatieberichten, bijvoorbeeld een RSS feed. De derde service, de cron service, haalt informatieberichten op uit de ingestelde externe en interne streams en bepaald of er extra informatie uit websites gehaald moeten worden. De laatste service, de Readability service, verzamelt belangrijke informatie van websites welke door de cron service aangemerkt zijn om nader te bestuderen. 17

18 Stageverslag 6. CODE KWALITEIT BEOORDELING DOOR SIG De code van is begin juni ter beoordeling naar SIG gestuurd. De code is onder andere beoordeeld op Unit Size, Unit Interfacing en Unit Complexity. Unit Size is het percentage code dat bovengemiddeld lang is. Unit Interfacing geeft aan wanneer er een bovengemiddeld aantal parameters aan methodes meegegeven wordt. Unit Complexity geeft aan wanneer de code te complex is en mogelijk opgesplitst moet worden. Allereerst zal de aanbeveling van SIG kort omschreven worden. Het originele commentaar van SIG is te vinden in bijlage H. Na de omschrijving wordt per onderwerp omschreven hoe de feedback is verwerkt AANBEVELINGEN VANUIT SIG De code is gemiddeld onderhoudbaar. Bij Unit size wordt opgemerkt dat binnen een aantal methodes aparte stukken functionaliteit te vinden is. Het advies is om deze functionaliteiten in nieuwe methodes te verwerken en deze vanuit de functie waar het origineel in stond aan te roepen. Dit laatste is ook als (enige) aanmerking gegeven bij Unit Complexity. Voor Unit Interfacing heeft SIG aangegeven dat het aantal parameters dat met methoden meegegeven wordt niet te hoog is. Echter wordt wel aangegeven dat gebruik gemaakt van combinaties van parameters welke mogelijk samengevoegd in object doorgegeven zouden moeten worden. Als laatste geeft SIG aan dat geen Unit test code gevonden is. Dat is ons bij het opsturen van de code ontschoten. Er is echter gebruik gemaakt van een ontwikkelomgeving waarin de kern van de client bij iedere verandering getest werd OPSPLITSEN METHODEN Zowel op de server als de client zijn meerdere lange methoden wanneer mogelijk opgesplitst in kleinere methoden. Op de server is bijvoorbeeld RssReader::readArticle opgesplitst, de functionaliteiten binnen deze methode zijn hieruit gehaald, in andere methodes geplaatst en worden aangeroepen vanuit readarticle. Sommige methoden zijn alsnog ongeveer 40 tot 50 regels lang. Deze methoden zijn niet opgesplitst, omdat deze een enkele functionaliteit hebben zoals bijvoorbeeld een databaserequest. Deze methoden hebben geen overlappende functionaliteit en het is daarom vanwege overzichtelijkheid en werking ook beter om dit niet op te splitsen. In de client zijn in de files templatedefenition en templates enkele veranderingen aangebracht om lange methodes te verkorten. In templatedefinition wordt door getchoicetree gebruik gemaakt van de methode posarticle om de juiste JSON te creëren. Voor getflattenedscreentemplates is hetzelfde gedaan met de methode posscreen. Daarnaast is in de methode addposistionvalues gerefactored naar twee kortere methodes. In templates is de methode getscreenarticlematch aangepast. Hierin is de methode createdimensiontobestarticlestack geëxtraheerd, daarnaast zijn enkele if else statements gecombineerd. Hierdoor is de methode een stuk korter geworden. 18

19 Stageverslag 6.3. SAMENVOEGEN PARAMETERS Om de Unit Interfacing te verbeteren zijn op de server een aantal aanpassingen aangebracht. Als eerste is op iedere plek waar $source[ url ] en $source[ id ] apart doorgestuurd werd, deze twee variabelen vervangen met een maal $source. Dit is veel logischer en heeft tot gevolg dat deze variabele op slechts één plaats uitgesplitst hoeft te worden. Ook is $source waar mogelijk toegevoegd aan $article. Dit is nodig omdat elke article een bron (source) heeft, daarom is source onderdeel van een article. Hierdoor hoeft $source niet meer apart meegegeven te worden. Als laatste is bij updatearticle de parameter $article hernoemd naar $new_article, dit voorkomt verwarring doordat het leek alsof een article en een article_id apart of zelfs dubbel doorgegeven werden UNIT TESTS Naar aanleiding van de opmerking over Unit tests is het aantal tests uit de client uitgebreid. Toegevoegde tests testen nu ook de PageCacher en Timespans module. Hierin wordt de werking van de code binnen de gelijknamige bestanden geverifieerd. De modules in de View laag van de MVC architectuur in de client zijn allen afhankelijk van de DOM van de browser. Door deze afhankelijkheid konden hier geen unit tests voor geschreven worden. De modules in de Model laag zijn afhankelijk van de server. Om dezelfde reden kon voor de modules in de Model geen unit tests geschreven worden. Dit is echter wel geprobeerd in de beginfase van het ontwerpen van de software, echter bleken deze tests geen toegevoegde waarde te bieden. Er zijn geen Unit tests geschreven voor de PHP code op de server. De server is bij alle handelingen afhankelijk van de database en een aantal van externe partijen. De combinatie tussen complexiteit en onvoorspelbaarheid van de invoer van deze klassen zorgen voor ingewikkelde tests. De complexiteit heeft er ook voor gezorgd dat wij geen tijd vrij konden maken om hiervoor goede Unit tests te schrijven. Naast de unit tests is er goed verkennend getest en was er wekelijkse een acceptatietest bij de afsluiting van de sprint. 19

20 Stageverslag 7. CONCLUSIE De doelstelling van het project is gehaald door een werkende versie van binnen de gestelde termijn op te leveren aan Moxio. is een losstaande applicatie welke informatie van verschillende bronnen kan combineren tot een visueel aantrekkelijk overzicht. Hieronder een kort overzicht van de oplossingen en mogelijkheden die biedt. De oplossingen en mogelijkheden zijn gebaseerd op de volgende deelproblemen: 1. moet verschillende informatiebronnen kunnen verwerken 2. Hoe worden meerdere informatiebronnen gecombineerd? 3. Waar nodig extra informatie verzamelen 4. Hoe moet het dynamisch en overzichtelijk weergeven worden? De eerste twee deelproblemen, verschillende bronnen verwerken en combineren, worden op de server opgelost. De server kan RSS 2.0, Twitter met behulp van RSS en Outpost, het sociale extranet van Moxio, uitlezen. Met deze techniek kunnen verschillende bronnen verwerkt worden. De gevonden informatie wordt vervolgens in een standaardformaat opgeslagen. Door dit standaardformaat kan de informatie uit verschillende zowel interne als externe - bronnen worden gecombineerd. Het derde probleem, het verzamelen van extra informatie, is opgelost met behulp van een externe API. Inkomende informatieberichten worden in ons systeem gescand op links naar webpagina s. De gevonden links worden als het bericht zeer kort is doorgestuurd naar de externe API, die de hoofdinhoud uit een website extraheert. De bron van korte berichten, zoals veel RSS berichten, wordt ook doorgestuurd. De externe API waar gebruik van wordt gemaakt is van Readability. Het laatste probleem, het dynamisch en overzichtelijk weergeven van de informatie, is opgelost met behulp van templates. Er zijn heel veel aangename schermindelingen vooraf gedefinieerd, waar met een algoritme de beste schermindeling wordt gekozen. Het algoritme combineert verschillende waarden van zowel artikelen, de schermindeling en de plaatsen op het scherm. Het resultaat is een dichte benadering van de optimale oplossing. 20

21 Stageverslag 8. AANBEVELINGEN In dit hoofdstuk worden enkele aanbevelingen gegeven voor verdere ontwikkeling van. is ontworpen met de ontwikkelmethode scrum. Er is gebruik gemaakt van een future backlog waar alle toekomstige ideeën voor extra functionaliteiten in staan. De belangrijkste functies welke nog niet geïmplementeerd zijn worden in dit hoofdstuk besproken. Een apart onderdeel hierbij is de integratie van in Outpost. Een korte samenvatting van het integratie document is te vinden in paragraaf 8.1. De eerste aanbeveling voor de verdere ontwikkeling van is het vervangen van Readability. Tijdens het project is gebleken dat Readability regelmatig een lijst met linkjes teruggeeft in plaats van de hoofdinformatie van de webpagina. Een mogelijkheid hiervoor is het schrijven van een eigen API die de functionaliteit van Readability over-neemt. Door een eigen API te schrijven is er minder afhankelijkheid van andere partijen. Een andere aanbeveling is het verzorgen van live updates wanneer nieuwe pagina s beschikbaar zijn. Tijdens het gebruiken van zouden nieuwe pagina s kunnen worden opgebouwd met nieuw ontvangen berichten. Wanneer een nieuwe pagina af is zou de gebruiker een update kunnen krijgen dat er een nieuwe pagina beschikbaar is. Het verkrijgen van live updates van feeds kan worden gerealiseerd met het gebruik van het protocol PubSubHubbub 1. Dit is een protocol welke bijna instantaan een notificatie stuurt wanneer een bericht aan een feed wordt toegevoegd. Naast het gebruik maken van deze notificaties kunnen nieuwe berichten direct worden geladen zonder Cronjob INTEGRATIE MET OUTPOST In dit project is als losstaande applicatie ontwikkeld. Deze applicatie moet onderdeel gaan uitmaken van een sociaal extranet wat gebouwd is in een framework. In het integratie document, zie bijlage G, is omschreven wat de problemen zijn die je daarmee tegen komt en worden er alternatieven aangedragen. is ontwikkeld met gebruik van HTML5 en CSS3, deze technieken zijn echter nog in ontwikkeling en kunnen niet gebruikt worden door Outpost. De voornaamste complicatie die hieruit volgt is dat CSS Regions niet gebruikt kan worden. Dit heeft tot gevolg dat tekst niet over meerdere kolommen kan worden verdeeld. Er zijn verschillende alternaltieven om hier mee om te gaan. Deze alternatieven worden in bijlage G gepresenteerd, het beste alternatief is om de weergave aan te passen. Op die manier kan de huidige logica bewaard blijven. Websites kunnen niet op een veilige manier intern worden geopend, omdat er geen gebruik kan worden gemaakt van het sandbox attribuut. Wij raden daarom af om gebruik te maken van deze functionaliteit van wanneer deze geintegreerd wordt met Outpost. Tevens wordt HTML5 gebruikt om de leesbaarheid van de code te verhogen. Er zijn echter geen technische redenen om HTML5 te gebruiken, met enkele omschrijvingen kan bij de integratie worden volstaan

22 Stageverslag 9. EVALUATIE In de evaluatie wordt er terug gekeken naar het proces van het bachelorproject. Het bachelorproject wordt hier als geheel gezien, dat wil zeggen van het vooronderzoek tot de afsluiting van de stage. De eindpresentatie is hier niet bij betrokken aangezien deze na de inleverdatum van het stageverslag wordt gehouden. Het bachelorproject is goed verlopen. Het te ontwerpen en implementeren product is volledig af en werkt naar verwachting. Een aantal punten zijn beter gelopen als verwacht, een aantal punten zijn minder goed verlopen. Bij de start van het project is besloten om de scrum methode te gebruiken. Dit was zeker geen verkeerde keuze, de methode heeft ons zeer goed geholpen bij het project. Wel moet hierbij opgemerkt worden dat wij het gebruik van scrum hebben aangepast op onze benodigdheden. Ons team was bijvoorbeeld zo klein dat stand-up meetings niet handig zijn gebleken. Meerdere keren is geprobeerd hiermee te werken, het is echter na verloop van tijd geschrapt. Delen van scrum welke zeer goed geholpen hebben zijn de Backlog en het Scrum Board. Dankzij de backlog kon iedere week van tevoren goed bedacht worden wat die week zou moeten gebeuren en werd dit afgestemd met de begeleider. Op deze manier is het voor Moxio mogelijk geweest om tijdens het project sturing te geven zodat het eindproduct voldoet aan hun eisen. Het Scrum Board heeft doordeweeks geholpen met het kiezen van taken. De taken konden simpelweg van boven naar beneden opgepakt worden. Dit was mogelijk doordat de taken op het Scrum Board op prioriteit gerangschikt zijn. Iedereen kon iedere taak oppakken aangezien de taken onafhankelijk van elkaar voltooid konden worden. Af en toe werd er voorkeur gegeven aan een andere taak, omdat sommige taken op elkaar aansloten kostte het minder tijd om deze door een enkele persoon te laten uitvoeren. Zolang dit een van de bovenste taken op het Scrum Board was, was dit geen probleem. Aan het eind van iedere sprint is een werkende versie van opgeleverd. Op deze manier is er vanaf de eerste sprint gezorgd dat er een werkend product kon worden afgeleverd. Hierdoor is er van begin af aan zekerheid dat aan het eind van het project een werkend product kan worden afgeleverd. Het afleveren van een sprintverslag en een design document aan het einde van iedere sprint is zeer nuttig geweest. Gedurende elke sprint is gedocumenteerd wat er tijdens die sprint gebeurd is, hierdoor zijn aan het einde van het project afwegingen uit de eerste sprints niet vergeten. Het was tevens leerzaam om een keer te werken met scrum, bij projecten op de universiteit wordt deze ontwikkelmethode niet gebruikt. Het is echter een veelgebruikte techniek en het is nuttig om zelf te werken met scrum. Er zou tijdens de opleiding meer aandacht kunnen worden besteed aan scrum, bijvoorbeeld gedurende het vak Software Engineering of een groot project uitvoeren met behulp van scrum. De communicatie met onze projectbegeleider van Moxio verliep zeer goed. Iedere sprint hebben wij eenmaal rond de tafel gezeten om de voortgang te bekijken en de doelen voor de volgende sprint samen te stellen. Mocht iets niet meteen duidelijk zijn dan was het geen probleem als dit gevraagd werd. Ook was er regelmatig tijdens de sprint kort contact met de begeleider. 22

23 Stageverslag De samenwerking met de universiteit verliep vrij goed. Het wisselen van begeleiders was niet handig in verband met het verschil in inzicht in het project van de begeleiders op het moment van wisselen. Dat werd echter onderling prima afgestemd, wij hebben hier gelukkig geen problemen door ondervonden. 23

24 Stageverslag VERKLARENDE WOORDENLIJST API Application Programming Interface. Hiermee kan een programma communiceren met een ander programma. Browser CSS Cronjob DOM Google Chrome HTML JavaScript JSLint JSON OAuth Outpost Pairprogramming RESTful Software waarmee een webpagina bekeken kan worden. Voorbeelden van browsers zijn Internet explorer en Google Chrome. Een centraal bestand waarin de opmaak van een website geprogrammeerd is. Een Unix commando dat op een vooraf ingesteld tijdstip of interval een programma of script uitvoert. Document Object Model ; Het is een taalonafhankelijke conventie over de representatie en interactie van objecten in HTML, XHTML en XML documenten. De webbrowser van Google. Zie Browser. Een programmeertaal waarin websites opgebouwd worden. Programmeertaal waarmee web applicaties binnen een webbrowser gemaakt kunnen worden. Programma waarmee JavaScript gevalideerd kan worden. JavaScript Object Notation; Een open standaard voor de notatie van JavaScript objecten. Open Authorization. Hiervan wordt door sommige API s gebruik gemaakt om gebruikers of programma s te verifiëren. Sociaal extranet ontwikkeld door Moxio, hiermee wordt de communicatie tussen collega s bevorderd. Met twee of meer personen aan een computer werken. Een type API waarbij de gegevens met een simpele folder achtige structuur via de URL opgevraagd kunnen worden. RSS Een vastgestelde, door veel websites aangeboden techniek om nieuwsberichten op te halen. Namespace Scrum SIG Stream Streamset TFS Een set, of groep, waarin namen van variabelen, functies en/of constanten worden gegroepeerd. Een manier van programmeren met een groep. Er word per tijdsdeel besloten wat de doelen zijn. Software Improvement Group ; De geschreven code is door hen beoordeeld. Een chronologische lijst van informatieberichten, bijvoorbeeld een RSS feed. Een set van verschillende streams. Zie Stream. Team Foundation Server ; Een programma van Microsoft dat het gebruik van scrum ondersteund. 24

25 Stageverslag BIJLAGEN De bijlagen gaan dieper in op het ontwerpproces en de implementatie. Als u meer wilt weten over het proces raden wij u aan vooral de Sprint documenten te lezen, ook het plan van aanpak kan interessant zijn. Wilt u meer weten over de technische inhoud dan zijn vooral de Design documenten, het vooronderzoek en het integratie document interessant. Voorafgaand aan het werkelijke implementeren is het plan van aanpak en het vooronderzoek geschreven. Meer informatie over het proces tijdens de implementatie is te vinden in de Sprint documenten. In de design documenten en het implementatiedocument is uitgebreide technische informatie over de verschillende delen en de werking van te vinden, deze zijn per sprint uitgewerkt. In het integratie document wordt aangegeven hoe geïntegreerd kan worden in het bestaande sociale extranet Outpost. Als laatste is het origineel verkregen commentaar van SIG bijgevoegd. De indeling van de bijlagen ziet er als volgt uit. A. Stageomschrijving B. Plan van aanpak C. Vooronderzoek D. Sprint Documenten Sprint 1 verslag Sprint 2 verslag Sprint 3 verslag Sprint 4 verslag Sprint 5 verslag Sprint 6 verslag Sprint 7 verslag E. Design Documenten Design document 1 Design document 2 Design document 3 Design document 4 Design document 5 Design document 6 Design document 7 F. Implementatie Document G. Integratie Document H. Aanbevelingen vanuit SIG 25

26 Stageverslag BIJLAGE A S T A G E O M S C H R I J V I N G

27 Stageopdracht bij Moxio Het bedrijf Moxio is een ICT-dienstverlener, gevestigd in Delft. We hebben een sterke band met de TU Delft mede door onze kantoorlocatie op de campus en het feit dat de meeste medewerkers een opleiding aan de TU Delft gevolgd hebben. We ondersteunen organisaties met het ontwikkelen van web based software waarbij kennis beheren, delen, uitwisselen en visualiseren centraal staat. We hebben een breed scala aan klanten in sectoren als ontwikkelingssamenwerking, civiele werken en semi-overheid, waarmee we samenwerken om zeer diverse oplossingen te realiseren. Onze producten worden ontwikkeld op basis van PHP en JavaScript en maken gebruik van in-house ontwikkelde technologie zoals een CMS en een Javascript framework. De werkzaamheden variëren van informatieverstrekking via een website tot tailored applicaties waarbij complexe bedrijfsprocessen worden geoptimaliseerd. Voor meer informatie kun je contact opnemen met Melissa Korn via of telefonisch via Een volledig overzicht van onze contactgegevens: Moxio BV Rotterdamseweg 183c 2629 HD Delft De opdracht Een van de producten dat door Moxio ontwikkeld wordt is een sociaal extranet, Outpost. Door een mix van tradionele intranet functionaliteit en de vrije interactie van sociale media, is Outpost een platform waarmee een werknemer alle middelen tot zijn beschikking heeft om ongeacht locatie zijn werk te kunnen doen en met collega s samen te werken. Er zijn echter nog enkele hiaten in de functionaliteit van Outpost die gevuld moeten worden om werkprocessen echt goed te kunnen ondersteunen. De probleemstelling Binnen deze opdracht gaat een team van studenten op zoek naar een oplossing die werknemers ondersteund bij het verwerken van een stroom van informatie die dagelijks op ze af komt Moxio Rotterdamseweg 183c, 2629 HD Delft /6/2012 pagina 1 van 2

28 Deze informatie is afkomstig uit een reeks verschillende bronnen die allemaal om aandacht vechten, zowel vanuit de eigen organisatie als van buitenaf. Denk aan: ; updates vanuit todo-lijsten, bug-trackers en klantverzoeken; werk gerelateerd nieuws (bijv. van de eigen organisatie) en nieuws uit vak- en interessegebied; uitwisseling van links, documenten en andere informatie tussen collega s (via Outpost). In de consumentgerichte wereld bestaan reeds allerlei applicaties die dergelijke informatie al voor de gebruiker verzamelen en op een manier verpakken die zowel praktisch en efficiënt is, als leuk en gebruiksvriendelijk. Echter, op het web en met de tools die de professional nu tot zijn beschikking heeft zijn de mogelijkheden nog erg beperkt. Een webpagina moet (ook voor een vluchtige blik) in een nieuw scherm geopend worden en een document moet eerst een plek op de harde schijf toegewezen krijgen voor het bekeken kan worden in weer een andere applicatie. Planning en verwachtingen Tijdens de stage gaat een groep van 3 studenten op onderzoek uit naar de implicaties van het hierboven gestelde probleem. Binnen de context van een grotendeels op Javascript gebaseerde web-applicatie als Outpost onderzoeken ze de mogelijkheden om hier oplossingen voor te realiseren. In overleg met Moxio wordt een oplossingsrichting gekozen die een technisch interessante uitdaging biedt en in de vorm van een op zichzelf staande applicatie te realiseren is binnen de gestelde tijd. De analysefase zal voor de start van 23 april 2012 al afgerond zijn, waarna er fulltime gewerkt wordt aan synthese, realisatie, test en documentatie. Er zal gewerkt worden in korte sprints van plan, uitvoering en reflectie met de begeleiding. Werkomgeving Moxio voorziet in haar kantoorruimte in werkplekken voor de studenten. Daarnaast kunnen de studenten gebruik maken van alle faciliteiten die beschikbaar zijn zoals webservers, printers, overlegruimte en natuurlijk lunch. Er wordt gezorgd voor een marktconforme stagevergoeding in twee delen: een reguliere maandelijkse vergoeding en een mogelijke bonus bij succesvolle afronding van het project. De precieze hoogte van beide delen wordt nog bepaald. Begeleiding Tijdens het project kan gebruik gemaakt worden van de kennis en ervaring van de werknemers van Moxio. Directe begeleiding van het project wordt waargenomen door: ir. Koen Lageveen koen.lageveen@moxio.com Moxio Rotterdamseweg 183c, 2629 HD Delft /6/2012 pagina 2 van 2

29 Stageverslag BIJLAGE B P L A N V A N A A N P A K

30 Plan van aanpak P L A N V A N A A N P A K VOORWOORD Aan de hand van de opdrachtomschrijving wordt het plan van aanpak opgesteld. In dit document wordt gespecificeerd aan welke eisen het eindproduct moet voldoen, wat er gedurende de ontwikkeling van de betrokkenen kan worden verwacht en in welk tijdsbestek het project zal worden uitgevoerd. STREAMPAPER Het product wat ontwikkeld gaat worden heeft de naam gekregen. wordt ontwikkeld om informatie van verschillende bronnen op internet samen te voegen en deze op een informatieve en visueel aantrekkelijke manier te presenteren. SAMENVATTING Het te ontwikkelen programma wordt ontwikkeld met behulp van de softwareontwikkelingmethode scrum. Acht weken lang zal iedere week minimaal één maal met de projectbegeleider binnen Moxio overlegd worden wat die week in de sprint moet gebeuren, en of de afgelopen sprint goed verlopen is. De projectleden zullen dagelijks overleggen wat die dag moet gebeuren, aan het eind wordt samen met de product owner bekeken of dit voltooid is. Op 25 mei en 25 juni wordt met de opdrachtgever besproken wat de voortgang is en of deze naar mening van de opdrachtgever voldoende is. Er zal full time door de projectleden aan gewerkt worden, de opdrachtgever zorgt voor volledige werkplekken zodat op werktijden op het kantoor van Moxio gewerkt kan worden.

31 Plan van aanpak 1. INTRODUCTIE 1.1. AANLEIDING Een van de van de producten dat door Moxio ontwikkeld word is een sociaal extranet Outpost. Outpost is een platform waarmee een werknemer alle middelen tot zijn beschikking heeft om ongeacht zijn locatie te kunnen werken, en contact met collega s te behouden. Er zijn echter nog enkele missende functionaliteiten binnen Outpost. Een van deze functionaliteiten is een oplossing welke werknemers ondersteund bij het verwerken van een stroom van informatie die dagelijks op hen afkomt. Deze informatie is afkomstig uit een reeks verschillende bronnen, zowel vanuit de eigen organisatie als van buitenaf, welke allemaal aandacht vergen. Er bestaan reeds applicaties vanuit de consumentenwereld, welke deze functionaliteit vanuit verschillende bronnen combineren en weergeven. De mogelijkheden vanuit het web zijn echter voor professionals erg beperkt ACCORDERING EN BIJSTELLING De goedkeuring van het plan van aanpak zal via de projectbegeleider van de TU Delft en de projectbegeleider van Moxio verlopen. Nadat deze begeleiders commentaar op het plan van aanpak geleverd hebben, zal deze bijgesteld worden TOELICHTING OP DE OPBOUW VAN HET PLAN Het plan van aanpak bestaat uit vier hoofdzakelijke onderdelen. Deze delen zijn: Projectopdracht, Aanpak en tijdsplanning, Projectinrichting en Kwaliteitsborging. In projectopdracht wordt de opdracht afgebakend zodat het voor de opdrachtgever en projectmanager duidelijk is waar het product aan moet voldoen. In het hoofdstuk projectinrichting wordt uitgezet welke eisen er gesteld worden aan de organisatie van het project. Hierbij wordt onder andere de projectinrichting, rapportering en benodigde technische resources beschreven. In kwaliteitsborging wordt uitgewerkt op welke wijze de opdrachtgever en de projectleden in staat zijn de kwaliteit van het project te beïnvloeden. 2. PROJECTOPDRACHT In dit hoofdstuk wordt de opdracht afgebakend zodat het voor de opdrachtgever en projectmanager duidelijk is waar het product aan moet voldoen. Voor de ontwikkelaars is het duidelijk wat er van hun wordt verwacht PROJECTOMGEVING Moxio heeft een sociaal extranet, Outpost genaamd, dit is een mix van traditionele intranet functionaliteiten en vrije interactie van sociale media. Het is een platform waarmee een werknemer alle middelen tot zijn beschikking heeft om zijn werk te doen en met collega s samen te kunnen

32 Plan van aanpak werken. Informatiestromen worden momenteel weergegeven als een oneindige lijst met berichten bestaande uit platte tekst en eventueel een kleine thumbnail van een bijgevoegde foto en/of document. In dit platform kunnen betere oplossingen bedacht worden om de verschillende informatiestromen van Outpost in een informatief overzicht te presenteren. Het betreft hier zowel interne als externe informatiestromen DOELSTELLING PROJECT Een informatief overzicht van alle interne en een aantal externe communicatie stromen is een waardevolle toevoeging voor Outpost. Belangrijke berichten staan op strategische plekken om met een snelle blik het belangrijkste nieuws te kunnen identificeren. De structuur van het overzicht is duidelijk en eenvoudig qua vormgeving. Het overzicht is creatief ingedeeld en zal de beschikbare informatie van berichten zo veel mogelijk proberen te visualiseren OPDRACHTFORMULERING Binnen deze opdracht gaat een team van studenten op zoek naar een oplossing die werknemers ondersteund bij het verwerken van een stroom van informatie die dagelijks op ze af komt. Deze informatie is afkomstig uit een reeks verschillende bronnen die allemaal om aandacht vechten, zowel vanuit de eigen organisatie als van buitenaf. Denk aan: ; Updates vanuit todo-lijsten, bug-trackers en klantverzoeken; Werk gerelateerd nieuws (bijv. van de eigen organisatie) en nieuws uit vak- en interessegebied; Uitwisseling van links, documenten en andere informatie tussen collega s (via Outpost). In de consument gerichte wereld bestaan al allerlei applicaties die dergelijke informatie al voor de gebruiker verzamelen en op een manier verpakken die zowel praktisch en efficiënt is als leuk en gebruiksvriendelijk. Echter, op het web en met de tools die de professional nu tot zijn beschikking heeft zijn de mogelijkheden nog erg beperkt. Een webpagina moet (ook voor een vluchtige blik) in een nieuw scherm geopend worden en een document moet eerst een plek op de harde schijf toegewezen krijgen voor het bekeken kan worden in weer een andere applicatie. De hoofdverantwoordelijkheid van het project is de basis van, het is de bedoeling dat de basis bestaat uit de algoritmen om de berichten op het scherm weer te geven en de uitwerking hiervan. Ook bevat de basis in ieder geval een of meerdere vormen van uit te lezen streams, zoals RSS, zodat de functionaliteit van duidelijk is. De opdrachtgever acht het belangrijker dat de uit te lezen streams zo foutloos mogelijk verwerkt worden, dan dat er zo veel mogelijk streams uitgelezen kunnen worden, kwaliteit gaat boven kwantiteit. De opdrachtgever verwacht dat naast het ontwikkelen van ook korte tijd gewerkt kan worden aan tot relevante problemen binnen Outpost. Dit laatste is belangrijk omdat de projectleden dan beter leren hoe het ontwikkelen en onderhouden van software in een professionele omgeving in werk gaat.

33 Plan van aanpak 2.4. OP TE LEVEREN PRODUCTEN EN DIENSTEN De analysefase zal voor de start van 23 april 2012 al afgerond zijn, waarna er fulltime gewerkt wordt aan synthese, realisatie, test en documentatie. Er zal gewerkt worden in korte sprints van plan, uitvoering en reflectie met de begeleiding. De opdrachtgever verwacht een uitgewerkt prototype van, het prototype moet werken en aan de hand van het concept moet bepaald kunnen worden of het bruikbaar is. Eventueel wil de opdrachtgever de code, of het ontwerp achter de code gebruiken en uitbreiden voor een definitieve versie van EISEN EN BEPERKINGEN Het vooronderzoek zal voor de start van 23 april 2012 al afgerond zijn, waarna er fulltime wordt gewerkt met behulp van Scrum. De eisen en beperkingen zullen worden gespecificeerd in de vorm van de product backlog. Deze product backlog items zullen worden voorzien van zowel business value als de tijdsinvestering van het desbetreffende item. Op deze manier kunnen er aan de hand van de prioriteiten items worden geselecteerd voor de verschillende sprints VOORWAARDEN Het project wordt uitgevoerd met scrum als iteratieve softwareontwikkelingmethode. Hierbij worden traditionele rollen omgezet naar verschillende rollen die binnen de scrum methodiek vallen. Binnen scrum heb je de rol scrum master, deze rol wordt iedere sprint door een andere student op zich genomen. In het sprint verslag wordt expliciet vermeld wie de scrum master was. De scrum master heeft als verantwoordelijkheid dat het scrum als proces goed verloopt. Dit houdt in dat de scrum master zorgt voor een kwalitatieve start en afsluiting van de sprint. De scrum master zorgt tevens voor de dagelijkse stand-up meetings. De studenten vervullen allemaal de rol developer, tester en software engineer. Deze worden nergens vastgelegd en ook niet gewisseld. De studenten zijn allround ontwikkelaars. In een scrum proces zijn de ontwikkelaars verantwoordelijk voor de voortgang en kwaliteit van het ontwikkelproces. De product owner is eigenaar van de product backlog en ook hoofd verantwoordelijke van de backlog. De product owner is daarom direct verantwoordelijk voor de kwaliteit van de backlog en indirect voor de kwaliteit van het product. De rol van product owner wordt vervult door Koen Lageveen. Naast de rollen binnen het scrum proces zijn er nog wat rollen welke vervuld moeten worden op het stage niveau. De opdrachtgever is Hylke van der Kolk namens Moxio. De stagebegeleider binnen Moxio is Koen Lageveen. Hierbij wordt opgemerkt dat er in het scrum proces geen projectmanager is omdat het team zelf de planning maakt en verantwoordelijk is voor het verloop en de kwaliteit van het product. De stagebegeleider binnen Moxio zal zorgen voor begeleiding van de technische vraagstukken tijdens het softwareontwikkelingproces. De stagebegeleider van de TU Delft is Peter van Nieuwenhuizen, welke vooral een controlerende en tevens begeleidende rol heeft. Rond 4 mei zal de begeleiding van de TU Delft over worden genomen door David Tax.

34 Plan van aanpak 3. AANPAK EN TIJDSPLANNING Het ontwikkeltraject is ingedeeld in acht sprints van ongeveer een week lang. De data van de sprints staan in bijlage 1. Voordat de eerste sprint van start gaat wordt een opzet van de product backlog, geproduceerd door het team, gepresenteerd aan de product owner. De opzet van de product backlog wordt samen met de product owner getransformeerd naar een product backlog waaruit de eerste backlog items voor de eerste sprint geselecteerd kunnen worden. Voor iedere sprint is input van de product owner nodig. De product owner zal bij het opstarten van de sprint presenteren welke backlog items er in de eerste sprint worden verwerkt. Deze items zullen door het team door middel van vragen en overleg samen met de product owner worden uitgewerkt. De specificaties worden zodanig uitgewerkt dat het team in staat is om de taken in te kunnen schatten, verdelen en op te pakken. Aan het einde van de sprint wordt een werkend product getoond met de verschillende backlog items van de desbetreffende sprint werkend in het geheel. De feedback van de product owner en eventueel producteigenaar worden verwerkt in de product backlog en kunnen bij een hoge prioriteit in de volgende sprint verwerkt worden. 4. PROJECTINRICHTING In de projectinrichting wordt uitgezet welke eisen er gesteld worden aan de organisatie van het project, onder andere projectinrichting, rapportering en benodigde technische resources zullen beschreven worden ORGANISATIE De betrokken projectleden zijn de drie stagiaires; Peter van Buul, Hylke Hendriksen en Huub van der Voort. De projectleden zijn als team verantwoordelijk voor het eindresultaat, echter zal de rol van scrum master per sprint gerouleerd worden, zodat ieder lid ervaren heeft hoe dit in werking gaat PERSONEEL De opdrachtgever en de product owner zullen afkomstig zijn van Moxio. De product owner zal minimaal een keer per week met de projectleden bespreken hoe het met het project staat, wat de sprint planning van de betreffende week is en of aan de planning van de afgelopen week voldaan is. De opdrachtgever heeft binnen het project geen actieve rol, deze zal overleggen met de product owner waarbij de richting van het product bijgestuurd kan worden. Ook zal een deel van het overige personeel van Moxio van tijd tot tijd beschikbaar zijn voor begeleiding en technische vragen.

35 Plan van aanpak 4.3. ADMINISTRATIEVE PROCEDURES Het project wordt in goede banen geleid door middel van een aantal bijeenkomsten. Eenmaal per week zal met de product owner besproken worden wat de deliverables van de komende sprint zullen worden, en of de afgelopen sprint voldoende voltooid is. Verder zullen de projectleden aan het begin en eind van iedere werkdag bij elkaar komen voor de stand-up meeting waarbij zal worden besproken wat per persoon gedaan is, gedaan gaat worden en problemen die ze zijn tegen gekomen. Ook is het, omdat de projectleden doorgaans in dezelfde ruimte werken, gemakkelijk om tussendoor overleg te plegen. Alle bijeenkomsten leiden ertoe dat het project niet te ver uit baan kan treden, waardoor het eindresultaat overeen zal komen met wat de product owner in gedachten heeft FINANCIERING De projectleden hebben ieder beschikking over een volledige werkplek en kunnen gebruik maken van beschikbare testresources. De werkplek beschikt over voldoende off-, en online opslagruimte, benodigde (software) tools. De studenten krijgen een financiele vergoeding voor de gedane werkzaamheden. Deze financiering bestaat uit een vast bedrag en een bonus. Deze financiering is opgenomen in een stagecontract RAPPORTERING De communicatie richting de opdrachtgever zal grotendeels via de product owner verlopen, deze zal er voor zorgen dat de eisen van de opdrachtgever vertaald worden in de wekelijkse planning en dus ook het eindproduct. Op 25 mei en 25 juni wordt met de opdrachtgever besproken wat de voortgang is, en of deze naar mening van de opdrachtgever voldoende is RESOURCES Voor ieder projectlid is er een werkplek met een computer met het besturingssysteem Windows. Deze computer bevat een tekstverwerkingsprogramma, toegang tot het internet, toegang tot de (test)servers van Moxio en een development environment om het product in te ontwikkelen. De projectleden hebben de mogelijkheid om naar wens open source of gratis legale software te installeren. Verder hebben de projectleden toegang tot de preview versie van het Scrum softwarepakket van Microsoft, TFS. De projectleden kunnen bestanden delen met behulp van de servers van Moxio. Deze servers beschikken ook over een dagelijkse back-up functionaliteit, waardoor bestanden veilig bewaard worden. 5. KWALITEITSBORGING De opdrachtgever en de product owner zijn beide werkzaam bij Moxio, zij hebben onderling contact zodat de visie van Moxio op in het product terug komt. Bij Scrum is de product owner nauw betrokken in het ontwikkeltraject. Met behulp van de product backlog en tussentijdse meetings heeft de product owner invloed op het product. De kwaliteit van de product backlog is bepalend voor de kwaliteit van het product, door de backlog samen met de product owner te maken

36 Plan van aanpak heeft deze invloed op de kwaliteit van het product. Daarnaast komen er twee keer per week meetings met de product owner om de voortgang te bespreken. Het betreft hier de start en afsluiting van de sprint. Hierbij wordt feedback van de product owner verwerkt in de product backlog zodat het zo snel mogelijk in het ontwikkeltraject opgepakt kan worden als het prioriteit heeft. Er zullen ook tussentijdse beoordelingen door Moxio plaatsvinden. De combinatie van deze meetings met de backlog moeten zorgen dat Moxio voldoende betrokken is bij de ontwikkeling van. BIJLAGEN Sprints 1. PLANNING Sprint Van Tot Duur sprint (in dagen) Sprint 1 25/05 04/05 7 Sprint 2 07/05 11/05 5 Sprint 3 14/05 18/05 4 Sprint 4 21/05 25/05 5 Sprint 5 28/05 01/06 4 Sprint 6 04/06 08/06 5 Sprint 7 11/06 15/06 5 Sprint 8 18/06 22/06 5 Vrije dagen Dag Datum Koninginnedag 30/04 Hemelvaart 17/05 Pinksteren 28/05

37 Plan van aanpak 2. CONTACTGEGEVENS Moxio BV Koen Lageveen Hylke van der Kolk Peter van Nieuwenhuizen David Tax Hylke Hendriksen Peter van Buul Huub van der Voort

38 Stageverslag BIJLAGE C V O O R O N DERZOEK

39 TUDELFT Vooronderzoek Hylke Hendriksen, Peter van Buul en Huub van der Voort Onderzoeksverslag naar de mogelijkheid van de bouw van een digitale knipselkrant, genaamd. In het eerste deel is onderzocht wat CSS3 en HTML5 kunnen betekenen bij de ontwikkeling van. In het tweede deel is gekeken hoe informatie op internet wordt aangeboden. In het derde deel is onderzocht hoe de user interface van kan worden opgebouwd.

40 Titel Vooronderzoek Auteurs In opdracht van Hylke Hendriksen Peter van Buul Huub van der Voort TU Delft en Moxio

41 INHOUD VOORWOORD... 1 INLEIDING CSS REGIONS MULTI-COLUMN EXCLUDES & FRAGMENTATION TRANSITIONS TRANSFORMS ANIMATIONS ONTWERP TOEVOEGINGEN 5 2. HTML CLIENT SIDE STORAGE WEB STORAGE WEB SQL DATABASE INDEXED DATABASE NADELEN VAN LOKALE DATABASES SELECTORS API IFRAMES BROWSERONDERSTEUNING 8 3. BERICHTEXTRACTIE UIT WEBSITES BESTAANDE PROGRAMMA S READABILITY BOILERPIPE ALGEMENE UITLEESBAARHEID VAN RSS FEEDS EN GOOGLE READER RSS STANDAARDEN ELEMENTEN BINNEN RSS ANALYSE EXTERNE RSS FEEDS GOOGLE READER WAT KAN GOOGLE READER BIEDEN? BRUIKBAARHEID GOOGLE READER VOOR STREAMPAPER... 14

42 4.4.3 STRUCTUUR GOOGLE READER FEED USER INTERFACE DEFINITIE INPUT TEMPLATES ARTIKELTEMPLATES BESTAAND ONDERZOEK SCHERMANALYSE OPBOUW ARTIKELTEMPLATES OPBOUW SCHERMTEMPLATES BIJZONDERE GEVALLEN CONCLUSIE BIBLIOGRAFIE BIJLAGEN BIJLAGE 1: LIJST VAN ARTIKELTEMPLATES 33 BIJLAGE 2: LIJST VAN SCHERMTEMPLATES KLEINE RASTERS (1X1, 2X1 & 1X2) MIDDELGROTE RASTERS (2X2, 2X3 & 3X2) MIDDELGROTE RASTERS (3X1, 1X3 & 3X3) GROTE RASTERS (4X2, 4X1, 1X4 & 4X3) GROTE RASTERS (4X4) GROTE RASTERS (4X5) GROTE RASTERS (4X6) GROTE RASTERS (4X7)... 39

43 Vooronderzoek Voorwoord VOORWOORD Dit onderzoek is gedaan ter voorbereiding van de ontwikkeling van een applicatie genaamd. Dit vindt plaats in het kader van ons bachelor eindproject aan de TU Delft onder begeleiding van de firma Moxio. INLEIDING wordt ontwikkeld om informatie van verschillende bronnen op internet samen te voegen en deze op een informatieve en visueel aantrekkelijke manier te presenteren. In het onderzoek hebben we de ruimte gekregen om de nieuwste technieken te onderzoeken en grotendeels te bepalen welke we kunnen gebruiken voor de implementatie van. De opzet van is dat het bij een succesvol prototype geïntegreerd wordt in Outpost, het social extranet van Moxio. De web-based applicaties van Moxio worden klant specifiek uitgerold, waardoor Moxio invloed heeft op sommige omgevingsfactoren waaronder de browserkeuze. Voor Moxio kunnen we met de nieuwste technieken aan de slag en op één bepaalde omgeving alles ontwikkelen. In de eerste twee hoofdstukken is onderzocht wat CSS3 en HTML5 kunnen betekenen bij de ontwikkeling van. In het derde hoofdstuk is gekeken hoe informatie van websides kan worden geëxtraheerd. In het vierde hoofdstuk is onderzocht hoe RSS feeds en google reader kunnen worden uitgelezen. In het vijfde hoofdstuk is onderzocht hoe de user interface van kan worden opgebouwd. 1

44 Vooronderzoek 1. CSS3 1. CSS3 CSS3 is de nieuwe versie Cascading Style Sheets. CSS3 is nog volop in ontwikkeling en is nog geen officiële standaard. Ondanks dat hebben veel browsers, vooral de nieuwste versies, verschillende modules van CSS3 opgenomen en kan je stukken uit CSS3 gebruiken. In een recente blog post van Adobe wordt ingegaan op de Regions module (1). Deze module is nog deels in ontwikkeling en hangt erg samen met andere modules van de CSS3 collectie. Drie uitbreidingen van CSS3 blijken zeer nuttig voor onze toepassing. Na een analyse van deze blog zijn de modules regions, excludes en fragmentation gemarkeerd als potentieel onderdeel van. 1.1 REGIONS Onderdeel van CSS Regions is ten eerste de threading content waarbij tekstuele inhoud over verschillende vlakken verdeeld wordt. Ten tweede region styling waarbij de tekstuele inhoud in verschillende vlakken - welke onderdeel zijn van threading content - verschillende stijlen kan bevatten. De regions module is nog deels in ontwikkeling waardoor de browsers die een deel al geïmplementeerd hebben de attribuutnamen geprefixt hebben. In Chrome hebben de regels de prefix -webkit-. FIGUUR 1: THREADING CONTENT ADOBE Allereerst de threading content. Dit kan worden geïmplementeerd met de CSS attributen flowinto en flow-from. Er kan een HTML element worden aangemaakt waar een artikel in staat. Deze content kan worden geassocieerd met een thread, zoals Adobe dat noemt, welke door andere elementen opgepakt kunnen worden. In figuur 1 is te zien dat de content verdeeld wordt over verschillende elementen. Dit is gerealiseerd met de flow-into en flow-from eigenschappen. Er zijn ook mogelijkheden om de informatie met een vooraf gedefinieerde volgorde te verdelen over verschillende elementen. Zo kan je verzekeren dat kolommen goed doorlopen en niet toevallig verkeerd gerenderd worden. Dit kan worden voltooid met de eigenschap wrap-shapeorder. Deze functionaliteit is echter nog niet ondersteund en geïmplementeerd in webkit (2). Region styling kan met behulp van regions in css3. Ook dit is momenteel nog niet beschikbaar in webkit (3). Hieronder staat een voorbeeld waarbij de inhoud van het artikel element in de verschillende regio s vloeit. article { flow-into: article_flow; } #region1, #region2, #region3, #region4 { flow-from: article_flow; } 2

45 Vooronderzoek 1. CSS3 1.2 MULTI-COLUMN Met de regions module kunnen we content van de ene container over laten lopen in de andere container. Hiermee kan onder andere een aantal kolommen gemaakt worden waarmee een tekstueel artikel in kolommen opgedeeld is. Dit is leesbaarder dan een grote lap tekst. Dit indelen in kolommen kan op een gemakkelijke manier wanneer de kolommen identiek zijn en in hetzelfde element gerenderd worden (4). De volgende CSS properties kunnen gebruikt worden om het voorgaande idee te realiseren. De column-count eigenschap stelt het aantal kolommen voor een HTML element in. Met columngap kan de grootte van het gat tussen de kolommen worden ingesteld, bijvoorbeeld in pixels. De breedte van een kolom kan met column-width worden vastgezet. Een column-rule kan worden ingesteld. Dit is een lijn tussen de kolommen, een soort border. Uiteindelijk maakt de CSS eigenschap tekst-align: justify het geheel af. #multi-column-example1 { column-count: 3; column-gap: 20px; text-align: justify; } #multi-column-example2 { column-width: 200px; column-gap: 30px; text-align: justify; } 1.3 EXCLUDES & FRAGMENTATION Onderdeel van de module excludes is het stuk waarmee je tekst om allerlei vormen heen kan wrappen. Andersom kan de tekst ook in bepaalde vormen gewrapt worden, echter is deze laatste toepassing niet relevant voor de implementatie van. CSS Fragmentatie betreft het opdelen van HTML elementen in onderdelen, bijvoorbeeld pagina s. Dit kan erg interessant zijn bij het bekijken van een lang artikel binnen onze applicatie. Hier gaat het om het passen van tekstuele content binnen een bepaald element. Er kunnen verschillende voorwaarden gemaakt worden, bijvoorbeeld waar je de pagina wil laten kunnen eindigen. Excludes & fragmentation zijn beide nog in ontwikkeling. 1.4 TRANSITIONS Met de CSS transities kunnen HTML elementen aangepast worden zonder het gebruik van javascript. Deze transities kunnen uitgevoerd worden door bijvoorbeeld een tijd-event of aan de hand van user events zoals een mouse-over. Voor onze software kunnen we verschillende elementen na een mouse-over een CSS transitie laten doen. Dit zal de javascript code voor de kern van schoon houden omdat de simpele bewegingen en veranderingen van de user interface in CSS ingesteld kunnen worden. Daarnaast zijn toepassingen te bedenken zoals bijvoorbeeld het animeren van een diashow of bewegen van een foto balk. Transities zijn simpel in te stellen en vereisen geen keyframe animaties. De werking van de transities gaat vrij eenvoudig. De transitie heeft 4 eigenschappen: property, duration, timing-function en delay. Deze zijn met de prefix transition- in te stellen in CSS. Het kan snel worden ingesteld met alleen een transition eigenschap. De volgorde van waarden is de volgorde property, duration, timing-function en als laatste delay. In een klein voorbeeld gaan we een transitie toepassen op een link element. 3

46 Vooronderzoek 1. CSS3 a { } background: #9c3; transition-property: background; transition-duration: 0.3s; transition-timing-function: ease; a { } background: #9c3; transition: background 0.3s ease; De stukken code links en rechts doen exact hetzelfde. Er wordt een transitie aangemaakt voor de achtergrond stijl voor 0.3 seconde met ease als transitie effect. De transitie moet nu alleen nog afgevuurd worden. Dit is te doen met de volgende code. a:hover { } background: #690; CSS heeft nu een transitie effect wanneer je met je muis over een link element heen beweegt. De verschillende soorten transitie effecten zijn ease, linear, ease-in, ease-out, ease-in-out en cubicbezier welke je toestaat je eigen tijdsgrafiek in te stellen. 1.5 TRANSFORMS De transforms module biedt de mogelijkheid de transform operaties als skew, rotate, scale en translate op alle DOM elementen toe te passen. De transform functies zijn in CSS in te stellen zoals bijvoorbeeld de code hieronder. div { } transform: rotate(30deg); 1.6 ANIMATIONS De animations module geeft ons de mogelijkheid om keyframe gebaseerde animatie toe te passen op HTML elementen. Dit geeft ons nauwkeurige controle over de animaties van HTML elementen in combinatie met de CSS eigenschappen. In zouden animaties een grote rol kunnen spelen bij de gebruikerservaring van onder andere het navigeren tussen het overzicht en de detail view van een artikel. De CSS3 animatie module is groot en zullen we proberen uit te leggen in een kort stukje tekst met een voorbeeld. Met de gevolgd door de naam van de animatie kan een animatie worden gedefinieerd. Daarin kan de animatie met from{} en to{} ingevuld worden. Dit ziet er als volgt my-animation-example { from {background: red;} to {background: yellow;} } Hierboven is alleen een begin en eindpunt gedefinieerd. Deze kunnen ook tijdens de animatie veranderen, de invulling van de animatie ziet er dan als volgt uit: 4

47 Vooronderzoek 1. my-animation-example { } 0% {background: red;} 25% {background: yellow;} 50% {background: blue;} 100% {background: green;} Een animatie is nu gedefinieerd en verschillende CSS veranderingen zijn aan deze animatie gekoppeld. De animatie moet nu nog worden aangeroepen door een stukje CSS op een element. De CSS property animation heeft de volgende eigenschappen: name, duration, timing-function (komt overeen met de timing-function van transities), delay, iteration-count, direction en playstate. Iteration-count specificeert het aantal iteraties van de animatie, directions de richting van de animatie in geval van meerdere animaties (bijvoorbeeld alternerend). Play-state is de status van de animatie, deze kan playing of pausing zijn. Wanneer deze property wordt veranderd zal ook de animatie stoppen of starten. Een element welke als voorbeeld gaat animeren ziet er als volgt uit: div { } animation-name: my-animation-example; animation-duration: 5s; animation-timing-function: linear; animation-delay: 2s; animation-iteration-count: infinite; animation-direction: alternate; animation-play-state: running; 1.7 ONTWERP TOEVOEGINGEN Er zijn nog veel toevoegingen in CSS waar we gebruik van kunnen maken om het gebruikersgemak en de gebruikerservaring van de te maximaliseren. Bijvoorbeeld: om elementen kan schaduw gezet worden. Dit kan ook worden gebruikt achter tekst. Echter moet de tekst er perfect uitzien omdat dat de primaire functie is van. Naast de tekst kan ook bijvoorbeeld een popup een schaduw krijgen om daarmee aan te geven dat deze weergave op het moment belangrijk is. Een CSS gradient kan heel licht een achtergrondeffect geven aan een artikel. Zo wordt het uiterlijk niet zo saai en eenzijdig. Veel functionele toepassingen die te maken hebben met het passend maken van tekst binnen een vooraf ingestelde marge staan wel op de roadmap van CSS maar zijn echter nog niet toegevoegd (5). Het betreft hier de eigenschappen tekst-wrap, voor het instellen van de wrap modus, en overflow-wrap voor het instellen hoe woorden en regels afgebroken moeten worden. Echter de eigenschap tekst-overflow is al wel geïmplementeerd en werkend in browsers. Deze eigenschap bepaalt hoe een stuk tekst eindigt wanneer overflow optreedt. Er zijn twee accepterende waardes, clip en ellipsis. Clip is standaard ingesteld en breekt gewoon de tekst af waar nodig. De ellipsis zal de tekst afbreken en een ellipsis invoegen. 5

48 Vooronderzoek 2. HTML5 2. HTML5 De vier belangrijkste elementen van HTML5 zijn het canvas- en video element, de geolocatie en de offline applicaties. Adobe heeft een HTML5 showcase met veel HTML5 en CSS3 modules. Deze showcase is online te vinden op beta.theexpressiveweb.com (6). De details van de offline applicaties zijn het meest belangrijk voor. De nadruk zal dan ook liggen op de offline werking van de applicatie. Ook selectors en de navigatie module worden in dit hoofdstuk behandeld. 2.1 CLIENT SIDE STORAGE Er zijn verschillende manieren om waarden op te slaan op de client. Voor zou het handig zijn als we een lijst met artikelen op konden halen die we lokaal weg kunnen schrijven waarna we later eenvoudig, snel en niet noodzakelijk met internetverbinding een overzicht kunnen creëren met de beschikbare artikelen. De lokale data moet dan wel gesynchroniseerd worden om de overzichten actueel te houden. In een artikel op html5rocks staat een vergelijking van verschillende local storage API s (7). In het artikel worden onder andere de volgende storage API s beschreven: web storage, web SQL database en indexed database WEB STORAGE Web storage kan waarden opslaan op de client computer in key/value paren (8). Het concept lijkt heel erg op cookies, maar het heeft een aantal cruciale voordelen ten opzichte van cookies. De eerste is dat de web storage niet mee gestuurd wordt met ieder request aan de server. Ten tweede kan er simpelweg meer data worden opgeslagen. Web storage kan niet worden gebruikt voor het opslaan van artikelen, maar voor wat simpele gegevens, bijvoorbeeld opties, om zo het gebruikersgemak hoog te houden is het heel geschikt WEB SQL DATABASE Naast de mogelijkheid om key/value pairs op te slaan is er ook een mogelijkheid om de local storage te benaderen als een database (9). Hierbij kan een tabel aangemaakt worden en kunnen verschillende SQL queries uitgevoerd worden op de lokale database. Deze lokale database kan bereikt worden met javascript code. Deze variant is echter niet geschikt voor veranderingen, want het databasemodel moet van te voren worden aangegeven. Om die reden is het niet flexibel genoeg voor agile technieken. Web SQL Database valt af voor met als voornaamste reden dat deze API deprecated is INDEXED DATABASE Deze variant is ontstaan uit de gebruikservaringen van de twee bovenstaande API s. Deze API is flexibeler omdat hij geen vooraf gedefinieerd model nodig heeft. De indexed database is een collectie van verschillende object stores. In iedere store kan je objecten opslaan. Er zijn geen restricties voor de object structuur waardoor het mogelijk is om later wijzigingen in de structuur door te voeren. Je kunt het vergelijken met een kaartenbak voor visitekaartjes, op sommige staat alleen een naam, op een andere kaart staat ook een adres en telefoonnummer. 6

49 Vooronderzoek 2. HTML5 Er kunnen indexes worden aangewezen op de stores om de zoeksnelheid te verbeteren. Het heeft een goede performance en brede ondersteuning van browsers. Het is gemakkelijk te leren dankzij het zeer eenvoudige data model. Nadelen van deze API is dat de objecten volledig ongestructureerd zijn opgeslagen, wat dus organisatie vereist. Een simpele tutorial om met indexed database aan de slag te gaan staat op html5rocks (10). Interessant om te zien is dat deze flexibele databases ook op apache gebouwd worden om zo de server en client gesynchroniseerd te houden. Een voorbeeld van een dergelijke database is CouchDB. Er is vraag naar een database met een lossere structuur die beter aansluit op de json structure (11). Er is een API geschreven, PouchDB, welke als laag voor indexeddb zit en de lokale database synchroniseert met een couchdb op de server (12) NADELEN VAN LOKALE DATABASES Er is echter ook commentaar op de lokale databases. De volgende punten zijn opgemerkt in een blog post op de Mozilla Hack Blog (13). Allereerst zou er niet kunnen worden opgemerkt of de database bijna vol of helemaal vol zit. Een simpele tool (14) laat zien dat het schrijven van de local Storage geblokkeerd wordt op het moment dat de storage vol zit. Tevens is die waarde voor iedere browser anders. Ten tweede kan een lokale database de pagina vertragen doordat de database synchroon wordt ingeladen. Als laatste is de lokale database afhankelijk van de lees- en schrijfsnelheden van de computer op de client. 2.2 SELECTORS API HTML5 heeft twee DOM selectie methoden, queryselector en queryselectorall (15). Een voorbeeld geschreven in javascript wordt dan bijvoorbeeld: document.queryselector(selectiecriteria); waarbij selectiecriteria de criteria zijn waarop geselecteerd moet worden. queryselector geeft het eerste DOM element terug dat een match heeft met de gegeven citeria. Daarentegen geeft queryselectorall een lijst met elementen terug die allemaal matchen met de gegeven criteria. De taal of grammatica waarin we de criteria specificeren is de gestandaardiseerde CSS selectors. Deze selectors zijn te vinden in de internationale standaard van W3C (16). jquery is een javascript framework dat in de praktijk veel gebruikt wordt. Het is zeer eenvoudig in gebruik en werkt in iedere browser. Het framework heeft een eigen selector functie welke na versie gebruikt maakt van de queryselectorall (17). 2.3 IFRAMES In willen we graag externe pagina s inladen. Use cases zijn bijvoorbeeld wanneer de bron van een artikel wordt opgevraagd of een artikel mogelijk niet goed opgehaald wordt. Ook links in een bericht van Twitter willen we graag in de applicatie laten zien. Iframes zijn daarvoor heel handig, echter niet altijd even veilig. Zo zou een externe site bij jouw DOM model kunnen komen, of zijn links in jouw venster openen. Er is een attribuut voor het iframe element dat de externe content binnen de iframe verschillende restricties oplegt om zo veilig embedden te kunnen garanderen. Dan ben je echter wel beperkt tot de browsers die het attribuut ondersteunen. Chrome ondersteunt het sandbox attribuut. (18) 7

50 Vooronderzoek 2. HTML5 2.4 BROWSERONDERSTEUNING De browserondersteuning van de besproken onderdelen binnen HTML5 en CSS3 zijn in tabel 1 naast elkaar gezet. In de kolommen staan 3 mogelijke browsers waar in ontwikkeld kan worden. In de rijen staan de verschillende modules die mogelijk gebruikt gaan worden. De vakken worden leeg gelaten wanneer de browser geen of een onduidelijke ondersteuning voor die module biedt. Wanneer de browser de module wel ondersteunt wordt de eerste versie ingevuld waarvoor de module ondersteund wordt. De data is afkomstig van caniuse.com. TABEL 1: BROWSERONDERSTEUNING VAN DE BESPROKEN MODULES Internet Explorer Mozilla Firefox Chrome Regions Multi-Column Transitions Transforms Animations Indexeddb QuerySelector Iframe Sandbox Een aantal eigenschappen vallen direct op. Internet explorer vereist versie 10.0 om alle besproken modules te kunnen gebruiken. Internet Explorer 10 is echter een developer preview. Deze browser is nog niet officieel gelanceerd. Mozilla Firefox ondersteunt niet alle modules, waaronder de CSS regions die erg belangrijk is voor de ontwikkeling van. Chrome ondersteunt alle modules voor versie De Chrome browser update automatisch, waardoor de meeste Chrome gebruikers al minstens op versie 17.0 zitten. Chrome lijkt de beste keus om in te ontwikkelen. 8

51 Vooronderzoek 3. Berichtextractie uit websites 3. BERICHTEXTRACTIE UIT WEBSITES In dit deel van het onderzoek wordt onderzocht of en hoe het mogelijk is om relevante, bruikbare informatie te extraheren uit bestaande nieuwswebsites. Er komen een aantal problemen naar voren; Vrijwel alle websites verschillen van elkaar, er is vooralsnog geen breed gebruikte standaard welke aangeeft hoe relevante informatie in een pagina geplaatst moet worden. Gevolg hiervan is dat het te gebruiken algoritme niet met 100% zekerheid zal werken. Echter is het voor wel van belang dat het optimale resultaat dicht benaderd wordt, zodat de juiste informatie op de meest functionele manier weergeven kan worden. Uiteindelijk zal het ook interessant zijn om te bekijken of het mogelijk is om, als de website niet geanalyseerd kan worden, dit aan de software door te geven zodat deze hier op kan reageren. 3.1 BESTAANDE PROGRAMMA S Er bestaan een aantal tools die relevante informatie uit websites halen. Hieronder zijn de meest relevante tools genoteerd en geanalyseerd READABILITY Readability is ontworpen om webpagina s in een format te representeren zodat de relevante tekst beter te lezen is. Readability is begonnen als een open source project; oude versies zijn te vinden en vrij te gebruiken. Echter is Readability recent closed-source geworden en is de source van de huidige versie niet beschikbaar. Readability geeft ontwerpers van applicaties en websites daarentegen wel de beschikbaarheid over een API waarmee de software te gebruiken is. GEBRUIKTE TECHNIEK De techniek achter Readability is in het verleden tussen versies grotendeels veranderd (19). Ook is de huidige source van Readability niet openbaar. Hierdoor kunnen we weinig tot niets zeggen over hoe deze software momenteel intern werkt. Over oudere versies is echter wel informatie te vinden; The basic logic of readability is to find all block level tags and count the length of text in them, not counting children. Then each parent node is awarded a fragment (half) of the weight of each of its children. This is used to find the largest block level tag that has the largest amount of plain text. From here, the content is further cleaned up. It's not bullet proof by any means, but it works well in the majority of cases. (20). BRUIKBAARHEID API VOOR STREAMPAPER De Readability API voorziet in alle benodigde functionaliteit om de relevante informatie uit webpagina s te verkrijgen. Om de API te gebruiken moet geregistreerd worden op de website, en moet een API-key aangevraagd worden. Volgens de website zelf zijn er vervolgens geen restricties voor gebruik; in de Terms of service staat echter meer. Dit heeft weinig tot geen invloed op het prototype van, maar zal wel van toepassing zijn op een commerciële versie. 9

52 Vooronderzoek 3. Berichtextractie uit websites De Terms of service : Limitations on Use You shall not: (i) take any action that imposes or may impose (as determined by Company in its sole discretion) an unreasonable or disproportionately large load on Readability's (or its third party providers') infrastructure; (ii) interfere or attempt to interfere with the proper working of the Readability Service or any activities conducted on the Readability Service; (iii) bypass any measures Readability may use to prevent or restrict access to the Readability Service (or other accounts, computer systems or networks connected to the Service); (iv) run Maillist, Listserv, any form of auto-responder or "spam" on the Service; or (v) use manual or automated software, devices, or other processes to "crawl" or "spider" any page of the Readability Service. You shall not (directly or indirectly): (i) decipher, decompile, disassemble, reverse engineer or otherwise attempt to derive any source code or underlying ideas or algorithms of any part of the Readability Service, except to the limited extent applicable laws specifically prohibit such restriction, (ii) modify, translate, or otherwise create derivative works of any part of the Readability Service, or (iii) copy, rent, lease, distribute, or otherwise transfer any of the rights that you receive hereunder. You shall abide by all applicable local, state, national and international laws and regulations. (21) BRUIKBAARHEID TECHNIEK VOOR STREAMPAPER De recente source code van Readability wordt niet vrijgegeven, deze is dus niet te gebruiken. Oude versies zijn wel beschikbaar, maar verschillen in gebruikte techniek en betrouwbaarheid. Mocht vanwege technische of financiële redenen besloten worden de software zelf te schrijven, dan kan gebruik gemaakt worden van eerdere versies van Readability BOILERPIPE Boilerpipe is een Java library, geschreven door Christian Kohlschütter. De software is vrijgegeven onder Apache License 2.0. Dit houdt in dat de software onder een aantal voorwaarden vrij gebruikt en aangepast mag worden. Boilerpipe komt voort uit een onderzoek van Kohlschütter waarin aan de hand van een groot aantal (nieuws) webpagina s onderzocht is hoe het relevante bericht uit de pagina te verkrijgen is. GEBRUIKTE TECHNIEK De basis van Boilerpipe berust voornamelijk op het tellen van woorden binnen de HTML DOM elementen. Kohlschütter heeft aan de hand van vele duizenden webpagina s onderzocht wat de beste technieken zijn, en wat de bijbehorende betrouwbaarheid is. Uiteindelijk is bevonden dat een HTML blok element met de relevante informatie gemiddeld tussen de 10 en de 17 woorden bevat. Om het algoritme betrouwbaarder te maken heeft de ontwerper van Boilerpipe extra regels toegevoegd, zoals de kans op relevante informatie is groter als in het blok ervoor of erna relevante informatie gevonden is. In de door Kohlschütter geschreven paper is alle informatie, inclusief resultaten, over dit onderzoek te vinden (22). BRUIKBAARHEID API VOOR STREAMPAPER De API van Boilerpipe voorziet in veel van de benodigde functionaliteiten, echter is er niet de mogelijkheid om ook plaatjes uit berichten te indexeren en door te geven. Gevolg hiervan is dat deze API voor gebruik bij met deze functionaliteit uitgebreid zou moeten worden. 10

53 Vooronderzoek 3. Berichtextractie uit websites Boilerpipe geeft geen duidelijke API restricties, maar legt deze wel op: Please note: Due to heavy use of this free service in the past, the number of requests per user is limited. The restriction can be removed by purchasing a commercial license for this Web API directly from Kohlschütter Search Intelligence for a modest fee. (23). Voor het prototype van zouden deze restricties waarschijnlijk niet van toepassing zijn, voor een commerciële versie is dit vrijwel zeker relevant, en zal een licentie aangeschaft moeten worden. BRUIKBAARHEID TECHNIEK VOOR STREAMPAPER De code is vrijgegeven onder Apache License 2.0 (23). Hierdoor is deze, als deze op eigen servers gedraaid zou worden zonder bijkomende kosten commercieel te gebruiken. Nadeel van Boilerpipe is dat deze in Java geschreven is. Hierdoor zou een interface tussen de Java applet en de PHP of Javascript software geschreven moeten worden. Een dergelijke interface is mogelijk, maar niet optimaal. Naast het directe gebruik van de Boilerpipe code is het ook mogelijk de code te herschrijven, of de techniek achter de code te gebruiken in eigen software. Dit zal echter technische uitdagingen en financiële gevolgen hebben voor de implementatie van deze techniek. 11

54 Vooronderzoek 4. Algemene uitleesbaarheid van RSS feeds en Google Reader 4. ALGEMENE UITLEESBAARHEID VAN RSS FEEDS EN GOOGLE READER In dit onderdeel van het onderzoek wordt onderzocht welke RSS standaarden er zijn, wat de hoofdonderdelen hiervan zijn, en of de meeste RSS feeds hier ook aan voldoen. Het is voor belangrijk dat zoveel mogelijk, zo niet alle geldige RSS feeds betrouwbaar uitgelezen kunnen worden. Ook wordt bekeken hoe Google Reader te integreren is in, of het überhaupt te gebruiken is en of de API voor gebruik bereikbaar is. Eerst wordt beschreven welke RSS versies er zijn, welke het meest gebruikt worden en hoe deze versies van elkaar verschillen. Ook zullen de mogelijke, bruikbare regels uit de RSS standaard beschreven worden. Als laatste wordt bekeken welke regels gebruikt worden bij een aantal verschillende feeds, of deze regels ook in de RSS standaard staan, en welke regels in het programma uitgelezen moeten kunnen worden. 4.1 RSS STANDAARDEN Er zijn twee verschillende aftakkingen van RSS, in het verleden is de RSS standaard 0.94 doorontwikkeld als RDS (heden ATOM genaamd) en RSS 2.0. RSS 2.0 is backward compatible. Dit betekent dat een RSS 0.92 feed ook aan de RSS 2.0 eisen voldoet. In grafiek 1 is duidelijk te zien dat RSS 2.0 ongeveer 85% van de feeds beslaat (24). Door dit grote percentage, en de backward compatibility, is het voor voornamelijk relevant om ons te richten op RSS 2.0. GRAFIEK 1: PERCENTAGE PER RSS VERSIE, OVER MEER DAN FEEDS 4.2 ELEMENTEN BINNEN RSS 2.0 Ieder bericht binnen een RSS feed bevindt zich binnen de <item></item> tags. Hieronder worden de door de RSS 2.0 specificatie gegeven toegestane elementen van een bericht uiteengezet. Het is mogelijk om de RSS specificatie uit te breiden (25). 12

55 Vooronderzoek 4. Algemene uitleesbaarheid van RSS feeds en Google Reader TABEL 2: ELEMENTEN BINNEN RSS 2.0 SPECIFICATIE Element Omschrijving title De titel van het item. link De URL van het item. description Korte inhoud van dit item. author adres van de auteur. category Categorieën waaraan dit bericht toebehoort. Meerdere category elementen toegestaan. comments URL naar comments pagina van dit item. enclosure Aan dit bericht verbonden media object. Format: http url, length in bytes, MIME type. guid Globally unique identifier. Format: geen syntax gespecificeerd. pubdate Datum van publicatie. Format: Sun, 19 May :21:36 GMT. source Naam van RSS feed waarin dit bericht staat Eigenschap: URL naar de XML 4.3 ANALYSE EXTERNE RSS FEEDS Hieronder wordt de structuur van een aantal RSS feeds uiteengezet. Er is te zien dat iedere feed een aantal dezelfde regels heeft: title, description, guid, pubdate en link. Hiernaast wordt gebruik gemaakt van andere regels, welke ook weer op verschillende manieren gebruikt worden, bijvoorbeeld; category. Ook wordt bij guid soms, maar niet altijd aangegeven of deze permanent is of niet. Verder verschilt het gebruik van regels. Bij een feed wordt description gebruikt als korte samenvatting van het stuk tekst dat in de regel content geplaatst is. TABEL 3: GEBRUIK ELEMENTEN BIJ EXTERNE FEEDS Tweakers.net CNN Engadget NU.nl Interfacelift title x x x x x link x x x x x description x x x x x author x x category x x meerdere x comments x x guid x x x x x pubdate x x x x x enclosure x related x copyrightphoto x dc:creator x feedburner x 13

56 Vooronderzoek 4. Algemene uitleesbaarheid van RSS feeds en Google Reader 4.4 GOOGLE READER zou, naast het inlezen van losse RSS feeds, gebruik kunnen maken van de door Google Reader aangeboden functionaliteiten. De gebruiker kan in dat geval in Google Reader aangeven welke feeds hij of zij wil zien, en welke prioriteiten deze feeds hebben. Het voordeel voor de gebruiker is dat Google Reader de feeds consequent in hetzelfde format plaatst en de feed indexeert en voor lange tijd opslaat WAT KAN GOOGLE READER BIEDEN? Google Reader biedt de gebruiker een visuele interface waarin externe feeds geladen kunnen worden. Zodra de gebruiker een feed invoert, haalt Google deze, als deze al geïndexeerd is, uit haar database, en zet de informatie geordend op het scherm. Voordeel van het uitlezen van Google Reader binnen zal zijn dat de feeds door Google opgeslagen zijn, en dus verder de geschiedenis in gaan. Ook is een voordeel dat de feeds door Google gestructureerd worden, en allemaal de zelfde structuur krijgen. Hierdoor wordt het uitlezen en verwerken eenvoudiger BRUIKBAARHEID GOOGLE READER VOOR STREAMPAPER Google Reader heeft vooralsnog geen API. Hierdoor wordt het bemoeilijkt om gebruik te maken van de functionaliteiten welke door Google Reader geboden worden. Het is echter wel mogelijk om de functionaliteiten van Google Reader via externe tools zoals pyrfeed (26) te gebruiken. Ook is het mogelijk om na authenticatie van de betreffende gebruiker de output van Google Reader als Atom feed op te vragen. Het is dus zeker mogelijk om de feed van Google Reader in te verwerken. Om dit vloeiend te laten gebeuren moet hier echter wel enig werk in verzet worden. Omdat Google de Atom feed van zijn Reader zelf samenstelt is de structuur altijd gelijk. Om dit uit te lezen kan dus een vast algoritme gebruikt worden. Vanwege de afwezigheid van een API is het niet mogelijk om vanuit feeds toe te voegen aan Google Reader, totdat een API beschikbaar is zullen alle aanpassingen binnen de site van Google zelf moeten gebeuren. Het laatste nadeel van het gebrek aan een API is de betrouwbaarheid van het uitlezen van een Google Reader feed. De mogelijkheid bestaat dat Google beslist om de structuur van de feed aan te passen. Hierdoor zullen de onofficiële API s, of de algoritmes op dat moment mogelijk niet meer werken. Dit laatste kan in de toekomst een kostenpost voor extra ontwikkeling veroorzaken. 14

57 Vooronderzoek 4. Algemene uitleesbaarheid van RSS feeds en Google Reader STRUCTUUR GOOGLE READER FEED De berichten binnen de Google Reader Atom feed hebben allen dezelfde structuur. Doordat de structuur overal gelijk is hoeft voor het analyseren van de Google Reader feed slechts een aantal regels geïmplementeerd te worden. Hieronder zijn de elementen uit een voorbeeld bericht uit de feed gegeven: <entry gr:crawl-timestamp-msec=" "> <id gr:original-id=" "></id> <category term="" scheme="" label="read"/> <category term="" scheme="" label="reading-list"/> <category term="" scheme="" label="fresh"/> <title type="html"></title> <published></published> <updated></updated> <link rel="alternate" href=" " type="text/html"/> <content xml:base="" type="html"></content> <author> <name></name> </author> <source gr:stream-id=" "> <id></id> <title type="html"></title> <link rel="alternate" href="" type="text/html"/> </source> </entry> 15

58 Vooronderzoek 5. User interface 5. USER INTERFACE In worden berichten uit verschillende bronnen visueel en informatief weergegeven in een overzicht. Bij het realiseren van een overzicht zal een keuze moeten worden gemaakt met betrekking tot hoe en waar de informatie wordt weergegeven. Gegeven is de inhoudelijke prioritering door Moxio. Vervolgens moet dit visualiseren. Bij het maken van de user interface moet rekening worden gehouden met verschillende kenmerken van de input van de informatie: berichten zijn verschillend van lengte, bevatten soms foto s of zelfs filmpjes. Dus de input bestaat uit verschillende datastructuren. De relevantie van de berichten moet tot uitdrukking komen in de wijze waarop ze worden weergegeven, dus in de lay-out. Daarbij moet er een balans worden gevonden tussen te veel en te weinig weergegeven data. De relevantie en balans moeten voorkomen dat de output van uitsluitend een opsomming van artikelen is. Tenslotte dient om te kunnen gaan met veranderende schermgroottes en draaiing van het scherm. De volgende aspecten van de informatie worden in dit rapport geanalyseerd: Datastructuren o Tekst o Foto s o Video s Randvoorwaarden bij verwerking van de artikelen o Relevantie o Hoeveelheid Technische uitdaging m.b.t. weergave op het scherm o Vergroten of verkleinen o Tablet (landscape en portrait) 5.1 DEFINITIE INPUT Het indelen van het scherm vereist enkele aannames over de beschikbare informatie van de artikelen. Op basis van deze informatie kunnen per artikel verschillende beslissingen genomen worden over de manier van weergeven. De veronderstelde beschikbare informatie is zo generiek mogelijk gekozen en bestaat uit de volgende elementen: Gegeven data: Prioriteiten Inhoud artikel o Tekst o Foto s o Video s 16

59 Vooronderzoek 5. User interface 5.2 TEMPLATES Tijdens de totstandkoming van de onderzoeksopzet is in eerste instantie onderzocht of het gebruik van templates voor de presentatie op het scherm van onbewerkte berichten zou kunnen bijdragen aan het realiseren van een gestandaardiseerde lay-out. De gedachten daarover waren als volgt: Met behulp van tevoren gedefinieerde templates kan in de keuze voor de lay-out van een combinatie van berichten op het scherm worden gestandaardiseerd. Bijvoorbeeld: bij veel plaatjes wordt er gekozen voor template 1, bij veel lange tekst template 2, enz. Omdat deze lay-outs een vaste vorm hebben, staat de presentatie van het bericht op het scherm daarmee ook vast. Daartoe worden constanten gedefinieerd die voor alle templates gelden, alsmede een aantal specifieke template afhankelijke constanten. Verder wordt rekening gehouden met verschillende invoervariabelen. Algemene constanten: Tekststijl Tekstgrootte Letterafstand Regelafstand Lettertype Constanten per template: Lay-out Afhankelijkheden invoer Kolombreedte Plaatjesgrootte Invoervariabelen: Relevantie Hoeveelheid Inhoud Plaatje (grootte, vorm, aantal) Video Door verschillende gedefinieerde invoervariabelen te gebruiken zou ervoor kunnen worden gezorgd dat bij elke soort invoer de lay-out er goed uit ziet. Met behulp van een nader te bepalen set regels, zou aan de hand van deze variabelen de optimale lay-out kunnen bepalen. Bovengenoemde opzet heeft echter belangrijke beperkingen. Bij het gebruik van templates, zoals hierboven is voorgesteld, is het noodzakelijk voor alle mogelijke combinaties van berichten aparte templates te schrijven. Dit aangezien de combinatie van berichten bepalend is voor de schermweergave. Het aantal templates wordt hierdoor onvoorspelbaar groot, een oneindig aantal combinaties is denkbaar. Dit inzicht heeft ertoe geleid dat er een andere oplossing is gevonden: Artikeltemplates. 17

60 Vooronderzoek 5. User interface 5.3 ARTIKELTEMPLATES Bij de Artikeltemplates worden de artikelen eerst tot standaard formaten bewerkt volgens van te voren bepaalde standaarden, de in het vervolg genoemde artikeltemplates. Dit gebeurt door een extra stap toe te voegen in het verwerkingsproces van de berichten. Vervolgens kunnen de geformatteerde artikelen wel op gestructureerde en van te voren bepaalde wijze op het scherm worden weergegeven. Op deze manier kunnen alle toegestane mogelijkheden op een systematische wijze worden afgehandeld. Deze nu voorgestelde standaardisatie komt het gehele proces ten goede. Voor het gebruik van artikeltemplates moet er vooraf ruimte gedefinieerd en vormgegeven worden. Dit wordt gedaan door middel van een schermopdeling in een raster. Dit raster kan vervolgens worden opgevuld met verschillende artikelen. Deze artikelen hebben een standaard opmaak waarvan de grootte en de indeling vast staat. Omdat niet bekend is welke informatie van de artikelen gaat worden gebruikt tijdens het maken van de lay-out, zal voor ieder artikel worden bepaald welke opmaken mogelijk zijn. Met deze informatie kan het scherm aan de hand van de templates gevuld worden. Eerst zal bestaand onderzoek worden besproken, dat wordt gebruikt om de keuzes te onderbouwen die in het verdere proces worden gemaakt. Daarna zal er onder het kopje schermanalyse een toelichting worden gegeven over hoe het scherm wordt ingedeeld en wat dit betekent voor de lay-out. Vervolgens zal de opbouw van de artikelen met behulp van dit raster worden besproken. Tot slot zullen verschillende templates voor het opbouwen van schermen worden gepresenteerd BESTAAND ONDERZOEK In de ontwikkeling van wordt rekening gehouden met de resultaten van de volgende onderzoeken: Uit onderzoek door Holmberg (27) is de volgende ranking bepaald tussen verschillende design keuzes. Een hogere ranking betekent dat het meer de aandacht trekt: 1. Pictures 2. Large headline 3. Articles 4. Short paragraphs 5. Drop quotes 6. Information graphics 7. Advertisements Verder is uit dit onderzoek gebleken dat plaatjes een positief effect hebben op het opbouwen van informatie door de hersenen. Daarom is er een voorkeur voor het gebruik van plaatjes bij het opbouwen van de verschillende lay-outs. Uit onderzoek gepubliceerd op useit.com (28), waarin wordt beschreven hoe internetgebruikers websites bekijken, blijkt het volgende: internetgebruikers bekijken websites via het F-patroon. De heat map hieronder geeft aan hoe het F-patroon er op verschillende sites uit ziet. 18

61 Vooronderzoek 5. User interface FIGUUR 2: HEAT MAPS AFKOMSTIG VAN USEIT.COM De rode delen zijn de plekken waar het langst naar is gekeken. Door belangrijke informatie op deze plekken neer te zetten zorgt men ervoor dat deze informatie beter wordt gelezen en beter wordt opgenomen. Omdat wil bereiken dat gebruikers optimaal kennis nemen van de meest relevante informatie, worden keuzes bij de ontwikkeling van de verschillende lay-outs gebaseerd op het F-patroon. Holmqvist (29) heeft ontdekt dat lezers een zigzagpatroon volgen bij het lezen van krantenpagina s. Bij dit zigzagpatroon wordt het meest naar het midden van het scherm gekeken. Wanneer dit patroon wordt gebruikt zal dit resulteren in andere lay-outs dan bij gebruik van het F-patroon. FIGUUR 3: ZIGZAGPATROON VAN HOLMQVIST SCHERMANALYSE Ieder artikel dat wordt weergegeven door zal andere informatie bevatten; hierdoor is de grootte van ieder artikel anders. Om dit in enigszins vaste structuur aan te bieden zullen er artikeltemplates gemaakt worden. Maar voor dit kan worden gedaan, zal er moeten worden uitgewerkt hoe het scherm kan worden ingedeeld teneinde artikeltemplates te kunnen gebruiken. Door het scherm onder te verdelen in een aantal kolommen en daar vervolgens rijen in te maken ontstaat er een raster waarin artikelen kunnen worden geplaatst. Deze artikelen kunnen één of meerdere vlakken van het raster innemen. De kolombreedte is gebaseerd op de kolombreedte van een aangenaam artikel. Dat is de optimale breedte voor het opnemen van informatie. Omdat het scherm niet altijd mooi in kolommen op te delen is zal de kolombreedte worden aangepast aan de schermresolutie. Dit zal worden gedaan door de volgende formule: 19

62 Vooronderzoek 5. User interface Waarin Alles wordt gespecificeerd in pixels. De is het zichtbare deel van de browser. De kan door ons worden vastgesteld. Hierdoor kunnen wij de breedte van de kolommen beïnvloeden. Ons eerste voorstel hiervoor is 280 pixels. Dit is ongeveer de optimale kolombreedte. Deze kan eventueel simpel worden aangepast als dit toch niet prettig blijkt te zijn. Door de zelf te bepalen wordt de breedte van de kolommen (en daarmee het aantal) door ons bepaald, maar goed afgezet op het scherm, zodat de hele breedte wordt benut. Het scherm is nu ingedeeld in kolommen met een breedte van pixels. Een voorbeeld hiervan staat hieronder: De rijhoogte kan vervolgens op verschillende manieren bepaald worden. In eerste instantie gaan wij uit van de formule: Voor deze verhouding is gekozen zodat het scherm opgedeeld wordt in vierkanten. Dit concept is makkelijker in te delen in templates. De rijhoogte kan afhankelijk worden gemaakt van de artikelen maar voor het gebruik van artikeltemplates is dit niet wenselijk. We willen immers vaste groottes definiëren voor de artikelen. Hierdoor komt het voorbeeldscherm er als volgt uit te zien: We kunnen nu voor de meest gangbare schermresoluties bepalen hoe het raster er uit gaat zien, zodoende kunnen we bepalen wat voor templates we gaan krijgen. 20

63 Vooronderzoek 5. User interface De meest gangbare schermresoluties begin 2012 zijn volgens Wikipedia (30) & Statcounter (31): Resolutie Aantal kolommen (uitgaande van 280 pixels standaard) 1024x x x x x x x Aantal rijen De meest gangbare verhouding is de 16:9 breedbeeld, wat betekent dat de rasters tot 4 rijen en 7 kolommen moeten worden uitgewerkt. Op deze manier wordt het probleem schermgrootte opgelost omdat alle schermen binnen deze rasters vallen. Hierbij moet wel worden vermeld dat volledig dynamisch is, en dus alle schermresoluties zal ondersteunen. De genoemde resoluties zullen echter wel bruikbaar zijn als basis om verder te redeneren en om de beginselen op te baseren. Bij het testen van is het aan te raden om deze resoluties te testen OPBOUW ARTIKELTEMPLATES Nu het scherm is beschreven, zal een raster verder worden onderverdeeld met mogelijke artikeltemplates. Het formaat van het te verdelen raster is 3x3 omdat artikelen niet te groot mogen worden. Als eerste een opsomming van de formaten die in theorie mogelijk zijn binnen dit 3x3 raster: 1x1 1x2 1x3 2x1 2x2 2x3* 3x1 3x2* 3x3* *De artikeltemplates voor deze rasters zijn in eerste instantie niet meegenomen bij de constructie van de schermtemplates. Deze artikeltemplates zullen in een later stadium alsnog kunnen worden meegenomen. Het 1x1 raster kan twee invullingen krijgen, een stuk tekst of een foto. Dit zijn dan twee verschillende artikeltemplates. Foto s in landscape kunnen in portret worden gezet (besproken in bijzondere gevallen) of kunnen in 2x1 rasters worden gezet. In plaats van foto s kan ook een filmpje worden geplaatst; dit kan vervolgens in een eigen interne mediaplayer worden afgespeeld. In bijlage 1 staat een schematische weergave van de mogelijke inhoud van de rasters. De volgorde waarin ze staan onder elk raster is de prioriteit waarmee de weergave wordt gekozen. Het eerst genoemde voorstel heeft een hogere prioriteit. Omdat foto s de aandacht trekken, 21

64 Vooronderzoek 5. User interface heeft het de voorkeur om artikelen met foto s te plaatsen. Door een willekeurig element toe te voegen kan de positionering van foto s en tekst binnen een template variabel worden gemaakt. Bij elk van de weergaves kunnen dus foto en tekstblokken worden gewisseld. Hierdoor staat in de artikeltemplate niet vast hoe het artikel wordt weergegeven, enkel welke informatie wordt weergegeven. Voor een artikel kan nu worden gekeken in welke vormen dit artikel kan worden weergegeven. De hoeveelheid informatie in een artikel bepaalt welke templates er mogelijk zijn. Het scherm kan nu worden gevuld aan de hand van deze templates OPBOUW SCHERMTEMPLATES Het te kiezen raster is afhankelijk van het formaat van het scherm en de schermresolutie. Voor de invulling van het raster moet uit een aantal mogelijkheden worden gekozen, waarbij de gebruikerservaring centraal staat. Voor iedere gekozen mogelijkheid moet een template bestaan. Deze templates worden in het vervolg schermtemplates genoemd. Voor de invulling van een raster kunnen kleine rasters worden gecombineerd tot grotere rasters. Hierdoor wordt een modulaire opbouw van het scherm mogelijk. Bij het opbouwen van de rasters zal rekening worden gehouden met de vooronderzoeken. Dus zal er een F-patroon worden gebruikt bij het plaatsen van artikelen. Artikelen met een hoge prioriteit komen links bovenin te staan en met een lage prioriteit rechts onderin. Om het raster op te bouwen kan bijvoorbeeld een greedy algoritme worden gebruikt, dat de prioriteit van de geplaatste artikelen maximaliseert. Dit algoritme werkt door telkens het artikel te kiezen met de hoogste prioriteit, dat ook in de juiste vorm kan worden gegoten. Bijlage 2 bevat een visualisatie van alle besproken rasters, in de volgorde waarin deze hieronder worden besproken. Deze rasters worden opgebouwd van klein naar groot. Bij elk raster wordt gestreefd naar een balans tussen details en overzicht, zodanig dat het visueel aantrekkelijk blijft. Het plaatsen van informatie volgens het F-patroon is hierbij leidend principe. KLEINE RASTERS (1X1, 2X1 & 1X2) Het eerste raster is een 1x1 raster, hierin kan slechts een enkel artikel worden geplaatst. Hierin bestaat dus geen keuze. Een 1x1 raster wordt vergroot door er een rij of een kolom aan toe te voegen. Zo ontstaan 2x1 of 1x2 rasters. Hierin bestaan wel meerdere opties voor de invulling van deze rasters. Omdat de lay-out van alle configuraties aan de vereisten voldoet, zal een keuze dienen te worden gemaakt door het algoritme. Mogelijke schermtemplates voor het 1x2 raster zijn: 1x2 raster1: 1x2A één 2kolomsartikel 1x2 raster2: 1x1A, 1x1A twee 1koloms artikelen 22

65 Vooronderzoek 5. User interface MIDDELGROTE RASTERS (2X2, 2X3 & 3X2) Wanneer aan een 1x1 raster zowel een rij als een kolom wordt toegevoegd, dan ontstaat er een 2x2 raster. Hierdoor ontstaan keuzemogelijkheden om de berichten te plaatsen. Niet alle mogelijkheden geven echter een goede lay-out volgens de principes van het F patroon. Volgens het F-patroon, dienen de artikelen bij voorkeur onder elkaar te worden geplaatst, en liever niet naast elkaar. Vanuit deze principes bestaat er een voorkeur voor 3 hieronder omschreven rasters. Hierin worden wel de 1x2 rijen gebruikt om het raster te vullen en niet de 2x1 kolommen. Daarnaast wordt de mogelijkheid opengelaten dat er onder een breed artikel nog 2 losse artikelen komen te staan. De drie mogelijke schermtemplates van het 2x2 raster zijn: 2x2 raster1: 2x2A 2x2 raster2: 1x2A, 1x2A één groot 2x2 artikel een 2koloms artikel op de eerste rij, een 2koloms artikel op de tweede rij 2x2 raster3: 1x2A, 1x1A, 1x1A een 2koloms artikel op de eerste rij, twee 1koloms artikelen op de tweede rij In plaats van een verdeling van het raster in (alle mogelijke combinaties van) artikelen kan het raster ook verdeeld worden in sub-rasters, of in een combinatie van artikelen en sub-rasters. Na het plaatsen van bijvoorbeeld het eerste artikel kan de resterende schermruimte worden benoemd als sub-raster. De mogelijke indelingen van dit kleinere sub-raster zijn dan al eerder beschreven. De rasters worden op deze manier recursief onderverdeeld. Dit heeft als voordeel dat er veel minder indelingen beschreven hoeven te worden. Hiermee kunnen bovenstaande drie schermtemplates gereduceerd worden tot twee: 2x2 raster1: 2x2A 2x2 raster4: 1x2A, 1x2R 1 groot 2x2 artikel een 2koloms artikel op de eerste rij, een 2koloms raster op de tweede rij Bij de overstap naar het 3x2 raster en het 2x3 raster is besloten om een 2x2 artikel te plaatsen op de belangrijkste plek. Hierdoor komt er een groot en belangrijk artikel op de plek waar het meest gekeken wordt. Daarnaast of daaronder staat een 2x1 of 1x2 raster waarbij het algoritme weer bepaalt wat er komt te staan. Dit zijn beide minder belangrijke artikelen en deze staan dus verder van het F patroon af. Een 2x2 artikel heeft de voorkeur boven een 2x2 raster (dat meerdere kleine artikelen kan bevatten), omdat er dan niet te veel verschillende informatie wordt weergegeven op een klein scherm. MIDDELGROTE RASTERS (3X1, 1X3 & 3X3) Voordat het 3x3 raster wordt ingevuld zullen eerst de 3x1 en 1x3 rasters worden gevuld. Om het F patroon te handhaven staat boven (of links) het belangrijkste artikel. Dit artikel kan 1, 2 of 3 vakken binnen het raster innemen. Door vervolgens aan te vullen met artikelen die maximaal even groot zijn als het eerste artikel staat op de belangrijkste plek het belangrijkste artikel en is dit artikel het grootst binnen dit raster. Net als bij het 2x3 en het 3x2 raster wordt links bovenin een 2x2 artikel geplaatst. Vervolgens worden de overige vakken opgevuld met twee rasters. Welke combinatie van rasters hiervoor 23

66 Vooronderzoek 5. User interface worden gebruikt maakt niet uit. Beide mogelijkheden (zoals gepresenteerd in bijlage 2) houden op een correcte wijze rekening met het F-patroon. Omdat de inhoud van de rasters hetzelfde is kan het gebeuren dat een greedy algoritme hier geen keuze in kan maken. In zo n geval zal een willekeurig element kunnen worden toegevoegd om de keuze te forceren. GROTE RASTERS (4X2, 4X1, 1X4 & 4X3) Voor het 4x2 raster zijn ook weer meerdere mogelijke invullingen. Er is hierbij gekozen om een 2x2 artikel te plaatsen zoals bij het 3x2 raster. Door onder dit artikel een raster te zetten, is er onderin het raster ruimte voor een afweging tussen het tonen van 1 of meerdere artikelen. Deze afweging zal weer door het algoritme kunnen worden gemaakt. De 4x1 en 1x4 rasters worden geconstrueerd volgens dezelfde principes als de 3x1 en 1x3 rasters. Een visuele representatie van deze rasters is te vinden in bijlage 2. Naast het 4x2 raster zal er ook een 4x3 raster moeten worden gemaakt, ook hier zijn veel verschillende mogelijkheden. Door links een 4x2 raster te plaatsen staat de belangrijkste informatie weer op de juiste plek. Aan de rechter kant wordt vervolgens in het 4x1 raster ruimte gelaten voor de minst belangrijke artikelen. GROTE RASTERS (4X4) Tot nu toe is de keuze voor bepaalde lay-outs redelijk vanzelfsprekend geweest. De voorgestelde schermtemplates worden ondersteund door de theorie van het F-patroon. Voor 4x4 rasters en grotere rasters biedt de theorie van het F-patroon ontoereikende sturing bij beslissingen ten aanzien van het maken van de schermtemplates. Waar de breedte groter wordt dan drie kolommen, zouden er twee F-patronen naast elkaar kunnen worden geplaatst. Lezers gaan dan over op andere leesstrategieën. Hierdoor lijkt de theorie van het F patroon niet meer van toepassing. De resultaten van het onderzoek door Holmqvist (29) bieden wellicht een betere oplossing voor rasters met veel kolommen. Er is voor deze schermtemplates daarom slechts een voorlopige eerste intuïtieve opzet gemaakt. Nadere studie en overleg met de expert bij Moxio moet nog plaatsvinden. Een mogelijke vervolgstudie worden gedaan door de verschillende schermtemplates te implementeren. Vervolgens kunnen de schermtemplates met elkaar worden vergeleken op nog nader te formuleren criteria. Als modulair wordt opgebouwd kan dit relatief makkelijk worden gedaan. Hieronder staan de redenaties, problemen en overwegingen die aan de orde zijn geweest bij de constructie van schermtemplates van 4x4 rasters en groter. Voor de eerste schermtemplate van het 4x4 raster is gekozen om de vier kolommen twee aan twee te gebruiken. Hierdoor staan grote (belangrijke) artikelen boven en kleine (minder belangrijke) artikelen onder in de schermtemplate. Zodoende wordt het F-patroon gehandhaafd. In de tweede schermtemplate wordt niet langer uitgegaan van het F-Patroon zoals voorheen werd gedaan. Bij de constructie van deze schermtemplate is uitgegaan van het zigzagpatroon. Door belangrijke grote artikelen in het midden te plaatsen staan deze op de meest bekeken plek van het zigzagpatroon. 24

67 Vooronderzoek 5. User interface GROTE RASTERS (4X5) De eerste optie voor de 4x5 schermtemplate voegt aan de rechter zijde een kolom toe aan het 4x4 raster. Als het 4x4 raster het F-patroon volgt dan wordt er aan de minst bekeken kant artikelen toegevoegd die een lagere prioriteit hebben dan de artikelen in het 4x4 raster. Als er echter voor wordt gekozen om het zigzagpatroon te gebruiken bij het 4x4 raster dan staat het belangrijkste artikel niet langer in het midden. De tweede schermtemplate heeft in het midden een lege kolom, die een opdeling in twee pagina s kan weergeven. Hierbij kan zowel links als rechts het F-patroon worden gebruikt. Het voordeel hiervan is dat er geen overdaad aan informatie op het scherm komt en dat de informatie gescheiden is in twee afzonderlijke delen. GROTE RASTERS (4X6) Bij het 4x6 raster worden voor de eerste twee schermtemplates dezelfde redenaties gehanteerd als bij het vullen van het 4x5 raster. De eerste schermtemplate heeft 3 F-patronen naast elkaar. De tweede heeft een zigzagpatroon met berichten met hoge prioriteit in het midden, hier staan echter wel zeer veel berichten naast. Daarom vult de derde schermtemplate niet meer dan 4 kolommen. Dit kan betekenen dat er hier weer twee pagina's van worden gemaakt zoals bij het 4x5 raster. Of dat er 4 kolommen gecentreerd worden waarbij de twee zijkanten leeg zijn. GROTE RASTERS (4X7) Voor het 4x7 raster zijn er weer dezelfde opties. Bij het eerste schermtemplate wordt aan de rechter zijde een kolom toegevoegd om zo het F-patroon te behouden. Voor de tweede schermtemplate is gekozen om hem niet breder te maken dan 4 kolommen. Bij de derde schermtemplate wordt deze niet breder gemaakt dan 6 kolommen. Bij zowel de tweede als de derde schermtemplate zou er een paginascheiding kunnen worden toegevoegd BIJZONDERE GEVALLEN Er zijn natuurlijk nog wat bijzondere gevallen, bijvoorbeeld meerdere foto s, filmpjes en te kleine foto s. Deze worden hieronder één voor één besproken. VERSCHILLENDE GROOTTES VAN FOTO S Bij te kleine foto s kan worden besloten deze niet weer te geven, dan heeft het artikel dus geen optie met foto. Grote foto s kunnen worden verkleind, als deze niet helemaal in het vak passen. Dan kan er een stuk leeg worden gelaten om de foto heen of een stuk van de foto af worden gesneden (scale en crop). Door op een foto te klikken wordt deze in zijn werkelijke formaat weergegeven. MEERDERE FOTO S BIJ 1 ARTIKEL Enkele foto s kunnen worden weergegeven in het vak waar de foto normaal komt. Door op de foto s te klikken, kunnen ze vervolgens allemaal stuk voor stuk worden bekeken. FILMPJES Filmpjes kunnen op de plek van een foto worden geplaatst. Door op deze filmpjes in te klikken kunnen ze worden afgespeeld in een eigen interne mediaplayer. 25

68 Vooronderzoek 5. User interface AANTALLEN VAN BESCHIKBARE BERICHTEN Als er te weinig berichten zijn om de pagina te vullen dan kan deze worden gevuld voor zover dat kan, de rest blijft dan leeg. Bij te veel berichten kunnen er meerdere pagina s worden gegenereerd. Op deze manier wordt dan een grote krant gegenereerd. HET KANTELEN VAN HET SCHERM Het aanpassen van de kanteling is een OS functie, hierdoor verschilt dit niet van het aanpassen van grootte van de browser. Dit kan worden opgevangen door de krant opnieuw op te bouwen voor de nieuwe waarden. 26

69 Vooronderzoek Conclusie CONCLUSIE Van CSS3 is nog niet veel geïmplementeerd en het deel dat is geïmplementeerd is helaas incompleet of nog niet ondersteund. Chrome 17 en hoger heeft met de prefix -webkit- de CSS regions opgenomen. Ook de andere modules zijn voor in deze versie van Chrome te gebruiken. Door de brede ondersteuning van de onderzochte modules wordt Chrome 17 aangeraden als primaire browser voor. De regions module is deels geïmplementeerd en is erg handig voor de kolommenstructuur van. In eenvoudige situaties kunnen we gebruik maken van de multi-column eigenschappen. Transities kunnen het beste gebruikt worden voor simpele animaties als een hover of focus. Animaties kunnen worden gebruikt om foto s in elkaar over te laten gaan of te bewegen. Animaties hebben een toegevoegde waarde voor de gebruikerservaring bij het navigeren door de applicatie. Een groot onderdeel van HTML5 is de mogelijkheid om offline applicaties te maken. Er bestaan goede mogelijkheden om offline een database te onderhouden waarin alle artikelen voor streams worden opgeslagen. IndexedDB is een goede API om die offline database te realiseren. Om offline beschikbaar te maken moet er een data laag komen waar de applicatie tegen praat. Voor de applicatie maakt het dan niet uit of er wel of geen internetconnectie is. Een sandbox attribuut is toegevoegd aan het iframe element. Dit attribuut zorgt er voor dat de pagina welke wordt geladen in de iframe zich aan verschillende veiligheidsrestricties moet houden. Van de twee onderzochte softwarepakketten is vanwege professionaliteit en bruikbaarheid aan te raden de API van Readability te gebruiken bij het prototype van. Mochten de limieten van de Readability API bereikt worden bij een eventuele toekomstige commerciële versie van, dan kunnen de ontwikkelaars er voor kiezen Readability commercieel te benaderen of een dergelijk softwarepakket te ontwikkelen. Aan de hand van de meest gebruikte RSS standaarden en de analyse van vijf onafhankelijke websites, is te concluderen dat de ondersteuning van RSS 2.0 en de bijbehorende voorgedefinieerde elementen voldoende zou moeten zijn om het gros van de feeds te ondersteunen. Er zijn in deze vijf feeds slechts drie elementen gevonden welke niet tot de RSS standaard behoren, namelijk dc:creator, copyrightphoto en feedburner. Deze drie elementen zijn voor niet van essentieel belang, omdat zij van toepassing zijn op informatie buiten wat zal gaan visualiseren. Google Reader is te implementeren door de gebruiker (mogelijk via ) op Google in te laten loggen, en vervolgens de Atom feed in te lezen. Hierna kunnen alle door Google Reader ondersteunde feeds uitgelezen en in de stream van verwerkt worden. Een belangrijk voordeel van Google Reader is dat deze, binnen de feeds, meer berichten uit het verleden kent. 27

70 Vooronderzoek Conclusie Bij het onderzoek naar mogelijke oplossingen voor de user interface van is een ontwerp tot stand gekomen aan de hand waarvan de user interface kan worden opgebouwd. Door het scherm in te delen in een raster worden blokken gecreëerd van een standaardgrootte. Omdat de grootte van dit raster afhangt van de resolutie is er voor elk raster minstens één schermtemplate ontworpen. Deze schermtemplates kunnen worden gevuld met artikelen of met kleinere rasters. Door artikeltemplates te maken op basis van dezelfde blokken kunnen de artikelen eenvoudig met behulp van de schermtemplates op het scherm worden getoond. Tijdens dit onderzoek is er een opzet gegeven voor de verschillende schermtemplates. Deze zullen echter moeten worden doorontwikkeld tijdens het maken van het product. Hierbij wordt de hulp van Moxio ingeschakeld om de juiste schermtemplates te maken. Door de modulaire opbouw van de verschillende templates zijn deze eenvoudig te testen. De schermtemplates kunnen met elkaar worden vergeleken op basis van nog nader te formuleren criteria. 28

71 Vooronderzoek Bibliografie BIBLIOGRAFIE [1] 1. CSS Regions: One Year In. Web Platform Team Blog. [Online] Adobe, 2012 maart 16. [Citaat van: 2 april 2012.] [2] 2. Smith, Andi. CSS Regions. [Online] 13 maart [Citaat van: 9 april 2012.] [3] 3. Rich page layout with HTML and CSS3. [Online] [Citaat van: 9 april 2012.] [4] 4. Multi-column text using CSS3. Red Team Design. [Online] [Citaat van: 11 april 2012.] [5] 5. Vasile, Christian. New CSS3 Properties For Better Text And Word Wrapping. 1st webdesigner. [Online] 8 maart [Citaat van: 11 april 2012.] [6] 6. The Expressive Web. [Online] Adobe, [Citaat van: 2 april 2012.] [7] 7. Mahemoff, Michael. Client-side storage. HTML5 Rocks. [Online] 1 oktober [Citaat van: 2 april 2012.] [8] 8. Pilgrim, Mark. The past, present & future of local storage for web applications. Dive into HTML5. [Online] [Citaat van: 2 april 2012.] [9] 9. Beyond named key-value pairs: Competing visions. [Online] [Citaat van: 2 april 2012.] [10] 10. Kinlan, Paul. A simple todo list using html5 indexeddb. HTML5ROCKS Tutorials. [Online] 15 mei [Citaat van: 9 april 2012.] [11] 11. Blommestein, Michiel van. CouchDB performt als een gek! Webwereld. [Online] 21 october [Citaat van: 9 april 2012.] [12] 12. Rogers, Mikeal. PouchDB is a pocket-sized database. Github. [Online] [Citaat van: 9 april 2012.] [13] 13. Heilmann, Chris. There is no simple solution for local storage. Mozilla hacks. [Online] 5 maart [Citaat van: 7 april 2012.] [14] 14. Tregubenko, Artemy. Test of localstorage limits/quota. [Online] [Citaat van: 7 april 2012.] 29

72 Vooronderzoek Bibliografie [15] 15. W3C Candidate Recommendation 22 December. Selectors API Level 1. [Online] W3C, 22 december [Citaat van: 2 april 2012.] [16] 16. W3C Recommendation. Selectors Level 3. [Online] W3C, 29 september [Citaat van: 2 april 2012.] [17] 17. JQuery will not exist in future? Stackoverflow. [Online] 28 oktober [Citaat van: 2 april 2012.] [18] 18. Pilgrim, Mark. What s next in HTML, episode 2: who s been peeing in my sandbox? The WHATWG Blog. [Online] Google, 26 januari [Citaat van: 9 april 2012.] [19] 19. Kohlschütter, Dr. What algorithm does Readability use for extracting text from URLs? StackOverflow. [Online] [Citaat van: ] [20] 20. RobertPitt. How do search engines find relevant content? StackOverflow. [Online] [Citaat van: ] [21] 21. Readability, LLC. Readability API Terms. Readability. [Online] [Citaat van: ] [22] 22. Boilerplate Detection using Shallow Text Features. Kohlschütter, C. 2010, WSDM, p.. [23] 23. Kohlschütter Search Intelligence. Boilerpipe Web API. Boilerpipe. [Online] [Citaat van: ] [24] 24. Kearney, Jeff Barr & Bill. Distribution of RSS versions. Syndic8. [Online] [Citaat van: ] [25] 25. RSS Advisory Board. RSS Advisory Board. RSS 2.0 Specification. [Online] [Citaat van: ] [26] 26. Google Reader API Group. Pyrfeed. Unofficial GoogleReader API. [Online] [Citaat van: ] [27] 27. Holmberg, Nils. Eye movement patterns and newspaper design factors. An experimental approach. sl : Lund University Cognitive Science, [28] 28. Nielsen, Jakob. F-Shaped Pattern For Reading Web Content. [Online] 17 april [Citaat van: 13 april 2012.] 30

73 Vooronderzoek Bibliografie [29] 29. Holmqvist, K, Holsanova, J, Barthelson, M, Lundqvist, D. Reading or Scanning? A Study of Newspaper and Net Paper Reading. sl : Elsevier Science Ltd, [30] 30. Display Resolution. Wikipedia. [Online] [Citaat van: 16 april 2012.] [31] 31. Resolution. [Online] [Citaat van: 17 april 2012.] [32] 32. Kohlschütter, Christian. Boilerpipe. Google Code. [Online] [Citaat van: ] [33] 33. Anirvan. Create Great Parser - Extract Relevant Text From HTML/Blogs. StackOverflow. [Online] [Citaat van: ] [34] 34. W3Schools. RSS History. W3Schools. [Online] [Citaat van: ] [35] 35. Doms, Martin. Using the Google Reader API. Martindoms. [Online] [Citaat van: ] [36] 36. Tweakers.net. Tweakers.net. [Online] [Citaat van: ] [37] 37. Nu.nl. Nu.nl. [Online] [Citaat van: ] [38] 38. CNN. CNN.com. [Online] [Citaat van: ] [39] 39. Engadget. Engadget.com. [Online] [Citaat van: ] [40] 40. Interfacelift. Interfacelift. [Online] [Citaat van: ] [41] 41. Readability, LLC. Readability API. Readability. [Online] [Citaat van: ] [42] 42. arc90labs. arc90labs-readability. [Online] [Citaat van: ] [43] 43. Gourdol, Arno. CSS3 regions: Rich page layout with HTML and CSS3. Adobe Developer Connection. [Online] 9 mei [Citaat van: 2 april 2012.] [44] 44. Adobe CSS Regions Labs. [Online] 31

74 Vooronderzoek Bibliografie [45] 45. Pilgrim, Mark. Beyond named key-value pairs: Competing visions. Dive into HTML5. [Online] [Citaat van: 2 april 2012.] [46] 46. Playground. HTML5 Rocks. [Online] [Citaat van: 2 april 2012.] [47] 47. Cederholm, Dan. Understanding CSS3 Transitions. A list apart. [Online] 16 november [Citaat van: 11 april 2012.] 32

75 Vooronderzoek Bijlagen BIJLAGEN BIJLAGE 1: LIJST VAN ARTIKELTEMPLATES 1x1 Foto Tekst 1x2 Tekst Tekst Foto (landscape) Foto Tekst Foto (landscape) 1x3 Foto (landscape) Foto (landscape) Tekst Foto Tekst Tekst Tekst Tekst Tekst 2x1 Tekst Foto Tekst Tekst 2x2 Foto (landscape) Tekst Tekst Tekst Tekst Tekst Foto (landscape) Tekst Foto Tekst Tekst Tekst 2x3 Tekst Foto Foto Tekst Foto Foto 33

76 Vooronderzoek Bijlagen Tekst Foto (landscape) Foto (landscape) Tekst Tekst Tekst Tekst Tekst Foto Tekst Tekst Tekst Tekst Tekst Tekst Tekst Tekst Tekst 3x1 Foto Tekst Tekst Tekst Tekst Tekst 3x2 Foto Foto Tekst Foto (landscape) Tekst Tekst Tekst Tekst Tekst Tekst Tekst Tekst Foto Foto Tekst Foto (landscape) Tekst Tekst Foto Tekst Tekst Tekst Tekst Tekst 3x3 Tekst Foto Foto Tekst Foto Foto Tekst Tekst Tekst Tekst Foto (landscape) Foto (landscape) Tekst Tekst Tekst Tekst Tekst Tekst Tekst Tekst Foto Tekst Tekst Tekst Tekst Tekst Tekst Tekst Tekst Tekst 34

77 Vooronderzoek Bijlagen Tekst Tekst Tekst Tekst Tekst Tekst BIJLAGE 2: LIJST VAN SCHERMTEMPLATES De notatie die hieronder gebruikt wordt is als volgt: 1x1A staat voor een 1x1 artikel, 1x1R staat voor een 1x1 raster. Het nummer dat tussen de haakjes staat, geeft de prioriteit aan van het artikel. 2.1 KLEINE RASTERS (1X1, 2X1 & 1X2) 1x1 raster: 1x1A 1x1 artikel (1) 1x2 raster1: 1x1A, 1x1A 1x1 artikel (1) 1x1 artikel (2) 1x2 raster2: 1x2A 1x2 artikel (1) 1x2 artikel (1) 2x1 raster1: 1x1A, 1x1A 1x1 artikel (1) 1x1 artikel (2) 2x1 raster2: 2x1A 2x1 artikel (1) 2x1 artikel (1) 2.2 MIDDELGROTE RASTERS (2X2, 2X3 & 3X2) 2x2 raster1: 2x2A 2x2 artikel (1) 2x2 artikel (1) 2x2 artikel (1) 2x2 artikel (1) 2x2 raster2: 1x2A, 1x2A 1x2 artikel (1) 1x2 artikel (1) 1x2 artikel (2) 1x2 artikel (2) 2x2 raster3: 1x2A, 1x1A, 1x1A 1x2 artikel (1) 1x2 artikel (1) 1x1 artikel (2) 1x1 artikel (3) 2x2 raster4: 1x2A, 1x2R 35

78 Vooronderzoek Bijlagen 1x2 artikel (1) 1x2 artikel (1) 1x2 raster (2) 1x2 raster (2) 2x3 raster: 2x2A, 2x1R 2x2 artikel (1) 2x2 artikel (1) 2x1 raster (2) 2x2 artikel (1) 2x2 artikel (1) 2x1 raster (2) 3x2 raster: 2x2A, 1x2R 2x2 artikel (1) 2x2 artikel (1) 2x2 artikel (1) 2x2 artikel (1) 1x2 raster (2) 1x2 raster (2) 2.3 MIDDELGROTE RASTERS (3X1, 1X3 & 3X3) 3x1 raster1: 3x1A 3x1 artikel (1) 3x1 artikel (1) 3x1 artikel (1) 3x1 raster2: 2x1R, 1x1A 2x1 raster (1) 2x1 raster (1) 1x1 artikel (2) 1x3 raster1: 1x3A 1x3 artikel (1) 1x3 artikel (1) 1x3 artikel (1) 1x3 raster2: 1x2R, 1x1A 1x2 raster (1) 1x2 raster (1) 1x1 artikel (2) 3x3 raster1: 2x2A, 3x1R, 1x2R 2x2 artikel (1) 2x2 artikel (1) 3x1 raster (2) 2x2 artikel (1) 2x2 artikel (1) 3x1 raster (2) 1x2 raster (3) 1x2 raster (3) 3x1 raster (2) 3x3 raster2: 2x2A, 2x1R, 1x3R 2x2 artikel (1) 2x2 artikel (1) 2x1 raster (2) 2x2 artikel (1) 2x2 artikel (1) 2x1 raster (2) 1x3 raster (3) 1x3 raster (3) 1x3 raster (3) 36

79 Vooronderzoek Bijlagen 2.4 GROTE RASTERS (4X2, 4X1, 1X4 & 4X3) 4x2 raster: 2x2A, 2x2R 2x2 artikel (1) 2x2 artikel (1) 2x2 artikel (1) 2x2 artikel (1) 2x2 raster (2) 2x2 raster (2) 2x2 raster (2) 2x2 raster (2) 4x1 raster: 3x1R, 1x1A 3x1 raster (1) 3x1 raster (1) 3x1 raster (1) 1x1 artikel (2) 1x4 raster: 1x3R, 1x1A 1x3 raster (1) 1x3 raster (1) 1x3 raster (1) 1x1 artikel (2). 4x3 raster: 4x2R, 4x1R 4x2 raster (1) 4x2 raster (1) 4x1 raster (2) 4x2 raster (1) 4x2 raster (1) 4x1 raster (2) 4x2 raster (1) 4x2 raster (1) 4x1 raster (2) 4x2 raster (1) 4x2 raster (1) 4x1 raster (2) 2.5 GROTE RASTERS (4X4) 4x4 raster1: 2x2A, 2x2A, 2x2R, 2x2R (4x2R, 4x2R) 2x2 artikel (1) 2x2 artikel (1) 2x2 artikel (3) 2x2 artikel (3) 2x2 artikel (1) 2x2 artikel (1) 2x2 artikel (3) 2x2 artikel (3) 2x2 raster (2) 2x2 raster (2) 2x2 raster (4) 2x2 raster (4) 2x2 raster (2) 2x2 raster (2) 2x2 raster (4) 2x2 raster (4) 4x4 raster2: 4x1R, 4x2R, 4x1R 4x1 raster (2) 4x2 raster (1) 4x2 raster (1) 4x1 raster (3) 4x1 raster (2) 4x2 raster (1) 4x2 raster (1) 4x1 raster (3) 4x1 raster (2) 4x2 raster (1) 4x2 raster (1) 4x1 raster (3) 4x1 raster (2) 4x2 raster (1) 4x2 raster (1) 4x1 raster (3) 37

80 Vooronderzoek Bijlagen 2.6 GROTE RASTERS (4X5) 4x5 raster1: 4x4R, 4x1R 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x1 raster (2) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x1 raster (2) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x1 raster (2) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x1 raster (2) 4x5 raster2: 4x2R, LEEG, 4x2R 4x2 raster (1) 4x2 raster (1) LEEG 4x2 raster (2) 4x2 raster (2) 4x2 raster (1) 4x2 raster (1) LEEG 4x2 raster (2) 4x2 raster (2) 4x2 raster (1) 4x2 raster (1) LEEG 4x2 raster (2) 4x2 raster (2) 4x2 raster (1) 4x2 raster (1) LEEG 4x2 raster (2) 4x2 raster (2) 2.7 GROTE RASTERS (4X6) 4x6 raster1: 4x2R, 4x2R, 4x2R 4x2 raster (1) 4x2 raster (1) 4x2 raster (2) 4x2 raster (2) 4x2 raster (3) 4x2 raster (3) 4x2 raster (1) 4x2 raster (1) 4x2 raster (2) 4x2 raster (2) 4x2 raster (3) 4x2 raster (3) 4x2 raster (1) 4x2 raster (1) 4x2 raster (2) 4x2 raster (2) 4x2 raster (3) 4x2 raster (3) 4x2 raster (1) 4x2 raster (1) 4x2 raster (2) 4x2 raster (2) 4x2 raster (3) 4x2 raster (3) 4x6 raster2: 4x1R, 4x2R, 4x2R, 4x1R (4x1R, 4x4R, 4x1R) 4x1 raster (3) 4x2 raster (1) 4x2 raster (1) 4x2 raster (2) 4x2 raster (2) 4x1 raster (4) 4x1 raster (3) 4x2 raster (1) 4x2 raster (1) 4x2 raster (2) 4x2 raster (2) 4x1 raster (4) 4x1 raster (3) 4x2 raster (1) 4x2 raster (1) 4x2 raster (2) 4x2 raster (2) 4x1 raster (4) 4x1 raster (3) 4x2 raster (1) 4x2 raster (1) 4x2 raster (2) 4x2 raster (2) 4x1 raster (4) 4x6 raster3: LEEG, 4x4R, LEEG LEEG 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) LEEG LEEG 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) LEEG LEEG 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) LEEG LEEG 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) 4x4 raster (1) LEEG 38

81 Vooronderzoek Bijlagen 2.8 GROTE RASTERS (4X7) 4x7 raster1: 4x6R, 4x1R 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x1 R (2) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x1 R (2) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x1 R (2) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x6 R (1) 4x1 R (2) 4x7 raster2: LEEG, 4x2R, LEEG, 4x2R, LEEG LEEG 4x2 R (1) 4x2 R (1) LEEG 4x2 R (2) 4x2 R (2) LEEG LEEG 4x2 R (1) 4x2 R (1) LEEG 4x2 R (2) 4x2 R (2) LEEG LEEG 4x2 R (1) 4x2 R (1) LEEG 4x2 R (2) 4x2 R (2) LEEG LEEG 4x2 R (1) 4x2 R (1) LEEG 4x2 R (2) 4x2 R (2) LEEG 4x7 raster3: 4x3R, LEEG, 4x3R 4x3 R (1) 4x3 R (1) 4x3 R (1) LEEG 4x3 R (2) 4x3 R (2) 4x3 R (2) 4x3 R (1) 4x3 R (1) 4x3 R (1) LEEG 4x3 R (2) 4x3 R (2) 4x3 R (2) 4x3 R (1) 4x3 R (1) 4x3 R (1) LEEG 4x3 R (2) 4x3 R (2) 4x3 R (2) 4x3 R (1) 4x3 R (1) 4x3 R (1) LEEG 4x3 R (2) 4x3 R (2) 4x3 R (2) 39

82 Stageverslag BIJLAGE D S P R I N T D O C U M E N T E N

83 Sprint 1 verslag SPRINT 1 VERSLAG Het belangrijkste doel van deze sprint was het opzetten van de ontwikkelomgeving. Er is bewust gekozen om het aantal backlog items voorde eerste sprint beperkt te houden en zo genoeg tijd te reserveren voor het opstarten van het project. De eerste sprint verliep niet volledig zoals een Scrum sprint bedoeld is. Bij deze sprint zijn een aantal problemen naar voren gekomen. Dit verslag is bedoeld als reflectie op de eerste sprint waarbij verbeteringen aan het proces voorgesteld worden en meegenomen worden in de tweede sprint. In het verslag wordt een reflectie van de verschillende scrum onderdelen en het prototype gegeven. Daarna worden er verbeteringen gepresenteerd welke uitgevoerd worden tijdens de tweede sprint. SPRINT BACKLOG Het is niet gelukt om vooraf een volledige sprint backlog op te zetten. Dit heeft tot gevolg gehad dat terwijl de sprint liep nieuwe taken toegevoegd zijn. Doordat tussendoor nieuwe taken toegevoegd zijn is de Burn-Down chart van de eerste sprint geen nette aflopende grafiek en is deze dus niet te gebruiken voor het verloop van de sprint. In bijlage A is de sprint backlog te vinden. Naast het vooraf definiëren van de backlog is het schatten en toekennen van tijden aan taken moeilijk gebleken. Door het ruim schatten van tijden zijn taken veelal eerder af dan de geschatte tijd. Echter is dankzij het samenwerken, zoals code controle tussen teamleden, ook tijd besteed wat niet op het scrum board staat. Hierdoor moet bij het schatten dan tijdsbesteding in de toekomst ook gelet worden op de door andere, niet aan de taak toegevoegde teamleden bestede tijd. Doordat het team bestaat uit drie leden en de producteigenaar niet full-time beschikbaar is voor het project, is de backlog veelal beheerd door verschillende teamleden. Volgens de Scrum methode is dit niet toegestaan. Het is echter, zolang de backlog niet continu aangepast wordt, geen probleem dat de backlog door bijvoorbeeld de Scrum Master beheerd word. Als laatste zijn een aantal organisatorische taken in de eerste sprint terecht gekomen welke niets te maken hebben met het product. Een van deze taken is bijvoorbeeld het opzetten van de ontwikkelomgeving. Ook een backlog item voor de documentatie is later toegevoegd. Hierin zijn verschillende taken voor rapporten in gedefinieerd. DEFINITION OF DONE De gekozen definition of done bestond uit de volgende elementen: JS Lint validatie Alle unit tests slagen en waar nodig zijn er tests bij geschreven Code review door collega SVN Commit met nuttig commentaar De definition of done was in de eerste sprint niet heel erg toepasselijk. Veruit de meeste taken zijn op done gezet terwijl meerdere regels van de defenitie van done niet toepasbaar waren. Het betreft hier vooral organisationele taken. Dit is echter geen probleem. 1

84 Sprint 1 verslag SCRUMBOARD Bij deze sprint is goed gebruik gemaakt van de opties welke door het Scrum board geboden worden. Er is gewerkt met nieuwe taken, waar iedereen mee bezig is en er is met de Definition of Done gedefinieerd wanneer een taak klaar is. ONTWIKKELOMGEVING De ontwikkelaars gebruiken ieder een eigen IDE om de code van te maken, bewerken en beheren. Iedere ontwikkelaar heeft zijn eigen voorkeur voor een IDE waardoor er niet een specifieke IDE gekozen is. Wel is er vereist dat er een makkelijke manier is om de kwaliteit van de code met JSLint te kunnen controleren door middel van bijvoorbeeld een plugin. wordt ontwikkeld in chrome. Het debuggen van de code gebeurt met Chrome DevTools. Een automatische testomgeving is opgezet welke bestaat uit unit tests, automatische code kwaliteit validatie door JSLint en handmatige code kwaliteit validatie door een collega volgens de definitie van done. De unit tests, waarmee de werking van low end functies geverifieerd wordt, draaien met gebruik van JSTestDriver in combinatie met Jenkins. Afgesproken in de definition of done is dat de unit tests moeten slagen wanneer iets klaar is. Ook Jenkins controleert of de unit tests slagen bij iedere commit van. Tijdens het ontwikkelen werken we met de methodiek design by contract. We ontwerpen methoden en objecten in UML relatie diagrammen en implementeren de stukken volgens het gemaakte UML diagram. Hierbij schrijven we pre en post condities in de vorm van argument en returns annotaties in de code. De json objecten waar naar verwezen wordt zijn in de desbetreffende UML diagrammen te vinden. Zie hiervoor ook het design document. De code wordt beheerd en geversioned door middel van een Subversion repository. Subversion of iets vergelijkbaars is een vereiste voor het onderhouden en beheren van stukken code. Een nette interne structuur, bestaande uit een trunk, branches en tags, zorgt er voor dat iedere sprint netjes een tag gemaakt kan worden van de dan werkende versie met de functionaliteiten van de desbetreffende sprint. SCRUM MASTER De eerste sprint was Huub de scrum master. De eerste sprint verliep rommelig met als reden dat de teamleden vanaf scratch moesten starten. Taken werden in de sprint uitgewerkt en gecreëerd. Stand-up meetings waren niet nodig omdat de teamleden door veelvuldig overleg te plegen van elkaar hun werktaken kenden. De momenten waar van de scrum methodiek werd afgeweken werden opgemerkt en bewust op een andere manier ingevuld. 2

85 Sprint 1 verslag STAND-UP MEETINGS Het is de bedoeling iedere ochtend en aan het eind van de middag met het hele team een korte staande meeting te houden over de voortgang van het project. Dit is echter veelal niet gebeurd omdat de teamleden gedurende de dag elkaar helpen, code controleren en over het ontwerp discussiëren. Het gevolg van dit door de dag samen komen is dat het hele team al op de hoogte is van de voortgang, en een extra meeting niet productief zal zijn. PROTOTYPE De door de projectbegeleider vooraf gestelde doelen van de sprint zijn gehaald. Aan het eind van de sprint is de basis van compleet, en kan een dummy stream op het scherm weergegeven worden. Uiteindelijk is ook een deel van de schermlogica geïmplementeerd, waardoor dynamisch rasters berekend worden en een passend raster gekozen word om de artikelen in weer te geven. Dit laatste was vooraf geen onderdeel van deze sprint, en daarmee eigenlijk een (positief) probleem omdat de tijd dus vooraf verkeerd geschat is. VERBETERPUNTEN Op verschillende onderdelen moeten de teamleden meer gestructureerd te werk gaan. De sprint backlog moet van te voren klaar zijn, stand-up meetings moeten gehouden worden en de teamleden moeten elkaar minder storen tijdens het werk. Wanneer je een collega nodig hebt geef je dat aan, die kan dan zelf wanneer die tijd heeft naar je toe stappen. Dit geldt ook voor de controles op de code van een collega, deze worden gedaan wanneer de collega daar klaar voor is. Voor overleg moet degene die het overleg initialiseert een moment nadenken over de structuur van het gesprek. Tevens moeten de teamleden een overleg, met verwachting langer dan tien minuten, buiten de werkkamer voeren. Op deze manier krijgen de teamleden meer rust tijdens het uitvoeren van hun taken waardoor ze productiever kunnen zijn. Komende Sprints wordt meer tijd besteed aan het vooraf definiëren van taken. Vooraf worden de hoofdtaken en de ingeschatte tijd gesteld. Deze taken worden grotendeels vooraf, maar kunnen tijdens de sprint onderverdeeld worden in subtaken. Hiermee wordt voorkomen dat de To Do tijd groter word, en toch kleine taken toegevoegd kunnen worden. De backlog zal voortaan door de Scrum Master beheerd worden, andere teamleden mogen in overleg taken toevoegen. Dit zal voorkomen dat verkeerde taken, met verkeerde tijdsschattingen toegevoegd worden. De backlog zal in dezelfde structuur geschreven en opgebouwd worden en er overzichtelijk uit komen te zien. Backlog items moeten omschreven worden als features. In de beschrijving moet duidelijk worden gemaakt wat het doel is van de feature. In welke delen en op welke manier het gemaakt wordt staat in de deeltaken. Deze taken worden aan het begin van de sprint gedefinieerd en geschat. 3

86 Sprint 1 verslag BIJLAGEN A. BACKLOG ITEMS SPRINT 1 Deze memo is een omschrijving van de backlog items welke voor de eerste sprint geselecteerd zijn. In de eerste sprint moet er een ontwikkelomgeving en automatische testomgeving opgezet worden welke het ontwikkelproces zullen gaan ondersteunen. De kwaliteit en werking van de geproduceerde code moet automatisch gecheckt worden. De vraag van de product owner is dat er in deze sprint aan de hand van een gegeven statische dataset een scherm kan worden gevuld. Hierbij mag de dataset gesimuleerd worden, aan de hand van deze database zal de logica van het programma worden gemaakt. Deze logica zal aan de hand van basis regels een resultaat op het scherm tonen. Verschillende variabelen binnen het ontwerp zullen in deze versie nog statisch zijn. Het scherm zal bestaan uit een enkele pagina met een vast aantal artikelen. Verwacht wordt dat de volgende elementen hiervoor geïmplementeerd moeten worden. Statische data Raster Artikeltemplate en schermtemplate Om dit te implementeren is gekozen voor een MVC structuur (zie design document). De backlog is daarom onderverdeeld in de elementen van de MVC structuur. In de model moet voor de eerste sprint de data simulatie worden geïmplementeerd. Het control gedeelte kan worden opgesplitst in een raster en een template deel. De view zal enkel een renderer bevatten. 4

87 Sprint 2 verslag SPRINT 2 VERSLAG Dit verslag is bedoeld als reflectie op de tweede sprint. Tijdens deze sprint is voornamelijk gewerkt aan het uitbreiden van de basisfuncties van. In deze sprint wordt meer rekening gehouden met de structuur van het scrum proces. Bijvoorbeeld is bij de start van deze sprint is de backlog voor de gehele week bepaald zodat het vrijwel niet nodig is geweest hier nog taken aan toe te voegen. In dit verslag zal beschreven worden welke problemen wij deze sprint tegen zijn gekomen. Vervolgens worden aanbevelingen gedaan om deze problemen in de toekomst te voorkomen. Hierna zal de scrum master van deze sprint zijn ervaringen geven. Als laatste is, in de bijlagen, de vooraf bepaalde sprint backlog gegeven. SPRINT BACKLOG Een van de features bleek te veel tijd te kosten. De template keuzemogelijkheid was ingewikkelder dan vooraf ingeschat. Dit heeft ertoe geleid dat alle teamleden enige tijd met het probleem hebben geworsteld voor het uiteindelijk kon worden opgelost. De kwaliteit van een andere feature, de fototemplates, is door het uitlopen van de template keuzemogelijkheid voor een deel in het gedrang gekomen. Een klein deel van deze feature functioneert niet naar behoren en moet naar een toekomstige sprint geschoven worden. Uiteindelijk konden, dankzij ruime schattingen en kleine compromissen, alle items uit het sprint backlog afgerond worden. Op een zeker moment binnen de tweede sprint waren de teamleden met te veel taken tegelijk bezig. Sommige taken moesten wachten op overleg of konden niet direct worden opgelost. Veel van deze taken zijn vervolgens binnen korte tijd afgerond. Hierdoor lijkt het alsof er op een dag meer werk vericht is dan de andere dagen van de week. Doordat sommige taken in de sprint backlog veel uren toegekend hebben gekregen stonden deze lange tijd als in progress op het scrum board. Gevolg hiervan is dat de burn-down chart tijdens het in uitvoering zijn van deze taken niet goed verliep. Ook is het niet mogelijk geweest deze taken te verdelen onder verschillende teamleden. STAND-UP MEETINGS Bij de eerste sprint is bepaald dat de stand-up meetings niet essentieel zijn wanneer de teamleden nauw met elkaar samenwerken. Wanneer de taken beter verdeeld zijn en iedereen zonder een ander te storen de taak kan voltooien, zou een stand-up meeting we nodig zijn. Deze sprint is geprobeerd naast elkaar te werken iedere ochtend een stand-up meeting te houden, waarbij kort overlegd werd wat ieder de bestreffende dag zal gaan doen. In het proces was meer overleg nodig dan verwacht waardoor de teamleden net als in de eerste sprint nauw samenwerkten. Niet iedere ochtend was een stand-up meeting nodig en ook niet gehouden. 1

88 Sprint 2 verslag SCRUM MASTER Deze sprint was Hylke de scrum master. Deze sprint verliep op een aantal punten beter als de eerste sprint. Wel is er uiteindelijk teveel tijd besteed aan taken welke wij in eerste instantie niet binnen de geschatte tijd af konden krijgen. Het gebruik van het scrum board en de sprint backlog is deze sprint goed verlopen. De sprint backlog werd vooraf vastgesteld en bleek te voldoen voor deze sprint. Hierdoor kon het scrum board goed gebruikt worden en was de burn down chart goed te gebruiken waarvoor deze bedoeld was. Dankzij de opgelopen vertraging en enkele zeer lange taken liep de burn down chart echter niet dagelijks het gewenst aantal uur naar beneden. Hieraan was te zien dat we prioriteiten moesten stellen, en door moesten werken. In de toekomst zal het handig zijn om problematische features vroeg te identificeren, en hier veel tijd aan toekennen, of de feature vroegtijdig te schappen. DOELSTELLINGEN De vooraf gestelde doelen van deze sprint zijn grotendeels gehaald. Aan het eind van deze sprint worden de artikeltemplates recursief vastgesteld zodat gemakkelijk meer templates toegevoegd kunnen worden. Ook is een begin gelegd aan het ondersteunen van foto artikelen binnen. Artikelen met foto s kunnen nu gerenderd worden in een template waarin de eerste foto in een van de hoekpunten van het artikel geplaatst wordt. Echter is nog veel te verbeteren aan de foto functionaliteit. De functionaliteit zit dus in maar moet gedeeltelijk aangepast worden. Verder wordt, als op de Read more knop onder een artikel geklikt word, een popup geopend waarin het gehele artikel te lezen is. Het artikel wordt met behulp van kolommen weergegeven in een popup met nette verhoudingen. Als het artikel te groot is voor de popup wordt binnen deze popup een scrollbalk weergegeven zodat het hele artikel te lezen is. Het vooraf gestelde doel hiervoor is geheel behaald. Andere doelstellingen zoals het verbeteren van bugs uit sprint 1 zijn ook voltooid, hierbij zijn geen problemen naar voren gekomen. VERBETERPUNTEN Taken hebben veel onderlinge afhankelijkheid. Het gevolg hiervan is dat een enkele taak pas op done kan worden gezet als alle taken, waar de functionaliteit van deze taak van afhangt, af zijn. Door de taken minder afhankelijk van elkaar te maken kunnen deze wel worden afgerond. De hoeveelheid tijd die is geïnvesteerd in het oplossen van de template keuzemogelijkheid is erg groot geweest. Om dit in een volgende sprint te voorkomen moet eerder worden besproken of de taak wel dusdanig belangrijk is. Als deze echt zo belangrijk is zal beter moeten worden overlegd hoe dit kan worden opgelost. Er stonden taken met een te lange toegekende tijdsduur in de sprint backlog. Deze taken zullen voortaan onderverdeeld moeten worden in kleinere subtaken van maximaal 4 uur. Dit zal onder andere voorkomen dat deze taken niet onder meerdere teamleden verdeeld gaat worden. 2

89 Sprint 2 verslag Ook in deze sprint is weer regelmatig met meer teamleden aan één taak gewerkt. Om dit te voorkomen moeten de taken voor de komende sprint beter los van elkaar geïmplementeerd kunnen worden. Dit wordt gedeeltelijk opgelost door het voorkomen van onderlinge afhankelijkheid, en deels opgelost door het opsplitsen van lange taken. BIJLAGEN A. BACKLOG ITEMS SPRINT 1 Deze memo is een omschrijving van de backlog items welke voor de tweede sprint geselecteerd zijn. In de tweede sprint kunnen we concrete features omschrijven doordat we de basis in de eerste sprint gemaakt hebben. Deze backlog items worden op volgorde van belangrijk naar minder belangrijk gepresenteerd. Als eerste hebben is er een nieuw concept bedacht om de statische templates lokaal op te slaan. In de eerste sprint was er een explosie aan statische templates. In deze sprint maken we de optie om in een schermtemplate op een bepaalde plek meerdere (zowel artikel als scherm) templates te kunnen zetten. moet na de tweede sprint te weinig artikelen kunnen afhandelen. In de huidige versie kan 1 artikel niet op het scherm getoond worden omdat het scherm niet compleet gevuld is. Een ander item is een simpele detailview per artikel met een artikel als tekst en zijn titel in de header. Daarnaast maken we view templates in de view van streampaper. De verschillende view templates moeten artikelen verschillend renderen. Een view template moet rule based gekozen worden aan de hand van zijn artikeldata. Afbeeldingen worden meegenomen in de statische data. In deze sprint wordt een enkele afbeelding meegestuurd met de statische data. Een aparte view template moet gemaakt worden voor het renderen van een artikel met een afbeelding. De tekst heeft in deze view echter de overhand. De berekende grid moet aangepast kunnen worden wanneer er geen screentemplate voor de huidige afmetingen van de grid is. De grootst mogelijke schermtemplate wordt gebruikt door de controller, de grid zou zich aan moeten passen zodat het template over het gehele scherm verdeeld wordt. Naast de voorgaande items moeten er verschillende thresholds verhuizen van de code naar de settings. Op die manier kan er op een enkele plek gespeeld worden met de variabelen. Hieronder volgt een gedetailleerd overzicht van de sprint backlog items voor sprint 2. De cijfers achter de backlog items zijn de verwachte uren voor de desbetreffende taak. 3

90 Sprint 2 verslag - Template keuzemogelijkeheid subtemplates = 12 o UML: Template keuzemogelijkheid - 2 o Design Document: template keuzemogelijkheid - 2 o Bestaande templates aanpassen op keuzemogelijkheid 2 o Conversie methode voor template keuzemogelijkheid Te weinig artikelen afhandelen = 2 o Bij tekort aan artikelen schermtemplate alsnog vullen en tonen Detailview simple text = 4 o Detailview opzetten - 2 o Layout maken View templates (text) = 6 o UML: View templates - 2 o Design Document: View templates - 2 o Herschrijven code: View templates Foto s = 26 o UML: Foto s - 3 o Design Document: Foto s - 2 o Viewtemplate met 3x tekst en 1x foto - 12 o Foto s toevoegen aan (static) inputdata - 1 o Foto oppervlakte meerekenen in DataFitsTemplate - 1 o Foto s toevoegen aan view.renderarticle - 1 o Overleg Grid setdimensions = 4 o Grid: setdimensions toevoegen - 2 o Control: setdimensions aanroepen wanneer nodig Hardcoded variabelen = 2 o Fix hardcoded variabelen Documentatie = 16 o Sprint verslag schrijven - 7 o Sprint verslag nakijken en verbeteren - 3 o Design Document schrijven - 4 o Design Document nakijken en verbeteren - 2 4

91 Sprint 3 verslag SPRINT 3 VERSLAG Dit verslag is bedoeld als reflectie op de derde sprint. Tijdens deze sprint is voornamelijk gewerkt aan het maken van de basisfuncties van de server van. Deze sprint was slechts 4 dagen in verband met hemelvaart, bij het maken van de backlog is hier rekening mee gehouden. De taken vooraf opgedeeld zodat er meer kortere taken zijn, zoals is voorgesteld in de refelectie op sprint 2. In dit verslag zal beschreven worden welke problemen wij deze sprint tegen zijn gekomen. Vervolgens worden aanbevelingen gedaan om deze problemen in de toekomst te voorkomen. Hierna zal de scrum master van deze sprint zijn ervaringen geven. Als laatste is, in de bijlagen, de vooraf bepaalde sprint backlog gegeven. SPRINT BACKLOG Bij het maken van de backlog werd duidelijk dat de taak voor het maken van het optimale algoritme nog niet volledig te specificeren was. Daarom is er ruimte gelaten om deze tijdens de sprint in te vullen. De overige taken zijn wel volledig uitgespecificeerd. Gedurende de sprint zijn bijna alle taken afgerond, het optimale algoritme is nog niet volledig geïmplementeerd. Het implementeren van Readability heeft meer tijd gekost dan verwacht. Gevolg hiervan was dat er deze sprint niet genoeg tijd was om alle taken van het optimale algoritme af te ronden. Daarom zullen een aantal sub-taken van deze feature komende sprint worden opgepakt. Doordat er in de backlog kleine losse taken waren gemaakt is er in deze sprint zo goed als geen pair-programming gedaan. Meer taken konden zonder hulp worden afgerond wat de productiviteit verhoogd. Hierdoor zijn er veel taken afgerond ondanks de verkeerde inschatting van Readability. De integratie van de gedane taken van Sprint 3 was geen onderdeel van deze sprint. Het maken van deze onderdelen is echter een vereiste om deze te kunnen integreren. Vandaar dat de integratie met in de komende sprint zal gebeuren. STAND-UP MEETINGS Ook deze sprint zijn weer stand-up meetings gehouden, doordat er minder samen werd gewerkt was de toegevoegde waarde van de stand-up meetings deze sprint hoog. Er moet echter wel worden opgelet dat er niet gedurende de stand-up over oplossingen word gesproken. Door elkaar hieraan te herinneren konden de meetings kort worden gehouden. SCRUM MASTER Deze sprint was Peter de scrum master. In deze sprint is weer goed gebruik gemaakt van het scrum board en zijn de stand-up meetings goed gebruikt. Er is in deze sprint vroeg gesignaleerd dat er een probleem was met readability, daardoor is er op tijd besloten meer tijd daarin te steken hierdoor is het algoritme dat optimaal de templates kiest niet afgerond. Doordat er wel aan de andere items 1

92 Sprint 3 verslag kon worden doorgewerkt konden deze wel worden afgerond. Hierdoor zijn dagelijks taken afgerond en is de burndown chart dit keer dichter bij de ideale lijn. DOELSTELLINGEN De vooraf gestelde doelen van deze sprint zijn grotendeels gehaald. Er zijn verschillende onderdelen van de server geïmplementeerd en er zijn verbeteringen aangebracht aan de foto afhandeling van de client. Het optimale algoritme is echter niet afgerond, dit betekend dat dit in de volgende sprint zal moeten worden gedaan. De server kan RSS feeds, berichten uit Outpost en websites uitlezen. Deze worden nog niet opgeslagen waardoor deze elke keer opnieuw moeten worden opgehaald. Dit ophalen duurt, doordat meerdere websites geladen moeten worden, erg lang wat betekend dat dit nog niet geïntegreerd kan worden met. Het vooraf gestelde doel, het uitlezen is gehaald. De integratie en het vooraf opslaan van artikelen zodat artikelen snel geladen kunnen worden zal komende sprint gebeuren. VERBETERPUNTEN Het inschatten hoe veel tijd taken kosten kan nog beter worden gedaan zodat alle taken worden afgerond. Het is echter nooit te voorkomen dat een taak aanzienlijk moeilijker blijkt te zijn dan vooraf is ingeschat. Hierdoor zullen in de toekomst waarschijnlijk vaker taken uitlopen. Echter kan wel geprobeerd worden vooraf te bepalen of een taak risicovol is en langer kan duren. Tegenover een risicovolle taak kan een uitlooptaak geidentificeerd worden, welke overgeslagen kan worden als een taak te ver uitloopt. 2

93 Sprint 3 verslag BIJLAGEN A. BACKLOG ITEMS SPRINT 3 Deze memo is een omschrijving van de backlog items welke voor de derde sprint geselecteerd zijn. In de derde sprint maken we een begin aan het gebruik van dynamische informatie. Op het programma staat onder andere het analyseren van websites en daar de belangrijke (artikel) informatie uit halen. RSS feeds moeten kunnen worden opgehaald en geconverteerd worden naar het datamodel welke gebruikt wordt in. De voorgaande twee functionaliteiten komen samen in de Streamreader. De Streamreader haalt items op via de zelfgemaakte rss reader, scant op linkjes naar webpagina s en wanneer het bericht klein is zal de Streamreader de zelfgemaakte website lezer aanroepen om extra informatie op te halen. Op de client maken we een Articlemanager welke de vraag naar artikelen managed. De Articlemanager regelt welke artikelen er op het scherm worden weergeven en of hij nieuwe artikelen moet laden. Naast de artikelmanager wordt voor de client een begin gemaakt aan een optimaal algoritme ter vervanging van het greedy algoritme voor het matching probleem van artikelen aan templates. Een aantal kleine verbeteringen als cache, foto s schalen en croppen en een iframe voor het tonen van de bronnen van berichten. Hieronder volgt een gedetailleerd overzicht van de sprint backlog items voor sprint 2. De cijfers achter de backlog items zijn de verwachte uren voor de desbetreffende taak. o Website uitlezen - 6 Uitvinden hoe Readability API werkt 2 Implementeren - 4 o RSS feeds = 8 Aanroepen - 2 Uitlezen - 2 Combineren - 2 Klasse maken -2 o Streamreader - 6 Rss aanroepen, evt websites uitlezen en combineren -4 Outpost uitlezen - 2 o Articlemanager = 4 Articles renderen en bijhouden welke gerendered zijn - 4 o Optimaal algoritme voor templatekeuze o iframe (voor bron) in popup = 2 o Verbeteren fotoweergave = 5 Image tiles berekenen (in vierkanten) 2 Image croppen (huub) 2 Image scale meenemen in image tiles - 1 o templates cachen = 2 3

94 Sprint 3 verslag o Outpost stream uitlezen = 8 SQL query bouwen 2 Omschrijven naar item format 4 Klasse maken - 2 o Documentatie Sprintverslag schrijven - 4 Sprintverslag controle 2 Design document schrijven 4 Design document controle - 2 4

95 Sprint 4 verslag SPRINT 4 VERSLAG Dit verslag is bedoeld als reflectie op de vierde sprint. Tijdens deze sprint is functionaliteit toegevoegd waarbij artikelen preiodiek worden opgehaald en opgeslagen in een database. De client haalt voortaan, in plaats van zelf uit de feeds, de artikelen uit de database. Verder is de structuur achter de JavaScript code geheel verbeterd en aangepast aan de hand van een gesprek met een ontwikkelaar bij Moxio (Frits van Campen). Ook zijn pagina s toegevoegd zodat een gebruiker meer berichten kan zien. SPRINT BACKLOG Bij het maken van de backlog werd besloten dat de feedback van Frits gedurende deze sprint verwerkt zou worden om te zorgen dat de kwaliteit van de code na deze sprint een stuk beter is. Daarnaast zouden verschilende onderdelen van de server worden samengevoegd, en moesten er weer verschillende features worden geïmplementeerd. Tijdens sprint 3 was het optimale algoritme niet volledig geïmplementeerd, in deze sprint is dit algoritme afgerond. De overige nieuwe items zijn bijna allemaal afgerond, het opzetten van verschillende pagina sets is niet volledig afgerond. Oorzaak hiervan is dat het combineren van de verschillende aspecten veel bugs op heeft geleverd welke gefixed moesten worden. Omdat de pagina sets weinig toegevoegde waarde hebben is de implementatie hiervan uitgesteld. STAND-UP MEETINGS In deze sprint zijn de korte stand-up meetings afgewisseld met langere meetings. Doordat in de stand-up meetings niet over de implementatie is gesproken werd er overdag langs elkaar heen gewerkt. Door verschillende implementaties van de taken waren de lange meetings nodig. Het is echter wel voorgekomen dat niet overlegd was over een taak, en dit wel nodig bleek. Nadat een deel geimplementeerd was bleek het dat de visies over deze taak niet overeenkwamen. Hierna is alsnog overleg gepleegd en is de richting bijgesteld. Hier is echter weinig tot geen overbodig werk gedaan. DOELSTELLINGEN De doelstellingen van deze sprint zijn grotendeels gehaald. Het optimale algortime is afgerond, de server onderdelen zijn geïntegreerd, de code is verbeterd en er kan gebladerd worden binnen een tijdsblok. Het wisselen van tijdsblokken zal nog moeten worden geïmplementeerd, hier zijn wel veel benodigdheden voor toegevoegd. Deze doelstelling is dus niet gehaald. Opvallend is dat aan het begin van deze sprint de verwachting was dat aan het eind dusdanig ver zou zijn dat de volgende sprints puur aanvullingen toegevoegd zouden worden. Nu blijkt dat bij deze sprint wel veel bereikt is, maar dat door onvoorspelbare variabele datasets veel onverwachte punten naar voren zijn gekomen. Deze onverwachte punten zullen een groot deel uitmaken van de volgende sprint. 1

96 Sprint 4 verslag VERBETERPUNTEN Er moet beter worden overlegd over de invulling van de backlog items zodat iedereen ze kan implementeren. Tijdens deze sprint zijn veel bugs geintroduceerd, maar ook opgelost. Als oplossing zou het mogelijk kunnen zijn preventiever te programmeren zodat er minder bugs bij komen. Echter is het de aard van de problemen dat de uitkomst van een oplossing vanwege onder andere variabele bronnen onvoorspelbaar kan zijn. 2

97 Sprint 4 verslag BIJLAGEN A. BACKLOG ITEMS SPRINT 4 UIT SPRINT 3 Optimaal algoritme (10) o Combineren van de 3 verschillende factoren (8) o Waarden voor positie op scherm aanpassen aan F-vorm (2) UIT GESPREK FRITS Documentatie (2) o Waarom de client/server structuur? Onderbouwen in design document 1. Alternatieve architecturen welke overwogen zijn noemen, en onderbouwen waarom die niet zijn gekozen. (2) Dependency injection (16) o Globals verwijderen (12) Window en document op 1 plek meegeven (main) en overal verwijderen, eventueel meesturen oid. Alles omtrent de dom in de dom_wrapper (8) jquery verwijderen, each functie naar utils. Andere functies van jquery proberen te schrijven met pure JS of ook wrappen (4) o Modules omschrijven zodat ze instanties van zichzelf teruggeven met een create functie. Deze modules moeten om de juiste plek aangemaakt en beheerd worden, let hierbij op verantwoordelijkheden. (4) o Resultaat moet twee instanties van naast elkaar kunnen draaien. (2) UIT FUTURE BACKLOG Server Artikelen Cachen (12) o Database opbouwen, de RSS feeds welke gemonitord worden, artikelen welke erbij horen en de images die daarbij horen. (4) RSS: [id, url] Artikelen: [id, title, content (clean), date,url] Images: [id, url, width, height, article] o Cron handler schrijven die alle rss feeds scant op nieuwe berichten en die verwerkt als er nieuwe zijn. (8) Server structuur veranderen. (8) o Huidige klassen worden deels omgebouwd en verhuisd naar het scon script. Een deel blijft bij de stream_handler. Ontwerp het met UML van te voren. (8) Simpel opzetje pagina s (12) o Drie tijdsblokken maken in de manager, Today, yesterday, last week. Een state system maken welke tussen deze states kan switchen (4) o View moet een pagina switch knoppen krijgen, zowel om nieuwe en oude artikelen binnen de tijdslijn te verkrijgen, maar ook om tussen de tijdsstates te switchen. (8) 3

98 Sprint 4 verslag Documentatie (12) o Sprintverslag schrijven (4) o Sprintverslag controleren (2) o Design document schrijven (4) o Design document controleren (2) STANDAARD Tijd te besteden: 90u Tijd van de taken: = 72u 4

99 Sprint 5 verslag SPRINT 5 VERSLAG In dit verslag wordt gereflecteerd op de vijfde sprint. Tijdens deze sprint zijn tijdsblokken toegevoegd waartussen kan worden genavigeerd en is outpost geïntegreerd met. Daarnaast zijn verschillende bugs opgelost en zijn er enkele kleine features toegevoegd. SPRINT BACKLOG Gedurende deze sprint zijn alle backlog items afgerond. Doordat ook deze keer de tijdsinschatting weer niet heel goed was, waren er dit maal meer uren beschikbaar dan ingepland. In deze extra uren zijn extra s toegevoegd welke eerder de backlog niet hadden gehaald. Deze sprint was een kleine fout gemaakt bij het invoeren van de taken; de taken hadden geen toegekende tijd. Dit is geen probleem voor het proces, maar resulteerd wel in een onbruikbare burn down chart. STAND-UP MEETINGS Deze sprint zijn geen officiele stand up meetings gehouden. Dit komt doordat de backlog voor een groot deel uit bugfixes bestond, hierdoor moest tussendoor over de oplossing overlegd worden. De sprint master heeft echter wel bijgehouden wie wat ging doen, en er voor gezorgd dat het juiste gebeurde. DOELSTELLINGEN Alle doelstellingen van de vijfde sprint zijn gehaald. In deze versie is als geheel een stap dichter naar het eindresultaat getild. Er kan nu tussen en door tijdsblokken genavigeerd worden. Ook externe pagina s en afbeeldingen worden binnen het programma geopend. Ook de links in de overview worden nu binnen geopend. Die popup is in de tweede sprint toegevoegd en de functionaliteit om een url hierin te openen in de derde sprint. De links in de overview zijn in de vierde sprint als bug gerapporteerd welke in deze sprint opgelost is. Naast de backlog items zijn ook nog andere zaken voltooid. Een script is gekoppeld aan een intern systeem van Moxio (Outpost) waardoor berichten nu ieder kwartier automatisch geïmporteerd worden in de database van. Daarnaast zijn er veel kleine toevoegingen doorgevoerd. VERBETERPUNTEN Een van de taken was veel te ruim ingepland, hierdoor was veel tijd over. Echter was vooraf niet beter te voorspellen hoe lang deze taak zou gaan duren. De vrijgekomen tijd van deze taak is besteed aan het verbeteren van de code en het implementeren van extra functionaliteit. In de toekomst kunnen meer taken aan de backlog toegevoegd worden, deze taken kunnen dan opgepakt worden als veel tijd over is. Aan de andere kant is het ook prima om deze tijd te besteden aan het verbeteren van de kwaliteit van de al bestaande code. 1

100 Sprint 5 verslag BIJLAGEN A. BACKLOG ITEMS SPRINT 5 Outpost opnieuw integreren o Intern overleg met Moxio (6) o Overleg onderling (6) o Implementatie (8) Speciale characters moeten goed de database in gezet worden (8) Timespans worden geïntegreerd in de manager (4) Programma shortcuts met het Toetsenboard (4) Datum en tijd van artikel bij het artikel weergeven. (4) o Datum object uitbreiden met methode die de leesbare tijd verkrijgt. (2) o Datum weergeven bij de artikelen welke gerenderd worden Linkjes in het overview (6) o Onderzoeken waarom deze niet in een popup geopend kunnen worden. (2) o Een oplossing maken voor het omgaan met de linkjes. (4) Whitespace uit berichten filteren op de server. Hiermee wordt het optimale algoritme efficiënter. (4) In het overview scherm moeten foto s vergroot kunnen worden. Daarbij moeten ze juist geschaald en gecropped worden. (2) Het linkje in de popup moet naar de header verhuizen, en achteraan de content staan. (2) 2

101 Sprint 6 verslag SPRINT 6 VERSLAG In dit verslag wordt gereflecteerd op de zesde sprint. Tijdens deze sprint is ervoor gekozen om weinig nieuwe features toe te voegen maar de huidige features uit te bereiden en bugvrij te maken. Toegevoegde features zijn bijvoorbeeld het detecteren van kleine artikelen met links is en het gebruiken van favicons bij artikelen. Uitgebreide features zijn bijvoorbeeld het gebruiken van kleine foto s in de overview en foto s in de read more gebruiken. SPRINT BACKLOG Bij deze sprint is er bewust voor gekozen om alle interessante items op de backlog te zetten ondanks dat deze waarschijnlijk niet allemaal kunnen worden afgerond. De backlog is bewust te groot gemaakt om alle taken te kunnen voltooien in deze week. Hier is voor gekozen om zo veel mogelijk interessante features te implementeren deze sprint. Dit is de laatste sprint waarin veel features ontwikkeld worden, de laatste sprints zullen vooral veel verbeteringen doorgevoerd worden. STAND-UP MEETINGS In deze sprint moesten veel kleine taken worden uitgevoerd. Dit betekende dat er vaak moest worden overlegd wie een taak ging doen en hoe deze precies zou worden uitgewerkt. Naast de meetings s ochtends is ook overdag veel overleg geweest. Door het vele overleg is voorkomen dat er dubbel werk is gedaan en zijn de taken zo verdeeld dat er aan gewerkt is door de persoon die de taak het beste kon uitvoeren. Zodoende heeft het overleg het proces verbeterd. DOELSTELLINGEN Doordat het niet de doelstelling was alle backlog items binnen deze sprint te voltooien maar zo veel mogelijk halen is de doelstelling gehaald. Er zijn een hoop fixes gedaan en enkele belangrijke features zijn toegevoegd. De bruikbaarheid van is hierdoor een stuk beter. De sprint is niet binnen de gegeven tijd afgerond. Een aantal taken, waaronder de documentatie zijn naar de maandag van de zevende sprint verplaatst. Voor de cron handler ontbrak nog wat documentatie en ook het design document was nog niet compleet. Een stream kan nu toegevoegd worden alleen moethet uiterlijk van de interface daarvan nog worden verbeterd. Er is deze sprint geen mogelijkheid om streamsets te kiezen toegevoegd. Van de backlog items is een item vervallen, dit betreft het aangeven welke tekst al was weergeven in de overview bij het openen van een detailview van een artikel. Deze taak is vervallen omdat het implementeren hiervan binnen het huidige programma niet haalbaar bleek te zijn. Er kon niet worden gedetecteerd waar de tekst niet meer in de gegeven ruimte past. De beschrijving van de iframe popup voor de integratie in outpost ontbreekt ook nog. Deze taak is doorgeschoven naar de zevende sprint. 1

102 Sprint 6 verslag VERBETERPUNTEN Er is gedurende deze sprint hard gewerkt en veel afgekomen, de twee laatste sprints moet dit worden vastgehouden. Binnen deze sprint zijn een paar taken geschrapt en/of doorgeschoven. Dit is echter een vooraf ingeschat gevolg van de uitgebreide backlog. Hierdoor is veel werk verzet deze sprint. BIJLAGEN A. BACKLOG ITEMS SPRINT 6 Outpost reply s meenemen (4) Kleine foto s in overview gebruiken (8) o Kleine foto s detecteren (2) o Kleine foto s weergeven (2) o Layout artikel veranderen om kleine foto s te kunnen weergeven (4) Foto s in read more (8) o Over implementatie vergaderen (2) o Kleine en grotere foto s onderscheiden (2) o Implementeren (4) Kleine berichten met enkel link afhandelen (8) o Kleine berichten met voornamelijk een enkele link detecteren (4) o Kleine berichten met voornamelijk een enkele link afhandelen (4) Bron aangeven van artikel (6) o Database aanpassen + opslagfunctie maken (2) o Icon en bron weergeven bij artikel (2) o Icon uit bron extracten (2) Artikelen met grote lijsten links verwijderen (4) In read more aangeven waar originele bericht is afgebroken (4) Small fixes (20) o Dubbele berichten uit database halen (2) o Footer onderin houden na resizen (2) o Popup in scherm met 1 col (2) o Laatste encoding probleem oplossen (4) o Bij overflow read more verwijderen (2) o Als readability faalt content uit rss gebruiken (2) o Hash over de tekst voor foto plaatsen (2) o Foto verhouding in popup fixen (2) o Bug in keyhandlers voor wisselen van timespan (2) Cron handler opsplitsen (8) o Cron handler voor rss maken (4) o Cron handler voor readability maken (4) Streamsets kiesbaar maken & feeds kunnen toevoegen (4) o Streamsets kiesbaar maken (2) o Feeds kunnen toevoegen (2) Pagina s versnellen of loading screen implementeren (8) 2

103 Sprint 6 verslag o Overleg (4) o Pagina s versnellen of loadng screen implementeren (4) iframe popup definieren voor outpost (8) Documentatie (12) o Sprintverslag (4) o Design document (4) o Controle sprintverslag (2) o Controle design document (2) 3

104 Sprint 7 verslag SPRINT 7 VERSLAG In dit verslag wordt gereflecteerd op de zevende sprint. Tijdens deze sprint is het grafische ontwerp van naar een hoger niveau getild met hulp van de designer van Moxio. Er zijn ook features gebouwd en andere functionaliteiten verbeterd. SPRINT BACKLOG Een aantal backlog items uit de zesde sprint zijn opgenomen in de backlog van sprint zeven. Het betreft hier het splitsen van de cron en onderdelen van het design document. Deze backlog items zijn als eerste opgepakt en hebben in totaal ongeveer 16 uur gekost. Deze sprint zijn een aantal fouten uit het programma gerepareerd, ook zijn er kleine features toegevoegd. Verder is gewerkt aan documentatie en de stijling van het programma. STAND-UP MEETINGS Er zijn geen stand-up meetings gehouden in de zevende sprint. Er werd de hele dag door nauw met elkaar samengewerkt om de verschillende functionaliteiten goed met elkaar af te stemmen. DOELSTELLINGEN Binnen deze sprint zijn de belangrijke doelstellingen allen behaald. Deze sprint zijn aan het begin aanzienlijk veel taken toegevoegd zodat zo veel mogelijk werk verzet zou kunnen worden. De taken zijn onder te verdelen in een aantal categorieen; Documentatie, bug reparatie, het schoonmaken van code en de stijling van. Van de documentatie is een deel afgekomen, maar hier moet komende sprint nog aan gewerkt worden. Vrijwel alle als belangrijk aangemerkte bugs zijn gerepareerd, andere bugs zijn niet belangrijk omdat zij niet van groot invloed zijn op het programma. De code is grotendeels doorgelopen en schoongemaakt. De stijling is geheel aangepast zodat er nu netjes uit ziet. Verder werd deze sprint feedback verwacht van SIG, deze is niet gekomen en zal dus volgende sprint verwerkt moeten worden. VERBETERPUNTEN Er is weinig aan te merken op deze sprint. Er moet komende sprint meer nadruk gelegd worden op documentatie, aanpassingen op het programma moeten een lage prioriteit krijgen. Deze en volgende sprint zijn eigenlijk geen Scrum sprints meer omdat de nadruk niet meer ligt op het ontwikkelen van software. Komende sprint zal vooral gecoordineerd moeten worden op delen van het stageverslag, wie doet wat en hoe zorgen we voor goede kwaliteit. 1

105 Sprint 7 verslag BIJLAGEN A. BACKLOG ITEMS SPRINT 7 Documentatie sprint 6 (8) o Afmaken design document (Cron) (4) o Controle design document (2) o Controle sprintverslag (2) Feature (4) o Cron opsplitsen code opschonen (4) Stageverslag (40) o Maandag (8) o Dinsdag (8) o Woensdag (8) o Donderdag (8) o Vrijdag (8) Code review Frits (14) o Overleg met Frits (6) o Feedback verwerken (8) Overleg met Hendrik (dinsdag) (18) o Voorbereiden overleg (4) o Overleg met Hendrik (6) o Conclusie uitwerken (8) iframe popup definieren voor outpost (8) documentatie (12) o Sprintverslag (4) o Design document (4) o Controle sprintverslag (2) o Controle design document (2) B. OPTIONELE BACKLOG ITEMS Features: o Bij outpost geen link geven naar outpost o Bij outpost voor reply s alleen de reply door readability niet het originele bericht vervangen Bugs: o Open popup -> open foto -> sluit foto -> navigeer met toetsen o Sommige berichten missen foto s terwijl ze die zouden moeten hebben (bijvb printing for ronny & Anon, but not alone: Anonymous helps its fallen brethren) o Links met daarin enkel een foto moeten foto openen ipv web popup (bijvb bij tweakers & nos) 2

106 Sprint 7 verslag o BBC: lijst van andere artikelen uit content verwijderen (readability faalt) o Treshold tweaken (zie Real-Time Traffic Info Gets More Real in 3x3) Hoe groter een artikel hoe erger een foutje zichtbaar wordt o Kleine lijstjes met links verwijderen Database schoon vegen 3

107 Stageverslag BIJLAGE E D E S I G N D O C U M E N T E N

108 Design Document Sprint 1 D E S I G N D O C U M E N T SPRIN T 1 : C L IE NT is opgedeeld in de client en de server. De server heeft twee verantwoordelijkheden. De eerste is bij een http request van een browser een volledige instantie van de client afleveren aan de browser. De tweede verantwoordelijkheid is de client applicatie voorzien van benodigde data welke opgevraagd kan worden door middel van services. In de eerste sprint wordt de client van ontworpen en geïmplementeerd. De client haalt statische data van de server. Met deze data wordt een overzicht gegenereerd en gevisualiseerd. In dit document wordt het ontwerp van de client nader uitgewerkt. De client is volledig geschreven in Javascript. JSON & Modules De applicatie bestaat uit JSON objecten en modules. JSON is een Javascript object notatie welke voor mensen gemakkelijk te lezen en schrijven zijn en voor machines gemakkelijk te parsen zijn. Een module is een Javascript variabele op gebouwd volgens het Module pattern 1. In de UML diagrammen staan verwijzingen naar zowel JSON objecten als modules. Hier bij wordt het voorgaande mee bedoeld. SAMENVATTING De client van moet artikelen ophalen en presenteren op het scherm. Hiervoor is een MVC structuur gekozen waarbij alleen de view de DOM van de browser aanpast. In de controller wordt een grid gemaakt van de schermafmetingen. Tevens wordt er met de grid afmetingen en statische templates gekozen hoe de artikelen op het schermverdeeld worden. Het model zorgt voor de connectie met de data op de server voor het ophalen van de artikelen. 1. CLIENT In bijlage A is de gehele client in een UML diagram weergegeven. De variabele naam van de hoofdvariabele heet sp. Daaronder zijn onder andere de JSON objecten globals en settings te vinden. Globals is een JSON object dat fungeert als mapping tool over de third party libraries. Dit heeft als voordeel dat er inzicht is in het gebruik van externe libraries. Ook de document en window worden via de globals aangeroepen. De settings is een module waar verschillende constanten verkregen kunnen worden. Naast globals en settings zijn ook model, view en control in de sp variabele te vinden. Deze staan voor de verschillende onderdelen van de MVC architectuur. De MVC architectuur is beschreven in hoofdstuk

109 Design Document Sprint 1 2. MODEL VIEW CONTROLLER De client wordt volgens de Model View Controller (MVC) architectuur geïmplementeerd. Er is voor de MVC structuur gekozen om een duidelijke scheiding te hebben tussen de weergave van de artikelen (view), het opvragen van data (model) en de transformaties (control) MODEL Het model bestaat in de eerste sprint alleen uit het opvragen van artikelen. De module Articles binnen het Model is verantwoordelijk voor het ophalen van de artikelen VIEW De view bevat vier modules; Application, Header, Footer en Articles. De header en footer bevatten nog geen functionaliteit behalve het visualiseren van de elementen zelf. De Articles module heeft echter meer functionaliteit. Deze moet verschillende artikelen kunnen weergeven. Deze methode krijgt volgens het schema in bijlage B gepositioneerde artikelen aangeleverd. Het weergeeft vervolgens de artikelen binnen het container element welke de module zelf beheerd. De Application module beheerd alle elementen binnen streampaper. Er is maar een enkel element, de application, welke door statische HTML gedefinieerd wordt. Alles binnen streampaper wordt door Javascript opgebouwd en gerenderd. De application module rendert de header, footer en articles CONTROL READY & MAIN De control namespace bevat alle logica en transformaties van de client. De ready module is een module welke regelt dat functies uitgevoerd worden wanneer de client van is ingeladen. De module slaat eventhandlers op in twee prioriteiten. De eerste is een lijst van functies welke core functionaliteit moeten initialiseren. De tweede is een lijst van functies welke daarna uitgevoerd worden wanneer de client van geladen is en alle core initialisatie functies voltooid zijn. Main heeft een initialisatie methode waarin de client van gestart wordt. Deze wordt als eventhandler aan de ready module gegeven GRID De Grid module berekent de grid van het scherm. Deze grid wordt gespecificeerd door twee dimensies. De eerste dimensie is de dimensie van de grid, het aantal kolommen en rijen. De tweede dimensie is zijn de afmetingen van een enkele entry in de grid. De grid wordt met een vooraf ingestelde threshold berekend. De threshold stelt een aangename kolom breedte voor. Deze threshold wordt uit de settings gehaald. 2

110 Design Document Sprint TEMPLATES Het concept rond om templates is erg belangrijk voor de functionaliteit van. Dit is gebaseerd op het vooronderzoek van. Er zijn twee modules in de control betreffende het template concept. De eerste module is de statictemplates, deze module bevat de statisch gedefinieerde templates. De tweede module is de templates module. Deze module bevat de logica betreffende het bepalen van het juiste template bij de juiste data. Deze positioneert ook de artikelen binnen het template MODULE STATICTEMPLATES StaticTemplates bevat een statische definitie van verschillende soorten templates. Zowel templates van artikelen als schermen zijn in de module gedefinieerd. Er is een verschil tussen de templates die statisch gedefinieerd zijn en de templates welke gerouleerd worden tijdens de runtime van het programma. In bijlage C is een UML diagram te zien hoe de templates voor en tijdens de runtime van de client verschillen van elkaar. Bij het initialiseren van de client worden de pre-initialised templates geconverteerd naar post-initialised templates. De static templates verschillen van structuur voor en na de initialisatie. Dit heeft als reden dat de static templates gedefinieerd worden op een recursieve manier. Schermtemplates kunnen bestaan uit artikeltemplates of schermtemplates of een combinatie van beide. Een recursie is zeer gewenst voor het handmatige onderhoud aan de statische templates. De recursie wordt uit de schermtemplates verwijderd om de verwerkingssnelheid tijdens de runtime van de client applicatie te optimaliseren. Een screentemplate bestaat voor de initialisatie uit een dimensie, een lijst met gepositioneerde artikeltemplates en een lijst met gepositioneerde screentemplates. Dit is te zien in bijlage C in het gedeelte Pre-initialised Static Templates. Een gepositioneerde artikeltemplate is een coördinaat in combinatie met een dimensie. Een gepositioneerde screentemplate is een screentemplate met een coördinaat. Een scherm is op deze manier opgebouwd uit kleinere schermen of artikelen. In de conversie worden recursieve screentemplates omgezet naar platte niet-recursieve schermtemplates, genaamd flattened screentemplates. Deze zijn te vinden in bijlage C in het gedeelte Post-initialised Static Templates. Een flattened screentemplate bestaat alleen nog uit artikelen en hun coördinaat, de plek op het scherm. De artikeltemplates kunnen opgevraagd worden met de getarticledimension methode. Deze krijgt artikeldata gespecificeerd volgens bijlage B binnen en berekend welke artikeltemplates mogelijk zijn met deze data. Een lijst met dimensies (de artikeltemplates) worden geretourneerd. De screentemplates worden opgevraagd door de dimensie van de grid mee te sturen. Wanneer er geen screentemplates van dezelfde maat als de grid beschikbaar zijn worden de grootst passende templates doorgestuurd. 3

111 Design Document Sprint MODULE TEMPLATES De templates module bevat de logica over templates. Hier worden de ontvangen artikelen en hun data gecombineerd met een best passende screentemplate. Deze heeft als verantwoordelijkheid gepositioneerde artikelen af te leveren. Het algoritme om de artikelen te matchen aan een schermtemplate werkt als volgt. De gesorteerde templates worden vergeleken met de te plaatsen artikelen. Het grootste template wordt vergeleken met het grootste mogelijke artikel waarna direct kan worden bepaald of de template kan worden gevult. De artikelen en templates zijn gesorteerd van groot naar klein waardoor zo vroeg mogelijk kan worden bepaald of het schermtemplate gaat passen. BIJLAGEN A. UML CLIENT 4

112 Design Document Sprint 1 B. UML POSITIONED ARTICLE C. UML TEMPLATES 5

113 Design Document Sprint 2 D E S I G N D O C U M E N T SPRIN T 2 Dit document dient ter rapportage van de toegevoegde technische onderdelen van in de tweede sprint. In dit document worden de technische beslissingen uit de tweede sprint uitgewerkt. SAMENVATTING Een artikel wordt afhankelijk van de soort en hoeveelheid beschikbare data op een vooraf bepaalde manier op het scherm gevisualiseerd. Deze manieren verschillen van een tekstuele weergave tot een diashow. Een screentemplate bevat een lijst, de mogelijkheden, met daarin gepositioneerde artikel- en schermtemplates. Dit wordt bij initialisatie verwerkt tot een flattenedscreentemplate, welke alleen nog maar gepositioneerde artikeltemplates bevat. Bij het klikken op de link onder een artikel wordt de detailweergave van het artikel geopend in een popup. Een popup wordt geopend door een event handler op de eerder genoemde link. Hierbij wordt gebruik gemaakt van de create methode van de popup module binnen de client. Een dummy dom is toegevoegd om bepaalde afmetingen van de te renderen data te berekenen voordat deze informatie op het scherm getoond wordt. 1. ARTICLE VIEW TEMPLATES Een nieuw concept voor het renderen van artikelen zijn de artikel view templates. Dit zijn geen statische templates, maar dynamische modules welke ieder op een andere manier data van een artikel visualiseert. Het idee is dat er rond de 5 templates komen. Het grootste onderscheid tussen de templates zijn het aantal en de grootte van de meegeleverde afbeeldingen. Geen afbeelding zal een template aanroepen welke tekst kan weergeven. Zo heb je ook templates met een kleine afbeelding, een grote afbeelding, heel veel afbeeldingen, of een combinatie van tekst en afbeeldingen. Dit concept is het leven in geroepen om een duidelijke scheiding te maken tussen de verschillende manieren van visualiseren per artikel. Er zijn een aantal templates, welke afhankelijk van de data mogelijk gebruikt kunnen worden. Wanneer meerdere templates mogelijk zijn wordt het meest visuele template gebruikt. In de tweede sprint wordt alleen de tekstuele en misschien de tekstuele met een enkele afbeelding geïmplementeerd. De template welke een enkele afbeelding met tekst genereert heet de textpicture viewtemplate. Deze module schaalt de afbeelding tot de breedte van de kolom. De afbeelding wordt willekeurig in een hoek van het artikel geplaatst. Een tekstkolom met de overige hoogte van het artikel wordt boven of onder de afbeelding geplaatst. 1

114 Design Document Sprint 2 2. STATIC SCREENTEMPLATES In design document 1 van is een opzet gemaakt van de statische artikel- en screentemplate. Een artikeltemplate bestaat uit een dimensie, een screentemplate uit artikel- of screentemplates op een bepaalde positie. De artikeltemplates zijn ongewijzigd gebleven, de screentemplates zijn verandert zodat ze beschikken over verschillende mogelijkheden. Een mogelijkheid voor een screentemplate is een verzameling van gepositioneerde artikel- of screentemplates. Het toevoegen van verschillende mogelijkheden voor iedere screentemplate levert een aantal extra moeilijkheden op bij de conversie naar geflatteerde templates. In bijlage C is de structuur van de templates voor en na de initialisatie weergeven. Een screentemplate bevat een lijst, de mogelijkheden, met daarin gepositioneerde artikel- en schermtemplates. Na de initialisatie zijn al deze mogelijkheden uitgewerkt tot screentemplates. Een screentemplate is dan geconverteerd naar een flattenedscreentemplate, welke alleen nog maar gepositioneerde artikeltemplates bevat. De screentemplates groeien exponentieel bij de conversie. Een cache mogelijkheid voor de conversie is gewenst en komt misschien ineen latere versie. 3. POPUPS In deze sprint is de functionaliteit van popups toegevoegd aan de client. De detailweergave van een artikel wordt weergeven in een popup. Een popup kan worden aangemaakt door de create methode van de popup module binnen de client aan te roepen. Deze geeft een popup instantie terug. De details API van de popup instantie is te vinden in bijlage B. Deze popup is al gecreëerd en aangemaakt in de DOM van de browser maar nog verborgen voor de gebruiker van. De popup wordt weergeven, geopend, wanneer de open functie wordt aangeroepen. Het creeren en openen gebeurt beide in de onclick handler van een lees meer knop bij een artikel. 4. DUMMY DOM Een dummy DOM is toegevoegd aan de view modules. Het concept achter de dummy DOM is dat elementen daarin gecreëerd kunnen worden en vervolgens informatie zoals grootte over de weergave van de elementen gebruikt kan worden voor het bepalen van de uiteindelijke weergave op het scherm. We werken met variabele informatie, denk aan stukken tekst, waar de grootte van de weergave niet van te voren te berekenen is. Deze afmetingen worden berekend in de dummy DOM voor de definitieve weergave. De dummy DOM is niet zichtbaar voor de gebruiker. De dummy DOM module kan een stukje ruimte in de dummy DOM reserveren met behulp van de create methode. Deze geeft een dummydom instantie terug, de structuur van dit element is te zien in bijlage D. Het gereserveerde DOM element in de dummy DOM kan worden opgehaald en worden vernietigd. 2

115 Design Document Sprint 2 BIJLAGEN A. UML CLIENT 3

116 Design Document Sprint 2 B. UML POPUP C. UML TEMPLATES 4

117 Design Document Sprint 2 D. UML DUMMY DOM 5

118 Design Document Sprint 3 D E S I G N D O C U M E N T SPRIN T 3 Dit document dient ter rapportage van de toegevoegde technische onderdelen van in de derde sprint. In dit document worden de technische beslissingen uit de derde sprint uitgewerkt. SAMENVATTING Aan de hand van verschillende Reader klassen worden RSS en Outpost streams uitgelezen en terug gegeven als lijsten met artikelen. De stream handler combineerd deze streams en geeft de beschikking over een enkele lijst met de gevraagde artikelen. De website reader kan aangevraagd worden met een link naar een website, deze website wordt vervolgens met behulp van externe API s uitgelezen en verwerkt tot een artikel. De website reader wordt gebruikt als een artikel uit bijvoorbeeld een RSS feed kort is en een link naar een website bevat. Een optimaal algoritme voor de beste keuze van een schermtemplate is gebaseerd op de volgende drie criteria: belangrijkheid van het artikel, de plaats van het artikel en hoe goed het artikel in de gegeven ruimte past. Een manager is toegevoegd aan de client om het inladen van artikelen te regelen en berichten binnen een ingestelde tijdspan te laden. Bij het klikken op de bron rechtsonder in een detailweergave wordt, zodat de gebruiker verder kan lezen, de bijbehorende website geopend in een popup. 1. SERVER STRUCTUUR Bij het maken van de server is ervoor gekozen om een handler te maken die de request van de client afhandeld. Deze handler bezit een StreamReader die voor een gegeven source de bijbehorende artikelen terug geeft. De StreamReader heeft dan weer de beschikking over een RssReader welke een RSS uitleest en een OutpostReader welke informatie uit de outpost database haalt. De beide readers kunnen via de StreamReader gebruik maken van de WebsiteReader. De WebsiteReader leest gegeven een url de bijbehorende website uit. Aan de WebsiteReader kan vervolgens de inhoud van deze website in de vorm van een artikel opgevraagd worden. 1.1 STREAM READER De StreamReader geeft de mogelijkheid om een bepaalde stream uit te lezen en terug te geven in de vorm van een lijst met artikelen. De StreamReader moet aangeroepen worden met een bron, een typeindicator, een tijdvak en een limiet. Vervolgens word een lijst met artikelen uit de betreffende bron met het gegeven type, binnenhet tijdsbestek en met maximaal het limiet aan artikelen terug gegeven. 1

119 Design Document Sprint 3 RSS READER De RSS Reader is in het leven geroepen om RSS feeds uit te kunnen lezen en de inhoud terug te geven in een lijst met artikelen. Bij het uitlezen van de RSS feeds wordt zoals in het vooronderzoek besproken is rekening gehouden met de RSS 2.0 standaard. Wanneer deze artikelen te klein zijn wordt met behulp van de hieronder besproken websitereader de content uit de bron opgehaald. De streamreader conbineert deze informatie tot een goed artikel wat mogelijk wel op het scherm kan worden weergegeven. OUTPOST READER De OutpostReader leest artikelen uit de database van Outpost. De artikelen worden uitgelezen door meerdere tabellen uit de outpost database te combineren en hier vervolgens de auteur en de inhoud van het bericht uit te halen. Voor het uitlezen van de database worden meerdere standaard binnen PHP beschikbare mysql functionaliteiten gebruikt. De door de database teruggegeven informatie wordt vervolgens verwerkt tot het door gebruikte Artikel formaat en in een array terug gegeven. Om de juiste gegevens uit de database te halen heeft de OutpostReader een aantal invoergegevens nodig; het tijdsbestek, het limiet en het id van de persoon waarvan de berichten opgehaald moeten worden. In de toekomst moet de OutpostReader uitgebreid worden met het uitlezen van aan berichten toegevoegde foto s. Verder moet de OutpostReader in de toekomst artikelen van andere Outpost streams zoals groepen uit kunnen lezen. WEBSITE READER De WebsiteReader geeft de mogelijkheid om de relevante informatie uit een website uit te lezen en deze informatie te verwerken tot een artikel. De relevante informatie wordt met behulp van Readability uit een website gehaald. Readability is een externe partij welke een API biedt waarmee webpagina s geanalyseerd kunnen worden. De Readability API is vrij te gebruiken, echter moet bij werkelijk commercieel uitgezocht worden of de limitaties welke Readability wat betreft aanvragen per tijdseenheid oplegd een probleem gaan vormen. Als deze limitaties een probleem vormen zal een oplossing gevonden moeten worden, mogelijk het aanschaffen van licenties bij Readability. Bij het integreren van Readability is gebruik gemaakt van de Kanedo API. Deze API zorgt voor de authenticatie met Readability. Ook zijn de functionaliteiten van de Readability API via Kanedo gemakkelijk te gebruiken. De belangrijkste reden om Kanedo te gebruiken is de Oauth authenticatie, dit bleek moeilijk zonder externe hulp te realiseren. Naast het uitlezen van websites zorgt de WebsiteReader ervoor dat de gelezen websites verwerkt worden tot het door gebruikte Artikel formaat. Hiervoor moeten foto s uit de door Readability gegeven inhoud gehaald worden. Om de foto s uit de inhoud te halen wordt gebruik gemaakt van een onder de MIT Licence vrijgegeven library simple_html_dom welke de mogelijkheid biedt om html tags binnen een stuk tekst te vinden. Met behulp van deze library worden alle afbeeldingen gezocht, verwerkt en opgeslagen in een array met foto s. Als laatste worden de foto s verwijderd uit de invoer tekst. De lijst met foto s wordt vervolgens toegevoegd aan het artikel zodat hier gebruik van kan maken. 2

120 Design Document Sprint 3 2. ARTICLE MANAGER De manager van op de client regelt het tonen van artikelen. Deze module haalt artikelen op van de server, beheerd een artikelstack en stuurt de artikelen naar de view voor weergave. De manager onthoudt welke artikelen op het scherm staan, welke er stonden en welke nog weergeven moeten worden. Ook beheert deze module de tijdspan waarin de artikelen zich moeten bevinden. Deze module haalt automatisch berichten op wanneer dat nodig is. 3. OPTIMAAL ALGORITME SCHERMTEMPLATE KEUZE Het algoritme welke artikelen in het scherm positioneert is momenteel een greedy algoritme en niet optimaal. In dit document wordt nader uitgelegd hoe het optimale algoritme, voor de matching van artikelen aan templates, moet gaan werken. Allereerst worden verschillende criteria voorgesteld. Het oude greedy algoritme wordt omschreven. Daarna worden de criteria uitgewerkt om vervolgens een plan te concluderen voor het omschrijven naar het optimale algoritme. OUDE ALGORITME Het bestaande algoritme lost het probleem op een greedy manier op. Er zijn nog geen waarden aan posities op het scherm gekoppeld. Ook hebben de artikelen nog geen waarde toegekend gekregen. De schermtemplates zijn op belangrijkheid gedefinieerd en worden één voor één doorlopen. Daarbij wordt gekeken op de meegegeven artikelen passen in de schermtemplate. Wanneer de artikelen passen wordt de schermtemplate gebruikt. In het optimale algoritme moet de schermtemplate met de beste matching van artikelen gebruikt worden. CRITERIA Er zijn drie onderdelen binnen het matching probleem welke verschillende waarden omvatten voor de match. Een combinatie van deze onderdelen zal de waarde van een matching bepalen. De onderdelen zijn de volgende: 1. Waarde van het artikel 2. Hoe goed het artikel in de gegeven ruimte past 3. Waar het artikel op het scherm is geplaatst 1. WAARDE VAN HET ARTIKEL Een artikel heeft een bepaalde waarde. Artikelen kunnen zo onderling op hun waarde gesorteerd worden. De waarde van een artikel kan op veschillende interne en externe factoren gebaseerd zijn. Voorbeelden van interne factoren is de lengte van de inhoud en het aantal meegeleverde afbeeldingen van een artikel. Een voorbeeld van een externe factor is de afkomst, denk aan Twitter berichten boven rss berichten. In deze sprint genereren we de waarde van berichten willekeurig. De artikelen krijgen allemaal willekeurig een waarde tussen 0 en 1, waarbij 1 belangrijker is dan 0. 3

121 Design Document Sprint 3 2. HOE GOED HET ARTIKEL IN DE GEGEVEN RUIMTE PAST Deze waarde is gebaseerd op de artikeldata. Artikeltemplates worden aan artikeldata gekoppeld. In het oude algoritme worden de artikeltemplates welkemet de artikeldata gevuld kunnen worden aan de artikeldata gekoppeld. Hier moet een waarde gecreerd worden, deze waarde representeert hoe goed het artikel in het artikeltemplate past. Hierbij hebben artikelen welke met afbeeldingen weergeven kunnen worden een hogere waarde dan artikelen met alleen tekst. Deze waarde moet tussen 0 en 1 liggen. 3. WAAR HET ARTIKEL OP HET SCHERM IS GEPLAATST De geflatteerde schermtemplates beschikken over gepositioneerde artikeltemplates. Deze artikeltemplates moeten onderling waarden krijgen om belangrijkere plekken te identificeren. Dit geschiedt middels een conversie functie welke volgens de theorieën van het onderzoeksrapport berekend welke plaatsen hoger zijn dan andere plaatsen. De F methodiek in combinatie met de leesdiagonaal (van linksboven naar rechtsonder) zullen de waarde bepalen. Een voorbeeld: een schermtemplate van tien gepositioneerde artikeltemplates zal waarden van 1 tot en met 10 aan een artikeltemplate toekennen. Ieder artikeltemplate heeft een unieke waarde voor het desbetreffende schermtemplate. Een hogere waarde heeft een belangrijkere positie op het scherm. Uiteindelijk moeten alle waarden tussen 0 en 1 liggen. Hiervoor wordt de waarde geschaald, 1 wordt 0 en 10 wordt 1. COMBINATIE VAN CRITERIA Ieder criterium heeft een gelijke waardespan, namelijk tussen 0 en 1. We geven ieder criterium een constante invloedsfactor welke de belangrijkheid van het criterium bepaald. Zo kunnen de criteria onderling van invloed verschillen. Noem de waarden van de criteria per artikel w 1a, w 2a en w 3a (met a als artikelnummer), de invloedsfactoren van de criteria c 1, c 2 en c 3 en n voor het aantal artikelen dan krijgen we de volgende formule om de waarde van een artikel/schermtemplate match te vinden: 4. WEBSITE POPUPS In deze sprint is een nieuwe soort popup toegevoegd, de website popup. Het is de bedoeling dat als ergens binnen op een weblink geklikt wordt, deze website in een popup geopend word. Momenteel geldt enkel voor de link rechtsonder in de detailweergave van een artikel dat de bestreffende website in een popup geopend word. De website popup is een uitbreiding op de bestaande popup. De aanroep van de popup is nu nog statisch, in de volgende sprint zal dit een object worden. Bij het openen van een website popup wordt url.openpopup(url, title) aangeroepen. Deze functie zal vervolgens de bestaande popup functie aanroepen met daarin een iframe welke de website bevat. De iframe waarin de website wordt geopend wordt sandbox modus geinitialiseerd. Hierdoor is het voor de website binnen de iframe niet mogelijk om mogelijk voor gevaarlijke scripts uit te voeren. 4

122 Design Document Sprint 3 BIJLAGEN A. UML SERVER 5

123 Design Document Sprint 3 B. UML CLIENT 6

124 Design Document Sprint 4 D E S I G N D O C U M E N T SPRIN T 4 Dit document dient ter rapportage van de toegevoegde technische onderdelen van in de vierde sprint. In dit document worden de technische beslissingen uit de vierde sprint uitgewerkt. SAMENVATTING De structuur van de client is veranderd en daarmee inzichtelijker gemaakt. Modules kunnen met behulp van statische aanroepen gecreëerd worden. Er worden dus instanties aangemaakt en beheerd en bijna geen statische functies meer aangeroepen. De uitzonderingen zijn de aanroepen naar de utils module en de aanroepen naar de statische templates. Een UML diagram is gemaakt welke een goed overzicht geeft van de afhankelijkheden tussen de verschillende module instanties. Een instantie kan nu aangemaakt worden door een manager te creëren. Deze manager heeft een hoge verantwoordelijkheid doordat deze veel onderdelen van het programma aanmaakt en beheerd. De applicatie module welke beheerd wordt door de manager communiceert met de DOM van de browser en is daarom verantwoordelijk voor de visualisatie van. Vanwege tijdsrestricties is gekozen om artikelen in een database op te slaan en de client artikelen uit de database te laten halen. De verantwoordelijkheden van de server zijn hierdoor opgedeeld in twee delen. Het eerste deel wordt automatisch om een vooraf gedefinieerd tijdsinterval aangeroepen, haalt de feeds op en slaat de artikelen op in een database. Het tweede deel wordt aangeroepen door de client en haalt de gevraagde artikelen uit de database. 1. REFACTOREN VAN DE CLIENT De code van de client van is in de vierde sprint structureel veranderd. De code was geschreven met behulp van het module pattern in Javascript (Design document 1). Er zijn wat verbeteringen ten opzichte van deze module pattern. Een module zou er als volgt uit moeten zien: name = (function () { // Private static var a; // Public static return { create: function () { // Private var b; // Public return { methode: pmethode }; } }; }()); 1

125 Design Document Sprint 4 Een instantie van een module kan dan aangemaakt en beheerd worden. Zo worden alle afhankelijkheden van modules onderling goed zichtbaar en kunnen verantwoordelijkheden beter bepaald worden. Met deze verbeteringen als basis zijn twee nieuwe UML diagrammen geproduceerd; De statische client en de relaties van de client. 2. CLIENT STATISCH Het verschil tussen statische objecten en instanties is duidelijk gemaakt in twee verschillende UML diagramman. Het eerste diagram is een overzicht van de statische JSON objecten in de client van, welke te vinden is in bijlage A. Het tweede diagram geeft de afhankelijkheden van verschillende instanties weer, dit wordt verder besproken in hoofdstuk 3. In dit hoofdstuk wordt het statische gedeelte uitgelegd. Het globals JSON object is volledig verdwenen. De window en document objecten worden bij het initialiseren van het programma meegegeven. Het window object wordt alleen gebruikt om de schermafmetingen te verkrijgen en de initialisatie van aan te roepen wanneer de browser klaar is met laden. Het document object wordt meegegeven aan de application klasse in de view. De application klasse maakt een document wrapper aan welke door alle view klassen gebruikt wordt. Naast alle statische objecten, welke instanties van klassen kunnen creëren, zijn er ook klassen welke statisch zijn en continue aangeroepen worden zoals Utils en templatesdefinition. Utils is een soort wrapper van handige methodes in jquery samen met handige functies die we zelf bedenken en maken. templatesdefinition is een statische module welke alle artikeltemplates en schermtemplates terug kan geven. Deze templates zijn statisch en kunnen dus overal in het programma opgevraagd worden. 3. COMMUNICATIE BINNEN DE CLIENT Het UML diagram client interaction geeft een overzicht van de communicatie tussen de modules van de client. Duidelijk is wie welke modules beheert en wie met wie communiceert. Tijdens het maken van het UML diagram zijn verschillende communicatiefouten er uit gehaald. De modules date en timespans zijn toegevoegd tijdens deze sprint. Deze modules regelen dat er logische tijdsblokken zijn waartussen genavigeerd kan worden. De module date fungeert als een wrapper om de javascript date. De date module zorgt ervoor dat er met behulp van logische functies over een date kan worden gerdeneeerd. Daarnaast biedt date de mogelijkheid om de date in het juiste formaat op te kunnen vragen voor de server. De module timespans wordt gebruikt om tijdsblokken op te bouwen waartussen kan worden geschoven. Daartoe worden de functies uit date gebruikt om op een logsiche wijze verschillende tijdsblokken op te bouwen. Bij het aanroepen van de module worden de tijdsblokken gemaakt, deze blokken redeneren vanaf het moment van aanroepen. 2

126 Design Document Sprint 4 4. SERVER Doordat het real-time ophalen van feeds uit websites aanzienlijk veel tijd in neemt, is besloten om artikelen uit toegevoegde streams in een database op te slaan. Het gevolg van deze beslissing is dat het server-deel van voortaan uit twee delen zal bestaan. Het eerste deel zal de gewenste artikelen uit de database halen en deze artikelen terug geven aan client. Het tweede deel zal alle artikelen van de gewenste feeds ophalen en opslaan in de database. De structuur van de beiden server delen zijn weergegeven in de UML diagrammen in de bijlage (Bijlage C, D). De structuur van de database is gegeven in bijlage E. 4.1 SERVER (OPHALEN UIT DATABASE) Om berichten in weer te geven zullen deze berichten eerst ergens opgehaald moeten worden. Omdat besloten is de berichten op te slaan in een database moeten de berichten uit de database gehaald worden. Om berichten uit de database te halen kan de client een PHP bestand aanroepen, waarbij een aantal gegevens meegegeven moeten worden: Een tijdsbestek, een aantal berichten vanaf een startaantal en uit welke streamset de berichten opgehaald moeten worden. Het meegegeven streamset kan in de toekomst door de gebruiker gekozen worden en bevat een aantal vooraf gedefinieerde feeds. Er is gekozen voor streamsets zodat de gebruiker hier tussen kan wisselen en in de toekomst mogelijk meerdere gebruikers met eigen streamsets toegevoegd kunnen worden. Na het aanroepen geeft het PHP bestand een JSON object terug. In dit JSON object staan alle opgevraagde berichten. Het PHP bestand heeft de database aangesproken en uit alle feeds binnen de gegeven streamset de artikelen binnen het gegeven tijdsbestek opgehaald. Deze artikelen worden vervolgens gesorteerd op datum en uit deze set worden het gevraagde aantal artikelen vanaf het gegeven startaantal gehaald. Uiteindelijk worden de artikelen als JSON object gecodeerd en terug gegeven aan de client. 4.2 SERVER (OPSLAAN IN DATABASE) Dit deel van de server haalt eerst uit de database welke feeds door gebruikers gelezen worden. Van iedere feed wordt vervolgens de RSS uitgelezen, per bericht wordt bekeken of deze genoeg tekens bevat. Als het bericht genoeg tekens bevat wordt deze opgeslagen in de database. Als het bericht niet genoeg tekens bevat wordt met behulp van Readability de bij het bericht behorende website uitgelezen en opgeslagen in de database. Er is gekozen om bij te korte RSS berichten de data uit de bijbehorende website te halen omdat hierdoor meer informatie weergeven zal worden, en het overzicht binnen hierdoor vollediger wordt. Voordat de berichten in de database opgeslagen worden, wordt de inhoud opgeschoont. De opgeslagen berichten bevatten uiteindelijk geen onnodige HTML tags, of JavaScript code. De berichten worden opgeschoond omdat HTML tags de layout binnen onbedoeld kunnen veranderen, een andere reden is dat aanwezige JavaScript code gevaarlijk zou kunnen zijn voor de gebruiker van, aanwezige JavaScript kan zelfs opgeslagen wachtwoorden van andere websites achterhalen en doorsturen. Gedetailleerde uitleg over de werking van het ophalen van artikelen door de server is gegeven in Design Document 3. 3

127 Design Document Sprint 4 BIJLAGEN A. UML CLIENT STATISCH 4

128 Design Document Sprint 4 B. UML CLIENT INTERACTION 5

129 Design Document Sprint 4 C. UML SERVER (OPSLAAN IN DATABASE) 6

130 Design Document Sprint 4 D. SERVER (OPHALEN UIT DATABASE) 7

131 Design Document Sprint 4 E. DATABASE STRUCTUUR 8

132 Design Document Sprint 5 D E S I G N D O C U M E N T SPRIN T 5 Dit document dient ter rapportage van de toegevoegde technische onderdelen van in de vijfde sprint. In dit document worden de technische beslissingen uit de vijfde sprint uitgewerkt. SAMENVATTING Paginering is in twee delen opgesplitst, het switchen tussen tijdsblokken en het switchen tussen pagina s binnen een tijdsblok. De knoppen worden beheerd in modules binnen de footer. De logica van het navigeren zit in de manager. Een bug in de overview dat onclickhandlers niet werkte van url s is opgelost. Met een timeout van nul seconden kan de browser zijn andere taken voltooien waardoor het wel werkt. Daarnaast worden foto s groter op het scherm getoond, er wordt willekeurig bepaald of een foto groter of kleiner op het scherm wordt gezet. Outpost is geintegreerd, hierover is overlegd met een werknemer van Moxio en is besloten dat iedere feed in de database opgeslagen gaat worden. Hierdoor hoeft geen onderscheid tussen feeds gemaakt te worden en zal het best onderhoudbaar zijn. Als laatste is een aanpassing doorgevoerd bij het berekenen van de lengte van een artikel. Dit wordt voortaan op de server gedaan en opgeslagen in de database. 1. PAGINERING Er kan op twee niveaus door het programma heen worden genavigeerd. De eerste is door de verschillende tijdsblokken, bijvoorbeeld vandaag en gisteren. Als tweede kan er door de tijdsblokken zelf worden genavigeerd. De berichten binnen een tijdsblok zijn zowel op tijd als op belangrijkheid gesorteerd, de berichten zijn binnen een tijdsblok dus niet op tijd gesorteerd. De knoppen om te schakelen zijn in twee verschillende modules thuisgebracht. Beide modules worden beheerd door de footer. Deze zijn op te vragen met de methoden getpagination en gettimepagination. De manager beheert de logica achter het schakelen tussen pagina s. Deze roept de modules aan welke de knoppen kan renderen. 1

133 Design Document Sprint 5 2. LINKS NAAR IFRAMEPOPUP Er was een bug aanwezig welke onclick handlers in de overview niet wilde vuren. Dit is momenteel opgelost door een timeout van nul seconden in te stellen en daarna de onclick handler pas te koppelen aan het linkje. De reden hierachter is dat de browser verschillende taken tegelijk moet uitvoeren, waarvan Javascript er een is. Deze taken worden niet helemaal synchroon uitgevoerd. Op deze manier geef je de browser de tijd zijn andere taken te laten bijlopen. Dit probleem is uitgelegd op Stackoverflow KEY HANDLERS Er zijn verschillende shortcuts in het programma toegevoegd. Je kunt nu met Ctrl + de linker en rechter pijltjes navigeren door tijdsblokken en zonder Ctrl met het rechter en linker pijltje tussen pagina s navigeren. Ook de popup kan worden gesloten met de escape toets. De bovenste popup blokkeert de voorheen aangemaakte instanties welke naar de toetsen luisterde. Zo kunnen de elementen onder de popup niet bestuurd worden met de toetsen wanneer de popup open staat. 4. UPDATE FOTOAFHANDELING Om grotere foto s te kunnen afhandelen moet de view informatie krijgen over het aantal tiles waar de foto in zou kunnen worden gerenderd. Daarom wordt deze informatie tijdens het berekenen van de imagetiles toegevoegd aan de data van de image. Aan de hand van deze informatie wordt bij het renderen van een artikel met foto willekeurig bepaald hoeveel kollommen deze foto zal innemen. 5. OUTPOST INTEGRATIE Om outpost berichten binnen te kunnen gebruiken is in overleg met een werknemer van Moxio besloten deze net als de RSS feeds in de database op te slaan. Reden hiervoor is dat Alle verschillende typen feeds, waaronder Outpost, nu vanuit de client als gelijk beschouwd kunnen worden. De client hoeft hierdoor geen onderscheid te kunnen maken tussen feeds, waardoor deze simpelweg aan de server een aantal berichten binnen een tijdspan kan vragen. Doordat de clinet gelijk blijft hoeft bij het veranderen van de structuur of inhoud van een feed slechts de klasse aangepast te worden welke deze berichten inleest en doorgeeft aan de database klasse. Hierdoor zal goed onderhoudbaar blijven. De berichten uit Outpost worden net als andere feeds periodiek in de database opgeslagen. Er kan gekozen worden op verschillende manieren een outpost feed te kiezen, bijvoorbeeld op gebruikersnaam of op groep naam. Bij een Outpost bericht worden naast het bericht zelf ook de comments op dat bericht opgehaald, deze worden uiteindelijk binnen weergeven

134 Design Document Sprint 5 6. ARTIKEL LENGTE Voorheen werd de lengte van een artikel op de client berekend, dit bleek vanwege HTML tags en een groot aantal spaties, tabs en line breaks niet voldoende te werken. Het is afgewogen om dit probleem op te lossen door op de server de spaties en tabs te verwijderen en op de client te lengte zonder de HTML tags te berekenen. Uiteindelijk is gekozen om dit probleem geheel op de server op te lossen. De database is aangepast en bij de artikelen is een extra waarde content_length toegevoegd. Op de server wordt de lengte van het artikel zonder witruimten en HTML tags berekend, deze lengte wordt vervolgens opgeslagen in de database. De client kan vervolgens de lengte van een artikel in de database uitlezen en gebruiken bij berekeningen. 3

135 Design Document Sprint 5 BIJLAGEN A. UML CLIENT INTERACTION 4

136 Design Document Sprint 5 B. DATABASE DIAGRAM 5

137 Design Document Sprint 5 C. UML SERVER OPHALEN 6

138 Design Document Sprint 5 D. UML SERVER OPSLAAN IN DATABASE 7

139 Design Document Sprint 5 E. UML CLIENT ARTICLES 8

140 Design Document Sprint 6 D E S I G N D O C U M E N T SPRIN T 6 Dit document dient ter rapportage van de toegevoegde technische onderdelen van in de zesde sprint. In dit document worden de technische beslissingen uit de zesde sprint uitgewerkt. SAMENVATTING Vanwege de lange looptijd van het server deel, dat nieuwe berichten uit feeds uitleest, websites ophaalt en deze opslaat in de database is dit algoritme opgesplitst in twee delen; De Stream Reader en een Readability Reader. Het algoritme waarmee artikelen aan plekken van een schermtemplate gekoppeld werden is geoptimaliseerd. Het algoritme is van O( ) teruggedrongen naar O( ) = O( ). De berekening in de geneste loop wordt nu ongeveer keer aangeroepen in plaats van De optimalisatie is gehaald door de binnenste twee loops te verplaatsen buiten de geneste loops. De locaties van afbeeldingen in het overzicht worden middels een hash van de inhoud semiwillekeurig op een bepaalde positie binnen het artikel geplaatst. Kleine afbeeldingen worden geschaald naar een vaste waarde relatief ten opzichte van de kolombreedte. Kleine berichten met een link naar een artikel worden - indien mogelijk - vervangen door de inhoud van het artikel waar naar verwezen wordt. Van iedere bron wordt bij het toevoegen het bijbehorende icoon en de titel opgehaald en opgeslagen in de database. De client weergeeft deze iconen en titels vervolgens in de artikelen. 1. OPSPLITSING CRON HANDLER Doordat de cron handler in het verleden direct de websites ophaalde met Readability duurde het lang voordat dit script uitgevoerd was. Vooralsnog heeft deze lange uitvoertijd geen problemen opgeleverd, dit kan echter in de toekomst leiden tot missende of dubbele berichten in de database. Vanwege dit probleem is besloten dat de Cron Handler opgesplitst moest worden in een Stream Reader en een Readability Reader. De Stream Reader haalt berichten uit de stream en haalt niet de website op. In plaats van de website maakt de Stream Reader alvast een bookmark aan bij Readability en slaat de bookmark id s op. De Readability Reader wordt vervolgens in een andere cron aangeroepen en loopt chronologisch van nieuw tot oud door de bookmarks. Deze bookmarks worden opgehaald bij Readability, de inhoud van deze artikelen word vervangen met de nieuwe opgehaalde inhoud. De UML diagrammen behorende tot de cron handler zijn gegeven in bijlagen A tot en met C. Bijlage A geeft de structuur van de database. Bijlage B geeft de structuur van het server deel dat de feeds uitleest, en bijlage C geeft de structuur van de Readability Reader. 1

141 Design Document Sprint 6 2. OPTIMALE ALGORITME Het algoritme waarin artikelen gekoppeld worden aan posities op een schermtemplate, waarna het beste schermtemplate gekozen wordt is geoptimaliseerd. Dit algoritme bestond uit de volgende vier loops: For each schermtemplates For each gepositioneerde artikeltemplate in schermtemplate For each artikelen For each dimension in artikel Bereken de match waarde van het artikel met het artikeltemplate De invoergrootte van de gegeven variabelen zijn: Variabele Minimale grootte van de collectie Maximale grootte van de collectie schermtemplates gepositioneerde artikeltemplate in 1 18 schermtemplate artikelen dimension in artikel 1 9 De tijdscomplexiteit van dit algoritme is met n als invoergrootte. De tijdscomplexiteit is polynomiaal begrensd, maar niet erg efficiënt. In een worst case geval volgens de voorgaande benaderde gegevens de ingesloten berekening bijna keer uitgevoerd worden. Door de 4 loops op te splitsen in twee geneste loops die achter elkaar worden uitgevoerd is veel snelheidswinst gehaald. Theoretisch zou in de worst case situatie ongeveer 2000 keer de eerste twee loops doorgelopen worden en de tweede ongeveer 100 keer. De binnenste twee loops berekenden gegeven een dimensie van het artikeltemplate het beste artikel. Dit wordt berekend met de waarde van het artikel en de waarde hoe past het artikel in de gegeven dimensie. Deze functionaliteit is uit de geneste loops gehaald waardoor er vooraf per dimensie een gesorteerde lijst met artikelen wordt opgebouwd. In de geneste loops kan dan in O(1) (constante tijd) het beste artikel voor de gegeven dimensie opvragen. Het algoritme heeft nu een tijdscomplexiteit van O( ). 3. HASH GEBRUIK Door het gebruik van een hash om de locatie van een foto te bepalen wordt gezorgd dat de layout van streampaper niet veranderd als er tussen pagina s wordt genavigeerd. De plaatsing van foto s is hierdoor verschillend voor artikelen maar zal voor een artikel niet veranderen. De volledig willekeurige plaatsing van de afbeeldingen is vervangen voor een semiwillekeurige plaatsing middels een hash van de artikelinhoud. 2

142 Design Document Sprint 6 4. GEBRUIK KLEINE FOTO S Op verzoek is de keuze gemaakt om ook kleine afbeeldingen te tonen in de overview. Kleine afbeeldingen zijn gedefinieerd als afbeeldingen waarvan de breedte kleiner is dan de breedte van een kolom. De kleine afbeeldingen worden opgeschaald naar een vaste waarde relatief ten opzichten van de kolombreedte. Op het moment van schrijven is deze waarde ingesteld als van de kolombreedte. De kleine afbeeldingen worden opgeschaald zodat de tekst goed om de afbeelding heen kan worden geplaatst. Naast het tonen van afbeeldingen in de overview moeten deze ook in de popup worden getoond. Zowel kleine als grote afbeeldingen worden in de popup weergeven. De kleine afbeeldingen worden met dezelfde logica als in de overview geschaald. De grote afbeeldingen worden allemaal teruggeschaald naar de kolombreedte. 5. KLEINE BERICHTEN MET ENKEL LINK In kleine berichten moet worden gezocht naar links. Door bij deze berichten de gevonden link naar Readability te sturen en het geconverteerde artikel van Readability te tonen worden deze berichten een stuk aantrekkelijker om te tonen. De threshold voor kleine berichten staat ingesteld op een lengte van onder de 250 tekens. Er zijn twee manieren waarop kleine berichten gescand worden op links. Deze twee methoden zijn gebaseerd op dat berichten html en plain tekst kunnen bevatten. Eerst wordt gezocht met behulp van de DOMdocument in php, hier wordt naar de a tag gezocht en de links die hierin gevonden worden worden opgeslagen. Wanneer het artikel slechts één link bevatten wordt deze link gebruikt. Wanneer de bovenstaande methode geen resultaat oplevert wordt er vervolgens met behulp van regular expressions door de inhoud gezocht naar links. Als beide methoden geen resultaat opleveren zal de originele inhoud worden gebruikt als inhoud. 6. ICOON UIT BRON HALEN Om duidelijkheid binnen aan te brengen is gekozen bij ieder artikel de titel van de bron en het bijbehorende icoon weer te geven. Het hiervoor genoemde icoon en de bron wordt door vrijwel iedere site gebruikt. Iedere browser weergeeft dit icoon in de titel of in de adres balk. Het icoon en de titel van een bron wordt op de server op het moment van toevoegen van een nieuwe feed uit de bij de feed behorende pagina gehaald. De server slaat deze gegevens vervolgens samen met de verdere gegevens van de feed op in de database. Er is gekozen om het icoon en de titel bij het toevoegen van een feed op te halen en op te slaan in de database omdat dit een rekenintensief proces is. Doordat dit eenmalig per bron uitgevoerd zal worden wordt hierdoor rekentijd bespaard. De server haalt het icoon en de titel van een bron op door in het RSS bestand te zoeken naar de bijbehorende webpagina, veelal staat deze in de tag link = alternative. Als deze pagina opgehaald is zoekt de server vervolgens binnen de header naar title, dit is de titel van de webpagina. Als laatste wordt het icoon gezocht, deze is veelal binnen de head in de link rel=shortcut icon tag te vinden. 3

143 Design Document Sprint 6 Als het icoon niet gevonden is, wordt bekeken of deze op een standaardplek op de server staat. Als het icoon gevonden is wordt bekeken of deze geopend kan worden, als dit zo is wordt deze in de database opgeslagen. Het UML diagram behorende tot dit deel van de server is gegeven in bijlage D. De client krijgt bij het ophalen van de gegevens van een artikel de url van het icoon en de titel van de bron terug van de server. Deze gegevens worden vervolgens in de client verwerkt en weergegeven. Als geen icoon of titel beschikbaar is, word in plaats van de titel de link naar de feed weergeven, het icoon wordt dan weggelaten. 7. LANGE LIJSTEN LINKS VERWIJDEREN Een probleem wat vaak voorkwam is dat readability een grote lijst met links terug gaf als inhoud van de tekst. Om dit op te lossen wordt weer de DOMdocument gebruikt om deze lijsten te vinden. Als zo n lijst is gevonden wordt de inhoud van het html element vervangen met een lege string. Op deze manier blijft de html correct maar bevinden zich geen grote lijsten meer in de artikelen. 4

144 Design Document Sprint 6 BIJLAGEN A. UML DATABASE 5

145 Design Document Sprint 6 B. UML SERVER: FEED CRON 6

146 Design Document Sprint 6 C. UML SERVER: READABILITY CRON 7

147 Design Document Sprint 6 D. UML SERVER: SAVE FEED 8

148 Design Document Sprint 7 D E S I G N D O C U M E N T SPRIN T 7 Dit document dient ter rapportage van de toegevoegde technische onderdelen van in de zevende sprint. In dit document worden de technische beslissingen uit de zevende sprint uitgewerkt. SAMENVATTING Er is een tijdslijn toegevoegd welke veranderd van grote en van plaats. De plaats is gekoppeld aan de positie van de huidige pagina vergeleken met alle pagina s binnen de tijspan. De grootte van het balkje varieert en stelt naar verhouding het aantal artikelen op het scherm voor. TIJDSLIJN Een smalle horizontale balk is toegevoegd boven de navigatie van. Deze balk is een subtiele weergave van de huidige positie van het scherm binnen een tijdspan. De screenshot in bijlage A is genomen wanneer we door de tijdspan vandaag heen bladerde. Op dat moment was op de tweede pagina en stond het roze balkje op een kleine afstand van de linkerkant van het scherm. kan binnen de tijdspan niet bepalen hoeveel pagina s er zijn. Iedere pagina wordt dynamisch opgebouwd en het aantal gevisualiseerde artikelen verschilt per pagina. Het programma weet hoeveel artikelen er totaal zijn, hoeveel er op de voorgaande gecreëerde pagina s staan en hoeveel er nu op het scherm staan. Met deze informatie wordt het balkje gemaakt. Het balkje is zo breed als de verhouding tussen het aantal artikelen op het scherm vergeleken met het totaal aantal artikelen. Het balkje schuift over het scherm heen en weer wanneer er door de pagina s heen genavigeerd wordt. 1

149 Design Document Sprint 7 BIJLAGEN A. SCREENSHOT STREAMPAPER LAGE RESOLUTIE 2

150 Stageverslag BIJLAGE F I M P L E M E N T A T I E D O C U M E NT

151 Implementatie Document I M P L E M E N T A T I E D O C U M E N T In dit document wordt uitgelegd hoe technisch in elkaar zit. Verschillende modules en schema s worden behandeld. Veel onderwerpen zijn al besproken in de design documenten. Er zal in dit document per onderdeel een globale uitleg volgen waarna er voor de details naar de design documenten verwezen zal worden. bestaat uit twee hoofdcomponenten. De Client en de Server. De Client wordt uitgelegd in hoofdstuk 1, de server in hoofdstuk 0. 1 CLIENT De client van is opgebouwd volgens de MVC architectuur. Er zitten meerdere modules in één laag van de structuur. De View laag is de enige laag welke de DOM van de browser manipuleert en interpreteert. De Model laag is de enige laag welke met de server communiceert. Deze laag gebruikt de save feed service en de stream service om respectievelijk feeds op te slaan en artikelen uit de database te verkrijgen. De Control laag is de laag welke alle logica regelt. Het aanmaken van de manager in de Control laag staat gelijk met het initialiseren van. Deze laag verkrijgt artikelen via de Model laag. De Control laag verwerkt de ruwe data tot een visuele indeling van een subset van alle ontvangen artikelen op het formaat van het scherm. De indeling wordt via de View laag op het scherm gerenderd. In dit hoofdstuk wordt per laag van de MVC architectuur de belangrijkste modules beschreven. Er wordt beschreven hoe ze in elkaar zitten en hoe ze werken. Een overzicht van alle klassen binnen de verschillende lagen van de client is te vinden in het UML diagram client static model in bijlage E. Een overzicht van de interactie tussen de belangrijkste klassen is te vinden in het UML diagram client interaction model in bijlage F. Het eerste ontwerp van de MVC architectuur is te vinden in hoofdstuk 2 van Design Document CONTROL In de Control laag van de client vinden alle logica en bewerkingen plaats. Een instantie van kan worden aangemaakt door een Manager te creëren. De manager is de hoofdschakel tussen de MVC lagen van de client. Allereerst bespreken we de Manager, welke de kern van omvat, waarna we de belangrijkste Modules binnen de Control laag uitleggen waar de manager mee communiceert. 1

152 Implementatie Document MANAGER De manager heeft de hoofd verantwoordelijkheid van. Het is de instantie van. Van initialisatie tot navigatie, alles wordt gecoördineerd door de manager. De manager staat zowel in connectie met de View als de Model laag. Het is dan ook de verantwoordelijkheid van de manager om te zorgen dat het de informatie die het nodig heeft krijgt en de View laag kant-en-klare informatie serveert zodat deze het alleen hoeft te presenteren. De manager bezit een ArticleManager om artikelen via de Model laag op te halen. De opgehaalde artikelen worden aan de Template module gegeven om er een visueel interessant scherm van te maken. De Templates module maakt gebruik van de module StaticTemplates, welke aan de hand van artikeldata templateinformatie teruggeeft, en TemplatesDefenition, welke de vooraf gedefinieerde templates bezit. De zojuist gemaakte indeling wordt gegeven aan de Articles module binnen de View laag welke de artikelen met hun posities op het scherm visualiseerd. De manager bewaart alle voorheen gemaakte schermindelingen in de PageCacher module. Bij navigatie door de pagina s wordt er eerst gekeken of de pagina die opgevraagd wordt al in de cache staat voordat deze opnieuw berekend wordt. Er zijn verschillende tijdsblokken welke bekeken kunnen worden. De module Timespans beheert de verschillende tijdsblokken en de navigatie door deze blokken. Deze blokken zijn dynamisch gedefinieerd zoals bijvoorbeeld Vandaag, Gisteren en Deze week. Bij de navigatie naar een nieuw tijdsblok wordt er een nieuwe ArticleManager en PagesCacher aangemaakt. Voor de interactie van de manager met de andere modules zie het UML diagram client interaction model in bijlage F ARTICLEMANAGER De ArticleManager communiceert met de Articles module in de Model laag. De ArticleManager beheert het ophalen van berichten van de server. Deze houd de limieten bij en haalt automatisch nieuwe berichten op wanneer de module een tekort aan artikelen dreigt te krijgen. Artikelen worden opgevraagd door de manager. De manager weergeeft echter slechts een subset van de opgevraagde artikelen en stuurt de ongebruikte artikelen terug naar de ArticleManager. De ArticleManager bewaart de artikelen vooraan in de queue. De ongebruikte artikelen worden bij het volgende verzoek als eerste meegestuurd. Voor verdere details zie hoofdstuk 2 uit Design Document TEMPLATES De Templates module heeft de verantwoordelijkheid om gegeven een lijst met artikelen en een schermgrootte de beste indeling van artikelen op het scherm te berekenen. Het berekenen van de beste indeling is gebaseerd op een aantal concepten. Deze concepten zullen hier genoemd worden waarna er doorverwezen zal worden naar de bijbehorende design documenten waarin de details staan. 2

153 Implementatie Document Bepaalde posities op het scherm hebben een hogere waarde dan andere posities. Belangrijke documenten worden het liefst op deze belangrijke posities gezet. De belangrijke posities in een scherm zijn geanalyseerd in het vooronderzoek (hoofdstuk 5 kop Bestaand onderzoek ) van. Een aanname van het project is dat verschillende berichten verschillende waarden kunnen hebben. Zo kan een bericht voorang krijgen boven een ander bericht. In de huidige implementatie van krijgen berichten de waarde van de bron. De bronnen kunnen gesorteerd worden op belangrijkheid waarmee aangegeven wordt dat de berichten van de ene bron belangrijker zijn dan een lager gewaardeerde bron. De data van een artikel is belangrijk voor de positionering van het artikel. Zo wordt de data van een artikel gestuurd naar de StaticTemplates module om alle mogelijke artikeltemplates van het artikel met hun bijbehorende waarde te genereren. Er worden alleen artikeltemplates teruggegeven waar het artikel in past met als uitzondering het kleinste template omdat alle berichten op het scherm getoond moeten worden. De waarde van een artikel gematcht aan een artikeltemplate hangt af van de grootte van het artikeltemplate (hoe groter hoe beter), de aanwezigheid van een grote afbeelding (bonuswaardering omdat visuele artikelen aantrekkelijker zijn) en hoe goed de inhoud van het artikel in het artikeltemplate past. De drie hiervoor genoemde waarderingen worden gecombineerd om de totale waarde te berekenen. Vooraf gedefinieerde indelingen van een scherm worden gecombineerd met meerdere schermindelingen. De verschillende indelingen worden allemaal gewaardeerd door de waarderingen van de artikelen op plaatsen in het schermtemplate allen met elkaar te combineren. De schermindeling met de hoogste waardering is de beste benaderde indeling van het scherm voor de gegeven artikelen. De schermtemplates zijn recursief gedefinieerd in de module TemplateDefinition. De templates kunnen op eenvoudige wijze gedefinieerd en hergebruikt worden. Enkele voorbeelden van een aantal artikeltemplates en schermtemplate staan hieronder weergeven. De templates worden bij initialisatie van recursief uitgewerkt waardoor het programma dat niet bij iedere nieuwe pagina hoeft te berekenen. De definitie van templates is te vinden in sectie van Design Document 1 en een verbetering in hoofdstuk 2 van Design Document 2. var articletemplates = [ Article2x2 = Dim(2, 2), Article3x2 = Dim(3, 2), ]; var screen4x2 = Screen(Dim(4, 2), [ [posarticle(coor(0, 0), article2x2), posscreen(coor(2, 0), screen2x2big)], // real big [posscreen(coor(0, 0), screen2x2big), posscreen(coor(2, 0), screen2x2medium)], // big [posscreen(coor(0, 0), screen3x2big), posscreen(coor(3, 0), screen1x2small)], // combi [posscreen(coor(0, 0), screen2x2medium), posscreen(coor(2, 0), screen2x2small)], // small ]); Voor meer informatie over de verschillende waarderingen en het optimale algoritme op het beste schermtemplate te berekenen zie hoofdstuk 3 van Design Document 3. Het algoritme is later nog versneld, die documentatie is te vinden in hoofdstuk 2 van Design Document 6. 3

154 Implementatie Document PAGESCACHER De manager stuurt de gemaakte schermindeling als pagina aan de PagesCacher module. De PagesCacher module slaat deze pagina op achteraan de pagina lijst. Tevens stelt de PagesCacher de zojuist toegevoegde pagina in als standaardpagina. De PagesCacher bezit publieke methoden om op te vragen of er een vorige of volgende pagina is en methoden om daar ook daadwerkelijk naartoe te schakelen en de pagina te verkrijgen. De PagesCacher is gebouwd om de berekeningen niet opnieuw uit te voeren en om de schermindelingen consistent te houden TIMESPANS EN DATE Er bestaan vier verschillende tijdsblokken in. Deze blokken zijn Vandaag, Gisteren, Deze week en Vorige week. Weken zijn van maandag tot zondag en Deze week is alleen beschikbaar wanneer de huidige dag woensdag of verder in de week is. Dit is zo gemaakt omdat vandaag alles van vandaag bezit, gisteren van gisteren, en in deze week wil je die berichten niet meer tegenkomen. FIGURE 1.1: DATE KLASSE BINNEN STREAMPAPER De Timespans module is zo gemaakt dat het gemakkelijk uit te breiden is. Tijdsblokken kunnen eenvoudig veranderd of toegevoegd worden. Onderhoud aan deze module is zeer makkelijk. Er is een wrapper geschreven om de Date klasse van JavaScript. Deze wrapper, de Date module binnen, bezit functies als ismonday en getyesterday. Een overzicht van deze functies staan in figuur 1.1. Een tijdsblok wordt nu als volgt gedefinieerd: var now = sp.control.date.create(); spans.push({ title: "Yesterday", start: now.getyesterday().getstartoftheday(), end: now.getyesterday().getendoftheday() }); 4

155 Implementatie Document 1.2 MODEL De Model laag is de koppeling tussen de client en de server van. Het is een zeer dunne laag en heeft als enige verantwoordelijkheid het regelen van de communicatie tussen de client en de server. Er zijn twee modules in de Model laag, de Articles en de Feeds module. De Articles module haalt aan de hand van de meegegeven parameters de desbetreffende artikelen van de server op. De Feeds module kan feeds opslaan in de database van. 1.3 VIEW De View laag kan de DOM van de browser manipuleren en ontvangt de events gegenereerd door de browser. De modules in de View laag bezitten DOM elementen welke alleen gemanipuleerd worden door de modules zelf. De Application module binnen de View laag bezit alle grote modulen binnen de view en is de module welke aangeroepen wordt door de Manager module uit de Control laag. De hoofdfunctie van de View laag is het presenteren van artikelen op het scherm volgens een gegeven indeling. Daarnaast is het van belang dat door de applicatie genavigeerd kan worden en de juiste toetsencombinaties opgevangen worden. Met een toetsencombinatie moeten de juiste modules, welke zich op dit event hebben moeten abonneren, worden ingelicht ARTICLES De templates bepalen waar en in welk formaat een bericht geplaatst wordt. De beschikbare ruimte per bericht kan volgens verschillende varianten ingevuld worden. In zijn meerdere varianten bedacht en een aantal geïmplementeerd. De Articles module welke de berichten op het scherm zet wordt opgedeeld in de verschillende soorten, deze soorten worden viewtemplates genoemd. Het zijn geen statische templates, maar een set van regels hoe een artikel op het scherm gezet wordt. Er worden twee viewtemplates gebruikt in, deze templates worden de text en textimage viewtemplate genoemd. De eerste variant weergeeft een bericht als tekst met kleine afbeeldingen. Deze afbeeldingen worden allen naar dezelfde breedte geschaald om het overzicht rustig te houden. De tweede variant weergeeft een bericht als een stuk tekst met daarbij een grote afbeelding. Deze afbeelding kan meerdere kolommen innemen. De keuze van een viewtemplate is volledig berust op de eigenschappen van een bericht. Er wordt onder andere bekeken of er afbeeldingen zijn om te presenteren, of wat de verhouding tekst ten opzichte van afbeeldingen is en of een afbeelding in het betreffende artikeltemplate past. Een textimage template heeft een hogere waarde dan een text template en heeft daarom de voorkeur. Naast de titel, datum en inhoud van een bericht wordt ook de afkomst van het bericht in weergeven. Bij het toevoegen van een rss stream wordt er geprobeerd om een icoon van het domein van de RSS url op te halen. Een icoon van Outpost is al aanwezig. Voor details over de viewtemplates zie hoofdstuk 1 van Design Document 1 en hoofdstuk 1 van Design Document 2. Voor details van het opvragen van de iconen zie hoofdstuk 6 van Design Document 6. 5

156 Implementatie Document POPUPMANAGER De PopupManager regelt de popups. Er kan gemakkelijk een popup aangemaakt worden, deze is als deze niet aangeroepen is onzichtbaar. Er kunnen eigenschappen en verschillende soorten inhoud worden ingesteld. De titel, inhoud, hoogte en breedte kunnen worden ingesteld. De popup is, als dit niet aangepast wordt, op formaat van het volledige scherm minus een kleine marge om te zien dat je nog in de applicatie bent. Er kunnen website popups worden gecreerd binnen de applicatie. Hierbij wordt er een externe website geladen binnen de contouren van de popup. Deze website popup wordt altijd in volledig scherm binnen weergeven. De toets Escape op het toetsenbord kan een popup laten sluiten, echter moet dit alleen bij de bovenste popup gebeuren. Dit is de reden dat de PopupManager is aangemaakt. Deze zorgt er voor dat alleen de bovenste popup naar de toetsen van het toetsenbord luistert. Voor de details van de popups zie hoofdstuk 3 van Design Document 2. Voor meer informatie over de website popup zie hoofdstuk 4 van Design Document SHORTCUTS Om gebruiksvriendelijker te maken is gekozen om shortcuts toe te voegen. Shortcuts zijn toetsencombinaties waarmee acties uitgevoerd kunnen worden zonder dat de muis gebruikt hoeft te worden. Er is gekozen om shortcuts te gebruiken om de popup met Escape te sluiten, tussen pagina s te wisselen met de pijlen naar links en rechts en om tussen tijdsblokken te wisselen als tegelijk Ctrl en een van de pijlen naar links of rechts ingedrukt worden. Voor details zie hoofdstuk 3 uit Design Document 5. 6

157 Implementatie Document 2 SERVER In dit hoofdstuk worden de vier services in technisch detail besproken. Er zal worden uitgelegd welke klassen en methoden er gebruikt worden voor de betreffende service. De server verleent vier services, waarvan twee services door de client van kunnen worden gebruikt. De eerste service wordt gebruikt om artikelen van een stream uit de database op te vragen, hierna stream service genoemd. De tweede service, de save feed service, kan verschillende streams toevoegen aan een bepaalde streamset. Een stream is gedefinieerd als een chronologische lijst van informatieberichten, bijvoorbeeld een RSS feed. De save feed service haalt bij de feed behorende informatie - inclusief titel en icoon - op en slaat deze informatie op in de database. De volgende twee services worden niet door de client maar op een vooraf bepaald tijdsinterval, doormiddel van een Cronjob, aangeroepen. Een Cronjob is een UNIX commando welke op een vooraf ingesteld tijdstip of interval een script uit kan voeren. De derde service, de cron service, haalt informatieberichten op uit de ingestelde externe en interne streams en bepaald of er extra informatie uit websites gehaald moeten worden. De verzamelde informatie over een bericht wordt vervolgens in de database opgeslagen. De laatste service, de Readability service, verzamelt belangrijke informatie van websites welke door de cron service aangemerkt zijn om nader te bestuderen. De uitgelezen informatie wordt opgeschoond en opgeslagen bij het desbetreffende bericht. 2.1 STREAM SERVICE De stream service wordt door de client aangeroepen, de client geeft hierbij aan welk tijdsbestek gewenst is en hoeveel berichten gewenst zijn. De stream verkrijgt de juiste berichten uit de database en verwerkt dit tot artikelen welke de client kan ontvangen. De server stuurt als antwoord op de aanvraag een lijst van artikelen in JSON formaat naar de client. Het UML diagram van de stream service is te vinden in bijlage A STREAM HANDLER De client roept de stream service aan door de stream handler aan te roepen. De stream handler verwacht dat een aantal variabelen in de header meegestuurd worden. Deze informatie bestaat uit een streamset, tijdspan en het limiet van de opgevraagde artikelen. De stream handler vraagt de artikelen van de streamset binnen de gevraagde tijdspan en limiet op bij de StreamReader. Het model van de stream handler is te vinden in Figure STREAMREADER De StreamReader vraagt de artikelen van een stream op bij de SourceReader. Deze artikelen worden vervolgens gesorteerd op belangrijkheid en de uit de database verkregen datum wordt omgeschreven naar een door de client geaccepteerd formaat. De klasse StreamReader is te vinden in Figure 2.2 7

158 Implementatie Document FIGURE 2.1: STREAMHANDLER FIGURE 2.2: STREAMREADER SOURCEREADER De SourceReader extends GeneralReader. De SourceReader haalt alle artikelen van een gegeven streamset binnen de gegeven tijdspan en limiet op. Hierbij worden de artikelen gecombineerd met de tot de artikelen behorende afbeeldingen. De verkregen artikelen worden samen met het totaal aantal artikelen teruggegeven. De klasse SourceReader is te vinden in Figure 2.4 en de samenhang met de GeneralReader is te vinden in bijlage A GENERALREADER De GeneralReader bevat hulpfuncties voor onder andere SourceReader. De GeneralReader houd de databaseconnectie bij en bied functionaliteit om informatie uit de database te halen. De invoer van databaseaanvragen wordt gecontroleerd op correctheid voordat deze gebruikt word. De klasse GeneralReader staat in Figure 2.3. FIGURE 2.3: GENERALREADER FIGURE 2.4: SOURCEREADER 2.2 CRON SERVICE De cron service wordt met vaste regelmaat door de server aangeroepen. De cron service zoekt in de database op welke streams, ook wel bronnen genoemd, uitgelezen moeten worden. Deze bronnen kunnen afkomstig zijn uit Outpost of het kunnen XML bestanden zijn welke opgebouwd zijn volgens de RSS specificatie. De cron service leest de verkregen bronnen uit, verwerkt de informatie en slaat dit op in de database. Als een item uit een bron erg kort is of alleen een link bevat, voegt de cron service een aanvraag voor de verwerking van een url toe bij Readability en slaat de uit Readability verkregen identificatie op. De Readability service zal hier gebruik van maken. Het UML diagram van de cron service is te vinden in bijlage B. 8

159 Implementatie Document CRON HANDLER De Cronjob roept met de cron handler de cron service aan. De cron handler is eigenaar van de connectie met de database. In cron handler wordt eerst een lijst met alle bronnen opgevraagd uit de database, vervolgens wordt met deze lijst ArticleImport aangeroepen. De cron handler staat in Figure ARTICLEIMPORT De klasse ArticleImport doet wat zijn naam al doet vermoeden, berichten van de gegeven bron importeren. Eerst word van deze bron opgezocht wat het laatste bekende artikel is. De gevonden datum en tijd van het laatst bekende bericht word gebruikt als begintijd om nieuwe artikelen op te halen. Er wordt bekeken welk type de bron heeft; bij RSS of Twitter word getarticles uit de RssReader aangeroepen met de source en de eerder gevonden tijd. Wanneer het type van de bron een van de verschillende outpost mogelijkheden is wordt de bijbehorende methode uit OutpostReader aangeroepen, deze krijgen ook de bron en tijd mee. De klasse ArticleImport is te vinden in Figure 2.7. FIGURE 2.5: ARTICLEIMPORT FIGURE 2.6: CRON_HANDLER RSSREADER De klasse RssReader heeft als verantwoordelijkheid RSS feeds uit te lezen. Bij het aanroepen van getarticles uit RssReader wordt met behulp van de PHP module SimpleXML het gegeven XML bestand uitgelezen. Uit het XML bestand worden vervolgens de artikelen gelezen. De RssReader kan verschillende typen opmaak van XML bestanden aan. Zo kan een artikel in een entry element, maar ook in een item element staan. Deze verschillen gelden ook voor de titel, content en andere waarden. In het vooronderzoek is hier al onderzoek naar gedaan. In de praktijk bracht het nog problemen met zich mee doordat veel RSS feeds zich niet aan de conventie houden. De artikelen uit het XML bestand worden met de savearticle methode naar de database geschreven. Deze methode bewerkt het artikel met behulp van een aantal methoden uit ArticleFunctions, namelijk; getwebsite, cleanarticle en setcontentlength. Daarna maakt savearticle gebruik van CronDatabase om de artikelen op te slaan. Als getwebsite aangeeft dat een website opgeslagen moet worden zal savearticle een rij toevoegen aan de database waarin dit opgeslagen word. De klasse RssReader is te vinden in Figure

160 Implementatie Document OUTPOSTREADER ArticleImport kan afhankelijk van het type Outpost bron verschillende functies aanroepen binnen OutpostReader. Typen bronnen zijn; gebruiker, groep, gebruiker mentioned allen op naam of identificatienummer. Allen beschikken ze over een eigen methode welke de bijbehorende gegevens uit de Outpost database ophaalt en vervolgens het opgehaalde artikel opslaat. Deze methoden delen enige functionaliteit, maar zijn grotendeels verschillend vanwege andere databaseaanroepen en verwerking. savearticle is op meerdere parameters na gelijk aan savearticle uit de RssReader. De klasse OutpostReader is te vinden in Figure 2.7. FIGURE 2.8: RSSREADER FIGURE 2.7: OUTPOSTREADER CRONDATABASE Alle methoden in de cron- en Readability service welke databaseaanpassingen doorvoeren zijn geplaatst in de CronDatabase klasse. Dit betreft de methoden welke alle bronnen ophalen, de laatste datum van een bron opzoekt en nieuwe artikelen naar de database schrijven. Ook zit hier de functie updatetoparticle in, deze wordt uitgelegd in de Readability service. De klasse Crondatabase is te vinden in Figure 2.9. FIGURE 2.9: CRONDATABASE 10