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
Från huvudmenyn kan man växla mellan server- och klient-läge för att dela med sig av tavlan eller koppla upp till en tavla. Av dom komponenter som fanns i lösningsförslaget
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.
<plupp x="-216.5" y="-127.5"> <colour>yellow</colour>
<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).
Figur 19: Mobilapplikationen; på grund av tidsbrist implementerades inget tangentbord utan enbart små kortkommandon såsom kopiera och klistra in samt “skapa en ny plupp”.
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
Alla deltagare tyckte att själva utformningen på huvudmenyn var bra men att det inte alls var tydligt att man behövde dubbelklicka för att få fram den. Vissa kom fram till att man skulle dubbelklicka direkt, andra tog det lite längre tid att förstå, man testade att högerklicka eller knappa in olika kombinationer på tangentbordet innan man till slut fick fram menyn. När detta var tydligt blev det dock inga problem att få fram den igen. En person fick hjälp med att få fram huvudmenyn, personen anmärkte senare att själva
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
Alla testpersonerna ägde själva en smart mobil. Ett tidigt problem med interaktionen med “tavlan” via den mobila applikationen var att nästan alla testpersoner försökte markera pluppen de skulle ta bort (uppgift 5) genom mobilen, de försökte till exempel hitta plup-pen i en lista eller meny. En testperson kommenterade att hon “letar efter plupp 2”. Men
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.