1 TUDELFT Stageverslag Hylke Hendriksen, Peter van Buul en Huub van der Voort 22/06/2012 Dit stageverslag is ter afsluiting van het bachelorproject vo...
Stageverslag Streampaper 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 Streampaper ontworpen en geïmplementeerd. Streampaper is een op zichzelf staande applicatie waarin verschillende externe informatiestromen gecombineerd kunnen worden weergegeven. De gebruiker van Streampaper kan gemakkelijk door pagina's met berichten uit deze bronnen bladeren. Het doel van Streampaper is het vergemakkelijken van het up-to-date blijven van werknemers wat betreft bedrijfsnieuws en eventuele andere relevante nieuwsbronnen.
Titel
Stageverslag (Streampaper)
Auteurs
Hylke Hendriksen Peter van Buul Huub van der Voort
In opdracht van
TU Delft en Moxio
1537776 1512269 1509446
TABLE OF CONTENTS Voorwoord ................................................................................................................................................................................. 4 Inleiding....................................................................................................................................................................................... 5 1.
Probleemstelling en analyse...................................................................................................................................... 6 1.1.
Proces ............................................................................................................................................................................... 10
Client – Server architectuur ........................................................................................................................... 11
4.2.
MVC in de client .................................................................................................................................................. 12
Pagina’s en tijdsblokken .................................................................................................................................. 14
Code kwaliteit beoordeling door SIG ................................................................................................................... 18 6.1.
Aanbevelingen vanuit SIG ............................................................................................................................... 18
Unit tests ................................................................................................................................................................ 19
Integratie met Outpost ..................................................................................................................................... 21
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 2012
4 Streampaper
Stageverslag
INLEIDING Gedurende de stage is het programma Streampaper ontworpen en geïmplementeerd. Streampaper is een op zichzelf staande applicatie waarin verschillende externe informatiestromen gecombineerd kunnen worden weergegeven. De gebruiker van Streampaper kan gemakkelijk door pagina's met berichten uit deze bronnen bladeren. Het doel van Streampaper 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 Streampaper is voortgevloeid. Hiertoe wordt het probleem geanalyseerd en de oplossing die Streampaper 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 Streampaper 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 Streampaper 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 Streampaper
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 Streampaper waren.
1.1.
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 Streampaper, 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 Streampaper 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. 2. 3. 4.
Streampaper moet verschillende informatiebronnen kunnen verwerken Hoe worden meerdere informatiebronnen gecombineerd? Waar nodig extra informatie verzamelen Hoe moet het dynamisch en overzichtelijk weergeven worden?
1.2.
OPLOSSING
De vier deelproblemen komen samen in het op zichzelf staande applicatie genaamd Streampaper. Streampaper 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 Streampaper
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.
1.3.
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 Streampaper zouden kunnen worden gebruikt. Uit dit onderzoek is gebleken dat CSS Regions een interessante techniek is om te gebruiken bij de ontwikkeling van Streampaper. Een belangrijk nadeel is echter dat enkel Google Chrome deze techniek ondersteund. Vanwege het voorgaande is besloten dat Streampaper 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 Streampaper. 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. Streampaper 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 Streampaper. 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 Streampaper verder onderzocht.
7 Streampaper
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 Streampaper
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 Streampaper 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 Streampaper. 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 Streampaper
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. Streampaper 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 Streampaper
Stageverslag
4. ONTWERP Streampaper 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.
4.1.
CLIENT – SERVER ARCHITECTUUR
Streampaper 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. Streampaper 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. Streampaper 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 Streampaper 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 Streampaper degelijk en reactief gemaakt worden. Voor details over de client – server architectuur zie ‘Design Document 1’ in bijlage E.
11 Streampaper
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 Streampaper vallen. De DOM hoort bij de browser en de server is onderdeel van Streampaper. 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 Streampaper. 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.
4.3.
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 Streampaper. 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 2.3.2 van ‘Design Document 1’ in bijlage E.
12 Streampaper
Stageverslag
4.4.
TEMPLATES
Streampaper 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 2.3.3 van ‘Design Document 1’ en hoofdstuk 2 van ‘Design Document 2’ welke beide in bijlage E te vinden zijn.
4.5.
POPUPS
Binnen Streampaper 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 Streampaper, welke naar een externe website verwijst, in te openen. Hiertoe is besloten, omdat de gebruiker van Streampaper 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 Streampaper 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 Streampaper
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 Streampaper 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 Streampaper. 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, Streampaper 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.
4.7.
READABILITY
Streampaper 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 Streampaper, 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 Streampaper 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 Streampaper
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 Streampaper. 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.
4.9.
OPTIMAAL ALGORITME
Onder de kop ‘optimaal algoritme’ is uitgewerkt hoe de optimale schermindeling binnen Streampaper 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 1.1.3 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 5.3.1 van het vooronderzoek in bijlage C.
15 Streampaper
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 Streampaper
Stageverslag
5. IMPLEMENTATIE In dit hoofdstuk zal worden omschreven hoe de verschillende delen van Streampaper 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 Streampaper 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 Streampaper
Stageverslag
6. CODE KWALITEIT BEOORDELING DOOR SIG De code van Streampaper 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.
6.1.
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.
6.2.
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 Streampaper
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.
6.4.
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 Streampaper
Stageverslag
7. CONCLUSIE De doelstelling van het project is gehaald door een werkende versie van Streampaper binnen de gestelde termijn op te leveren aan Moxio. Streampaper 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 Streampaper biedt. De oplossingen en mogelijkheden zijn gebaseerd op de volgende deelproblemen: 1. 2. 3. 4.
Streampaper moet verschillende informatiebronnen kunnen verwerken Hoe worden meerdere informatiebronnen gecombineerd? Waar nodig extra informatie verzamelen 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 Streampaper
Stageverslag
8. AANBEVELINGEN In dit hoofdstuk worden enkele aanbevelingen gegeven voor verdere ontwikkeling van Streampaper. Streampaper 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 Streampaper in Outpost. Een korte samenvatting van het integratie document is te vinden in paragraaf 8.1. De eerste aanbeveling voor de verdere ontwikkeling van Streampaper 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 Streampaper 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 PubSubHubbub1. 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.
8.1.
INTEGRATIE MET OUTPOST
In dit project is Streampaper 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. Streampaper 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 Streampaper 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.
1
https://code.google.com/p/pubsubhubbub/
21 Streampaper
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 Streampaper 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 Streampaper
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 Streampaper
Stageverslag
VERKLARENDE WOORDENLIJST API
‘Application Programming Interface’. Hiermee communiceren met een ander programma.
Browser
Software waarmee een webpagina bekeken kan worden. Voorbeelden van browsers zijn ‘Internet explorer’ en ‘Google Chrome’.
CSS
Een centraal bestand waarin de opmaak van een website ‘geprogrammeerd’ is.
Cronjob
Een Unix commando dat op een vooraf ingesteld tijdstip of interval een programma of script uitvoert.
DOM
‘Document Object Model’; Het is een taalonafhankelijke conventie over de representatie en interactie van objecten in HTML, XHTML en XML documenten.
Google Chrome
De webbrowser van Google. Zie “Browser”.
HTML
Een programmeertaal waarin websites opgebouwd worden.
JavaScript
Programmeertaal waarmee web applicaties binnen een webbrowser gemaakt kunnen worden.
JSLint
Programma waarmee JavaScript gevalideerd kan worden.
JSON
JavaScript Object Notation; Een open standaard voor de notatie van JavaScript objecten.
OAuth
‘Open Authorization’. Hiervan wordt door sommige API’s gebruik gemaakt om gebruikers of programma’s te verifiëren.
Outpost
Sociaal extranet ontwikkeld door Moxio, hiermee wordt de communicatie tussen collega’s bevorderd.
Pairprogramming
Met twee of meer personen aan een computer werken.
RESTful
Een type API waarbij de gegevens met een simpele folder achtige structuur via de URL opgevraagd kunnen worden.
RSS
Een vastgestelde, door veel nieuwsberichten op te halen.
Namespace
Een set, of groep, waarin namen van variabelen, functies en/of constanten worden gegroepeerd.
Scrum
Een manier van programmeren met een groep. Er word per tijdsdeel besloten wat de doelen zijn.
SIG
‘Software Improvement Group’; De geschreven code is door hen beoordeeld.
Stream
Een chronologische lijst van informatieberichten, bijvoorbeeld een RSS feed.
Streamset
Een set van verschillende streams. Zie Stream.
TFS
‘Team Foundation Server’; Een programma van Microsoft dat het gebruik van scrum ondersteund.
websites
kan
een
aangeboden
programma
techniek
om
24 Streampaper
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 Streampaper te vinden, deze zijn per sprint uitgewerkt. In het integratie document wordt aangegeven hoe Streampaper 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. B. C. D.
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 [email protected] of telefonisch via 015 268 25 92. Een volledig overzicht van onze contactgegevens: Moxio BV Rotterdamseweg 183c 2629 HD Delft 015 268 25 92 www.moxio.com
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.
Deze informatie is afkomstig uit een reeks verschillende bronnen die allemaal om aandacht vechten, zowel vanuit de eigen organisatie als van buitenaf. Denk aan:
e-mail; 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 [email protected] 06 - 55 967 381
PLAN VAN AANPAK 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 Streampaper gekregen. Streampaper 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 Streampaper 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 Streampaper gewerkt worden, de opdrachtgever zorgt voor volledige werkplekken zodat op werktijden op het kantoor van Moxio gewerkt kan worden.
Streampaper
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.
1.2. 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.
1.3. 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.
2.1. 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
Streampaper
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.
2.2. 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.
2.3. 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:
E-mail; 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 Streampaper, 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 Streampaper 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 Streampaper ook korte tijd gewerkt kan worden aan tot Streampaper 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.
Streampaper
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 Streampaper, 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 Streampaper.
2.5. 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.
2.6. 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.
Streampaper
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.
4.1. 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.
4.2. 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.
Streampaper
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.
4.4. 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.
4.5. 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.
4.6. 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 Streampaper 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
Streampaper
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 Streampaper.
Streampaper Vooronderzoek Hylke Hendriksen, Peter van Buul en Huub van der Voort 2-5-2012
Onderzoeksverslag naar de mogelijkheid van de bouw van een digitale knipselkrant, Streampaper genaamd. In het eerste deel is onderzocht wat CSS3 en HTML5 kunnen betekenen bij de ontwikkeling van Streampaper. In het tweede deel is gekeken hoe informatie op internet wordt aangeboden. In het derde deel is onderzocht hoe de user interface van Streampaper kan worden opgebouwd.
Titel
Streampaper Vooronderzoek
Auteurs
Hylke Hendriksen Peter van Buul Huub van der Voort
2. HTML5 ..................................................................................................................................... 6 2.1 CLIENT SIDE STORAGE
6
2.1.1 WEB STORAGE ................................................................................................................................... 6 2.1.2 WEB SQL DATABASE .......................................................................................................................... 6 2.1.3 INDEXED DATABASE ............................................................................................................................ 6 2.1.4 NADELEN VAN LOKALE DATABASES ......................................................................................................... 7 2.2 SELECTORS API
7
2.3 IFRAMES
7
2.4 BROWSERONDERSTEUNING
8
3. BERICHTEXTRACTIE UIT WEBSITES ............................................................................................ 9 3.1 BESTAANDE PROGRAMMA’S
9
3.1.1 READABILITY ...................................................................................................................................... 9 3.1.2 BOILERPIPE ...................................................................................................................................... 10 4. ALGEMENE UITLEESBAARHEID VAN RSS FEEDS EN GOOGLE READER ........................................ 12 4.1 RSS STANDAARDEN
12
4.2 ELEMENTEN BINNEN RSS 2.0
12
4.3 ANALYSE EXTERNE RSS FEEDS
13
4.4 GOOGLE READER
14
4.4.1 WAT KAN GOOGLE READER BIEDEN? ................................................................................................... 14 4.4.2 BRUIKBAARHEID GOOGLE READER VOOR STREAMPAPER ......................................................................... 14
4.4.3 STRUCTUUR GOOGLE READER FEED ..................................................................................................... 15 5. USER INTERFACE .................................................................................................................... 16 5.1 DEFINITIE INPUT
2.1 KLEINE RASTERS (1X1, 2X1 & 1X2) ........................................................................................................ 35 2.2 MIDDELGROTE RASTERS (2X2, 2X3 & 3X2).............................................................................................. 35 2.3 MIDDELGROTE RASTERS (3X1, 1X3 & 3X3).............................................................................................. 36 2.4 GROTE RASTERS (4X2, 4X1, 1X4 & 4X3) ................................................................................................ 37 2.5 GROTE RASTERS (4X4) .......................................................................................................................... 37 2.6 GROTE RASTERS (4X5) .......................................................................................................................... 38 2.7 GROTE RASTERS (4X6) .......................................................................................................................... 38 2.8 GROTE RASTERS (4X7) .......................................................................................................................... 39
Vooronderzoek
Voorwoord
VOORWOORD Dit onderzoek is gedaan ter voorbereiding van de ontwikkeling van een applicatie genaamd Streampaper. Dit vindt plaats in het kader van ons bachelor eindproject aan de TU Delft onder begeleiding van de firma Moxio.
INLEIDING Streampaper 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 Streampaper. De opzet van Streampaper 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 Streampaper. 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 Streampaper kan worden opgebouwd.
Streampaper 1
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 Streampaper.
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-.
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; }
Streampaper 2
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; }
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 Streampaper. 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 Streampaper 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.
Streampaper 3
Vooronderzoek
1. CSS3
a {
a { background: #9c3; transition-property: background; transition-duration: 0.3s; transition-timing-function: 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 Streampaper 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 annotatie @keyframes 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 uit: @keyframes 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:
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 Streampaper 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 Streampaper. 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.
Streampaper 5
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 Streampaper. 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 Streampaper 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.
2.1.1 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.
2.1.2 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 Streampaper met als voornaamste reden dat deze API deprecated is.
2.1.3 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 e-mailadres en telefoonnummer.
Streampaper 6
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).
2.1.4 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 1.4.3 gebruikt maakt van de querySelectorAll (17).
2.3 IFRAMES In Streampaper 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)
Streampaper 7
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
10.0
17.0
Multi-Column
10.0
3.6
17.0
Transitions
10.0
9.0
17.0
Transforms
9.0
3.6
17.0
Animations
10.0
9.0
17.0
Indexeddb
10.0
9.0
17.0
QuerySelector
8.0
3.6
17.0
Iframe Sandbox
10.0
17.0
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 Streampaper. Chrome ondersteunt alle modules voor versie 17.0. De Chrome browser update automatisch, waardoor de meeste Chrome gebruikers al minstens op versie 17.0 zitten. Chrome lijkt de beste keus om Streampaper in te ontwikkelen.
Streampaper 8
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 Streampaper 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.
3.1.1 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 Streampaper, maar zal wel van toepassing zijn op een commerciële versie.
Streampaper 9
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.
3.1.2 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 Streampaper met deze functionaliteit uitgebreid zou moeten worden.
Streampaper 10
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 Streampaper 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.
Streampaper 11
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 Streampaper belangrijk dat zoveel mogelijk, zo niet alle geldige RSS feeds betrouwbaar uitgelezen kunnen worden. Ook wordt bekeken hoe Google Reader te integreren is in Streampaper, 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 Streampaper voornamelijk relevant om ons te richten op RSS 2.0.
GRAFIEK 1: PERCENTAGE PER RSS VERSIE, OVER MEER DAN 800.000 FEEDS
4.2 ELEMENTEN BINNEN RSS 2.0 Ieder bericht binnen een RSS feed bevindt zich binnen de 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).
Streampaper 12
Vooronderzoek
4. Algemene uitleesbaarheid van RSS feeds en Google Reader
TABEL 2: ELEMENTEN BINNEN RSS 2.0 SPECIFICATIE
Element title link description author category
Omschrijving De titel van het item. De URL van het item. Korte inhoud van dit item. e-mail adres van de auteur. Categorieën waaraan dit bericht toebehoort. Meerdere category elementen toegestaan. URL naar comments pagina van dit item. Aan dit bericht verbonden media object. Format: http url, length in bytes, MIME type. Globally unique identifier. Format: geen syntax gespecificeerd. Datum van publicatie. Format: Sun, 19 May 2002 15:21:36 GMT. Naam van RSS feed waarin dit bericht staat Eigenschap: URL naar de XML
comments enclosure guid pubDate source
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
title link description author category comments guid pubDate enclosure related copyRightPhoto dc:creator feedburner
Tweakers.net x x x x x x x x
CNN x x x
Engadget x x x
NU.nl x x x x
x x
x meerdere x x x
x x x x x
Interfacelift x x x x x x
x x
Streampaper 13
Vooronderzoek
4. Algemene uitleesbaarheid van RSS feeds en Google Reader
4.4 GOOGLE READER Streampaper 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.
4.4.1 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 Streampaper 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.
4.4.2 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 Streampaper 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 Streampaper 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 Streampaper algoritmes op dat moment mogelijk niet meer werken. Dit laatste kan in de toekomst een kostenpost voor extra ontwikkeling veroorzaken.
Streampaper 14
Vooronderzoek
4. Algemene uitleesbaarheid van RSS feeds en Google Reader
4.4.3 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="1334164627888"> <source gr:stream-id=" ">
Streampaper 15
Vooronderzoek
5. User interface
5. USER INTERFACE In Streampaper 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 Streampaper 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 Streampaper uitsluitend een opsomming van artikelen is. Tenslotte dient Streampaper 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
Streampaper 16
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 Streampaper 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 Streampaper 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.
Streampaper 17
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.
5.3.1 BESTAAND ONDERZOEK In de ontwikkeling van Streampaper 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.
Streampaper 18
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 Streampaper 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
5.3.2 SCHERMANALYSE Ieder artikel dat wordt weergegeven door Streampaper 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: Streampaper 19
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 staat hieronder:
kolommen met een breedte van
pixels. Een voorbeeld hiervan
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.
Streampaper 20
Vooronderzoek
5. User interface
De meest gangbare schermresoluties begin 2012 zijn volgens Wikipedia (30) & Statcounter (31): Resolutie
Aantal kolommen (uitgaande Aantal rijen van 280 pixels standaard)
1024x768
3
2
1280x800
4
2
1366x768
4
2
1280x1024
4
3
1680x1050
6
3
1920x1080
6
3
1600x900
5
3
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 Streampaper 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 Streampaper is het aan te raden om deze resoluties te testen.
5.3.3 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, Streampaper 21
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.
5.3.4 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
Streampaper 22
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
één groot 2x2 artikel
2x2 raster2: 1x2A, 1x2A
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
1 groot 2x2 artikel
2x2 raster4: 1x2A, 1x2R
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 Streampaper 23
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 Streampaper 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.
Streampaper 24
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.
5.3.5 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 Streampaper te klikken kunnen ze worden afgespeeld in een eigen interne mediaplayer.
Streampaper 25
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.
Streampaper 26
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 Streampaper. De regions module is deels geïmplementeerd en is erg handig voor de kolommenstructuur van Streampaper. 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 Streampaper 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 Streampaper. Mochten de limieten van de Readability API bereikt worden bij een eventuele toekomstige commerciële versie van Streampaper, 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 Streampaper niet van essentieel belang, omdat zij van toepassing zijn op informatie buiten wat Streampaper zal gaan visualiseren. Google Reader is te implementeren door de gebruiker (mogelijk via Streampaper) 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 Streampaper verwerkt worden. Een belangrijk voordeel van Google Reader is dat deze, binnen de feeds, meer berichten uit het verleden kent.
Streampaper 27
Vooronderzoek
Conclusie
Bij het onderzoek naar mogelijke oplossingen voor de user interface van Streampaper 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.
Streampaper 28
Vooronderzoek
Bibliografie
BIBLIOGRAFIE [1] 1. CSS Regions: One Year In. Web Platform Team Blog. [Online] Adobe, 2012 maart 16. [Citaat van: 2 april 2012.] http://blogs.adobe.com/webplatform/2012/03/16/cssregions-one-year-in/. [2] 2. Smith, Andi. CSS Regions. [Online] 13 maart 2012. [Citaat van: 9 april 2012.] http://www.andismith.com/blog/2012/03/css-regions/ . [3] 3. Rich page layout with HTML and CSS3. [Online] [Citaat van: 9 april 2012.] http://www.infoq.com/news/2012/03/CSS3-Regions-Exclusions. [4] 4. Multi-column text using CSS3. Red Team Design. [Online] [Citaat van: 11 april 2012.] http://www.red-team-design.com/multi-column-text-using-css3. [5] 5. Vasile, Christian. New CSS3 Properties For Better Text And Word Wrapping. 1st webdesigner. [Online] 8 maart 2012. [Citaat van: 11 april 2012.] http://www.1stwebdesigner.com/design/css3-text-word-wrapping/. [6] 6. The Expressive Web. [Online] Adobe, 2011. [Citaat van: 2 april 2012.] http://beta.theexpressiveweb.com. [7] 7. Mahemoff, Michael. Client-side storage. HTML5 Rocks. [Online] 1 oktober 2010. [Citaat van: 2 april 2012.] http://www.html5rocks.com/en/tutorials/offline/storage/. [8] 8. Pilgrim, Mark. The past, present & future of local storage for web applications. Dive into HTML5. [Online] [Citaat van: 2 april 2012.] http://diveintohtml5.info/storage.html. [9] 9. Beyond named key-value pairs: Competing visions. [Online] [Citaat van: 2 april 2012.] http://diveintohtml5.info/storage.html. [10] 10. Kinlan, Paul. A simple todo list using html5 indexeddb. HTML5ROCKS Tutorials. [Online] 15 mei 2011. [Citaat van: 9 april 2012.] http://www.html5rocks.com/en/tutorials/indexeddb/todo/. [11] 11. Blommestein, Michiel van. CouchDB performt als een gek! Webwereld. [Online] 21 october 2009. [Citaat van: 9 april 2012.] http://webwereld.nl/tips-entools/79953/couchdb-performt-als-een-gek-/3.html. [12] 12. Rogers, Mikeal. PouchDB is a pocket-sized database. Github. [Online] [Citaat van: 9 april 2012.] https://github.com/mikeal/pouchdb. [13] 13. Heilmann, Chris. There is no simple solution for local storage. Mozilla hacks. [Online] 5 maart 2012. [Citaat van: 7 april 2012.] http://hacks.mozilla.org/2012/03/there-is-no-simple-solution-for-local-storage/. [14] 14. Tregubenko, Artemy. Test of localStorage limits/quota. [Online] [Citaat van: 7 april 2012.] http://arty.name/localstorage.html.
Streampaper 29
Vooronderzoek
Bibliografie
[15] 15. W3C Candidate Recommendation 22 December . Selectors API Level 1. [Online] W3C, 22 december 2009. [Citaat van: 2 april 2012.] http://www.w3.org/TR/selectors-api/. [16] 16. W3C Recommendation. Selectors Level 3. [Online] W3C, 29 september 2011. [Citaat van: 2 april 2012.] http://www.w3.org/TR/css3-selectors/. [17] 17. JQuery will not exist in future? Stackoverflow. [Online] 28 oktober 2010. [Citaat van: 2 april 2012.] http://stackoverflow.com/questions/4038878/jquery-willnot-exist-in-future. [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 2010. [Citaat van: 9 april 2012.] http://blog.whatwg.org/whats-next-in-html-episode-2-sandbox. [19] 19. Kohlschütter, Dr. What algorithm does Readability use for extracting text from URLs? StackOverflow. [Online] 21 11 2010. [Citaat van: 11 04 2012.] http://stackoverflow.com/questions/3652657/what-algorithm-does-readability-usefor-extracting-text-from-urls. [20] 20. RobertPitt. How do search engines find relevant content? StackOverflow. [Online] 19 10 2010. [Citaat van: 11 04 2012.] http://stackoverflow.com/questions/3967076/how-do-search-engines-find-relevantcontent. [21] 21. Readability™, LLC. Readability API Terms. Readability. [Online] 1 1 2012. [Citaat van: 11 04 2012.] http://www.readability.com/publishers/terms/. [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] 01 01 2012. [Citaat van: 11 04 2012.] http://boilerpipe-web.appspot.com/. [24] 24. Kearney, Jeff Barr & Bill. Distribution of RSS versions. Syndic8. [Online] 11 04 2012. [Citaat van: 11 04 2012.] http://www.syndic8.com/stats.php?Section=rss#tabtable. [25] 25. RSS Advisory Board. RSS Advisory Board. RSS 2.0 Specification. [Online] 30 03 2009. [Citaat van: 11 04 2012.] http://www.rssboard.org/rss-specification. [26] 26. Google Reader API Group. Pyrfeed. Unofficial GoogleReader API. [Online] 01 01 2012. [Citaat van: 11 04 2012.] http://code.google.com/p/pyrfeed/wiki/GoogleReaderAPI. [27] 27. Holmberg, Nils. Eye movement patterns and newspaper design factors. An experimental approach. sl : Lund University Cognitive Science, 2004. [28] 28. Nielsen, Jakob. F-Shaped Pattern For Reading Web Content. [Online] 17 april 2006. [Citaat van: 13 april 2012.] http://www.useit.com/alertbox/reading_pattern.html. Streampaper 30
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, 2003. [30] 30. Display Resolution. Wikipedia. [Online] [Citaat van: 16 april 2012.] http://en.wikipedia.org/wiki/Display_resolution. [31] 31. Resolution. [Online] [Citaat van: 17 april http://gs.statcounter.com/#resolution-ww-monthly-200903-201203.
2012.]
[32] 32. Kohlschütter, Christian. Boilerpipe. Google Code. [Online] 06 06 2011. [Citaat van: 11 04 2012.] http://code.google.com/p/boilerpipe/. [33] 33. Anirvan. Create Great Parser - Extract Relevant Text From HTML/Blogs. StackOverflow. [Online] 18 07 2009. [Citaat van: 11 04 2012.] http://stackoverflow.com/questions/1146934/create-great-parser-extract-relevanttext-from-html-blogs. [34] 34. W3Schools. RSS History. W3Schools. [Online] 01 01 2012. [Citaat van: 11 04 2012.] http://www.w3schools.com/rss/rss_history.asp. [35] 35. Doms, Martin. Using the Google Reader API. Martindoms. [Online] 21 01 2010. [Citaat van: 11 04 2012.] http://blog.martindoms.com/2010/01/20/using-thegoogle-reader-api-part-3/. [36] 36. Tweakers.net. Tweakers.net. [Online] 01 04 2012. [Citaat van: 01 04 2012.] http://www.tweakers.net. [37] 37. Nu.nl. Nu.nl. [Online] 01 04 2012. [Citaat van: 01 04 2012.] http://www.nu.nl. [38] 38. CNN. CNN.com. [Online] 01 04 2012. [Citaat van: 01 04 2012.] http://www.cnn.com. [39] 39. Engadget. Engadget.com. [Online] 01 04 2012. [Citaat van: 01 04 2012.] http://www.engadget.com. [40] 40. Interfacelift. Interfacelift. [Online] 01 04 2012. [Citaat van: 01 04 2012.] http://www.interfacelift.com. [41] 41. Readability™, LLC. Readability API. Readability. [Online] 1 1 2012. [Citaat van: 11 04 2012.] http://www.readability.com/publishers/api. [42] 42. arc90labs. arc90labs-readability. [Online] 06 07 2009. [Citaat van: 11 04 2012.] http://code.google.com/p/arc90labsreadability/downloads/detail?name=readability.js&can=2&q=. [43] 43. Gourdol, Arno. CSS3 regions: Rich page layout with HTML and CSS3. Adobe Developer Connection. [Online] 9 mei 2011. [Citaat van: 2 april 2012.] http://www.adobe.com/devnet/html5/articles/css3-regions.html. [44] 44. Adobe CSS Regions http://labs.adobe.com/technologies/cssregions/.
Labs.
[Online]
Streampaper 31
Vooronderzoek
Bibliografie
[45] 45. Pilgrim, Mark. Beyond named key-value pairs: Competing visions. Dive into HTML5. [Online] [Citaat van: 2 april 2012.] http://diveintohtml5.info/storage.html#future. [46] 46. Playground. HTML5 Rocks. [Online] [Citaat van: 2 april 2012.] http://playground.html5rocks.com/. [47] 47. Cederholm, Dan. Understanding CSS3 Transitions. A list apart. [Online] 16 november 2010. [Citaat van: 11 april 2012.] http://www.alistapart.com/articles/understanding-css3-transitions/.
Streampaper 32
Vooronderzoek
Bijlagen
BIJLAGEN BIJLAGE 1: LIJST VAN ARTIKELTEMPLATES 1x1 Foto Tekst 1x2 Tekst
Foto
Tekst
Tekst
Foto (landscape)
Foto (landscape)
1x3 Foto (landscape)
Foto (landscape)
Tekst
Foto
Tekst
Tekst
Tekst
Tekst
Tekst
2x1 Tekst Foto Tekst Tekst 2x2 Foto (landscape) Tekst
Foto (landscape) Tekst
Tekst Tekst
Foto Tekst
Tekst Tekst
Tekst Tekst
2x3 Tekst Tekst
Foto Foto
Foto Foto
Streampaper 33
Vooronderzoek
Bijlagen
Tekst Tekst
Foto (landscape) Tekst
Foto (landscape) Tekst
Tekst Tekst
Tekst Tekst
Foto Tekst
Tekst Tekst
Tekst Tekst
Tekst Tekst
3x1 Foto Tekst Tekst Tekst Tekst Tekst 3x2 Foto Foto Tekst
Foto Foto Tekst
Foto (landscape) Tekst Tekst
Foto (landscape) Tekst Tekst
Tekst Tekst Tekst
Foto Tekst Tekst
Tekst Tekst Tekst
Tekst Tekst Tekst
3x3 Tekst Tekst Tekst
Foto Foto Tekst
Foto Foto Tekst
Tekst Tekst Tekst
Foto (landscape) Tekst Tekst
Foto (landscape) Tekst Tekst
Tekst Tekst Tekst
Tekst Tekst Tekst
Foto Tekst Tekst
Tekst
Tekst
Tekst
Streampaper 34
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.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)
Streampaper 39
Stageverslag
BIJLAGE D
SPRINT DOCUMENTEN
Streampaper
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 Streampaper. 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 Streampaper
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 Streampaper 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. Streampaper 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 Streampaper. 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 Streampaper
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 Streampaper 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 Streampaper
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 Streampaper
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 Streampaper. 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 Streampaper
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 Streampaper. 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 Streampaper 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 Streampaper
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. Streampaper 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 Streampaper
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 - 6 Te weinig artikelen afhandelen = 2 o Bij tekort aan artikelen schermtemplate alsnog vullen en tonen - 2 Detailview simple text = 4 o Detailview opzetten - 2 o Layout maken - 2 View templates (text) = 6 o UML: View templates - 2 o Design Document: View templates - 2 o Herschrijven code: View templates - 2 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 - 6 Grid setDimensions = 4 o Grid: setDimensions toevoegen - 2 o Control: setDimensions aanroepen wanneer nodig - 2 Hardcoded variabelen = 2 o Fix hardcoded variabelen - 2 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 Streampaper
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 Streampaper. 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 Streampaper 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 Streampaper
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 Streampaper. 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 Streampaper
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 Streampaper. 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
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 Streampaper 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 Streampaper
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 Streampaper
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 Streampaper 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
Streampaper
Sprint 4 verslag
STANDAARD
Documentatie (12) o Sprintverslag schrijven (4) o Sprintverslag controleren (2) o Design document schrijven (4) o Design document controleren (2)
Tijd te besteden: 90u Tijd van de taken: 10 + 2 + 16 + 12 + 8 + 12 + 12 = 72u
4 Streampaper
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 Streampaper. 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 Streampaper 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 Streampaper 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 Streampaper. 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 Streampaper
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 Streampaper
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 Streampaper 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 Streampaper
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
Streampaper
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 Streampaper
Sprint 7 verslag
SPRINT 7 VERSLAG In dit verslag wordt gereflecteerd op de zevende sprint. Tijdens deze sprint is het grafische ontwerp van Streampaper 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 Streampaper. 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 Streampaper 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 Streampaper
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
Streampaper
Sprint 7 verslag BBC: lijst van andere artikelen uit content verwijderen (readability faalt) 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 o o
3 Streampaper
Stageverslag
BIJLAGE E
DESIGN DOCUMENTEN
Streampaper
Design Document Sprint 1
DESIGN DOCUMENT SPRINT 1: CLIENT
Streampaper 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 Streampaper 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 pattern1. In de UML diagrammen staan verwijzingen naar zowel JSON objecten als modules. Hier bij wordt het voorgaande mee bedoeld.
SAMENVATTING De client van Streampaper 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 2.
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).
2.1. 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.
2.2. 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.
2.3. CONTROL 2.3.1. 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 Streampaper 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 Streampaper geladen is en alle core initialisatie functies voltooid zijn. Main heeft een initialisatie methode waarin de client van Streampaper gestart wordt. Deze wordt als eventHandler aan de ready module gegeven.
2.3.2. 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 Streampaper
Design Document Sprint 1
2.3.3. TEMPLATES Het concept rond om templates is erg belangrijk voor de functionaliteit van Streampaper. Dit is gebaseerd op het vooronderzoek van Streampaper. 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. 2.3.3.1 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 Streampaper
Design Document Sprint 1
2.3.3.2. 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 Streampaper
Design Document Sprint 1
B. UML POSITIONED ARTICLE
C. UML TEMPLATES
5 Streampaper
Design Document Sprint 2
DESIGN DOCUMENT SPRINT 2
Dit document dient ter rapportage van de toegevoegde technische onderdelen van Streampaper 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 Streampaper
Design Document Sprint 2
2. STATIC SCREENTEMPLATES In design document 1 van Streampaper 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 Streampaper. 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 Streampaper
Design Document Sprint 2
BIJLAGEN A. UML CLIENT
3 Streampaper
Design Document Sprint 2
B. UML POPUP
C. UML TEMPLATES
4 Streampaper
Design Document Sprint 2
D. UML DUMMY DOM
5 Streampaper
Design Document Sprint 3
DESIGN DOCUMENT SPRINT 3
Dit document dient ter rapportage van de toegevoegde technische onderdelen van Streampaper 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 Streampaper 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 Streampaper
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 Streampaper 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 Streampaper 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 Streampaper 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 Streampaper hier gebruik van kan maken.
2 Streampaper
Design Document Sprint 3
2. ARTICLE MANAGER De manager van Streampaper 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 Streampaper
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 w1a, w2a en w3a (met a als artikelnummer), de invloedsfactoren van de criteria c1, c2 en c3 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 Streampaper 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 Streampaper gevaarlijke scripts uit te voeren. 4 Streampaper
Design Document Sprint 3
BIJLAGEN A. UML SERVER
5 Streampaper
Design Document Sprint 3
B. UML CLIENT
6 Streampaper
Design Document Sprint 4
DESIGN DOCUMENT SPRINT 4
Dit document dient ter rapportage van de toegevoegde technische onderdelen van Streampaper 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 Streampaper 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 Streampaper. 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 Streampaper 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 Streampaper
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 Streampaper, 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 Streampaper 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 Streampaper
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 Streampaper 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 Streampaper 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 Streampaper 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 Streampaper 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 Streampaper onbedoeld kunnen veranderen, een andere reden is dat aanwezige JavaScript code gevaarlijk zou kunnen zijn voor de gebruiker van Streampaper, 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 Streampaper
Design Document Sprint 4
BIJLAGEN A. UML CLIENT STATISCH
4 Streampaper
Design Document Sprint 4
B. UML CLIENT INTERACTION
5 Streampaper
Design Document Sprint 4
C. UML SERVER (OPSLAAN IN DATABASE)
6 Streampaper
Design Document Sprint 4
D. SERVER (OPHALEN UIT DATABASE)
7 Streampaper
Design Document Sprint 4
E. DATABASE STRUCTUUR
8 Streampaper
Design Document Sprint 5
DESIGN DOCUMENT SPRINT 5
Dit document dient ter rapportage van de toegevoegde technische onderdelen van Streampaper 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 Streampaper 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 Streampaper
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 Stackoverflow1.
3. 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 Streampaper 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 Streampaper 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 Streampaper 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 Streampaper weergeven.
6. ARTIKEL LENGTE Voorheen werd de lengte van een artikel op de Streampaper 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 Streampaper
Design Document Sprint 5
BIJLAGEN A. UML CLIENT INTERACTION
4 Streampaper
Design Document Sprint 5
B. DATABASE DIAGRAM
5 Streampaper
Design Document Sprint 5
C. UML SERVER OPHALEN
6 Streampaper
Design Document Sprint 5
D. UML SERVER OPSLAAN IN DATABASE
7 Streampaper
Design Document Sprint 5
E. UML CLIENT ARTICLES
8 Streampaper
Design Document Sprint 6
DESIGN DOCUMENT SPRINT 6
Dit document dient ter rapportage van de toegevoegde technische onderdelen van Streampaper 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 2.000 keer aangeroepen in plaats van 300.000. 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 Streampaper 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 Streampaper
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 ‘schermtemplates’ ‘gepositioneerde artikeltemplate’ in ‘schermtemplate’ ‘artikelen’ ‘dimension’ in ‘artikel’
Minimale grootte van de collectie 1 1
Maximale grootte van de collectie 100 18
18 1
18 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 300.000 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 Streampaper
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 Streampaper 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 Streampaper
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 Streampaper
Design Document Sprint 6
BIJLAGEN A. UML DATABASE
5 Streampaper
Design Document Sprint 6
B. UML SERVER: FEED CRON
6 Streampaper
Design Document Sprint 6
C. UML SERVER: READABILITY CRON
7 Streampaper
Design Document Sprint 6
D. UML SERVER: SAVE FEED
8 Streampaper
Design Document Sprint 7
DESIGN DOCUMENT SPRINT 7
Dit document dient ter rapportage van de toegevoegde technische onderdelen van Streampaper 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 Streampaper. 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 Streampaper op de tweede pagina en stond het roze balkje op een kleine afstand van de linkerkant van het scherm. Streampaper 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 Streampaper
Design Document Sprint 7
BIJLAGEN A. SCREENSHOT STREAMPAPER LAGE RESOLUTIE
2 Streampaper
Stageverslag
BIJLAGE F
IMPLEMENTATIE DOCUMENT
Streampaper
Implementatie Document
IMPLEMENTATIE DOCUMENT In dit document wordt uitgelegd hoe Streampaper 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. Streampaper 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 Streampaper 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 Streampaper. 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 1’.
1.1 CONTROL In de Control laag van de client vinden alle logica en bewerkingen plaats. Een instantie van Streampaper 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 Streampaper omvat, waarna we de belangrijkste Modules binnen de Control laag uitleggen waar de manager mee communiceert.
1 Streampaper
Implementatie Document
1.1.1 MANAGER De manager heeft de hoofd verantwoordelijkheid van Streampaper. Het is de instantie van Streampaper. 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.
1.1.2 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 3’.
1.1.3 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 Streampaper
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 Streampaper. 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 Streampaper 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 Streampaper recursief uitgewerkt waardoor het programma dat niet bij iedere nieuwe pagina hoeft te berekenen. De definitie van templates is te vinden in sectie 2.3.3 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 Streampaper
Implementatie Document
1.1.4 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.
1.1.5 TIMESPANS EN DATE Er bestaan vier verschillende tijdsblokken in Streampaper. 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 Streampaper, 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 Streampaper
Implementatie Document
1.2 MODEL De Model laag is de koppeling tussen de client en de server van Streampaper. 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 Streampaper.
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.
1.3.1 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 Streampaper 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 Streampaper, 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 Streampaper 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 Streampaper
Implementatie Document
1.3.2 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 Streampaper 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 3’.
1.3.3 SHORTCUTS Om Streampaper 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 Streampaper
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 Streampaper 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.
2.1.1 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 2.1.
2.1.2 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 Streampaper
2.1.3 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.
2.1.4 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.
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 Streampaper
Implementatie Document
2.2.1 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 2.6.
2.2.2 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
2.2.3 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 2.8.
9 Streampaper
Implementatie Document
2.2.4 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
2.2.5 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 Streampaper
Implementatie Document
2.2.6 ARTICLEFUNCTIONS Alle methoden met betrekking op de inhoud van artikelen zijn ondergebracht in ArticleFunctions. Hieronder vallen de methoden checkOnlyLink en getWebsite welke bekijken of een website uitgelezen moet worden en als dat zo is een object teruggeven wat naar de database geschreven kan worden. Andere methoden zijn cleanContent en removeSmallArticle, deze zorgen er voor dat bijvoorbeeld grote blokken links naar andere websites uit de inhoud verwijderd worden. De methode SetContentLength berekend het aantal tekens in de inhoud van een artikel en voegt dit toe aan het artikel. Dit gegeven wordt door de client gebruikt om het juiste blok voor een artikel te vinden. De klasse ArticleFunctions staat in Figure 2.10.
2.2.7 WEBSITEREADER De WebsiteReader word binnen de Cron service gebruikt om een Readability Bookmark aan te maken. Een Readability Bookmark is een aanvraag bij Readability om een website uit te lezen. Readability heeft tijd nodig om de site te verwerken, waardoor we later in de Readability service de inhoud bij Readability uitgelezen. De klasse WebsiteReader staat in figuur .
FIGURE 2.10: ARTICLEFUNCTIONS
FIGURE 2.11: WEBSITEREADER
2.3 READABILITY SERVICE Dit script wordt evenals de cron service door een Cronjob aangeroepen. De Readability service verwerkt alle opgeslagen aanvragen aan Readability. Per Readability aanvraag wordt de bijbehorende inhoud van de website opgehaald bij Readability. Deze opgehaalde informatie zal vervolgens opgeschoond worden en het originele korte bericht zal vervangen worden met de gevonden informatie. Het UML diagram van de Readability service is te vinden in bijlage C.
11 Streampaper
Implementatie Document
2.3.1 CRON READABILITY HANDLER De cron readability handler roept de Readability service aan. Deze handler zal vervolgens bij CronDatabase updateTop aanroepen. Deze methode haalt het laatst toegevoegde Readability verzoek uit de database en vervangt de inhoud van het bijbehorende artikel met de inhoud uit de website. Alvorens het vervangen van deze inhoud wordt deze opgeschoont met functies zoals cleanArticle uit ArticleFunctions. Nadat de inhoud van het artikel vervangen is zal het Readability verzoek worden verwijderd uit de Streampaper database en bij Readability. Voor details over Readability zie hoofdstuk 3 van het vooronderzoek.
2.4 SAVE FEED SERVICE De save feed servic kan een stream toevoegen aan een streamset. Deze service kan in het geval van een XML bestand het proberen te openen. Als het een valide xml bestand is zal de bijbehorende titel en icoon opgezocht en opgeslagen worden in de database. In het geval van een Outpost feed wordt bekeken of de gevraagde groep of gebruiker in de database bestaat. Zo niet dan word dit aangegeven, anders word ook deze feed in de database opgeslagen. Het UML diagram van de Save feed service is te vinden in bijlage D.
2.4.1 SAVE FEED HANDLER De client roept de save feed service aan door de save feed handler op te roepen. De save feed handler verwacht dat een aantal variabelen in de header meegestuurd worden. Deze variabelen zijn de feed zelf, het type feed, de streamset waaraan deze toegevoegd moet worden en de belangrijkheid van deze feed. Aan de hand van deze gegevens wordt de methode addFeed uit SaveFeed aangeroepen.
2.4.2 SAVEFEED De methode addFeed voegt aan de hand van het meegegeven type een feed to aan de database. Als het type Twitter of een van de Outpost mogelijkheden is word een vast icoon en titel aan de feed toegevoegd. Als het type RSS is wordt uit de XML gelezen wat de tot de feed behorende website is, hiervan wordt de titel en het icoon opgezocht en opgeslagen. Als de meegegeven gegevens incorrect zijn zal SaveFeed een foutmelding terug geven welke in de client afgevangen en weergegeven kan worden.
FIGURE 2.12: SAVEFEED
12 Streampaper
Implementatie Document
BIJLAGEN A. STREAM SERVICE Het UML diagram van de Stream service geeft de structuur van de service welke gevraagde artikelen uit de Streampaper database haalt en deze terug geeft aan de client.
Streampaper
13
Implementatie Document
B. CRON SERVICE Het UML diagram van de Cron Service geeft de structuur van de Cron Service. Deze service haalt uit verschillende feeds artikelen, verwerkt deze en slaat deze op.
Streampaper
14
Implementatie Document
C. READABILITY SERVICE Het UML diagram van de Readability Service geeft de structuur van deze service. Duidelijk is te zien dat de CronDatabase gebruik maakt van de websiteReader en de ArticleFunctions om vervolgens de verkregen informatie op te slaan.
D. SAVE FEED SERVICE Het UML diagram van de Save Feed service geeft aan dat deze service bestaat uit een ophalend en een opslaand deel.
Streampaper
15
Implementatie Document
E. CLIENT STATIC MODEL Een overzicht van alle klassen binnen de client. De klassen zijn opgedeeld in de lagen van de MVC architectuur.
F. CLIENT INTERACTION MODEL Het client interaction UML diagram geeft de interactie tussen de verschillende modules binnen de client weer. De manager is de belangrijkste module, deze bezit de belangrijkste modules over de verschillende MVC lagen van de client.
Streampaper
16
Implementatie Document
17 Streampaper
Stageverslag
BIJLAGE G
INTEGRATIE DOCUMENT
Streampaper
Integratie Document
INTEGRATIE DOCUMENT Dit document is geschreven om de integratie van functionaliteiten uit Streampaper in Outpost te ondersteunen. Streampaper is ontworpen als losstaande applicatie omdat het framework van Moxio een te hoge learning curve heeft en er zo nieuwe methoden en technieken gebruikt kunnen worden. Doordat vooraf, samen met de begeleider, besloten is de nieuwst mogelijke technieken te gebruiken is specifiek voor de browser Google Chrome gekozen. Chrome ondersteund van alle browsers de meeste nieuwe technieken, deze technieken zijn echter niet definitief en kunnen in de toekomst vervallen. Outpost is browser onafhankelijk en werkt met technieken die hedendaags in de meeste browsers beschikbaar zijn. Hierdoor is het interessant om te bekijken welke technieken in Streampaper niet gebruikt kunnen worden in Outpost en of daar alternatieven voor zijn. Naast gebruikte technieken zal Streampaper binnen het huidige Outpost gebruikt worden, dit heeft invloed op bijvoorbeeld de schermbreedte en hoogte. Advies wat betreft gebruik binnen Outpost wordt gegeven in het hoofdstuk ‘Outpost omgeving’.
1 TECHNIEKEN Binnen Streampaper worden een aantal technieken gebruikt welke nog in ontwikkeling zijn waarvan de eerste versie al gebruikt kan worden in onder andere de browser Google Chrome. Er wordt gebruik gemaakt van HTML5, wat niet in alle browsers werkt. Om oudere browsers te ondersteunen zullen deze HTML5 specifieke tags vervangen moeten worden met oude, goed ondersteunde varianten. Hieronder worden de gebruikte problematische technieken opgesomd en wordt voor iedere techniek een oplossing gegeven.
1.1 CSS REGIONS In Streampaper wordt gebruik gemaakt van CSS Regions. Regions geeft de mogelijkheid om een blok tekst over meerdere blokken te verdelen. Met CSS Regions kan de inhoud van een element in een ander element gezet worden. Daarnaast kan de inhoud van een element wat niet past in het huidige element in een ander element overlopen. Met deze techniek kunnen tekst kolommen gemaakt worden. Binnen Streampaper wordt Regions gebruikt om de tekst uit een artikel over meerdere kolommen te verdelen. Hierdoor kan de tekst een groot deel van het scherm beslaan en dankzij relatief smalle kolommen toch goed leesbaar blijven. Het gebruik van kolommen in Streampaper is te vergelijken met kolommen in kranten en tijdschriften. CSS Regions is vooralsnog alleen binnen nieuwe versies van Chrome beschikbaar, hiervoor zal een alternatief gevonden moeten worden.
1 Streampaper
Integratie Document
ALTERNATIEVEN Een alternatief is een Javascript module met een soortgelijke functionaliteit als CSS Regions. Dit zou zelf geïmplementeerd kunnen worden of er zou een externe library gebruikt kunnen worden. Er bestaan libraries in Javascript om kolommen te maken, er kan ook voor worden gekozen om het zelf te implementeren. Moxio heeft aangegeven dat iets dergelijks eerder is geprobeerd en niet succesvol is gebleken. Daarom is aangenomen dat het gebruik van een Javascript library geen degelijk alternatief is. Naast CSS3 en Javascript libraries zijn er, zover bekend, geen mogelijkheden om colommen te maken in een webpagina waarbij de tekst automatisch van de ene kolom in de andere overvloeit. Een aantal mogelijkheden voor een weergave zonder kolommen worden hieronder besproken. VASTE BREEDTE VOOR KOLOMMEN MET 1 KOLOM PER ARTIKEL Artikelen kunnen in enkel één kolom worden weergeven, met een globaal gelijke kolombreedte. Het scherm wordt in zoveel kolommen worden opgedeeld als dat de berekende grid breed is. Een kolom kan meerdere artikelen bevatten. Grote artikelen zullen hoog zijn terwijl kleine berichten als Twitterberichten klein weergegeven kunnen worden waarbij er meerdere boven elkaar staan. Deze veranderingen kunnen geforceerd worden door de voorgedefinieerde templates alleen over artikelen te laten beschikken welke de breedte van 1 kolom hebben. Daarnaast moet de CSS3 regels uit de betreffende view klassen gehaald worden. VARIËRENDE BREEDTE MET 1 KOLOM PER ARTIKEL Artikelen worden in dit alternatief ook in één kolom weergeven, hierbij kan de kolombreedte in tegenstelling tot het vorige alternatief wel van breedte variëren. Grote artikelen kunnen dan ongeveer twee maal zo breed worden weergeven als kleine artikelen. In dit geval zal de enkele artikelbreedte smaller moeten worden, zodat grote artikelen goed leesbaar blijven. De vooraf gedefinieerde templates mogen in dit alternatief alleen artikelen bevatten welke niet breder zijn dan twee. Daarnaast zal alleen de weergave van de artikelen veranderd moeten worden in Streampaper, de logica voor de indeling van het scherm blijft hetzelfde. AFBEELDING NAAST EEN ARTIKEL In combinatie met een van bovenstaande opties kunnen artikelmogelijkheden toegevoegd worden waarin links of rechts van een artikel een afbeelding wordt weergegeven. Hierdoor kunnen artikelen zonder dat de tekstbreedte te groot wordt alsnog breder weergegeven worden. Door een van bovenstaande mogelijkheden te gebruiken kan Streampaper gebruikt worden zonder gebruik van CSS Regions. De indeling van het scherm kan op gelijke manier als in Streampaper verlopen. De indeling van artikelen varieert aan de hand van de gekozen oplossing.
2 Streampaper
Integratie Document
1.2 IFRAME ‘SANDBOX’ ATTRIBUUT Binnen Streampaper worden externe websites weergegeven in een popup. Om dit te realiseren wordt gebruik gemaakt van een iframe. Het HTML element iframe geeft de mogelijkheid om binnen een webpagina andere webpagina’s te weergeven. Iframe bestaat al erg lang en wordt door alle browsers goed ondersteund. Om er voor te zorgen dat de externe pagina in een eigen omgeving gedraaid wordt en cross-domain veiligheidsproblemen omzeild worden1, bezit het iframe element het attribuut sandbox. Dit attribuut wordt echter niet door iedere browser ondersteund. De browsers Chrome en Safari ondersteunen het attribuut, daarentegen ondersteunt Internet Explorer het echter pas vanaf versie tien2. De veiligheid van de gebruiker hangt af van zijn of haar browser. Door de beperkte ondersteuning van sommige browsers raden wij het af om externe webpagina’s met behulp van een iframe (met sandbox) te gebruiken in Outpost.
1.3 HTML5 Bij het ontwerp van Streampaper is gebruik gemaakt van de opmaaktaal HTML5. De gebruikte elementen zijn alleen gebruikt voor duidelijkheid en in de toekomst betere bruikbaarheid van de code. Een voorbeeld is dat artikelen in een ‘article’-element geplaatst zijn. Voor betere bruikbaarheid bij oudere browsers kunnen deze HTML5 specifieke elementen allen vervangen worden door ‘div’-elementen.
2 OUTPOST OMGEVING Streampaper zal waarschijnlijk niet in de huidige vorm in Outpost worden weergeven. De huidige vorm mengt verschillende nieuwsberichten, blogposts en outpost-berichten. Streampaper geeft een overzicht van de belangrijkste en meest actuele berichten weer. Deze berichten worden zo groot mogelijk, indien mogelijk helemaal, getoond in het overzicht.
2.1 VASTE GROOTTE Het levert een aantal beperkingen op aan de werking van Streampaper. Streampaper krijgt een vaste grootte binnen Outpost en zal niet meer dynamisch hoeven te veranderen. Er kan meer rekening worden gehouden met de schermgrootte doordat deze van een vaste grootte is voorzien. De vaste waarde voor de kolombreedte kan bijvoorbeeld op precies één vierde van de schermbreedte gezet worden zodat er precies vier kolommen gemaakt worden. Doordat Streampaper nu op vaste schermgrootte draait zullen er minder templates nodig zijn.
2.2 DE VOORKEUR AAN KLEINE BERICHTEN In tegenstelling tot Streampaper, moeten berichten in Outpost niet te groot zijn, alleen een introductie, inclusief afbeeldingen, moet gevisualiseerd worden. Artikelen mogen niet meer dan 1 2
Integratie Document twee kolommen bevatten en niet hoger dan twee rijen zijn. Daarnaast krijgen berichten met één rij en/of één kolom de voorkeur boven grotere berichten. Dit tot gevolg dat aanzienlijk minder templates gedefinieerd hoeven te worden. Daarnaast moet de logica aangepast worden dat kleinere berichtende voorkeur hebben. In Streampaper krijgen grote berichten een hogere waarde. Dit kan aangepast worden in de methode waar het artikel gecombineerd met een bepaalde dimensie een waarde krijgt voor de match. Deze methode heet getArticleTemplateMatchValue en is te vinden in de module StaticTemplates.
2.3 TIJD NIET ALS RODE DRAAD Outpost wordt gebruikt binnen een bedrijf en dient als sociaal extranet. Werknemers moeten met behulp van Streampaper binnen Outpost op de hoogte blijven van het nieuws van en gerelateerd aan het bedrijf. In Streampaper is de tijd de rode draad voor de navigatie door het programma. Bij het opstarten zie je de meest actuele berichten, er kan dan terug in de tijd genavigeerd worden. Er bestaan informatiebronnen, bijvoorbeeld twitter, waarbij de berichten in een kort interval achter elkaar gepost worden. Het gevolg hiervan is dat deze veelal relatief oude, door de organisatie als belangrijk beschouwde berichten binnen Streampaper vooraan weergegeven moeten worden. Streampaper is opgebouwd als krant waarbij de tijd de rode draad is door het programma. Nieuwe berichten hebben de voorkeur, ook als berichten een hoge waarde van belang hebben gekregen. Binnen een paar pagina’s kunnen berichten wel naar voren schuiven op basis van een aantal waarden. Mocht Streampaper binnen Outpost gebruikt worden dan zal deze volgorde van voorkeur aangepast moeten worden. Dit is echter simpel aan te passen in de getArticlesAndCountByStreamSetId methode in de SourceReader klasse. Hier kan een sortering worden ingesteld in de query, waardoor de belangrijke berichten eerst teruggegeven worden.
2.4 GEVOLGEN VAN MEERDERE DRAAIENDE CRONJOBS Streampaper maakt gebruik van Readability om websites uit te lezen. Voor het uitlezen van Readability wordt een account gebruikt, hierop worden zogenaamde ‘bookmarks’ van websites gemaakt. Deze bookmarks kunnen later uitgelezen worden. Als Streampaper in Outpost geintegreerd word zullen mogelijk voor verschillende bedrijven verschillende Cronjobs ingesteld worden om websites uit te lezen. Het gevolg hiervan is dat als meerdere Cronjobs onder dezelfde account dezelfde website uit proberen te lezen geeft Readability een error terug en kan deze website niet verwerkt worden. Een voor de hand liggende oplossing is het aanmaken van bedrijfsspecifieke Readability accounts. Deze oplossing is daarentegen niet ideaal omdat dan aparte licenties aangevraagd zullen moeten worden. Hiervoor zal een oplossing gevonden moeten worden.
4 Streampaper
Integratie Document
3 LICENTIES In een korte tijd is er veel geproduceerd en dit is vanaf de grond af gebouwd. Er worden een aantal externe libraries gebruikt om sommige functionaliteiten uit handen te geven. Zo was er genoeg tijd om ons te richten op de interessante technische vraagstukken wat onze probleemstelling betreft. Hier worden de licenties van de gebruikte externe libraries besproken.
3.1 READABILITY Voor gebruik van Readability zal onderzocht moeten worden wat de beperkingen en mogelijkheden zijn. Readability geeft in de “Terms of Service”3 aan wat zij toestaan en wat niet. Readability geeft niet aan wat de precieze limieten zijn op het gebruik van de door hen geboden service, ze geven echter wel aan dat er een limiet is. Als of voordat dit limiet bereikt wordt kan een licentie genomen worden bij Readability, de kosten van deze licenties worden niet aangegeven en zullen afhangen van het type gebruik. Het is aan te nemen dat dit limiet bereikt zal worden bij gebruik binnen Outpost. Voordat Readability binnen Outpost gebruikt kan worden zal dus contact opgenomen moeten worden over eventuele licenties.
3.2 SIMPLE HTML DOM Deze externe bibliotheek wordt binnen Streampaper gebruikt om afbeeldingen uit tekst te extraheren. Simple HTML DOM is vrijgegevenonder de MIT License. 4 De MIT License geeft gebruikers van de software het recht om de software zonder restricties te gebruiken, aan te passen en te verkopen.5 Er hoeft dus geen actie ondernomen worden om deze software in Outpost te gebruiken.
3.3 KANEDO READABILITY Deze externe bibliotheek wordt binnen Streampaper gebruikt om verbinding met de Readability API te verkrijgen. Kanedo maakt gebruik Oauth, welke is vrijgegeven onder de MIT License.6 Kanedo wordt gehost door GitHub, GitHub geeft aan dat gratis accounts alleen gelden voor Open Source projecten. 7 Kanedo Readability is dus een open source project. Echter wordt verder niet aangegeven wat de beperkingen van gebruik zijn.
3.4 JQUERY JQuery wordt binnen Streampaper voor verschillende doeleinden gebruikt. JQuery is vrijgegeven onder of de MIT Licence, of GPL.8 Deze software mag dus zonder restricties worden gebruikt, aangepast en geredistribueerd.9
AANBEVELINGEN VANUIT SIG De code van het systeem scoort ruim 3 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code gemiddeld onderhoudbaar is. De hoogste score is niet behaald door een lagere score voor Unit Size, Unit Interfacing en Unit Complexity. Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Binnen de langere methodes in dit systeem, zoals bijvoorbeeld de 'RssReader::readStream'-methode, zijn aparte stukken functionaliteit te vinden welke ge-refactored kunnen worden naar aparte methodes. Commentaarregels zoals bijvoorbeeld '//add first image to array' of een vrijstaand if-else block om een variabele zoals "$article['content']" te vullen zijn een goede indicatie dat er een autonoom stuk functionaliteit te ontdekken is. Ook aan de client kant zijn hier voorbeelden van te vinden, zie bijvoorbeeld de functie 'getScreenArticleMatch' gedefinieerd in 'templates.js' Het is aan te raden kritisch te kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen. Voor Unit Interfacing wordt er gekeken naar het percentage code in units met een bovengemiddeld aantal parameters. Doorgaans duidt een bovengemiddeld aantal parameters op een gebrek aan abstractie. Daarnaast leidt een groot aantal parameters nogal eens tot verwarring in het aanroepen van de methode en in de meeste gevallen ook tot langere en complexere methoden. Wat hier opvalt is niet zozeer het aantal parameters, maar het doorgeven van paren van parameters zoals bijvoorbeeld een "$timeWindow" en een "$limit" of een "$articles" met een "$source_id". Het lijkt erop dat deze paren samen een concept vormen. Het introduceren van een expliciete modellering van dit concept kan er voor zorgen dat toekomstige ontwikkelaars een beter beeld hebben van de concepten die gebruikt worden binnen de applicatie. Voor Unit Complexity wordt er gekeken naar het percentage code dat bovengemiddeld complex is. Ook hier geldt dat het opsplitsen van dit soort methodes in kleinere stukken ervoor zorgt dat elk onderdeel makkelijker te begrijpen, makkelijker te testen en daardoor eenvoudiger te onderhouden wordt. In dit geval komen de meest complexe methoden ook naar voren als de langste methoden, waardoor het oplossen van het eerste probleem ook dit probleem zal verhelpen. Over het algemeen scoort de code gemiddeld, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. Als laatste nog de opmerking dat er geen (unit)test-code is gevonden in de code-upload. Het is sterk aan te raden om in ieder geval voor de belangrijkste delen van de functionaliteit automatische tests gedefinieerd te hebben om ervoor te zorgen dat eventuele aanpassingen niet voor ongewenst gedrag zorgen.
