5. Moment05 - Teori

Även om denna kurs till största delen är väldigt praktisk med skapande så måste vi också lära, och förhålla, oss till viss teori. Vi kommer i detta moment kika på internets utveckling fram tills idag, du skall få fundera på internets påverkan på samhället och vi skall lära oss de lagar som vi behöver förhålla oss till när vi utvecklar applikationer till webben.

5.1 Momentets mål

I varje moment så jobbar vi mot ett eller flera mål som skolverket har satt upp i varje kurs.

5.1.1 Centralt innehåll

• Webben som plattform, dess historia och samhällspåverkan.
• Processen för ett webbutvecklingsprojekt med målsättningar, planering, specifikation av struktur och design, kodning, optimering, testning, dokumentation och uppföljning.
• Riktlinjer för god praxis inom webbutveckling.
• Interoperabilitet genom att följa standarder och testa på olika användaragenter.
• Applikationer som fungerar oberoende av val av användaragent, operativsystem eller hårdvaruplattform och hur tillgänglighet uppnås även för användare med funktionsnedsättning.
• Kvalitetssäkring av applikationens funktion och validering av kodens kvalitet.
• Terminologi inom området webbutveckling.

5.2 Internets historia

Vi skall gå igenom webbens historia och för detta använder vi oss av informationen på den utmärkta svenska webbplatsen internetmuseum.se. Denna sidan innehåller en mängd utvalda artiklar om internets historia med start på 1960-talet och framåt. Varje artikel belyser ett visst ämne, fenomen eller händelse som har påverkat internets utveckling. Många artiklar innehåller grymma filmer om hur det var och några av de saker som forskare och användare förutspådde har slagit in eller inte alls varit i närheten av att slå in. Vi får ha respekt att internets utveckling har gått enormt snabbt, framförallt hur det används på senare år, vilket gör att vi hela tiden måste lära oss att tänka om och tänka nytt. I början av 2000-talet tyckte de flesta att det var helt onödigt att ha en kamera i telefonen, våra krav ser lite annorlunda ut idag. På Internetmuseum finns det också en kortare sammanfattning av det viktigaste om internets historia. Jag tycker att du skall ta avstamp i uppgiften genom att läsa igenom denna text.

En annan historiebeskrivning är att leta upp historiken kring en specifik webbsida. Det kan du göra genom tjänsten archive.org. Det kan ju vara intressant att se hur en webbsida har utvecklats över tid, kanske din egen, kanske den sidan som är din favorit idag eller så finns det ju möjlighet att ta fram en nyhetstjänst en viss dag för att se hur nyheterna presenterades då.

5.3 Kvalitetssäkring av webbsidans funktion och kodens kvalitet

Vi har flera gånger pratat om vilken hjälp vi får av webbläsare som tolkar koden åt oss ifall vi skriver inkorrekt kod. Det finns både för- och nackdelar med detta. Fördelen är att sidan visas i webbläsaren medan nackdelarna kan vara flera, dels så kanske sidan visas upp på ett annat sätt än vad vi vill eftersom den tvingas tolka den kod som inte är korrekt. Även om sidan visas korrekt i en webbläsare så är det ingen garanti att den tolkas på samma sätt i en annan webbläsare. Därför är det så viktigt att testa dina applikationer i flera webbläsare, eller användaragenter som det också kallas.

Här är det också på sin plats att höja en liten varning för inbyggda servrar i de IDE som ni använder. De har absolut sin funktion och nytta men denna server kan redan innan webbläsaren gör en tolkning av din sida förändra de fel som du eventuellt har skrivit. När du sedan lägger upp sidorna på Miss Hosting så blir du inte räddad av detta och då fungerar inte din site som det är tänkt. Vanliga problem som de inbyggda servrarna tolkar till din fördel är felaktiga länkar (mappar och undermappar som inte har den strukturen som du hade tänkt) eller problem med versaler/gemener i filnamn.

I detta avsnitt så skall vi gå igenom en mängd tester och kontroller som behöver genomföras för att vara säker på att webbsidan håller bra kvalitet.

