Design och implementation av ett webbaserat bokningssystem för offentlig sektor

Storlek: px
Starta visningen från sidan:

Download "Design och implementation av ett webbaserat bokningssystem för offentlig sektor"

Transkript

1 Design och implementation av ett webbaserat bokningssystem för offentlig sektor David Åberg 9 februari 2009 Examensarbete i Datavetenskap, 30 hp Handledare på CS-UmU: Helena Lindgren Extern handledare: Britt-Inger Johansson Examinator: Per Lindström Umeå Universitet Institutionen för Datavetenskap UMEÅ Sverige

2

3 Sammanfattning Användningen av webbapplikationer ökar stadig inom den offentliga sektorn. Det finns en stor potential att via införandet av webbaserade tjänster höja servicen, öka tillgängligheten, och effektivisera verksamheten. Interbook är ett webbaserat bokningssystem, anpassat för bokning av kommunala anläggningar. I denna rapport beskrivs utvecklingen av ett nytt användarvänligare gränssnitt för detta system. Det visas att genom asynkron kommunikation mellan webbserver och klient är det möjligt att bygga webbapplikationer där alla interaktioner sker på en och samma HTML-sida. Dessa enkelsidiga webbapplikationer tillåter användare att arbeta på ett mer intuitivt icke-linjärt sätt. Rapporten beskriver även en metod för att bygga nedgraderbara Ajax-applikationer som fungerar utan krav på att användaren har tillgång till en specifik teknik. Design and Implementation of a Web-based Booking System for the Public Sector Abstract The usage of web applications is increasing in the public sector. Information technology offers major opportunities for improving the service to citizens and companies. Interbook is an online facility reservation system aimed at the public sector. This thesis describes the development of a new more usable graphical user interface for Interbook. It is proven that by asynchronous communication between the server and the client it is possible to build web applications in which all interactions with a Web application take place on one page. These single-page user interfaces allow users to work in an intuitive, non-linear way. Further the thesis presents a method for building degradable Ajax-applications, that works without any presumptions of user technique.

4 Innehållsförteckning Kapitel 1 Introduktion Bakgrund Disposition... 1 Kapitel 2 Problembeskrivning Uppgift Tjänster Uppdragsgivare Mål Målgrupp Avgränsning... 5 Kapitel 3 Metodbeskrivning Identifiera behov och etablera krav Utveckla designalternativ som uppfyller kraven Kortsortering Skapa interaktiva versioner av designalternativen Low-fidelity prototyper High-fidelityprototyper Konceptuell design Fysisk design Utvärdera de interaktiva versionerna Quick and dirty utvärdering Användartest Kapitel 4 Ajax-applikationer och användbarhet Teoretisk bakgrund Den traditionella webbapplikationsmodellen Webbapplikationsmodellen med Ajax Ajax och användbarhet... 17

5 4.2.1 Fördelar med Ajax Nackdelar med Ajax Hur ska AJAX användas Diskret Ajax Principer för Ajax-applikationer Användning av AJAX för e-bokningssystem Slutsatser Kapitel 5 Genomförandebeskrivning Prototyputveckling, iteration Identifiera behov och etablera krav Utveckla designalternativ Low-fidelity prototyp Utvärdering av low-fidelity prototyp Prototyputveckling, iteration Identifiera behov och etablera krav Informationsdesign Utveckla designalternativ High-fidelity prototyp Utvärdering av high-fidelity prototyp Kapitel 6 Resultat Kravspecifikation Informationsstruktur Low-fidelity prototyp Resultat av utvärdering Slutgiltig prototyp Gränssnitt Implementation Resultat av utvärdering av prototyp Granskning av uppfyllse av kravspecifikation Kapitel 7 Slutsats och Diskussion... 53

6 7.1 Begränsningar Framtida arbete Kapitel 8 Tack Referenser Bilaga A Styrdokument Bilaga B Uppfyllelse av styrdokument... 63

7 Figurförteckning Figur 3.1: En enkel modell av designprocessen, baserad på figur 6.7 i [2] Figur 4.1: Den traditionella webbapplikationsmodellen, baserad på figur 1 i [10] Figur: 4.2: Sykron kommunikation mellan klient och server, baserad på bild figur 2 i [10] Figur 4.3: Webbapplikationsmodellen med Ajax, baserad på bild figur 1 i [10] Figur 4.4: Asykron kommunikation mellan klient och server, baserad på bild figur 2 i [10] Figur 5.1: Tidiga gränssnittsskisser Figur 5.2: Ett tidigt desingförslag Figur 6.1: Grundstruktur i low-fidelity prototypen Figur 6.2: Registreringssidan i low-fidelity prototypen Figur 6.3: Söksidan i high-fidelity prototypen Figur 6.4: Huvudmenyn i high-fidelity prototypen Figur 3.5 Ikoner för high-fidelity prototypens olika delar Figur 6.6: Sidfot i prototypen Figur 6.7: Flikarna i low-fidelity prototypen Figur 6.8: Registreringssidan i high-fidelity prototypen Figur 6.9: Inloggningssida i high-fidelity prototypen Figur 6.10: Enkel och utökad sökning i high-fidelity prototypen Figur 6.11: Söksidan i high-fidelity prototypen Figur 6.12: Lokalschema i high-fidelity prototypen Figur 6.13: Bokningssidan i high-fidelity prototypen Figur 6.14 schematisk bild over webbapplikationens struktur

8 Kapitel 1 Introduktion 1.1 Bakgrund Under de senaste åren har 24-timmarsmyndigheten blivit ett vedertaget begrepp för de allra flesta myndigheter och offentliga institutioner i Sverige [4]. Vad det egentligen innebär är helt enkelt möjligheten att kontakta och till viss mån interagera med myndigheter under dygnets alla timmar. Denna kontakt tillhandahålls vanligtvis genom så kallade e-tjänster. Till offentliga e-tjänster räknas den service som offentliga aktörer erbjuder genom elektroniska kontakter som telefon, dator och liknande. Eftersom såväl ung som gammal, datorkunnig som datornovis skall komma åt tjänsterna, så medför detta höga krav avseende tillgänglighet. Interbook är en e-tjänst i form av ett webbaserat bokningsverktyg utvecklat för kommuner och den offentliga sektorn. Bokningssystemet Interbook har funnits på marknaden ett antal år och är väletablerat (används i dagsläget av mer än 100 skandinaviska kommuner). Systemet är konstruerat för att hantera diverse bokningsverksamhet. Under den senaste tiden har Interbook kompletterats och byggts ut, på kunders förfrågan. Vid införandet av nya funktioner har även gränssnittet successivt utökats. I samband med en nyleverans av systemet har krav på en förbättring av systemets användarvänlighet uttryckts. Det befintliga gränssnittet uppvisar många brister och är inte kompatibelt med dagens standard. Denna rapport är en del i ett examensarbete utfört under civilingenjörsutbildningen Interaktion och Design i Umeå, med syfte att utveckla ett nytt användargränssnitt för Interbook. I rapporten presenteras förslag på ett mer användarvänligt gränssnitt till ovan nämnda bokningssystem, ett gränssnitt som följer gängse standarder samt uppfyller kraven för webbplatser inom offentlig service. 1.2 Disposition Nedan följer en kortare beskrivning av rapportens innehåll och struktur i en ordning som följer projektets genomförande. Kapitel 2 Problembeskrivning I kapitlet Problembeskrivning ges en mer detaljerad beskrivning av: uppgiften, bakgrunden till problemet och den målsättning som ska uppnås.

9 Kapitel 1. Introduktion 2 Kapitel 3 Metodbeskrivning I kapitlet Metodbeskrivning presenteras de aktiviteter som omfattas av processen för interaktionsdesign. Varje moment innehåller sammanfattningar av de metoder och tekniker som tillämpats vid genomförandet. Kapitel 4 - Ajax-applikationer och användbarhet I kapitlet Ajax-applikationer och användbarhet beskrivs Ajax påverkan av användbarheten för webbaserade gränssnitt. Vad tillför tekniken och hur ska de mer komplexa interaktionsmöjligheterna som tillförs hanteras? Kapitel 5 Genomförande I kapitlet Genomförande beskrivs genomförandet av projektet fördelat över designprocessens olika faser (etablera krav, utveckla designalternativ, skapa en interaktiv version av designen och utvärdera designen). Kapitel 6 Resultat I kapitlet Resultat presenteras resultatet av det arbete som utförts. Det grafiska gränssnittet presenteras i kombination med en skriftlig redogörelse av systemets olika delar. Kapitel 7 Slutsatser och diskussion I kapitlet Slutsatser och diskussion förs en sammanfattande diskussion om vad som har åstadkommits. Här diskuteras huruvida målet har uppfyllts, vilka begränsningar som finns i lösningen och områden för framtida utveckling.

10 Kapitel 2 Problembeskrivning Nedan följer en redogörelse av det uppdrag som det beskrivna projektet utgör. Projektets mål, omfattning och avgränsning förtydligas. 2.1 Uppgift I och med att allt fler kommuninvånare vänder sig till internetbaserade alternativ för att utföra diverse ärenden höjs kraven på dessa tjänster. Huvuduppgiften består i att konstruera ett nytt gränssnitt till det webbaserade bokningssystemet Interbook, där såväl ung som gammal, datorkunnig som novis skall kunna nyttja tjänsterna. Detta medför omfattande krav avseende användbarhet och tillgänglighet. Målet är att bokningssystemet ska ha ett intuitivt gränssnitt som alla kan använda. Vidare ska gränssnittet ha en attraktiv design som avspeglar den underliggande arkitekturen. Vid implementationen av gränssnittet ska aktuella tekniker så som Ajax tillämpas för att åstadkomma ett bra resultat. De fördelar som dessa tekniker medför kommer att identifieras för att kunna nyttja dem i designfasen. Det är även viktigt att uppbyggnaden är flexibel då nya moduler och funktioner kan komma till i framtiden. Utöver utvecklingen av nya gränssnitt ska projektet även mynna ut i ett styrdokument. Detta dokument ska specificera riktlinjer som kan komma till hands vid framtida utveckling av liknande system och kompletterande tjänster Tjänster Bokningssystemet består av två delar, en publik del samt en administrativ del. Den administrativa delen av systemet kontrolleras av en bokningshandläggare medan den publika delen nyttjas av medborgare, företag och föreningar. Detta projekt kommer att fokusera på utveckling av delar av gränssnitten för den publika delen av systemet. Nya gränssnitt ska konstrueras till följande tjänster: - Registrering Företag, föreningar och medborgare ska kunna registrera sig för att sedan kunna genomföra bokningar via internet. - Inloggning Registrerade användare kan logga in med hjälp av användaruppgifterna och få tillgång till det som systemet erbjuder.

11 Kapitel 2. Problembeskrivning 4 - Söka lokaler/tid Det ska vara möjligt för användare att söka efter lediga lokaler och tider utifrån ett antal sökvillkor. - Visa schema Det ska vara möjligt att studera schemat för en viss lokal. Användaren får en överblick över vilka tider som är bokningsbara. - Bokningsförfrågan Användare av tjänsten kan efterfråga att få boka tid i en lokal Uppdragsgivare Uppdragsgivaren Explizit är ett konsultföretag inom informations- och kommunikationsteknologi. Företaget är baserat i Skellefteå och erbjuder utveckling av programvara i såväl större system som enskilda produkter. En del av verksamheten består i att bygga system för offentlig service och 24 timmarskontoret. Explizit har i dagsläget ett 40-tal anställda och ingår i Argentum Group(ca 100 anställda) med kontor i Skellefteå, Göteborg och Malmö. 2.2 Mål Målsättningen för arbetet är att utifrån funktionaliteten hos ett existerade bokningssystem utveckla ett nytt koncept som bättre motsvarar dagens krav på denna typ av produkt. Det är en uppgift med tre delmål som måste uppfyllas. Det första momentet består i att ta fram en ny övergripande informationsstuktur som är intuitiv och lättnavigerad. Eftersom systemet på senare tid har utökats med kompletterande tjänster är den linjära struktur som finns i dag inte tillfredställande. Vidare ska de grafiska gränssnitt som berörs vid ett bokningsförfarande omarbetas. Målet är att gränssnittet ska vara användarvänligt, intuitivt samt följa gängse standardiseringar/krav som Verva och W3C [4]. Det är även viktigt att designen känns tilltalande och modern. Det resulterade gränssnittet ska sedan implementeras i form av en interaktiv prototyp. Denna prototyp ska förvekligas genom samma tekniker är tänkta att tillämpas i den färdiga produkten, det vill säga, med hjälp av ASP.NET 3.5, CSS och Ajax. Slutligen ska ett styrdokument utvecklas vilket kan tillämpas som stöd för att verifiera att en e- tjänst uppfyller de krav som ställs. 2.3 Målgrupp Att bokningssystemet riktar sig till offentlig service medför att målgruppen för systemet är extremt bred. Det saknas gemensamma nämnare och aktörerna skiljer sig i så väl ålder som

12 Kapitel 2. Problembeskrivning 5 datorvana. Detta har till följd att i princip inga restriktioner kan göras eller användargrupper uteslutas. Systemets gränssnitt måste byggas så att det går att använda förutsättningslöst. 2.4 Avgränsning Den tidsomfattning som examensarbetet sträcker sig över (30 hp) medför att vissa begräsningar måste göras. Detta innebär främst att vissa delar av gränssnittet inte kommer att omfattas av den interaktiva prototypen, då det kompletta systemet är väldigt omfattande. Nedan följer de viktigaste avgränsningarna: - Fokus läggs på de delar av systemet som berör själva bokningsförfarandet. - Resultatet kommer inte att vara en färdig och produkt utan snarare en interaktiv prototyp. - Utvecklingen ska ske i ramverket Microsoft.NET - Utvärderingar koncentrerats till de funktioner som är avgörande för systemets funktionalitet. - Prototypen kommer endast uppfylla de krav på offentliga webbplatser som anses relevanta för systemet i fråga. - Det styrdokumentet som utvecklas beskriver endast de problem som bör tas hänsyn till vid utveckling av e-tjänster. Styrdokumentet kommer inte att tillhandahålla beskrivningar av hur problemen praktiskt ska lösas.

13 Kapitel 3 Metodbeskrivning På senare år har informationsteknologiska produkter kommit att spela en allt större roll i vår vardag. Interaktionsdesign handlar om att forma dessa produkter, tjänster och miljöer genom att särskilt fokusera på deras brukskvalitéer, det vill säga hur de ska uppföra sig och hur de ska användas [1]. Inom området människa-datorinteraktion finns det mängder av litteratur som beskriver förfarandet för utveckling av gränsytor med dessa brukskvalitéer i fokus. I detta projekt har en anpassad version av designprocessen som den beskrivs av Preece och medarbetare [2] tillämpats, en designprocess indelad i fyra huvudaktiviteter: identifiera behov och etablera krav, utveckla designalternativ som uppfyller kraven, skapa interaktiva versioner av designalternativen samt utvärdera de interaktiva versionerna. Förståelse för de olika aktiviteterna är viktigt för att lyckas med en design, det krävs också en insikt i hur aktiviteterna är relaterade till varandra. I figur 1 presenteras en av många modeller som beskriver flödet mellan de olika aktiviteterna i designprocessen. Figur 3.1: En enkel modell av designprocessen, baserad på figur 6.7 i [2]. Alla aktiviteter som ingår i designprocessen är sammanflätade och utvärdering av en alternativ lösning leder ofta till ytterligare ett varv i processen. Denna iteration är en av de viktigaste egenskaperna för en lyckad designprocess. Iterationen leder till att lösningar förfinas och att nya idéer dyker upp [1, 2]. Genom att involvera användare framkommer nya insikter om vad som krävs av en produkt. Dessa nya insikter leder i sin tur till ett behov av att omforma produktens design. Detta kapitel ger en överblick av ovan nämnda aktiviteter samt de kompletterande metoder och tekniker som använts vid genomförandet av projektet. Avsnitt 3.1 (Identifiera behov och etablera krav) presenterar de behov som det kommande systemet ska uppfylla samt metoder

