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

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

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

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

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

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

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

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

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

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp 2008 02 21 Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp PM, Seminarie SEM1, 3hp Kapitel 4 Seminariegrupp 7 Författare: Robin Hellsing Robin Jarl Handledare: Rolf Lövgren Sammanfattning

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

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

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

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

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

Skillnader mellan design för tryck och webbdesign

Skillnader mellan design för tryck och webbdesign Vad är en webbtext? Webbtexter är inte en specifik texttyp i likhet med protokoll, rapporter eller artiklar. Istället kan webbtexter vara precis vilken texttyp som helst, och det enda som förenar dem är

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

Med koppling till EmiWeb

Med koppling till EmiWeb Datavetenskap Opponent(er): Jonas Brolin Mikael Hedegren Respondent(er): David Jonsson Fredrik Larsson Webbaserad släktträdsmodul Med koppling till EmiWeb Oppositionsrapport, C/D-nivå 2005:xx 1 Sammanfattat

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

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

Användarutbildning i SiteVision

Användarutbildning i SiteVision Användarutbildning i SiteVision Senselogic AB Version 2.4 Innehållsförteckning 1 Komma igång med SiteVision...1 1.1 Starta SiteVision... 1 1.2 Redigeringsläget i SiteVision... 2 1.2.1 Verktygsfält...2

Läs mer

Måldriven, informationscentrerad webbdesign

Måldriven, informationscentrerad webbdesign Måldriven, informationscentrerad webbdesign Linus Forsell Digitala Distributionsformer vid Högskolan Väst, Trollhättan, Sverige linus.forsell@student.hv.se 1 Abstrakt I den här essän kommer måldriven och

Läs mer

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 7 i Rogers et al.: Interaction design

Föreläsning 2: Datainsamling - Observation, enkät, intervju. Att läsa: Kapitel 7 i Rogers et al.: Interaction design Föreläsning 2: Datainsamling - Observation, enkät, intervju Att läsa: Kapitel 7 i Rogers et al.: Interaction design Stjärnmodellen Analys Utvärdering Implementation Prototyper Krav Design 100326 Datainsamling

Läs mer

Decentraliserad administration av gästkonton vid Karlstads universitet

Decentraliserad administration av gästkonton vid Karlstads universitet Datavetenskap Opponent(er): Markus Fors Christian Grahn Respondent(er): Christian Ekström Per Rydberg Decentraliserad administration av gästkonton vid Karlstads universitet Oppositionsrapport, C/D-nivå

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

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

Användbar webbdesign.

Användbar webbdesign. Examensarbete Användbar webbdesign. Vilka faktorer som är avgörande för att en användare ska uppleva användbarhet på en webbplats. Författare: Ellinor Grönfors Handledare: Peter Adiels Examinator: Patrik

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

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

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

Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport

Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport Respondenter: Emma Henriksson och Ola Ekelund Opponenter: Eva Pettersson och Johan Westerdahl Sammanfattande omdöme

Läs mer

Umeå Stockholm Västerås Linköping Göteborg Malmö Tel vxl 090-15 49 00 www.vitec.se

Umeå Stockholm Västerås Linköping Göteborg Malmö Tel vxl 090-15 49 00 www.vitec.se Umeå Stockholm Västerås Linköping Göteborg Malmö Tel vxl 090-15 49 00 www.vitec.se Innehåll 1. INLEDNING... 3 2. VITEC PORTAL GENERELLT... 3 2.1 SORTERING AV KOPPLADE FUNKTIONER... 3 2.2 INFORMATION OM

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

Vägledningen 24-timmarswebben få fler att använda er webbplats. Magnus Burell, Verva

Vägledningen 24-timmarswebben få fler att använda er webbplats. Magnus Burell, Verva Vägledningen 24-timmarswebben få fler att använda er webbplats Magnus Burell, Verva Källa: Skrotbil: Håll Sverige rent, www.hsr.se Källa: The Design of Everyday Things, Donald Norman SAS Coffee Pot: www.ergonomidesign.se

Läs mer

Word-guide Introduktion

