Webbutveckling 1 · område 8 · guide

Projektguiden: från kund till färdig sajt

Processen steg för steg – krav, plan, bygge, test och uppföljning. Exemplen kommer från Ekerverkstan, en påhittad cykelverkstad i Vikstad.

Slutprojektet lär dig ingen ny kod. Det du ska lära dig är processen: att ta reda på vad någon behöver, skriva ner det, planera, bygga, testa och i efterhand jämföra med planen. Den här guiden går igenom processen steg för steg. Koden står i guiderna från område 2–7, och den här guiden säger när du ska slå upp dem.

Exemplen kommer från Ekerverkstan, en påhittad cykelverkstad i Vikstad. Hela dess projektdokument är ifyllt, och sajten är byggd efter det. Du får låna arbetssättet, inte innehållet.

Kraven guiden stödjer står i Projekt 7.

Vad du kan efter guiden

• Göra om det en kund säger till krav som går att pröva.
• Skilja på ska-krav, bör-krav och det som inte ingår.
• Skriva mål som går att svara ja eller nej på efteråt.
• Göra en tidsplan mot de pass du faktiskt har, och se när den inte håller.
• Förutse vad som kan gå fel och bestämma i förväg vad du gör då.
• Rita en sitemap och veta vilka wireframes som behövs.
• Arbeta två i samma repo utan att skriva över varandra.
• Testa en sajt systematiskt och skriva en buggrapport som går att använda.
• Skriva en README.md och en uppföljning som förklarar, inte bara räknar upp.

Avsnitt 1–3 hör till lektion 74, 4–6 till lektion 75, 7–8 till bygget från lektion 76, 9 till lektion 83 och 10–11 till lektion 84.

1. Processen i sex steg

Varje webbprojekt, stort eller litet, går igenom samma steg. De har olika namn på olika arbetsplatser, men ordningen är densamma:

Två saker är värda att se redan nu.

Steg 1 och 2 görs före uppehållet, steg 3–6 efter. När du kommer tillbaka i maj har du glömt det mesta av vad du tänkte i mars. Det du skrev ner finns kvar. Skriv därför planen så att någon annan skulle kunna bygga efter den – den någon annan är du själv, åtta veckor senare.

Steg 6 jämför med steg 1 och 2. Uppföljningen går bara att skriva om kraven och målen var tydliga från början. Ett krav som "sajten ska vara snygg" går inte att följa upp. Därför lägger du mest tid på det första steget.

Prova själv

Läs Ekerverkstans projektdokument från början till slut innan du skriver något eget. Det tar tio minuter och visar hur de fyra delarna hänger ihop.

2. Från kund till kravspecifikation

En kravspecifikation (ofta förkortat kravspec) är en lista över vad sajten ska göra, skriven så att både du och kunden kan hålla med om den. Den är det du bygger efter, och det du bedöms mot.

Börja med vad kunden säger

Kundbeskrivningen har ett stycke som heter Kunden säger. Det är kundens egna ord, och de är ofta oprecisa. Så här lät Ekerverkstan:

"På våren står telefonen aldrig still. Vad kostar en service, hur lång väntetid, lagar ni elcyklar. Vi vill att folk ska kunna se det själva."

Tre frågor, ett problem. Kravspecens första avsnitt, 1.1 Kunden och syftet, blev:

Problemet är telefonen. På våren ringer den hela dagarna med samma tre frågor: vad en service kostar, hur lång väntetiden är och om de lagar elcyklar. Sajten ska svara på de frågorna, så att telefonen används till att boka.

Lägg märke till att syftet inte är "en snygg hemsida". Syftet är att telefonen ska ringa mindre. Allt annat i kravspecen går att pröva mot det.

Målgruppen och scenarierna

Målgruppen är de som besöker sajten. Skriv ålder, vilken skärm de oftast har, och vad de vill få gjort. Har kunden flera grupper, skriv om var och en.

