Det är dyrt att vara riktigt agil. Eller?

Att vara agil när man jobbar i Scrum betyder (bland annat) att man efter varje iteration har lyckats bygga en ny fungerande och värdefull version av produkten eller systemet, som går att leverera till kund eller butik om man så önskar. Men att vara riktigt agil kostar. Eller?

För att varje sprint ska resultera i en nytt levererbart inkrement ställs det stora krav. Först måste vi ha lyckats bryta ner våra features så att de är tillräckligt små så att flera får plats i sprinten. Och med ”få plats” menar jag att man hinner med allt för att gå från idé till leverans, dvs. varje enskild feature ska designas, kodas, testas, dokumenteras och sammanfogas med helheten (allt enligt vår Definition of DONE for User Stories). Vi behöver dessutom känna oss trygga i att resten av systemet fortfarande fungerar och att vi inte har introducerat nya buggar.

Om vi förutsätter att vi har kontroll över våra IT-system och inte har några externa beroenden vad gäller testmiljöer och servar (vi är inte beroende av externa köer för att få något jobb gjort) så är det ändå inte helt trivialt att få till en leverans varje sprint.

Låt oss titta på ett exempel på hur en treveckorssprint skulle kunna se ut.

.

Först och främst har vi våra Scrum möten. Syftet med dessa är att planera (läs analysera) vad vi ska göra härnäst (Sprint Planning), hur vi på bästa sätt koordinerar oss inom teamet (Daily Scrum), fånga upp feedback så att vi kan förbättra processen (Sprint Retrospective) samt lära oss vad som kan göra produkten ännu bättre (Sprint Demo). Sista fredagen är dessutom en sprint-fri dag där teamet kan hämta andan och samla ny energi till nästa sprint.

.

För att vi med trygghet ska vilja lämna ifrån oss den nya versionen (som innehåller våra nya features) vill vi dessutom känna oss trygga i kvalitén. Detta gör vi med att arbeta med att fixa buggar och verifiera buggfixar (Hardening). Vi vill också testa igenom systemet i sin helhet för att försäkra oss om att vår nya kod inte saboterat någon annan funktionalitet eller försämrat någon egenskap (såsom t.ex. prestanda). Denna testning inleds typiskt med en uppgradering av acceptancetestmiljön. Hela teamet hjälps åt att testa. Vad man fokuserar på klurar man ut som team genom att göra en riskanalys. Det kan t.ex. innebära en balans mellan körning av delar av regressionstestsviten plus identifierade Exploratory Testing sessioner. Var man lägger sin testfokus beror på var man ser att riskerna finns, vilka moduler som utsatts för förändring etc. När så slutgiltig paketering är gjord och en sista hand har lagts på dokumentationen är teamet redo att leverera den nya versionen till kund eller förvaltning. Tada!

.

Det som återstår är vårt utrymme för utveckling. Det är alltså denna tid som finns tillgänglig för design, kodning, testning och dokumentation av nya features. Det vi påbörjar ska hinna slutföras innan ”Code-freeez-mode” slår till.

.

Sådärja. Då har vi lyckats visualisera de olika typerna av arbete som pågår under en sprint. Låt oss visualisera hur de olika formerna av arbeta står i proportion till varandra…

.

Nu kan man såklart ställa sig två frågor:

	Vilket arbete tillför värde?
	Vilket arbete är waste?

.

Eftersom exemplet inte förtäljer hela historien så kan vi bara spekulera. ”Development” och ”Scrum Meetings” tillför såklart värde, det är här vi skapar, analyserar, planerar, designar och koordinerar oss. Sedan kan vi såklart ställa oss frågan – kan Scrum mötena (såsom sprint planeringen) göras effektivare och kortare?

”Hardening” borde inte behövas om vi byggde kvalitet från början. Detta är tydlig waste. Packaging, miljöuppgraderingar etc. döljer också troligtvis en hel del waste – detta borde gå att automatisera.

Den gemensamma testinsatsen som sker i slutet av sprinten… är den waste? Jag skulle argumentera för att den inte är det – här bygger vi kunskap om hur systemet som helhet mår efter att vi infört våra förändringar och bygger beslutsunderlag till frågan – ska denna release gå till kund?

.

.

