�ݺ�ߣ

Editor's Notes

• #3: Jag har jobbat med webben I en eller annan form sedan 1998. Som webbig applikationsutvecklare I Lotus Notes-plattformen, byggt intranät, en evenemangsguide som bisyssla, varit Episerver-utvecklare, och de senare åren som webbstrateg och webbanalytiker. Jag har fördelat tiden till hälften inom VGR&Sahlgrenska och andra hälften som konsult (ofta med offentlig sektor som kund).
• #4: Det här är agendan för min presentation. Jag passar väl redan nu på att tacka Hans för inbjudan och möjligheten att presentera dessa tankar. Bakgrunden är att vi inom objektet ”Kommunikation via webbtjänster” känt behov av att införa mätbarhet på de leveranser som görs. Så baserat på de krav vi verksamhetspersoner känner att vi har på oss från allmänheten och lagstiftarna har vi tagit fram denna bruttolista med punkter. Jag är medveten om att alla yrkesgrupper har sina checklistor och många av er har säkert några stycken sedan tidigare. Anledningen till att jag är här är dels att förankra dessa punkter med fler inom VGR men självklart att möta er respons och tankegångar. Vad vet jag, det kanske saknas något. Förhoppningen är att vi i en snar framtid kan börja använda en checklista liknande denna, att välja ut de punkter som ska gälla för varje projekt och på så vi etablera en regional webbstandard. Denna checklista är på inget sätt helig eller att betrakta som bud givna av en högre makt. Om man I projektet kan argumentera för att låta bli en punkt eller tolka den annorlunda är det I sin ordning. Poängen är att man nog bör dokumentera sina avsteg, och stämma av dem med alla inblandade. >>
• #5: Sedan årsskiftet är det olagligt att diskriminera någon med funktionsnedsättning att använda ens webbplats. Exempelvis blev Göteborgs Universitet nyligen anmälda till Diskrimineringsombudsmannen för att blinda elever inte kan använda IT-systemen på egen hand – exempelvis att ta emot meddelanden från sina lärare via kurssystemen. Nu kunde man ju varit en god människa och brytt sig redan innan det blev en lag  Detta är vad tillgänglighet handlar om. Studier visar att när en användare väntat en sekund på svar från en webbplats tappar de koncentrationen. Vi som utgivare av ett system kan alltså orsaka att samtliga av våra besökare får en mental funktionsnedsättning, vi försämrar deras kognition, de glömmer bort vad de höll på med. Det är inte god användbarhet eller ändamålsenligt. VGR består till stor del av glesbygd, dessutom bör väl alla tjänster vi erbjuder fungera när de behövs? Med andra ord ska allt fungera åtminstone drägligt på en mobil uppkoppling. Mobilnäten är lite olika bra. Kolla in bredbandskollen.se och se hur den sämst uppkopplade tredjedelen har det I en glesbygdskommun på 3G-nätet. Dagens så kallade responsiva webbplatser har gjort detta oerhört mycket värre än tidigare. Nu är det inte ovanligt med 2 Mb Javascript-filer för att snyggt bläddra mellan de jättestora bilderna som väger in på 10 Mb. Pröva gärna att stå I svampskogen med svajig 3G eller EDGE-uppkoppling och leta giftinformation på en sådan webbplats… På tal om att nå ut till användare av webben så är det viktigt att spela med på Googles spelregler. De tycker att prestanda är viktigt, både för deras egen skull så det går snabbt att indexera så stor del av ens webbplats som möjligt på kort tid men också för att Google anser att en snabb och webbplats är bra för kvalitetindikatorer. Alltså har Google valt att lägga in det I sin ranking. >>
• #6: WCAG står för Web Content Accessibility Guidelines. Det är standardorganisationen W3C som tagit fram WCAG. Numera finns det en version 2. Riktlinjen finns I tre olika nivåer beroende på vilken ambition man har, det är nivå A till trippel-A, där trippel-A är en mycket strikt efterlevnad. Den 24:e april (2015) kommer Google börja straffa de som har dålig användbarhet. Som utvecklare är det väl inte givet att man ska stå som ansvarig för samtliga punkter inom WCAG, men finns ingen person som gör användbarhetstest bör man välja ut de viktigaste punkterna och testa själv. >>
• #7: Det finns massor med sätt att mäta svarstid och inladdningstid. I detta fallet är det den tiden det tar ute I användarens webbläsare vi pratar om. I bildexemplet används Firefox-pluggen LORI, och på 4G ute I glesbygden igår tog det 1,7 sekunder till den första byten hamnade I webbläsaren, 3,3 sekunder för att ladda in sidan komplett (då låg mycket redan I webbläsarens cache…). Här skulle man ju förstås vilja att det tog max en sekund. Det är ju tre olika figurer inblandade I detta; - de som fixar med driften (och de servrar som erbjuds) - dels utvecklarens - självklart också redaktörens bidrag >>
• #8: Google Pagespeed fångar allt möjligt som kan vara problematiskt för en användare. Bland annat en del teknikaliteter, som på bilden, att filer inte har förväntad livslängd satt (vilket väl är en del av headern I HTTP?) men också grafiska saker som att länkar har för små träffytor (alla har inte samma motorik som en fullt frisk tonåring…). Pagespeed finns som webbtjänst, som tillägg till både Firefox och Chrome, men som API att programmera mot för den som vill kolla _massor_ med sidor eller automatisera kontrollen. >>
• #9: För utvecklaren är det smidigt att kunna dela upp CSS-filerna. Ofta är det en fil för struktur/gridsystemet, en ytterligare för hur det hela ska flöda om på olika stora skärmar, en med lite färger. Inte omöjligt att det tillkommer en CSS-fil för varje jQuery-plugin man har, bildbläddrare, modala dialogrutor etc. Detta är alltså utvecklarens behov av ordning och reda. Användaren däremot kan inte bry sig mindre om hur vi vill ha det med våra filer – bara det går fort. Problemet är att vid sämre omständigheter, exempelvis om man har en svag mobil uppkoppling, kan det dröja lång tid innan en fil börjar skickas. Förra semestern hade jag själv cirka 3 sekunder I ping som bäst på 3G-nätet där jag har sommarstugan. Det är ju onödigt att av lättja eller okunskap (som I VGR-exemplet på bild) då använda 6st CSS-filer om de lika gärna kan slås samman och minska latensen till en sjättedel för just CSS-filerna. >>
• #10: Samma som punkten innan. Hur många Javascript-filer _behöver_ man verkligen? I många utvecklingsverktyg finns idag så kallad bundling, då slås dessa filer samman till färre. Det är en bra idé. I just detta exempel på Vgregion.se används 15 Javascript-filer. Multiplicera det med 3 sekunders svarstid så förstår du hur trött man blir på att vänta på en regional webbsida i solstolen i Dalsland. >>
• #11: När det gäller bilder I gränssnittet så används ju ett flertal tekniker av webbdesigners för att uppnå god prestanda och kvalitet. Äldsta varianten är något som kallas CSS Sprites – det är en bildkarta, det vill säga att man har en större fil med många bilder I istället för många mindre filer. Sedan visas bara en bild I taget med hjälp av CSS. Dessutom kan man jobba med webfonts, egna teckensnitt helt enkelt, som tar hand om ikoner och sådant som man med dagens högupplösta skärmar gärna vill ska ha skalbar storlek. En framtida variant är SVG-filer. SVG är ett vektoriserat bildformat som dessutom kan programmeras – bland annat så att en bild som visas på liten skärm inte har en massa svåra detaljer, men att samma bild visas med många detaljer på en större skärm. En och samma fil alltså. >>
• #12: Finns 4 moment att gå igenom när man skapar en bild som ska ut på webben: 1. En bild ska vara i den storlek som visas på webbsidan (här är det lite stökigt om webbplatsen är “responsiv” då man ofta får tumma på denna regel). 2. Vara sparade i det��format som möjliggör minst filstorlek��i relation till bildkvalitet (oftast PNG 8-bitar för illustrationer, JPG för fotografier). 3. Vara��sparad för webben. Då kan man välja hur hårt man optimerar bilden – vilket kan göra bildens filstorlek väldigt mycket mindre. 4. Körts genom programvara för��icke-förstörande optimering. Exempel på bilden där bilder I flera fall blivit hälften så stora utan att försämra bildkvaliteten.
• #13: Ofta får man med extra teckensnitt om man väljer något ramverk för design, som Twitters Bootstrap exempelvis. Första frågan är ju om man enligt den grafiska manualen ens får lov att introducera andra teckensnitt än de som beslutats. Jag kanske enbart talar för mig själv, men inte tusan kan jag tillräckligt om typografi för att ens börja argumentera med identitetsansvarig på kommunikationsavdelningen. Kan du? Om man nu mot förmodan ändå ska ha ett extra teckensnitt är det ju bra om det ser ut som det är tänkt (på fler datorer än ens egna utvecklingsmaskin). Font Family Reunion hjälper dig att tala om huruvida Arial Black ser ut som det ska på en äldre Iphone (san-serif blir serifen Times…). Dessutom så blir ju webbplatsen något trögare att ladda hem om det tillkommer en fil för teckensnittet. Är det värt det? >>
• #14: Om man följer de rekommendationer som sätts av W3C ökar chansen att man slipper ångra sig senare, och målar in sig I ett hörn (host, Internet Explorer 6). Vendor-prefixes I CSS är vad vissa idag menar är samma oförståndiga kodning. Det kan vara något man inte bör hålla på med, då de per definition är en enskild tillverkares test av en kommande CSS-teknik. >>
• #15: Minifiering går ut på att ta bort alla mellanslag, tabbar och radbryt som inte måste vara där för att koden ska fungera. Det där som gör koden lättare att läsa för utvecklare gör filerna större, det vill säga långsammare att ladda ner. Det är inte särskilt mycket, men I extremfall har jag sett att filer kunnat göras hälften så stora genom minifiering. Kör man med kontinuerlig integration får man kolla om ens byggserver fixar minifiering löpande. >>
• #16: Om man ställer in webbservern att skicka textfiler I komprimerat format går det oftast mycket snabbare att föra över filen. Inte sällan har filer minskats till en tiondel av sin okomprimerade storlek. För större filer kan detta göra rätt mycket skillnad. För att kolla upp detta kan man som första steg gå till Google Pagespeed. Är det riktigt illa varnas det där. Vill man granska detaljer funkar Yahoos Yslow bra om man kollar under GZ-kolumnen. >>
• #17: För den med ambition kan man ju välja att följa prioritetsnivå 2 också. På nivå 2 tillkommer saker som även de kan kännas uppenbara, som att man ska ta hand om etablerade webbadresser på ett vettigt sätt. Se webbriktlinjer som tips på hur det borde vara. Det är framtaget av de främsta I Sverige inom respektive nisch, så har ditt projekt inte exceptionellt god anledning att avvika från riktlinjerna är det bara att följa dem. >>
• #18: Många filer på en webbplats kommer aldrig uppdateras. Det är något man bör planera för. Går man till Googles Pagespeed och får skäll för att webbplatsen inte använder webbläsarens cache vet man att man bör göra bättre ifrån sig. När tror du filen för jQuery 2.1.3 kommer uppdateras? Antagligen aldrig. Den kommer ersättas av en fil med annat namn. Man kan jobba likadant med sin logotyp, favicon, css-filer med mera. Versionsnumrera dem och om de mot förmodan behöver uppdateras ersätts de av en version med högre nummer. Då kan man både få ihop att inte skicka samma gamla logga på nytt till återkommande besökare, samtidigt som det inom 30 dagar går att uppdatera filer (som ligger I webbläsarens cache). Rent tekniskt är detta något man som .NET-kodare fixar I webbservern IIS eller I web.config, är man däremot av UNIX-tappning görs inställningen I filen .htaccess I webbplatsens hemkatalog. >>
• #19: Japp, det var checklistan det. Tack för mig  Om det finns tid (Hans) så kanske någon vill diskutera eller reflektera kring detta. (Annars finns jag kvar här under förmiddagen om någon vill droppa en kommentar senare.) (Jag fattar pennan).