Ett scenario är en påhittad besökare med ett ärende. Det gör målgruppen konkret:

Amir, 29, har fått punktering på väg till jobbet. Han står vid cykeln och vill veta om verkstaden har öppet nu och vad det kostar. Han har telefonen i handen.

Ur det scenariot kommer ett krav nästan av sig självt: öppettiderna ska synas direkt, på en telefon, utan att Amir behöver leta.

Krav som går att pröva

Det här är avsnittets viktigaste del. Ett krav är bara användbart om du efteråt kan svara ja eller nej på om det är uppfyllt.

Mallens kravtabell har kolumnen Så prövar jag det. Fyll i den för varje krav. Kan du inte skriva hur du ska pröva kravet, är kravet för vagt – skriv om det.

Ska och bör

Kundbeskrivningen har två listor: Måste finnas och Gärna. De blir dina ska- och bör-krav.

• Ska-krav måste vara uppfyllda när du lämnar in. Stryk inget ska-krav utan att prata med läraren.
• Bör-krav gör du om tiden räcker. När tidsplanen spricker är det bör-kraven du stryker, i en ordning du har bestämt i förväg.

Ekerverkstan har sex ska-krav och två bör-krav. Sex till åtta krav totalt är en rimlig storlek för fyra till sex sidor.

Prova själv

Ta din kunds Måste finnas-lista. Skriv om varje punkt till ett krav som går att pröva, och skriv hur du prövar det. Jämför med tabellen ovan: står det snygg, tydlig, bra eller lätt någonstans, är du inte klar.

3. Avgränsningen

Avgränsningen säger vad som inte ingår. Den skyddar dig från ett projekt som växer tills det inte blir klart.

Skriv det som kunden kanske tror att hen får, men som du inte bygger:

• Riktig bokning med kalender ingår inte. Formuläret är en förfrågan, och verkstaden ringer upp.
• Formuläret skickar ingenting. Att ta emot uppgifter kräver en server, och det ligger utanför kursen.
• Ingen webbshop och ingen inloggning.

Den andra punkten gäller alla i klassen. Din sajt ligger på GitHub Pages, som bara skickar ut filer och inte kan ta emot något. Ett formulär på din sajt kan se ut och bete sig som ett riktigt – det validerar, det visar fel – men ingenting skickas. Skriv det i avgränsningen, så vet både kunden och läraren att du vet det.

Prova själv

Läs din kunds Gärna-lista och fråga dig för varje punkt: hinner jag det, och kan det alls byggas med HTML, CSS och JavaScript utan server? Det som svarar nej på någon av frågorna hör hemma i avgränsningen.

4. Projektplanen: mål, tidsplan och milstolpar

Kravspecen säger vad. Projektplanen säger hur och när.

Mål

Ett mål säger vad som ska vara sant när projektet är klart. Det liknar ett krav, men handlar om vad besökaren kan göra, inte om vad sajten innehåller.

1. Den som ringer för att fråga om pris hittar priset själv, med högst två tryck från startsidan. 2. En bokningsförfrågan går att fylla i på en telefon utan att zooma. 3. Sajten fungerar från 320 px till desktop. 4. Sajten fungerar utan JavaScript.

Tre till fem mål räcker. I uppföljningen svarar du ja eller nej på vart och ett.

Tidsplanen

Mallen har en rad per pass, från 76 till 85. Kolumnen Planerat fyller du i nu. Kolumnen Gjort fyller du i efter varje pass under bygget.

Tre råd när du planerar:

• Planera efter milstolparna. De fyra milstolparna i avsnitt 7 ger ramarna. Fyll i passen mellan dem.
• Formulär tar längre tid än du tror. Varje fält behöver label, rätt type, required där det behövs, och formuläret ska fungera med och utan skript. Ekerverkstan planerade ett pass för formuläret och behövde ett och ett halvt.
• Lämna luft före deadline. Pass 85 är finputs, inte bygge. Det som inte är klart på pass 84 ska strykas eller skjutas till uppföljningen, inte klämmas in.