Word-guide Introduktion Word-guide Introduktion På det kognitionsvetenskapliga programmet kommer du läsa kurser inom flera olika vetenskapsområden och för varje vetenskapsområde finns ett speciellt sätt att utforma rapporter.

Läs mer

Undervisningen ska ge eleverna tillfälle att arbeta i projekt samt möjlighet att utveckla kunskaper om projektarbete och dess olika faser.

Undervisningen ska ge eleverna tillfälle att arbeta i projekt samt möjlighet att utveckla kunskaper om projektarbete och dess olika faser. 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

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

Kursplanering Objektorienterad programmering

Kursplanering Objektorienterad programmering Kursplanering Objektorienterad programmering Fakta Ämne Programmering Poäng 40 Yh-poäng Kurskod YSYS-OOP Klass Systemutvecklare.NET 2 Syfte och koppling till yrkesrollen Syftet är att få en stabil grund

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

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman Design och krav Henrik Artman >>Ett av skälen till att projektet inte höll tidplan och budget var [beställarens] höga ambitionsnivå. Dessutom skulle man gjort en stordel av arbetet självt, men en del av

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

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

Interaktionsdesign som profession. Föreläsning Del 2

Interaktionsdesign som profession. Föreläsning Del 2 Interaktionsdesign som profession Föreläsning Del 2 Vikten av att göra research Varför behöver vi göra research? En produkt blir aldrig bättre än den data som denna baseras på Men Vi har redan gjort en

Läs mer

Sluta gissa börja testa workshop alla pratar ux, 28 nov 2013

Sluta gissa börja testa workshop alla pratar ux, 28 nov 2013 Sluta gissa börja testa workshop alla pratar ux, 28 nov 2013 DAYTONA COMMUNICATION AB Riddargatan 17D, 114 57 Stockholm, Sweden Phone +46 8 579 397 50, Fax +46 8 579 397 55 www.daytona.se, info@daytona.se

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

Dags att skriva uppsats?

Dags att skriva uppsats? Dags att skriva uppsats? Grundkurs i Word 2010 SDM Studentdatorutbildning vid Malmö högskola Att skriva i Word! 1 Börja skriva/skapa ditt dokument- något att tänka på 1 Spara ditt dokument 1 Bra att veta

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

30 år av erfarenhet och branschexperts

30 år av erfarenhet och branschexperts 30 år av erfarenhet och branschexperts Integrerad Säkerhet Integrerad Säkerhet Varför överordnat system Användarvänlighet Kvalitet Trygghet Kostnadseffektivitet Varför ett överordnat system? Med stora

Läs mer

SMULTRON. Fredrik Li, Ester, Anders, Jessica, Philip. Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007

SMULTRON. Fredrik Li, Ester, Anders, Jessica, Philip. Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007 SMULTRON av Fredrik Li, Ester, Anders, Jessica, Philip Malmö Högskola Konst Kultur Kommunikation OOP5 - Mobile Applications IDK 05 - April/Maj 2007 - När man har turen att hitta en plats där man trivs

Läs mer

Utbildningsplan. Webb och multimedia. Dnr HS 2015/172 SGWOM. Programkod: Webb och multimedia Study Programme in Web and Multimedia

Utbildningsplan. Webb och multimedia. Dnr HS 2015/172 SGWOM. Programkod: Webb och multimedia Study Programme in Web and Multimedia Dnr HS 2015/172 Fakulteten för humaniora och samhällsvetenskap Utbildningsplan Webb och multimedia Programkod: SGWOM Programmets benämning: Högskolepoäng/ECTS: 120/180 Beslut om inrättande: Undervisningsspråk:

Läs mer

Projektplan Magasinet

Projektplan Magasinet Magasinet agnes.walmstedt@gmail.com juliask_y@hotmail.com ludvig93@live.se Bakgrund Projektets förutsättningar Detta projektarbete görs inom Medieteknik A på Södertörns högskola. Projektets syfte är att

Läs mer

PROJEKT: WEBB- OCH INFORMATIONSDESIGN Avvägningar och motiveringar vid gränssnittsdesign av webbsida för PolyPlast+