5.3.1 Validering av kod

I denna kurs så jobbar vi med de två grundteknikerna HTML5 och CSS. Eftersom vi inte naturligt får någon hjälp i webbläsaren med validering av dessa tekniker så måste vi göra det själva.

5.3.1.1 HTML5

validator.w3.org är en bra valideringstjänst för din HTML5-kod. På sidan kan du välja att klistra in kod (vilket är smidigt när du utvecklar sidan lokalt på din dator), ladda upp en fil eller skriva in en länk till en sida som ligger på en webbserver uppkopplad till internet. När du sedan klickar på check så valideras kod och ger dig information om saker som är direkt felaktiga, som bör ändras eller som kan ändras. Valideringen sker mot standarden men ibland kan det finnas anledning att inte följa standard. Ju duktigare du blir på både kodning och felsökning desto bättre beslut kan du ta om vad som behöver ändras.

En funktionalitet som jag använde mig av på en tidigare version av kursolle var att i sidfoten ha en länk till denna validering, i den nuvarande versionen har jag ingen sidfot och då har jag också tagit bort dessa länkar. Men så här såg länken ut, https://validator.w3.org/nu/?doc=http://www.kursolle.se/weuweb01/moment05.php.

5.3.1.2 CSS

jigsaw.w3.org/css-validator är en tjänst från samma organisation, W3, som ovan och den funkar på i stort sett samma sätt fast nu valideras CSS. Du skall för så bra kod som möjligt göra så få avvikelser från standard som möjligt och det kan vara skönt att få koll på saker som är obsolete vilket innebär att det är attribut som inte längre används och snart inte finns stöd för. Länken till denna sidans validering.

Men är det ok att inte rätta de fel som validatorerna ger? I normalfallet så vill jag ju att du använder validatorerna som en hjälp att skriva bra och effektiv kod. Genom att lära sig reglerna så förstår man och vilka regler man kan bryta mot/avvika ifrån och när detta kan göras. Att använda kod från andra tjänster innebär ibland att vi får acceptera fel. Att försöka hänvisa till fel och hitta på en anledning till att inte rätta dessa fel är fel sätt att ta sig an utmaningen.

Typiska varningar som ni kommer stöta på när ni valderar HTML-kod är att validatorn klagar på att ni inte använder rubriker i vissa element som t.ex. section och article. Orsaken till detta är att enligt HTML5-standarden så skall dessa element direkt innehålla en rubrik. Så hur löser vi det?

1. Vi lägger in en rubrik som vi egentligen inte vill ha.
2. Vi lägger in en rubrik som vi sedan väljer att inte visa mha css-instruktioner som t.ex. visibility: hidden.
3. Vi byter ut alla element som ger oss problem mot div-element och skiter i HTML5-standarden.

Vilken av lösningarna gör oss nöjda? Ingen av dem så vi låter varningen vara men vi kommenterar varför vi låter den vara i vår utvärdering och validering av våra projekt.

5.3.2 Användaragenter

Användaragenter innebär i vår värld olika webbläsare i en dator men också webbläsare i smartphones och tablets. För att göra ett fullständigt test i varje användaragent så behöver du testa i alla webbläsare och i alla typer av smartphones/tablets men det är ju orimligt för våra applikationer. Jag kommer dock kräva att du alltid testar på minst två olika webbläsare där den ena skall vara Google Chrome som är den som flest sidvisningar görs i, och sedan en webbläsare till, förslagsvis Mozilla Firefox då många av de som bestämmer standarden för html/css arbetar inom Mozillas organisation.

Safari och Edge är också många som använder och en stor anledning till detta är att det är standardwebläsare i Apples produkter samt Microsoft Windows. Så gör du inget aktivt val så är det dessa webbläsare som du får. Tyvärr så har bägge dessa företagen rent historiskt hittat på lite egna lösningar vilket gör dem problematiska att testa i.

