• www.anvandbart.se/ab/webbapplikationer

Formulär var från början ett sätt att få in information från användaren. Men redan tidigt började formulären också användas till att styra datorprogram – som i det här sammanhanget brukar kallas webbapplikationer ¹².

Ett mycket enkelt exempel på en sådan applikation är sökningen på en webbplats. Den styrs via ett miniformulär, som består av ett textfält och en skicka-knapp. Mer avancerade exempel på webbapplikationer är söktjänster som Google, biljettbeställning på SJ, e-post via Hotmail, webbaserade tidsredovisning och internetbanker.

Gränsen mellan formulär som samlar in information från användaren och formulär som styr applikationer är ganska diffus. Vill man vara petig så kör alla sorters formulär (med några sällsynta undantag) program på servern och att få in information från användaren brukar vara en viktig del av alla sorters applikationer.

Skapar något

Det särdrag som ändå brukar få oss att tala om applikationer är att de låter användaren ta kontroll och åstadkomma något – till skillnad från ”vanliga” formulär där användaren tämligen passivt lämnar ifrån sig information. Det kan vara något enkelt, som när sökningen resulterar i en sida specialanpassad för användaren med länkar till sidor som innehåller ett visst ord. Det kan också vara mer komplicerade saker, som att reservera en biostol, lägga in en faktura i ekonomisystemet, skapa en webbsida med hjälp av publiceringssystemet eller göra sin självdeklaration.

Webbapplikationen är ett verktyg för användaren att göra något, och ger upphov till ett påtagligt resultat som i någon mening är knutet till eller unikt för den enskilde användaren.

Skillnader mot traditionella applikationer

Det finns naturligtvis många likheter mellan traditionella applikationer som fungerar som fristående program och applikationer som används genom webbläsaren. Men det finns också ett par viktiga skillnader:

• Användaren är inte tvungen att antingen göra klar eller uttryckligen avbryta en inmatning hon påbörjat. Tvärtom är det väldigt enkelt att oavsiktligt råka lämna den oavslutad.

• Informationen på en sida fryser när sidan laddas. Förändringar i den syns inte innan nästa sidladdning. Det som står på sidan och som var sant när sidan laddades är inte nödvändigtvis sant när användaren läser det. Sidan kan vara inaktuell sedan lång tid tillbaka, utan att på något synligt sätt skilja sig från en som är helt färsk.

Ingen av dessa skillnader är absolut. Det finns sätt att helt eller delvis lösa problemen. Men de är fallgropar man måste hålla ett öga på när man gör webbapplikationer.

Skillnader mot informationswebbar

Även jämfört med traditionella webbsidor skiljer sig ofta webbapplikationerna. Saker som är viktiga för en informationswebb kanske inte alls är lämpliga i en viss webbapplikation, till exempel:

• Att sätta ut datum och ansvarig på sidan (däremot kanske det behövs kontaktinfo till teknisk support, om något skulle krångla)

• Olika färg för länkar till besökta och obesökta sidor

• Begriplig länkbar webbadress

• Att alla sidor lätt hittas av söktjänster

• Sidor som går lätt att skriva ut

Det kan till exempel innebära att en del (men alls inte alla) webbapplikationer kan använda ramar (sid 83 ) utan att störas av de problem som de brukar ge en normal webb.

Konsekvens viktigt när webbapplikationerna blir många

På många arbetsplatser får webbapplikationer en allt viktigare roll, och det är inte längre ovanligt att ha en webbapplikation uppe på skärmen hela sin arbetsdag och gör sitt huvudsakliga arbete med hjälp av den. Det gör naturligtvis kraven på snabbhet, ergonomi etc. mycket högre än för webbplatser användaren tillfälligt passerar i sökande efter information.

Ännu vanligare är att en mängd kringfunktioner webbifieras. Det kan till exempel röra sig om tidsrapportering, ekonomisystemet, projektverktyg, lokalbokning, telefonprogrammering, visit­korts­beställ­ning och rese­räknings­rapport­er­ing.