PROJEKT: WEBB- OCH INFORMATIONSDESIGN Avvägningar och motiveringar vid gränssnittsdesign av webbsida för PolyPlast+ PROJEKT: WEBB- OCH INFORMATIONSDESIGN Avvägningar och motiveringar vid gränssnittsdesign av webbsida för PolyPlast+ IT-universitetet i Göteborg Interaktionsdesign - Grafiska Gränssnitt 2003-09-17 Deltagare:

Läs mer

Läsa artiklar i artikeldatabaser med kompensatoriska hjälpmedel

Läsa artiklar i artikeldatabaser med kompensatoriska hjälpmedel Läsa artiklar i artikeldatabaser med kompensatoriska hjälpmedel en översikt Sammanfattning Idag finns det tillgång till en uppsjö vetenskapliga artiklar i form av e-text via artikeldatabaser, insamlade

Läs mer

Operatörer och användargränssnitt vid processtyrning

Operatörer och användargränssnitt vid processtyrning Operatörer och användargränssnitt vid processtyrning Normativa och beskrivande analyser Uppsala universitet @ 2003 Anders Jansson Sammanfattning kap. 1 Sociotekniska system Många olika grupper av användare

Läs mer

Metoder för datainsamling

Metoder för datainsamling Metoder för datainsamling Föreläsning 16/10-2002 Christina von Dorrien Kapitel 9.4, 12-13 Användarcentrerad designmetodik Analysera användare, användningssituation och uppgift Testa och utvärdera designförslag,

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

MANUAL FÖR JÄGAREFÖRBUNDETS KRETSAR

MANUAL FÖR JÄGAREFÖRBUNDETS KRETSAR MANUAL FÖR JÄGAREFÖRBUNDETS KRETSAR I följande dokument hittar ni information om hur ni administrerar er nya hemsida. Manualen går endast igenom grundläggande administration. För mer avancerad redigering

Läs mer

LEGA ONLINE. Bli lönsammare med Lega Online. www.legaonline.se. - Sveriges största internetbaserade bokningssystem.

LEGA ONLINE. Bli lönsammare med Lega Online. www.legaonline.se. - Sveriges största internetbaserade bokningssystem. LEGA ONLINE - Sveriges största internetbaserade bokningssystem Bli lönsammare med Lega Online Tänk om alla dina bokningar, kunder och artiklar fanns samlade i ett system, med fullständig statistik och

Läs mer

För smartare belysning

För smartare belysning För smartare belysning CityTouch LightPoint Lighting Asset Management. CityTouch LightPoint / Asset Management 3 Välkommen till framtidens smarta belysning Professionell hantering av offentlig belysning

Läs mer

Zimplit CMS Manual. Introduktion. Generell Information

Zimplit CMS Manual. Introduktion. Generell Information Zimplit CMS Manual Introduktion Detta dokument ger en överblick av Zimplit CMS (Content Management System) användargränssnitt och dess funktioner. (För mer information och hjälp-forum, se zimplit.org.)

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

Exempel på verklig kravspecifikation

Exempel på verklig kravspecifikation Exempel på verklig kravspecifikation Detta är ett exempel på en proffessionell kravspecifikation hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och

Läs mer

E-handel köksportalen Projektuppgift i kursen Användarcentrerad systemdesign, hösten 2003 The Usability Engineering Lifecycle av Deborah J.

E-handel köksportalen Projektuppgift i kursen Användarcentrerad systemdesign, hösten 2003 The Usability Engineering Lifecycle av Deborah J. E-handel köksportalen Projektuppgift i kursen Användarcentrerad systemdesign, hösten 2003 The Usability Engineering Lifecycle av Deborah J. Mayhew Rasha Alshammari, rasha.alshammari.2454@student.uu.se

Läs mer

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning

Läs mer

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08

JavaRats. Kravspecifikation. Version 1.1. Gustav Skoglund gussk258@student.liu.se. Marcus Widblom marwi026@student.liu.se. Senast ändrad: 13 / 05 / 08 JavaRats Kravspecifikation Version 1.1 Gustav Skoglund gussk258@student.liu.se Marcus Widblom marwi026@student.liu.se Senast ändrad: 13 / 05 / 08 Sammanfattning Kravspecifikationen för JavaRats har skrivit

