Möte med Staffan 12/5 -2008

Medverkande: Staffan, Daniel & Peter

Idag pratade vi mest om rapporten och hur den ska struktureras och vad som ska finnas med i den. Nedan listas de saker som diskuterades:

• Vad hittade vi i litteraturen i förstudien?
• Hur påverkade förstudien vårt arbete?
• Varför valde vi Flash- och iPod touch-prototyper?
• Resultaten från testerna kanske borde vara i appendix istället för i rapporten. Istället ha en kort beskrivning i rapporten.
• Samma sak gäller för resultatet från designmetoderna. Vi bör kolla över detta i alla delar där det blir väldigt mycket text.
  
• Nu borde vi skriva mest på resultat och framåt så alla delar blir ungefär lika tunga och utifrån det strukturera rapporten.
• I diskussionen: saker som vi inte riktigt har belägg för.
• Beskriv skillnaden mellan vår prototyp och vårt koncept.
• Relaterat arbete: Knyter vi an till de sakerna i rapporten sen? Varför? Varför inte?
• Genomförandet: Vilket relaterat arbete har vi använt oss av?
• Designmetoder: Vilka metoder har vi använt och varför?
• Diskussion: Metoder - hur funkade det? Prototyper - hur funkade det?
• Slutsatser: Är det kopplat till syfte? Skriva att det vi gör är ETT sätt att göra det på.
  

Möte med Staffan 5/5 -2008

Medverkande: Staffan, Peter & Daniel

Idag pratade vi mycket om rapporten och slutsemenariet.

Rapporten:

Saker som kan vara med i diskussionen:

• Hur nöjda är vi med resultatet?
• Varför blev det inte som vi har tänkt oss?
• Tips till andra
• Kan man generalisera resultatet?
• Utvärdering om det behövs

Vi ska även kolla efter gamla exjobb för att se lite hur man kan göra strukturellt och innehållsmässigt.

Oppositionen:

• Konstruktiv kritik
• Både bra och dåliga saker, glöm inte de bra BRA
• Ställa dåliga saker som frågor istället / ge förslag på förbättring
• Diskussion angående hur det funkade i genomförandet.
• En dialog mellan båda parter. Ex: "Vad sade företaget" osv...

Designing the information bubble

When tapping and holding an element in the map an information bubble (tooltip) will appear. According to what kind of element is tapped the bubble will contain different information (see list below).

• Unit - Name, Number, Address
  
• Route - Unit, Name/Number, Number of stops, Time boundaries,
  
• Route Stop - Route Name/Number, Stop number, Recipient information, Address Time
  
• Trip - Unit, Trip Number, Time Boundaries
  
• Road Issue - Type, Classification (traffic: stocking, very tight, medium, flows, no data), Duration, Address
  
• Alarm - Type, Unit, Time, Address
  
• Geofence - Name, Unit(s), Type (inside/outside/border crossing)

To-do-lista i iteration 4

Oj, tiden går fort och vi går in i iteration numero 4. Vi har utifrån analysen i iteration 3 gjort en to-do-lista på vad som ska göras i protoypen. Vi kommer helt gå ifrån Flashprototypen och göra allt direkt i iPod touchen nu istället. Detta för att de saker vi testade i Flashen visade sig funka bra och inte behöver testas mer. Tidslinjen kommer förmodligen inte implmenteras alls i iPoden pga tidsbrist men zoomindikatorn kommer kanske implementeras delvis. Detta beror så klart på hur lång tid allt annat tar.

Listan av vad vi ska implmentera i nästa prototyp kommer här och är på det där utrikiska språket:

1. The map should automatically zoom and pan to the appropriate geographical boundaries when filtering.
2. Fix the issues with the uncertainty with the map/ list view states. Perhaps implement two designs, one with highlighted buttons and one with just one toggle button.
3. Show timeline in list (remove back button and title)
   
4. Show difference between routes and trips in the map.
5. Shortcut to show all information in the map (this must be designed first)
6. Information bubble when tap-and-holding on elements in the map (this must be designed first)
7. Implement zoom indicator, perhaps a static one.
8. Make the list interactive.
9. Tap-and-hold the timeline as a shortcut to jump to the current day.
10. Make the timeline stetch/pan when entering the system for pliancy indication.
11. Fix bug: Keyboard disappears.
12. Fix bug: Map pinch/pan problem.
    

Användartester iteration #3

Nu är vi klara med användartesterna i iteration #3. De gick väldigt bra och användarna hade bra förståelse för vårt system. Vissa saker behöver dock diskuteras och omdesignas för att göra det hela ännu bättre. Just nu sitter vi och skriver om resultat och analys av användartesterna.

Användarna har talat...

Idag gjorde vi användartest på två personer. Det blev mer än intressant och det ska bli ännu mer intressant att fortsätta nästa vecka med två till.

Ha en skön helg alla bloggläsare...

//D & P

Design- och användbarhetsprinciper

Vi har nu även diskuterat vad det är vi vill fokusera på för teoretiska design- och användbarhetsprinciper under testerna. De vi kommer fokusera på är:

Norman:

Feedback - Testa om systemet ger användaren ger tillräckligt med feedback
Constraints - Har systemet rätt constraints som gör att användaren inte kan göra fel?
Visibility - Visar systemet rätt information för användaren så att denne kan göra rätt val?
Consistency - Fungerar samma funktioner på samma sätt genom hela systemet?

Nielsen:

Visibility of system status - Förstår användaren vilken status systemet har?
Match between and the real world - Använder systemet ett, för användaren, naturligt språk?
User control and freedom - Kan användaren ångra interaktioner på ett smidigt sätt?
Help users recognize, dianose, and recover from errors - Om fel uppstår, visar systemet användaren hur dessa kan lösas?
Error Prevention - Gör systemet det svårt att göra fel?
Recognition rather than recall - Är systemet konsistent och visar knappar/reglage hur de fungerar?

Lauesen:

Subjective satisfaction - Gör systemet användaren nöjd (kollas under intervjun)
Understandability - Score of understanding (kollas under intervjun)