Några av dessa hanterar användaren dagligen, andra, som semester­pla­ne­ring­en, kanske det var ett år sedan hon såg senast.

Det växande antalet gör det viktigt att applikationerna ser ut och fungerar så likt varandra som möjligt. Om varje webbapplikation på intranätet är utformad för sig, med ett eget utseende, egna termer, eget gränssnitt, så måste användaren ägna mycket tid och energi till att lära sig hantera dem. Är det en applikation som hon använder sällan, hinner hon glömma och måste börja från början nästa gång.

Om applikationerna däremot fått så många gemensamma drag som möjligt, kan hon använda sina tidigare erfarenheter för att hantera även nya applikationer.

Även för applikationer som används dagligen är konsekvens viktigt – men då framför allt att samma handling på olika webbapplikationer måste få samma sorts resultat. Det får inte vara så att tider i en applikation skrivs in med punkt mellan timmar och minuter, medan en annan applikation kräver kolon. Eller att en applikation har en knapp för att spara, medan en annan har en knapp placerad på samma ställe som avbryter och slänger bort det arbete som gjorts.

Därför har webbprofilen (sid 42 ) stor betydelse vid utvecklingen av webb­applika­ti­on­er. Den är ett verktyg för att upprätthålla konsekvens mellan olika utvecklingsprojekt.

E-handel

För att få ytterligare en vy på webbapplikationer se avdelningen om E-handel, sid 376 , där mycket av det som tas upp här kan ses i ett konkretare perspektiv.

• www.anvandbart.se/ab/valja-flervalskontroll

Valbox, vallista, kryssrutor och radioknappar är de kontroller som låter användaren välja mellan flera alternativ. Som nämnts tidigare är vallistan en sällsynt kontroll, så det kan vara klokt att i första hand välja någon av de andra.

Hur många alternativ finns det?

Om det är få alternativ – fyra eller färre – är det bättre med radioknappar eller kryssrutor än att välja från en valbox eller vallista.

Även med fler alternativ är ofta radioknappar och kryssrutor att föredra – men måste vägas mot layoutens krav. Alltför många knappar och rutor gör formuläret i sin helhet svåröverblickat och klumpigt. I sådana fall kan det vara bättre med en valbox att välja från.

Ibland kan en kompromiss vara vallistan, där man kan se flera av alternativen utan att platsbehovet för den skull blir alltför stort.

Om det är många alternativ är även valboxar svåra att använda. Mer om detta i Undvik långa valboxar , sid 255.

Får man välja mer än ett alternativ?

Om användaren kan välja mer än ett alternativ är kryssrutor nästan det enda alternativet.

Rent tekniskt är det möjligt att välja flera alternativ ur en valbox eller vallista. Detta kräver dock handgrepp som få användare känner till och som inte är helt enkla att förklara, så de rekommenderas inte. Se Be inte användaren välja flera alternativ ur en valbox , sid 255.

Får man välja maximalt ett alternativ?

Om man är begränsad till ett alternativ, skall radioknappar eller valboxar användas.

Om valboxar används, finns det en risk att användaren väljer flera alternativ ur denna. Den är inte stor, men måste fångas när formuläret kontrolleras.

Måste man välja minst ett alternativ men får gärna välja flera?

Det finns ingen kontroll som direkt klarar av detta. Bästa alternativet är kryssrutor i kombination med instruktioner och en kontroll att minst en ruta är ikryssad.

Är det inte nödvändigt att välja någonting alls?

Om inget av alternativen behöver väljas är kryssrutor lämpligare än radioknappar och listor.

Om radioknappar används, se Radioknappar bör ha ett förval, sid 253. Om valbox används, se Valboxar där inget alternativ skall vara förvalt kan inledas med en instruktion , sid 255.

• www.anvandbart.se/ab/valja-kontroller

Ofta finns flera olika kontroller att välja mellan för att få en uppgift från användaren, och det kan vara svårt att veta vilken man skall välja.

Nedan finns frågor som kan hjälpa dig att välja rätt.

Vet du vilka alternativ som finns?