Läs mer

Välkommen till kursen i Avancerad interaktionsdesign. Certec & EAT Institutionen för designvetenskaper

Välkommen till kursen i Avancerad interaktionsdesign. Certec & EAT Institutionen för designvetenskaper Välkommen till kursen i Avancerad interaktionsdesign Certec & EAT Institutionen för designvetenskaper Idag Översikt över kursen Kursmål och metoder Examinationskriterier Inspiration Praktisk information

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

Dialogue Technologies April 2005

Dialogue Technologies April 2005 Dialogue Technologies April 2005 En typisk självbetjäningstjänst för web ser ut enligt följande En inledande text för att användaren skall förstå tjänsten En aktuell lista med de 10 vanligast frågorna

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

Hypergene 14-1. Beskrivning av nya funktioner

Hypergene 14-1. Beskrivning av nya funktioner Hypergene 14-1 Beskrivning av nya funktioner Hypergene 14-1 Detta dokument sammanfattar de stora nyheterna i Hypergene 14-1, som blir allmänt tillgänglig för befintliga och nya kunder efter sommaren. Utöver

Läs mer

Utvecklingen av ett tidregistrerings- och faktureringssystem

Utvecklingen av ett tidregistrerings- och faktureringssystem Datavetenskap Opponenter: Anders Heimer & Jonas Seffel Respondenter: Daniel Jansson & Mikael Jansson Utvecklingen av ett tidregistrerings- och faktureringssystem Oppositionsrapport, C-nivå 2006:10 1 Sammanfattat

Läs mer

Kristian Almgren Artificiell Intelligens Linköpings Universitet 2011. Talstyrning

Kristian Almgren Artificiell Intelligens Linköpings Universitet 2011. Talstyrning Talstyrning Abstrakt Talstyrning är en teknik som gör det möjligt för oss människor att mer eller mindre verbalt kommunicera med en dator eller ett system. Det här är ett tillvägagångssätt inom AI och

Läs mer

Avancerade Webbteknologier

Avancerade Webbteknologier Projektledning, Business Knowledge Användbarhet & Layout Avancerade Webbteknologier Lkti Lektion 1 Kommunikation Tobias Landén tobias.landen@chas.se Avancerade webbteknologier del 1 (4 KY poäng) Syfte

Läs mer

Objektorientering. Grunderna i OO

Objektorientering. Grunderna i OO Objektorientering Grunderna i OO 1 Systemutveckling Tre systemnivåer: Verksamhet Informationssystem Datasystem Huvuduppgifterna i ett systemutvecklingsarbete: Verksamhetsanalys Informationsbehovsanalys

Läs mer

1. Polopoly och webbpublicering på SU

1. Polopoly och webbpublicering på SU 1. Polopoly och webbpublicering på SU Den här guiden är en introduktion till webbpubliceringssystemet Polopoly 9.16 för dig som ska arbeta som webbredaktör vid Stockholms universitet. Här går vi igenom

Läs mer

Hemsida till företaget Entusiastisk Coaching

Hemsida till företaget Entusiastisk Coaching Beteckning: Akademin för teknik och miljö Hemsida till företaget Entusiastisk Coaching Annelie Hammar Juni 2010 Examensarbete, 15 högskolepoäng, B Datavetenskap Internetteknologi Examinator: Anders Jackson

Läs mer

Bild 1: Översikt över faserna i projektarbetet

Bild 1: Översikt över faserna i projektarbetet Projektarbete kring system X Det här dokumentet beskriver uppgiften samt innehåller mallar för de rapporter som ska lämnas in. Bild 1 visar ordning och ungefärligt förhållande för tidsåtgång mellan de

Läs mer

Vad utmärker ett bra användargränssnitt?

Vad utmärker ett bra användargränssnitt? Vad utmärker ett bra användargränssnitt? Att kommunicera med användarna Feedback och Pliancy Excise kontra Flow GUI = Graphic User Interface GUI = Graphic User Interface GUIn, eller grafiska gränssnitt

Läs mer

Olika syften. TDDD60 användbarhetstest. När passar vilken typ? Med eller utan användare

