Webbutveckling01 [weuweb01]

Moment05 - Teori

Introduktion

Ä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.

Momentets mål

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

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.

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.

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å.

Uppgift

För att lösa denna uppgift så har du antingen fått en genomgång på internetmuseum.se eller så läser du igenom artikeln om internets historia.

  • Välj 2-3 av händelserna(artiklarna) som du tycker verkar intressanta från olika decennier. Läs på mer om händelsen/tekniken/företeelsen och skriv ett inlägg på din Wordpress om just detta. Glöm inte bort ditt valda inläggs påverkan på samhället.

  • Välj nu ytterligare en teknik/företeelse som du ger en historik för, du beskriver nuläget och du försöker dig på en framtidstanke. Hur tror du att detta ser ut om X antal år? (Exempel. Snapchat skapades 2011, hur används det idag? Hur har det påverkat nätet? Vad tror du om Snapchats framtid?)

Uppgiften är väldigt fri att göra vad du vill av den. Det enda fel som kan uppstå är om du inte håller dig till historiska fakta. Framtiden kan ingen sia om så din analys är så god som någon. Glöm inte att ange källor för den fakta som du använder.

Tänk på de kunskapskrav som vi bara testar i detta moment. Du får givetvis chansen att göra om uppgiften senare på en djupare nivå om du vill, men enklast för dig är att göra uppgiften på rätt nivå direkt.

Kunskapskrav

Text

Betyget E

Betyget C

Betyget A

1. Webbens påverkan

Eleven beskriver [1] webbens historia och dess påverkan på samhället och de grundläggande tekniker som webben bygger på.

[1] översiktligt 

[1] utförligt 

[1] utförligt och nyanserat 

Validering, användaragenter och tillgänglighet

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.

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.

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. Om du kikar längst ner i sidfoten på alla sidor i kursolle så finns det två länkar som validerar HTML5 och CSS. Det är enkelt sätt för mig att kunna validera alla sidor med bara ett klick.

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.

Länken till denna sidans validering. Som du ser så får jag ett error. Hur löser man det?

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 validerar 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. Här är det fler error, några som jag har skapat och några som jag fått på köpet för att jag använder syntaxhighlighter för att kunna visa upp källkod på det sätt som jag gör.

Uppgift

Testa din aktuella samlingssida mot validatorerna för HTML5 och CSS. Ta en skärmdump (shift+cmd+4 för del av skärm / shift+cmd+3 för hel skärm) på de varningar och/eller error du får och försök se vad validatorn vill att du ändrar. Fundera på vad du vill/(måste) ändra och gör dessa ändringar. När du är nöjd så validerar du sidan igen och tar en skärmdump på resultatet. Skriv ett inlägg på din Wordpress där du visar den första skärmdumpen, berättar kortfattat vad du ändrar, eller varför du inte ändrar om du nu har valt att inte göra det (att inte ändra för att man inte orkar är inget godkänt argument), samt skärmdump på resultatet efter ändringen.

Användaragenter

Användaragenter innebär i vår värld olika webbläsare i en dator men också 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 Chrome som är den som flest sidvisningar görs i, och sedan en webbläsare till.

Source: StatCounter Global Stats - Browser Market Share

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 sida 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.

Bild
Högerklicka på sidan och välj sedan Inspekteraren. Denna bilden visar hur det ser ut i Chrome, andra webbläsare har motsvarande funktioner som heter inspektera element i Firefox och granska element i Opera. I Safari måste du först aktivera utvecklarläget genom att i inställningar/avancerat kryssa i rutan Visa utvecklarmenyn i menyraden för att nå Granska element när du högerklickar.
Bild
Inne i inspekteraren så ser du webbsidans utseende i den vänstra delen och information om html och css i den högra delen. Den kod som finns är inte den kod du har skrivit utan hur koden ser ut när webbläsaren har tolkat den. Dåligt skriven kod ger mer tolkning av webbläsaren och då är risken större att det blir annorlunda än vad du har tänkt.
Bild
I den vänstra delen kan du nu välja att visa hur sidan skall se ut i andra användaragenter, t.ex. en smartphone eller en tablet.

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. Givetvis gillar inte Google kursolle.se för denna sidan har blivit underkänd utifrån mobilanpassning. Jag får också hjälp med vad jag kan ändra så att sidan blir mer mobilanpassad.

Ett annat verktyg från Google, PageSpeed Insights visar hur snabbt din webbsida laddas i dator och i smartphone. Även här får jag tips på saker som kan/behöver förbättras, vissa saker är enklare att åtgärda medan andra saker kräver lite mer kunskap. Omdömet på kursolle hittar du här.

Att skriva korrekt kod gör att webbläsaren snabbare kan rita upp sidan. 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.
  • phpbeautifier.com gör samma sak som ovan fast med php-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.

Uppgift

