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)

Möte med Martin 15/4 -2008

Medverkande: Martin, Peter och Daniel

Idag pratade vi en hel del om de prototyper vi har och användartesterna vid ska göra för att testa dem. Martin fick göra ett snabbt pilottest för att visa hur vi ska gå till väga samt för att se om det finns saker vi kan bättra på i testerna.

Testlogg - iPod

• Martin tryckte först på list-ikonen för att kunna se Lars alla resor och rutter
• Han tryckte sedan på "Map"- en tillbakaknapp, men den fungerar inte än i prototypen
  
• Ikonerna var lite för små för att det skulle vara enkelt för Martin att trycka på dom, trots att han inte har jättestora fingrar - detta är ordnat nu genom att ikonerna fått en osynlig bakgrund
• Istället för att skriva Yesterday skrev Martin in 2008-04-14, vilket ju är helt riktigt, men det fungerar inte i prototypen (vi vill att systemet skall ha ett så naturligt språk [natural language] som möjligt, vilket kan vara ett problem med datorvana användare, alltså borde båda fungera)
  

Testlogg - Flash

• Martin ville använda filtret eftersom han just använt det i iPoden, men det är inte tänkt att det skall användas i Flash-prototypen (Daniel borde helt enkelt stänga av det), han skrev in 06-18
  
• Vi upptäckte att allt inte var klart i Flash, vilket Daniel skall fixa
• Vi uppmanar Martin att pincha timelinen, vilket inte fungerade i iPoden, men fungerar i Flash
• Han hittar 06-18 efter hjälpen
• I uppgift 2 försöker han skriva in Show all - inget händer
• Han testar med Trucks - inget händer
• Behöver hjälp för att tänka på att zooma ut - frågan kanske behöver skrivas om?
• Utzoomningen går bra
  
• Ännu ett fel i Flash upptäcks, inget visas
  

Efteråt pratade vi om att det vore bra (konceptuellt) med shortcuts, många olika sätt att skriva in tid exempelvis 8 för 08:00 och 06-18 för att visa allt som hände idag mellan 06:00 och 18:00
Man kanske borde ha mer feedback för filtret, t.ex. highlighta de ord som fungerar som filterord. Det kanske även skulle vara bra med text completion för t.ex. y = year, yesterday.

Det var nog det hela...

Möte med Staffan 7/4 -2008

Medverkande: Staffan, Daniel och Peter

Diskussioner:

• Ska vi kategorisera testpersonerna utifrån erfarenhet av IT-system/kartsystem?
• Vilken sorts genomgång ska testpersonerna få innan de börjar testa systemet?
• Ska vi spela in events som händer med timestamps, funktioner, x/y-värden, etc.