Olika syften. TDDD60 användbarhetstest. När passar vilken typ? Med eller utan användare TDDD60 användbarhetstest Olika syften Olika typer av metoder Mått på användbarhet/kravuppfyllelse Olika syften Hitta användbarhetsproblem för att förbättra (mål: åtgärda problem, förbättra produkten) Formativ

Läs mer

Prototyping - faser, typer och potentiell problematik

Prototyping - faser, typer och potentiell problematik Prototyping - faser, typer och potentiell problematik Josefin Karlsson KTH Kungliga Tekniska Högskolan CSC Skolan för datavetenskap och kommunikation josefink@kth.se Maria Wikforss KTH Kungliga Tekniska

Läs mer

Klarspråk på nätet - Webbredaktörens skrivhandbok av Karin Guldbrand & Helena Englund Hjalmarsson

Klarspråk på nätet - Webbredaktörens skrivhandbok av Karin Guldbrand & Helena Englund Hjalmarsson Klarspråk på nätet - Webbredaktörens skrivhandbok av Karin Guldbrand & Helena Englund Hjalmarsson Klarspråk på nätet är en praktisk handbok för dig som någon gång skriver text för webb, surfplattor och

Läs mer

X-jobbs katalog. Medius R&D November 2011

X-jobbs katalog. Medius R&D November 2011 X-jobbs katalog Medius R&D November 2011 Contents ERP och Workflow System... 2 ipad och workflow system... 3 Nya möjligheter med HTML5... 4 Nya alternativ för affärsregelmotorer... 5 Process Intelligence

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

Webbpolicy för Klippans kommun

Webbpolicy för Klippans kommun Webbpolicy för Klippans kommun Framtagen av Kommunkansliet 2006-10-11 (ändring 2006-10-31) 1 Innehållsförteckning 1. Inledning... 2 2. Bakgrund... 2 3. Syfte och målgrupper... 3 4. Riktlinjer... 3 5. Ansvar...

Läs mer

Grundläggande funktioner i CMS ifrån Argonova Systems, 2011.

Grundläggande funktioner i CMS ifrån Argonova Systems, 2011. Grundläggande funktioner i CMS ifrån Argonova Systems, 2011. Syfte Detta dokument tar upp grundläggande funktioner i Argonova Systems CMS i syfte att förbereda och stödja användaren, vid sidan av och inför

Läs mer

Läs denna sekretesspolicy innan du använder AbbVies webbplatser, eller skickar personlig information till oss.