Några småuppdrag blir denna delens uppgift

  1. Ta en skärmdump på utvecklarläget i din webbläsare där du visar hur din samlingssida ser ut på valfri smartphone och tablet.
  2. Validera också samlingssidan och se om den är mobilanpassad, reflektera över ditt resultat utan att behöva ändra, det kommer vi göra i nästa moment. Har du en idé om vad du vill göra för att få ett bättre betyg så får du naturligtvis testa detta.
  3. Testkör samlingssidan för att se hur snabb den är och fundera över de förslag du får på hur du kan göra sidan snabbare.
  4. Kör html- och css-kod från din samlingssida i dirtymarkup.com och se om det blir stor skillnad i den fina koden och i orgnialkoden.
  5. Testa att komprimera html- och css-kod för samlingssidan och se hur stor skillnaden är. Har du en stor sida kan du testa att köra speedtest igen och se om du får högre betyg.

Uppgiften redovisas i ett eller flera inlägg på din Wordpress.

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 så många som möjligt. Det som är enkelt att inse är de personer som har olika synsvagheter som gör att de har svårt med mindre texter, dåliga kontraster mellan text och bakgrundsfärg samt vissa färgkombinationer som flyter ihop. Men det handlar också om att ta hänsyn för de som är helt blinda och som använder sig av verktyg som läser upp webbsidan. Tillgänglighetsproblem kan vi också skapa genom att länkar, menyer och klickytor blir för små, detta är främst vanligt när vi använder en smartphone för att titta på en webbsida. Detta är några exempel på problem som vi ofta glömmer bort att ta hänsyn till när vi skapar en webbsida.

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/#perceivable, avläst 2017-03-29.

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

Princip 3: Begriplig - Information och hantering av användargränssnitt måste vara begriplig.


https://www.w3.org/Translations/WCAG20-sv/#understandable, avläst 2017-03-29.

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/#robust, avläst 2017-03-29.

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. Vad säger tex Riktlinje91? Detta är något vi skall jobba med i nästa moment.

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.
  • 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.

Uppgift

Några småuppdrag blir denna delens uppgift

  1. Kör en kontroll av din samlingssida med wave.webaim.org. Ta en skärmdump av resultatet, ändra det som eventuellt behöver ändras och testa igen. Dokumentera och resonera kring de ändringar du har gjort.
  2. Gör också en kontroll av samlingssidan med Eiii Page Checker. Ta en skärmdump av resultatet, ändra det som eventuellt behöver ändras och testa igen. Dokumentera och resonera kring de ändringar du har gjort.
  3. Om du blev nyfiken på någon annan tjänst och har testat den så lägg upp resultat och reflektioner av detta test.

Uppgiften redovisas i ett eller flera inlägg på din Wordpress.

Kunskapskrav

I detta avsnitt så testar vi följande kunskapskrav. Flera av dessa kommer vi senare testa även i slutprojektet.

Kunskapskrav

Text

Betyget E

Betyget C

Betyget A

3. Kodkvalitet

I arbetet utvecklar eleven kod som med [5] resultat följer standarder och som omfattar [6] av de grundläggande teknikerna för märkspråk och stilmallar. [7]

[5] tillfredsställande

 

[6] några

 

[7] [inget]

[5] tillfredsställande 

[6] några

 

[7] I produkten infogar eleven enkla diskreta domskript.

[5] gott

 

[6] flera

[7] I produkten infogar eleven diskreta domskript.

6. Produktens kvalitet

Produkten är av [11] kvalitet och följer etablerad god praxis. [12]

[11] tillfredsställande

[12] [inget]

[11] tillfredsställande 

[12] Detta kontrollerar eleven med några tester.

[11] god

 

[12] Detta kontrollerar eleven både manuellt och med flera tester.

7. Testning

Eleven testar produkten [13], samt [14] för att åstadkomma snabb överföring [15].

[13] i några webbläsare

 

[14] vidtar några enkla åtgärder 

[15] av bilder och andra mediafiler.

[13] på flera plattformar, inklusive traditionella datorer och mobila enheter

[14] vidtar några åtgärder

 

[15] av bilder och andra mediafiler.

[13] på flera plattformar, inklusive traditionella datorer och mobila enheter

[14] optimerar bilder och andra mediafiler

[15] och vidtar åtgärder för att reducera antalet överföringar per sida.

8. Tillgänglighet

Dessutom bygger eleven en webbplats som med [16] resultat följer grundläggande principer för tillgänglighet [17].

[16] tillfredsställande 

[17] [inget]

[16] tillfredsställande

[17] och kontrollerar detta med några automatiserade tester.

[17] gott

[18] och kontrollerar detta med automatiserade tester och simuleringar.

Redovisning

Detta moment består av uppgifter där du skriftligt, eller på annat sätt, redovisar uppgifterna och publicerar detta på din wordpress.
Du bestämmer själv om du redovisar detta i ett eller flera inlägg.