Examensarbete inom Datalogi
Visualisering av Kanban boards
VISUALIZATION BOARD
Visualization of Kanban boards
Institut:
Sammanfattning
Visualiseringstavla - Visualisering av Kanban boards
Hos många företag används whiteboards för att visualisera arbetsprocessen. En vanlig metodik för detta är så kallade Kanban boards, ett system av tabeller och lap-par för att indikera olika avvikelser eller moment i projekt med datum och annan relevant information. Företag kan även välja att använda en mjukvara som simulerar samma metodik, ett exempel på detta är så kallade Elektroniska kanban boards. I detta arbete har båda dessa metoder (whiteboard samt en digital lösning) observer-ats hos tre olika företag på uppdrag av ett managementkonsultföretag i Stockholm som använder sig av Kanban boards och liknande metodik med sina kunder. En omvärldsanalys har genomförts genom att studera olika funktioner hos existerande elektroniska kanban boards samt en litteraturstudie över existerande forskning inom ämnet. Många problem upptäcktes med existerande arbetsmetod såsom komplika-tioner med säkerhet och problem med att dela med sig av en tavla till människor som inte är lokalt närvarande. I detta arbete har efter förstudien ett lösningsförslag presenterats och delvis implementerats. Förslaget utvecklades genom en iterativ designprocess och kontinuerliga samtal med arbetsgivare, där fokus har legat på interaktion. Den slutliga prototypen testades med några potentiella slutanvändare genom låta dom utföra enkla uppgifter med programmet och sedan diskutera för-och nackdelar med interaktionsupplevelsen. Slutligen demonstrerades programmet för arbetsgivare och managementkonsulter. Förslaget godkändes för vidare utveck-ling och en stor pekskärm köptes in för vidare experiment.
Abstract
Visualization board - visualization of Kanban Boards
Innehåll
1 Bakgrund 1
1.1 Avgränsning . . . 3
2 Förstudie 4 3 Existerande arbetsmetod 6 3.1 Whiteboardlösning (Företag A och B) . . . 6
3.1.1 Delbarhet och historik . . . 6
3.1.2 Krångligt och resurskrävande . . . 7
3.1.3 Ergonomi . . . 7
3.2 Digital lösning (Företag C) . . . 8
4 Existerande lösningar 9 4.1 Interactive Boards . . . 9
4.1.1 Forskning . . . 9
4.1.2 Smart boards . . . 11
4.1.3 PQ Labs multi-touch overlay . . . 12
4.2 Elektroniska Kanban Boards . . . 12
4.2.1 Oracle och SAP . . . 13
4.2.2 Team Foundation Server (Microsoft) . . . 14
4.2.3 Swift-Kanban (Digité) . . . 15 4.2.4 LeanKit . . . 17 4.2.5 iObeya . . . 18 5 Metod 19 5.1 Iterativ design . . . 19 5.2 Parallell design . . . 19 5.3 Arbetsmetod . . . 20 6 Lösningsförslag 20 6.1 Medium . . . 21 6.1.1 Plattform . . . 21 6.2 Gränssnitt . . . 22 6.3 Post-WIMP . . . 22 6.3.1 Komponenter . . . 24 6.4 Inmatning . . . 25 6.4.1 Persondator . . . 25 6.4.2 Pekskärm/interaktiv tavla . . . 25 6.5 Delbarhet . . . 26
6.5.1 Hela upplägget globalt och lokalt . . . 27
6.5.2 Webtjänst . . . 27
6.6 Lappar lokalt med förbipasserande . . . 27
6.8 Historik och statistik . . . 29
7 Implementering 29 7.1 Iterativ designprocess . . . 30
7.2 Den slutliga prototypen . . . 32
8 Utvärdering 35 8.1 Interaktionstest . . . 35
8.1.1 Resultat . . . 36
8.2 Presentation för arbetsgivare . . . 38
8.3 Test med pekskärm . . . 39
9 Diskussion 40 10 Slutsats 41 10.1 Forsatt utveckling . . . 43
11 Referenser 44
12 Appendix 48
1
Bakgrund
I många arbetsmiljöer visualiseras information i form av tavlor med färgglada pluppar, lappar och tabeller istället för skriven text eller instruktioner. Man använder denna teknik till exempel i samband med visualisering av Kanban, en teknik introducerad av Taiichi Ohno på Toyota för att med lappar synliggöra materialbehov vid produktion.[1] Kanban är ett kalendersystem som ger en stor överblick över vad som behöver produceras, när det ska produceras och hur mycket som ska produceras. Detta system används som ett bokningssystem för Lean och Just-In-Time (JIT), den signalerar för dessa arbetsmetoder resursbehov eller belastning med mera. Lean är en produktionsmetod och filosofi, även den utvecklad av Toyota för hanteringen av resurser och effektiviseringen av arbetspro-cesser, för ökat ackumulerat värde för slutkund. Inom Lean behandlas alla resurser som inte direkt medför något värde för slutkunden som slöseri som bör elimineras från pro-duktionsprocessen. Just-In-Time är även det en filosofi som förlitar sig på Kanban för visualisering. JIT är en produktionsstrategi som bygger på att en produkt bör produceras just när den behövs och enbart i den mängd den behövs. På så sätt håller man lagrings-och transportkostnader nere. För att få en bra överblick av produktion lagrings-och tillgångar så att man kan ta viktiga beslut inom dessa två system används Kanban Boards. Dessa kan vara digitala eller faktiska tavlor som visar veckor, dagar, olika projekt, beställningar, avvikelser/problem och dom resurser som är tillgängliga. Den mängd av information som visas på tavlan och dom metoder som används för visualiseringen skiljer sig från företag till företag.
Figur 1: En Heijunka Box. Kolumner är tidsperioder och antal lappar av varje bokstav anger efterfrågan.
fungera som veckor och rader indikera olika produkter, eller varianter av samma produkt. Utöver dom nämnda visualiseringsmetoderna används tavlor i företag för andra syften såsom egna grupplaneringar, scheman eller projektöverblick. Företag använder sig till ex-empel av whiteboards med tabeller, post-it lappar eller fotografier och egna utskrivna pappersmallar. Det är runt dessa tavlor en grupp samlas för att ta beslut eller följa upp ett projekt. Ibland krävs en kontinuerlig överblick av tavlan beroende på vilken teknik man visualiserar, som till exempel i Continuous-flow manufacturing (CFM). I denna ar-betsmetod använder man sig genom JIT och Kanban av produktionseffektivisering för att helt eliminera kö-tid, material-förluster och skapa billigaste möjliga produkt. Man åstadkommer allt detta genom att ha kontinuerliga korta möten där utvecklare ombeds att fokusera på ett specifikt moment och försöka förbättra produktionen där.[2] Det är dock fler arbetsmetoder än CFM som kräver kontinuerliga möten, inom arbetsmetodiken Scrum används tavlor för att visualisera iterationsstegen i en mjukvaras utveckling, I den-na metod finns till exempel dagliga obligatoriska möten runt tavlan. [3] Oftast är tavlan en vanlig whiteboard och går under många olika namn såsom teamboard, task board eller
Kanban Board. Task boards är speciellt vanliga för att illustrera vad som görs just nu, vad
som bör göras och vad som är färdigt i ett arbete, därför består tavlan oftast av enbart dessa tre kolumner och lappar för att beskriva dom olika momenten man jobbar med. Även här används färger för att illustrera hur viktigt ett moment eller arbete är. Dessa moment kallas i Scrum för “Stories”, som måste slutföras under en så kallad Sprint. En Sprint är helt enkelt en kort tidsperiod (oftast mellan en vecka och en månad) under vilken arbetet ska utföras.[3] Digitala lösningar såsom Electronic Kanban eller eKanban har blivit vanligare på senare tid. Dessa utgör en blandning av traditionell teknik såsom lappar och tavlor, men också med streckkoder på som kan skannas och skickas som text-meddelanden till lager eller andra enheter i ett företag. Dessa digitala lösningar använder sig oftast av internet för informationsflödet.[4] Dom har till exempel använts av Ford Motor Company för att förbättra arbetsprocesser.[5]
Figur 2: Ett upplägg på en whiteboard
1.1
Avgränsning
Vårt mål är att förbättra existerande arbetsmetod, en sådan förbättring har avgränsats till att enbart behandla interaktionen med en whitebord som används för kanban. En mjukvara har utvecklats, där även där en avgränsning gjorts med mål att enbart fokusera på användarvänlighet, utformning och interaktionen mellan människa och dator/tavla. Säkerhet, plattform och andra kanban-relaterade detaljer har berörts flyktigt. Eftersom kanban boards används i många olika yrken har fokus valts att läggas på målgruppen
managementkonsulter. Detta har gjorts med uppdragsgivarna (Samarbetande konsulter
AB, Gamla Stan), som är managementkonsulter, i åtanke. Detta innebär helt enkelt att vi är intresserade av alla sorters kanban-lösningar, från dom mer strikta lean- eller JIT-tavlorna där kort enbart visar resurstillgångar, Heijunka-Boxar som visar efterfrågan där kolumner symboliserar olika datum och simpla Task boards, till mer avslappnade former såsom gruppplaneringar eller projektöverblick där kanban-korten, kolumnerna och hela utformningen kan skilja sig markant från företag till företag. Vårt fokus är därför mer att
simulera en whiteboard och allt vad det innebär, så att våra slutanvändare
2
Förstudie
Arbete inleddes i början av sommarlovet innan terminstart. Kurser valdes under termi-nen för att passa till ämnet arbetet behandlade, eftersom jag inte läser Data-Interaktion utan en renodlad datalogi-master så valde jag att läsa kurserna
Människa-datorinteraktion (DH2620) 6 hp, Kooperativ IT-Design (DH2655) 9 hp samt Interaktions-design II (DH2627) 15 hp. Dessa läste jag parallellt med mitt arbete för att förstå alla
termer och tillvägagångssätt. Arbetsgivarna (Samarbetande Konsulter i Gamla stan) gav mig både resurser och tid att observera arbetssituationen och deras nuvarande arbetsme-tod. Utöver dessa undersökningar har en omvärldsanalys gjorts, se avsnitt 4.2 Elektroniska
Kanban Boards. Deras behov var formulerad som att00förbättra existerande arbetsmetod00,
jag hade därför fria händer att lösa problemet på det sätt jag fann mest lämpligt. Jag spenderade flera veckor hos arbetsgivarna i deras kontor i Gamla stan, genom att delta i deras möten och seminarier så fick jag insyn i det dagliga arbetet med Kanban boards. Jag åkte till Frankrike tillsammans med arbetsgivarna och samtalade med två MDI-experter från KTH under en tre dagar lång konferens där olika ämnen togs upp däribland Heijunka och Lean. Slutanvändarna var ytterst diskreta om sitt arbete och den potentiellt mycket känsliga information som behandlades, därför hålls de anonyma i resultaten.
Det som var svårt med arbetet var att samla in data, speciellt slutanvändares åsikter om existerande arbetsmetod. Ibland var det svårt att ens få till ett möte, på grund av mycket hög sekretess hos konsulternas kunder så kunde man inte ta bilder eller spela in interaktionen under möten. När en prototyp väl presenterades så fick man väldigt mycket positiv respons, man gillade interaktionen, utseendet osv, men väldigt få kommenterade olika buggar eller interaktionsproblem. Den vanligaste kommentaren om prototypen var
00Ser jätte bra ut, implementera lappar och tabeller också00. Det var problematiskt då
arbetet behövde utvärdera vad som var bra och vad som var dåligt.
Existerande arbetsmetoder har observerats i samband med kontextuella intervjuer samt samtal med experter i form av kvalitativa intervjuer. En kontextuell intervju är när man intervjuar någon om en aktivitet i dennes arbetsmiljö, medan personen utför denna ak-tivitet. Denna metod tillhör den användarcentrerade designmetod arbetet har följt där man för att utveckla eller förbättra en produkt lägger stor vikt på slutanvändarens behov, krav och begränsningar [6]. Därför har under hela arbetets gång olika besök och intervjuer gjorts med slutanvändare eller experter. Dels för att förstå den existerande arbetsmeto-den, dess brister och fördelar, samt för att kunna kartlägga olika krav på en potentiell förbättring.
är vanlig med kontextuella intervjuer där man diskuterar det man observerat istället för en enkät med förbestämda frågor (strukturerad). Den var också lämplig eftersom enbart tre företag besöktes och vi därmed behöver kvalitativa svar. Det har inte funnits någon möjlighet att spela in arbetsprocessen med en kamera under kontextuella observationer på grund av sekretess.
Företag A: Detta företag använde sig av en whiteboard som medium för sitt upplägg där man i slutet av veckan samlades för att gå igenom olika projekt. Tre möten observerades som alla varade i högst en timme. Efteråt samtalade jag med deltagare, direkt efter mötet eller vid ett senare tillfälle.
Företag B: Detta företag använde sig av whiteboards som medium för sitt upplägg. Här observerades fyra stora tavlor under användning samt samtal med konsulter som jobbar med att utveckla upplägget och förbättra tavlorna. Just detta besök handlade mest om att förstå hur stora dessa tavlor kunde bli och vad för slags komponenter som kan användas. Mötet varade en hel dag men observationen av tavlorna varade enbart i 30 minuter.
Företag C: Detta företag använde sig av en enkel digital lösning (Microsoft Excel). I samband med detta möte som varade i en halvtimme (30 min) utfördes en kontextuell intervju där anteckningar och observationer gjorde på ett anteckningsblock. Sedan ställdes riktat öppna frågor och följdfrågor till moderatorn av mötet samt till handledaren som närvarade vid mötet.
3
Existerande arbetsmetod
I detta avsnitt sammanställs olika för- och nackdelar med dom två olika metoderna från förstudien, whiteboard-lösningen samt den digitala lösningen.
Det finns en viss skillnad på hur denna visualiseringsmetod används mellan olika företag. Vissa gör tavlans upplägg tillgänglig för alla, andra, på grund av sekretess, gör den endast tillgänglig för vissa personer. Vissa företag använder sig av stora faktiska whiteboards som hänger i korridorer och mötesrum, på utvecklingsnivå och på verkställande nivå. Andra företag föredrar hellre att använda kalkyl-ark i till exempel Microsoft Excel för att simulera en whiteboard. Detta görs så att de enkelt kan delas med människor som inte är närvarande på kontoret utan kanske befinner sig på någon annan arbetsplats men ändå vill ta del av tavlan. Dessa existerande lösningar som beskrivs nedan bör ses som unika för management konsulter och inte hur kanban boards generellt används, då stora skillnader kan uppstå beroende på vilken typ av arbete som utförs.
3.1
Whiteboardlösning (Företag A och B)
Efter att ha utfört kontextuella intervjuer och observerat fem whiteboard-upplägg hos företag A och företag B står det tydligt att denna visualiseringsmetod är bristfällig. Jag observerade flera uppenbara problem med den traditionella tavlan på väggen. Det framkom också av intervjuerna att whiteboarden inte var enkel att ersätta, framför allt framkom det i intervjuer hur viktigt det var med den stora breda ytan samt den överblick man får. Många brister och önskade funktioner kommenterades också, nedan listas några av dom problem som är återkommande.
3.1.1 Delbarhet och historik
Man kan därför inte gå tillbaka i tiden och se över hur det såg ut en vecka eller en månad sedan. Det faktum att man inte behöver identifiera sig för tavlan när man bidrar till upplägget gör att man också har svårt att följa vem som redigerat vad. Vi har alltså både problem med att identifiera vem samt när något gjordes. En förbättring av existerande arbetsmetod bör möjligöra dessa två krav som användare ansåg vara nödvändigt för deras arbete. Många av dessa tavlor har information om beställningar, kapacitet i lager eller annan känslig information för ett företag. Det kan därför vara problematiskt för ett företag om dess Kanban Board läcker ut till allmänheten. Många företag höll därför tavlorna hemliga, vilket problematiserade intervjuprocessen då enbart anteckningar kunde tas och ingen inspelning var möjlig. Det bör dock framgå att säkerhet är viktigt för en framtida förbättring av existerande arbetsmetod.
3.1.2 Krångligt och resurskrävande
För att använda sig av en whiteboard till Kanban eller liknande visualiseringsmetod måste man använda sig av många olika komponenter som placeras på tavlan. Under arbetet har en rad olika former av post-its, självhäftande lappar och färgglada pluppar observerats. Man skapar tabeller med tejp i olika färger och små laminerade foton eller egna små pappersmallar används. Dessa tillbehör måste köpas och sen eventuellt slängas, vilket skapar ett resurs-slöseri. Faktum är att det vanligaste problemet med traditionella kanban tavlor av denna typ är borttappade lappar. [8, 9] Pennor används också för att fylla i olika fält eller lappar, pluppar som inte används står i ett litet hörn för framtida användning. Processen att ändra något är krånglig och tidskrävande, speciellt om en hel kolumn eller något mer substantiellt ska redigeras, då allt sker manuellt där någon får plocka bort och placera om olika komponenter. Ett lösningsförslag bör därför inkorporera en mindre krånglig och resurskrävande metod för att både skapa ett upplägg, samt redigera det.
3.1.3 Ergonomi
sitter ned kan det öka risken (för män) för hjärt och kärlsjukdomar.[11] Därmed är långa sittande möten direkt skadliga. Det samma gäller om man under arbetet står upp mycket, sitter en kort stund under mötet och sedan måste ställa sig upp igen för att interagera med whiteboarden, till exempel lägga till en post-it eller ta bort en plupp. Man har helt enkelt ingen möjlighet att göra något med whiteboarden sittande utöver att titta på den, i vissa företag kan man inte ens titta på whiteboarden från en stol då den hänger i en korridor. Det är dock inte upp till oss att tala om för folk huruvida dom ska stå eller sitta. En mångsidig förbättring av existerande arbetsmetod bör därför möjligöra båda arbetsformerna: sittande och stående, för trötta och för utvilade.
3.2
Digital lösning (Företag C)
Under en metodikstudie som genomfördes i samband med detta arbete, observerades hur en digital lösning till problemet kan fungera. Denna lösning användes av ett företag (C) som en temporär lösning till ett växande problem med whiteboarden, man behövde fort dela med sig av tavlan till kollegor spridda över hela Sverige samt i utlandet och som inte hade möjlighet att närvara runt tavlan lokalt. På grund av sekretess användes endast anteckningar för att observera den kontextuella interaktionen vid det möte som observerades.
människor som inte är närvarande. Dom lösningar man har försökt med, såsom kalkylark, är inte heller särskilt användarvänliga eller intuitiva, man får inte samma känsla som när man fäster en post-it mot en tavla. Ett annat problem är att alla som deltog i mötet var tvungna att titta på den del av tavlan som moderatorn förstorat, eftersom hela mötet består av att en person (moderatorn) delar med sig av sin skärm till andra deltagare. Man var inte heller intresserad av moln-tjänster som fungerade som kalkyl-ark, såsom Google Docs av Google Inc, där man kan vara flera personer som editerar och ser ett gemensamt dokument över nätet. Anledningen var att kunden hade som policy att inte placera information på främmande servrar, på grund av det känsliga material som kan finnas på ett Kanban board.
4
Existerande lösningar
Digitala Whiteboards har funnits länge i form av så kallade Interactive whiteboards (IWB). Utöver den forskning som finns gällande dessa tavlor finns också kommersiella produkter såsom smartboards, en serie digitala Whiteboards av ett kanadensiskt företag. En annan kommersiell produkt är PQ Labs multi-touch overlay, en serie ramar som om-vandlar valfri bildskärm till en pekskärm. Förutom dessa hårdvarulösningar finns också flera mjukvaror som emulerar/simulerar Kanban Boards eller liknande visualiseringsme-toder, dessa kallas oftast för elektroniska Kanban (eKanban). I detta avsnitt undersöks både hårdvarulösningen samt mjukvarulösningen för att bättre förstå deras egenskaper samt få en helhetsbild av olika existerande lösningar till whiteboard-problemet.
4.1
Interactive Boards
Det finns en konsensus inom människa-dator-interaktionsfältet att bord historiskt har spelat en viktig roll för beslutsfattande och samarbete [13] och därmed vore det naturligt att utvidga interaktiva skärmar till bordsformat. Eftersom vårt fokus är först på visualis-ering och sen beslutsfattande, följer även att argument för bord är starka, men sekundära för detta arbete, dom tillhör samarbetsdelen, som i sig är viktig men inte primär.
4.1.1 Forskning
blyga människor vågar interagera i större utsträckning.[14] Vidare visar forskningen att i mer strikta former av möten där mer ska sägas än göras (interagera med skärmen), så är det bättre med en person som håller i musen eller interaktionsmedlet. En mångsidig lösning ska därför helst kunna möjligöra att alla styr (för mer interaktiva möten) eller att en styr (för presentation och diskussion).
En annan fördel med interaktiva tavlor eller bord är att om dom har möjligheten att visa i realtid vilka som bidrar under arbetet, säg i ett möte, så tenderar människor som talar mycket att minska på kvantiteten och öka på kvalitén av det som sägs. Detta tolkas som att man får en mer symmetrisk kollaboration, där alla samlade runt skärmen går mot att bli mer delaktiga. En sådan undersökning gjordes där man visade delaktigheten hos varje person med lysdioder på ett bord, delaktigheten mättes med mikrofoner som mätte när respektive person talade.[15] Det finns dock forskning som talar för att realtidsstatis-tik inte påverkar alla, till exempel menar vissa forskare att människor som bidrar lite till mötet inte påverkas av real-tids feedback utan behöver se hur dom presterade jäm-fört med andra under föregående möte, för att sedan kunna förbättra sitt deltagande vid nästa.[16] En mångsidig och övergripande lösning av whiteboard-problemet bör inkor-porera möjligheten för rendering av deltagande i real-tid samt kunna visa historik över deltagande. Detta kräver också att man vet vilka som bidrar till upplägget och infor-mationen på tavlan, återigen ställs vi inför identifikationsproblemet. I tavlans nuvarande form kan man inte identifiera vilka som redigerar upplägget.
I själva verket kanske det bästa medlet för jämlikt deltagande för interaktiva tavlor är den personliga sfären. Med personlig sfär menas det utrymme där människor känner sig bekväma, exempel på situationer där vissa människor inte känner sig bekväma är på scen eller bakom ett podium inför en publik. Att ge människor i rummet ett diskret och privat sätt att redigera och manipulera den gemensamma ytan utan att ställa sig upp och tala inför publik tillåter blyga, introverter eller deltagare med annat modersmål att känna sig bekväma och våga bidra.[17] Detta kan möjliggöras genom att förutom den klassiska pekskärmen låta deltagare interagera via sina egna datorer, handdatorer eller mobiler. Att dela upp användargränsnittet på detta vis kallas Distributed User Interface (DUI) och är problematisk i sig att implementera, speciellt om man är ute efter ett post-WIMP-gränssnitt, då inga standariserade implementeringsmetoder finns. [18] Post-WIMP är de gränssnitt som går bortom det vanliga klassiska användargränsnittet på datorer (WIMP) och försöker skapa ett eget paradigm, oftast ett som är mer intuitivt och bekant från den verkliga världen. WIMP står för Windows, Icons, Menus, Pointer. Det är en interaktionsstil där man använder sig av just dessa element (Fönster, ikoner, menyer och pekare) för att skapa ett grafiskt gränssnitt. WIMP utvecklades 1973 av Xerox PARC (se Figur 3). Flera problem kan uppstå med DUI, från kalibrering av pek-input mellan olika skärmar till ånger-historik. [18, 19] Dessa problem stöter vi dock på vid all sorts samarbete, vare sig den är samlokaliserad eller över ett nätverk.
Figur 3: Xerox Star gränssnitt[20]
traditionell whiteboard, vilket kan ses som en uppmaning till en mer aktiv arbetsmiljö. Ett förslag av Probst m.fl är dock att skapa ett kontor där man sömlöst kan växla mellan olika arbetsmiljöer, där hårdvaran är spridd över olika möbler och ställningar.[21] På så sätt kan de som föredrar att titta på och interagera med whiteboarden från en stationär dator göra det, men givetvis också ha möjligheten att göra det stående framför tavlan. Tanken är att inte tvinga personen att sitta framför sin dator, utan istället ha åtkomst till det digitala från valfri hårdvara på arbetsplatsen. I förslaget presenteras tre former för en arbetsplats: ett högt bord att stå vid, ett lågt traditionellt skrivbord och en whiteboard. En lösning för det problem vi ställs inför ska helst möjliggöra alla dessa former. En mer radikal arbetsform är att jobba på ett löpband, dvs att personen går på ett löpband och har en dator framför sig.[22] Denna form är till för att behandla överviktighet, och givetvis vore det mycket intressant om lösningsförslaget är flexibelt nog att möjligöra även en sådan unik lösning på ett växande hälsoproblem.
4.1.2 Smart boards
utformad mjukvara (Smart Notebook för utbildning eller Smart Meeting Pro för företag), även dessa utvecklade av Smart technologies. Plattformen är Microsoft Windows oper-ativsystem, man är inte heller bunden till ett specifikt program utan kan installera och köra en tredjepartslösning om man så behagar. En sådan lösning är iObeya, en mjukvara för visualisering av Kanban-tavlor och som presenteras lite mer i nästa avsnitt. Sett från interaktionsperspektivet är inmatningsmöjligheterna i SMART board dom mest intres-santa. Eftersom tavlan inte är en bildskärm utan enbart en panel som känner av tryck (med en projektor som projicerar bild), så besparar man företag kostnaden av att köpa en stor tryckkänslig bildskärm men ger också användaren möjligheten att interagera med skärmen bortom att peka. Man kan till exempel trycka objekt mot tavlan eller använda en penna. Därför medföljer whiteboard-pennor dom flesta modeller av tavlan. Tekniken för inmatningen utvecklades av företaget 2003 och är kamera-baserad, igenkänning av flera penndrag eller pek-inmatning sker via en mjukvara som körs i bakgrunden. Tidigare modeller använde sig dock av den mer traditionella resistiva plastfilmen som placeras över en vanlig skärm. Som produkt ger Smart boarden oss insyn i hur en interaktiv whiteboard kan se ut när den väl implementeras som en kommersiell produkt. Vi är främst intresser-ade av att förstå vad det finns för existerande lösningar och hur dessa ter sig, så att vi längre fram kan föreslå en egen lösning, som är bättre lämpad för vår målgrupp och syfte.
4.1.3 PQ Labs multi-touch overlay
PQ Labs erbjuder en billig lösning till att installera stora pekskärmar. Istället för att investera i en stor och oftast kostsam pekskärm så kan man istället placera en så kallad “multi-touch overlay”, en ram som genom infraröda sensorer med en hastighet på upp till 200 fps (bilder per sekund) kan känna av 32 inmatningar (fingrar) mot vilken bild-skärm som helst samt en respons upplösning på hela 32768 gånger 32768 pixlar. Det man gör är att placera ramen över en bildskärm och när ett finger bryter strålen vid tryck/pek, så registrerar ramen som är kopplad till en dator en inmatning. Produkten är en speciellt bra teknisk lösning eftersom ramarnas storlek kan gå upp till 350” vilket är något uppdragsgivare för detta exjobb letar efter, en realistisk ersättare till alla stora whiteboardlösningar. En annan bra anledning till att investera i denna produkt är att drivrutiner finns tillgängliga för alla stora operativsystem (Windows, Mac OS och GNU Linux).
4.2
Elektroniska Kanban Boards
som uppstår med den traditionella tekniken såsom borttappade lappar, mänskliga mis-stag eller långsamt informationsflöde.[12] Det finns många mjukvaror som simulerar eller emulerar olika Kanban-lösningar. Nedan presenteras några eKanbans som en omvärlds-analys över ett par skilda lösningar och de funktioner dom besitter. Vissa av dessa program erbjuds i form av Software as a Service (SaaS) där hela programmet är i molnet (under en webserver) och körs på en webläsare hos användaren. Andra verktyg erbjuds dock som program att installera på given plattform. Dom program som presenteras nedan har valts för att täcka ett så stort spektrum som möjligt, från stora multinationella mjukvaruföre-tag till små öppen-källkods projekt. Programmen har även valts för att presentera så skilda lösningar som möjligt, till exempel valdes flera öppenkällkods-projekt bort, då de var nästintill identiska. Försök har även gjorts att finna program som kan köras på digitala tavlor eller är anpassade för pekskärmar, handhållna datorer, smarta mobiler eller andra plattformar förutom den vanliga personliga datorn. Detta har gjorts för att upptäcka nya användningsområden och hur dessa elektroniska Kanban-tavlor kan se ut på olika plat-tformar. Försök har även gjorts för att finna eKanban som inte är bundna till en specifik teknik såsom Lean eller Scrum utan som kan visualisera olika arbetsmetoder. Fokus för evalueringen har lagts på gränssnitt, interaktion samt efterfrågade funktioner som sak-nas i existerande arbetsformer och som diskuterats i samband med avsnitt 3 Existerande
arbetsmetod.
4.2.1 Oracle och SAP
Figur 4: SAP:s Kanban Board lösning
4.2.2 Team Foundation Server (Microsoft)
Team Foundation Server (TFS) är en plattform för samarbete och överblick av mjuk-varuprojekt och är en del av Microsofts Application Lifecycle Management (ALM). [26] Detta program används för mjukvarukonstruktion där man följer en iterativ process, så-som Scrum. 2012 valde Microsoft att ge sitt Team Foundation Service, där TFS ingår, en Task board. Den kan köras i valfri webläsare (se Figur 5) och möjliggör Kanban eller till exempel Scrum beroende på om man väljer Kanban Board eller Task Board.
Figur 5: Team Foundation Service, Board-vy
används för all sorts utveckling eller produktion och är inte nödvändigtvis bundna till mjukvaruutveckling. I några av dom företag som besöktes i samband med arbetet användes till exempel pappersmallar med olika fält och ID:n, laminerade foton på dom som tilldelats arbete samt pluppar i olika färger som ibland användes för att markera någon form av avvikelse. I kontextuella intervjuer förklarades att inte bara överblicken, där man kan se hela tavlan utan att behöva dra något eller scrolla, men också färg-paletten och dom egna mallar man skriver ut (förutom post-it lapparna) gjorde tavlan till ett sådant bra verktyg. Allt detta tillsammans skapar den överblick en Kanban Board är menad att ge. Microsofts lösning är en bra lösning för mjukvaruutvecklare men är helt enkelt inte den lösning vi är ute efter. Den är inte heller särskilt anpassningsbar, manualen för detta på MSDN (Microsofts hjälpsamling) bestod av ett stycke, något som i fyra av fem fall ansågs vara ohjälpsamt. [27] Den visar dock hur viktig Kanban har blivit inom företag, som exempel på utvecklingen kan ges att TFS 2011 saknade en Kanban Board. Istället fanns flera tredjeparts-tillägg för Kanban Boards till TFS såsom Eylean Board. [28]
4.2.3 Swift-Kanban (Digité)
Figur 6: Dialog för att skapa ett nytt kort i Swift-Kanban
Figur 7: Kanban Board av XPlink Co. på Android operativsystemet
4.2.4 LeanKit
hörnet, att ha menyer fixa på det sättet försvårar användningen vid stora skärmar, det finns alltid risk att en meny är för långt bort åt en sida eller för högt upp för att nå. Att ha menyer på detta vis är egentligen mer konvention än strikt WIMP.
Figur 8: LeanKit Kanban Board
4.2.5 iObeya
iObeya från det franska företaget Kap IT är nog det bästa verktyget som undersökts i denna omvärldsanalys sett från vår målgrupp. Verktyget binder sig inte till något form av Kanban som Lean eller Heijunka, utan försöker istället simulera en whiteboard. Program-met kan köras som ett SaaS eller som en del av ett fysiskt serverpaket att installera [32], vilket är bra för företag som inte känner att det är säkert att ha konfidentiell information i molnet. Utöver detta upfyller den några av dom krav som kom fram i avsnitt 3.1
White-boardlösning, som historik och delbarhet. iObeya tillåter användare att samarbeta på en
Figur 9: iObeya
5
Metod
I detta avsnitt presenteras två olika designmetoder samt en kort motivering och beskriv-ning av den metod arbetet har följt.
5.1
Iterativ design
En iterativ designmetod innebär att man först utvecklar en enkel prototyp eller design-förslag, denna behöver inte vara fungerande utan kan vara allt från low-fidelity proto-typer (enkla, snabbt skissade idéer) till mer funktionella protoproto-typer. Därefter utvärderar man sitt koncept med sina slutanvändare för att upptäcka brister och problem. Efter utvärderingen går man tillbaka till ritbordet och förbättrar sin design. Detta fortsätter i flera iterationer tills utvecklaren är nöjd med produkten, vilket inom kooperativ design är när slutanvändaren är nöjd.
5.2
Parallell design
prototyp direkt tenderar man att enbart ändra smådetaljer efter evaluering, just för att man lagt så mycket tid och möda på prototypen. Parallell design är också mycket effektiv, den har en generationsförbättring på hela 70% jämfört med vanlig iterativ designprocess [33] som är på 18%.[34] Generationsförbättringen mättes genom att låta testpersoner interagera med varje iteration och försöka lösa enkla problem och sedan mäta antal lösta uppgifter. Dessvärre är parallell design mer kostsam och tidskrävande än den iterativa metoden.
5.3
Arbetsmetod
Arbetsmetoden har följt en kombination av parallell design och iterativ design där mer vikt har lagts på den iterativa designmetoden. Efter förstudien skissades några förslag fram, vissa mer konventionella och andra mer experimentella. Sedan implementerades två av dessa förslag för att slutligen helt fortsätta med ett av dessa koncept och iterativt för-bättra designen allteftersom respons från handledare och slutanvändare sammanställdes. I lösningsförslaget i nästa avsnitt presenteras detta koncept, och i avsnitt 7
Implementer-ing presenteras den faktiska prototypen som implementerades samt i avsnitt 7.1 Iterativ designprocess, själva iterationsstegen.
6
Lösningsförslag
6.1
Medium
När det gäller medium så ställs vi inför ett viktigt val, ska vi ersätta whiteboarden med hårdvara eller mjukvara? Ska vi utveckla en ny interaktiv tavla specifikt för Kanban eller ska vi enbart utveckla en mjukvara? Efter att ha observerat olika lösningar av eKanban (avsnitt 4.2 Elektroniska Kanban Boards), ser vi tydligt att många lösningar finns för specifika Kanban-metoder men väldigt få är kapabla att tillfredställa alla olika metoder som en whiteboard gör, vilket är problematiskt för vår målgrupp managementkonsul-ter, som ständigt måste implementera olika sorters lösningar för sina kunder och inte är bundna till en Kanban-lösning. Alla program hade sina begränsningar när det gällde vilka plattformar dom kunde köras på eller var utvecklade för. Till exempel kunde man använda sig av Swift-Kanban på smarta mobiler men det var som verktyg inte anpassat för interaktiva tavlor som SMART board eller stora pekskärmar generellt. Det motsat-ta gällde iObeya, som var anpassad för interaktiva motsat-tavlor men saknade stöd för smarmotsat-ta mobiler. Interaktiva tavlor i sig är inte heller en lösning på problemet, det finns inget speciellt med enbart en interaktiv tavla för att kunna ersätta en whiteboard såvida det inte medföljer en mjukvara som simulerar en whiteboard. Fokus för lösningen bör därför vara en mjukvara som simulerar en whiteboard med Kanban Boards i åtanke. Genom att ta lärdom av forskningen (avsnitt 4.1.1 Forskning) gällande DUI samt sömlöst växlande mellan enheter [21], bör vi utveckla en applikation som fungerar på olika enheter, från en interaktiv tavla till persondator, mindre handhållna enheter och smarta mobiler. På så vis behöver inte en användare binda sig till ett medium, mindre företag och institut be-höver inte från början investera i en kostsam interaktiv tavla/pekskärm och problem med ergonomi (avsnitt 4.1.1 Forskning) löses då valfri enhet kan användas för att interagera med Kanban-upplägget. [21]
6.1.1 Plattform
SMART board har som operativsystem Microsoft Windows eller GNU Linux, många av eKanban-lösningarna var SaaS som kördes via en webläsare. Under intervjuer (avsnitt
3.2 Digitalösning) med användare och företag framgick det att dom absolut inte kunde
6.2
Gränssnitt
För att programmet ska simulera en whiteboard måste vi överväga utformningen av gränssnittet. Allt pekar på en mjukvarulösning där man använder sig av ett Post-WIMP grafiskt användargränssnitt (GUI), där man går bortom det klassiska meny- och panel-systemet. Det vi vill åstadkomma är att manipulera eller redigera ett upplägg på en tavla, men det klassiska WIMP-gränssnittet handlar om att ha en dialog med datorn för att åstadkomma något.[35] Ett exempel på hur WIMP kan skilja sig från Post-WIMP är vid in-zoomning av en bild. I ett klassiskt WIMP-paradigm klickar man på “visa” i huvudmenyn längst upp, väljer “zoom” varvid man får upp en dialog med ett textfält där man fyller i “173%”, sedan godkänner för att zooma in bilden till 173 procent. En möjlig lösning i Post-WIMP som tillåter en mer naturlig interaktion är till exempel att använda sig av musens hjul för att förstora eller förminska, en ännu mer naturlig interaktion är att fullt ut använda sig av den styrplatta som finns på många bärbara datorer och med hjälp av två fingrar (moderna plattor stödjer detta) nypa till eller sära på fingrarna för att simulera en in-zoomning. Detta är bara ett exempel på hur Post-WIMP möjligör en mer naturlig interaktion mellan människa och dator. Den mjukvara som utvecklades för detta ex-jobb implementerade senare denna in-zoomningsmetod för att möjligöra in- och ut-zoomning med två fingrar på en pekskärm samt styrplatta (se avsnitt 10.1 Fortsatt
utveckling). Vissa eKanban-lösningar såsom iObeya har förstått att för att kunna
anpas-sa gränssnittet till en interaktiv tavla, så måste man skapa en mer naturlig interaktion som människor är bekanta vid från vanlig interaktion med en whiteboard. Därför går iObeya bortom WIMP-paradigmet och skapar ett eget gränssnitt som är mer lämpat för pekskärmar och interaktiva tavlor (avsnitt 4.2 Elektroniska Kanban Boards).
6.3
Post-WIMP
punkt man valt att framkalla menyn på. Ickelinjära menyer kan ha många fördelar när det gäller yteffektivitet, paj-menyer har visats vara mer yteffektiva än linjära.[36] Denna sorts meny har dock mer fördelar än så, jämfört med linjära menyer har dom funnits ge färre felval och en snabbare söktid. Eftersom alla val är lika långt bort från epicentrum så bidrar detta till ett snabbare och mer precist val.[13] Paj-menyer har denna fördel för att olika val sparas i det spatiala minnet hos användaren. För att kunna få alla dessa fördelar med paj-menyer måste epicentrum där menyn blommar ut alltid vara där mus-pekaren är. Knapparna på en meny behöver inte alla ha samma utseende vilket återigen skapar en större visuell igenkänning.[36] Därför föreslås att alla menyer har denna form, huvudmenyn kan blomma ut där man dubbelklickar på tavlan, och en redigeringsmeny kan blomma ut runt den komponent (till exempel: Kanban-kort) man redigerar. Eftersom forskning visar att olika former på knapparna ger en större igenkännbarhet, föreslås att även detta implementeras i menyerna.[36] För att åter förbättra användarkänslan föreslås
Figur 10: Paj-meny
da-torer nu för tiden har grafikkort kapabla till att rendera både animation och skalning. För att skala tavlan kan man tänka sig att man använder musens scroll-funktion när man sitter på sin personliga dator och drag med två fingrar när man använder sig av en multipekskärm.
6.3.1 Komponenter
Dom komponenter som har observerats användas mest (företag A och B) presenteras i tabellen nedan.
Plupp Pluppar är små runda plastknappar med en magnet på bak-sidan. Dessa numreras ofta och används i ett par olika färger för att symbolisera olika avvikelser eller arbeten. Från Figur 2 (avsnitt 1 Bakgrund) ser vi att pluppar är en mycket använd komponent. I den digitala lösningen (avsnitt 3.2 Digital
lös-ning (Företag C)) valde användaren att även ge “plupparna”
små kommentarer, vilket resulterade i ett slags mellanting mel-lan plupp och post-it.
Tabell Tabeller symboliserar ofta olika tidsenheter såsom vecka eller månad. Det är i dennes celler som Kanban kort eller pluppar placeras, dom kan dock också placeras mellan två celler. Post-it Post-It lappar i olika färger fungerar som en mer avancerad
plupp, här kan man få plats med lite mer information (ett arbete och vem som ska utföra arbetet) än enbart en siffra som på pluppen. Dom fungerar helt enkelt som vanliga Kanban-kort.
Avancerade kort Dessa papperslappar skiljer sig stort mellan olika projekt och används inte alltid. Det är mallar med olika celler där viktig in-formation om beställningar eller avvikelser fylls i. Dessa lappar kan även innehålla foton. Man kan uttrycka att dessa lappar är mer avancerade Post-its.
Tabell 1: Olika komponenter som används i whiteboardlösningen
Figur 11: Ett par tidiga skisser på hur dom olika komponenterna kan se ut
6.4
Inmatning
För att kunna interagera med mjukvaran behövs någon form av inmatning, denna metod kommer givetvis att skilja sig från enhet till enhet beroende på vilken typ av hårdvara som är kopplad till enheten. Om programmet körs på en stor pekskärm/interaktiv tavla så föreslås en metod, och om den körs på en stationär eller bärbar dator så finns en annan inmatningsmetod. Båda presenteras nedan.
6.4.1 Persondator
För en vanlig persondator föreslås användadet av mus och tangentbord. Skulle enheten vara en handhållen dator med pekskärm så föreslås det standardiserade skärmtangent-bordet samt enhetens pek-möjligheter som inmatning.
6.4.2 Pekskärm/interaktiv tavla
Figur 12: En skiss framtagen i samband med kursen DH2627 (Interaktionsdesign 2) på KTH. En mus-joystick samt två musknappar (höger och vänster) syns i bilden, dessa behövs inte för pekskärmar som redan kan ta emot inmatning med fingrar vilket simulerar en musplatta.
Alla som jobbar med Kanban boards hos arbetsgivarna har observerats använda sig av smarta mobiler, enheter dom själva äger. Därför föreslås att en applikation utvecklas för dessa användares mobiler. Mobilen ska genom det trådlösa nätverket kunna koppla upp sig till tavlan och genom applikationen kunna interagera med den. Programmet ska simulera ett helt tangentbord, så att personer som står framför tavlan ska kunna markera en lapp och redigera den från sin mobil. Utöver tangentbordet ska kort-kommandon finnas såsom “kopiera”, “klista in” och “ta bort”. Applikationen på mobilen skall även kunna skapa nya lappar eller pluppar och slänga över dom till tavlan för alla att se. Alla dessa principer resoneras fram efter den forskning (se avsnitt 4.1.1 Forskning) gjord över vikten av den personliga sfären och hur viktigt det är att låta användare ha ett personligt medium att interagera genom för att slippa stå på en scen bara för att redigera tavlan. [17] Utöver dessa ovannämnda fördelar följer att vi nu kan identifiera vissa av dom ändringar som görs, eftersom vi kan kräva att alla smarta mobiler måste identifiera sig med inloggning. Detta kommer vi se gynna oss i allt från säkerhet till historik-loggar och statistik över delaktighet som vi från tidigare avsnitt har funnit vara mycket relevant. Skulle en pekskärm/interaktiv tavla ha ett trådlöst handhållet tangentbord så kommer detta också att fungera på samma vis som ett simulerat tangentbord i mobilen. Problemet med denna teknik är dock att man inte kommer kunna identifiera vem det är som skriver. Givetvis blir ett sådant verktyg också en extra hårdvara att köpa vilket kan bli kostsamt om flera ska interagera med skärmen samtidigt.
6.5
Delbarhet
Inga andra kunde redigera i upplägget utan enbart observera vad moderatorn gjorde och få en överblick av upplägget.
6.5.1 Hela upplägget globalt och lokalt
För att lösa problemet med åtkomst globalt som lokalt, föreslås att programmet vid behov kan fungera som klient eller server för att både koppla upp till en server för att kunna se och redigera olika upplägg globalt över internet, samt fungera som server själv för att dela med sig av en lokal Kanban board till olika klienter. Som en klient kan man koppla upp från valfri enhet som kör programmet, man ser då vilka andra som är uppkopplade och kan navigera till den del av tavlan man vill fokusera på, något som inte gick med Excel-lösningen (avsnitt 3.2 Digital lösning (Företag C)) då moderatorn där bara delade med sig av skärmen över internet. Någon form av rättighetslista bör även existera för att hindra vissa användare från att till exempel redigera.
6.5.2 Webtjänst
En moderator ska kunna utöver att fungera som en vanlig server till andra klienter, även kunna publicera en tavla till en websida. Såsom många andra eKanban-lösningar som ges ut i form av ett SaaS så bör även denna lösning kunna möjligöra åtkomst till tavlan via en webläsare. Fördelen med detta är att man då inte behöver utveckla en version av programmet för handhållna datorer eller andra mobila enheter som smarta mobiler med mera.
6.6
Lappar lokalt med förbipasserande
problematiskt, man öppnar upp för attacker från icke-samlokaliserade användare, poten-tiella säkerhetsluckor kan öppna upp för attacker från personer som inte ens kan se eller är nära tavlan utan bara är inom det trådlösa nätverkets täckning. Tekniken kräver även att mobilen identifierar sig för programmet och nätverket. Liknande problem uppstår med annan trådlös teknik som BlueTooth. En annan metod är kontaktbaserad kommunika-tion som Near Field Communicakommunika-tion (NFC) eller den äldre Radio-frequency identificakommunika-tion (RFID). Dessa kommunikationstekniker möjliggör datatransaktioner genom att trycka en NFC- eller RFID-kapabel mobil mot till exempel en interaktiv tavla med samma kommu-nikationsteknik. Men denna lösning kommer inte fungera på alla enheter, många datorer, interaktiva tavlor och mobiler är inte NFC- eller RFID-kompatibla, denna hårdvarulösning är inte bara kostsam utan ter sig inte praktisk i nuläget då vi kommer markant minska antalet kompatibla enheter. Det unika med en whiteboard är att man måste närvara och faktiskt plocka bort lappen för hand, men kontaktbaserad kommunikationsteknik är inte särskilt utbredd i dagsläget, därför föreslås en annan metod: Genom att låta varje lapp dynamiskt kunna generera en streckkod med dess innehåll inbäddat, kan en mobil med kamera enkelt läsa av innehållet samt lagra det. Därför föreslås att varje digital lapp ska kunna generera samt presentera på skärmen en Quick Responce Code (QR-kod) av dess utseende samt innehåll för att senare kunna läsas av applikationen på den smarta mobilen. QR-koder är en form av 2-dimensionell streckkod utvecklad för den japanska bilindustrin av ett dotterbolag till Toyota. QR-koder kan lagra strax över 4200 tecken, vilket begränsar hur stor en lapp kan vara för att kunna använda sig av denna metod. Lappar större än dessa (högst osannolikt i Kanban boards) får därför kopieras över till en fil och skickas med annan valfri metod som till exempel det trådlösa nätverket. Detsamma gäller för lappar som har bilder. Är tavlan i server-läge kan man enkelt spara ned en valfri lapp via det trådlösa nätverket.
Figur 13: Ett exempel på hur en QR-kod kan se ut, just denna beskriver en gul plupp
6.7
Import och export
det tydligt att “Kanban-kort” eller avvikelser skickades via e-post. Detta är en naturlig företagskultur som kanske inte är den mest effektiva men fortfarande den mest bekanta och intuitiva för användarna. [12] Därför föreslås möjligheten för alla komponenter eller hela tavlan att uttryckas i formatterad text (till exempel CSV), så att ett Kanban-kort eller plupp kan exporteras till text och importeras från text. Ett scenario skulle vara att man kopierar ett Kanban-kort från sin egna tavla och klistrar in den i ett e-post som skickas iväg till en moderator. Moderatorn kopierar texten som beskriver komponenten och klistrar in den i tavlan som automatiskt generar komponenten. Man kan då även kopiera en komponent från en session av tavlan till en annan. Skulle man vilja, kan man skriva en ny komponent för hand och klistra in den i programmet. Utöver möjligheten att exportera och importera individuella komponenter bör man även kunna spara ned hela tavlan till en fil. Filformatet på detta dokument bör följa samma formatering som den när man exporterar och importerar komponenter.
6.8
Historik och statistik
Historik över tavlan bör alltid finnas tillgänglig så att man kan gå tillbaka och se olika förändringar eller ångra något. Detta möjliggörs enkelt genom att kontinuerligt spara ned tavlan. Att ha olika tavlor från olika datum sparade möjliggör analys av datat, man kan då söka igenom olika tidsstämplar med användares namn på. På så vis kan vi föra statistik över vilka som är mest aktiva med redigeringen av tavlan. Detta följer från avsnitt 4.1
Interactive Boards där forskning visade att en överblick av historiken av deltagande skapar
ett mer jämställt deltagande vid nästa session. [16] Realtidsstatistik över vilka som deltar i nuvarande session diskuterades även i avhandlingen [15], forskning visar att folk som deltar lite inte ändrar sitt mönster med realtidsvisualisering över deltagande, men skulle det ändå finnas intresse kan man implementera så att tavlans tidsstämplar från dagens session läses av, räknas och illustreras som en färg eller siffra under respektive deltagares namn. Förslagsvis ska personer som deltar mindre, få större namn i listan för att motivera till ökat deltagande.
7
Implementering
7.1
Iterativ designprocess
Lösningsförslaget från avsnitt 6 Lösningsförslag, var ett koncept som skissades fram allt-eftersom den iterativa designprocessen tog sin form. Processen började delvis som parallell-design där två prototyper utvecklades, en WIMP och en post-WIMP. Post-WIMP blev den metod som forsatte att utvecklas och den som slutligen utvärderades, all utveckling av båda prototyperna skedde genom en iterativ designprocess där ändringar presenterades för arbetsgivaren, som också är slutanvändare. På grund av brist på resurser och tid utvecklades inte båda prototyperna samtidigt.
Figur 14: Iterationsstegen, två prototyper kodades, en WIMP-version och en post-WIMP
Efter att ha visat ett par rudimentära skisser på papper för arbetsgivaren, kodades en enkel prototyp som kunde skapa pluppar, arbetet började med pluppar eftersom dom var enklast att implementera, därmed kunde fel upptäckas tidigt och åtgärdas istället för att direkt implementera alla komponenter och sedan upptäcka att man missförstått slutanvändaren. Denna enkla implementering, där man kunde placera små färgglada cirklar (pluppar) blev första iterationen (se Figur 14), den visades återigen upp för arbetsgivaren som tyckte om upplägget men ville se mer och efterfrågade mer komponenter och färgval. Därav blev nästa iterationsteg enkla “lappar”. Detta visades återigen upp för arbetsgivaren (se Figur 15). Denna första prototyp följde det klassiska WIMP-utseendet. Vikten låg mer på att ge funktion så snabbt som möjligt än att överväga interaktionsdesignen eller annan möjlig användning bortom en vanlig persondator. Vid det andra iterationssteget ville arbetsgivaren veta hur det såg ut om man delade med sig av upplägget till andra användare över nätet. Därför blev nästa iterationssteg – det tredje – att ge prototypen möjlighet att skicka över upplägget till en klient. Anledningen till att delbarhet blev det sista iterationsteget är att det redan fanns en existerande arbetsmetod för att dela med sig av ett Kanban board, nämnligen en form av fjärrstyrning för att dela skärmen med andra deltagare, för detta användes en tredjepartstjänst och därmed kunde en implementering av en dedikerad metod vänta tills tredje iterationsteget, se avsnitt 3.2 Digital lösning
(Företag C).
Figur 15: WIMP-prototypen; detta var den första prototypen.
7.2
Den slutliga prototypen
I detta avsnitt redovisas den tekniska implementationen av den slutliga prototypen. Här presenteras tillvägagångssätt, vilka funktioner som har implementerats och vilka val och beslut som gjordes.
Programmet utvecklades i programmeringsspråket Java i den integrerade utvecklingsmiljön (IDE) Netbeans på operativsystemet Ubuntu (GNU Linux). Detta språkval (Java) gjordes då ett av kraven var att programmet skulle kunna köras på de tre största operativsys-temen (GNU Linux, Microsoft Windows och Mac OS) vilket program utvecklade i Java kan. Eftersom programmet skulle följa ett post-WIMP gränssnitt vilket i vårt fall innebär cirkulära menyer (paj-menyer), så behövdes detta gränssnitt programmeras också. För att göra ett nytt användargränssnitt från början behöver man hantera många grafiska element, speciellt om man vill att programmet ska vara estetiskt tilltalande. Eftersom vi också skulle ha ett gränssnitt med animation så behövde vi någon form av hårdvaru-acceleration för vår rendering av bilder. Istället för att koda ett grafiskt renderingssystem så importerades istället spelutvecklingsbiblioteket Slick2D. Detta bibliotek tillåter enkel rendering av ett stort utbud av filtyper såsom PNG och SVG, två bildtyper som använ-des för att skapa grafiken i programmet. med många olika manipulationsmöjligheter (till exempel rotation och skalning). Slick2D använder sig av OpenGL (open graphics library) för att uppnå hardvaru-accelererad grafik. Huvudmenyn var det första som implementer-ades (post-WIMP: Iterationssteg 3). Menyn kommer fram när man dubbelklickar på valfri plats på “tavlan” (se Figur 16). Från huvudmenyn är det menat att alla funktioner som traditionellt sätt nås genom en panel högst upp i WIMP GUI kan nu nås från denna cirkulära meny.
Figur 16: Huvudmenyn
implementerades enbart pluppar. En plupp kan markeras med ett klick och hamna i redigerings-vy med dubbelklick. Varje plupp har, som nämnts i lösningsförslaget, ett val-fritt kommentarsfält (se Figur 17).
Figur 17: Till vänster: en ny plupp, till höger: samma plupp markerad
Redigeringsmenyn för en plupp är även den en cirkulär meny som blommar ut från pluppen med en snabb animation. Menyn har fyra olika färger som när dom väljs ändrar pluppens färg, en knapp för att generera en QR-kod, två knappar för att flytta fram eller bak plupp-ens ordning relativt andra pluppar, en knapp för att kopiera pluppen, en knapp för att ta bort pluppen samt en knapp för att växla mellan ett alltid synligt kommentarsfält och ett kommentarsfält som enbart är synligt vid markering av pluppen (se Figur 18).
Figur 18: En plupp med redigeringsmeny, samma plupp efter några ändringar, samma plupp med genererad QR-kod.
Hela tavlan kan sparas ned från huvudmenyn till en XML-fil. XML valdes eftersom fil-formatet är ett vanligt filformat som tillåter hierarkisk struktur, vilket är nödvändigt om programmat ska vidareutvecklas för att tillåta “avancerade lappar” där varje sådan lapp kan bestå av flera fält, bilder och andra komponenter. När en plupp kopieras så kopieras dess XML-data, därmed kan den exporteras till en textfil, vid importering av en plupp är det bara att klistra in XML-datat igen. Nedan är ett exempel på en plupp beskriven i XML, vid kopiering av en plupp är det detta som kopieras till klippbordet.
<title>New</title>
<author>Adam.Sam</author>
<timestamp>2012-09-10</timestamp>
<note visible="false">Empty Note</note> </plupp>
Det är också i detta format som data skickas mellan server och klient. XML är alltså vårt protokoll för kommunikation.
Som en temporär lösning för inzoomning så placerades en scrollbar(rullningslist) längst ned för att simulera ett mushjul eller en multipekskärms inzoomningsmöjlighet. Ide-alt ska detta enbart skötas av musens hjul när en mus används och en handgest som till exempel drag med två fingrar för att indikera inzomning när en multipekskärm an-vänds, detta implementerades dock senare (se avsnitt 10.1 Fortsatt utveckling). En mobil applikation utvecklades för operativsystemet Android (se Figur 19) i utvecklingsmiljön Eclipse med programmeringsspråket Java. Programmet kan läsa av QR-kod genererad av en plupp. Applikationen kan också koppla upp sig till en tavla som en klient och kopiera eller ta bort olika komponenter eller lägga till nya pluppar. På grund av tidsbrist implementerades aldrig ett fullfjädrat tangentbord enligt lösningsförslaget (avsnitt 6.4.2
Pekskärm/Interaktiv tavla).
8
Utvärdering
Utvärderingen av verktyget bestod av två olika moment, första momentet bestod av ett test där sex personer som jobbat med Kanban boards eller liknande visualiseringsmetoder fick testa på att lösa simpla uppgifter med hjälp av verktyget och sedan intervjuas med riktat öppna frågor där dom fick uttrycka sina tankar kring interaktionen. Andra mo-mentet är en timmes presentation för arbetsgivaren och olika managementkonsulter, där dom senare gav sina tankar kring projektet och huruvida dom var intresserade med att fortsätta utveckla det.
8.1
Interaktionstest
Ett enkelt test utfördes för att utvärdera interaktionen. Testet bestod av uppgifter som användaren skulle utföra på en bärbar dator. Nedan följer alla uppgifter:
1 Skapa detta upplägg:
2 Ta bort från detta upplägg plupp “5” 3 kopiera plupp “4” till ett textdokument
4 klistra in en modifierad version av plupp “4” där titeln är ändrad till “hej” 5 använd mobilen för att ta bort plupp ”2”
6 använd mobilen för att skapa en ny plupp “hello”
Utöver dessa uppgifter gavs ingen annan information, varken hur man får upp huvud-menyn eller hur man navigerar, zoomar ut och in eller redigerar en plupp. Detta gjordes för att se hur inlärningskurvan såg ut men också för att upptäcka hur en testperson förvän-tar sig att programmet ska fungera och hur detta skiljer sig från programmets faktiska natur. En smart mobil med applikationen för verktyget installerad, delades ut. Upplägget var redan i server-läge och mobilen var redan uppkopplad, detta eftersom uppkoppling till upplägget fortfarande förlitade sig på att knappa in rätt IP-adress, något testanvändarna inte kände till. Det förklarades för testpersonerna att enbart musens vänstra musknapp samt tangentbord och mobil var godkända interaktionsmedel. Innan själva testet började presenterades arbetet, dess bakgrund och mål. Sex personer medverkade, alla med en högskole-ingenjörsutbildning eller högre. Vissa hade en mer datorvetenskaplig bakgrund, andra var från helt orelaterade bakgrunder. Alla hade gemensamt att dom jobbat med whiteboard-upplägg i någon form i sitt arbete. Testpersonerna fick ställa frågor om dom hade kört fast, eller kommentera på olika funktioner under testets körning, detta blev som en form av think-aloud protocol (TAP). TAP är en metod som ofta används inom utvärdering av användarinteraktion, genom att låta testpersonerna tänka högt när de interagerar med mjukvaran så får man en större mängd kvalitativ data att analysera. Efter slutfört test ställdes riktat öppna frågor om interaktionen och uppgifterna. Sedan diskuterades programmet kort, där generella åsikter antecknades. Detta test hade flera begränsingar, antalet försökspersoner var litet men tillräckligt (enligt min handledare som tyckte att sex personer räckte), däremot var medlen så som bärbar dator med mus och tangentbord inte en särskilt bra ersättning för en whiteboard. Antalet pluppar var begrän-sade och experimentet visar inte hur man ställer upp ett Kanban Board. Den fokuserar mer på interaktionen med menysystemet samt digitala pluppar. Det är dock fortfarande relevant för våra arbetsgivare eftersom de även ibland behöver använda sig av en laptop för att interagera med mjukvaran. Det var först när arbetsgivaren köpte in en whiteboard som tester kunde utföras på den, se 8.3 Test med pekskärm.
8.1.1 Resultat
Testperson 1 Testperson 2 Testperson 3 Testperson 4 Testperson 5 Testperson 6 19 min 15 min 20 min 14 min 15 min 18 min
Tabell 2: Tiden det tog för att fullfölja hela testet varierade från person till person.
Huvudmenyn
interaktionen var väldigt trevlig och användarvänlig när man väl förstått hur man gör men att man vant sig vid ett paradigm och “ställt in sig” på att menyer kommer fram med högerklick vilket gjorde denna implementation enligt testpersonen i början väldigt “förvirrande”.
Redigering av plupp
Efter att ha förstått att menyer kommer fram genom dubbelklick så blev det mycket naturligare för testpersonerna att få upp redigeringsmenyn genom att dubbeklicka på pluppen. Att välja färg på pluppen kändes för alla användare som mycket “intuitivt”, det var bara att klicka på vald färg. Att editera text var dock mycket svårare för vis-sa testpersoner, många anmärkte på att “Empty Note” texten bör suddas ut när man markerar textfältet första gången, så att man inte behöver sudda ut den för hand. Många anmärkte också på att det var “osannolikt” för dem att enbart behöva markera text och editera (börja skriva) utan någon ny dialog eller andra mellansteg. I början kändes det svårt (flera försökte dubbelklicka på texten för att få fram en dialog) men alla höll med om att denna metod, ur ett användarvänligt perspektiv var mycket bekväm när man väl lärt sig hur man gör. En intressant sak som uppstod var att vissa försökte få upp rediger-ingsmenyn genom att dubbelklicka på kommentarsfältet under pluppen istället för själva pluppen. En testperson ansåg att det var allt för många steg för att ändra titeln på en plupp. Anledningen till att kommentarsfältet har färre steg till redigering än pluppens titel är för att man i Kanban boards ofta ändrar kommentaren men väldgt sällan nam-net eller titeln på pluppen. Många testpersoner försökte trycka på returknappen istället för att markera bort redigeringsmenyn för en plupp, detta var dock inte implementerat, flera snabb-kombinationer såsom Ctrl-V (klistra in) eller Ctrl+C (kopiera) behöver också implementeras då flera testpersoner försökte sig på dem.
XML-redigering
Alla deltagare hade någon erfarenhet med XML-baserade språk såsom HTML. Dock an-märkte majoriteten att själva konceptet att ett objekt såsom en plupp kan omvandlas till text och sen tillbaka till en plupp var något dom var högst ovana vid. En testperson ansåg att själva ideen var “ovanlig och lite förvirrande i början”. Alla tyckte dock att det var otroligt smidigt när dom väl klistrat in den nya pluppen till tavlan på uppgift 4. Några testpersoner hade problem med att förstå att man skulle markera den nya modifierade texten och kopiera den och sedan klistra in den i programmet från huvudmenyn. Störst problem uppstod med att förstå att man skulle markera hela texten som beskrev plup-pen och kopiera den, till exempel med Ctrl+C. Alla förstod direkt att det var “<title>” taggen i filen som skulle ändras från “4” till “hej”.
Mobil-interaktion
mobilen fungerar mer som en fjärrkontroll, efter att ha förklarat för testpersonerna att man markerar pluppen först via musen och sedan använder mobilen för att ta bort så gick det mycket bättre. Vissa gav upp direkt medan andra efter ett tag förstod “fjärkon-trollsparadigmet”. Det hade kanske fungerat bättre om man istället för en laptop hade haft en pekskärm så att man fick använda fingrarna för att markera. Flera testpersoner ansåg att retur-knappen i mobilen bör vara en accepterad inmatning för att till exempel skapa en plupp (Skapa knappen).
Diskussion
Det framgick genom diskussion med testpersonerna efter testet att det i början var förvir-rande hur användargränssnittet var utformat. Alla ansåg dock att när man väl visste hur man skulle göra så var interaktionsupplevelsen väldigt rolig och “innovativ”. Några förslag till förbättringar behandlade mest små-buggar som att mellanslag inte alltid registrerades eller att applikationen på den smarta mobilen vid ett tillfälle förlorade uppkoppling och behövde loggas in igen. En återkommande anmärkning var att vid uppgift 6 skapades inte den nya pluppen där man hade zoomat in eller navigerat till utan trädde istället fram vid en fix position vilket inte uppskattades alls, förslaget från många var att pluppar som skapas från mobilen bör skapas där man tittar, dvs där man har zoomat in. En plupp som klistras in, skapas vid sin forna plats där den kopierades, men detta kändes för alla väldigt kontra-intuitivt eftersom alla ansåg att pluppen ska klistras in där man har tagit fram huvudmenyn. Därmed bör klistra-in metoden ersätta koordinaterna för en kopierad plupp med nya koordinater relativa till huvudmenyn. Alla testpersoner gav positiva kom-mentarer för utseendet och var ytterst intresserade av forskningen bakom paj-menyer och post-WIMP GUI, alla höll även med om att paj-menyerna kändes enklare att navigera än vanliga linjära menyer. En testperson anmärkte att dubbelklick var ett mycket bättre alternativ till det klassiska “hålla in” för att simulera ett högerklick, enligt dennes egna utsago så har det alltid varit problem med hur länge man ska hålla in samt att fingret måste vara stilla för att få fram menyn på en pekskärm.
8.2
Presentation för arbetsgivare
och hur man kan gå vidare. Alla kommentarer var positiva och dom flesta ville genast se hur man skulle gå tillväga för att implementera lappar samt tabeller. Man uppmärk-sammade speciellt hur bra mobil-interaktionen var samt möjligheten att kopiera pluppar till ett textdokument direkt. Som ett positivt resultat bestämdes vid slutet av mötet av VD:n att projektet skulle gå vidare till nästa fas och att man direkt ska sätta upp ett labb och köpa in en stor pekskärm för fortsatt utveckling.
8.3
Test med pekskärm
Arbetsgivaren beslutade att köpa in en 4200 PQ Labs multi-touch overlay samt en 4200 bild-skärm. Installationen var väldigt enkel, en bärbar dator med operativsystemet Microsoft Windows med prototypen installerad kopplades till PQ labs overlay med en USB-sladd. PQ Labs overlay fästes med tejp mot bildskärmen som i sin tur också var kopplad till den bärbara datorn. En glasskiva bör egentligen vara placerad mellan skärm och overlay men denna var inte placerad där under detta test på grund av brist på resurser. Drivrutinerna för PQ Labs overlay installerades och ett test av interaktionen utfördes med en manage-mentkonsult hos arbetsgivaren. Syftet med testet var att testa tekniken tillsammans med mjukvaran. Konsultens åsikter om både mjukvara (prototypen) och hårdvara (pekskärm) diskuterades och alla funktioner som var implementerade i prototypen testades (se Figur 20).
Ett par problem upptäcktes genast med inmatningen. Det var väldigt svårt att dubbelk-licka, oftast utan framgång. Detta beror dock på PQ Labs multitouch overlay som inte var fäst ordentligt, då vi fick liknande resultat med dubbelklick i andra program. Att dra en plupp runt kändes väldigt naturligt, och att interagera med mobilen var väldigt bekvämt, dock upptäcktes några buggar som kan ha uppstått på grund av operativsystemet (Win-dows) eller kontorets höga nätverkssäkerhet. Till exempel gick det inte att använda sig av mobilapplikationens alla funktioner såsom “kopiera” och “klistra in”, däremot gick det att skapa pluppar från applikationen. Som slutsats behöver programmet definitivt testas mer på Windows, debuggas i kontorets säkra trådlösa nätverk samt vidare tester utföras med pekskärmen när allt är fäst korrekt och en glasskiva är installerad. Konsultens åsikter var positiva genom hela testet, han uttryckte även att prototypen i sin nuvarande form kan fungera även utan lappar eftersom pluppar har ett kommentarsfält, men att han hellre vill se ett färdigt program.
9
Diskussion
Detta avsnitt syftar till att diskutera arbetets upplägg och genomförande.
Det finns mycket att förbättra med arbetet, speciellt i dess tidiga fas. Jag hade velat göra fler besök hos olika företag och gärna spela in deras interaktion med en videokamera. Gällande den iterativa designprocessen hade jag velat se fler personer som fick ge sina åsikter, det var i princip enbart arbetsgivaren eller andra konsulter som fick se processen. Det i sig är inte dåligt, alla dessa var slutanvändare. Det hade dock varit bättre för iterationsstegen om en fokusgrupp eller liknande hade anordnats.
Tillsammans med en konsult satte vi upp den inköpta pekskärmen i kontoret och började experimentera med mjukvaran. Nu kunde man direkt se hur mjukvaran simulerar en whiteboard med pluppar. Det hade varit mycket givande om en sådan skärm hade varit tillgänglig i ett tidigt skede i arbetet så att både funktion och utseende hade kunnat anpassas till skärmen. Även interaktionstester hade kunnat utföras på skärmen. Eftersom pekskärmen var ett kostsamt köp valde dock företaget att vänta tills jag hade en prototyp att visa, vilket jag demonstrerade under min presentation (se avsnitt 8.2 Presentation för
arbetsgivare).