De stora webbläsarna har idag alla någon form av utvecklarläge där det finns ett antal hjälpverktyg för webbutvecklare. Dessa verktyg behöver du lära dig att dra nytta av. När du ändå håller på kika om du kan hitta läget där du kan se hur din landing page ser ut i en smartphone eller en tablet. I nästa moment kommer vi lära oss bygga webbsidor som är mer anpassade för olika användaragenter.

När du kollar hur din webbsida ser ut i ett mobilläge från utvecklarverktyget så kanske du tycker att den ser väldigt bra ut och är synnerligen mobilanpassad men är det verkligen så? För att testa detta så använder vi oss av verktyg för att få en objektiv bedömning. Google har ett verktyg som testar om din webbsida anses mobilanpassad. Numera så är kursolle godkänd utifrån mobilanpassning. Om sidan inte blir godkänd så får jag hjälp med hur jag kan åtgärda problemen. Vi återkommer till detta verktyg och denna validering i nästa moment.

5.3.3 Prestanda

En sak som är viktig när vi bygger våra webbsidor är att skapa förutsättningar för att vi skall ha så kort laddtid på våra sidor som möjligt. En viktig del är att skriva korrekt kod, html och css, vilket vi kontrollerat genom att validera koden. Men det finns fler sätt att optimera våra sidor och det skall vi kolla på i detta avsnitt.

Fördelen med detta avsnittet är att det är relativt enkelt att med hjälp av olika verktyg på nätet. Jag kommer länka till fyra olika verktyg som alla är bra och som testar lite olika saker och ger råd på lite olika sätt. För att du skall känna vilken du tycker passar dig bäst så vill jag att du testar alla fyra iaf en gång var. När du sedan testar dina webbsidor så handlar det ju hela tiden om att du skall få den bästa hjälpen för att göra bra förändringar som gör dina sidor snabbare.

• Google PageSpeed Insights, denna ger dig förklaringar och tips på svenska. Börja gärna med den.
• GTmetrix, gör flera analyser på samma gång och betygsätter din sida på flera olika områden vilket gör det enklare att avgöra prioritetsordningen för vad som skall åtgärdas. Ger dig också en bra förståelse för vad som eventuellt bromsar upp en sida då du tydligt ser i vilken ordning olika saker sker.
• Webpagetest, liknar GTmetrix.
• Pingdom, överskådlig men ej så detaljerad. Den talar om vilka prestandaproblem som finns generellt men inte exakt var dessa finns. Länken är ändå med eftersom Pingdom ofta används och hänvisas till när det pratas om prestanda.

Alla fyra tjänsterna analyserar din sida och ger olika riktvärden för vilken prestanda en webbsida har och ger sedan tips på hur du kan förbättra denna. Nu kommer du märka att detta är verktyg som även används av professionella webbutvecklare. Här kommer du kunna få tips att ta bort kod som inte används, tex css och javascript, minifiera koder, välja andra bildformat, komprimera bilder och också komprimera text och kod (vilket ligger utanför denna kursen). Här gäller det att se vad som kan åtgärdas av oss för tillfället.

Det enklaste vi kan göra i denna kursen är att skriva kompakt kod, ta bort onödiga mellanslag och mängder av luft, gör att det går fortare att hantera filen och skicka den till användaren. Här pratar vi om korta tider men om vi kapar tid i varje led så finns det faktiskt en hel del tid att vinna. Vilka verktyg kan vara intressanta att använda här?

• dirtymarkup.com för att snygga till kod i html/css/javascript vilket gör koden lättare att läsa men den tar också bort onödig luft. Skriver du extremt tight kod så kan en körning i detta verktyg göra att det tillförs luft.
• Compress HTML kan användas ifall du vill ta bort alla white spaces i din html-kod.
• csscompressor.com tar bort mycket, eller all luft i ett css-dokument. Hur mycket du vill ta bort handlar om vilken läsbarhet som du vill ha. I ett färdigt projekt där det finns många eller stora css-filer så kan det vara värt att låta verktyget ta bort all luft och göra det så litet, och oläsligt som möjligt, för att optimera hastigheten. Verktyget kan också göra en decompress så att koden blir lättare att läsa.
  Andra verktyg som gör liknande saker htmlcompressor.com, jscompress.com, miniwebtool.com/html-compressor. Det finns fler på nätet, hitta din favorit.

