Klient

Klienten till verktyget är webbaserad och implementerades med ramverket Angular [29]. Angular skapar en komponentbaserad arkitektur som lämpar sig bra till fallstudien ef- tersom verktyget skapar just komponenter från de handritade skisserna. För att skapa MD-komponenter användes Angular Material som är ett bibliotek med komponenter som implementerar Material Design.

För att bygga en webbapplikation finns det alternativ när det kommer till val av ram- verk och bibliotek. React och Vue är två populära alternativ till Angular och hade fungerat för att bygga klienten [30][31]. Anledningen till att Angular valdes av författarna var fram- förallt för att Exsitec bygger sina webbapplikationer i Angular och har god kunskap om ramverket. Angular användes tillsammans med ngrx-store, som är inspirerat av Redux och hanterar webbapplikationens tillstånd [32][33]. Ngrx-store har fördelen att det skapas en ensam källa till webbapplikationens tillstånd, vilket underlättar när komplexiteten växer och fler komponenter påverkar varandra. Tillståndet kan ändras genom att definiera och skicka ut händelser som fångas upp och ändrar tillståndet. Då tillståndet ändras notifieras alla komponenter som prenumererar på tillståndet.

4.2.2

Ikoner

För att användare ska förstå hur man kan rita olika komponenter utvecklades ikoner som var och en representerar de olika komponenterna. Dessa ikoner styr på vilket sätt de olika komponenterna skissas. Eftersom klassificeringen fungerar bättre om klasserna är distinkta från varanda kommer ikonernas utformning påverka prestandan hos automationen. Många ikoner som ser ungefär likadana ut gör uppgiften svårare, vilket leder till att det blir fler fel. Då ikonerna togs fram var ett av målen att skapa en uppsättning ikoner som var så distinkta som möjligt sinsemellan, ingen ikon skulle vara den andra lik.

Ikonerna påverkade också en annan egenskap hos verktyget, hur enkelt det är att använda. Visserligen blir verktyget enklare att använda om det blir färre fel, men om ikonerna i sig är svåra att skissa skapar det utmaningar som kan leda till att det tar längre tid att skapa komponenterna man vill. Ikonerna bör också bestå av enkla former som är enkla att skissa för användaren. Stilen på ikonerna som togs fram blev ikoner designade med tjocka enkla linjer som påminner om hur det ser ut när man skissar i verktyget.

Ytterligare en aspekt som det togs hänsyn till är likheten till komponenten som genere- ras. Genom att utforma ikonen så att det på ett intuitivt sätt går att se vilken komponent den gestaltar var målet med att förenkla inlärningen av ikonerna. Att komma ihåg att ikonen för en slider ser ut som en slider bör till exempel vara enklare än att komma ihåg än att den ser ut som någon annan godtycklig form. I bästa fall skulle även användare kunna gissa sig till hur en komponent skissas för att automationen ska känna igen den.

Ett alternativ till att utveckla ikoner hade varit att helt enkelt inte använda ikoner alls. Istället för ikoner skulle namnet på komponenten varit det som användaren baserade sin skiss på. Vilket troligtvis skulle leda till att skissernas utseende skulle skilja sig betydligt mer och klassificeringsuppgiften skulle bli svårare.

En variant av ikoner som skulle kunna användas istället för de skissartade ikonerna som tagits fram är att använda bilder av komponenterna som genereras. Det skulle bli svårare att skissa och klassificera jämfört med de skissartade ikonerna, men användarna får mer att gå på än om de endast får namnet på komponenten.

4.2. Prototypverktyg med automationsstöd De skissartade ikonerna valdes över de andra varianterna eftersom de ledde till den enklaste klassificeringsuppgiften. Det var ett säkert val i det här sammanhanget då träningsdata skulle framställas under projektet. Då kunde prestandan hos klassificeringen förväntas blir bra nog för att verktyget skulle kunna användas för att testa automationsdesignkoncepten under de planerade användartesterna.

Figur 4.1 är en bild på alla ikoner som användes som förslag på hur de olika komponenterna kunde skissas, intill varje ikon står namnet på komponenterna (i de flesta fall samma som används i komponentbiblioteket Angular Material). Genom att presentera förslag på hur skisserna kan se ut gjordes antagandet att det skapas träningsdata med mindre varians än vad som hade skapats utan förslagen. Samma ikoner som används för att ge förslag på skisserna används i prototypverktyget för att visa hur en viss komponent ritas. Ikonerna utformades med målet att hitta en balans mellan att likna den färdiga komponenten, vara enkel att rita och skapa så distinkta klasser som möjligt.

Figur 4.1: Ikonerna som användes i gränssnittet som förslag på hur de olika komponenterna kunde skissas.

4.2.3

Insamling av data

Data i form av handritade skisser av komponenterna baserade på ikonerna som togs fram behövde samlas in för att kunna träna modellen. Metoden som användes för att göra det gick till som så att personer på Exsitec blev tillfrågade om ifall de hade tid att skissa några komponenter. Att skisserna skulle användas för att träna ett neuralt nätverk förklarades för personen innan den började skissa. Gränssnittet som användes utvecklades för att göra

4.2. Prototypverktyg med automationsstöd uppgiften att skissa en komponent enligt ikonens utseende och sedan skicka in den så enkel som möjligt. Dessutom skulle användaren uppmanas att fortsätta skissa nästa komponent efter att skissen var klar.