14 Kapitel 3. Metodbeskrivning 7 för hur detta ska konkretiseras i en kravspecifikation. Avsnitt 3.2 (Utveckla designalternativ som uppfyller kraven) beskriver metoder för att utforska problemrymden och upptäcka alternativa designlösningar. Avsnitt 3.3 (Skapa interaktiva versioner av designalternativen) uttrycker metoder för att praktiskt realisera designlösningar genom prototyper av skiftande komplexitet. Avsnitt 3.4 (Utvärdera de interaktiva versionerna) redogör för metoder att verifiera hur väl designlösningar uppfyller de förväntningar som ställdes initialt i projektet. Vidare har en litteraturstudie genomförts där information insamlats från vetenskapliga artiklar och internetsidor. Urvalet av material för analys har gjorts utifrån frågeställningen: är det möjligt att förbättra användbarheten av webbapplikationer för offentlig service genom införandet av Ajax-teknik? 3.1 Identifiera behov och etablera krav Den inledande fasen i de flesta designprocesser går ut på att identifiera vad som systemet ska klara av och under vilka förutsättningar det ska fungera. För att kunna identifiera behov krävs god kännedom om en produkts målgrupp. Endast då målgruppen är välkänd är det möjligt att förutse till vilken nytta produkten kan vara. Målgruppens behov ligger sedan till grund för de krav som en produkt ska uppfylla. Denna aktivitet är en fundamental del inom användarcentrerad design [2]. Det är vanligt att kategorisera krav i två olika grupper, funktionella krav och icke funktionella krav. Funktionella krav specificerar de handlingar som systemet ska kunna utföra. Icke funktionella krav behandlar de begräsningar som finns för designen eller implementationen [3]. Kravens betydelse kan också skilja sig, vissa krav kan kategoriseras som nödvändiga för systemets funktion medans andra endast anses som önskvärda [1]. Krav som identifieras vid designprocessens början behöver inte vara beständiga utan kan mycket väl ändras eller avskrivas vid senare iterationer [2]. 3.2 Utveckla designalternativ som uppfyller kraven Att utveckla designalternativ kan anses som designprocessens kärnaktivitet. Genom att utveckla designalternativ så föreslår man olika sätt att uppfylla de krav som tagits fram. Denna aktivitet kan med fördel delas upp i de två delaktiviteterna konceptuell design och fysisk design. Konceptuell design innebär att ta fram en konceptuell modell för produkten som beskriver vad produkten ska göra, hur den ska uppträda och se ut. Fysisk design ligger mer på detaljnivå och behandlar saker som färger, ljud, bilder, och ikoner [2] Kortsortering Ett strukturerat menysystem är kanske den viktigaste delen i ett väl fungerande gränssnitt [4]. En snabb och pålitlig metod för att undersöka hur användare föredrar att gruppera innehåll på en webbsida är så kallad kortsortering (card sorting). Kortsorteringsmetoden genererar en

15 Kapitel 3. Metodbeskrivning 8 heltäckande informationsstruktur för en webbplats. Tekniken resulterar även i förslag på navigation, menyer och möjliga taxanomier. Det första steget i kortsorteringsmetoden är att välja ut de ämnen som ska ingå i sorteringen. Dessa kan hämtas från vitt spridda källor, både existerade och potentiellt framtida innehåll är av intresse. Ett lämpligt antal ämnen kan vara stycken. Anteckna namnen på de ämnen som ska kategoriseras på ett antal kort. Nästa steg är att välja ut en testgrupp bestående av 7-10 personer som är representativa för användarna av det färdiga systemet. Försöksdeltagarna ombeds att gruppera ämneskorten i en ordning som känns naturligt för dem. Uppmana deltagarna att sätta rubriker på de grupper som skapas. Övningen är klar så fort som försökspersonerna anser sig klara. Under tiden som sorteringen pågår är det som försöksledare viktigt att dokumentera allt som sker. För anteckningar under sorteringen och var noga med att fånga den slutgiltiga sorteringsordningen. Kortsortering kan inte garantera en komplett informationsstruktur men den kan vara till hjälp att besvara många frågor. Det är högst troligt att testpersonerna tycker olika angående kategorier eller indelningar. I sådana situationer kan kortsortering användas för att identifiera trender. Ett exempel på en typisk frågeställning som kan besvaras genom att studera dessa trender är: Hur vill användarna att informationen ska grupperas efter ämne, process, affärsgrupp eller informationstyp?. Vidare bör resultaten användas för att svara på vilka kategorier ska klassas som huvudkategorier samt vad dessa grupper ska kallas. Själva analysen kan utföras på två olika sätt: genom att studera tydliga mönster eller genom att använda ett verktyg för kluster analys. När det handlar om stora mängder kort är det senare alternativet bättre lämpat. Genom att föra in resultatet i ett kalkylblad kan data hanteras med hjälp av statistiska metoder. Vid mindre omfattande undersökningar räcker det ofta att visuellt studera resultatet för att se mönster i grupper och kategoriseringar. Vid båda varianterna kommer mönster att framträda. Dessa mönster är troligtvis lätta att förstå för användare av systemet. Det är dock viktigt att komma ihåg att även områden där försöksresultaten skiljer sig kan erbjuda viktig information. Dessa områden kan ge insikt om: - Innehåll som användarna inte har förstått - Innehåll som kan tillhöra mer än ett område - Alternativa vägar till innehållet - Hur olika typer av deltagare tolkar informationen Oavsett vilken av analysmetoderna som väljs så finns det inga exakta instruktioner om vad man ska leta efter. För att hitta mönster och kunna dra slutsatser krävs en viss magkänsla [5].

16 Kapitel 3. Metodbeskrivning Skapa interaktiva versioner av designalternativen Interaktionsdesign handlar om att utveckla interaktiva produkter. Det mest direkta sättet att utvärdera interaktiva designalternativ är genom att interagera med dem. Denna interaktion kan uppnås på en rad olika sätt. Inom området interaktionsdesign innebär begreppet prototyp en begränsad representation av en produkt eller design [2]. Prototypen tillåter användare att interagera med en ofullständig produkt och utforska dess användningsområde. Genom att använda sig av prototyper är det enklare att kommunicera och reflektera kring den tänkta produkten. En av de största fördelarna med prototyper är ett de kan användas för att kontinuerligt utvärdera produkter under designprocessen. En prototyp kan vara allt från en simpel skiss på ett papper till ett komplext datorsystem. Tidigt i designprocessen kan det räcka med enkla pappersprototyper för att identifiera problem. Längre fram i processen kan mer avancerade prototyper hjälpa till att hitta problem på en abstraktionsnivå som ligger närmre den fullständiga implementationen. Prototyper kan alltså följaktligen avvika olika mycket från en fullständigt implementerad produkt. De som ligger relativ långt ifrån den slutgiltiga produkten brukar klassificeras som low-fidelity prototyper medan de som har mycket gemensamt med den färdiga produkten betecknas som high-fidelity prototyper [1,2]. Nedan följer en beskrivning av de två nivåerna för att bygga prototyper Low-fidelity prototyper En low-fidelity prototyp är en enkel modell som till hög grad avviker från den slutgiltiga produkten. Low-fidelity prototyper ska användas för att utforska idéer och måste därför vara flexibla och uppmuntra till förändringar. De är ofta producerade i enkla billiga material till exempel kartong eller papper, fokus ligger på att de ska gå snabbt att ta fram. Traditionella pappersskisser är kanske den mest använda metoden för utveckling av dessa prototyper men det existerar även andra metoder. Vid utveckling av webbsidor är datorverktyg vanligt förekommande, fördelen med dessa är att en färdig uppsättning med gränssnittskomponenter tillhandahålls. Low-fidelity prototyper bör inte vara för välutvecklade eller polerade eftersom de då lätt kan uppfattas som något färdigt som inte kan kritiseras. Dessa prototyper är väldigt nyttiga, eftersom de är enkla, billiga och går fort att producera uppfyller de många av de egenskaper som framförallt är önskvärda i de tidigare stadierna av designprocessen. Det är viktigt att ha i åtanke att low-fidelity prototyper endast är till för utforskning och inte ämnade att behållas för integrering i den slutgiltiga produkten. Nackdelarna med denna typ av prototyp är att det är svårt att simulera navigation och flöde hos komplexa ickelinjära gränssnitt genom enkla skisser. Det kan även vara problematiskt att identifiera brister i användbarhet genom enkla prototyper [2] High-fidelityprototyper High-fidelity prototyper är mer detaljerade och inrymmer fler av egenskaperna som den slutgiltiga produkten förväntas besitta. Till exempel så är en mjukvaruprototyp utvecklad i Visual Studio mer high-fidelity än motsvarande pappersbaserade prototyp. Dessa prototyper

17 Kapitel 3. Metodbeskrivning 10 bygger ofta på kunskaper som erhålls vid utveckling och utvärdering av tidigare low-fidelity prototyper. För att bygga en mer avancerad mjukvaruprototyp är det ofta lämpligt att använda sig av någon form av utvecklingsverktyg. Dessa verktyg är ofta kraftfulla och möjliggör ett rättframt sätt att ta fram prototyper. High-fidelity prototyper är användbara för att identifiera interaktionsmönster, testpersoner får en känsla för navigering och flöde i den slutgiltiga produkten. De ger även en förnimmelse om känsla och utseende hos den färdiga designen. Nackdelen med mer komplexa prototyper är att de tar relativt lång tid att utveckla vilket medför att de inte är lika flexibla eller mottagliga för förändring [2] Konceptuell design I den konceptuella designfasen överförs de fastställda kraven till en konceptuell modell av systemet. En beskrivning av det tänkta systemet i termer av integrerade idéer och koncept om vad systemet skall göra, hur det skall bete sig och hur det ska se ut. Målet är att denna beskrivning även kommer att förstås av användare på det förväntade sättet [2]. Grunden för att konstruera denna modell är de uppgifter som användare av systemet ska kunna utföra. Interaktionsdesignerns uppgift är att fokusera på vilka de tilltänkta användarna är och vilka mål och behov de har när man ska formulera en vision för den färdiga produkten. Genom att basera modellen på välkända processer, objekt eller metaforer blir den enklare för användare att ta till sig [6]. En bra konceptuell modell gör att användaren känner igen sig, även i situationer som denne inte upplevt tidigare [6,2] Fysisk design Till skillnad från konceptuelldesign innebär den fysiska designen någonting mer konkret men det finns ingen tydlig gräns mellan de två. Den fysiska designen involverar detaljer som knappar, menysystem och grafik. Fysisk design handlar om att försöka uppfylla de funktionella krav som ställs på systemet. Det är vanligt att kraven står i konflikt med de förutsättningar som finns vilket leder till att kompromisser måste göras. Det är viktigt att den fysiska designen inte står i konflikt med den kognitiva process som pågår hos användaren vid genomförandet av en specifik uppgift [2]. kob Nielsen har introducerat 10 riktlinjer som kan ligga till grund för beslut som tas vid genomförandet av den fysiska designen och som också använts i detta projekt [7]: - Synlighet av systemets status. Systemet ska förse användare med information om vad som pågår genom kontinuerlig feedback. - Matchning mellan systemet och verkligheten. Systemet ska tala samma språk som dess användare, ord, fraser och koncept ska vara välkända för användaren. Följ konventioner från verkligheten så att information framförs på ett naturligt och logiskt sätt.

18 Kapitel 3. Metodbeskrivning 11 - Användarkontroll och frihet. Användare begår ofta misstag och behöver stöd för att ta sig ur oönskade tillstånd. Ge stöd för handlingar som ångra och gör om. - Konsekvens och standarder. Användare ska inte behöva fundera om olika ord, situationer, eller handlingar betyder samma sak. Följ de konventioner som gäller. - Förebygg fel. En väl genomtänkt design som förebygger att ett problem inträffar är till och med bättre än ett tydligt felmeddelande. Eliminera antingen alla felkällor eller varna användare innan de utför en handling som kan leda till fel. - Igenkänning före erinring. Minimera behovet för användare att komma ihåg saker genom att göra objekt, handlingar och alternativ synliga. Användaren ska inte behöva komma ihåg information från en situation till en annan. Instruktioner för att använda systemet ska vara synliga eller enkla att ta fram. - Flexibilitet och effektiv användning. Ge stöd för olika kunskapsnivåer hos användarna. Inkludera funktioner som kan göra arbetet effektivare för erfarna användare men gör dem inte synliga för oerfarna användare. - Estetisk och minimalistisk design. Systemet ska bara presentera information som är relevant eller som ofta behövs. All överflödig information konkurrerar med och försämrar synligheten av relevant information. - Hjälp användare att känna igen, diagnostisera och korrigera fel. Felmeddelanden ska utryckas i vardagligt språk, vara precisa, beskriva problemet samt föreslå en lämplig lösning. - Hjälp och dokumentation. Det är alltid bättre om ett system kan användas utan några instruktioner, det kan dock vara nödvändigt att tillhandahålla hjälp och dokumentation. All information av denna typ ska vara sökbar, fokuserad på vad som ska utföras samt konkret lista de steg som måste genomföras. 3.4 Utvärdera de interaktiva versionerna Det sista steget i varje iteration av designprocessen är alltid utvärdering. Genom utvärdering är det möjligt att fastställa om designen är godtagbar och hur användbar den är. Detta kan mätas på olika sätt men vanligt förekommande är att räkna antalet fel testpersonerna begår, hur tilltalande produkten är eller hur väl kraven tillgodosetts. Interaktionsdesign gagnas att användare involveras i samtliga steg av utvecklingsprocessen och chansen att en användbar produkt levereras ökar. Utvärdering innebär att systematiskt samla in data om hur det är för en specifik användare eller grupp av användare att använda en produkt för en given uppgift i en viss omgivning.

19 Kapitel 3. Metodbeskrivning 12 Detta är en av grundstenarna i användarcentrerad utveckling. Utan utvärdering är det omöjligt att fastställa att en applikation är användbar och uppfyller användarnas krav. Med hjälp av kontinuerliga utvärderingar är det möjligt att fånga upp problem tidigt i utvecklingsprocessen och undvika kostsamma omkonstruktioner i ett senare skede. Under designprocessen förändras även produkten och man måste utvärdera på nytt för att säkerhetsställa att kraven är uppfyllda. En iterativ cykel designa-utvärdera-omdesigna uppstår, det krävs kunskap för att välja rätt utvärderingsmetod vid rätt skede i utvecklingen. När produkten anses klar avgörs vanligtvis av tid och budget. Vid utvärdering av ett gränssnitt finns ett antal metoder att välja mellan. Två olika utvärderingsmetoder kommer att användas för att utvärdera de två olika prototyperna som utvecklats under projektet, Quick and dirty -utvärdering och användartester. Nedan beskrivs förfarandet vid de båda utvärderingarna [2] Quick and dirty utvärdering Quick and dirty är en snabb informell utvärderingsmetod som används till att samla in feedback samt verifiera att idéer och koncept stämmer överens med användarnas behov. Denna typ av utvärdering kan genomföras när som helst i designprocessen, tyngdpunkten ligger på snabb respons inte noggrant dokumenterade resultat. Utvärderingen resulterar i anteckningar och skisser samt intervjumaterial och samlade kommentarer [2] Användartest Användartester är ett sätt att utvärdera en produkt genom att dokumentera hur typiska användare agerar i kontrollerade testsituationer. Styrkan med metoden är att den tillhandahåller direkt information om exakt vilka problem användare stöter på i kontakten med den aktuella gränsytan [8]. Exakt vad man väljer att fokusera på beror på hur långt fram i designprocessen man väljer att utvärdera produkten. Vid utvärdering i ett tidige skede kan det vara av intresse att reda ut hur användarvänlig produkten är och hur idéer fungerar. Vid test i ett senare skede kan det vara intressant att undersöka om produkten uppfyller de krav som specificerats, alternativt hur den fungerar som en helhet. Detta genom att fånga upp hur väl produkten presterar i termer av till exempel effektivitet och felfrekvens. Fokus ligger på att undersöka hur väl en produkt uppfyller dess ursprungliga syfte. Tillvägagångssättet består i att skapa scenarion eller realistiska situationer, där användarna får utföra ett antal uppgifter med hjälp av produkten. Användarnas agerande observeras antingen genom direkt observation eller med någon form av inspelningsutrustning. Resultatet analyseras sedan i termer av effektivitet, antal fel, känslomässig respons och igenkänning. Det är av stor vikt att komma ihåg att det är produkten som ska testas inte användaren. Testet ska utföras i en lugn kontrollerad miljö [2,8].

20 Kapitel 4 Ajax-applikationer och användbarhet På senare år har webben utvecklats från att vara ett statiskt medium för presentation av information till att vara mer dynamisk med större möjligheter till interaktion. Användning av e- tjänster kan i många situationer jämföras med bruket av traditionella skrivbordapplikationer. AJAX står för Asynchronous vascript And XML och är ett samlingsnamn för olika tekniker för att skapa webbapplikationer där bara delar av användargränssnittet uppdateras vid behov [9]. Denna litteraturstudie behandlar huruvida man kan göra e-tjänster mer användarvänliga genom att använda AJAX, en som teknik skiljer sig på många sätt från det klassiska sättet att bygga webbsidor. I fördjupningen undersöks för- och nackdelarna med Ajax och hur det påverkar användbarheten hos en applikation. Vad måste man som utvecklare ha i åtanke då man utvecklar med AJAX? 4.1 Teoretisk bakgrund Begreppet Ajax myntades och fick sitt stora genombrott 2005 men teknologin bakom har existerat betydligt längre än så. På senare tid har tekniken används vid utvecklingen av många uppmärksammade webbapplikationer, den mest väl kända kanske är Google Maps som är ett interaktivt kartverktyg som låter användare studera omvärlden med hjälp av satellitbilder [10]. Ajax involverar vanligtvis följande tekniker [11]: - XHTML och CSS för att styra presentationen - DOM för att dynamiskt kunna styra innehållet på webbsidan - XML eller något annat format för att ta emot data - XMLHttpRequest används för att skicka och ta emot data asynkront mellan klient och server. - vascript för att sammanföra de olika teknikerna Det var dessa tekniker som Jesse mes Garrett refererade till då han myntade begreppet Ajax [10]. Det har dock visat sig att även andra tekniker kan användas för att uppfylla definitionen Den traditionella webbapplikationsmodellen