Om du inte har en komplett bild av vilka alternativ som finns, så är det enda alternativet att låta användaren skriva in svaret i ett textfält.

Underskatta inte problemet att i förväg förutse vilka alternativ användaren kan behöva. Det brukar vara lätt att se regeln, men svårt att se alla undantagen. En fördel med textfält är att användaren kan fylla i det även om hennes svar inte stämmer med det som webbmakaren trodde var de möjliga alternativen. (Detta kan vara både en för- och en nackdel. Det kan leda till att du får svar som är svåra att bearbeta. Men det kan också leda till att du inte får in felaktigt svar som användaren tvingats lämna eftersom inga korrekta alternativ fanns.)

Vilket är naturligast för användaren: att skriva svaret eller att välja det?

Ofta är det bättre för användaren att skriva i ett textfält än att välja. Speciellt att välja ur valboxar bryter lätt användarens arbetsrytm.

Exempel på sådant som är naturligare att skriva än att välja kan vara antal, ålder och datum.

Är svaret lätt att skriva fel?

Om svaret är långt, svårstavat eller användaren är osäker på hur det bör formuleras, är det bättre att ha färdiga svarsalternativ (det vill säga valbox, kryssrutor eller radioknappar).

Behöver användaren se alternativen för att förstå frågan?

Ibland är de möjliga svarsalternativen den bästa förklaringen av vad som egentligen menas med frågan. I sådana fall är det bäst att ha färdiga svarsalternativ.

Är det viktigt att svaren blir i rätt form?

Om en människa skall läsa det inmatade spelar det sällan någon roll, vi har stor förmåga att tolka och då fungerar ett textfält alldeles utmärkt.

Om svaret skall databehandlas blir det litet mer komplicerat. Är det avgörande för den fortsatta behandlingen att svaret är i rätt form är färdiga svarsalternativ bäst.

Ibland är ett alternativ att låta användaren skriva sitt svar i ett textfält, men att sedan kontrollera det (se Kontroll av inmatade uppgifter, sid 275) och återkomma med en fråga om vad användaren menar, om detta inte är helt klart (helst tillsammans med en lista över tänkbara alternativ).

Överväg också om det är möjligt att ändra databehandlingen så att den blir mer förlåtande.

• www.anvandbart.se/ab/formular-navigation

Formulär och navigation går inte särskilt bra ihop. För små formulär är det sällan något problem, men så snart de börjar bli litet större eller komplexa finns alltid risken att användaren av misstag lämnar sidan utan att ha fyllt i dem klart och klickat på skicka-knappen.

I ett normalt datorprogram, alltså ett som inte är webbaserat, finns ett skydd kring inmatningen av information. Ofta använder det dialogrutor. Dessa låser användaren så att hon inte kan lämna dem på annat sätt än att uttryckligen klicka på antingen ”OK” eller ”Avbryt” – formuleringen på knapparna kan variera, men i grunden finns bara två varianter: ”spara och använd det jag gjort här” eller ”jag har ångrat mig, släng bort det jag gjort”.

Även när större mängder information matas in finns skyddet på plats. Har man skrivit in text i ett ordbehandlingsdokument men inte sparat, går det inte att stänga dokumentet utan att få en dialogruta som kräver att man antingen sparar eller uttryckligen avbryter.

På webben är det inte så. Användaren matar in information i ett formulär, men kan när som helst göra något annat. Hon kan klicka på en länk på sidan, eller använda bokmärkesfunktionen i webbläsaren, och lämnar då formuläret. Till skillnad från ett vanligt program frågar webbläsaren inte om hon vill spara det inmatade. Den slänger bara bort det, utan att säga något.

Detta är olyckligt på två sätt. Dels går det arbete användaren lagt ner förlorat, bara för att hon missade att klicka på skicka-knappen. Men än värre kan vara att användaren inte görs medveten om detta, utan tror att något är gjort som datorn i själva verket i tysthet slängt bort.

Två lösningar

Det finns i princip två sätt att skydda sig mot att användaren av misstag lämnar formuläret: tunneln och skyddsnätet.