Det som blir uppenbart av att titta på bilden är dock att själva utvecklingen av nya features som mest utgör hälften av arbetet. Mycket tid går åt till ”annat”. Man skulle kunna påstå att Velocityn blir ”lidande” (antal features eller Story Points per sprint) eftersom vi anstränger oss för att vara helt agila. Från ett leveransperspektiv är det så att varje sprint levererar ett färdigt och komplett increment, dvs. Definition of DONE för User Stories är komplett och lämnar inget till senare. ViVET att vi hela tiden är redo för leverans till kund. I exemplet ovan ”vet” vi att vi har levererat 24 features när deadline närmar sig.

.

Att vara helt agil i Scrum kostar så det är enkelt att lockas till att flytta ut vissa kriterier från Definition of DONE for User Stories till Definition of DONE for Release. Dvs. vi skjuter viss testning, viss dokumentation, etc. till en ”release sprint”. Detta ökar såklart vår Velocity (antalet features per sprint), men vi är å andra sidan inteleveransredo varje sprint eftersom vi har skjutit arbete och risk framför oss. Faktum är att release sprinten troligtvis inte alls blir en strikt timeboxad sprint eftersom vi inte vet hur mycket arbete och risk vi skjutit framför oss förrän vi sitter ner och planerar (och exekverar) den sprinten. Med detta uppläggkanske vi levererat 30 features när deadline kommer, men det troliga är att vi kämpar med testning, buggfixningar och refactoring av tekniska svagheter långt förbi deadline. Vad ännu värre är att vi har skapat en rejäl fördröjning i feedbacken mellan test och kodning då vissa tester inte körs förrän så mycket som fem sprintar senare.

.

Att inte vara DONE utan att först uppnå DONE i release sprinten öppnar upp för följande:

	Vi riskerar missa deadline
	Vi introducerar waste genom långa feedbackcyckler (både vad gäller test och kvalitet men även kundens feedback om funktions värde)
	Vi skjuter på tekniska risk och missar chansen att hantera problem tidigt
	Vi tappar den sanna insynen i hur vi faktiskt ligger till (vi vet inte vad som är klart och vad som är ”work in progress” eftersom vi inte testat klart)
	Vi förlorar styrförmåga. Innan vi helt kan styra om fokus måste vi genomföra release ”sprinten”.

.

Så är det dyrt att vara agil, eller är det kostsamt att inte vara det?

.

Definiera syftet

Webbutvecklarvärlden har mycket att lära sig från den mobila världen, enligt min åsikt är den största gåva Steve Jobs gav oss när han introducerade Apples iPhone 2007 inte deras App Store eller själva telefonen i sig utan det nya fokus på syftet för varje interaktion och varje tecken eller bit av grafik som presenteras i den användarcentrerade och skräddarsydda app-upplevelsen. Denna fokusering på det huvudsakliga syftet och endast det väsentliga är en stor del (om inte den största) av Apples mobila framgång och har sedan gradvis spridit sig till samtliga aspekter av mobil utveckling, webb och även andra former av användarupplevelser.

Det som vi således ska ta till vara på när ett nytt webbprojekt startas är att som första steg alltid definiera syftet med webbsajten eller applikationen. Detta kan definieras så pass enkelt som

• att sälja produkter av en viss typ

till lite mer spretiga mål så som

• strategisk varumärkesutveckling
• företags- och kontaktinformation
• att användas som en integrerad del i säljprocessen med existerande kunden
• initiera en första personlig kontakt med potentiella kunder

Det viktigaste är dock inte hur målen och syftena ser ut, bara att de är tydligt definierade så att man i nästa steg enkelt kan få en översikt och använda dessa som utgångspunkt. Enklast är att skriva upp dem i en lista så att man en klar separation mellan de olika målen. Genom att tydligt definiera syftet kan sedan informationsarkitektur, innehåll (information eller storyline i ett spel till exempel) och användarupplevelse tas fram genom iterationer och konceptualiseringar med målet att producera en fungerande prototyp. I fallet med en webbsajt betyder det att prototypen ska vara byggd i HTML och målplattformen, ofta ett CMS så som WordPress eller via ett fristående MVC-ramverk för lite mer specialiserade webbsajter.

Börja med syftet och tänk ut innehåll, användarupplevelse och den grafiska designen utifrån det, inte tvärt om.

EPiServer Meetup med Template Foundation & Commerce R2

För att avsluta en fantastisk vårsäsong stod Capgemini som sponsor för EPiServer Meetup i Öresundsregionen.