User tests - the english slow version (Iteration #3)

Type of test:

Think-aloud with prototypes

Test Team:

The authors - One facilitator and one log keeper

Test Users:
2 of Kartenas employees (high IT knowledge, high system knowledge)
2 Novice users (low/medium IT knowledge, no system knowledge)

Test Tasks:
In Flash:

1. You want to look at what has happened during this work day. A work day in you company is between 06:00 to 18:00.
   
2. You need to see all trucks on the map at the same time.
   

In iPod touch:

1. You want to look at Lars Johanssons all trip and routes.
2. You think that the information on the map is cluttered so you want to see it as a list instead.
3. Now you need to see all the events that happened yesterday, but you want to see them in the map.
4. You want to see all units, including the ones that are currently outside the current map boundaries.
   

Measurements:
How to carry out the measurement (Write about this in Theory)
Problem Counts (Lauesen s.27)

What to measure
+ Problem counts.

+ Score for understanding

- Not task time (Could be measured by event recording?) Since we are developing a new system we have no experienced users (Lauesen s.25)

- NotKeystroke counts

- Not Opinion poll

- Not Guideline adherence

The requirement or target
+ Problem counts - 3 of 4 should be able to carry out the test without critical problems. At most 7 medium problems.

Användartester - snabb skiss

Vi har börjat diskutera hur vi ska lägga upp användartesterna och så... Bilden nedan visar våra tankar och är galet enkel att förstå (jämför med raketforskning).

Möte med Staffan 31/3 -2008

Medverkande: Peter, Daniel och Staffan.

Saker som diskuterades:

• Konceptet är det viktigaste resultatet
• Beskriv prototyperna väl i rapporten
• Begränsa inte konceptet utifrån prototypobegränsningar
• Skriv inte detaljer om koden
• Vilken arbetsmetod har vi gällande programmeringen?
• Skriva att vissa förutsättningar har ändrats pga SDKn
• Motivera väl varför vi gör vissa saker i Flash och vissa direkt i iPod touch
• Litteratur om pekskärmar. När började det användas?
• Litteratur om datum/tidsvisualisering
  
• Skriv om våra influenser!
• I bakgrunden och teorin ska det stå om hur det var innan vi började
• I genomförandet ska vi utgå från vad som finns idag och sen utifrån det så gjorde vi som vi gjorde
• Diskussionen: Är vi nöjda med resultatet? Är vi nöjda med sättet att arbeta? Hur påverkade detta exjobbet? Kan man generalisera resultatet (forskningslikt)? Framtida arbete: 1.Detta skulle andra exjobbare kunna utföra 2. Detta skulle Kartena kunna göra vid en eventuell implementation
• Om utvärderingen i iteration #3: HUR ska vi göra användartesterna (t ex hur mycket vi ska berätta för användarna om hur systemet fungerar innan de börjar testa)? VAD vill vi få ut? VARFÖR gör vi utvärderingen (vad är det för input vi vill ha av användarna? förslag på lösningar, testa om någonting fungerar, sätta olika designförslag mot varandra?)?

Exjobbsredovisningar

Igår var vi på exjobbsredovisningar och fick då lite tankar i våra små huvuden.

Designprocessen:
Kombinera test med intervju.

Rapporten:
Skriva någonting om medierande objekt.
Skriva om svårigheten med just det vi gör.
Skriva om Kartenas produkter som vi utgår ifrån och berätta vad vi lägger till/tar bort.
Hitta information om design för små skärmar.
Bakgrund om informationsvisualisering.
Spela historik? Inte nödvändigtvis intressant bara för att man kan.

Presentationen:
Redovisningsspråk.
Koppla iPod touch till extern skärm?

Prioriteringslista Iteration #3

Flash:

1. Timeline - Visualisering och Interaktioner


iPod touch:

1. Pan Map
2. Zoom Map
3. Show Units
4. Show Items
5. Show Routes

Designval Iteration #3

Olika designval adresserades idag. De listas nedan på det där engelska språket.


TIMELINE:

Snapping Points

• When panning the timeline slow it should snap to distinct positions.
• When panning fast ("throw" the timeline) it should snap first when it slows down.
• How many different steps should it be? In the current design this number is 3, but other designs should be tested.
• Different suggestions of the visualizations and interactions of the timeline should be designed and tested.

Scroll/Pan speed

• Should follow the iPod touch guidelines.

Zoom Out

• Should follow the iPod touch guidelines (Two-finger single tap).

Boundary details

• Down to hours?
• Should be tested on users

Filtering (show exact information?)

• Must be exactly the information inside the time boundaries.
• Perhaps visualize a route/trip start and end points distinctly (e.g. shapes, colors).

"Today" Function

• What kind of time boundaries do the "today" functionality have?
• Different designs to be tested.
• Should the most detailed zoom level depend on the information load? Meaning that if there is a lot of information in the time boundaries the system will have a less detailed zoom level.

OTHER:

Back Button

• List and Map view: No back button
• Detailed view: Back button to the previous section (map or list view)

Same information in Map and List view?

• YES
  

How should the Selector Popup work?

• NEXT: Next element in the list view
• PREVIOUS: Previous element in the list view

Element, Function, Sort:

Unit >| , Next Unit , Alphanumerical
Route >| , Next Route , Time
Trip >| , Next Trip , Time
Alarm >| , Next Alarms , Time
Geofence >| , Next Geofence , Creation Time
Route Stop >| , Next Stop in Route , Time


Information in Detailed view must be discussed as well....

Möte med Martin 20/3 2008

Medverkande: Peter, Daniel, Martin och Samuel (Som jobbar tillsammans med Martin på Astando)


De saker som diskuterades var följande:

- Vad är det egentligen föraren ska få se? Kan det vara bra att föraren får se andra bilar (ta en fika med någon, inte känna att endast admin får se "allt")?

- Vi borde tala med slutanvändaren, den verkliga användaren av vårt system för att undersöka de faktiska behoven på hur systemet ska utvecklas.

- Vi fick tips av Samuel om att det finns några skottar som forskar på accelerometers och annat. Han skulle skicka över en länk till detta.

- Vad ska det vara för delfault-läge på timelinen? Detta kan också vara bra att undersöka med en förmodad användare.

Möte med Staffan 17/3 -2008

Medverkande: Staffan, Daniel och Peter

- Vi borde sätta upp prioriteringslistor i de olika iterationerna vi gör. Så vi vet vad som är viktigast att bygga som prototyp och vad som är viktigt att testa. Är det viktigaste i denna iteration gränssnitt, det tekniska systemet, eller vad? Bra att ställa sådana frågor ofta.

- Slutsats: Prototypen - Innehåller inte allt. Koncept - Innehåller alla våra tankar om hur det ska vara.

- Det viktigaste är helt klart KONCEPTET, inget annat.

- Staffan undrade om man i systemet kan se om man är före eller efter i tidsplaneringen. Samt också kanske kunna jämföra någons trip med en annan som körde samma en annan gång.

- Vad ska vara Future Work och vad ska vi ha med i vår prototyp? Diskutera gärna det vi inte vill ha med i systemet och förklara om det skulle vara med i en framtida produkt.

- Uppdelning i de olika iterationerna (ungefär som det redan är i rapporten):
Prio-lista
Varför gör vi det vi gör i denna iteration?
Hur gör vi det?
Resultat

Flash-prototyp: Zooma tid

http://thesis.remotable.se/iPod-touch.html

Håll inne ALT för att få upp en "fingertopp" till. Håll sedan ner den vänstra musknappen för att pincha ut och in.

Varje ny "pinchning" måste påbörjas med att musknappen trycks ner.

Håll nere SHIFT och klicka på tidsaxeln för att zooma in (zooma ut med knapptryckning är inte implementerat än).

Möte med Martin 6/3 -2008

Medverkande: Martin, Peter och Daniel (Erik var också med en del av mötet)

Idag har vi kollat lite på historikfunktioner även i ett annat projekt som Kartena är delaktiga i. Vissa saker som kom fram under dessa diskussioner är intressanta för oss att fundera på för vår prototyp också. Nedan listas lite tankar.

• Man borde kanske ha någon form av snap på tidslinjen, t ex ett år. Så den inte är helt steglös.
• Panoreringen i tidslinjen skulle kunna göra på olika sätt, eller i alla fall med olika interaktionssätt. Martin tycker att man kan "kasta" tidslinjen för att panonera snabbare. Ett snabbt kast man resultera en förflyttning i flera år på samma gång.
• Kan man zooma ut tidslinjen på något snabbare sätt än pinch?
• Ska man ha någon form av tillbakaknapp? Hoppa tillbaka till den vyn jag var på tidigare.
• Man kanske ska ha en ganska abstrakt nivå på tid, inte så pass detaljerad att man kan välja på minuter.
• Snappa på väl valdra punkter, t ex på dagar, månader, år.
• Kinetisk acceleration på scrolling
• Kanske är vettigt att bara visa det som finns i timeline, att det är den exaktheten som krävs
• Man kanske vill visa på vilken adress en enhet befinner sig just nu i textform, i informationen om enheten.
• Skip/back är nästa händelse/arbetspass för alla enheter som är markerade
• På något sätt måste man i tidslinjen kunna välja att ha IDAG som start eller slutpunkt på vad man ser rent tidsmässigt. Förslag: Hålla fingret en liten stund på start-datumet för att sätta det till idag. Samma för slutdatum.
  

Prototypdiskussion

Idag har vi fortsatt med prototypandet och även skissat lite på ikoner som kan användas till kartan (mest för skoj skull). Vi har dessutom haft en design-diskussion med Erik O som arbetar som konsult på Kartena och han hade en del förslag och tankar.

• Man kan ha flera timelines, t.ex. om man klickar på ett år så kommer det upp en ny tidslinje för dess månader, månad till dag etc.
  
• När man arbetar med tidslinjen så läggs den i mitten och förstoras upp så att man kan koncentrera sig på att välja tid.
  
• Tidslinjen borde finnas kvar så att man ser i vilken tidsrymd man är i för tillfället, men mindre så att den inte stör.
  

En lastbilsikon.

En karta med lastbilar, stopp och trafikproblem.

Historik

Vidare diskussioner om hur man ska visa historiken...

Vi kom på en idé att låta tidsaxeln bete sig mycket mer som själv kartan gör, eller i alla fall interaktionen med den. Alltså zooma in och ut, samt panna sig till den tidpunkt man vill visualisera. På så sätt kan man snabbare ta sig mellan olika tider.



Vi har även talat om hur man ska kunna sortera det som finns på kartan om man går in i list-läget istället för kart-läget. En fundering är att ha tre olika knappval i den undre menyn, ungefär som i iPoddens musiklista, där man kan välja att sortera efter t ex album, genre och spår. I vårt fall kan man då sortera efter Unit, Trip och Route.

Visualisering

Nu har visualiseringsdiskussionerna dragit igång på allvar. De saker vi diskuterat och skissat på idag är följande:

- Vi funderar på att se allting som en tidslinje för att inte behöva ett speciellt läge för historikfunktionaliteten. Då kan man alltså alltid när man är i kartläget filtrera mellan vilka tidpunkter/datum som man vill visa information från. Som ses i bilden finns det två reglage på tidslinjen (som ligger högst upp) som då symboliserar filtreringens start och slutpunkt. I fallet på bilden visas information från 2 dagar bak i tiden till 1 dag fram i tiden. I detta exempel visas två redan körda resor (trips) och en framtida rutt (route). På detta sätt kan man se både körda tripper och framtida rutter. Man ska också kunna visa en tänkt rutt samtidigt som man ser den faktiska trippen. Alltså den tänkta körvägen (route) och den faktiska körvägen (trip), för att se om dessa stämmer överens.
Man ska även kunna ändra tidslinjens format. Nu är mellanrummet mellan två streck 1 dag, men detta skulle kunna vara 3 dagar, 1 vecka, 2 veckor, 1 månad, 6 månad, 1 år, eller något sådant.


- Det måste finnas något sätt att ställa in avancerade filtreringsval för historiken, t ex genom en "setup"-knapp jämte tidslinjen. Här ska man kunna ställa in om man t ex vill se; historiska rutter, geofence, alarms.

- Man ska kunna skifta mellan kartläge och listläge. Det ska alltid finnas enkel navigering mellan att gå från läget då man ser t ex en rutt eller massa items (t ex alla företagets chaufförer) på en karta, samt att få samma information i en överskådlig lista. Detta syns i bilden längst ner till vänster och längst ner till höger.

-Man måste kunna gå in i ett "administrator"-läge där man t ex kan; skapa nya rutter, ändra rutter, skapa geofence, ändra geofence. Den ligger i bilden som en knapp i den nedre menyn (Admin mode).

- Som syns i bilden utgår vi ifrån en unit (i detta fall en förare och dess lastbil) och filtrerar vyn efter denna. Man kan även filtera utifrån fler units på en och samma gång. Då trycker man på knappen som finns i den undre menyn (Unit(s): Björn Johansson) och får då upp en lista på alla Units som finns till förfogande. Man kan utifrån denna lista välja vilka units man vill se på kartan, t ex med hjälp av checkboxes. Det måste också finnas knappar som väljer alla, respektive inga units på en och samma gång. För att kunna skrolla snabbt genom listan kan man använda en lista med bokstäver i högersidan av listan (som i musikspelaren i iPod touch). Då trycker man helt enkelt på bokstaven B för att hoppa till de units som börjar på denna bokstav.

Vem är användaren egentligen?

Idag har vi haft diskussioner om vem som egentligen skulle kunna tänkas använda den produkt vi håller på att utveckla. Det är inte så att vi inte har haft uppe denna diskussion tidigare men vid tidig skissning kom blev det tydligt att vi borde ha en så snäv målgrupp som möjligt.
Vi har tittat på en fiktiv kund som arbetar med transporter av varor och på vilket sätt en kartapplikation i iPod touch kan gynna dem och deras organisation.
De två olika sorters användare (aktörer) vi ser hos en kund som denna är: Chauffören och Övervakaren. Alltså den som kör lastbilen och den person som ser till att alla transporter inom företaget fungerar som de ska. Dessa två aktörer har olika behov och kommer således att få olika tillgång till systemets olika delar.
För att strukturera dessa delar och visa vilken åtkomst aktörerna har används ett Use Case-diagram. I bilden nedan ses de två aktörerna (representerade av streckgubbar) och vilka olika sorters use-case (ellipser) de berörs av.



Vi har även börjat fundera lite på hur egentligen dagens rutiner fungerar och har då fokuserat på taxi- och lastbilar. Daniel tog kontakt med sin gode vän Mårten "the trucker" Newman och han påpekade problematiken med ruttgenomgångar innan man startar en ny tur. I dagsläget får man långa textremsor utskrivna med information om vilka stopp man ska göra. Vid turer med färre stopp sköts detta genom verbal kontakt (vi behöver göra djupare undersökningar kring denna problematik).
Vi ska även undersöka på vilket sätt taxichaufförer får nya rutter och stopp och hur chauffören mottager och godkänner en ny resa.

Tidigare har vi diskuterat möjligheten att kunna sätta meddelanden på "items" på kartan. T ex att skriva en kort text eller bifoga ett foto om någonting man vill förmedla till sina kollegor. Ett exempel skulle kunna vara att skriva en text kopplat till ett specifikt företag (ett "item" i systemet) som man hämtar varor av. Meddelandet om företaget Ronny Snickare lyder: "-Kunden har varit missnöjd med att vi parkerar för långt ifrån lastkajen vilket gör att säkerheten för deras truckförare påverkas". Då kan man snabbt och enkelt påverka kundrelationen på ett positivt sätt.

Paper Prototyping, grunder

Idag har vi startat med att skapa en del grundförutsättningar för paper prototyping. Dessa består av en modell av en iPod i wellpapp med ett hål där skärmen befinner sig i vanlig fall, en karta ritad på papper och post-it bitar som förställer enheter och items.

Brainstorm med Interaction Relabeling som utgångspunkt

Denna glade whiteboard-tavla är det ostrukturerade resultatet från vår Brainstorm med Interaction Relabeling som utgångspunkt. Under bilden på tavlan befinner sig resultatet från Brainstormingen utifrån Interaction Relabeling.



Map Functions/Interactions

Input from Interaction Relabeling	Output from Brainstorming
Camera: Spin Objective	Zoom In/Out. Perhaps use accelerometer or gestures.
Camera: Shortcuts (Specialized Buttons) Coffee Machine: One-click-changes	Shortcuts: Gestures, Taps, Buttons

History Functions/Interactions

Input from Interaction Relabeling	Output from Brainstorming
Camera: Save on memory card Coffee Machine: Store Things	Save additional information. Auto-save? Have a draft/publish functionality.
Camera: Customization Camera: Modules Coffee Machine: Different types of products	User Profiles (Costumization) Save user behaviours Store editors name/date/time with changes Build the system with Plugins: Different kind of modules: Unit list, actions, geofence, alarms, etc
Coffee Machine: Trash can	Revisions, list, undo

Unit Functions/Interactions

Input from Interaction Relabeling	Output from Brainstorming
Coffee Machine: Different types of products	Presets: Different kind of unit items: car, boat, house, route

Alarm and Notification Functions/Interactions

Input from Interaction Relabeling	Output from Brainstorming
Coffee Machine: Notifications	Notifications: textual, visual, sound?

Visualizations

Input from Interaction Relabeling	Output from Brainstorming
Camera: Switch orientation	Portrait/Landscape mode. In a web application on iPod touch the browser controls the orientation via the accelerometer. Which mode is the application in its initial state?
Camera: Thumbnails Camera: Picture-in-Picture	Map-in-map Thumbnails of saved locations
Camera: Themes	Themes (User theme, Administration theme) Indication of mode (like rumble icons on iPod touch)
Camera: Picture overlay Camera: Focus Camera: Lock Coffee Machine: Steam	Semi transparent overlays Controls - buttons? Dialogs Fade/Animation/Focus/Blur of currently disabled functions Lock Map Information Layers
Camera: Zoom Visualizations (18-55)	Zoom indication. How do you present which zoom level is active?
Coffee Machine: Extra settings hidden Coffee Machine: One-click-changes	Show/hide relevant information Give the user proper feedback
Coffee Machine: Specialized compartments	Show how many objects (e.g. items, stops) that are left. Drag-and-drop objects from a box. Handle like war shuffleboard-table. Place troops. Risk, Tabletop, World of Warcraft
Paper map: Icon explanation	Icon explanation (e.g. tooltips, help section, help, layer)
Paper map: City view/ Region view	Views, zoom-level (e.g. city, region). Can this be visualized via icons of a city, region etc?
Paper map:City view/ Region view	Map views: Full screen (one map view) Map-in-map (several map views) Side-by-side (several map views) Overlay (several map views)
Paper map: City size visual	Visualize importance of different objects (e.g. size, color). Could be airports, hospitals but also units and items.
Paper map: Distance between two pins on map Paper map: Distance table	Show distance between to points. Perhaps by just press two points on map with two fingers.

Environmental/Device issues

Input from Interaction Relabeling	Output from Brainstorming
Coffee Machine: Need manual to handle it (bad)	Easy to use

Brainstorming

En solig måndag i centrala Göteborg tar två 'unga' män tjuren vid hornen och utför en designmetod, det är inte vilken metod som helst utan den ökända gamla fornnordiska metoden hjärnstormning (fri översättning). Vad fick dessa män ut av metoden i fråga? Det finns fint uppraddat (är det ett småländskt ord?) nedan.

Map Functions/Interactions

Input from Extreme Characters	Output from Brainstorming
Ninja: To be controlled with as few hands as possible Medieval Princess: Fit small hands	One/two handed interactions. Perhaps use small gestures to fit both types of interaction and different hand sizes.
Ninja: Fast	Different pan-speeds. Save locations in shortcuts (bookmarks) Use shortcuts, perhaps gesture based (e.g. a circular interaction clockwise - zoom in)
Ninja: Gloves - iPod touch can not detect fingers God: Shake for Quake	Pan the map using the accelerometer Shake the iPod touch could start a function Twist the iPod touch to zoom in
Medieval Princess: Can not write very well	Tap interactions. (e.g. morse code password)

History Functions/Interactions

Input from Extreme Characters	Output from Brainstorming
Medieval Princess: Show geographical map	View history/future in geographical calendar
Medieval Princess: Keep track of where she has been	Wi-Fi based positioning of iPod touch
God: Sin notification	Statistics of trips (e.g. speed, accuracy)

Unit Functions/Interactions

Input from Extreme Characters	Output from Brainstorming
Ninja: Show villains on map Medieval Princess: Show horses Medieval Princess: Show staff locations God: Show people, show angels, keep track of believers	Which is the best way to show units? Colors, icons etc. Should there be different classes of objects? Show obstructions: traffic jams etc. Could these be implemented automatically from "Vägverket"?
God: Sin meter	Unit/Item ranks (e.g profit size, type, deal with supplier)

Alarm and Notification Functions/Interactions

Input from Extreme Characters	Output from Brainstorming
Ninja: Silent	Maybe use audio feedback
Medieval Princess: Be notified of assassin.	Alarm notifications (e.g. a unit is outside a geofence)

Visualizations

Input from Extreme Characters	Output from Brainstorming
Ninja: Security - Show only for ninjas	Have different security levels. Perhaps depending on which person is online.
Ninja: Show geographical information	Show terrain
Ninja: Extremely detailed map Medieval Princess: Show only own kindgdom God: Map of everythinh	Have Regional views (e.g. world, continent, country, city)
Ninja: Where can i hide, Where can I refill my weapons?	Show interaction pliability on map (show possible places to put items)
Ninja: Black Medieval Princess: Pink	Themes, color codes. Always show which mode that is enabled (place unit, show route, show history)
Medieval Princess: Rumors, pictures of trips	Show position related information (e.g. pictures, voice recordings, text)
God: Other-dimensional travel	Layer visualizations. Enable and disable many different layers at the same time (e.g. satellite, terrain, items, units, and history layers)
God: Thought based interface	Every user have their own profile
God: Reboot genesis	Filter views. Separate projects from each other.

Collaboration Functions/Interactions

Input from Extreme Characters	Output from Brainstorming
Ninja: Send secret information Medieval Princess: Keep in touch with friends God: Send angels, send S:t Peter	Chat, send help and emergency units.

Environmental/Device issues

Input from Extreme Characters	Output from Brainstorming
Ninja: Hidden in sword	Where and in which context is the device and application going to be used?
Medieval Princess: Easy to use	Must be easy to use for the novice user.
God: Thought based interface	Intelligent agent that remembers the users actions and learns from them

Interaction Relabelling

Idag har vi fortsatt med designövningarna genom att titta på andra objekt och fundera på om deras egenskaper kan appliceras på en kartapplikation. Det första steget vi tog var att lista de intressanta egenskaperna medan vi efter det analyserar dem för att hitta det som kan vara intressanta att använda.

Vi valde att inte analysera gårdagens extrema karaktärer för att försöka hålla tankarna öppna för alla galna idéer.



Camera
Change orientation (landscape, portrait)
Zoom - spin objective
Save pictures on memory card/ in camera
Hang around neck
Lots of customization possibilities
See thumbnails
Change themes
Picture Overlay
Picture-in-picture
Modules - change
Focus (perhaps on visualizations)
Zoom Visualizations (18-55)
Shortcuts (Specialized buttons)
Timer
Lock

Coffee Machine
Steam
Made for making many different types of products
Extra settings hidden
Two different bean compartments
Always textual feedback
Notifications (Rinsing, Cleaning)
Store things (Coffee cups etc)
Need manual to handle it (bad)
Connect external units
Trash can
Movable parts
Not mobile
Specialized compartments
One-click-changes
Self-cleaning


Paper map
Foldable
Icon explanations
City view/ region view
Distance table
Color codes/roads in different colors
Names on regions (e.g. Södermanland)
Road numbers visual
City names
City size visual
Color codes on top of the pages (tabs)
Distance between two pins on map
Icons for places (airport, camping)
Altitude info (e.g. mountains)
Browse by changing "page"
Scale indicator (geographical distance measuring)

Extreme Characters

Dagen började med lite rapportskrivande om prototyper och användartester för att sedan svänga om till att handla om extrema karaktärer. Här tog vi tre extrema karaktärer (en ninja, en medeltida prinsessa och gud) och försökte se vad de skulle önska för funktioner och interaktioner hos en framtida mobil enhet med tillhörande kartapplikation. Det vi fick fram av designmetoden listas nedan.

Ninja:
Silent
Black
Show Secret Passsages
Security - Show only for ninjas
Durable
Send secret info
Use as flash light/ light bomb
Hidden in sword
Could be used as shuriken
Remote distraction (sound, light)
See villains on map
Augment non visual info
Show fellow ninjas
To be controlled with as few hands as possible
Fast interaction
Gloves - iPod touch can't detect fingers
Low weight
Show geographical formations
Extremely detailed map (3d?)
Just local view, not important to see the world
Where can I hide?
Where can I refill my weapon supply?

Medieval Princess:
Match dress
Keep track of horses
Soft and pink
Watch only the own kingdom
Geographical calendar(event agenda), must plan because horse travel is slow.
Easy to use
Fit small princess hands
Show staff location
Measure height and length (jump to tree from tower)
Keep track of food intake
Keep in touch with friends
Start rumor/ get hold of latest rumors
Nice pictures of places she's been
Save speeches at geographical position
Automatic keep track of where she has been
Be notified if assassin is in vicinity
Connect to dragon GPS unit
Special tap (morse) password, she can´t write very well


God:
High altitude
Long battery time
Other-dimensional travel (not to be confused with xyz dimensions)
Thought based interface
Sin meter / heaven-hell ratio of people
Keep track of people
Sin notification
Keep track of angels
Remote control Send angels
Direct connect to S:t Peter
Notification if Pearly Gate is opened
Map of Everything (including Eden & Paradise)
Send digital Paradise Ticket
Keep track of believers
Place natural disasters
Alarm Clock (e.g. for Armageddon)
"Shake for Quake"
(Re)boot - Genesis (Not to be confused with the band with Phil)
Route to Paradise

Val av designmetoder och prototyper

Idag har vi dykt ner i det djupa hav som kallas designmetoder. Vi har kikat på vilka som kan vara intressanta för oss att använda i detta initiala skede där det är viktigt att skapa både funktionella och innovativa interaktionslösningar.

De metoder vi diskuterat är:

Experience Prototyping:
Känns som det är för tidigt i designprocessen för att använda sig av denna metod. Kan vara bra i senare skede.

Body Storming:
Kanske inte kommer användas som en utpräglad metod men kommer säkerligen ligga som en inspiration i detta stadie då det kan vara bra att fundera på hur en användare beter sig i en verklig användningssituation.

Interaction Relabelling:
Denna metod är den som ligger varmast om hjätat just nu och det är den vi ser skulle kunna ge mest innovativa interaktionsidéer.

Extreme Characters:
Också en metod som känns bra för att sparka igång våra kreativa tankar och tänka "utanför boxen"

De olika kategorier av prototyper som kan tänkas komma till användning under våra användartester är:

Low-Fidelity Prototypes:
Pappersprototyper

Medium-Fidelity Prototypes:
Presentationsprogram (Flash, PPT)

High-Fidelity Prototypes:
Fungerande prototyp på iPod touch

Möte med Martin 11/2 -2008

Medverkande: Martin, Peter och Daniel

Martin tycker att vi ska prata med Jocke på Kartena om implementation av resor i befintligt system (vilket visade sig vara ungefär som vi tänkt oss i en framtida produkt).

Kartsnurr - Man kanske skulle kunna spinna kartan som en jordglod, alltså att om man t ex drar med fingret och släpper i en viss riktning så fortsätter kartan att panorera.

Citat Martin: "Zooma länge, problem" Martin menar att det tar lång tid att zooma in långt i Google Maps då man använder 'Pinch-tekniken'. Det blir många pinchar efter varandra.

Alarm: Kan man skapa en notifiering i applikationen som inte stör för mycket? Man kanske borde klassificera larmen så att inte alla visas på samma sätt. Stora alarm måste man ta tag i direkt och mindre larm blir en notifikation i menyraden eller något sånt. Om man får en notifikation om ett larm så kan det komma upp som en liten karta med en förhandsvisning av en karta. Denna karta kan sedan maximeras om detta alarm rör mig eller om det är mitt anvarsområde. Kan också komma upp på en ny sida (som i safari i iPod touch)

Konceptuell idé: Om man har GPS så vore det bra om man endast får larm i närheten av där man befinner sig. T ex för utryckningsenheter och jourpersonal.

Actions: Kan man visa på karta direkt i en bubbla. Knappar direkt i bubblan (tooltip på ett item eller unit) där man kan styra functions (t ex tuta, låsa bilen). Man borde också kunna få action-choices direkt på alarmnotifikationer. T ex om en bil har gått utanför ett geofence så stäng av motor med en knapptryckning.

Visa alarm/actions i historiken.

Direkt feedback på actions? Det är ju svårt då signal måste skickas tillbaka från GPS-enheten. Konceptuellt hade detta varit väldigt bra.

Två olika actions:
Action in responce to alarm
User initiated action

Visualisera actions och alarms på ett bättre sätt än idag.

Användning i bil? Vi bör tänka på var iPodden ska användas.

Standard Responce chat: Yes, no, maybe. Kan vara gestbaserat. Ska vara smidigt att göra utan att man ska behöva titta noga på skärmen.

Prioriteringslista: Martin tycker historik och kartnavigeringen är viktigast.

Enhands-panorering. Kanske att man håller iPodden med en hand och låser med fingret och sedan flyttar iPodden för att panorera.

Function Analysis och prioriteringslista

Idag har vi arbetat med metoden Function Analysis för att klassificera de funktioner som vi tidigare tagit fram. Funktionerna och deras klassificering presenteras nedan.

Main:
Show Map

Necessary:
Pan Map
Zoom Map
Show History
Search/Filter History
Show Units
Show Items
Show Routes

Desirable:
Spin/Speed Pan Map
Track Units
Show Alarms
Show Alarm Notifications
Show Address
Search Address
Send Action
Send Chat/IM
Recieve Chat/IM
Show Geofence
Show Details (Item, Unit, Route, Geofence)

Unnecessary:
Create (Item, Unit, Route, Geofence, Address)
Edit (Item, Unit, Route, Geofence, Address)
Delete (Item, Unit, Route, Geofence, Address)


Efter vi klassificerat funktionerna har vi även listat alla funktioner i den ordning vi kommer att prioritera de vid prototyptillverkning. Prioriteringen ses i listan nedan:

1. Show Map
2. Pan Map (Includes Spin/Speed Pan Map)
3. Zoom Map
4. Show Units
5. Show Items
6. Show Routes
7. Show History
8. Search/Filter History
9. Show Alarms
10. Track Units
11. Show Geofence
12. Show Unit Details
13. Show Item Details
14. Show Alarm Details
    
15. Show Route Details
    
16. Show Geofence Details
17. Show Alarm Notifications
18. Search Address
19. Show Address
20. Send Actions
21. Receive Chat/IM
22. Receive Chat/IM
    

Möte med Staffan - 8/2-2008

Medverkande: Staffan, Daniel och Peter

Vi ska beskriva interationsmöjligheterna hos Ipod touch och göra en sammanfattning och beskrivning av dessa. Kan vi hitta nya möjligheter ska vi beskriva dessa också.

Begränsingar: Ska vi begränsa oss till endast det som finns tillgängligt i SDKn, ska vi gå efter hårdvarubegränsningar, eller ska vi arbeta rent konceptuellt.

Vi kan göra fejkade skärmdumpar av det vi inte hinner bygga i prototypen?

Det finns inga direkta regler för layouten för uppsatsen. Det finns regler för framsida men det finns ingen anledning att fokusera på det nu.

Hitta en röd tråd och följ den hela tiden!!!!!!!!

Funktionalitet

Idag har vi börjat titta lite på vilken funktionalitet som kan tänkas vara med i touchen. Vi har delat upp det hela i lite olika kategorier för att strukturera det.

MAP
Zoom - in
Zoom - out

Pan - North
Pan - East
Pan - South
Pan - West

HISTORY
Sort by:
Trip bounds
Date/Time Bounds
Map Bounds (Geofence Bounds)
Unit Bounds


UNITS
Track
Create
Read
Edit
Delete
Overview

GEOFENCE
Create
Read
Edit
Delete
Overview

ALARM
Show
Notification

ITEMS
Activate
Inactivate
Create
Read
Edit
Delete
Overview

ROUTE
Has Items
Create
Read
Edit
Delete
Overview

ADDRESS
Search Create
Read
Edit
Delete
Overview

ACTIONS
Send action X on
Send action X off

Designmetoder

Ännu en dag i exjobbets underbara värld...

Idag har det försts diskussioner kring vilka designmetoder som skulle vara passande för oss att använda. De som vi har skrivit lite om men känner är mindre passande är: Innovation by boundary shifting och Experience Prototyping. Andra som däremot mycket väl skulle kunna bli lyckade inslag i designprocessen är: Brainstorming, Extreme Characters, Interaction Relabelling och Function Analysis.

Usability och Role model

Hej bloggen

Idag har vi skrivit om Usability och försökt förklara det så gott det går och även börjat strukturera hur användartesterna ska utformas. Det som är viktigt där är att få med vad det egentligen är vi har för input och output vid varje iteration och varför vi över huvudtaget utför de. Sen lite annat smått och gott så klart...

Vi har även tittat på Role Model och hur de intressenter som finns passar in i role model och varför, och givetvis har Tufte fått lite tid tillägnat sig.

En fredag innan helgen

Idag har letandet i litteraturen fortsatt, t.ex. har vi börjat titta på Tuftes "Envisioning Information" och har just klarat av första kapitlet som handlar om "Escaping Flatland". Vi har även skrivit om Nielsens användbarhetsprinciper.

Möte med Martin - 31/1-2008

Medverkande: Martin, Peter och Daniel

Martin tipsar om en webbapplikation till iPod touch som visar kartor från google maps. I applikationen kan man 'panna' med två fingrar.

Det vore bra att ha någon slags detaljvy (som förstoringsglaset vid textinmatning i iPod touch) när man håller fingret på ett och samma ställe på kartan en viss tid.

Ha någon slags funktion där man kan använda accelerometern som linjal (mäta sträckor).

Man skulle kunna panorerna i den karta genom att fysiskt flytta iPodden. Som att kartan ligger på bordet och att man maskar tittgluggen genom iPodden.

Torsdagsmöte

På plats: Daniel, Martin, Peter

Vi gick igenom hur långt vi kommit (börjat med introduktion och relaterat arbete) och talade lite om informationsvisualisering.

Martin kom med idéen att man skulle kunna ha ett förstoringsglas till kartan så att man kan se en detaljnivå även när man är på en hög zoomnivå.

Han tipsade också om en web-applikation för iPod touch där de gjort ett interface så att man kan 'panna' i Google Maps med hjälp av två fingrar istället för med musen som i den vanliga web-applikationen. Applikationen finns länkad på http://www.apple.com/webapps/utilities/googlemapsforipodtouch.html och ligger på http://www.grapier.com/maps.html. Den kan vara användbar för oss då det är möjligt att vi kan tillämpa samma strategi på Kartenas kartor.

Vi pratade också om att man skulle kunna förflytta sig i kartan genom att flytta på iPoden, dvs med hjälp av accelerometern avgöra när man flyttar på iPod och därmed scrolla i kartan.

Relaterat arbete och Designmetoder

Igår grävdes det en del i djungeln av relaterat arbete. Det skrevs en del om Google Maps, Android, iPhone/iPod touch, Reactable, Entertaible, Microsoft Surface och OpenMoko.

Innan har vi även skrivit om några designmetoder som kan tänkas användas under arbetets gång. I dagsläget är dessa: Interaction Relabelling, Extreme Characters, Brainstorming, Experience Prototyping, Innovation by boundary shifting och Function Analysis. Denna listan kommer med stor sannorlikhet se annorlunda ut längre fram.

Möte med Staffan - 28/1-2008

Medverkande: Staffan, Daniel och Peter

Ska vi jobba parallellt eller inte? Alltså ha flera lösningar och förslag och sen testa de emot varandra.

Ha olika strategier: En med bara single-touch, en med bara multi-touch, och en med både och.

Vill vi göra en konkret eller en abstract uppsats? Prototyper kontra teorier.

Ska vi använda formativ evaluering?

Användartest: Vilka ska vi testa på? Experter, noviser, oss själva?

Staffan tycker att vi ska ha ett formellt möte med Martin på Karten varje vecka så att vi får input från företaget om vårt arbete.

Vi borde ha interna deadlines (T ex:I iteration 4 måste vi ha zoom in/zoom ut färdigt)

Strukturera iterationerna, ha möte på måndagen där vi går igenom vad vi ska göra denna iteration och på fredagen för att gå igenom vad vi verkligen gjorde under iterationen.

Möte med Staffan

Idag har vi haft möte med Staffan och diskuterat följande:

Ska vi testa olika idéer mot varandra inom en iteration eller ska vi välja en idé och testa den?

Det kan vara olika designmål eller designstrategier som testas mot varandra, t.ex. att man ska kunna sköta allt genom single-touch. Detta leder till frågan om iterationerna för dessa olika strategier skall ske parallellt eller sekvensiellt och ombytligt, dvs att vi först kör en iteration med enbart single-touch och sen en vecka med enbart multi-touch (exempelvis) eller att vi kör båda idéernas iteration under samma vecka.

Vilket fokus ska vi ha på uppsatsen?

Ska det vara fokuserat på designmetoder och hur vi använder de eller ska vi vara fokuserade på att vara mer praktiska och verkligen bygga en bra prototyp?

Hur skall testerna gå till?

Ska vi ha tester med oss själva eller ska vi ha det med verkliga användare, noviser eller experter osv?

Ett bra sätt vore att ha formella möten med Martin i analysfasen i varje iteration för att gå genom vad vi kommit fram till, och även så att Martin kan testa det som vi gjort för att få något slags expertutlåtande. Sådana möten skall givetvis dokumenteras. Vissa veckor kanske det räcker med att vi själva testar det och andra kanske vi ska ha mer djuplodande tester.

Interna deadlines

Det är viktigt att vi strukturerar upp arbetet i iterationerna ordentligt, exempelvis med iterationsmöten i slutet av veckan och interna planeringsmöten i början av veckan.

Ett annat sätt för att få det mer strukturerat är genom att göra en "Functional Analysis" för att få en prioriterad lista med funktioner och dessutom beroenden mellan olika funktioner. Denna lista kommer förmodligen att omarbetas under tiden i och med att saker blir klara och/eller omprioriteras.

Ytterligare en sak som är bra för struktur är att ha en risklista för att se vilka risker vi har i projektet och hur vi kan motverka dom samt hantera dom om de skulle hända.

Litteratur
Vi har fått boken Envisioning Information av Edward R. Tufte från biblioteket och ska börja titta om den innehåller relevant information för oss.

Litteratursökning

Idag har vi spenderat dagen åt att leta och läsa relaterad litteratur. Vi har också beställt böcker som berör informationsvisualisering (ex. Tufte) till Lindholmens Chalmersbibliotek.

Förberedelser

Dagens aktiviteter har bestått av att leta källor och vi har formaterat referenser på ett stiligt sätt i rapporten för att slippa göra det i sista stund. En del referenser som kan vara bra i framtiden är även de införda, markerade med en turkos färg.

Vi har även satt en preliminär titel till "Exploring the interactive capabilities of iPod touch to enhance classic and mobile web-based map applications".

Nya mål

Kartena tyckte att vi skulle utveckla iPod-prototypen så att den var adapterbar till en vanlig webbläsare också. Så vi har skrivit om målet med exjobbet så att det stämmer överens med uppgiften. När det gäller själva gränssnittet till iPoden så är det ett helt nytt sätt att interagera om man jämför med deras nuvarande produkter. När det gäller gränssnittet i webbläsaren handlar det i dagsläget mest om att visualisera olika sorters rutt-historik.

Vi har även börjat kolla lite på den inofficiella SDK:n för iPod touch, för att vara på den säkra sidan om inte Apples officiella släpps som den ska av någon intressant anledning.

Vidare har det också skrivits lite i uppsatsen och vi har börjat kolla vilken sorts litteratur vi vill ha med. Både gällande designmetoder och designteori (t ex användbarhet och generella principer).