5.2 Prototypen
5.2.8 Inställningar
Figur 16: Stödkontakt
Från startsidan är det tänkt att användaren vid behov ska kunna ändra inställningarna för den tänkta applikationen från inställningssidan, vilken nås från ”kugghjuls-ikonen” längst ner till hö-ger på startsidan. Härifrån kan användaren stänga av eller sätta på GPS-spårningen, stänga av eller sätta på att stödkontakten blir meddelad vid återfall, byta stödkontakt, byta stödgrupp, redigera kontaktuppgifter, redigera mål och fördelar, lägga till eller ta bort riskzoner och ändra svaren på missbruksförfrågan. Om användaren klickar på ”byt stödgrupp” så synliggörs ett var-ningsfönster, vilket förklarar vad effekten blir om hen fortsätter och frågor om hen vill fortsätta. Detta för att användaren inte av misstag skulle råka byta stödgrupp. För att komma tillbaka till startsidan kan användaren klicka på ”bakåtpilen” eller ”hus-ikonen” och vid behov av extra instruktioner kan hen klicka på ”frågetecken-ikonen”.
(a) Inställningar, byt stödkon-taktförfrågan
(b) Inställningar, redigera kon-taktuppgifter
(c) Inställningar, redigera framsteg och mål
Figur 17
Om användaren skulle vilja byta stödkontakt, så kan hen klicka på ”byt stödkontakt” från inställ-ningssidan. Då kommer användaren till en sida där hen kan fylla i kontaktuppgifter till den nya tänkta kontaktpersonen. Användaren behöver inte fylla i alla uppgifter, enbart e-postadressen är obligatorisk, men kommunikationsmöjligheterna kan bli begränsad om någon uppgift rörande stödkontakten saknas. När de uppgifter som användaren vill ange är ifyllda så kan hen klicka på ”Skicka förfrågan”, då är det tänkt att en förfrågan ska skickas till den angivna e-postadressen och när/om personen ifråga svarat på förfrågan så blir denna person användarens nya stödkontakt. När den tänkta stödpersonen svarar på förfrågan så är det även tänkt att denna ska få möjlighet att se över uppgifterna användaren angivit, ändra på felaktiga uppgifter och lägga till information som saknas. Skulle användaren vara i behov av att byta stödkontakt utan att ha någon person tillgänglig för den uppgiften så kan hen klicka på knappen ”Ny stödperson från stödgruppen”. Då är det tänkt att en förfrågan ska skickas till en av medlemmarna i användarens stödgrupp. Om den medlemmen skulle avböja skickas en ny förfrågan till en annan medlem i stödgruppen. Detta ska fortgå tills antingen alla medlemmar avböjt eller någon medlem accepterar. Om alla medlemmar i användarens stödgrupp avböjer så ska detta meddelas till användaren och fråga om hen vill leta efter en stödkontakt i en annan stödgrupp eller om hen vill avbryta och då anting-en avstå från att ha anting-en stödkontakt eller ha kvar sin tidigare stödkontakt. Om användaranting-en vill uppdatera sina kontaktuppgifter så kan hen klicka på knappen ”Redigera kontaktuppgifter” och kommer då till en sida där hen kan genomföra detta. Om användaren vill uppdatera målen och fördelarna som hen förhoppningsvis satte upp första gången den tänkta applikationen startades så kan detta genomföras genom att klicka på knappen ”Redigera mål och fördelar” från inställ-ningssidan. Härifrån kan användaren se mål och fördelarna hen satte upp, första målet och dess fördelar är markerat med en ”soptunna-ikon” bredvid målet och ”brutna kedjor-ikoner” bredvid fördelarna. Användaren kan markera ett annat mål genom att klicka på den. ”Soptunna-ikonen” ska ta bort målet som ikonen hör ihop med och fördelarna som bara är länkade till det målet.
’Brutna kedjor-ikonerna” ska ta bort länken mellan det markerade målet och den aktuella förde-len, om en fördel inte är länkat till något mål så ska den försvinna. Målen har unika index och fördelarna har samma index som målen den är länkad till, är en fördel länkad till flera mål har den flera index. Skulle användaren vilja lägga till ett nytt mål så kan användaren klicka på ”nytt mål” och ska då få möjligheten att skriva namnet på det nya målet och sedan välja vilka fördelar som detta mål ska ha. Antingen genom att välja en fördel som redan är uppsatta genom att mar-kera den eller/och lägga till en ny fördel till den nya målet genom att klicka på ”Ny fördel”. På alla sidor kan användaren få ytterligare instruktioner genom att klicka på ”frågetecken-ikonen”. När användaren vill komma tillbaka till inställningssidan så kan hen klicka på ”bakåtpilen” eller om användaren vill komma tillbaka till startsidan kan hen klicka på ”hus-ikonen”.
(a) Inställningar, riskzoner (b) Inställningar, förfrågan
Figur 18
Användaren ska kunna lägga till eller ta bort riskzoner som hen satte upp första gången den tänkta applikationen startades från inställningarna. Riskzoner är platser som användaren asso-cierar med droganvändande och skulle användaren närma sig en sådan plats så är det tänkt att applikationen ska varna användaren och avråda hen från att fortsätta för att förhoppningsvis undvika att drogsuget blir för intensivt. Användaren ska kunna navigera runt på kartan genom att dra med fingret åt det hållet hen vill styra kartan och genom att nypa eller dra isär fingrarna för att zooma in och ut på kartan. Om användaren vill ta bort en markering så är det tänkt att hen ska hålla fingret under 2 sekunder på markeringen så ska den markeringen tas bort. Vill användaren lägga till en markering så ska hen kunna klicka på området på kartan som ska
markeras och sedan nyper eller drar isär fingrarna för att kunna ändra storlek på den aktuella markeringen. Förfrågningen rörande missbruksproblematiken som användaren besvarade första gången applikationen startades, ska kunna ändras från inställningssidan genom att klicka på ”Svar på förfrågningen”. Skulle användaren ändra på svaren och sedan vilja ha en ny stödgrupp baserat på det nya svaren kan hen klicka på ”Byt stödgrupp” från inställningssidan. Båda dessa sidor har tillgång till hjälpfunktioner som aktiveras genom att användaren klicka på ”frågetecken-ikonen”. När användaren vill lämna någon av dessa sidor kan hen klicka på ”bakåtpilen” för att komma tillbaka till inställningssidan eller genom att klicka på ”hus-ikonen” för att komma tillbaka till startsidan.
Listing 1: Ett urklipp av koden från prototypsidan Start, Mål och fördelar som tydliggör hur prototypens kod är uppbygg i grunden och visar hur gränssnitten som skapades i Adobe XD är sammankopplade. <!DOCTYPE html> <html> <head> <style> .img { position: absolute; z-index: 1; display: block; margin-left: auto; margin-right: auto; } * * * .radioboxdiv { position: absolute; z-index: 2; overflow: hidden; white-space: nowrap;
font-family: ’Segoe UI’, Tahoma, Geneva, Verdana, sans-serif
֒→ ; margin-left: 50%; margin-right: 50%; left: -166px; top: 105px; } .checkboxdiv { position: absolute; z-index: 2; overflow: hidden; white-space: nowrap;
font-family: ’Segoe UI’, Tahoma, Geneva, Verdana, sans-serif
֒→ ;
margin-left: 50%; margin-right: 50%; left: 9px;
top: 104px; } * * * </style> </head> <body> * * *
<div style="display: flex; justify-content: center;">
<img
src="../../../Skiss/XD/drawable-mdpi/Start-mal-och-֒→ fordelar-ingen-text.png" class="img" usemap="buttons"> <map id="buttons" name="buttons">
<area shape="rect" coords="136, 337, 224, 362" href="#" name
֒→ ="addArea" id="addArea" alt="" onclick="addAnswer()"> <area shape="rect" coords="136, 602, 224, 627" href="../Meny
֒→ .html"/>
<area shape="rect" coords="311, 595, 350, 640" href="#" name
֒→ ="helpArea" id="helpArea" alt="" item="helpToggler"
֒→ onclick="addHelp()">
</map>
<form action="#" class="radioboxdiv" id="radiobox">
<input type="radio" name="radiobox" value="mal1" id="mal1">M
֒→ ål 1<br>
<input type="radio" name="radiobox" value="mal2" id="mal2">M
֒→ ål 2<br>
<input type="radio" name="radiobox" value="mal3" id="mal3">M
֒→ ål 2<br>
<input type="radio" name="radiobox" value="nyttmal" id="
֒→ nyttmal">Nytt mål<br> </form>
<form action="#" class="checkboxdiv" id="checkbox">
<input type="checkbox" name="checkbox" value="fordel1" id="
֒→ fordel1">Fördel 1<br>
<input type="checkbox" name="checkbox" value="fordel2" id="
֒→ fordel2">Fördel 2<br>
<input type="checkbox" name="checkbox" value="fordel3" id="
֒→ fordel3">Fördel 3<br>
<input type="checkbox" name="checkbox" value="fordel4" id="
֒→ fordel4">Fördel 4<br>
<input type="checkbox" name="checkbox" value="fordel5" id="
֒→ fordel5">Fördel 5<br>
<input type="checkbox" name="checkbox" value="nyfordel" id="
֒→ nyfordel">Ny fördel<br> </form>
* *
</div> </body>
Listing 2: Urklipp av HTML/CSS-koden från prototypsidan Start, Mål och fördelar som tydliggör hur hjälpfunktionen är implementerad med hjälp av HTML/CSS.
<!DOCTYPE html> <html> <head> <style> .img { position: absolute; z-index: 1; display: block; margin-left: auto; margin-right: auto; } .help { position: relative; display: block; margin-left: auto; margin-right: auto; z-index: 3; } .helpdiv { display: none; } * * * </style> </head> <body> <script type="text/javascript"> * * * function addHelp() {
var div = document.getElementById("helpToggler"); if (div.style.display === "none") { div.style.display = "block"; } else { div.style.display = "none"; } }
* * *
</script>
<div style="display: flex; justify-content: center;">
<img
src="../../../Skiss/XD/drawable-mdpi/Start-mal-och-֒→ fordelar-ingen-text.png" class="img" usemap="buttons"> <map id="buttons" name="buttons">
<area shape="rect" coords="136, 337, 224, 362" href="#" name
֒→ ="addArea" id="addArea" alt="" onclick="addAnswer()"> <area shape="rect" coords="136, 602, 224, 627" href="../Meny
֒→ .html"/>
<area shape="rect" coords="311, 595, 350, 640" href="#" name
֒→ ="helpArea" id="helpArea" alt="" item="helpToggler"
֒→ onclick="addHelp()">
</map>
* * *
<div class="helpdiv" id="helpToggler">
<img
src="../../../Skiss/XD/drawable-mdpi/Start-mal-och-֒→ fordelar-hjalp.png" class="help" onclick="addHelp()
֒→ "> </div>
</div> </body>
Listing 3: Exempel av HTML/CSS-koden från prototypsidan riskzonessidan som tydliggör hur ett av skripten i JavaScript och canvans är uppbyggda. I detta fall möjliggör skriptet att användaren kan placera ut markeringar på en karta, vilka ska representera riskzonerna som användaren ska undvika. Två markeringar är redan utmarkerad för att illustrera hur den aktuella sidan kan se ut. <!DOCTYPE html> <html> <head> <style> .img { position: absolute; z-index: 1; display: block; margin-left: auto; margin-right: auto; } .canvasdiv{ position: absolute; background-image: url("../../../Bilder/googlemaps,screenshot ֒→ .png"); z-index: 2;
margin-left: 50%; margin-right: 50%; left: -188px; top: 67px; } * * * </style> </head> <body> * * *
<div style="display: flex; justify-content: center;">
<img src="../../../Skiss/XD/drawable-mdpi/Riskzoner-ingen-karta
֒→ .png" usemap="buttons" class="img"> <map name="buttons">
<area shape="rect" coords="311, 10, 351, 50" href="../Meny.
֒→ html">
<area shape="rect" coords="10, 590, 60, 640" href="
֒→ Installningar.html">
<area shape="rect" coords="311, 595, 350, 640" href="#" name
֒→ ="helpArea" id="helpArea" alt="" item="helpToggler"
֒→ onclick="addHelp()">
</map>
<div class="canvasdiv">
<canvas id="canvas" width="368" height="525" onclick="draw(
֒→ event)"> </canvas> <script>
var canvas = document.getElementById("canvas"); var context = canvas.getContext("2d");
context.strokeStyle = "#FF0000"; context.beginPath(); context.arc(160,390,30,0,2*Math.PI); context.stroke(); context.beginPath(); context.arc(274,120,10,0,2*Math.PI); context.stroke(); function draw(event) {
var pos = getMousePos(canvas, event); posx = pos.x;
posy = pos.y;
context.strokeStyle = "#FF0000"; context.beginPath();
context.arc(posx, posy, 20,0,2*Math.PI); context.stroke();
}
function getMousePos(canvas, event) {
var rect = canvas.getBoundingClientRect(); return { x: event.clientX - rect.left, y: event.clientY - rect.top }; } </script> </div> * * * </div> </body>
6 Analys
Användartestning av personer i rätt målgrupp har inte varit möjligt att genomföra på grund av problem med lagstiftningen, vilket har medfört svårigheter när det kommer till att kvalitétesta arbetet. Så en slutsats rörande resultatet av arbetet har genomförts delvis genom att proto-typen och resultatet av efterforskningarna har analyserats utifrån syftet och delvis genom att prototypen har testat av personer som inte ingår i målgruppen och av ämnesgranskaren. Test-ningen gav ingen direkt information om prototypen skulle kunna underlätta nykterhetsprocessen eftersom ingen av personerna som testade prototypen lider av missbruksproblematik, men det gav viss inblick angående resultatet av designvalen, vilket överlag var positiva. De utomståen-de personernas respons av applikationen var dock tvivelaktig på grund av bristanutomståen-de kunskap inom mjukvarudesign och på grund av den sannolika skillnaden mellan dessa personers erfaren-het med mobila applikationer och den tänkta målgruppens erfarenerfaren-het av mobila applikationer. Ämnesgranskarens respons var betydligt mer givande och gav större insikt i kopplingen mellan människa-datorinteraktion och prototypen och denna respons används som ledning under hela arbetet.
Designens åskådlighet skulle bestå av lugna färger som kompletterar varandra, färgblindhet skulle tas med i beaktning, ikoner och bilder skulle användas sparsamt och applikationens funk-tioner skulle vara tillgängliga från samma plats och vara väl synliga. Detta för att undvika att trigga drogsug, öka tillgängligheten och för att undvika att användandet av den tänkta appli-kationen blir frustrerande. Utifrån analysen av prototypen och responsen från testningen så har detta mål uppfyllts. Huvudfärgerna i prototypen är av olika nyanser av blått vilka kan anses vara lugna färger. Grönt och rött har undvikits till stor del för att underlätta för personer som lider av färgblindhet, vilket oftast påverkar den drabbade personens förmåga att urskilja dessa färger. I det få fall där grönt och rött ändå har behövs användas på grund av dessa färgers associationer till att vara redo (grönt) och icke redo (rött) har ytterligare skuggning används för att personer drabbade av färgblindhet ändå ska kunna urskilja dessa objekt. Endast ett fåtal bilder skapade av utomstående har använts som ikoner i det fall där det verkligen har behövs och där de för-hoppningsvis endast kompletterar applikationen. Alla bilder som har använts har licenser som åtminstone tillåter användning i icke-kommersiella syften. I de allra flesta fall har dock egenska-pade ikoner och gränssnitt används. Från menyn får användaren tillgång till alla huvudfunktioner i applikationen. Funktioner tänkta att användas under stressfyllda situationer är placerade högst upp och funktionerna som är tänk att användas under lugnare stunder är placerade längre ned på menyn med ett mellanrum mellan dessa två typer av funktioner. Rapiditeten i prototypen har beaktats för att applikationen ska kunna användas under hög stresspåverkan. Applikationen behöver därmed vara snabbnavigerad, vilket har uppfyllts genom att dels ha alla huvudfunk-tioner tillgängliga från startsidan. Användaren måste även kunna ta sig tillbaka till startsidan med endast ett knapptryck från alla sidor genom att klicka på ”hus-ikonen”. Att meddela återfall är lätt att genomför eftersom detta kan genomföras från startsidan. Knappen som används till detta är avskiljt från resten av knapparna från menyn och är placerad längst ner på menyn. Designen är lättöverskådlig för att snabbt kunna navigeras. Knappar som används på flera sidor, som t ex ”bakåt-knappen”, är placerad på samma position. Detta för att öka igenkännligheten och därigenom även rapiditeten. För att öka tillgängligheten av applikationen var det viktigt att applikationen skulle vara lättförståeligt. Designen har skapats med åtanke att målgruppen är en heterogen grupp, bestående av olika utbildningsnivåer, ålder, kön, etcetera. Så beskrivningen på knappar och övrig text är skapat med enkla ordval. Designen är uppbyggt med en enkel, klas-sisk design och förutsätter inte att användaren har använt sig av mobila applikationer tidigare. Varje sida har lättillgängliga hjälpfunktioner som aktiverar informationsrutor med enkla förkla-ringar om den aktuella sidan och dess funktion, för att förhoppningsvis råda bot på eventuella
oklarheter.
Funktionerna har endast implementerats i prototypen till den grad att det är väl förståeligt vad som ska implementeras i den framtida applikationen och hur funktionerna ska användas. Så en analys av funktionaliteten har bitvis varit svår att genomföra, men funktionerna som utarbetades under efterforskningen har utvärderats av handledaren av arbetet, vilken har stor kunskap inom ämnet missbruksproblematik. Enligt honom bör funktionerna uppnå syftet med arbetet och med tanke på att funktionera bygger på tidigare forskning inom området så existerar redan belägg för att funktionerna bör uppnå syftet med arbetet. En större analys av funktionerna rekommenderas därför att genomföras när en första version av applikationen är färdigställd för att kunna säkerställa kvalitén av funktionerna, med tanke på att de inte har testas. Det bör tilläggas att på grund av oklarhet kring funktionernas duglighet bör därför funktionerna implementeras modulärt i applikationen. Detta underlättar modifikationer och tillägg av funktionerna, om det framkommer att någon funktion behöver modifieras eller om det skulle visa sig att någon funktion saknas.
7 Slutsats
7.1 Begränsningar i arbetet
Möjligheten att utforma egna teorier och utifrån dessa skapa prototypen, implementera inter-aktiva funktioner och att testa prototypen var under arbetets gång extremt begränsat. Inget eget material fick skapas om det inte byggde fullt ut på redan tidigare publicerat material. Så alla tänkta funktioner i prototypen bygger på just detta. Något som efterliknar en fungerande applikation fick inte utvecklas, utan endast en prototyp till en applikationen med begränsad inter-aktionsmöjlighet. Detta eftersom medicintekniska produkter bland annat måste uppfylla följande kriterier[24]:
• Produkten ska ha adekvata funktioner som stödjer den avsedda användningen.
• Patientens säkerhet ska beaktas i riskhanteringsprocessen.
• Tillverkaren ska visa att produktens prestanda verkligen uppfyller det medicinska syftet, t.ex. genom en utvärdering.
• Produkten ska CE-märkas.
Vad som anses vara en medicinteknisk produkt är en produkt som uppfyller någon av följande kriterium[24]:
• Påvisa, förebygga, övervaka, behandla eller lindra en sjukdom.
• Påvisa, övervaka, behandla, lindra eller kompensera en skada eller en funktionsnedsättning.
• Undersöka, ändra eller ersätta anatomin eller en fysiologisk process, eller kontrollera be-fruktning.
Så om en applikation hade utvecklats istället för en prototyp hade den klassificeras som en me-dicinteknisk produkt, vilket hade givit konsekvensen att kriterierna ovan hade behövas uppfyllas och kravet på CE-märkning hade inte hunnits genomföras inom tiden för detta arbete.
Testning av prototypen på en korrekt målgrupp kunde inte verkställas utan att en etikpröv-ning skulle behövas genomföras på grund av lagen om etikprövetikpröv-ning, paragraf 3 och 4[33]. Det är lagen beskriver vilka arbeten som måste genomföra en etikprövning innan det kan genomföras. En etikprövning hade inte varit möjlig att genomföra inom tidsbegränsningen för detta arbete. 3 § Träder i kraft I:2019-01-01/ Denna lag ska tillämpas på forskning som inne-fattar behandling av
1. personuppgifter som avses i artikel 9.1 i EU:s dataskyddsförordning (känsliga personupp-gifter), eller
2. personuppgifter om lagöverträdelser som innefattar brott, domar i brottmål, straffproces-suella tvångsmedel eller administrativa frihetsberövanden. Lag (2018:1999).
4 § Utöver vad som följer av 3 § ska lagen tillämpas på forskning som 1. innebär ett fysiskt ingrepp på en forskningsperson,
2. utförs enligt en metod som syftar till att påverka forskningspersonen fysiskt eller psykiskt eller som innebär en uppenbar risk att skada forskningspersonen fysiskt eller psykiskt,
3. avser studier på biologiskt material som har tagits från en levande människa och kan härledas till denna människa,
4. innebär ett fysiskt ingrepp på en avliden människa, eller
5. avser studier på biologiskt material som har tagits för medicinskt ändamål från en avliden människa och kan härledas till denna människa. Lag (2008:192)
Utöver etikprövningslagen så skulle testningen även medföra problem med General Data Protec-tion RegulaProtec-tion (GDPR)10, vilken är lagen som bland annat reglerar personuppgiftslagring inom Europeiska unionen. Detta eftersom testpersonernas data skulle behöva lagras för att möjliggöra