En annan erfarenhet gruppen fick var att det var en bra ide att använda sig av muntlig kommunikation så mycket som möjligt, med till exempel Discord, istället för skriftlig kom- munikation när gruppmedlemmarna befann sig på olika platser. Det gjorde det mycket lättare att diskutera olika idéer, förslag och lösningar utan att missförstå varandra. Däremot att sitta tillsammans med hela gruppen på samma plats fungerade helt klart bäst och gav det effektivaste arbetet.
Ett råd till nästa års studenter är att lägga stor vikt vid kravspecifikationen. Att ha en tydlig och väl genomtänkt kravspecifikation gjorde att gruppen visste vad som skulle gö- ras och vad som kunden förväntade sig av programmet. Tyvärr framgick det vid slutet av projektet att det fanns funktioner som kunden inte hade nämnt när kravspecifationen togs fram men som ändå önskades i programmet. Att få kunden att tänka igenom hur den vill ha produkten och att få fram så konkreta och korrekta krav som möjligt kommer att förenkla utvecklingsprocessen. Dessutom bör detta leda till en nöjdare kund.
Ett till råd till nästa års studenter är att få tillgång till en referensgrupp tidigt i projektet, framför allt om programmet kräver en användarcentrerad design. Gruppen fick inte tag på en full referensgrupp föränn programmet var färdigt. Då uppdagades det okända krav och önskemål, från de faktiska slutanvändarna, som varken gruppen eller kunden var medvetna om. Att vara frågvis och duktigt tolka de tankar som kunden har är därför inte nog om kun- den själv inte har hela sanningen. Detta är något som givetvis kan ligga utanför gruppens påverkan, men en lärdom likväl om hur det kan gå.
5.6
Översikt över individuella bidrag
Detta delkapitel behandlar samtliga gruppmedlemmars individuella bidrag.
A. En spelmotors påverkan på ett projekt som vårt av Martin Jirenius
Tidigt i projektet var gruppen tvungen att välja mellan om de skulle göra en egen 3D-motor för programmet eller om en befintligt skulle användas. I det här individuella bidraget kom- mer fördelarna med en egen 3D-motor jämfört med en befintlig motor att studeras. I resultatet redogörs huruvida gruppen anser vad som hade passat det här projektet genom en under- sökning och under diskussionen kommer man försöka dra slutsatser utifrån svaren.
B. En jämförelse mellan 3D-spelmotorerna Unity 3D och Unreal Engine 4 av Arin
Rashid
I ett projekt som detta där det varit mycket diskussioner huruvida vi ska använda Unity 3D eller Unreal Engine 4 kände jag att det vore intressant att jämföra dessa två spelmotorer för att se om någon faktiskt är bättre och om vi valde rätt.
C. Lärstilar och Learn-by-doing av Jacob Olausson
Detta projekt krävde att de gruppmedlemmar som saknade erfarenhet av programmet Unity 3D var tvungna att snabbt lära sig hur programmet kunde användas för att utveckla nya avancerade program. Här använde sig gruppen av olika metoder, men de flesta utgick från metoden Learn-By-Doing. Detta fick mig att undra, är det lämpligt att alla gruppmedlemmar använder samma metod för att lära sig? och vilka missgynnas av tidspressen som finns i projektet och varför?
D. Hur kan ikoner användas i ett program för att öka förståelsen? av Johan
Fallström
Här undersöks och jämförs ikoner som visuellt redskap med användandet av text. Avsnittet innehåller även en kort historisk beskrivning av några vanliga ikoner, då sett till mjukvara.
E. En jämförelse mellan olika Git-arbetsflöden av Simon Gustavsson
I detta avsnitt följer en jämförelse mellan olika populära Git-arbetsflöden och en undersök- ning om arbetsflödet som användes i projektet var optimalt eller om ett annat arbetsflöde borde ha valts.
F. Hur kan 3D-rekonstruktioner påverka rättsprocesser och forensik av Viktor
Barr
Efter terrordådet på Drottninggatan 2017 konstruerades en 3D-rekonstruktion som visade hur händelseförloppet gick till för att visas i rättegången. Teknik för att scanna in hela brotts- platser till ett virtuellt 3D-rum finns och har använts i rättegångar. I detta delkapitel under- söks hur 3D-rekonstruktioner av brottsfall kan påverka brottsbekämpning och rättsprocesser.
G. Blender och MakeHuman i ett projekt av Yohan Ayoub
I detta avsnitt diskuteras vilket 3D-modelleringsprogram som är optimalt för detta projekt. För- och nackdelar med de olika programmen diskuteras och jämförs.
6
Diskussion
I detta kapitel diskuteras och analyseras de olika delarna av rapporten.
6.1
Resultat
Nedan följer en analys av resultatet från projektet.
6.1.1
Användarvänlighet
Varje designbeslut som tagits har i någon mån utgått från dess användarvänlighet. Gräver vi lite i de tankar och diskussioner som utformat programmet så blir detta väldigt tydligt. De flesta designbeslut som beskrivs nedan finns också beskrivna i det designmanifest som använts som referensmaterial under projektets gång (Se Bilaga I).
Färgval
Programmet använder huvudsakligen 3 färger: ljusgrå, mörkgrå och blå. Den vitaste och den svartaste färgen undveks då dessa färger varierar starkt beroende på vilken skärm som programmet visas på. De står dock i god kontrast mot varandra, så att programmets menye- lement tydligt ska synas om det visas upp med projektor. Mörkgrå är den dominanta färgen då ett mörkt färgtema är bekvämare för ögonen och bättre lämpar sig för att användas under längre perioder. Den blå färgen valdes då det också står i god kontrast mot de andra färgerna och för att blått ger ett lugnt men seriöst intryck.
Förutom dessa huvudfärger så användes tre till i mindre utsträckning: röd, grön och beige. Röd används för alla element som tar bort något, och grön används för alla element som lägger till något. Röd och grön är komplementfärger och de används ofta som motpoler (tänk på trafikljus, som ett allmänt exempel). Den beige färgen används endast till knappen för att öppna ett projekt, som föreställer en pappersmapp. Detta för att pappersmappar ofta är tillverkade av oblekt papper.
Formval
Figur 6.1:Exempel på tidig knappdesign.
I början av projektet så gick vi efter ett annat formspråk på programmet. Då var fokus på att knappar skulle efterlikna fysiska knappar, i det att de skulle se ut som en upphöjd yta som kunde tryckas ned (Se: Figur 6.1). Vi lämnade dock denna design senare i arbetet, och gick istället för en mer modern design som lånar inspiration från den aktuella versionen av operativsystemet Windows (Se: Figur 6.2). Här är formspråket rektangulärt, med undantag för reglagebanor och enskilda knappar. Helfärger används genomgående i programmet, och eventuella övergångar är diskreta förutom när sidomenyn visas/döljs.
Knappar kommer i två utföranden: textknappar och ikoner. Textknapparna är rektanglar som varierar sin bredd efter innehållet, som är en textsträng. Den innehållande texten be- rättar då vad knappen är till för, och knappens färg styrker, om det är möjligt, detta syfte. Ett exempel är knappen DELETE i skadevyn som har en röd bakgrund då den tar bort den nuvarande skadan. Ikoner används istället där det råder konventioner för vad en sådan ikon betyder. Det tydligaste exemplet återfinnes i filhanteringsknapparna, som föreställer ett pap- persark (med ett tillagt grönt plus efter önskan av kunden), en diskett och en pappersmapp. Dessa är ikoner som kan återfinnas i program sedan den tid när disketter fortfarande var den dominanta lagringsenheten. Till höger om dessa ikoner finns det två knappar som också försöker förmedla sitt syfte genom metaforer. Knappen för inställningar har en ikon som föreställer en skiftyckel för att beskriva korrigering och inställning. Knappen för hjälp är i form av ett frågetecken. Detta för att förmedla att det är dit användaren kan vända sig om något känns oklart med programmet. Något som är gemensamt för alla knappar är att de lyses upp om användaren håller muspekaren över dem, och blir mörkare om de trycks ned. Detta för att förstärka visuellt för användaren att knapparna svarar på dess interaktion.
6.1. Resultat
Figur 6.2:Exempel på aktuell knappdesign.
Det finns också menyelement som kan aktiveras och avaktiveras. Detta gäller navigerings- pilar för skade- och bildlistan samt för kryssrutor. Navigeringspilar berättar för användaren att de går att använda om de är blå, medan de är mörkgrå om de är avstängda. Kryssrutor är istället blå om de är valda och mörkgrå när de inte är det.
Skadelistan har gått igenom en del revideringar under projektet. Till en början skissades den som en radlista i menyn till vänster, då listor ofta går uppifrån och ned. Detta byttes i sinom tid ut till en horisontell lista som är placerad vid skärmens nedre kant. Detta beslut togs av två anledningar: dels för att menyn behövde rymma andra element, dels för att en horisontell lista efterliknar en tidslinje, vilket förstärker att skadorna bildar ett händelseför- lopp.
Programflöde
Programflödet är format för att erbjuda användaren ett fåtal menyelement åt gången. Detta för att motverka att användaren ska känna sig överrumplad med för många alternativ. Pre- senteras de istället i etapper så blir det lättare för användaren att lära sig vad varje element gör, och det välkomnar användaren till att själv utforska programmets funktioner. Program- met är uppdelat i fyra särskilda vyer, som alla erbjuder en viss typ av funktionalitet. Detta gör det lätt för användaren att få en överblicksbild om var denne kan finna en önskad funk- tionalitet. Dessa vyer presenteras också för användaren i utförandeordning: för att kunna presentera skador så behöver skador ha satts ut. För att ha något att sätta ut skadorna på så måste karaktären ha skapats, och för att kunna skapa en karaktär så måste ett projekt ha skapats eller valts.
Tidigare i programutvecklingen så tillhandahölls vyerna för användaren på ett annorlunda sätt. Startvyn existerade inte, utan användaren togs istället till en tom 3D-rymd där endast den övre sidomenyn fanns presenterad. Efter att ha skapat ett projekt så visades det sedan tre knappar vid skärmens nedre kant, där alla ledde till en av de kvarvarande vyerna (Se Figur 6.3). Då var tanken att det skulle vara lätt att intuitivt navigera mellan vyerna, samt att det då skulle gå att ändra på karaktären även efter att skador satts ut. Denna design avskaffades av flera anledningar:
• Till en början övergavs idéen om att kunna återvända till karaktärsvyn relativt tidigt. Det hade varit svårt att implementera, då skadorna hade behövts följa med när använ- daren antingen ändrade på en karaktär eller bytte ut den helt. Slutanvändaren skulle inte ha ett behov att behöva ändra på kroppen när den väl börjat sätta ut skador.
• En annan annan anledning att lämna designen var för att knapparna hade behövt kon- kurrera med skadelistan om skärmutrymme. En tanke var att presentera knapparna där presentationsknappen sitter nu, men då hade dess centrala funktion för program- met inte framgått lika bra. Att sätta dem mitt i nedre kant var just för att förstärka hur viktiga de var.
• Det var också svårt att hitta en god design till knapparna. Ikoner testades men det var inte intuitivt ens för gruppmedlemmarna vad de representerade. Även textknappar testades, men då tog de istället för mycket plats. Av dessa orsaker valdes till sist det nuvarande flödet mellan vyerna, och gruppmedlemmarna upplever själva att det var ett klokt beslut.
Figur 6.3:Tidig designskiss.
Verktygsutformning
De verktyg och funktionaliteter som programmet erbjuder är i en form som ska vara enkel att använda. Det innebär ofta att en del funktionalitet begränsats eller rentav hoppats över för att stärka användarvänligheten. Under gruppens spånande av vad programmet ska innehålla så fick vi ofta stanna upp och fråga oss själva om en funktion stärkte användarvänligheten eller endast var en bekvämlighet för den datorvane.
Ett sådant exempel är hur kameran styrs i programmet. I nuläget finns det två sätt: di- rekt med musen eller med kameraknapparna i programmet. Musstyrningen efterliknar det styrningssätt som vi i gruppen känner igen från liknande program som använder en 3D-vy. Det är en konvention som vi är bekväma med, då vi stött på den förut. Vi insåg dock att det inte är en självklarhet att slutanvändaren är lika van med denna styrning, så därför lade vi in kameraknappar i programmet. Med hjälp av att interagera med dessa knappar så kan användaren styra kameran lika exakt som denne hade kunnat göra med musen, men skillnaden är att dessa presenteras tydligare för användaren och fungerar rent interaktivt på samma sätt som övriga knappar i programmet.
Vi funderade även på att ha en låd-zoom i programmet. Det innebär att användaren mar- kerar en area på skärmen, och att då programmet zoomar så att denna area fyller skärmen. I slutändan så skippade vi denna funktion, just för att den inte bidrar med någon nytta för slutanvändaren som inte övrig kamerastyrning redan fyller. Det fanns också risk att använ-
6.1. Resultat
daren kunde ha blivit förvirrad av funktionen, om den plötsligt zoomar in när det inte var en avsiktlig handling.
Hjälpmedel
En del verktyg tillhandahålles för användaren för att ytterligare underlätta användandet. Som ovan nämnt så har programmet kameraknappar för att underlätta styrningen av kame- ran, men det är inte den enda anpassningen som gjorts. En funktionalitet som också stärker användarvänligheten är de textsträngar som dyker upp när användaren interagerar med de flesta element i programmet. Dessa strängar ger en kort förklaring på vad användaren pekar på, och hur det kan användas. Det blir således som en aktiv användarmanual, som alltid kan ge tips om programmets användning. Skulle användaren fortfarande känna sig förvirrad, eller ha funderingar om hur en funktion ska användas, så kan denne klicka på hjälpknappen uppe till vänster. Då öppnas det en komplett guide till hur programmet används, tillsam- mans med ett par frågor och svar.
En annan funktion, som lätt tas för givet, är implementationen av varningsrutor. Varje interaktion som gör en större påverkan på projektet, som att något tas bort eller att karak- tärsskapandevyn lämnas, öppnar en varningsruta. Varningsrutan agerar mellanled mellan den önskade handlingen och själva utförandet, och är till för att garantera att dess påverkan är önskvärt.
Arbetet med att garantera användarvänlighet är både utförligt och genomtänkt. Genom att alltid ha det på tapeten så är det få designbeslut som inte fått gro ur detta ledord, och för- hoppningsvis leder det till ett program som de flesta kan använda!
6.1.2
Systemanatomi
Den resulterande systemanatomin har få likheter med den initiala skissen. Detta beror på den okunskap om Unity som samtliga medlemmar hade. Att då lägga fram en hypotetisk anatomi som skiljer sig avsevärt från hur Unity är strukturerat, gjorde att den blev överflödig. Den anatomi som används nu baseras istället på rådande konventioner, men också löst på den designskiss som tidigt togs fram.
6.1.3
Värde för kund
Hur vet vi att kunden kommer att använda programmet, och hur vet vi att det används som det var avsett? Det vet vi inte. Från start hade vi stora krav på användarvänlighet, funk- tionalitet och etik, och det går inte att garantera att vi bemött dessa till fullo. Det kanske framkommer om en månad att programvaran utger en säkerhetsrisk, eller att den saknar en funktion som kunden själv hade glömt. I sådana fall kanske programmet vidareutvecklas el- ler lämnas helt. Skulle också programmet vidareutvecklas så kommer kunden förmodligen behöva betala licenskostnader till Unity, då programmet då ägs av ett företag som drar in ett betydande kapital [82].
6.1.4
Egen kommentar
Gruppen känner sig generellt nöjda med programmet. Dock så kunde inte alla krav med högsta prioritet utföras i tid, så vissa kompromisser behövde göras. Gruppmedlemmarna var eniga om att detta berodde på att tid som troddes kunde användas till utveckling behövde läggas på att skriva dokument, skapa/utföra presentationer, oppositioner o.s.v.