Läs denna sekretesspolicy innan du använder AbbVies webbplatser, eller skickar personlig information till oss. SEKRETESSPOLICY Ikraftträdandedag: 16.10.2014 Denna sekretesspolicy förklarar hur vi hanterar den personliga information du förser oss med på webbplatser som kontrolleras av AbbVie (inklusive dess dotterbolag

Läs mer

F15 Tillgänglighet/Accessibility Dagens agenda

F15 Tillgänglighet/Accessibility Dagens agenda F15 Tillgänglighet/Accessibility Dagens agenda Varför bry sig? Vad tjänar jag? WAI Funka Nu WCAG 1, 2 Hjälpmedel Prolog Varför bry sig? En stor del av Sveriges befolkning lider av funktionsnedsättningar

Läs mer

MANUAL FÖR JÄGAREFÖRBUNDETS KRETSAR

MANUAL FÖR JÄGAREFÖRBUNDETS KRETSAR MANUAL FÖR JÄGAREFÖRBUNDETS KRETSAR I följande dokument hittar ni information om hur ni administrerar er nya hemsida. Manualen går endast igenom grundläggande administration. För mer avancerad redigering

Läs mer

Prototyper och användartest

Prototyper och användartest Föreläsning i webbdesign Prototyper och användartest Rune Körnefors Medieteknik 1 2012 Rune Körnefors rune.kornefors@lnu.se Prototyp för en webbplats! Utkast eller enkel variant av webbplatsen" Syfte"

Läs mer

NU! NU! Bygg en webbplats NU! Bygg en webbplats. Swedish Language Edition published by Docendo Sverige AB. Bygg en webbplats.

NU! NU! Bygg en webbplats NU! Bygg en webbplats. Swedish Language Edition published by Docendo Sverige AB. Bygg en webbplats. web_omslag.qxp 2006-03-20 17:06 Sida 1 NU! CDn innehåller: Upptäck hur du: Använder "dra och släpp-metoden" för att lägga till text, bilder och andra objekt till en webbsida Skapar listrutor och dynamiska

Läs mer

Nyheterna i Visma Tendsign 4.0

Nyheterna i Visma Tendsign 4.0 Användarmanual Nyheterna i Visma Tendsign 4.0 Uppdaterad 2014-05-21 VISMA COMMERCE AB +46 13 47 47 500 tendsignsupport@visma.com www.tendsign.com Innehållsförteckning 1. Visma TendSign 4.0... 2 2. Grafiskt

Läs mer

Färger. Matthew Woehlke Översättare: Stefan Asserhäll

Färger. Matthew Woehlke Översättare: Stefan Asserhäll Matthew Woehlke Översättare: Stefan Asserhäll 2 Innehåll 1 Färger 4 1.1 Inledning........................................... 4 1.2 Hantering av scheman................................... 4 1.2.1 Importerar

Läs mer

2000-talet tillgänglighet på webben. Olle Olsson Swedish W3C Office Swedish Institute of Computer Science (SICS)

2000-talet tillgänglighet på webben. Olle Olsson Swedish W3C Office Swedish Institute of Computer Science (SICS) Ivan Herman 2000-talet tillgänglighet på webben Olle Olsson Swedish W3C Office Swedish Institute of Computer Science (SICS) EpiServer-dagen 11 mars 2009 SICS Swedish Institute of Computer

Läs mer

Grupparbete ACSD Projektplanering för ett Patientjournalsystem

Grupparbete ACSD Projektplanering för ett Patientjournalsystem Grupparbete ACSD Projektplanering för ett Patientjournalsystem Uppsala Universitet Institutionen för Informationsteknologi Användarcentrerad Systemdesign Grupp 8, ht03 Christian Rick, rick@bahnhof.se Frida

Läs mer

Användarutbildning i SiteVision

Användarutbildning i SiteVision Användarutbildning i SiteVision SiteVision AB Version 3 Innehållsförteckning 1 Komma igång med SiteVision...1 1.1 Starta SiteVision... 1 1.2 Redigeringsläget i SiteVision... 2 1.2.1 Verktygslisten...2

Läs mer

Systembeskrivning. Inklusive beskrivning av klienterna. Juni 2009. Författare: Ted Björling, Accedo Broadband AB

Systembeskrivning. Inklusive beskrivning av klienterna. Juni 2009. Författare: Ted Björling, Accedo Broadband AB Systembeskrivning Inklusive beskrivning av klienterna Juni 2009 Författare: Ted Björling, Accedo Broadband AB Alex Johnsson, Patrick Broman och Fredrik Eldh, Mobile Sorcery AB Innehållsförteckning 1 Introduktion...

Läs mer

Gör en egen webbplats

Gör en egen webbplats I det här avsnittet får du lära dig att bygga en egen minsida lägga till text och bilder skapa en egen design lägga till en bakgrund på webbplatsen I nästa nummer får du hjälp att bygga en större webbplats

Läs mer

Förbered och planera bildmanuset

Förbered och planera bildmanuset Del av Kapitel 4: Förbered och planera bildmanuset I detta kapitel kommer du att: Omvandla ditt manus till ett bildmanus Lägga till bildmanusguider Planera för de bilder som ska visas på skärmen Skriva

Läs mer

Introduktion till MySQL

Introduktion till MySQL Introduktion till MySQL Vad är MySQL? MySQL är ett programmerings- och frågespråk för databaser. Med programmeringsspråk menas att du kan skapa och administrera databaser med hjälp av MySQL, och med frågespråk

Läs mer

Manual till publiceringsverktyg

Manual till publiceringsverktyg Manual till publiceringsverktyg Allmänt När man har loggat in hamnar man direkt på översikten över hela webbplatsen. Överst hittar man en meny som alltid ligger med i verktyget. Denna meny innehåller översikten

Läs mer