Fyll i Gjort efter varje pass

Det tar en minut, och det är den minuten som gör uppföljningen lätt. Så här såg Ekerverkstans rader ut när planen sprack:

En plan som spricker är inget fel. En plan som spricker utan att det syns någonstans är det.

5. Risker

En risk är något som kan gå fel. Poängen med att skriva ner den är att bestämma vad du gör innan det händer, när du fortfarande kan tänka lugnt.

Mallens tabell har fyra kolumner:

Tänk på fyra sorters risker:

• Tid – något tar längre tid än du tror, eller du är borta.
• Teknik – något går inte att bygga som du tänkt dig.
• Material – du saknar bilder eller texter. Gäller särskilt den som har en riktig kund.
• Samarbete – i par: den andra är borta, eller ni är oense.

Den första risken i exemplet inträffade. Eftersom åtgärden stod i planen blev det en rad i tidsplanen, inte ett problem.

Prova själv

Skriv ner den risk du tror är mest sannolik för just ditt projekt. Skriv sedan en åtgärd som du kan göra själv, utan att fråga någon. "Fråga läraren" är ingen åtgärd.

6. Sitemap och wireframes

Sitemap

En sitemap visar alla sidor och hur de hänger ihop. För en sajt med fyra till sex sidor räcker en lista med indrag:

Startsida
  Service och priser
  Boka service
  Hitta hit

Fråga dig för varje sida: vilket scenario i kravspecen behöver den? En sida som inget scenario behöver kan strykas. Ett scenario utan sida betyder att en sida saknas.

Wireframes

Wireframes ritar du i Figma-mallen från område 4. Hur du ritar dem står i designguiden, avsnitt 4–6. Här gäller bara vilka du behöver:

• Startsidan i mobil och desktop. Den viktigaste sidan, och den som ändras mest mellan bredderna.
• Minst en undersida i mobil och desktop. Välj den som är svårast – ofta den med en tabell eller ett formulär.

Rita mobilen först. Det som får plats ovanför skärmkanten på en telefon är det viktigaste på sidan, och det ska stämma med kravspecen. Ekerverkstans krav 1 säger att öppettiderna syns utan att scrolla – då ska de stå ovanför kanten i wireframen.

Dela Figma-filen

Wireframen lämnas in som en länk i projektplanen. Figma-filer är privata från början. Välj Share → Anyone with the link → can view, och pröva länken i ett privat fönster innan du lämnar in.

7. Bygget i fyra milstolpar

Bygget går lektion 76–84. Det är samma ordning som kursen gått i: struktur, form, anpassning, interaktivitet, optimering. Fyra milstolpar delar upp det:

Milstolparna är hållpunkter, inte inlämningar. Läraren tittar på dem under passet.

Milstolpe 1: struktur

Bygg all HTML för alla sidor innan du skriver en rad CSS. Det känns fel, eftersom sidorna ser tråkiga ut länge. Men det tvingar fram rätt ordning: semantiken bestäms av innehållet, inte av hur det ska se ut.

• Samma header, nav och footer på varje sida.
• En h1 per sida, rubrikerna i ordning utan hopp.
• label på varje fält, alt på varje bild.
• Validera varje sida. Noll fel.

Slå på GitHub Pages första passet, så fort index.html finns: repot → Settings → Pages → Deploy from a branch → main → Save. Skriv adressen i README.md och högst upp i projektdokumentet. Då finns den publicerade adressen hela bygget – validatorn tar den direkt, telefonen kan öppna den, och Lighthouse på lektion 82 mäter på riktigt. Den som väntar till sista veckan upptäcker på deadlinekvällen att Pages aldrig slogs på.

Milstolpe 2: responsivitet

Börja med designsystemet: färger, typsnitt och avstånd som variabler i :root. Bygg sedan layouten för telefonen först, och lägg till brytpunkter bara där innehållet behöver dem.