5.3.4 Bildformat

När du har gjort prestandatester på dina webbsidor så återkommer hela tiden olika kommentarer om bilder och hur detta påverkar sidans prestanda. Då är det väl dags att vi kikar även på detta.

5.3.4.1 Bilder i rätt storlek

En bild som du publicerar på en webbsida bör visas upp i den storlek som bilden har. Om du väljer att skala ner en stor bild till ett mindre format på webbsidan så får du två problem när det gäller prestanda.

1. En större bild, som innehåller fler pixlar, tar mer utrymme och kommer då också behöva mer bandbredd för att skickas till användaragenten där den skall visas upp.
2. En bild som inte är i rätt storlek måste förminskas, eller förstoras, i webbläsaren vilket tar onödig tid.

Enklast är att skapa filen i rätt storlek från början i något bildredigeringsprogram men det finns också tjänster online för detta. Två av dessa tjänster är resizeimage.net och picresize.com.

5.3.4.2 Optimera bilder

Det finns flera olika bildformat som kan användas på webben. De klassiska formaten är JPEG/PNG/GIF/SVG. PNG och JPEG lämpar sig bäst för bilder, GIF lämpar sig för enklare bilder som logotyper och SVG är vektorbaserad vilket gör att den är knivskarp även om man zoomar in den bilden.

Om du använder bilder som finns på nätet så är du oftast fast i den typ som bilden redan har. Att konvertera från ett bildformat till ett annat är sällan bra då du tappar kvalitet i konverteringen. Mer intressant är det om du skapar egna bilder i tex Photoshop och kan välja vilket format och kvalitet som bilden skall visas i. Läs mer om de vanligaste bildformaten.

Det som däremot är intressant att göra med redan skapade bilder är att optimera dem och se till att bilden får en mindre filstorlek. Denna funktionen finns i de flesta bildredigeringsprogram men det finns också tjänster på nätet för detta. Här brukar jag använda tinypng som komprimerar både jpeg och png på ett bra sätt.

5.3.4.3 Nya bildformat

I statistik som httparchive.org presenterar så är ca 50% av den totala vikten på en hemsida bilder. De äldre bildformaten har vissa problem med komprimering och det har länge varit tydligt att det är dags att uppgradera bildformaten. De senaste åren har de kommit fram flera olika exempel på nya bildformat och Metamatrix har en bra genomgång av dessa. De nya formaten är inte kompatibla med alla webbläsare i skrivande stund (oktober 2020) men kompabiliteten kommer bli bättre och bättre ju längre tiden går. WebP är det bildformatet som för tillfället har kommit längst då det endast är Safari som inte har full kompabilitet. Vill du se vilka format som är kompatibla med vilken webbläsare så finns den infon här.

5.3.4.4 Bildredigeringsprogram

Denna kursen kräver inte att du skall kunna skapa egna bilder i ett bildredigeringsprogram men om du är van vid att använda tex PhotoShop så har du ju där ett verktyg som hjälper dig att skapa content till dina webbsidor. Det finns användbara program såsom Gimp att ladda ner från nätet och det finns också flera kraftfulla photoshopliknande onlineapplikationer.

5.4 Tillgänglighet

Tillgänglighet på webben innebär att vi hela tiden måste tänka på att skapa webbsidor som är anpassade för alla, eller i varje fall för så många som möjligt. Ungefär var femte person har behov av någon form av tillgänglighetsanpassning, här hittar du exempel på användare med olika behov.

W3.org tar fram Web Content Accessibility Guidelines (WCAG) 2.0 som är guidelines för hur webbplatser med god tillgänglighet skall skapas. Det finns flera checklistor på nätet att följa och många av dem är inriktade på att myndigheter och organisationer skall vara förutseende att skapa god tillgänglighet för sina webbplatser. Om vi kikar på WCAG 2.0 Riktlinje så finns det fyra stycken principer som den som utvecklar eller publicerar information på webben bör ta hänsyn till.