Ett separat gränssnitt användes under datainsamlingen, se Figur 4.2. Gränssnittet var tänkt att påminna om verktyget och på så sätt skapa liknande förutsättningar för att skissa vid insamling av data som vid användning av verktyget. Detta för att göra skisserna från insam- lingen så lika skisserna i verktyget som möjligt. En användare blev uppmanad att skissa en komponent baserat på ikonen för den komponenten. Användaren valde själv när skissen var redo att skickas in och hade valet att sudda sin skiss och börja om. Då en skiss skickats in uppmanades användaren att skissa en annan komponent. Gränssnittet roterade på det sättet genom alla komponenter med tillhörande ikoner och samlade in lika många skisser på varje komponent.

Figur 4.2: Gränssnittet som användes för att samla in data för att träna det neurala nätverket. För att skapa en första klassificeringsmodell var metoden med ett separat gränssnitt för att samla in data den enda som diskuterades. Däremot när den första modellen var på plats och fungerade i verktyget väcktes frågan kring om data skulle kunna samlas in samtidigt som verktyget användes. Det krävdes en initial modell för att verktyget skulle gå att använda i över huvud taget och därefter väcktes ytterligare frågeställningar kring hur insamlingen av data kunde fortskrida. Det alternativet som sågs var att implementera en lösning som sam- lade in information kring vilken komponent som valdes att generaras som resultat av den skissen som skapats. På så sätt skulle insamlingen av data ske automatiskt så länge verktyget användes. För det här projektet ansågs dock den data som samlades in med det separata gränssnittet som tillräcklig och en automatiserad insamling av data implementerades aldrig. Totalt samlades 446 skisser in fördelat över 22 komponenter, vilket motsvarar cirka 20 skisser per komponent. Varje skiss är en 28x28 pixel stor matris.

4.2.4

Salvador AI

Ett förmänskligande av automationen har implementerats i form av en agent som kommu- nicerar med användaren. Agenten har valts att kallas Salvador Ai och karaktäriseras av en grön färg i gränssnittet. När förslagen från automationen presenteras kommunicerar Salva-

4.2. Prototypverktyg med automationsstöd dor genom en kommentar ovanför förslagen. Kommunikationsstilen har valts till att vara trevlig i enlighet med de rekommendationer som finns kring design av förmänskligande av automation, se kapitel 2.5.3.1.

Ingen figur för Salvador har tagits fram utan han representeras endast av text i gränssnittet. Att förtydliga genom att använda sig av en figur av Salvador ihop med kommentarerna är något som inte implementerats. Det valdes bort till fördel för annat förbättringsarbete då en version inför användartesterna skulle färdigställas. Framtagandet av en figur ansågs vara tidskrävande och risken att det skulle påverka testresultatet på oönskade sätt ledde fram till det beslutet. Med det menas att formgivningen av figuren skulle kunna påverka användarens intryck av automationen baserat på användarens bakgrund och på så sätt skapa variationer under användartesterna baserat på detta. Eftersom användartesterna är fokuserade på att testa skillnader hos tre olika interaktionsmodeller hade variationer beroende på användarens uppfattning av figuren för Salvador kunnat ha oönskade effekter på testresultaten.

4.2.5

Träna CNN modell

Klassificering av handritade komponenter görs av ett CNN som tränas på insamlad tränings- data. Arkitekturen på nätverket som har valts kan ses i Bilaga C. Nätverket har en förhållan- devis enkel arkitektur jämfört med många av de stora nätverk som används vid bildigen- känning, vilket bör innebära att det kan tränas med mindre träningsdata jämfört med mer komplexa nätverk. Arkitekturen till nätverket hittades i ett exempel som klassificerar hand- skrivna siffror från MNIST-datasetet som är en liknande klassificeringsuppgift. Efter att mo- dellen hade tränats på träningsdatan klassificerade den 93.18% av valideringsdatan korrekt.

4.2.6

Ta fram förslag

När användare skissar en komponent skapas en bild från skissen med rätt dimensioner, 28x28 pixlar, som sedan på något sätt ska klassificeras med modellen som tränats. Då finns det två olika alternativ när det kommer till att använda den för att klassificera skisser i verktyget. När användare skissar en komponent skapas en bild från skissen med rätt dimensioner, 28x28 pixlar, som sedan ska klassificeras med modellen som tränats.

En metod är att med hjälp av moderna JavaScript-bibliotek göra klassificeringen direkt i webbläsaren. Då använder verktyget inte någon back-end för klassificering utan allt sker direkt i klienten. Det för med sig flera fördelar då inga nätverksanrop behövs göras vid till- fället då förslag ska tas fram. En nackdel med att modellen laddas hem till alla som använder verktyget är att den inte kan döljas och skyddas. Ett alternativ till att göra klassificeringen i webbläsaren är att flytta ut klassificeringen till en server som klienten sedan gör anrop till. Fördelen med det är att klienten inte behöver ladda ner modellen. Det är en fördel eftersom modeller för klassificering av innehåll i bilder kan vara relativt stora, upp mot 50MB och större.

Modellen som används i verktyget har en relativt enkel arkitektur, vilket bidrar till att den innehåller lite information. Modellens filstorlek är mindre än de stora modeller som används i andra klassificeringsuppgifter och att ladda modellen i klienten går fort. För att ta hänsyn till användare som vill hålla användningen av mobildata nere kunde en dialog implementeras där användaren innan verktyget kan börja användas tillfrågas angående om bandbredd får användas till att ladda ner modellen. Det har inte implementerats eftersom verktyget under projektets gång endast är tänkt att användas i en testmiljö av personer med förståelse för verktyget.

4.2. Prototypverktyg med automationsstöd klienten med biblioteket KerasJS som är en avskalad version av Python-biblioteket Keras implementerat i JavaScript som innehåller funktioner för att klassificera med hjälp av en fär- digtränad modell. Med KerasJS kunde sedan modellen användas för att klassificera skisser direkt i webbläsaren och på så sätt krävs ingen back-end för att använda verktyget, allt sker direkt i webbläsaren.