Ekerverkstan behövde en enda brytpunkt. Kortgalleriet klarar sig med repeat(auto-fit, minmax(15rem, 1fr)), och tabellerna ligger i en ruta som scrollar själv. Färre brytpunkter betyder färre saker som kan gå sönder.

Milstolpe 3: interaktivitet

Minst en funktion som tillför verklig nytta för kunden. Välj den ur kundens behov, inte ur modulbiblioteket. Fråga: vad skulle besökaren sakna?

Ekerverkstan har tre skript:

Den tredje finns inte i modulbiblioteket. Den kom ur kravspecen: kunden ville att folk skulle se priset själva. Priset står i varje etikett, så utan skript kan besökaren räkna själv. Skriptet gör det åt hen.

Testa milstolpen med JavaScript avstängt. Hur det går till står i fördjupningsguiden, avsnitt 11.

Milstolpe 4: klart

Optimera bilderna, mät före och efter, testa, publicera, skriv README.md och uppföljningen. Avsnitt 9–11 i den här guiden.

8. Två i samma repo

Arbetar ni i par har ni ett repo. Den ena äger det, den andra läggs till som collaborator – en medarbetare med rätt att pusha.

Sätta upp repot

1. Ägaren skapar repot från kursens template-repo, som vanligt.
2. Ägaren: repot → Settings → Collaborators → Add people, och skriver in den andras GitHub-namn.
3. Den andra godkänner inbjudan, i mejlet eller på github.com.
4. Båda öppnar var sin Codespace på samma repo.

Varje pass

Git har ingen aning om att ni är två. Den vet bara vilka ändringar som finns i din Codespace och vilka som finns på GitHub. Därför samma rytm varje pass:

git pull                         när passet börjar
git add . && git commit -m "…"   när en sak är klar
git push                         direkt efter

git pull hämtar den andras ändringar. Gör du det inte, arbetar du på en gammal version, och det är då det blir problem.

Dela upp arbetet per fil

Två personer som ändrar samma rader i samma fil är det som ger en konflikt. Det enklaste sättet att undvika det är att aldrig göra det:

• Varsin sida. Den ena gör service.html, den andra boka.html.
• stil.css har en ägare. Den andra säger till innan hen ändrar i den.
• Skriv fördelningen i projektplanen, avsnitt 2.7.

När det säger nej

Den första är ofarlig och händer ofta. Den andra går att lösa, men inte på egen hand första gången.

Ni bedöms var för sig

Commit-historiken visar vem som skrivit vad. Båda ska ha commits, och båda ska kunna förklara hela sajten – inte bara sin halva. Det kommer upp i betygssamtalet.

9. Testprotokollet

Att testa är inte att klicka runt och se att det ser bra ut. Det är att gå igenom en lista och skriva ner vad du såg, också det som fungerade.

Vad protokollet täcker

Skriv vad du såg, inte bara ja. "Menyknappen öppnar och stänger. Öppettiderna slutar på 634 px av 812" går att kontrollera. "Funkar" gör det inte.

Korstestet

På lektion 83 testar du en annan elevs sajt, och någon annan testar din. Du hittar fel i andras kod som du aldrig hittar i din egen, eftersom du vet hur din egen är tänkt att användas.

Så testar du någon annans sajt:

1. Läs deras kravspec först. Du testar mot den, inte mot din smak.
2. Pröva varje ska-krav på det sätt de skrivit.
3. Gör sedan det en besökare gör: klicka fel, skicka tomt, ändra bredden.
4. Skriv en buggrapport för varje fel, direkt i deras protokoll, i läget Föreslå.

Dokumentet är delat med dig som Kommentator, så du kan inte skriva i tabellen direkt. Men du kan föreslå: pennan uppe till höger i Google Docs → Föreslå. Det du skriver syns i färg, och ägaren godkänner det med ett klick. Ingen behöver ändra sin delning.