21 Kapitel 4. Ajax-applikationer och anvädbarhet 14 Den traditionella webbapplikationsmodellen härstammar från Internets ursprungliga användningsområde som hypertext medium. Den traditionella modellen för webbapplikationer innebär att användargränssnittet uppdateras genom att hela HTML-sidor laddas. När en användare interagerar med en webbapplikation genom att till exempel klicka på en länk så sker ett HTTP-anrop till webbservern. Servern processar inputen t.ex. genom att hämta information från en databas. Därefter sätter servern ihop en ny HTML-sida som den returnerar till klienten för rendering, se figur 4.1 [10]. Figur 4.1: Den traditionella webbapplikationsmodellen, baserad på figur 1 i [10]. Traditionellt är det alltså användaren som indirekt styr när webbläsaren ska kommunicera med webbservern. Denna interaktion med webbservern brukar kallas för synkron. Synkron kommunikation innebär att det uppstår en väntetid för användaren medan server processar data, se figur 4.2. Denna modell har många tekniska fördelar utifrån Internets ursprungliga användningsområde, men är inte anpassat för hur Internet brukas idag med avancerade användargränssnitt, gränssnitt där användaren inte bara hämtar information, utan även bidrar med den.

22 Kapitel 4. Ajax-applikationer och anvädbarhet 15 Figur: 4.2: Sykron kommunikation mellan klient och server, baserad på bild figur 2 i [10] Webbapplikationsmodellen med Ajax Ajax innebär att en extra nivå introduceras i webbapplikationsmodellen, en Ajax-motor som placeras mellan användaren och servern. Istället för att en webbsida renderas direkt i webbläsaren laddas i stället en Ajax-motor in, se figur 4.3. Denna motor ansvarar både för att rendera gränssnittet och att kontrollera användares kommunikation med webbservern [11].

23 Kapitel 4. Ajax-applikationer och anvädbarhet 16 Figur 4.3: Webbapplikationsmodellen med Ajax, baserad på bild figur 1 i [10]. Ajax-motorn låter användarens interaktion med webbsida ske asynkront, det vill säga helt oberoende av kommunikationen med servern. Detta innebär att användaren slipper vänta på att servern ska processa data efter varje interaktion. När användaren utför något som i vanliga fall skulle generera en http-förfrågan körs istället ett vascript som anropar Ajax-motorn. Alla typer av interaktioner mellan webbsidan och användaren kräver inte att servern blandas in. Enklare validering eller redigering av data som finns sparat i minnet kan motorn hantera av sig själv. Så fort Ajax-motorn behöver någon information från servern så utför den ett asynkront anrop. Detta sker vanligtvis genom XML-meddelanden och utan att uppehålla användarens interaktion med webbsidan [10,11].

24 Kapitel 4. Ajax-applikationer och anvädbarhet 17 Figur 4.4: Asykron kommunikation mellan klient och server, baserad på bild figur 2 i [10]. Eftersom information kan skickas och hämtas utan att användaren måste ladda om hela webbsidan, kan små dataöverföringar mellan servern och klienten utföras vid behov se figur 4.4. Vidare kan olika element på en webbsida uppdateras dynamiskt. Detta medför att en Ajax applikation uppträder snarlikt en lokal skrivbordsapplikation. Resultatet blir en användarupplevelse som skiljer sig från det traditionella sättet att utforska webbsidor [12]. 4.2 Ajax och användbarhet Ajax gör många nya tekniker tillgängliga för webbutvecklare som tidigare enbart kunde uppnås genom DHTML eller insticksprogram som Flash. Tekniken förser utvecklare med verktyg som har potentialen att öka interaktionen mellan webben och dess användare. Detta behöver inte enbart ses som något positivt. Animationer, popup- fönster, blinkande text är bara några av distraktioner som görs möjliga [12]. Innan man beskriver hur användbarhet ska skapas kan det vara en god idé att definiera vad det är. kob Nielsen väljer att dela in begreppet användbarhet i fem delar [13]: - Lärbarhet: Hur enkelt är det för användare att utföra grundläggande uppgifter första gången de använder en applikation - Effektivitet: Hur effektivt kan vana användare utföra uppgifter.

25 Kapitel 4. Ajax-applikationer och anvädbarhet 18 - Enkel att minnas: Hur lätt kan användare återuppta sina gamla färdigheter efter ett uppehåll i användningen av en applikation. - Fel: Hur många fel begår användare, hur allvarliga är dessa fel och hur snabbt kan de åtgärda felen. - Tillfredställelse: Hur tillfredställande är det att använda en design. I detta kapitel utreds hur införandet av Ajax kan användas för att öka användbarheten för en webbapplikation. Viktiga frågeställningar som ska besvaras är vad ska undvikas och i vilka situationer det är lämpligt att utnyttja Ajax-funktionalitet Fördelar med Ajax Ajax-applikationer anses ha bättre prestanda än traditionella webbapplikationer [3]. Generellt sett stämmer detta påstående eftersom Ajax möjliggör mer responsiva gränsytor där användare slipper de avbrott som vanligtvis uppstår vid omladdning av webbsidor. Användarupplevd prestanda definieras som tiden mellan det att en användare utför en handling till det att systemet ger någon form av respons. Korta responstider ger användaren en känsla av att systemet är högpresterande [14]. Eftersom en minimal mängd data skickas mellan klienten och servern blir Ajax-tillämpningar snabba. Detta innebär också en effektiv användning av bandbredd [11]. Ökad interaktivitet är en av de mest signifikanta positiva effekterna av Ajax. Genom att tillåta användare att arbeta direkt med data på servern kan en Ajax-applikation erbjuda avancerad funktionalitet. Designern får tillgång till samma repertoar av interaktionskontroller som finns för skrivbordsapplikationer. Det är även möjligt att finjustera detaljer i hur gränssnittet ska agera. Interaktivitet mellan användare och system är starkt kopplat till användbarhet. Studier har visat att en ökad interaktivitet har en positiv inverkan på användares upplevda tillfredställelse, effektiviteten, verkningsgraden och den allmänna attityden gentemot en webbsida Tester har visat att användare föredrar interaktiva Ajax-funktioner över traditionella webbkontroller [15]. En annan fördel med Ajax är möjligheten att skapa webbgränssnitt där det mesta av funktionaliteten ryms inom en HTML-sida. Detta kan leda till en signifikant förbättring av användarupplevelsen. Genom att minska antalet webbsidor som måste besökas för att utföra en uppgift ges användaren ett bättre arbetsflöde att jobba efter Nackdelar med Ajax Sättet att interagera med en webbsida som introduceras genom Ajax medför även fällor som man som designer lätt kan falla i. Källan till dessa är vanligtvis att gränssnittet uppdateras utan att användaren observerar det [16].

26 Kapitel 4. Ajax-applikationer och anvädbarhet 19 Det är vanligt att Ajax-tillämpningar dynamiskt uppdaterar och manipulerar element i gränssnittet. Det är också möjligt att överlämna information till servern utan någon interaktion med användaren. Till exempel så är de flesta användare vana vid att formulärdata skickas, valideras och processas när de trycker på knappen Skicka. Med Ajax kan informationen processas närsomhelst, utan att det krävs någon knapptryckning. Detta kan förvirra användare och göra dem osäkra [17]. Ett annat problem med Ajax är hur gränssnittet uppdateras. När en uppdatering av gränssnittet sker är det inte säkert att användaren lägger märke till de ändringar som utförts. Konsekvensen kan bli felaktiga inmatningar, eftersom användaren arbetar utifrån den gamla vyn utan att observera de förändringar som skett. Detta problem är ännu större för de som använder sig av skärmläsare. Dessa verktyg läser vanligtvis en webbsida linjärt från början till slut. När gränssnittet förändras, är det inte garanterat att skärmläsaren lägger märke till förändringen och det nya innehållet kommer inte att bli uppläst. En hel uppdatering av sidan innebär att användarna är väl medvetna om att deras handling har påverkat applikationen och att respons kommer så fort som sidan laddats om [18]. Ajax kräver vascript, detta innebär att applikationer utvecklade med tekniken inte kommer att fungera i webbläsare eller enheter som inte har stöd för vascript. Av denna anledning är Ajax inte tillgänglig för många webbanvändare [17]. I vägledningen 24-timmarswebben finns det ett uttryckligt krav att det på en webbplats ska vara möjligt att använda alla funktioner utan tillgång till vascript [4]. Vilket måste beaktas i detta projekt då det är ett uttryck krav från uppdragsgivaren att vägledningen ska följas. Dynamiskt uppbyggda sidor registreras inte i webbläsarens historikobjekt. Eftersom Ajaxapplikationer inte laddar in helt nya webbsidor kommer inte historikobjektet att känna till uppdateringar av innehållet eftersom de har skett asynkront. Detta medför att webbläsarens bakåt- och framåtknappar inte kommer att fungera som förväntat med det finns lösningar för att justera detta med hjälp av vascript [12]. 4.3 Hur ska AJAX användas Ajax är en relativt ny teknik och att använda den till att bygga användarvänliga webbtjänster är fortfarande ett område under utveckling. Vad måste man då som designer tänka på vid användning av denna teknik? Eftersom Ajax-applikationer innebär en ny interaktionsform på webben bör man komma ihåg att användare inte är vana vid hur de fungerar. Det första man måste tänka på som utvecklare är att göra användare medvetna om den funktionalitet som är tillgänglig. Det går inte att utgå ifrån att användare ska upptäcka att ett objekt går att dra, ett fält går att editera eller att en bild kan kommenteras. Man måste tänka på att se till att tydligt markera de element som kan

27 Kapitel 4. Ajax-applikationer och anvädbarhet 20 modifieras. Funktioner som kräver en viss inmatningsenhet ska undvikas. Ett exempel är funktioner som kräver att användaren med musen drar och släpper objekt [4]. Vid design av Ajax-applikationer är det av stor vikt att kommunicera till användare att sidans innehåll uppdateras. Två vanliga metoder för att upplysa användare om att en uppdatering har skett är att använda färg och animationer. Att ändra färg på uppdaterade element är ett effektivt sätt att belysa området för förändring. Det är dock viktigt att välja en färg som utgör en god kontrast mot resten av gränssnittet. Animation kan också vara ett effektivt medel att påkalla uppmärksamhet eftersom människor instinktivt fokuserar på rörelser. Animationer kan också användas för att förstärka känslan av respons hos gränssnittet. Vid användning av visuella effekter som förmedlar information till användarna är det viktigt att komma ihåg att samma information måste förmedlas till de som inte kan se innehållet. En annan metod som kan kombineras med ovanstående är att förvarna användarna att en viss handling kommer att leda till en uppdatering. Ajax bör inte användas till funktioner som redan finns i webbläsaren eller fungerar lika bra utan. All webbläsarspecifik funktionalitet bör undvikas. Använd istället etablerade standarder som W3C:s dokumentobjektmodell (DOM) [4]. Gör det möjligt att skapa länkar till informationen på en webbplats. Om skript används för att dynamiskt uppdatera sidan med information bör det vara möjligt att referera till den i andra sammanhang genom t.ex. vanliga länkar [4] Diskret Ajax Rätt tillämpat kan Ajax göra mycket för användbarheten hos en webbplats. Det finns dock ett grundläggande krav för all utökad funktionalitet av detta slag: det måste fungera även utan vascript [4]. Diskret Ajax är en metod för att utveckla webbapplikationer som infriar detta krav. Det handlar inte om någon webbstandard utan om en god praktik för att utveckla webbapplikationer. Tanken är att webbapplikationer ska fungerar för de flesta webbläsare och klienter utan att några specifika tekniska krav ställs. Det enda som kan förutsättas är att användaren är kapabel att interagera med rena html-sidor, allt annat ska vara valfritt. Diskret Ajax handlar om separation, att separera vascript från (X)HTML, att skilja beteendet från innehållet på ett sätt som gör att (X)HTML - koden fungerar autonomt. Vidare innebär diskret Ajax att innehållet ska separeras från presentationen. vascript och (X)HTML ska inte användas för att definiera hur saker ska se ut, utan detta ska styras med hjälp av fristående stilmallar (CSS). Separationen av HTML, CSS och vascript bör ske både på en fysisk- och en konceptuell nivå. Genom att skilja på funktion, beteende och innehåll blir det lättare för utvecklaren att organisera systemets struktur och det säkerställs att varje del fungerar självständigt. Detta är särskilt viktigt för (X)HTML-koden [19]. Praktiskt innebär diskret Ajax att all vascript-kod ska placeras i separata skriptfiler, vascript ska aldrig inkluderas som ett attribut i ett (X)HTML-dokument. Nedan följer ett typiskt exempel på dålig uppmärkning där vascript har blandats med HTML.

