Checklista inför release av en sajt

När man släpper nya sajter kan det vara bra med en checklista så man inte glömmer viktiga saker

Här är en bra checklista för vad man bör gå igenom när det börjar närma sig släpp av en ny sajt och förstås gärna redan under /Utvecklingen.

Lägga in Google analytics (eller motsvarande)

Det är ganska självklart att kunden (och vi själva) vill veta hur många besök sajten har, oftast får man frågan en månad eller två efter sajten är släppt eller ofta just efter t.ex. en tv-reklam i samband med en ny sajt. Har man glömt lägga in analyskoden har man inga siffror att ta fram i efterskott. Eftersom google analytics är gratis finns ingen anledning att vara utan denna statistik.

Skapa en favicon.ico

Det är lätt att glömma denna lilla ikon under /Utvecklingen men den tillför mycket för den slutgiltiga känslan så lägg några minuter på att skapa en. Ladda upp loggan på http://www.favicon.cc/ så har du en bra start.

Lägga in felloggning på lagom nivå

När sajten väl är släppt så dyker ofta fel upp som man inte fått i /Utvecklingsmiljön eller ens testmiljön och att då ha en log som hjälper en att felsöka när något uppstått men minst lika viktigt, gör det möjligt att se hur ofta ett problem uppstått så man kan skilja nån som vid ett enda tillfälle gått in med en gammal browser eller gamla cachade javascript och ett fel som uppstår för varenda besökare. Man får heller inte glömma att sajten kanske får tusentals besökare om dan och då får man förstås inte logga alltför mycket heller.

DNS även utan www

Ovana användare skriver alltid addresser med www först, t.ex www.tekniken.nu, men vi vanare användare skriver gärna bara tekniken.nu och att då få DNS-fel gör att man lätt tror att man har fel adress.

Prestanda med fullt material och i servermiljö

När man utvecklar en sajt har man ofta bara en del av materialmängden som kommer finnas på sajten tiden efter release. Att testa sajten ganska tidigt med den mängden material som förväntas finnas där åtminstone närmaste åren kommer göra att man slipper i panik försöka fixa prestandaproblem med en sajt som är ute live och kanske dessutom har mängder av besökare. Det händer dessutom att saker som fungerar snabbt i en /Utvecklingsmiljö kan bli olidligt långsamt i livemiljön pga små saker som t.ex. pingtider. Märker man såna tendenser innan release finns det fortfarande möjligheter att lägga in cachningar och dylikt för att minimera problemen.

Testa i alla vanliga webbläsare

Det är lätt att man gör ändringar sent i projektet (kanske sista minuten t.o.m) och glömmer testa i alla populära webbläsare. Vi utvecklare använder gärna de senaste versionern av alla webbläsare, men då missar man ofta de mest använda versionerna. Normalt sett fungerar internet explorer 8 ganska likt de andra stora webbläsarna och då glömmer man lätt att IE7 är mycket vanlig och i vissa kundgrupper även IE6. För att försvåra testningen ytterligare så beter sig IE8 i kompabilitetsläge inte helt och hållet som IE7. Lösningen på ie testning heter IE Tester http://my-debugbar.com/wiki/IETester/HomePage.

Testa med rätt version även på servern

Redan under /Utvecklingstiden bör man förstås hålla koll på vilka versoner av allt som används på den server som sajten skall drivas på, men det är lätt att glömma att även små skillnader som t.ex servicepack och dylikt kan orsaka små subtila buggar som nästan är omöjliga att felsöka. Optimalt är att parallellt sätta upp en stage miljö på samma server som sajten skall /Driftas på så det finns några dagar där man kan testa den nya sajten i samma miljö som den senare skall användas i.

Hantera gamla länkar

Ofta skapar man inte en helt ny sajt utan en ny version av en redan befintlig sajt och då får man inte glömma att det ofta finns mängder av länkar på andra ställen som numera inte går till rätt ställe. Det går givetvis inte tvinga alla andra sajter och sökmotorer att länka rätt men man kan oftast se till att hantera gamla länkar snyggare än bara ett 404-felmeddelande. Uppdatera de länkar ni kan och för lägg till funktion som fångar upp de gamla adresserna och skickar vidare till motsvarande nya sida med en 301 redirect (dvs moved permanently) t.ex genom en smartare 404-sida. Genom detta får man dessutom behålla sökmotorpoäng t.ex Googles PageRank.

Känns sajten bra?

Om sajten varit klar några dagar innan release så kommer ett lugn sprida sig när sajten går live. Om buggar fixas in i sista minuten så kommer det kännas som en sämre release även om antal buggar är samma. Om sajten får ”marinera” några dagar utan att nån hittar nån allvarlig bugg så blir alla gladare när den släpps.

Se sajten genom andras ögon

När utvecklare tittar på en sajt under /Utveckling så är det för att hitta och lösa problem. En vanlig användare tittar inte på marginaler och Javascript-funktioner utan försöker hitta information eller lösa en uppgift. Det är lätt att som utvecklare störa sig på småsaker som en vanlig användare aldrig skulle märka. Genom att antingen själv försöka använda sajten eller ännu hellre låta nån annan faktiskt använda den så får man ett annat perspektiv och oftast en mer positiv bild.

Tommy Söderström
2009-12-10