Princip 1: Möjlig att uppfatta – Information och komponenter i ett användargränssnitt måste presenteras för användare på sätt som de kan uppfatta.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#perceivable, avläst 2020-09-28.

Princip 2: Hanterbar - Komponenter i ett användargränssnitt och navigering måste vara hanterbara.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#operable, avläst 2020-09-28.

Princip 3: Begriplig - Information och hantering av användargränssnitt måste vara begriplig.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#understandable, avläst 2020-09-28.

Princip 4: Robust - Innehåll måste vara robust nog för att kunna tolkas på ett pålitligt sätt av ett brett spektrum av olika användarprogram, inklusive hjälpmedel.
https://www.w3.org/Translations/WCAG20-sv/WCAG20-sv-20121023/#robust, avläst 2020-09-28.

Innan vi kikar vidare lite mer detaljerat så behöver vi få koll på vissa saker. DOS-lagen är det första och det står för Lag om tillgänglighet till digital offentlig service och är en lag som tagits fram för att statliga organisationer skall tvingas hålla en viss kvalitet i sin tillgänglighet. WCAG har tre nivåer som man behöver förhålla sig till, A (lägsta nivån), AA och AAA (högsta nivån) där lägsta nivån är relevant även för våra applikationer.

Till varje princip finns det flera riktlinjer samt tips och råd till hur dessa skall kunna uppfyllas. Vill du läsa mer så klicka på länken ovan och lär dig bygga mer tillgängliga webbplatser. En sista sida som jag vill ge tips om är webbriktlinjer.se som i första hand riktar sig till de som arbetar med webbplatser för offentlig sektor i Sverige. Men många av råden är generella och ger ett väldigt bra underlag för att höja kvalitén på de webbplatser du skapar. Här finns möjlighet att filtrera riktlinjerna på ett antal sätt, kanske vill du ha koll på vad man behöver tänka på när vi skall bygga en användarvänlig navigation eller så kikar vi på alla riktlinjer som har klassificeras med prio 1. Vad säger tex Riktlinje91? Detta är något vi skall jobba med i nästa moment.

Ur ett tekniskt perspektiv tycker jag att följande filtrering Teknik & kod, prioritet 1 kan vara en bra sammanfattning av de viktigaste sakerna vi behöver tänka på inom ramen för denna kursen.

Nu är det ju massor av principer, riktlinjer och tillgänglighetsaspekter att ta hänsyn till. Som tur är så finns det flera verktyg för att få hjälp att bygga tillgängliga webbplatser. Vi skall kika på några av dessa.

• wave.webaim.org är en enkel webbtjänst för att mäta tillgängligheten. WAVE finns som tillägg till flera webbläsare. Fördelen med denna plugin är att du kan testa sidan utan att behöva ladda upp den på din domän.
• Eiii Page Checker testar din kod mot WCAG 20 regelverk. Här får du också tips på hur du kan rätta koden för att följa reglerna.
• På webbriktlinjer.se så finns det en lista på automatiska testverktyg som både finns som webbtjänster och/eller plugin för olika webbläsare. Kika gärna och se om du hittar din egen favorit. Tänk på att verktyg både kan tillkomma och försvinna.
• En sida, PageSpeed Insights, som vi använde tidigare när vi kollade på prestanda ger också tips på tillgänglighet och även lite annat smått och gott som kollas. Vill man gå på djupet av en av testerna kanske det inte är den bästa sidan, men som en generell översikt över vad som bäst behöver förbättras så borde den fungera bra.

5.5 Redovisning

5.5.1 Frivilliga uppgifter

Ett ganska teoritungt moment där du förhoppningsvis har lärt dig en hel del saker som givit dig inspiration till att förändra webbsidor du har byggt tidigare, söka mer information om något område vi har tagit upp under momentet eller skapat sug att bygga någon ny webbsida.

Har du tid över så använd denna på något bra sätt inom webbutveckling. Har du planer på att göra ditt gymnasiearbete inom webbutveckling så kanske delar av detta momentet kommer vara en del av det arbetet.