28 Kapitel 4. Ajax-applikationer och anvädbarhet 21 <a onclick="gornagot()" href="#">klicka!</a> God uppmärkning är när alla beteenden som styrs av vascript ligger i en separat skriptfil som länkas till dokumentet genom en <script>-tag i sidhuvudet [20,21]. Ett exempel på god uppmärkning kan se ut som nedan: <a href="backuplink.html" class="gornagot">klicka!</a> Den tillhörande vascript-koden: $('a.gornagot').click(function(){ // Här ska något göras! alert('du har gjort något!'); }); Att skriva kod på detta sätt innebär att den fungerar oavsett om vascript är tillgängligt hos klienten. Det enklaste sättet att utveckla en webbapplikation med diskret Ajax är att tidigt i utvecklingsprocessen arbeta utifrån kravet att vascript inte är tillåtet. Vänta tills all nödvändig funktionalitet är klar innan den första raden vascript skrivs. När sidan väl fungerar utan vascript är det dags att börja fundera hur användarvänligheten ska förbättras genom att tillföra vascript och asynkrona anrop mot webbservern [19, 21] Principer för Ajax-applikationer Nedan identifieras några grundprinciper som kännetecknar väl genomförda Ajax-applikationer. Inga överraskningar: Ajax applikationer introducerar ofta nya interaktionsmodeller som inte återfinns i traditionella webbapplikationer. I stället för klicka-vänta använder Ajax applikationer andra gränssnitsparadigm så som dra-och-släppa eller dubbelklicka. Oavsett vilken interaktionsmodell som väljs är det viktigt att vara konsekvent så att användare vet vad de kan förvänta sig [22]. Etablerade konventioner: Ödsla inte tid på att uppfinna nya interaktionsmodeller som användare inte är vana vid. Låna istället från traditionella webbapplikationer och skrivbordsapplikationer. När användare känner igen sig minskar inlärningskurvan för gränssnittet [22]. Inga distraktioner: Undvik onödiga objekt, så som itererande animationer och blinkande texter. Överflödiga element som inte tillför något distraherar användaren från den uppgift som ska utföras [23]. Tillgänglighet: Beakta vad applikationen har för målgrupp och hur dessa mest sannolikt kommer att bruka applikationen. Lås dock inte applikationen till målgruppen så att en ny oväntad användargrupp blir utestängd. Det är viktigt att tänka på att vissa användare kanske har äldre webbläsare eller behov av specialverktyg [22].

29 Kapitel 4. Ajax-applikationer och anvädbarhet 22 Undvik nedladdning av hela sidor: Efter att den första sidan laddats ner ska all kommunikation med servern hanteras av Ajax-motorn. Att uppdatera små mängder data i vissa situationer medan hela sidan laddas om i andra förstör användarupplevelsen [23]. Användaren först: Designa en Ajax-applikation utifrån användarna. Försök bygga upp applikationen så att vanliga användarscenarion blir enkla att utföra. Undvik att låsa tankegångarna runt bruk av spektakulära effekter [22]. Lita inte på vascript: Som utvecklare går det aldrig att förlita sig till stöd för vascript för att leverera innehåll eller information. Det går dock bra att använda vascript för att förbättra informationen, göra den snyggare eller mer interaktiv [23]. 4.4 Användning av AJAX för e-bokningssystem När ett webbformulär kräver fler än ett steg är det ofta ett tecken på att den underliggande funktionalitet är bättre lämpad för en webbapplikation, viken erbjuder användare en mer interaktiv upplevelse [24]. En av de stora fördelarna med Ajax är möjligheten att bygga gränssnitt där alla interaktioner sker på en och samma HTML-sida. Enkel-sidiga användargränssnitt tillåter användare att arbeta på ett mer intuitivt icke linjärt sätt [25]. Tidigare webbapplikationer har inte fungerat på detta sätt, traditionella webbsidor är uppbyggda av en sidstruktur där användare navigerar från sida till sida. En modell som passar bra i många situationer t.ex. vid läsning av nyheter. Läsning av nyheter börjar vanligtvis med att användaren klickar på en rubrik, rubriken är en länk som leder till en ny sida innehållande hela artikeln. Långa artiklar kan vid behov även delas upp på flera sidor. Användaren navigerar mellan sidor med hjälp av knappar som nästa och föregående. Eftersom läsning i grunden är en linjär process så passar denna modell bra för webbsidor som levererar denna typ av innehåll [26]. Traditionella fler-sidiga webbapplikationer fungerar väl för enkla linjära arbetsflöden. Enkel-sidiga gränssnitt är dock betydligt effektivare för komplexa, icke linjära arbetsflöden [25]. Att boka lokaler genom ett webbaserat bokningssystem kan delas in i följande fem steg: 1. Definiera kraven för bokningen (tid, plats, pris osv.) 2. Sök efter alternativ som uppfyller kraven 3. Utvärdera och jämför alternativen 4. Bestäm vilket alternativ som passar bäst 5. Genomför bokningen Detta är tillsynes en relativt linjär process, vilket dock inte alltid är helt riktigt. Bokning behöver inte innebära ett komplext arbetsflöde, beroende på användare kan det vara väldigt enkelt. Vissa användare bokar samma lokal samma tid månad efter månad, för dessa människor är bokning en snabb sekventiell process.

30 Kapitel 4. Ajax-applikationer och anvädbarhet 23 Medan vissa användare vet precis vad de är ute efter måste dock de flesta kompromissa. Anta att en användare vill boka en tid för tennis kommande vecka. Kraven för denna bokning kan då till exempel definieras som: - Plats: En lokal inom rimligt avstånd - Aktivitet: Tennis - Tidpunkt: torsdag den 25/10 mellan 17:30 och 20:00 - Aktivitetslängd: 2 timmar - Pris: Mellan 0 och 120kr Dessa krav kommer antagligen att resultera i flera olika alternativ. Så hur väljer användaren då? För att kunna välja det mest lämpade alternativet måste resultatet från flera sökningar jämföras. Antagligen kommer användaren att genomföra mer ingående analys av alternativen. Lokal, avstånd, pris, tider kommer att ställas mot varandra och någon form av kompromiss måste göras. Upprepade sökningar på fler-sidiga bokningsgränssnitt är en tröttsam uppgift. Dessa användargränssnitt tvingar användare att följa en specificerad linjär väg från sökning till formulär för att genomföra bokningen. Denna process är väl fungerande för användare som vet precis vad de är ute efter och detta finns också tillgängligt. Problem uppstår dock då användare måste kompromissa eller undersöka olika alternativ. I bokningssystem med flersidiga användargränssnitt är det mycket vanligt att nästan alla steg i bokningsprocessen har en egen sida [25]. I nuvarande version av Interbook finns till exempel en sida för inloggning, en sida för sökning, en sida för att visa resultat av sökningen, en sida för detaljerad information om varje sökresultat och en sida för bokning. Detta gör det svårt för användare att få en översikt av informationen i systemet. När användare ser en lista med sökresultat kan de inte se de sökkriterier som genererade resultatet, vilket gör det svårt att förfina sökningen. För att gå tillbaka och ändra ett sökvillkor måste hela processen göras om från steg ett. Användare som vill undersöka många olika alternativ tvingas att besöka många olika sidor. Att klicka sig bakåt och framåt i systemet är tidskrävande och det finns en risk att tappa bort sig i systemet. Detta upplägg för ett webbaserat bokningssystem har många brister och ger dåligt stöd till användare vid sökning, jämförande av alternativ och beslutsfattande. Att införa ett enkel-sidigt gränssnitt skulle kunna förbättra användarupplevelsen för Interbook markant. Att sammanföra steg 2,3 och 4 av bokningsprocessen till ett och samma gränssnitt skulle göra förfarandet betydligt mer intuitivt. Om sökning, presentation av resultat och presentation av detaljinformation kan göras på samma sida är det mycket enklare att jämföra olika alternativ samt förfina sökvillkoren. När användaren får en överblick av alla de viktigaste elementen på samma sida blir det enklare att söka, anpassa sökningar, se mönster och jämföra alternativ. Kombinationen av direkt respons och en god överblick gör att applikationen blir mer tillfredställande att använda. Användare förväntas uppleva att de får ett bättre arbetsflöde och mer kontroll över bokningsprocessen [25].

31 Kapitel 4. Ajax-applikationer och anvädbarhet Slutsatser Genom att använda Ajax på ett genomtänkt sätt finns det goda möjligheter att förbättra användares uppfattning av en webbplats och motivera återbesök. Ajax kan göra väldigt mycket för användbarheten hos en webbplats. Det kan göra den snabbare, interaktivare, enklare att navigera samt lättare att hantera [4]. Det är inte nödvändigtvis så att Ajax-applikationer garanterar en bättre användarupplevelse än traditionella webbapplikationer. Ajax förser interaktionsdesignern med fler och kraftfullare verktyg. Ökad flexibilitet kräver dock viss försiktighet, Ajax är inte någon universal lösning för alla situationer. Utan vid felaktig eller överdriven användning är det sannolikt att användbarheten nedgraderas hos en applikation. Frågan kvarstår, när ska tekniken nyttjas? I alla situationer där interaktionen med en webbapplikation bygger på en linjär process i flera steg bör Ajax övervägas som ett alternativ. När effektivitet är ett viktigt krav finns det också mycket att vinna genom att använda Ajax. Viktigt att tänka på när man applicerar Ajax är att göra det på ett sätt som inte utesluter användare som av någon anledning inte har stöd för vascript i sin utrustning. I de flesta riktlinjer och checklistor framhävs att en webbapplikation ska fungera oberoende av vascript. Ajax tillför webben interaktionsformer som användare inte är vana vid, inga tydliga konventioner existerar. Därför är behovet av att experimentera, diskutera och reflektera stort. Dock ska man ha i åtanke att många av de interaktionsproblem som dyker upp vid utveckling av Ajax-applikationer har blivit lösta tidigare, i skrivbordsapplikationer. Än så länge finns det inga beprövade heuristiker för att utvärdera webbsidor som utnyttjar denna typ av teknik. Som designer är det enklaste sättet att säkerställa att ens applikation fungerar att testa. Genom att involvera användare i utvecklingsprocessen samt följa de råd som presenteras ovan så är det möjligt att bygga lösningar som är både tillgängliga och användarvänliga.

32 Kapitel 5 Genomförandebeskrivning I detta kapitel beskrivs projektets förlopp från det inledande stadiet till den slutgiltiga prototypen. Det tillvägagångssätt som introducerades i kapitel 3 har agerat som modell för genomförandet, det vill säga ett iterativt arbetsflöde där användare involveras i slutskedet av varje cykel för att utvärdera delresultaten. Den skriftliga framställningen av designprocessen som görs i denna rapport är till viss del missvisande, då den presenteras som en linjär process där de olika aktiviteterna inträffar sekventiellt. I själva verket har många av aktiviteterna löpt jämsides och influerat varandra. Istället för att utgå ifrån det befintliga gränssnittet för Interbook och utvärdera detta togs beslutet att utveckla ett helt nytt koncept för applikationen. Anledningen var att den existerande designen var så pass bristfällig att endast justeringar av denna troligtvis inte skulle ge ett tillfredställande resultat. Det ansågs lämpligare att bygga helt nya gränssnitt och dra fördel av aktuella tekniker. På grund av projektets begränsade tid var det inte möjligt att revidera alla gränssnitt i bokningssystemet utan arbetet koncentrerades till de delar av systemet som berör själva bokningsförfarandet (registrering, inloggning, sök tider, visa sökresultat, visa schema och boka tid). De här delarna ansågs vara de viktigaste för systemets funktion och valdes ut i samråd med en referensgrupp sammansatt av uppdragsgivaren. Referensgruppen utgjordes av 5 personer på Explizit som alla arbetar eller har arbetat med Interbook, varav en säljare, en produktägare samt tre utvecklare. 5.1 Prototyputveckling, iteration 1 I detta avsnitt beskrivs designprocessens första iteration Identifiera behov och etablera krav Inledningsvis genomfördes ett möte med den referensgrupp som etablerats. Under mötet avhandlades produkten, existerande problem och de önskemål som fanns inför framtiden. Avsikten med mötet var att ta reda vad som förväntades av projektet. Systemets målgrupp diskuterades och det konstaterades att inga restriktioner gällande ålder eller datorvana kunde göras. Bokningssystemet riktar sig mot offentlig service vilket innebär en väldigt bred målgrupp. Den enda beröringspunkten i den blivande användargruppen är nyttjandet av internet. Efter diskussionen med referensgruppen sammanställdes önskemål, synpunkter och idéer i en kravspecifikation för prototypen, denna återfinns i avsnitt 6.1. Kravspecifikationen är ett viktigt dokument för att kunna fortlöpa med designprocessen, den

33 Kapitel 5. Genomförandebeskrivning 26 är även värdefull i slutet av projektet för att verifiera hur väl prototypen uppfyller de förväntningar som fanns vid projektets inledning Utveckla designalternativ Efter att behoven identifierats och kraven etablerats fortlöpte arbetet med att utforska olika designalternativ och koncept för systemet. Målet var att transformera de förutsättningar som identifierats i kravspecifikationen till en konceptuell modell för systemet. Genom enkla skisser undersöktes en mängd olika idéer för både layout och interaktionsmodeller, se figur 5.1. Utgångspunkten för arbetet var att hitta en bra placering för de element som är nödvändiga för systemets funktion. Skisserna diskuterades fram och tillbaka med handledare och övriga anställda hos uppdragsgivaren tills ett mer förfinat koncept formats. En grundmall för de element som är gemensamma för alla delar av systemet utarbetades. Denna innefattade ett sidhuvud, en huvudmeny, en länkstig samt en sidfot. Tanken var att systemets olika delsidor skulle placeras inom denna grundmall. Grundmallens utformning presenteras i avsnitt 6.3. Med stöd av de resultat som framkom i fördjupningen gjordes valet att frångå den traditionella modellen för webbapplikationer. Tanken var i stället att placera stora delar av funktionaliteten för att söka och boka tider inom en och samma sida. Följaktligen sammanfördes de tidigare separata delarna sök lokaler, visa resultat och visa schema till en gemensam webbsida. Detta innebar ett steg bort ifrån den sekventiella process som tillämpas vid bokning i det nuvarande systemet, användaren får större flexibilitet och kan enklare styra arbetsflödet. Svårigheten med detta var hur det skulle realiseras utan att gränssnittet skulle kännas överbelamrat eller rörigt. Det mest utmanande momentet var att finna en lämplig placering av schemat. Det första alternativet som övervägdes var att schemat för en vald lokal skulle presenteras jämsides med sökresultatet. Fördelen med detta alternativ var att relationen mellan sökresultat och lokalschema blir väldigt tydlig. Det finns dock en stor nackdel, schemat måste samsas om utrymme med sökresultaten, schemats bredd begränsas vilket i förlängningen leder till sämre överskådlighet. En alternativ lösning var att placera schemat på så vis att det täcker sökresultaten. Effekten blir ett mer överskådligt schema men på bekostnad av en mindre tydlig koppling mellan schema och sökresultatet. Ett tredje alternativ innebar att schemat skulle presenteras i ett popup-fönster. Efter diskussion med referensgruppen togs beslutet att gå vidare med alternativ två, det vill säga att schemat placeras över listan med sökresultat. Då många kunder har beklagat sig över storleken på schemat i det nuvarande systemet, var schemats överskådlighet något som skulle prioriteras. Det uttrycktes också en rädsla för att gränssnittet skulle bli rörigt om allt för mycket information presenteras samtidigt.

34 Kapitel 5. Genomförandebeskrivning 27 Figur 5.1: Tidiga gränssnittsskisser Low-fidelity prototyp För att snabbt kunna få feedback på den desinglösning som utvecklats tillverkades en lowfidelity prototyp. Med utgångspunkt från de idéer som fick bäst respons påbörjades arbetet med att utforma den första prototypen. Denna prototyp konstruerades i form av enkla skisser. Syftet med prototypen var att underlätta för diskussion samt kunna genomföra en utvärdering för att verifiera potentialen i konceptet. I den första modellen ignorerades den grafiska designen, fokus låg istället på placeringen av olika element och den allmänna sammansättningen. De delarna som inkluderades i prototypen var en övergripande grundstruktur för layout samt delsidorna registrering, inloggning, sök tider och boka tider. Denna första low-fidelity prototyp presenteras i avsnitt Utvärdering av low-fidelity prototyp Innan nästa iteration i designprocessen påbörjas och mer komplexa prototyper utvecklas är det viktigt att fastställa om de krav och behov som identifierats uppfylls av det koncept som framkommit. Low-fidelity prototypen presenterades för referensgruppen under ett möte. Generellt var responsen mycket positiv, det rådde dock funderingar om konceptet var möjligt att realisera utan att göra avkall på kraven för tillgänglighet. För att uppmärksamma eventuella användbarhetsbrister och undersöka att projektet var på rätt spår genomfördes en quick and dirty -utvärdering med hjälp av pappersprototypen. 8 försökspersoner med varierande datorvana deltog i testet, syftet var att testa den initiala förståelsen för konceptet samt arbetsflödet i prototypen.

35 Kapitel 5. Genomförandebeskrivning 28 Ingen av testdeltagarna uppgav att de tidigare varit i kontakt med bokningssystemet interbook. Testet utfördes informellt där det gränssnitt som vanligtvis ska visas på en datorskärm visades med hjälp av bilder från pappersprototypen. Ett scenario introducerades där deltagarna uppmanades att beskriva hur de skulle gå tillväga för att söka upp en ledig tid i en viss lokal och boka denna. Under utförandet uppmanades försökspersonerna att uttrycka sina tankar kring prototypen och beskriva hur de förväntade sig att olika element skulle fungera. Försökpersonernas agerande och synpunker antecknades, resultatet av utvärderingen finns att läsa i avsnitt Prototyputveckling, iteration 2 Efter att den första prototypen utvärderats initierades arbetet med att utveckla en interaktiv high-fidelity prototyp. Detta kapitel beskriver designprocessens andra iteration Identifiera behov och etablera krav De krav som etablerats vid projektets inledning kvarstod även i den andra iterationen av desingprocessen, ytterligare några krav tillkom dock efter utvärdering av low-fidelity prototypen. Vidare utvecklades ett kompletterande styrdokument, där tekniska detaljer specifierades mer ingående. Syftet med detta dokument var att det skulle fungera som en checklista och säkerställa att applikationen följer uppsatta standarder. Tanken var även att styrdokumentet ska vara en resurs vid framtida utveckling av liknande tjänster. Dokumentet sammanställdes från de riktlinijer och vedertagna normer som finns för offentliga webbplatser. Styrdokumentet finns att läsa i bilaga A Informationsdesign I syfte att utveckla en bättre informationsstruktur för systemet genomfördes en kortsorterings studie, metoden finns beskriven i avsnitt papperskort skapades där varje kort representerade en specifik del av systemet. Vid tillverkningen av kort låg det existerande systemet som grund tillsammans med kommande funktioner som framkom vid ett möte med referensgruppen. Två pilottester utfördes i syfte att undersöka om testet fungerade som planerat eller om något var oklart. Därefter testades åtta personer i åldrarna år. Varje test tog i snitt cirka 20 minuter att genomföra. Efter att deltagarna sorterat klart fick de även kommentera och motivera sina val. Testdeltagarna ombads också komma med förslag på lämpliga namn till de grupper de sorterat korten i. Resultatet av kortsorteringsstudien och den informationstruktur den genererade finns att läsa i avsnitt Utveckla designalternativ Med utgångspunt i den grundstruktur som framkom vid utvecklingen av low-fidelity prototypen påbörjades arbetet med att ta fram en grafisk design för bokningssystemets gränssnitt. Ikoner knappar och övriga gränisnittselement formades med hjälp av bildbehandlingsprogrammet Adobe Photoshop CS3. Grundtanken var att designen skulle upplevas som stilren och samtidigt modern, därför valdes också ett ljust färgschema. Ett antal

36 Kapitel 5. Genomförandebeskrivning 29 olika kombinationer av typsnitt, nyanser och layouter prövades och diskuterades med referensgruppen innan den slutligtiga designen kunde fastställas. I figur 5.2 presenteras ett av tidiga designförslagen Figur 5.2: Ett tidigt desingförslag. Jämsides med utvecklingen av den grafiska profilen började en interaktiv prototyp ta form. Här fokuserades på att implementera en webbapplikation som hanterar den funktionalitet som beskrevs i low-fidelity prototypen och den konceptuella modellen, och en webbapplikation

37 Kapitel 5. Genomförandebeskrivning 30 som följer webbstandarder och inte försummar kraven på tilllgänglighet. Denna process var mycket tidsödande High-fidelity prototyp För att konkretisera de koncept som etablerats byggdes en interaktiv high-fidelity prototyp. Syftet var att undersöka interaktionsmönster och få en känsla för navigering och flöde i systemet. High-fidelity prototypen kan ses som en realiserig av de ideer som formats under designprocessen. Den konceptuella modellen, systemets grundsstruktur och den grafiska profilen sammanslagna till ett enhetligt koncept. Prototypen konstruerade genom tekniker som är tilltänkta för att användas i en färdig produkt. Den slugiltiga prototypen och dess implementation beskrivs närmare i kapitel Utvärdering av high-fidelity prototyp För att utvärdera high-fidelity prototypen genomfördes ett användartest med 10 deltagare. Testerna utfördes på ett avskilt kontor hos uppdragsgivaren, en lugn och kontrollerad miljö. Ingen tid avsattes för att bekanta sig med systemet, ingen av försökspersonerna hade heller varit i kontakt med Interbook tidigare. Det antogs att gränssnittet var så intuitivt att användarna skulle kunna bruka det direkt utan några förkunskaper. Testpersonernas ålder varierade mellan Datorvanan bland deltagarna varierade från novis till erfaren datoranvändare. Ett antal realistiska uppgifter konstruerades som testpersonerna fick i uppdrag att genomföra: - Registrera en användare i systemet. - Använd den registrerade användaren för att logga in i systemet. - I vilka lokaler är det möjligt att spela fotboll? - I vilket distrikt ligger anläggningen Eddahallen? - Undersök om det finns det någon ledig tid för att spela golf på Rönnbäckens GP under lördag eftermiddag. - Boka en tennistid söndag förmiddag i en närliggande anläggning, jämför olika lokaler och välj det alternativ som passar bäst. - Vilka lokaler finns att tillgå i norra distriktet? Testpersonernas agerande dokumenterades med hjälp av ett skärminspelningsprogrammet ScreenToaster. Resultatet analyserades sedan i termer av effektivitet, antal fel, respons och

38 Kapitel 5. Genomförandebeskrivning 31 igenkänning. Efter att testpersonerna genomfört de uppgifter som delgivits fick de besvara ett antal frågor angående sin uppfattning om gränssnittet i allmänhet: - Var gränssnittet enkelt att förstå och använda? - Framträder knappar och länkar tydligt? - Var det något som var otydligt eller oklart? - Var feedbacken på dina handlingar tillfredställande?. - Inträffade det uppdateringar som du missade?. - Är det någon del av gränssnittet som skulle behöva förbättras? - Uppfattades färgschema och layout som tilltalande? - Vilket är ditt generella intryck av prototypens design? - Skulle du kunna tänka dig använda denna typ av system för tidsbokning?

39 Kapitel 6 Resultat I detta kapitel beskrivs de olika delresultat som framkom under genomförandet av projektet. Avsnitt 6.1 presenterar den slutgiltiga kravspecifikationen, avsnitt 6.2 presenterar den informationsstruktur som utvecklats, avsnitt 6.3 presenterar resultatet från utvecklingen av low-fidelity prototypen, avsnitt 6.4 presenterar den slutgiltiga prototypen samt avsnitt 6.5 presenterar uppfyllelsen av kravspecifikationen. 6.1 Kravspecifikation Här framställs den kravspecifikation som utarbetats, det är en förteckning över de krav som den slutgiltiga high-fidelityprototypen förväntas uppfylla. De krav som presenteras nedan baseras på det existerande systemet, uttryckta önskemål från beställaren samt vedertagna teorier. Kraven är uppdelade i två kategorier, funktionella och icke-funktionella, vad denna indelning innebär i praktiken klargjordes i avsnitt 3.1. Nödvändiga funktioner i det nuvarande systemet identifierades och placerades som funktionella krav i kravspecifikationen. Detta för att säkerställa att den resulterande prototypen besitter nödvändig funktionalitet. Icke-funktionella krav - Användargränssnittet ska vara intuitivt och användarvänligt. - Layout och utformning av gränssnittskomponenter ska vara konsekvent över de olika delarna av systemet. - Gränsnittet ska fungera oavsett upplösning och skärmstorlek. - Gränssnittet ska uppfattas som modernt och estetiskt tilltalande. - Systemet ska fungera felfritt i de vanligast förekommande webbläsarna. - Systemet ska ge informativ och tydlig feedback på utförda handlingar. - Systemet ska upplevas som responsivt. - Systemet ska ha en logisk informationsstruktur.

40 Kapitel 6. Resultat 33 - Systemet ska följa de standarder och riktlinjer som finns för webbplatser för offentlig service. Det ska vara tillgängligt för alla oavsett tekniska förutsättningar. Funktionella krav - Nya besökare av bokningssystemet ska kunna registrera en användare för att boka tider. - Registrerade användare ska kunna logga in i systemet med sina användaruppgifter. - I systemet ska det vara möjligt att söka efter bokningsbara lokaler. - Användare ska kunna söka efter lokaler med följande sökparametrar: anläggning, aktivitet, område, lokalstorlek samt lokaltyp. - Sökparametrarna ska vara indelade i enkla och avancerade, där avancerade sökalternativ inledningsvis ska vara dolda. - Systemet ska presentera resultaten av en sökning i en lista med sökträffar. - Om en sökning resulterar i många träffar ska resultatet delas upp på flera sidor som går att bläddra mellan. - Användare ska kunna välja ut någon av lokalerna bland sökträffarna för att se lokalens schema. - I ett lokalsschema ska det synas vilka tider som är bokningsbara och vilka som inte är tillgängliga för bokning. - Schemat för en lokal ska visas veckovis, användare ska själva kunna välja vilken vecka som visas. - Användaren ska genom att klicka på en ledig tid i ett schema kunna boka tiden. - Systemet ska enkelt ge tillång till instruktioner och hjälp som beskriver hur olika uppgifter ska utföras. 6.2 Informationsstruktur I det befintliga systemet saknas en tydlig struktur på innehåll och information. Upplägget kan närmast kallas för platt utan några kategoriseringar eller nivåindelningar. Med hjälp av den genomförda kortstudien framtogs en övergripande hierarkisk informationsstruktur för hela

41 Kapitel 6. Resultat 34 systemet. Strukturen beskriver ett upplägg för systemet och hur de olika delarna ska vara sammanlänkade. Resultatet från kortstudien ligger till grund för det menysystem som prototypen använder. Vid analys av resultatet för kortsorteringen utkristalliserades 8 grupperingar: - Mina sidor: Logga in, registrera användare, glömt lösenord?, se mina bokningar, bokningsförfrågan, se/ändra registrerade uppgifter - Information: Kontakt, hjälp - Evenemang: Evenemangsregister, evenemangsinformation - Boka anläggning: Sök tider, lokalinformation, sök träningstider, bokningsförfrågan - Enkäter: Enkäter - Föreningsliv: Föreningsregister, föreningsinformation, sök föreningsbidrag, aktivitetsstöd - Hamnplats: Hamnregister, hantera kö (hamnplats) 6.3 Low-fidelity prototyp Nedan presenteras den resulterande low-fidelity prototypens utformning. Detta tidiga koncept beskriver en tänkt struktur och systemets ingående komponenter. Prototypen är uppbyggd av sammanlagt 17 bilder vilket möjliggjorde utvärdering genom olika användarscenarion. Det som dock inte framgår av gränssnittsbilderna är hur själva interaktionerna fungerar och transformationen mellan olika tillstånd. I figur 6.1 visas en tänkt grundlayout för systemet. Tanken var att hitta en struktur som fungerar för alla webbsidor som omfattas av systemet. Detta för att skapa ett sammanhållet intryck med hög igenkänningsfaktor. Längst upp på varje delsida finns en horisontell meny placerad. Denna meny är systemets övergripande navigationselement, här finns länkar till alla interna sidor i bokningssystemet. Förutom menyn är även snabblänkar till undersidorna inloggning och registrera användare placerade i den övre delen av gränssnittet. En länkstig (breadcrum) är placerad under huvudmenyn och förtydligar för användaren var på webbplatsen denne befinner sig. Centralt i gränsnittet placeras all funktionalitet och de komponenter som är kopplade till den aktuella tjänsten. Varje webbsida avslutas med en sidfot där snabblänkar, viktig information och kontaktuppgifter lokaliserats.

42 Kapitel 6. Resultat 35 Figur 6.1: Grundstruktur i low-fidelity prototypen. I figur 6.2 visas en tänkt registreringssida där det är möjligt för nya besökare att skapa en egen användare i bokningssystemet. Den största förändringen i prototypen var beslutet att särskilja registreringen för de olika typerna av användare. Således finns ett formulär för företagsanvändare och ett för vanliga användare. Syftet med detta var att användare inte ska behöva konfronteras med ej relevant och distraherande information. Det går snabbt att växla mellan de två alternativen genom att använda flikarna som finns ovanför formuläret. Till höger om registreringsformulären placeras relevanta länkar. Det finns även ett hjälpavsnitt med förklarande text kring registrering och vad det innebär.

43 Kapitel 6. Resultat 36 Figur 6.2: Registreringssidan i low-fidelity prototypen. Inloggningssidan är uppbyggd på samma sätt som registreringssidan. För att logga in i bokningssystemet fyller användaren i sitt personnummer (alternativt organisationsnummer för företagsanvändare) samt det lösenord som numret kopplats till vid registreringen. Till höger om inloggningsformuläret placeras en lista med viktiga länkar som: registrera användare, hjälp och glömt lösenord. I figur 6.3 presenteras gränssnittet för att söka tider. Detta gränsnitt är i princip uppbyggt av tre olika vyer, en för att söka tider, en för att visa sökresultat samt en för att visa schema. I sökrutan kan antal sökparametrar anges och genom att klicka på de ovan belägna flikarna är det enkelt att växla mellan enkel och avancerad sökning. Efter det att användaren klickar på knappen sök så presenteras sökträffarna i en lista under sökrutan. Tanken är att användare enkelt ska kunna koppla sina sökningar till presenterat resultat. Genom att klicka på någon av sökträffarna visas schemat för den tillhörande lokalen. Detta innebär att det på ett snabbt sätt är möjligt att jämföra schemat för olika lokaler. Användare kan enkelt välja ut det bästa alternativet för bokning. Schemat visar vilka tider som är tillgängliga och genom att klicka på någon av de lediga tiderna i schemat så omdirigeras man till sidan för att boka tider.

44 Kapitel 6. Resultat 37 Figur 6.3: Söksidan i low-fidelity prototypen. Efter att tid för bokning valts kommer användaren till bokningsformuläret. Här får användaren fylla i ett antal nödvändiga upplysningar innan denne klickar på knappen boka för att bekräfta bokningen. Om uppgifterna godtas så visas ett kvitto upp där information relaterad till bokningen presenteras. En länk gör det möjligt att skriva ut kvittot som även skickas med e- post till den adress som användaren står registrerad på Resultat av utvärdering För att verifiera att low-fidelity prototypen uppfyllde förväntningarna genomfördes en utvärdering. Försökspersonernas agerande och kommentarer gav en fingervisning om vad prototypen saknade och hur detta skulle kunna åtgärdas. Av utvärderingen framkom att många av förslagen i den första designen kunde fungera. De tillfrågade uttryckte tilltro till konceptet. Samtliga personer tog den avsedda vägen genom bokningsprocessen. Det verkade dock inte tydligt framgå att det var möjligt att klicka på något av sökresultaten för att visa schemat för en viss lokal. Flera av försöksdeltagarna trevade sig fram innan de listade ut hur de skulle gå tillväga. Det var även en person som inte förstod att tiderna i lokalschemat var klickbara. Även relationen mellan det valda datumet och det schema som visas verkade oklar. Det generella intrycket var att de testpersoner som hade högre datorvana fann det enklare att förstå prototypen. De hade framförallt fördel av att förstå funktioner som knappar och rulllister. Inloggnings och registreringssidorna förvirrade inte någon av användarna nämnvärt.

45 Kapitel 6. Resultat 38 Insamlade kommentarer gav uppslag till flera förändringar i utformningen som kom att användas i utvecklingen av den slutgiltiga prototypen. 6.4 Slutgiltig prototyp Prototypen som presenteras bygger på de initiala kraven samt idéer som har framkommit under prototyputveckling och utvärderingar. Utöver specifika krav har även vedertagna tankar och principer kring användarvänlighet och grafiska gränssnitt haft inflytande på den slutgiltiga prototypen. Som fastslaget vid projektets inledning så ligger fokus på delarna sök tider och visa schema eftersom dessa två är de mest komplexa delarna samt att de är avgörande för att bokningsprocessen ska löpa problemfritt. Den resulterande prototypen förverkligades med hjälp av samma tekniker som ska tillämpas i den färdiga produkten. Tanken är att även om systemet har vissa brister så ska det vara möjligt att bygga vidare på och förfina prototypen till en slutgiltig produkt. Hur implementationen ser ut i detalj presenteras i avsnitt Layouten för systemets alla delar följer den grundmall som etablerades i den första low-fidelity prototypen Gränssnitt Utformningen av systemets gränssnitt var det centrala fokuset för projektet. Gränssnittet har iterativt utvecklats genom designprocessens olika faser. Sammantaget var målsättningen ett gränssnitt som är enkelt att använda, intuitivt samt estetiskt tilltalande. Det skulle vidare inrymma all funktionalitet som finns i det nuvarande systemet. Efter de inledande förstudierna och den teoretiska fördjupningen togs beslutet att etablera en ny konceptuell modell för systemet. Skissövningar och bollande av idéer ledde fram till vad som kom att bli den konceptuella modellen för prototypen. En avgörande skillnad från det befintliga systemet är att i prototypen så har bokningsprocessen komprimerats. Det nuvarande bokningsförfarandet är en linjär sekvens i flera steg (sök tider, lista sökresultat, visa schema), uppdelad på flera olika webbsidor. Dessa delmoment har i prototypen koncentrerats till en och samma sida. Detta möjliggörs genom användning av Ajax-teknik och förväntas underlätta och effektivisera bokningsprocessen. Eftersom delar av gränssnittet kan uppdateras asynkront så är det viktigt att tänka på att kommunicera dessa uppdateringar till användaren. I prototypen används diskreta animationer för att göra användaren uppmärksam på att innehåll laddas eller att gränssnittet förändras. Här har dock en avvägning gjorts då rörliga objekt och animationer kan distrahera användare. Ett viktigt estetiskt krav var att det nya gränssnittet skulle vara stilrent och ge ett modernt intryck. Färgschemat i prototypen är ljust och går i en grå skala där vissa kompletterande färger används för att förstärka viktiga element och komponenter. Till exempel så har de flesta klickbara ytorna som knappar eller länkar markerats med en avvikande färg. Detta för att understryka för användaren vad som är klickbart. Vidare har ytan för dessa klickbara element

46 Kapitel 6. Resultat 39 gjorts i en väl tilltagen storlek för att minska behovet av precision och underlätta interaktionen. All text är svart på en ljus bakgrund alternativt vit på mörk bakgrund. Detta för att skapa hög kontrast mellan bakgrund och innehåll, en nyckel till god läsbarhet. Typsnittet för all text är Tahoma i grundstorlek som motsvarar 12 pixlar. I stället för att ange exakta pixelvärden för textstorlek så är all text storleksbestämd i den flexibla måttenheten em. Detta gör det möjligt för användare att styra textstorlek genom att använda webbläsares inbyggda funktioner för att anpassa innehåll. I dagsläget råder det stor variation i skärmstorlek hos användare, vilket är viktigt att beakta vid design av gränssnitt för webbapplikationer. Därför valdes även en flexibel måttenhet för layouten så att bredden kan anpassas efter användarens önskemål. Det enda som storleksmässigt begränsar layouten är en lägsta skärmupplösning på 600x800 pixlar. Avgörande parametrar när det kommer till användbarhet och användarvänlighet är konsekvens och igenkänning. Med detta i åtanke utvecklades några globala grundkomponenter som återfinns i varje del av prototypen. Dessa benämns som: huvudmeny, länkstig, sidfot och flikar. Komponenterna beskrivs närmare nedan. Tanken är att en konsekvent utformning där menyer, länkar och viktiga funktioner alltid är placerade på samma plats och fungerar på samma sätt blir enklare att använda. Konsekvensen och förutsägbarheten gör att användaren slipper lägga extra tid på att fundera hur webbplatsen fungerar för varje ny sida denne kommer till. En annan fördel med dessa komponenter är att de även går att återanvända vid utveckling av nya tjänster. Nedan presenteras de viktigaste komponenterna som tillsammans bygger upp det grafiska gränssnitt som utgör den slutgiltiga prototypen. Bilderna kompletteras med beskrivande text där de mest grundläggande funktionerna beskrivs. Huvudmeny Huvudmenyn är bokningssystemets primära navigationselement och består av interna länkar som grupperade tillsammans bildar ett navigationsschema. Figur 6.4 visar huvudmenyns utseende. Strukturen på menyn är hierarkisk med två nivåer och baseras på det resultat som framkom vid kortsorteringsstudien. I den översta nivån finns länkar till de olika kategorier som fastslagits. I den undre nivån hittar man länkar, varje länk leder till en specifik sektion av applikationen. Till exempel kan en navigationsmeny bestå av länkar som har med information att göra. Den undre nivån aktiveras genom att användaren för muspekaren över en viss kategori i den övre nivån, en så kallad dropdown-meny. Denna typ av meny är ett vanligt förekommande element på webben och något som flesta internetanvändare har nyttjat tidigare. Länkarna indikerar att de är klickbara genom att ändra färg då muspekaren förs över dem.

47 Kapitel 6. Resultat 40 Menyn är placerad längst upp på varje webbsida som tillhör bokningssystemet. Placeringen är konsekvent och funktionen oförändrad över hela bokningssystemet. Figur 6.4: Huvudmenyn i high-fidelity prototypen. Länkstig Ett effektivt sätt att underlätta för användare att förstå var de befinner sig i informationsstrukturen är att förtydliga navigeringsnivåerna. Detta kan visuellt göras genom att introducera så kallade länkstigar (breadcrums). En länkstig är en textrad som beskriver den aktuella webbsidans läge i relation till högre nivåer i systemets hierarki. På varje del i prototypen finns en länkstig som visar användaren var denne befinner sig. Denna komponent är placerad längs upp på varje delsida precis under huvudmenyn. Tillsammans med länkstigen så finns också en ikon som förtydligar den aktuella tjänsten. Ikonen bidrar också till den grafiska designen. I figur 6.5 visas ikonerna för de olika delarna. Figur 6.5 Ikoner för high-fidelity prototypens olika delar. Sidfot Varje webbsida i prototypen avslutas med en sidfot som innehåller snabblänkar och viktig information. Sidfoten knyter samman gränsnittet och gör användare medveta om att de nått en sidas slut. Sidfotens utseende presenteras i figur 6.6.

48 Kapitel 6. Resultat 41 Figur 6.6: Sidfot i prototypen. Flikar För att presentera mycket information på en och samma webbsida används flikar till att separera olika områden av gränsytan. Flikar är ett välkänt gränssnittsparadigm och kan metaforiskt liknas vid att bläddra genom registret i en telefonkatalog. I prototypen tillämpas flikarna för att alternera mellan olika tillstånd av gränssnittet och inte för att navigera mellan systemets delar. Flikarna är placerade parallellt på en rad och till varje flik hör en panel som fungerar som behållare för det innehåll som är kopplat till fliken. Genom att klicka på en flik så visas den panel som är kopplad till fliken medan resterande paneler döljs. Den för tillfället valda fliken markeras genom att dess typsnitt ändrar färg samt att bakgrunden blir vit, se figur 6.7. Resultatet blir ett intryck av att den valda fliken ligger framför de andra flikarna, detta understryker vilken flik som är vald. Att fliken får samma bakgrundfärg som panelen medför också att den upplevda kopplingen mellan de två förstärks, precis som när man fysiskt bläddrar i ett register. De flikar som inte är valda har en grå skuggad bakgrund vilket innebär att de uppfattas ligga bakom den valda fliken. De är dock fortfarande fullt synliga och läsbara. De icke valda flikarna påminner användare om ytterligare alternativ. vascript används för att växla mellan de olika flikarna vilket medför korta responstider. Ett klick på en flik gör att den tillhörande panelen dyker upp omedelbart. Användare får en känsla av en fysisk koppling mellan musklicket och framträdandet av den valda panelen. På alla sidor finns en flik med rubriken hjälp, denna gör att en hjälpfunktion för den aktuella situationen presenteras på ett konsekvent sätt. Det är viktigt att grupperingarna av innehållet mellan panelerna är tydligt avgränsade för att användningen ska bli intuitiv.

49 Kapitel 6. Resultat 42 Figur 6.7: Flikarna i low-fidelity prototypen. Registrering För att användare av bokningssystemet ska få tillgång till funktionerna direktbokning och direktbetalning så krävs att de registrerar en användare i systemet. Det finns två olika typer av användare av systemet, företagsanvändare och vanliga användare. Eftersom dessa två har olika typer av uppgifter kopplade till sig så togs beslutet göra separata registreringsformulär för dessa två grupper. Flikar används för att särskilja vilken typ av användare som ska registreras. På detta sätt behöver inte användare konfronteras med att fylla i uppgifter som inte är relevanta eller distraheras av ej relevant information. Till exempel ska användare inte behöva fundera över organisationsnummer. Detta underlättar också för valideringen av inmatade uppgifter. I figur 6.8 presenteras registreringssidan som den ser ut i prototypen. Ifyllda uppgifter valideras av ett vascript vilket innebär att användarna får direkt feedback på uppgifterna och sidan behöver inte laddas om. De uppgifter som användare fyller i kontrolleras också på serversidan av säkerhetsskäl. Till höger om registreringsformuläret finns en lista med relevanta länkar.

50 Kapitel 6. Resultat 43 Figur 6.8: Registreringssidan i high-fidelity prototypen. Inloggning Registrerade användare kan använda sina uppgifter för att logga in i bokningssystemet. Inloggningssidans design presenteras i figur 6.9. Inloggade användare får ökade befogenheter så som direktbetalning med kontokort. Precis som vid registrering finns separata formulär för vanliga användare och företagsanvändare. Inloggningssidan består av två formulär ett för inloggning för privatpersoner och ett för inloggning av företagsanvändare. Dessa två särskiljs genom användning av flikkomponenten, vanlig inloggning är det förvalda alternativet. Användare fyller i användarnamn och lösenord vilka kontrolleras innan användaren ges tillgång till de funktioner som är kopplade till dennes profil. Till höger om inloggningsformuläret finns en lista

51 Kapitel 6. Resultat 44 med nyttiga snabblänkar relaterade till inloggning, Glömt lösenord, registrera användare och hjälp. Figur 6.9: Inloggningssida i high-fidelity prototypen. Sök tider Gränssnittet till tjänsten för att söka tider utgörs av tre komponenter: en ruta för att söka tider, en lista för att visa sökresultat samt en schemakomponent. I sökrutan kan ett antal sökparametrar anges och genom att klicka på de ovan belägna flikarna är det enkelt att växla mellan enkel och avancerad sökning, se figur Vid enkel sökning finns möjlighet att söka med anläggning och aktivitet som sökparametrar. I den avancerade sökningen finns fler alternativ här går det att söka på område, lokalstorlek samt göra en fri textsökning. Om inget val görs blir resultatet alla lokaler.

52 Kapitel 6. Resultat 45 Figur 6.10: Enkel och utökad sökning i high-fidelity prototypen. Efter att användaren klickar på knappen sök presenteras sökträffarna i en lista under sökrutan, se figur Sökresultatet hämtas asynkront från webbservern med hjälp av Ajax. En roterande animation visas under tiden resultatet laddas och indikerar att sökningen processas.

53 Kapitel 6. Resultat 46 Figur 6.11: Söksidan i high-fidelity prototypen. Genom att klicka på någon av sökträffarna visas schemat för den tillhörande lokalen, se figur Även här visar en roterande animation att schemat håller på att läsas in. Schemat ger information om vilka tider som är tillgängliga, vecka för vecka. Ovanför schemat finns en textruta, denna används för att välja vilket datum schemat ska visa. Genom att klicka på en ledig tid i schemat så omdirigeras användaren till sidan för att boka tider.

54 Kapitel 6. Resultat 47 Figur 6.12: Lokalschema i high-fidelity prototypen. Boka tid Boka tid är det sista steget i ett bokningsförfarande. Prisuppgifter och nödvändig information om användare och lokal hämtas. I figur 6.13 presenteras bokningssidan som den ser ut i den slutgiltiga prototypen.

55 Kapitel 6. Resultat 48 Om man är inloggad är vissa uppgifter på bokningssidan redan ifyllda till exempel adressuppgifter. Dessa fält som redan är ifyllda är inte möjliga att ändra här. Användaren uppmanas att fylla i några kompletterande uppgifter som är nödvändiga för bokningen. Om någon uppgift glöms så ger systemet ett meddelande om detta. Bokningen verkställs sedan genom att klicka på knappen Boka. När bokningen slutförts visas ett kvitto på bokningen. Kvittot går att skriva ut genom att klicka på knappen Skriv ut. Figur 6.13: Bokningssidan i high-fidelity prototypen Implementation Applikationen utvecklades som överenskommet med hjälp av ramverket ASP.NET 3.5. Grässnittskoden följer standarden XHTML transitional och har genomgått användbarhetstestning enligt W3C:s valideringsverktyg. Utvecklingen har i den mån det varit

56 Kapitel 6. Resultat 49 applicerbart följt W3C:s riktlinjer samt de rekommendationer som publicerats i Vervas dokument Vägledningen 24-timmarswebben [4]. Genom att följa standarder säkerställs att koden fungerar i kommande versioner av webbläsare, det underlättar även för de som besöker webbplatsen med hjälpverktyg. För all utveckling användes utvecklingsmiljön Visual Studio Då alla delsidor i prototypen följer samma grundmall för layout innebär detta att en mängd element är återkommande över hela applikationen. Konstruktionsmässigt är det idealiskt om dessa element bara behöver byggas upp en gång. Denna funktionalitet finns i ASP.Net och kallas för MasterPages. En MasterPage har använts för att bygga upp den grundmall med grafiska element som är gemensamma för hela webbplatsen. Detta innebär att sidhuvud, logotyp, meny och sidfot alla styrs från samma plats. Eventuella förändringar av grundstrukturen kan enkelt göras i grundmallen vilket påverkar hela webbapplikationen. I denna mall är sedan en så kallad Content Placeholder deklarerad, där placeras undersidorna Logga in, Registrera användare, Sök lediga tider samt Boka. Figur 6.14 visar en schematisk bild över den beskrivna strukturen. Figur 6.14 schematisk bild over webbapplikationens struktur. Då det var viktigt att applikationen skulle vara enkel att integrera och bygga har denna konstruerats på ett modulärt sätt. Två användarkontroller(user controls) har producerats, en schemakontroll och en kontroll för att lista sökresultat. Genom att konstruera dessa element som användarkontroller blir de enkla att återanvända på andra webbsidor, något som är önskvärt då de innehåller viktig funktionalitet. Huvudsyftet till detta designval var dock att

Så gör Vägledningen 24-timmarswebben dig till en bättre beställare. Funda Denizhan, Statskontoret Kommits 17 november, 2005

Så gör Vägledningen 24-timmarswebben dig till en bättre beställare. Funda Denizhan, Statskontoret Kommits 17 november, 2005 Så gör Vägledningen 24-timmarswebben dig till en bättre beställare Funda Denizhan, Statskontoret Kommits 17 november, 2005 Om IT och webb inte är en teknikfråga vad är det då? Är IT och webb en verksamhetsfråga?

Läs mer

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till?

1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? 1. (3p) Inom MDI-området framhåller man att människor lär sig via metaforer. Hur menar man att detta går till? Att lära sig via metaforer innebär att man drar nytta av kunskap som användaren redan har,

Läs mer

Undervisningen i ämnet webbutveckling ska ge eleverna förutsättningar att utveckla följande:

Undervisningen i ämnet webbutveckling ska ge eleverna förutsättningar att utveckla följande: WEBBUTVECKLING Ämnet webbutveckling behandlar de tekniker som används för att presentera och bearbeta information i webbläsaren samt utifrån dessa tekniker skapa och vidareutveckla statiska och dynamiska

Läs mer

Webbtillgänglighet. Webbtillgänglighet. World Wide Web Consortium. Web Accessibility Initiative, WAI WCAG 2.0 WCAG 1.0

Webbtillgänglighet. Webbtillgänglighet. World Wide Web Consortium. Web Accessibility Initiative, WAI WCAG 2.0 WCAG 1.0 Webbtillgänglighet Webbtillgänglighet Att göra webbinnehåll så att de är tillgängliga för alla oavsett vilka funktionsnedsättningar man har Att göra webbinnehåll tillgängligt oavsett vilken in- och utmatningsutrustning

Läs mer

Projektet. TNMK30 - Elektronisk publicering

Projektet. TNMK30 - Elektronisk publicering Projektet TNMK30 - Elektronisk publicering Gruppindelning projekt Valfria grupper ~4 per grupp TNM088 - Digitala media-grupperna är ok Projektgrupper 4 personer Jämna par Lika arbete för små grupper Anmäl

Läs mer

Vad påverkar designen?

Vad påverkar designen? Vad påverkar designen av ett gränssnitt? Vi ser arbetet med design av ett användargränssnitt som något som liknar en arkitekts arbete. En arkitekt ska i sin utformning av en ny byggnad se till att: Byggnaden

Läs mer

Utvärdering av prototyp: Frågedatabas av Mårten Cronander. Innehållsförteckning

Utvärdering av prototyp: Frågedatabas av Mårten Cronander. Innehållsförteckning 1 (6) Mottagare: Åsa Cajander Mårten Cronander Utvärdering av prototyp: Frågedatabas av Mårten Cronander Innehållsförteckning 1 Inledning 2 1.1 Ten usability heuristics 2 1.2 Severity ratings for usability

Läs mer

Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014

Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kursplan Gränssnittsdesign och Webbutveckling 1 Vårtermin 2014 Kurswebb: www.creativerooms.se/edu, välj Gränssnittsdesign eller Webbutveckling 1 Lärare: Aino-Maria Kumpulainen, aino-maria.kumpulainen@it-gymnasiet.se

Läs mer

GRÄNSSNITTSDESIGN. Ämnets syfte. Kurser i ämnet

GRÄNSSNITTSDESIGN. Ämnets syfte. Kurser i ämnet GRÄNSSNITTSDESIGN Ämnet gränssnittsdesign behandlar interaktionen mellan dator och människa med fokus på designaspekterna i utveckling av användbara, tillgängliga och tilltalande gränssnitt. Det innehåller

Läs mer

Webbteknik. Innehåll. Historisk återblick Teknisk beskrivning Märkspråk Standardisering Trender. En kort introduktion

Webbteknik. Innehåll. Historisk återblick Teknisk beskrivning Märkspråk Standardisering Trender. En kort introduktion Webbteknik En kort introduktion Innehåll Historisk återblick Teknisk beskrivning Märkspråk Standardisering Trender 1 Historisk återblick 89 CERN Tim Berners Lee Ett plattformsoberoende sätt att sprida

Läs mer

Projektuppgift.

Projektuppgift. Projekt Projektuppgift Designa och implementera ett webbaserat gränssnitt för att söka information i en befintlig databas. Webssidan ska vara komplett med navigering, överblick, sökning och strukturerad

Läs mer

Kommentarer till MDI tentamen 081003

Kommentarer till MDI tentamen 081003 Kommentarer till MDI tentamen 081003 1) I utvärderingssammanhang vill man ofta att de tilltänkta användarna ska finnas med. Nämn tre sätt att ta med användarna och jämför de olika sätten, likheter och

Läs mer

Vägledningen 24-timmarswebben. Magnus Burell, Verva Uppdaterad: 2007-09-11

Vägledningen 24-timmarswebben. Magnus Burell, Verva Uppdaterad: 2007-09-11 Vägledningen 24-timmarswebben Magnus Burell, Verva Uppdaterad: 2007-09-11 Vägledningen 24-timmarswebben Vad? Ca 150 riktlinjer för utveckling av webb och e-tjänster i offentlig sektor Senaste version 2006

Läs mer

Principer för interaktionsdesign

Principer för interaktionsdesign Designtrappan och GDK Principer för interaktionsdesign Mattias Arvola Institutionen för datavetenskap Designtrappan är framtagen av Dansk Design Center och vidareutvecklad av SVID. 2 Dagens föreläsning

Läs mer

Tillgänglighetskrav på teknik Dessa krav baseras på WCAG 2.0, http://www.w3.org/tr/wcag20/

Tillgänglighetskrav på teknik Dessa krav baseras på WCAG 2.0, http://www.w3.org/tr/wcag20/ Tillgänglighetskrav på teknik Dessa krav baseras på WCAG 2.0, http://www.w3.org/tr/wcag20/ UPPDRAGSGIVARE: Malmö stad VÅR REFERENS: Andreas Cederbom 08-555 770 64 andreas.cederbom@funkanu.se DATUM: 2009-04-03

Läs mer

Interaktionsdesign och användbarhet Personas. Paper prototyping. » Metod för representation av användaren. » Metod för konceptutveckling

Interaktionsdesign och användbarhet Personas. Paper prototyping. » Metod för representation av användaren. » Metod för konceptutveckling martin östlund 2008 Interaktionsdesign och användbarhet Personas» Metod för representation av användaren Paper prototyping» Metod för konceptutveckling Att designa för användbarhet» Forsknings- och tillämpningsområden»

Läs mer

Några exempel. Principer för design. Vilka problem medför den här designen? Vilken av följande placeringar av piltangenterna är bäst?

Några exempel. Principer för design. Vilka problem medför den här designen? Vilken av följande placeringar av piltangenterna är bäst? Några exempel Principer för design Hur många kan ställa in klockan på sin video utan manual? Hur ofta vrider man på fel platta på spisen eller glömmer vrida av den när man är klar? Hur ofta knuffar man

Läs mer

E12 "Evil is going on"

E12 Evil is going on E12 "Evil is going on" Föreläsning 12, HT2014 AJAX Kurs: 1dv403 Webbteknik I Johan Leitet E12 Evil is going on Dagens agenda AJAX XMLHttpRequest-objektet JSON Vad är AJAX? Asynchronous JavaScript and XML

Läs mer

behövs för enhetlighet, tala samma språk, så att användaren kan lära sig och använda det vidare.

behövs för enhetlighet, tala samma språk, så att användaren kan lära sig och använda det vidare. 1 2 3 Grafisk profil reglerar grunddragen i utseendet (logga, färger, typsnitt) en helhet skapas Vi ska känna igen oss, vi ska förstå vad som avsändaren vill kommunicera. Kan vara svårt att direkt applicera

Läs mer

TENTAMEN: Design och konstruktion av grafiska gränssnitt DAT215/TIG091

TENTAMEN: Design och konstruktion av grafiska gränssnitt DAT215/TIG091 TENTAMEN: Design och konstruktion av grafiska gränssnitt DAT215/TIG091 DAG: 5 mars, 2012 TID: 8.30 12.30 SAL: Hörsalsvägen Ansvarig: Olof Torgersson, tel. 772 54 06. Institutionen för tillämpad informationsteknologi.

Läs mer

Hållbar utveckling A, Ht. 2014

Hållbar utveckling A, Ht. 2014 Hållbar utveckling A, Ht. 2014 Kommunikation och projektledning för hållbar utveckling Projektplan Bakgrund Som ett stöd i ert projekt kommer ni att arbeta utifrån en projektplan i tre delar, varje ny

Läs mer

Utvärdering av gränssnitt särskilt befintliga. Hur utvecklar man användbara system? Användbarhet handlar om kvalitet

Utvärdering av gränssnitt särskilt befintliga. Hur utvecklar man användbara system? Användbarhet handlar om kvalitet Utvärdering av gränssnitt särskilt befintliga Hur utvecklar man användbara system? Lära sig organisationen Förstå användarens situation Förstå användarens språk Involvera användare i processen Utvärdera,

Läs mer

Projektanvisning. Webbsideprojekt. Författare: Johan Leitet Version: 2 Datum: 2012-10-09

Projektanvisning. Webbsideprojekt. Författare: Johan Leitet Version: 2 Datum: 2012-10-09 Projektanvisning Webbsideprojekt Författare: Johan Leitet Version: 2 Datum: 2012-10-09 Inledning Du har nu under ett antal laborationer i webbteknik fått relativt styrda uppgifter där du ensam fått lösa

Läs mer

Nya sundbyberg.se. Webbkoncept. v1.0, Sundbyberg där staden är som bäst

Nya sundbyberg.se. Webbkoncept. v1.0, Sundbyberg där staden är som bäst Nya sundbyberg.se Webbkoncept v1.0, 2012-04-04 Innehåll 1. Introduktion 2. Webbstrategi 3. Prioriteringar 4. Innehåll startsida 5. Tonalitet 6. Form 7. Interaktivitet och dialog 8. Sociala medier 9. Sökfunktion

Läs mer

Boken. Kap 2.1-2.4 Kap 11.3

Boken. Kap 2.1-2.4 Kap 11.3 Konceptuell design Boken Kap 2.1-2.4 Kap 11.3 Konceptuell design är helt grundläggande inom interaktionsdesign kan upplevas som abstrakt och svårt att förstå förstås bäst genom att man utforskar och upplever

Läs mer

Föreläsning 4, Användbarhet, prototyper

Föreläsning 4, Användbarhet, prototyper Föreläsning 4 Användbarhet och prototyper Kapitel 5-7 i Stone et al. Mer om användbarhet Psykologiska principer avseende: Förväntningar En uppgift i taget Struktur för förståelse Känna igen eller komma

Läs mer

SKOLFS. beslutade den XXX 2017.

SKOLFS. beslutade den XXX 2017. 1 (12) Skolverkets föreskrifter om ämnesplan för ämnet webbutveckling i gymnasieskolan, inom kommunal vuxenutbildning på gymnasial nivå och inom vidareutbildning i form av ett fjärde tekniskt år; beslutade

Läs mer

Det här dokumentet är till för att ge en översikt över ASP.NET MVC samt hur WCF Services används från.net applikationer.

Det här dokumentet är till för att ge en översikt över ASP.NET MVC samt hur WCF Services används från.net applikationer. Informationsinfrastruktur 7.5 hp Mattias Nordlindh Inledning Det här dokumentet är till för att ge en översikt över ASP.NET MVC samt hur WCF Services används från.net applikationer. Dokumentet består av

Läs mer

27 september Finansieringsguiden. Sammanställning och slutleverans Verksamt Värmland

27 september Finansieringsguiden. Sammanställning och slutleverans Verksamt Värmland 27 september 2018 Finansieringsguiden Sammanställning och slutleverans Verksamt Värmland Innehåll Projektbakgrund Sammanställning användartest 7/9 Sammanställning användartest 21/9 Slutgiltig design Kommentarer

Läs mer

Visualisering av samverkan

Visualisering av samverkan Visualisering av samverkan 18 december 2017 En viktig aspekt i samverkan är att inte bara ha koll på vilka andra aktörer du själv samverkar med, utan även veta om vilka aktörer du inte samverkar med, men

Läs mer

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning

campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning campus.borlänge Förstudie - Beslutsstöd för operativ tågtrafikstyrning En rapport från CATD-projektet, januari-2001 1 2 Förstudie Beslutsstöd för operativ tågtrafikstyrning Bakgrund Bland de grundläggande

Läs mer

Sju riktlinjer vid utveckling av hemsidor för mobil och desktop

Sju riktlinjer vid utveckling av hemsidor för mobil och desktop Sju riktlinjer vid utveckling av hemsidor för mobil och desktop Denna artikel går igenom hur du gör en hemsida användarvänlig till både vanliga desktopdatorer och mobilanvändare utan att behöva ha två

Läs mer

Chaos om IT-projekt..

Chaos om IT-projekt.. Användarcentrerad systemutveckling, gränssnitt och prototyper. Lämplig extraläsning Gulliksen, Göransson: Användarcentrerad systemdesign, Studentlitteratur, kapitel: 4, 5, 6, 7, 8, 9 (Bredvidläsning) Syfte

Läs mer

Varför ska man använda ett CMS? Vilka är fördelarna och är det alltid bra? Kattis Lodén 2010-03-18

Varför ska man använda ett CMS? Vilka är fördelarna och är det alltid bra? Kattis Lodén 2010-03-18 Varför ska man använda ett CMS? Vilka är fördelarna och är det alltid bra? Kattis Lodén 2010-03-18 Innehåll Inledning... 3 Fakta... 4 Innehåll... 4 Texthantering... 4 Granskning och versionshantering...

Läs mer

Tillgänglighetskrav på interaktion och design Dessa krav baseras på WCAG 2.0,

Tillgänglighetskrav på interaktion och design Dessa krav baseras på WCAG 2.0, Tillgänglighetskrav på interaktion och design Dessa krav baseras på WCAG 2.0, http://www.w3.org/tr/wcag20/ UPPDRAGSGIVARE: Malmö stad VÅR REFERENS: Andreas Cederbom 08-555 770 64 andreas.cederbom@funkanu.se

Läs mer

Elektronisk publicering TNMK30

Elektronisk publicering TNMK30 Elektronisk publicering TNMK30 Förra gången Usability & interaktionsdesign Projektintroduktion Bildbehandling. Byte av handledare Istället för Martin Johansson Annsofi Pettersson, annpe655@student.liu.se

Läs mer

Nämnden för elektronisk förvaltning

Nämnden för elektronisk förvaltning Nämnden för elektronisk förvaltning fastställer gemensamma standarder för myndigheters elektroniska kommunikation med varandra och med medborgare och företag Inrättades 1 januari 2004 13 ledamöter Statskontoret

Läs mer

Chaos om datorprojekt..

Chaos om datorprojekt.. Systemutveckling och användbarhet Användarcentrerad systemutveckling, gränssnitt och prototyper. Referens till avsnitt i kursboken Dix kapitel 6 Gulliksen, Göransson: Användarcentrerad systemdesign, kapitel:

Läs mer

Vad är design? Designmetodik. Varför en metodik? Samma (5!) huvudmoment. Härledning av form från specifikation. Användarcentrerad designmetodik

Vad är design? Designmetodik. Varför en metodik? Samma (5!) huvudmoment. Härledning av form från specifikation. Användarcentrerad designmetodik Designmetodik Vad är design? Föreläsning 11/9 2003 Preece: kap 1, 6.1-6.3 Härledning av form från specifikation Varför en metodik? Användarcentrerad designmetodik En metodik är tänkt att vara en hjälp

Läs mer

Konverteringsskola Del 3: Vad är användbarhet?

Konverteringsskola Del 3: Vad är användbarhet? Konverteringsskolans andra del behandlade vikten av att lära känna sina besökare. Vi kommer nu att arbeta vidare med besökarna i åtanke och fokusera på hur pass väl de kan använda webbplatsen. Om webbplatsen

Läs mer

Här ges en överblick över de delar som ingår i projektarbetet och beskriver kraven och bedömningskriterierna.

Här ges en överblick över de delar som ingår i projektarbetet och beskriver kraven och bedömningskriterierna. ACPU 2006 Experter Årets tema handlar om tekniska stöd åt experter. Vi vill att ni ska koncenterar er på människor som har en konkret och specifik kompetens inom ett avgränsat område. Denna kunskap kan

Läs mer

EAs krav vid ackreditering av flexibel omfattning

EAs krav vid ackreditering av flexibel omfattning SWEDAC DOC 12:1 2012-05-10 Utgåva 1 Inofficiell översättning av EA 2/15 M:2008 EAs krav vid ackreditering av flexibel omfattning Swedac, Styrelsen för ackreditering och teknisk kontroll, Box 878, 501 15

Läs mer

Manual HSB Webb brf 2004 03 23

Manual HSB Webb brf 2004 03 23 TERMINOLOGI I Polopoly används ett antal grundläggande begrepp för publicering och hantering av information, eller innehåll som det också benämns. Nedan följer en kort genomgång av denna grundläggande

Läs mer

Välkommen till Studiekanalen.se

Välkommen till Studiekanalen.se Välkommen till Studiekanalen.se Det här produktbladet beskriver besökarens (elevens) väg till utbildningen, hur de matchas mot rätt skola och utbildning. Det beskriver även hur utbildningsanordnaren kan

Läs mer

http://www.one-life.com/ http://www.bjork.com/ http://www.ro.me/ http://www.protest.eu/en#!/home

http://www.one-life.com/ http://www.bjork.com/ http://www.ro.me/ http://www.protest.eu/en#!/home http://www.one-life.com/ http://www.bjork.com/ http://www.ro.me/ http://www.protest.eu/en#!/home http://www.oakley.com/legionofoakley?cm_mmc=ads-_-apparel_goggles-_-prs_sigseries-_-appa Inspiration Koncept

Läs mer

Slutrapport: Design av Hemsida för PolyPlast+

Slutrapport: Design av Hemsida för PolyPlast+ Slutrapport: Design av Hemsida för PolyPlast+ Av: Behzad Charoose, Johan Magnuson, Mikael Onsjö och Sofie Persson Datum och Plats: 03-09-19 Göteborg, Chalmers/GU Anledning: Uppgiften ingick som en obligatorisk

Läs mer

INDIVIDUELL INLÄMNINGSUPPGIFT

INDIVIDUELL INLÄMNINGSUPPGIFT INDIVIDUELL INLÄMNINGSUPPGIFT Sofia Aronsson ANVÄNDBARHET OCH GRAFISK DESIGN MIS 13, Nackademin Yrkeshögskola Lärare: Ellinor Ihlström Inledning... 3! Analys... 3! Hitta... 3! Förstå... 5! Använda... 6!

Läs mer

Föreläsning 7: Kognition & perception

Föreläsning 7: Kognition & perception Föreläsning 7: Kognition & perception FSR: 3, 4 Att läsa: Kapitel 2-3 i Rogers et al.: Interaction design Översikt Att kunna om perception och kognition Konceptuella modeller Metaforer Paradigm, teorier,

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

WEBBTEKNIK. Ämnets syfte

WEBBTEKNIK. Ämnets syfte WEBBTEKNIK Webbteknik används för att utveckla och vidareutveckla statiska och dynamiska webbsidor, webbplatser, webbapplikationer eller andra applikationer där webbtekniker används, till exempel applikationer

Läs mer

Föreläsning 10: Gränssnitt och webbdesign

Föreläsning 10: Gränssnitt och webbdesign Föreläsning 10: Gränssnitt och webbdesign FSR: 6 Att läsa: Kapitel 6 i Rogers et al.: Interaction Design 1501006 Gränssnitt och webb 2 Översikt Gränssnitt historiskt Kännetecken olika gränssnitt Designutmaningar

Läs mer

Utvärdering. Övergripande (1) Med/utan användare. Övergripande (2) Fredag 1 oktober F1. Ann Lantz - Anna Swartling -

Utvärdering. Övergripande (1) Med/utan användare. Övergripande (2) Fredag 1 oktober F1. Ann Lantz - Anna Swartling - Utvärdering Fredag 1 oktober 13-15 F1 Ann Lantz - alz@nada.kth.se Anna Swartling - ast@kth.se Övergripande (1) Av den verkliga världen: Hur agerar man, vad händer? Hur används teknik? Beteendevetenskapliga

Läs mer

Kursplan Webbutveckling 2, 100p Läsår 2013-2014

Kursplan Webbutveckling 2, 100p Läsår 2013-2014 Kursplan Webbutveckling 2, 100p Läsår 2013-2014 Kurswebb: www.creativerooms.se/edu, välj Webbutveckling 2 Lärare: Aino-Maria Kumpulainen, aino-maria.kumpulainen@it-gymnasiet.se Hösttermin 2013 Vecka Tema

Läs mer

Klient/server. Översikt. Lektion 1: Webbtekniker från Microsoft. Webbteknik från Microsoft. Klient/server. Designmönster. Utrullning.

Klient/server. Översikt. Lektion 1: Webbtekniker från Microsoft. Webbteknik från Microsoft. Klient/server. Designmönster. Utrullning. Klient/server Översikt Webbteknik från Microsoft. Klient/server. Designmönster. Utrullning. Lektion 1: Webbtekniker från Microsoft Microsoft webbtekniker. ASP.NET. Klientsidan. Internet Information Server.

Läs mer

Idag. Prototyper och användbarhetsutvärdering. Vad prototyper prototypar. Olika sorters prototyper. Del 2 Prototyper Utvärdering Analytisk Empirisk

Idag. Prototyper och användbarhetsutvärdering. Vad prototyper prototypar. Olika sorters prototyper. Del 2 Prototyper Utvärdering Analytisk Empirisk Idag Prototyper och användbarhetsutvärdering Del 2 Prototyper Utvärdering Analytisk Empirisk Prototyper: en fråga om syfte och mottagare Vad prototyper prototypar Kommunikation Med sig själv för att driva

Läs mer

"Distributed Watchdog System"

Distributed Watchdog System Datavetenskap Emma Henriksson Ola Ekelund Oppositionsrapport på uppsatsen "Distributed Watchdog System" Oppositionsrapport, C-nivå 2005 1 Sammanfattande omdöme på exjobbet Projektet tycks ha varit av

Läs mer

Utveckling av Läsaren

Utveckling av Läsaren Utveckling av Läsaren Projektet steg för steg Läsaren har utvecklats sucessivt till att bli den anpassningsbara och situationsoberoende tjänst den är idag. Tabellen nedan visar hur utvecklingen har skett

Läs mer

Användarcentrerad Systemutveckling

Användarcentrerad Systemutveckling Användarcentrerad Systemutveckling Människadatorinteraktion (MDI) Inst. för informationsteknologi http://www.it.uu.se/edu/ course/homepage/hci/ ht10 Användarcentrerad systemutveckling, gränssnitt och prototyper.

Läs mer

Granskning av gränssnitt. Mattias Arvola

Granskning av gränssnitt. Mattias Arvola Granskning av gränssnitt Mattias Arvola 2 Att skapa interaktiva system Identifiera krav Utforma alternativ Ta fram prototyper (eller annan illustration av system) Utvärdera 3 Mål med utvärderingen Revidera,

Läs mer

Kursplanering Utveckling av webbapplikationer

Kursplanering Utveckling av webbapplikationer Kursplanering Utveckling av webbapplikationer Fakta Ämne Programmering Poäng 40 Yh-poäng Kurskod YSYS-WEB Klass Systemutvecklare.NET Syfte och koppling till yrkesrollen För att kunna arbeta som systemutvecklare

Läs mer

Att använda ELSA. Vad behövs för att använda ELSA?. Felrapportering och support

Att använda ELSA. Vad behövs för att använda ELSA?. Felrapportering och support KI Biobank Instruktion Användarmanual för ELSA Innehållsförteckning Allmänt... 1 Vad är ELSA?... 1 Vad behövs för att använda ELSA?... 2 Felrapportering och support... 2 Att använda ELSA... 2 Viktig information...

Läs mer

Prototypningsverktyg. A Human-Centered Design Process (ISO 9241-210, 2010) Mattias Arvola. @mattiasarvola Institutionen för datavetenskap

Prototypningsverktyg. A Human-Centered Design Process (ISO 9241-210, 2010) Mattias Arvola. @mattiasarvola Institutionen för datavetenskap A Human-Centered Design Process (ISO 9241-210, 2010) Prototypningsverktyg 1. Plan the humancentred process 2. Understand the context of use Mattias Arvola Meets the requirements 5. Evaluate against requirements

Läs mer

Rapport Projekt 1 Från material till webb

Rapport Projekt 1 Från material till webb IT-Universitetet Grafiska gränssnitt, 6 p Göteborg 2003-09-19 Rapport Projekt 1 Från material till webb Grupp 1: Vilhelm Bergman Hanna Friberg Björn Nord Ulrika Olsson Marlene Sjöberg Innehållsförteckning

Läs mer

Prototyping. Planera och genomföra webbproduktionsprojekt. Innehåll. Fördelarna med Pappersprototyper. Lofi-prototyp. Prototyping

Prototyping. Planera och genomföra webbproduktionsprojekt. Innehåll. Fördelarna med Pappersprototyper. Lofi-prototyp. Prototyping Innehåll Planera och genomföra webbproduktionsprojekt Stefan Berglund Prototyping Prototyping LoFi-prototyp HiFi-prototyp Användarcentrerad utveckling Användbarhet Specificering av krav Prototyping Kartläggning

Läs mer

Webbprogrammering TDDD52

Webbprogrammering TDDD52 Webbprogrammering TDDD52 ERD MySQL+PHP. Förra gången Idag Javascript jquery Progressive enhancement XML & AJAX Lab 4 och 5 Sammanfattning av kursen. Om databastabeller varje tabell ska beskriva en typ

Läs mer

Workshop II (1IK419) jp222px (Johnny Pesola) sid. 1 av 5

Workshop II (1IK419) jp222px (Johnny Pesola) sid. 1 av 5 Workshop II (1IK419) jp222px (Johnny Pesola) sid. 1 av 5 Steg 1.1 Sammanfattningen av diskussionen är att strukturen på en sida bör vara till största del i balans, symmetrisk, reguljär, förutsägbar och

Läs mer

Gränssnittsdesign. Design för användbarhet. Gränssnittsdesign - designheuristik

Gränssnittsdesign. Design för användbarhet. Gränssnittsdesign - designheuristik Gränssnittsdesign - designheuristik Vad påverkar designen? Vad ska man utgå från? Heuristik praktiska regler, tips och råd. Exempel (bra, dåliga) Gränssnittsdesign Vi ser arbetet med design av ett användargränssnitt

Läs mer

Guide för Innehållsleverantörer

Guide för Innehållsleverantörer Library of Labs Content Provider s Guide Guide för Innehållsleverantörer Inom LiLa ramverket är innehållsleverantörer ansvariga för att skapa experiment som "LiLa Learning Objects", att ladda upp dessa

Läs mer

Fö 4: Utvärdering. Gästföreläsning. Muddy-cards resultat. Varför och vad? Varför? Vad? Mot vad? (Krav) Hur? IMPACT

Fö 4: Utvärdering. Gästföreläsning. Muddy-cards resultat. Varför och vad? Varför? Vad? Mot vad? (Krav) Hur? IMPACT Varför? Vad? Mot vad? (Krav) Hur? IMPACT Fö 4: Utvärdering Gästföreläsning Computer Supported Collaborative Work flera användare. Live Help Systems Johan Åberg Vecka 10 Måndag 3/3 kl 10 i sal C3 Muddy-cards

Läs mer

Prototyping medium/high fidelity Användarupplevelse Interaktionsflöde och flow Användbarhetsutvärdering - Usability testing Tillgänglighet

Prototyping medium/high fidelity Användarupplevelse Interaktionsflöde och flow Användbarhetsutvärdering - Usability testing Tillgänglighet martin östlund 2008 Prototyping medium/high fidelity Användarupplevelse Interaktionsflöde och flow Användbarhetsutvärdering - Usability testing Tillgänglighet Medium fidelity prototyping/testning» Använda

Läs mer

WEBBKLUSTRING SLUTRAPPORT

WEBBKLUSTRING SLUTRAPPORT Arne Jönsson 2014-01-09 WEBBKLUSTRING SLUTRAPPORT 1. Inledning Inom projektet har vi utvecklat teknik som gör det möjligt att identifiera webbsidors innehåll och därefter klustra (gruppera) dem så att

Läs mer

Utveckling av ett grafiskt användargränssnitt

Utveckling av ett grafiskt användargränssnitt Datavetenskap Opponenter: Daniel Melani och Therese Axelsson Respondenter: Christoffer Karlsson och Jonas Östlund Utveckling av ett grafiskt användargränssnitt Oppositionsrapport, C-nivå 2010-06-08 1 Sammanfattat

Läs mer

Prototypning. Filmtajm. Prototypens roll: Evolutionär eller kasta bort. Dagens föreläsning. Detaljgrad. Detaljerad i vilket avseende?

Prototypning. Filmtajm. Prototypens roll: Evolutionär eller kasta bort. Dagens föreläsning. Detaljgrad. Detaljerad i vilket avseende? Filmtajm Prototypning Sketch-a-move http://vimeo.com/5125096 Mattias Arvola Institutionen för datavetenskap 2 Dagens föreläsning Typer av prototyper Upplösning Pappersprototyper Datorprototyper Verktyg

Läs mer

Digital inlämning av årsredovisningar

Digital inlämning av årsredovisningar Digital inlämning av årsredovisningar Tekniskt ramverk Version 1.0 1 Innehållsförteckning 1 Bakgrund och syfte... 3 2 Inledning... 3 3 Säker kommunikation... 4 4 Infrastruktur och aktörer... 4 5 Tjänstebeskrivningar...

Läs mer

Spel som interaktiva berättelser

Spel som interaktiva berättelser Spel som interaktiva berättelser Finns många typer av interaktivt berättande; ska titta närmare på spel eftersom de exemplifierar en rad aspekter av interaktivt berättande väldigt tydligt. Kan förstå spel

Läs mer

Version: 1.0.1 Datum: 2012-05-23. DynaMaster 5 Golf Övergripande manual

Version: 1.0.1 Datum: 2012-05-23. DynaMaster 5 Golf Övergripande manual Version: 1.0.1 Datum: 2012-05-23 DynaMaster 5 Golf Övergripande manual Innehållsförteckning 1 Inledning 3 1.1 Systemkrav 3 2 Logga in 4 3 Översikt 5 4 Verktygsfält och funktioner 6 4.1 Översikt gränssnitt

Läs mer

Projektuppgift- Mashup- Applikation

Projektuppgift- Mashup- Applikation Projektuppgift- Mashup- Applikation Som avslutning på denna kurs är det tänkt att Du ska bygga en egen mashup- applikation. Du ska bygga en komplett applikation som du utan tvekan skulle kunna vilja visa

Läs mer

Föreläsning 8, Design

Föreläsning 8, Design Föreläsning 8: Design och prototyper FSR: 1, 4, 5, 6 Att läsa: Kapitel 11 i Rogers et al.: Interaction Design Översikt Konceptuell design (Fysisk design) Uppgiftsallokering Prototyper Typer av prototyper

Läs mer

Bonus Rapport Kommersiell Design KTH

Bonus Rapport Kommersiell Design KTH Bonus Rapport Kommersiell Design KTH Johan Holmström & Lars Åkesson Introduktion Denna rapport beskriver projektet och delmomentet Kommersiell Design i kursen Interaktionsdesign 2 på KTH i Stockholm. Detta

Läs mer

Fö: Användbarhetsutvärdering

Fö: Användbarhetsutvärdering Fö: Användbarhetsutvärdering Samla in, analysera och presentera användbarhetsmått Heuristisk utvärdering Användbarhetstestning Upplägg Heuristisk utvärdering Heuristiker Utvärderare Gå igenom systemet

Läs mer

Användarutbildning i SiteVision

Användarutbildning i SiteVision Användarutbildning i SiteVision Innehållsförteckning 1 Komma igång med SiteVision 2 1.1 Starta SiteVision 2 1.2 Redigeringsläget i SiteVision 3 1.2.1 Verktygsfält 3 1.2.2 Modulväljare 4 1.2.3 Navigator

Läs mer

Upplägg. Fö: Användbarhetsutvärdering. Heuristisk utvärdering. 10 heuristiker (Nielsen) Hur många utvärderare?

Upplägg. Fö: Användbarhetsutvärdering. Heuristisk utvärdering. 10 heuristiker (Nielsen) Hur många utvärderare? Upplägg Fö: Användbarhetsutvärdering Heuristisk utvärdering Användbarhetstestning Samla in, analysera och presentera användbarhetsmått Heuristisk utvärdering Heuristiker Utvärderare Gå igenom systemet

Läs mer

Fältstudier. Torsdagen den 13 november K2. Ann Lantz Sinna Lindqvist

Fältstudier. Torsdagen den 13 november K2. Ann Lantz Sinna Lindqvist Fältstudier Torsdagen den 13 november 15-17 K2 Ann Lantz alz@nada.kth.se Sinna Lindqvist Sinna@nada.kth.se Fältstudier Fält Målgrupp Funktionshinder Design för alla 24-timmars myndigheten Web Accessibility

Läs mer

ÖrebroCupen. Institutionen för Ekonomi, Statistik och Informatik, ESI Informatik, Klientprogrammering för webbsystem, 5 poäng

ÖrebroCupen. Institutionen för Ekonomi, Statistik och Informatik, ESI Informatik, Klientprogrammering för webbsystem, 5 poäng Institutionen för Ekonomi, Statistik och Informatik, ESI Informatik, Klientprogrammering för webbsystem, 5 poäng Examinationsuppgift VT 2005 Ver 1.2 ÖrebroCupen Mathias Borg, mathias.borg@esi.oru.se Benny

Läs mer

Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg

Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg Datavetenskap Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg Oppositionsrapport, C-nivå 2006:12 1 Sammanfattat omdöme av examensarbetet Examensarbetet är intressant eftersom

Läs mer

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare Fibonacci / översättning från engelska IBSE Ett självreflekterande(självkritiskt) verktyg för lärare Riktlinjer för lärare Vad är det? Detta verktyg för självutvärdering sätter upp kriterier som gör det

Läs mer

Nya Medier. Gränssnitt, Interaktivitet och Digital kod

Nya Medier. Gränssnitt, Interaktivitet och Digital kod Nya Medier Gränssnitt, Interaktivitet och Digital kod Människa-Dator: Gränssnittet Tre lager tas upp i boken: Fysiska apparaten som möjliggör för användaren att styra/använda datorn Mjukvara som organiserar

Läs mer

Tillämpad programmering CASE 1: HTML. Ditt namn

Tillämpad programmering CASE 1: HTML. Ditt namn Tillämpad programmering CASE 1: HTML Ditt namn 18 [HTML] Din handledare vill se din skicklighet i att använda HTML-koden. Du ska utveckla en webbplats om ditt intresse, inriktning eller gymnasiearbete.

Läs mer

Laboration 3 i kursen Produktion för tryckta medier och webb: Webbplatsproduktion med ett publiceringssystem

Laboration 3 i kursen Produktion för tryckta medier och webb: Webbplatsproduktion med ett publiceringssystem Laboration 3 i kursen Produktion för tryckta medier och webb: Webbplatsproduktion med ett publiceringssystem Målsättning Att bygg upp en komplett webbplats i ett publiceringssystem. Platsen ska vara snygg,

Läs mer

Föreläsning 7 Mentala modeller, metaforer och emotionell interaktion. Kapitel 5 (3) i Rogers et al.

Föreläsning 7 Mentala modeller, metaforer och emotionell interaktion. Kapitel 5 (3) i Rogers et al. Föreläsning 7 Mentala modeller, metaforer och emotionell interaktion Kapitel 5 (3) i Rogers et al. Översikt Human Action Cycle Konceptuella modeller Metaforer ikoner Emotionell design Antropomorfism Agenter

Läs mer

Utvärdering. Exempel från lok. Utvärderingsmetoder. Metoder för att utvärdera användning av IT-system. Anders Jansson

Utvärdering. Exempel från lok. Utvärderingsmetoder. Metoder för att utvärdera användning av IT-system. Anders Jansson Utvärdering Metoder för att utvärdera användning av IT-system Anders Jansson Utvärderingsmetoder Direkt observation Indirekt observation Verbala protokoll Loggning av händelser/aktiviteter Intervjuer Enkätstudier

Läs mer

LÄRARHANDLEDNING TILLGÄNGLIGA WEBBSIDOR

LÄRARHANDLEDNING TILLGÄNGLIGA WEBBSIDOR UPPDRAGSGIVARE: IT-CENTER VÅR REFERENS: STEFAN JOHANSSON TEL.: 0708-23 10 64 E-POST: stefan.johansson@funkanu.se INNEHÅLL: LÄRARHANDLEDNING TILLGÄNGLIGA WEBBSIDOR _ Funka Nu AB Finnbodavägen 2, 131 31

Läs mer

De fem gyllene reglerna. Analys. Engagera dina användare. Känn dina användare. Lär av andra. Testa och korrigera designen

De fem gyllene reglerna. Analys. Engagera dina användare. Känn dina användare. Lär av andra. Testa och korrigera designen De fem gyllene reglerna Analys av användare och deras uppgifter Känn dina användare Engagera dina användare Testa och korrigera designen Lär av andra Samordna hela gränssnittet Känn dina användare Engagera

Läs mer

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Grupp 6 Ali Abid Kjell Nilsson Patrick Larsson Mälardalens högskola KN3060, Produktutveckling med

Läs mer

Process- och metodreflektion. Grupp 3; Ida Gustafsson, Mikael Karlsson, Jonas Lind, Hanne Sundin, Maria Törnkvist

Process- och metodreflektion. Grupp 3; Ida Gustafsson, Mikael Karlsson, Jonas Lind, Hanne Sundin, Maria Törnkvist Process- och metodreflektion Grupp 3; Ida Gustafsson, Mikael Karlsson, Jonas Lind, Hanne Sundin, Maria Törnkvist Planeringen Redan från början av projektet bestämde vi oss i gruppen för att planera utförande

Läs mer

Sovra i materialet. Vad är viktigt? Vad kan tas bort? Korta ner långa texter.

Sovra i materialet. Vad är viktigt? Vad kan tas bort? Korta ner långa texter. Sid 1 (6) Skriva för webb Att skriva för webben handlar om att skriva kort och enkelt för att fånga läsaren. Relevant innehåll Fundera över vad läsaren vill veta. Skriv för målgruppen. Sovra i materialet.

Läs mer

Kursplan Gränssnittsdesign, 100p Läsår

Kursplan Gränssnittsdesign, 100p Läsår Kursplan Gränssnittsdesign, 100p Läsår 2013-2014 Kurswebb: www.creativerooms.se/edu, välj Gränssnittsdesign Lärare: Aino-Maria Kumpulainen, aino-maria.kumpulainen@it-gymnasiet.se Hösttermin 2013 Vecka

Läs mer

Innehåll. Webbproduktion. Prototyputveckling. Arbetsgång (R)

Innehåll. Webbproduktion. Prototyputveckling. Arbetsgång (R) Innehåll Webbproduktion Produktion och publicering av större webbplatser Produktion Användbarhet/Användbarhetstest Publicering Underhåll Arbetsgång (R) 1) Utred mål och syfte (verksamhets- och målgruppsanalyser)

Läs mer

Komma igång med Qlikview

Komma igång med Qlikview Denna instruktion är till dig som är ny i Qlikview och snabbt vill komma igång med grundläggande funktioner. Innehåll 1 Introduktion... 2 1.1 Behörighet... 2 1.2 Webbläsare... 2 2 Installation av Qlikview

Läs mer

Föreläsning 9: Gränssnitt och webbdesign

Föreläsning 9: Gränssnitt och webbdesign Föreläsning 9: Gränssnitt och webbdesign FSR: (1), 4, 6 Att läsa: Kapitel 6 i Rogers et al.: Interaction Design 160429 Gränssnitt och webbdesign 2 Översikt Gränssnitt historiskt Kännetecken olika gränssnitt

Läs mer