Capgemini med Henrik Sellberg, Johan Sjöström och Per Lorin presenterade ett pågående projekt med EPiServer Commerce R2 och delade med sig av nyttiga erfarenheter.

EPiServer MVP Ted Nyberg från Ted & Gustaf AB hade tagit sig ner från Stockholm för att ge en introduktion av det egenutvecklare ramverket EPiServer Template Foundation vilket bl.a. tillhandahåller basfunktionalitet för grundläggande funktioner såsom hantering av nyheter, kontakter, RSS-flöden, integration med Live Writer, med mera.

Stort tack till våra sponsorer under våren – vi ser fram emot fler givande meetups till hösten! Glad sommar!

Agil utveckling av webbprojekt

Jag gillar agila utvecklingsmetoder (även om det är lite av en underdrift, jag är riktigt stort fan av dessa metoder), problemet med de vanligaste metoderna är att de inte fungerar så bra när hela projektet är mindre än en enda sprint och utvecklingsteamet kan räknas på en eller två fingrar. Detta är fallet för många ganska enkla webbplatser vilka ofta kan byggas av en ensam utvecklare på mindre än en månad. Så, jag har funderat på hur man tar några av de idéer som gör SCRUM så effektivt och hur man tillämpar dem på mindre webbprojekt.

Mitt förslag är att istället för att använda tid för att bryta upp utvecklingen använda ett antal steg som bygger på den naturliga utvecklingen av en webbsajt, från idé till prototyp till färdig produkt. Dessa steg är alla utformade för att resultera i någonting som kan användas som bas till följande steg så att inget arbete går förlorat längs vägen. Syftet är fortfarande detsamma som sprintarna i SCRUM, att ge produktägaren och övriga intressenter en chans att få insyn i utvecklingen och anpassa lösningen baserat på hur väl prototyperna fungerar samt att påskynda utvecklingen genom ökad effektivitet. Varje steg ska resultera i ett demo och bör itereras till dess att produktägaren är nöjd med resultatet.

Följande steg används för att bryta upp utvecklingsarbetet: idéfas, innehåll, funktionell prototyp, grafisk design och färdig webbsajt. Jag väljer att skapa och bygga en prototyp med det riktiga innehållet innan grafisk design av den enkla anledningen att jag tycker att användarupplevelsen är viktigare är ögongodis. Genom att anpassa grafiken till funktionen istället för att anpassa interaktionsdesign och innehåll till en grafisk profil är slutresultatet fokuserat på användaren och användarupplevelsen.

Under idéfasen bestäms syfte och grundläggande informationsarkitektur av webbplatsen. Resultatet kan till exempel ske i form av beskrivande texter och/eller skisser. Det är viktigt att alla som kommer att bidra till utveckling, innehåll, underhåll, grafisk design och framförallt produktägaren deltar i detta arbete så att ingen känner sig utanför och kopplas in först när de inte har en chans att påverka inriktningen av arbetet (eller man måste göra om en massa tidigare arbete för att tillgodose de nya behov och tankar som dyker upp).

Med en klar bild över syfte och informationsarkitektur tas innehållet fram, det behöver inte vara satt i sten men ju närmare det är att vara det slutgiltiga desto lättare blir arbetet för interaktions- och den grafiska designern. Sanningen är att det inte bara blir enklare, det är en förutsättning för att kunna skapa en funktionell prototyp som motsvarar den verkliga användarupplevelsen och en grafisk profil som motsvarar den slutliga webbsajten.

Den funktionella prototypen skapas på samma plattform som den färdiga sajten kommer att utvecklas i och driftas på. På så sätt går inget arbete förlorat och det blir inga överraskningar av typen att prototypens funktionalitet och lösningar inte fungerar i verkligheten. Av denna anledning använder jag inte wireframing och rekommenderar inte andra att använda det heller, att sätta upp en grundläggande struktur och grafisk layout i HTML går på några minuter och gör man detta kan man sedan börja producera kod som kan användas i den färdiga lösningen utan att behöva göra om arbetet. Gör en koll så att prototypen fungerar som på alla relevanta plattformar och anpassa layouten till formatet på olika enheter om det är önskvärt (vilket det borde vara).

När arbetet med den funktionella prototypen är klart används den som mall för den grafiska designen. Det är viktigt att inga designbeslut tas förrän nu (trots att det alltid är bra att ha med sig idéer och tankar från idéfasen och framåt) av den enkla anledningen att den grafiska designen ska användas för att förstärka och förtydliga användarupplevelsen och innehållet, inte tvärt om.