En buggrapport som går att använda

En bra buggrapport säger var, vad som händer och vad som borde hända. Den säger inte vad som är fel i koden – det är den andras jobb att ta reda på.

Båda rapporterna är äkta – de hittades i Ekerverkstan. Den första visade sig bero på att valideringsmodulen bygger felmeddelandet av etikettens text. Etiketten Vilken sorts cykel blev Cykeltyp, och meddelandet blev "Fyll i cykeltyp."

Den som äger sajten fyller i Åtgärd och Status. Rättat eller Inte rättat, eftersom … – båda är godkända svar. Ett fel utan åtgärd är det inte.

10. README.md

README.md är det första som syns när någon öppnar ditt repo. Den ska svara på vad det här är, var det finns och vem som gjort det. Den behöver inte vara lång.

# Ekerverkstan

Webbplats åt Ekerverkstan, en cykelverkstad i Vikstad.
Slutprojekt i Webbutveckling 1.

Publicerad: https://användarnamn.github.io/ekerverkstan/
Projektdokument: (länken till Google Docs)

## Sidorna

- index.html – startsidan, öppettider och vad vi gör
- service.html – servicepaket och priser
- boka.html – formulär för bokningsförfrågan
- hitta-hit.html – karta och kontakt

## Skript

- js/meny.js – modul 1 ur modulbiblioteket
- js/validering.js – modul 5, anpassad
- js/prisuppskattning.js – egen, räknar ihop valda tjänster

## Gjort av

Förnamn Efternamn. I par: vem som gjort vilka sidor.

Länken till projektdokumentet måste fungera för den som rättar. Pröva den på samma sätt som på delinlämningen.

11. Uppföljningen

Uppföljningen är där du jämför planen med vad det blev. Den är kort, men den är det som skiljer E från A i matrisens sista rad.

4.1 och 4.2: målen och kraven

Gå igenom dem ett i taget och pröva dem på det sätt du skrev i kravspecen. Svara ja eller nej, och skriv hur du vet:

Ett nej är inget misslyckande, om du kan förklara det. Ett ja utan kommentar säger ingenting.

4.3 och 4.4: tidsplanen och ändringarna

Jämför kolumnerna Planerat och Gjort. Var hamnade du efter, och varför? Vad ändrades mot planen?

Jag låg ett halvt pass efter från pass 78 till 80. Formuläret tog längre tid än jag trodde, eftersom varje fält behövde en label och formuläret skulle fungera både med och utan skript. Risken stod i planen, och åtgärden fungerade.

Ändringar är inte fel. Oförklarade ändringar är det.

4.5: nästa gång

Det här är avsnittet som visar att du lärt dig något om processen, inte bara om koden. Skriv vad du skulle göra annorlunda – och varför.

Jag skulle korstesta tidigare. Båda felen i 3.6 hittades av någon annan på pass 83, och båda hade varit lättare att rätta i pass 80, när layouten gjordes.

Ett konkret svar med ett skäl slår tre allmänna. "Planera bättre" säger ingenting. "Planera formulär som två pass" säger något.

12. Ta det längre

Mät målen på riktiga människor

Ekerverkstans första mål var att priset ska gå att hitta med högst två tryck. Det prövades genom att räkna tryck. Ännu bättre är att ge sajten till någon som inte sett den, säga "ta reda på vad en stor service kostar", och ta tid. Det kallas ett användartest, och det hittar saker som inget protokoll gör.

Prioritera med MoSCoW

Ska och bör räcker långt. I större projekt används ofta fyra nivåer: Must, Should, Could och Won't – på svenska ungefär måste, bör, kan och inte nu. Won't är avgränsningen, skriven som krav.

Skriv en ändringslogg

Längst ner i README.md kan du ha en rubrik Ändringar med datum och vad som ändrades. Den gör commit-historiken läsbar för någon som inte kan git – till exempel kunden.

13. Felsökning

14. Snabbreferens

15. Ordlista