Efter att prototypen har förskönats har vi i princip en färdig webbsajt, det som återstår är att knyta ihop paketet genom att minska antalet förfrågningar som krävs för att visa en sida via sammanslagning av JavaScript- och CSS-filer, lägga ihop bilder till sprites, skapa sajtkartor och finjustera innehåll, sidstruktur och användarupplevelse. Nu är det också dags att testa webbplatsen i stödda webbläsare och plattformar och se till att allt fungerar som förväntat. Det bör ju dock inte vara några problem eftersom webbstandarder har använts under utvecklingen och vi bara stödjer webbläsare som anammar webbstandarder, eller?

Genom att kontinuerligt arbeta på en prototyp på målplattformen är vi reda att sätta in den i produktion när annars arbetet ska börja. Som en bonus har vi haft tid att verkligen testa funktionaliteten, informationsarkitekturen och basera den grafiska designen på innehåll och användarupplevelse. Denna metod är inte bara tillämpbar på nya projekt, den kan lika gärna anpassas till att utveckla nya funktioner och flöden i befintliga webbplatser så länge de bryts ner till att vara mindre än en normal sprint tar i anspråk.

Sogeti värdar för lyckat SharePoint User Group-möte

I torsdags var Sogeti värdar för Sweden SharePoint User Group i Stockholm (SSUG). SSUG är en användarförening som regelbundet ordnar träffar för att dela med sig av erfarenheter och kunskaper kring SharePoint.

Mötet inleddes av Markus Persson från Sogeti SharePoint Center i Stockholm, som berättade om Umeå Kommuns beslutsstödslösning på SharePoint 2010. Lösningen är en vidareutveckling av den lösning som byggdes åt Socialtjänsten på SharePoint 2007. Lösningen ger beslutsfattare på olika nivåer i kommunen möjlighet att följa upp och analysera nyckeltal  som berör verksamheten. En riktigt trevlig lösning som Microsoft ofta lyfter fram som referenscase.

Andra talare på evenemanget var Peter Nicks från Microsoft som pratade om hur man kan växa i sina befintliga SharePoint-lösningar och dra nytta av alla funktioner och tjänster som plattformen erbjuder. Måns Barklund från Microsoft berättade även om Project Server 2010 och gav en häftig demo på vilka möjligheter som finns i denna produkt.

Mer info om Umeå Kommuns lösning (2007-versionen) finns här:
http://www.microsoft.com/sverige/business/kundreferenser-artikel.mspx?Id=ffabb53f-a45b-44c0-a837-afbc653c8e7a

SharePoint User Group
http://www.ssug.se/

 

Lite bilder från kvällen
Foto: Henrik Palm

 

 

 

Sökdrivna webbsajter

Under ett säljseminarium för en sökmotorleverantör såg jag statistik att 26% av alla besökare på webbsidor börjar sin interaktion med att gå direkt till sökfältet och skriva in en sökfråga. Det här kan låta som ett stort incitament till att helt skippa den vanliga navigeringen och istället förlita sig på en sökdriven design och att verkligen optimera sin interna sökmotor och de resultat som den visar beroende på vilka frågor som ställs. För mig så säger det att den största mängden användare (74%) föredrar att använda traditionell navigering.

Vidare säger statistiken inte varför användarna har valt att gå direkt till sökfältet för sin första interaktion. Jag tror att många skapar sig en överklick av sidans navigationselement och ser de inte vad de letar efter då så många sajter är alldeles för överbelamrade nyttjar de sökfunktionaliteten. Så problemet är inte den traditionella navigeringen (som trots allt de flesta föredrar) utan det är mängden information, hur den presenteras och informationsarkitekturen.

Att få användarna av tjänsten att hitta rätt information handlar framförallt om att reducera bruset.

Vad vi verkligen kan lära oss från förespråkarna av sökdriven navigering är hur de dynamiskt använder sökfrågor och förslag. En vanlig funktion är att föreslå populära sökningar eller till och med visa de allra populäraste sökningarna när man går till sökfältet. Den här informationen borde användas kontinuerligt för att iterativt optimera den konventionella navigeringen på sidan!

Det finns såklart tillfällen när man inte vill eller kan reducera mängden information och i de här fallen kan sökdriven navigering vara rätt väg att gå. Det betyder dock att användarna behöver veta vad de letar efter och man måste vara försiktig så att man inte uppfinner nya sätt att navigera bara för sakens skull, att följa vedertagna konventioner skänker en stor trygghet. Alla projekt har olika förutsättningar och mål, men för att gå ifrån den traditionella navigeringen behöver man se till att det skänker ett mervärde som överstiger tröskeln med att inte använda vedertagna normer. Men se framförallt till att använda information från sökmotorn för att se vad användarna egentligen vill hitta.

Mobil webb och appar

De flesta mobilitetsutvecklingsgurus jag har lyssnat på (inklusive vår egen Andreas Sjöström) hävdar att appar är det självklara valet för direkt interaktion via mobila enheter. Den mobila webben är då valet för indirekt användning, som en landningssida när någon klickar på en länk med en mobil enhet i Twitter, Facebook, mail eller liknande. Men, det börjar bli trångt och svårt att sortera i appmarknaderna och jag tror att appar har ett snävare användningsområde. Tänk till, vilket är snabbast och kräver minst ansträngning av användaren

• Öppna app-affären
• Hitta den önskade appen
• Klicka på installera (eller "Free" och sen "Install")
• Klicka på accetera villkoren (eller skriva in sitt lösenord)
• Vänta på att appen ska laddas ner och installeras
• Hitta appen någonstans på enheten
• Använda appen till att tex hitta information eller bli road

eller

• Öppna den mobila browsern
• Skriva in URL-addressen
• Använda webbsajten till att tex hitta information eller bli road

Mobila appar kan bara ses som direkt kommunikation när användaren redan har en etablerad relation med företaget eller tjänsten och regelbundet använder den aktuella appen. För nya relationer eller om användaren inte redan har installerat appen är det en tids- och energikrävande omväg där det krävs att ansträngningen är värd besväret när väl appen används. Mer än 26% av alla appar används bara en gång innan de tas bort och jag misstänker att andelen som bara används en gång och sedan bara ligger och skräpar är mycket större än så.

Det finns ingenting som hindrar oss från att presentera information lika fint och i många fall lika snabbt i en mobil webbsajt som i en native app, vi tvingar inte användaren att söka, installera, ta upp minnesutrymme samt skräpa ner skärmytan och listor för i många fall en enda interaktion. En annan fördel är att man inte behöver gå igenom en ansökningsprocess och hoppas på att ens innehåll kommer att godkännas för att ens kunna tillhandahålla sin app utan man kan skapa fritt och för detta är webben ett mer passande medium som dessutom fungerar på de allra flesta mobila plattformar.

Jag säger inte att det inte finns fall där appar inte är att föredra framför webben, det finns många sådana exempel där affärer där man handlar återkommande, avancerad grafik i spel och nyttoappar med integrationer som inte går att hantera via JavaScript är bland de första som dyker upp i mitt huvud.

Vad jag menar är att appar framförallt är lämpliga när de ger ett mervärde som inte är möjligt i en webbaserad applikation och när användaren redan har en relation till företaget eller tjänsten så att de litar på att programmet och innehållet är värt besväret. För enklare tjänster kan många gånger en mobil webb vara mer passande helt enkelt på grund av att den har en mindre tröskel än nativa appar, andra gånger är en paketerad HTML-baserad app som går via de vanliga distributionskanalerna lämplig. Som med så många andra saker gäller det bara att ha sitt sinne öppet och se till alla tillgängliga alternativ.

Tänka utanför ramarna

Sitter och hämtar inspiration för idéer till en ny webbplats. Surfar runt på de länkar jag har och upptäcker ett strålande exempel på kreativt tänkande. Varje år så utses de bästa webbplatserna av The Webby Awards. Förra årets vinnare inom kategorin "Personal Services" visar verkligen förmågan att tänka utanför ramarna.

När jag först klickar på länken till Booneoakleys webbplats tror jag att jag hamnat fel. Varför i hela friden hamnar jag på YouTube??? En film drar igång och jag inser att filmen faktisk är själva webbplatsen. Klickar man på den navigation som finns drar man igån ett klipp i klippet så att säga. Till en början känns det mycket märkligt, men efter ett tag börjar jag inse det genialiska. Som användbarhetsdesigner så mässar jag ständigt om vikten av att användarna ska känna igen sig, men faktum är att för att kunna gå vidare i utvecklingen måste det finnas ett visst mått av kreativitet. Så, hatten av för utvecklarna av Boonoakleys "webbplats". De kan konsten att tänka utanför ramarna. Jag är inte säker på hur det fungerar ur marknadsföringsperspektiv men de står helt klart ut från sina konkurrenter.

 

Errors, faults and failures = fel?

För några veckor sedan laddade jag ner ett par kandidat-uppsatser som alla handlade på ett sätt eller annat om test. Det var titlar som Model Based Testing for Non-Functional Requirements, QA Activities in Agile, Investigating Exploratory Testing in Industrial Practice, etc. Alla väldigt fascinerande (antar jag efter vad titlarna och abstrakten säger) men den som fångade min blick var Testarbetets svåra val. Främst för när jag läste abstrakten slogs jag av denna smocka till mening:

”Nackdelen med test inom systemutvecklingsorganisationen är att test tar mycket tid.”

Vilket direkt reser nackhåren. Visar sig sedan när man läser abstraktet samt resten av uppsatsen att den tolkning jag direkt hoppade till inte var den som menats med meningen. Dra mening ut ur kontext, etc. Samtidigt ”gärna hitta fel”:testare::”gillar laga mat”:kock. Iallafall. Det i uppsatsen som fick mig att börja tänka är när de börjar prata om errors, faults och failures och mer specifikt när de börjar diskutera dessa med sina intervjupersoner.

För att färska upp minnet är error, faults och failures helt enkelt olika sätt att kategorisera något som inte står rätt till i test-objektet. Om vi säger testobjektet är en applikation så  genom bristfällig kod uppstår en error som ger ett fault i en funktion som sedan skapar en failure i applikationen.

De tar upp dessa definitioner redan i sin ordlista, där jag fnyser initialt åt onödan i att definiera dessa termer. När jag strosar nedåt i uppsatsen ser jag att denna mentala fnysning har repeterats av en av intervjupersonerna:

”Under alla mina år inom test (drygt 10) har jag aldrig hört någon prata om Error, Faults och Failures annat än på utbildningar…”

”Precis!” tänker jag. Varför behöver man ha specifika termer när alla vet vad fel innebär? Men. Är det så lätt? Direkt kopplas min förra testledares röst på:

”Vem är alla? Delar dem verkligen din syn? Hur vet du det?”

Om vi säger att alla inblandade i testprocessen börjar använda sig av dessa termer. Att alla ”testare” börjar använda sig av samma termer. Om alla test-specialister börjar säga ”jag tror jag har hittat en error” till utvecklaren. Borde detta inte leda till en bättre kommunikation i utvecklings-teamet?

Jo jag vet, sjukt retoriskt. Men då kommer följdfrågan, om detta är självklart, varför används inte dessa och/eller liknande termer?

Webbplats utan struktur. Är det möjligt?

Jag har länge funderat på om det är möjligt att skapa en webbplats utan att ha en traditionell struktur. Som användbarhetsexpert kan jag tycka att det är en omöjlig ekvation. För några år sen skulle det vara en omöjlighet, men de senaste månaderna har detta dykt upp gång på gång. I uppstarten för ett aktuellt projekt väcktes frågan: "Ska vi strunta helt i den traditionella strukuren och istället förlita oss på sök?". Svaret då blev nej eftersom vi trodde att användarna skulle känna sig osäkra utan en traditionell navigering, men efter att sett en presentation på Site Seeker Summit undrar jag om användarna kanske är mogna för detta.

Det var Jerry Hedlund, en före detta kollega från Uppsala, som presenterade en lösning de gjort för www.milkproduction.com. När man surfar in på webbplatsen är skillnaden inte så väldigt stor mot det traditionella men det intressanta är att allt innehåll, bortsett från en toppnavigering så finns det ingen traditionell navigering. Allt innehåll byggs upp utrfrån det sätt redaktörena taggat innehållet. Utmaningen här är att på ett pedogogiskt plan få redaktörena att köpa detta. I detta fall så var det enkelt eftersom det bara fanns en huvudredaktör som i stort sett la in allt material själv. Men det föder i alla fall en tanke. Studier de senaste åren visas att över 80% av användarna (i alla åldersgrupper) ser sök som ett förstaval när de besöker en webbplats, varför inte då stödja detta beteende fullt ut?