Användbarhet av chatbotar i medelstora företag

Linköpings universitet

Linköpings universitet | Institutionen för datavetenskap

Examensarbete på grundnivå, 16hp | Datateknik

2020 | LIU-IDA/LITH-EX-G--20/074--SE

Användbarhet av chatbotar i

medelstora företag

Usefulness of Chatbots in Medium-sized Companies

Elise Anderson

Isabelle Strömsrud

Handledare : Erik Berglund Examinator : Sahand Sadjadee

Upphovsrätt

Detta dokument hålls tillgängligt på Internet - eller dess framtida ersättare - under 25 år från publice-ringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopi-or för enskilt bruk och att använda det oförändrat för ickekommersiell fkopi-orskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan använd-ning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsman-nens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/.

Copyright

The publishers will keep this document online on the Internet - or its possible replacement - for a period of 25 years starting from the date of publication barring exceptional circumstances.

The online availability of the document implies permanent permission for anyone to read, to down-load, or to print out single copies for his/hers own use and to use it unchanged for non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional upon the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedu-res for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.

© Elise Anderson Isabelle Strömsrud

Sammanfattning

Combitech håller på att utveckla ett eget intranät och undersöker om det är möjligt att implementera en bot som hanterar enkla uppgifter för att förenkla vardagen för sina medarbetare. Denna rapport undersöker om en chatbot som hanterar bokningen av möten kan vara användbar för företaget. Efter implementering av chatboten och testning med hjälp av 5 medarbetare blev slutsatsen att en chatbot för mötesbokning inte är särskilt användbar för företaget. Däremot var alla testare väldigt positiva till att ha en chatbot i intranätet om den implementeras för att hantera mer tidskrävande eller komplicerade uppgifter.

Combitech is aiming to develop their own intraweb and they are investigating if it is possible to implement a bot that handles menial task to make daily tasks easier on their employees. This thesis investigates whether a chatbot which handles the booking of me-etings will be useful to the company. After implementing the chatbot and testing it with 5 employees the conclusion was made that a chatbot for meetings was not very useful. However, the testers were very positive about having a chatbot on the intraweb if it is implemented for tasks which are timely or complicated to solve.

Författarens tack

Vi vill börja med att ge ett stort tack till Combitech som dels gav oss uppdraget och som varit tålmodiga i att vänta på resultatet. Vi vill även rikta ett stort tack till våra opponenter Lucas Carlberg och Olivia Shamon.

Innehåll

1.3 Syfte och Frågeställning . . . 2

1.4 Avgränsningar . . . 2

2 Teori 3 2.1 Outlook för företag . . . 3

2.2 Botar . . . 5

2.3 Azure . . . 6

2.3.1 Azure Bot Service . . . 6

2.4 OAuth 2.0 . . . 6

2.5 Microsoft Graph . . . 7

2.6 Natural Language Processing . . . 7

2.6.1 LUIS . . . 7

2.7 Microsoft Visual Studio Community 2019 . . . 7

2.8 SDK . . . 8

2.8.1 Bot Framework v4 . . . 8

2.9 Bot Framework Emulator . . . 9

2.10 Ngrok . . . 10

2.11 Användarvänlighet . . . 10

2.12 Relaterat Arbete . . . 11

3 Metod 13 3.1 Installation och utvecklingsverktyg . . . 13

3.2 Implementation . . . 14

3.2.1 LUIS konfiguration . . . 14

3.2.2 Main Dialog . . . 15

3.2.3 Booking Dialog . . . 15

3.2.4 MeetingTime Dialog . . . 15

3.2.5 Cancel and Help Dialog . . . 15

3.2.6 Logout Dialog . . . 15

3.4 Utvärdering . . . 16 4 Resultat 17 4.1 Implementation . . . 17 4.1.1 Uppstart . . . 17 4.1.2 Boka möte . . . 18 4.1.3 Hitta mötestider . . . 21 4.2 Testning . . . 23 4.3 Utvärdering . . . 24

5 Diskussion och Analys 25 5.1 Resultat . . . 25 5.1.1 Implementation . . . 25 5.1.2 Testning . . . 26 5.1.3 Förbättringsförslag . . . 26 5.1.4 Övergripande kommentarer . . . 28 5.2 Metod . . . 29 5.2.1 Replikerbarhet . . . 30 6 Slutsatser 31 6.1 Slutsats . . . 31

6.2 Arbetet i en bredare kontext . . . 31

6.3 Framtida arbete . . . 32

Litteratur 33 A Appendix 36 A.1 Appendix1 . . . 36

Figurer

2.1 Skapa en mötesbokning i Outlook genom att klicka på ”New Items” . . . 3

2.2 Skapa en mötesbokning i Outlook genom att klicka på önskad mötesdag . . . 4

2.3 Välja tid och datum för möte samt bjuda in mötesdeltagare i Outlook . . . 4

2.4 ”Room Finder” hjälper användaren att hitta lediga mötesrum . . . 5

2.5 Översikt över Dialogs . . . 9

4.1 Startdialog med boten . . . 18

4.2 Bokningsdialog där all information ges direkt . . . 18

4.3 Dialog för bokning av möte . . . 19

4.4 Bekräftelse av mötesbokning . . . 19

4.5 Kontroll och bekräftelse av bokning . . . 20

4.6 Konversation då mötet inte går att boka . . . 21

4.7 Försök att hitta mötestid med en medarbetare . . . 21

4.8 Dialog för att hitta ledig tid och bokning av möte . . . 22

4.9 Kontroll och bekräftelse av bokning . . . 22

5.1 Föslag på utskrift för instruktioner för att minska risken att skriva på fel format . . 27

Tabeller

2.1 Befintliga mallar för botar i Bot Framework v4 . . . 8 3.1 Tabell över alla paket som installerades i Visual Studio . . . 14 4.1 Tabell över entiteter och fraser som LUIS kopplar till intentioner . . . 17 4.2 Hur långt tid det tog för de olika personerna att skapa ett möte med boten och i

Outlook . . . 23 A.1 Lista över färdiga botar i Bot Framework SDK v4 samt deras funktion . . . 36

1

Introduktion

De flesta människor äger idag en smartphone där de har appar som kan starta uppvärmning av bilen, larma huset, prata med läkare och alla möjliga olika saker. Effektivitet är något som är viktigt för många. Saker ska gå snabbt och ska vara enkelt att göra. I takt med att hem-sidor och appar växer måste även företagen bibehålla samma tillväxt inom kundnöjdheten. En hemsida eller app måste idag ha kundservice dygnet runt som alltid levererar service i världsklass. Det är här botar kommer in, med funktioner som exempelvis bokning av flygre-sor, biljettköp till evenemang eller bara för att svara på frågor kan företag bibehålla en hög standard samtidigt som de kan fokusera på sin huvuduppgift.

En vanlig sorts app som många har och är bekväma med att använda är chat-appar som Facebooks Messenger, Kik, WhatsApp, Slack m.fl. Ett resultat av detta är att chatbotar växt mer och mer då människor är vana vid textkommunikation och samtal i korta meningar. På 60-talet, när en av de tidigaste chatbotarna kom, var inte detta fallet och det är en anledning till varför chatbotar inte blivit stora förrän nu. En av de tidigaste chatbotarna heter Eliza och kom på 60-talet. Den använde enkel mönster matchning för att efterlikna en psykoterapeuts konversationsstil. Succén av Eliza gjorde att ett stort intresse att skapa chat-botar som kunde klara Turing testet1_{startades. En mindre lyckad chat-bot var Clippy som kom med Microsoft}

Office 1997-2003. Clippy var inte alls omtyckt och var mer ett störmoment än hjälp. Trots detta är basen av användargränssnittet i Clippy väldigt likt det som används i dagens chatbotar. [1]

Trots succén med många chatbotar finns det fortfarande mycket svårigheter med att skapa en väl fungerande chatbot. Ett bra och naturligt språk är en av de viktigaste egenskaperna hos en chatbot för att användare ska tycka att en bot är bra men det är också en av de svåraste sakerna att implementera. För att en användare ska vilja använda en bot behöver den prata på ett naturligt sätt, alltså inte robotlikt, men samtidigt inte vara för personlig så att användaren har svårt att få hjälp från boten. [2]

1.1

Bakgrund

Combitech är ett teknikkonsultbolag som är en oberoende del av Saab-koncernen. Företaget är baserat i Norden men arbetar även med företag internationellt. Företaget har cirka 1900

1.2. Motivering

anställda och finns i flera städer i Sverige, Norge, Finland och Danmark. De är verksamma inom teknik, miljö och säkerhet.

Combitech utvecklar och implementerar för tillfället en Office 365-plattform (Combinet) där de är intresserade av att skapa en bot som kan hjälpa deras anställda.

1.2

Motivering

I dagsläget använder sig Combitech av Saabs intranät där säkerheten är mycket hög. Eftersom att Combitech inte behöver en lika hög säkerhetsnivå håller de på att utveckla och implemen-tera ett eget intranät, Combinet, som baseras på Microsofts Office365. De funderar på om en bot skulle kunna vara till hjälp i deras system. Systemet för mötesbokning som finns nu är krångligt då en bokning måste skapas för att få svar om ett rum är ledigt för mötestiden och om rummet skulle vara upptaget måste en ny bokning skapas. Målet är att en bot ska göra det enklare att hitta lediga mötesrum och skapa en bokning direkt i Microsoft Teams vilket är deras främsta verktyg för kommunikation inom företaget. Långsiktigt skall detta kunna byggas ut till att innefatta automatisering av flera delar i systemet.

1.3

Syfte och Frågeställning

Syftet med detta projekt är att undersöka om en bot skulle effektivisera processen av att bo-ka rum och om boten skulle vara användbar för Combitech att implementera i sitt system Combinet. Frågeställningarna som arbetet utgår från är följande:

1. Underlättar en bot det dagliga arbetet för tjänstemän på ett medelstort företag? a) Är det mer tidseffektivt att använda en bot för att skapa en mötesbokning än att

skapa en mötesbokning i ett system utan en bot?

b) Är det enklare att skapa en mötesbokning med en bot än i ett system utan en bot?

1.4

Avgränsningar

Combinet är baserat på Office365 och därför kommer endast Microsofts egna funktioner för skapande av botar att användas. Boten är även skapad för att kunna fungera i Microsoft Teams även om den går att anpassa för att få den att fungera i andra applikationer. Boten är utvecklad för att fungera i en Windows-baserad miljö då det är vad Combitech använ-der idag. Då LUIS (Language Unanvän-derstanding Intelligent Service för tillfället inte stödjer svenska som språk kommer boten endast att kunna svara och förstå engelska.2Frågeställningen kan ses som väldigt bred, därför togs ett beslut att implementera en funktion som medarbetarna använder flitigt idag då det representerar en uppgift som de flesta medarbetarna gör varje dag. Boten kommer därför att behandla mötesbokningar med andra personer inom organi-sationen. Fokus kommer att ligga på att testa och utvärdera användarvänligheten hos boten eftersom att ett användarvänligt system är oftast det som användarna föredrar.

2

Teori

Detta kapitel presenterar relevant teori för att förstå hur en bot skapas med Microsofts olika verktyg. Även teori för att kunna svara på frågeställningen presenteras.

2.1

Outlook för företag

Som en del av Microsoft 365 erbjuds en företagsversion av Outlook som låter organisationen att samla mail, kontakter och kalendern på ett och samma ställe. Att boka ett möte i Outlook sker i flera steg. Det kan ske antingen genom att dubbelklicka på önskad dag i kalendern eller genom att klicka på ”New Item” följt av ”Appointment” eller ”Meeting” vilket illustreras i figur 2.1 samt figur 2.2

2.1. Outlook för företag

Figur 2.2: Skapa en mötesbokning i Outlook genom att klicka på önskad mötesdag

Därefter kan startdatum, starttid, slutdatum samt sluttid skrivas in. För att bjuda in per-soner i mötet kan mailadresser skrivas in manuellt eller så kan ”Address Book”, adressboken, öppnas genom att klicka på ”Invite Attendees”. I adressboken går det att söka efter personer inom organisationen. Det går även att skicka med en mötestitel och en beskrivning av vad mötet skall handla om.

Figur 2.3: Välja tid och datum för möte samt bjuda in mötesdeltagare i Outlook

Via ”Room Finder” går det att hitta lediga mötesrum och det går att få hjälp med att se vilka tider mötet inte går att ha på grund av att de andra inbjudna skulle vara upptagna.

2.2. Botar

Figur 2.4: ”Room Finder” hjälper användaren att hitta lediga mötesrum

När mötet är skickat får de inbjudna en inbjudan som de kan acceptera eller neka. Sva-ret de ger skickas till mötesinbjudaren. Mötesrummet ligger som en egen ”deltagare” och samma princip gäller där, om rummet är ledigt skickas ett mail där rummet accepterar bok-ningen eller om rummet är bokat nekar rummet bokbok-ningen. När deltagarna accepterar eller nekar bokningen kan de skicka med ett svar där de exempelvis förklarar varför de nekar eller om de önskar att lägga till eller ändra någonting i mötet. Då kan mötesansvarige skicka en uppdaterad kallelse till samtliga deltagare.

2.2

Botar

En generell beskrivning av en bot är ett program som skapats för att automatiskt genomföra uppgifter. För att kommunicera med en bot går det att använda tal, text eller grafik beroende på implementering. Det finns flera olika sorters botar, en vanlig sort är chatbotar. En chat-bot är en maskin som fungerar som ett användargränssnitt till data och tjänster genom att använda text eller tal. Ordet chatbot kommer från chat robots.[2] En chatbot kan exempelvis ha funktionen att boka en flygresa eller hitta biljetter till en konsert, meningen med en sådan är då att förenkla. En interaktion mellan en människa och en bot skapar en aktivitet. Varje aktivitet hanteras sedan av en turn handler som kallar på varje individuell activity handler för den specifika aktiviteten.1

1

2.3. Azure

En undersökning av varför personer använder chatbotar gjordes 2017 av P.B. Brandtzaeg och A. Fölstad. I deras undersökning svarade 146 personer i åldrarna 16-55 på varför de an-vänder chatbotar. Resultatet visade att det fanns fyra huvudanledningar vilka var; produkti-vitet, underhållning, socialt/relation och nyfikenhet där produktivitet var det mest frekventa svaret. Enligt undersökningen använde de flesta chatbotar för att det går snabbt och det är enkelt. [3]

B. Abu-Shawar och E. Atwell gjorde en undersökning om chatbotar är användbara. Un-dersökningen gjordes på fyra olika användningsområden; underhållning, verktyg för språ-kinlärning, informationshämtning och assistenter för e-handel. Slutsatsen de kom fram till var att chatbotar bör skapas för att hjälpa människor som ett verktyg eller hjälp vid interak-tion med datorer men inte ersätta människan. [4]

2.3

Azure

Microsoft Azure är en molnbaserad applikationsplattform som tillhandahåller olika typer av programvara utvecklade av Microsoft. Azure använder ett specialutveckat operativsystem kallat Windows Azure som möjliggör utveckling och körning av applikationer på en och sam-ma plats. Utöver AI-tjänsterna Azure Bot Service och LUIS erbjuds tjänster inom Blockchain, DevOps, Databaser och nätverkslösningar.2

2.3.1

Azure Bot Service

Azure Bot Service stödjer skapandet och implementationen av botar i C#, Javascript och Pyt-hon. När en bot är skapad lokalt går det att publicera den i Azure och koppla den till oli-ka applioli-kationer som Microsoft Teams, Slack och Facebook. Det går även att testa boten i ”WebChat” som är en integrerad testmiljö för boten. När en bot publiceras skapas tre olika resurser: Web App Bot där en bot deployas till en Azure App Service, App Service där det går att bygga och hosta applikationer samt en App Service Plan där resurser skapas för att köra applikationer.3

2.4

OAuth 2.0

OAuth skapades för att användare ska kunna dela information ifrån en service till en annan utan att behöva lämna ut sina inloggningsuppgifter. Ett exempel skulle vara att importera alla kontakter från ett Gmail konto till ett Facebook konto. Istället för att användare ska ge sina uppgifter till Facebook kan OAuth istället användas för att skicka förfrågningar och till-gångstokens. Det enda användaren behöver göra är att skapa en förfrågan om att importera kontakterna och godkänna att Facebook får tillgång, sedan ska kontakterna börja importeras. [5]

OAuth är en standard för autentisering där OAuth loggar in med en API-nyckel och en secret. Användaren kommunicerar med sin identitets leverantör, identity provider, som genere-rar ett krypterat token som skickas vidare till applikationen för autentisering. Applikationen har innan fått info om att denna identitetsleveratören är en godkänd leverantör. Om använ-daren exempelvis tillhör en organisation som använder Office 365, är Microsoft identity pro-vider. OAuth kan även användas för att ge en användaren information om vilken personlig information en applikation vill ha tillgång till utan att behöva ange lösenorddirekt till appli-kationen.4

2_{https://azure.microsoft.com/en-us/services/}

3

https://docs.microsoft.com/sv-se/azure/bot-service/bot-builder-tutorial-basic-deploy?view=azure-bot-service-4.0&tabs=csharp#deploy-your-bot

2.5. Microsoft Graph

2.5

Microsoft Graph

Microsoft Graph är en modell som används för att få tillgång till och använda data i Office365 och samtidigt bibehålla säkerheten, detta genom att alltid kolla att en användare har rätt au-tentisiering. Applikationer kan få tillgång till användarens kalender, kontakter, mail, filer och anteckningar. På detta sätt går det att få tillgång till kalendern för en användare och det går då också att kolla om användaren är ledig en viss tid och skapa en bokning som syns i kalen-dern utan att ha direkt tillgång till användares kalendrar.5För att kunna använda MS Graph krävs det att appen som vill ha tillgång till informationen har rättigheter att göra det. När en applikation begär tillgång till datan måste den skicka med en autentiseringstoken som appli-kationen fått av en Microsoft identitetsleveratör för att säkerställa att användaren godkänt att dennes data tillgängliggörs. Bara den datan användaren godkänt att applikationen använder kan kommas åt via MS Graph.6

2.6

Natural Language Processing

Natural Language Processing (NLP) är en form av artificiell intelligens som hjälper datorer att förstå mänskligt språk. På grund av komplexiteten som finns i språk är detta en svår upp-gift. För att kunna förstå språk använder NLP algoritmer som kan extrahera och identifiera språkregler på ett sätt så att data kan konverteras till en form datorer kan förstå. Datorerna kan sen genom syntax- och semantik-analys få fram betydelsen av varje mening. [6]

Att exempelvis få hjälp med ett billån hos en bank skulle vara enkelt inom natural langu-age (NL) genom att kunden söker efter information om billån och systemet kan då svara med alternativ för ansökan om lån, existerande lån eller gamla lån och gå vidare utifrån det. Skul-le en kund istälSkul-let vilja ha råd om investeringar och vill veta vilka företag som mest troligt kommer slås ihop inom en snar framtid så blir det mycket mer komplicerat för NL system att hjälpa med detta då då fraser som ’troligt’ och ’snar framtid’ är väldigt svåra att tolka. [7]

2.6.1

LUIS

LUIS (Language Understanding Intelligent Service) är en molnbaserad API-tjänst från Micro-soft som förstår konversationsspråk. LUIS ger utvecklare som inte har kunskaper inom ma-skininlärning möjligheten att ändå kunna skapa applikationer med mama-skininlärning. Tidigare har alternativen för maskininlärning varit handgjorda modeller, vilka är enkla att skapa men svåra utöka, eller maskininlärnings modeller, vilka är enkla att utöka men kräver mycket kunskaper. Genom att använda LUIS kan en utvecklare skapa intentioner och entiteter som kan användas för att tolka ett uttryck. Skulle exempelvis ett gym vilja ha maskininlärning kan en intention vara StartaAktivitet med entiteten AktivitetsTyp. Om en användare då sä-ger uttrycket ’Börja springa’ ska LUIS kunna identifiera att det är intentionen StartaAktivitet med AktivitetsTyp ’springa’. Genom att skapa olika exempelfraser och använda inlärnings-funktionen kommer LUIS blir mer och mer precis. LUIS sätter även poäng på olika yttranden och föreslår utefter det vilken intention eller entitet som passar. [8]

2.7

Microsoft Visual Studio Community 2019

Visual Studio Community 2019 är en gratis IDE, Integrated Development Enviroment, som vänds för att skapa applikationer, molntjänster eller webbapplikationer. Visual Studio kan an-vändas för att utveckla applikationer till alla plattformar och har tillgång till tusentals tillägg. Genom att använda Visual Studio går det att designa, redigera och debugga i ett och samma verktyg.7Visual Studio använder NuGet paket som är färdig kod och funktioner skrivna av

5_{https://docs.microsoft.com/en-us/graph/overview} 6_{https://docs.microsoft.com/en-us/graph/auth-v2-user} 7_{https://visualstudio.microsoft.com/vs/community/}

2.8. SDK

andra som distribueras som paket. Detta gör att utvecklare inte behöver implementera funk-tioner som redan finns färdiga. Utvecklare kan då installera ett NuGet paket i sitt projekt och kalla på dessa funktioner utan att behöva definiera och skapa dem själv.8

2.8

SDK

SDKer, Software Development Kit, finns för att förenkla skapandet av applikationer genom att verktyg för mjukvaruutveckling finns samlade i ett installerbart paket. Dessa är ofta platt-formsspecifika och krävs för att kunna utveckla en applikation i ett visst operativsystem eller på en viss plattform. En SDK kan innehålla färdigbyggda mallar, kod för att testa applikatio-nen och även dokumentation för att enkelt kunna hitta information om SDKn.9

2.8.1

Bot Framework v4

Bot Framework SDK v4 är ett open source SDK från Microsoft som ger utvecklare möjlighet att utveckla och bygga botar som interagerar med användare på ett naturligt sätt. I detta ram-verk finns det hjälpram-verktyg inkluderade för att bygga, testa och ansluta botar med användare.

10 _{Bot Framework v4 innehåller mallar för redan färdiga botar som antingen kan användas}

som de är eller modifieras efter eget tycke. I tabell 2.1 nedan presenteras de olika mallarna som finns tillgängliga, vad de gör samt när de lämpar sig att användas:

Tabell 2.1: Befintliga mallar för botar i Bot Framework v411

Mall Beskrivning Användning

Echo Bot En simpel bot som skickar tillbaka det användaren matar in.

Lämplig för nybörjare inom Bot Framework v4 och vill börja med en minimal och simpel mall.

Core Bot Den mest avancerade mallen då den innehåller 6 redan färdiga funktioner som de flesta botar be-höver.

Lämplig för personer som är nå-gorlunda vana vid att använda Bot Framework v4.

Core Bot with Tests Samma som Core Bot men innehål-ler även kompletta tester för att visa hur Bot Framework Testing fram-ework kan användas.

Lämplig för personer som är nå-gorlunda vana vid att använda Bot Framework v4 och vill testa ytterli-gare funktionalitet i ramverket. Empty Bot Endast ett tomt skal för att kunna

anpassa boten efter eget tycke.

Lämplig för personer som är va-na att skapa botar inom Bot Fram-ework v4.

Dialogs, är en central del i Bot Framework v4 från Microsoft. Dialoger är nödvändigt för att boten ska kunna föra en sammanhängande konversation. Det finns olika typer av dia-loger definierade i Dialogs-biblioteket, se figur 2.5.12 Waterfall är en typ av dialog som kan användas i botar för att skapa en konversation. Genom att ha vattenfallssteg kan boten föra vidare konversationen till nästa steg när den fått respons från användaren. Denna funktionen är bra att använda när boten behöver samla information från användaren då den alltid sparar informationen i varje steg för att kunna användas i nästkommande steg i konversationen.13 Prompts är en dialogtyp som används för att fråga användaren om information och hantera

8_{https://docs.microsoft.com/en-us/nuget/what-is-nuget} 9_{https://en.wikipedia.org/wiki/Software_development_kit} 10_{https://github.com/microsoft/botframework#Bot-Framework-SDK-v4} 11_{https://marketplace.visualstudio.com/items?itemName=BotBuilder.botbuilderv4} 12_{https://docs.microsoft.com/en-us/azure/bot-service/bot-builder-concept-dialog?view=azure-bot-service-4.0} 13 https://docs.microsoft.com/en-us/azure/bot-service/bot-builder-dialog-manage-conversation-flow?view=azure-bot-service-4.0&tabs=csharp

2.9. Bot Framework Emulator

svaret. Det finns flera typer av prompts: text, nummer, datum och tid, bekräftelse, val och attachment. Varje typ kräver att användaren matar in rätt typ. Detta är en två-stegs konver-sation då boten vill ha en typ av input och beroende på vad som anges returnerar boten en valid-flagga att svaret godkännes eller så gör den en re-promt där den ber om ett nytt svar då datatypen var felaktig.

Figur 2.5: Översikt över Dialogs14

I Bot Framework v4 finns även UIs, User Interfaces, i form av Cards som är som har knap-par för att gå vidare i en konversation med en bot. Meningen är att de ska förenkla använd-ningen av en bot genom att ge användaren olika val. Cards gör det även enklare att imple-mentera boten då användaren endast kan välja mellan att visst antal alternativ istället för att skriva vad som helst i fritext.

Bot Framework v4 innehåller även redan färdiga botar som har simpel funktionalitet med en eller flera basfunktioner implementerade. Det finns exempelvis botar med funktionalitet för Microsoft Teams, som är integrerade med LUIS, som använder sig av cards eller vatten-fallsdialoger.15Dessa botar finns beskrivna i appendix A.1.

2.9

Bot Framework Emulator

Bot Framework Emulator är ett program som tillåter utvecklare att testa botar lokalt på da-torn utan att de behöver vara konfigurerade för publicering eller redan vara publicerade. I emulatorn går det att chatta med boten samt att det går att se datan som överförs mellan användaren och boten.16 _{Bot Framework Emulator är utvecklat av Microsoft och stödjer}

an-vändandet av Bot Framework SDK samt erbjuder möjligheten att konfigurera så att LUIS kan användas.17 14_{https://docs.microsoft.com/en-us/azure/bot-service/bot-builder-concept-dialog?view=azure-bot-service-4.0} 15_{https://github.com/microsoft/BotBuilder-Samples/tree/master/samples/csharp_dotnetcore/} 16 https://docs.microsoft.com/en-us/azure/bot-service/bot-service-debug-emulator?view=azure-bot-service-4.0&tabs=csharp 17_{https://github.com/Microsoft/BotFramework-Emulator/wiki}

2.10. Ngrok

2.10

Ngrok

Ngrok är en plattformsoberoende applikation som hjälper utvecklare att testa system eller ap-plikationer på ett säkert sätt under utvecklingen. Om Bot Framework Emulator används på en dator med brandvägg krävs det att ett tunnlingsverktyg för att kapsla in information och skicka det säkert över internet. Bot Framework Emulator är integrerat att använda ngrok som är ett exempel på ett tunnlingsverktyg. Det används genom att verktyget skapar en tunnel mellan datorn, genom brandväggen, till utsidan. Detta möjliggör att kunna testa applikatio-nen utan att behöva publicera den och göra den offentlig.18

2.11

Användarvänlighet

Det finns två aspekter av användarvänlighet enligt Eric Reiss, en fysisk och en psykologisk. Den fysiska aspekten innebär att programmet faktiskt gör det den ska och den psykologiska aspekten innebär att programmet gör det användaren förväntar sig att den ska göra. Detta innebär att programmet inte endast ska utföra uppgiften korrekt utan även tillhandahålla en trevlig upplevelse för användaren. De fysiska parametrarna i ett program handlar om knappar, kommandon och annat som användaren interagerar med som gör program lättare att använda. Reiss presenterar fem punkter att tänka på:

• Funktionalitet: Saker måste funka. Ett knapptryck skall generera önskad respons och en länk ska skicka vidare användaren till rätt sida. Instruktioner skall vara skrivna på ett sådant sätt att när användaren följer dem till punkt och pricka, skall programmet inte klaga.

• Mottaglighet: Användaren vet och kan vara säker på att saker funkar. Programmet ger användaren relevant feedback på sina handlingar.

• Ergonomi: Saker ska vara lätta att identifiera. Viktigare knappar bör vara större då de blir lättare att skilja från mindre knappar som bör ha en mindre viktig funktion. • Lättillgänglighet: Knappar och liknande skall vara placerade så att det är logiskt för

användaren. Vad som är lättillgängligt för en programmerare är inte alltid detsamma för slutanvändaren. En användare ska inte behöva göra ett extra steg för att det under lättar för programmeraren eller liknande.

• Idiotsäkerhet: Användaren skall kunna klicka på saker utan att förstöra allt. Exempel-vis skickar textediteringsprogram ut varningar när en användare försöker stänga doku-mentet om denne inte sparat filen. Formulär där användare ska fylla i personnummer han ha föreslaget format ifyllt som sedan försvinner när personer matar in sitt person-nummer.

När det kommer till det psykologiska i att göra någonting användarvänligt och behagligt att använda fokuserar Reiss återigen på fem punkter:

• Visibilitet: Saker och ting går att identifiera och se. Knappar och informationstext som en användare behöver för att kunna slutföra en uppgift finns väl synligt.

• Begriplighet: Användaren begriper vad denne ser och läser samt förstår hur det fun-kar. Förkortningar eller språk som är företagsspecifikt bör undvikas för att inte förvirra användaren.

• Logik: Det användaren ser och blir ombedd att göra är logiskt. Användaren ska inte behöva fundera på varför något ska göras eller hur det ska göras. Logiken bakom och anledningen skall vara tydlig för användaren.

2.12. Relaterat Arbete

• Konsekvent: Reglerna för hur något skall göra ändras inte mitt i. Två knappar som gör olika saker bör skilja i utseende medan två knappar som gör samma sak bör ha samma utseende för att inte förvirra användaren.

• Förutsägbarhet: När användaren gör något är nästa steg förutsägbart. Instruktioner bör vara händelsebaserade så användaren inte måste läsa igenom en hel manual innan denne startar.

Dessa två listor överlappar många gånger eftersom att de fysiska parametrarna måste vara uppfyllda för att de psykologiska aspekterna skall kunna uppfyllas. Skulle funktionaliteten exempelvis vara bristfällig finns det risk för att programmet inte är konsekvent eller förut-sägbart. [9]

Användarvänlighet är svårt att mäta då känslor och upplevelser är individuella och ing-en människa upplever saker på samma sätt som andra. Enligt Nielsing-en, J. kan användbarhet definieras enligt 5 punkter:

• Inlärning: Hur enkelt det är att lära sig grundläggande funktionalitet när de kommer i kontakt med designen första gången?

• Effektivitet: När användare har lärt sig designen, hur snabbt kan de lära sig att utföra nya saker?

• Minnesvärdhet: Om användaren kommer tillbaka efter en tids uppehåll, hur snabbt kan de komma igång igen?

• Fel: Hur många fel gör användare, hur grova är felen och hur lätt är det för användaren att fixa till felet?

• Nöjdhet: Hur nöjd är användaren med designen?

Det finns flertalet metoder för att studera användbarhet men det viktigaste är att välja test-personer som väl representerar den typiska användaren. Dessa ska sedan utföra en, för designen, representativ uppgift utan att få hjälp eller direktiv. Resultaten skall observeras och dokumenteras och testarna skall själva få diskutera hur dessa upplevde designen utan att testledarna lägger sig i och påverkar upplevelsen. Det viktigaste Nielsen påpekar är att det är viktigt att låta testarna lösa problem på egen hand utan att ge dem direktiv, annars kan testresultaten bli missvisande.[10]

Att utvärdera en testpersons upplevelser är inte alltid lätt. Dumas et al. föreslår att i slu-tet av ett användarvänlighetstest ställa öppna frågor av karaktären ”Beskriv tre saker som var bra och dåliga med det du testade” eller ”Beskriv vad du fann lätt eller svårt med att använda programmet” då dessa ger mer värdefulla insikter och kommentarer i hur an-vändarvänligt någonting var. Frågor som ”Har du något att tillägga?” tenderar att avsluta sessionen då svaret ofta blir nej. Som svar på de öppna frågorna tenderar testarna att svara med funktionalitet snarare än användarvänlighet. Det blir då viktigt att guida personen att ge rätt svar utan att påverka dennes omdöme genom följdfrågor. Om testpersonen svarade ”Jag tyckte om att man kunde skapa formulär” kan en följdfråga vara ”Var det enkelt eller svårt att skapa formulären?” och göra det tydligt att det är användarvänligheten som är i fokus. [11]

2.12

Relaterat Arbete

Sandberg, M. et al. undersökte i sitt examensarbete om det finns någon bakomliggande in-telligens i Microsofts Bot Framework. Syftet med arbetet var att undersöka hurvida en bot kan hantera språkliga varianser hos en användare. Detta undersöktes genom att sätta upp en

2.12. Relaterat Arbete

kunskapsbas i QnA Maker utan att manuellt lära in rätt svar på frågor. [12] Studien visade på att det inte kunde påvisas att Microsoft Bot Framework hade någon intelligens gällande stavfel, synonymer eller känslofraser. Detta innebär med största sannolikhet att det inte finns någon intelligens i QnA Maker givet att QnA Maker inte lärs av en utomstående att tolka frågorna.

P.B. Brandtzaeg et al. [3] förklarar att majoriteten av dagens chatbotar misslyckas i att uppfylla användarens behov. Trots det är de implementerade i många plattformar. Chatbotar kräver mycket kunskap om användarens motiv till att använda chatbotar för att kunna im-plementeras rätt. P.B. Brandtzaeg och A. Følstad kommer fram till att mycket mer forskning inom området krävs innan en definitiv slutsats kan dras. Det studien tyder på är dock att det är viktigt för användarna att boten effektiviserar arbetet och gör det lättare.

Bot-utvecklare står inför ett par frågor som de måste besvara innan de designar och ut-vecklar boten[2]. Ska boten vara man, kvinna eller könsneutral? Hur vänlig ska boten va-ra? Hur människolik ska boten vava-ra? Utvecklare måste tänka på hur boten kan komma att missbrukas och vad användare kan komma att använda som input. Men allt eftersom att chatbotarna ökar i antal måste utvecklare ta hänsyn till vad användarnas behov är.

I [13] diskuterar Shum, H.Y. et al. designprinciperna som måste tas i beaktning när sociala chatbotar utvecklas. Vikten av att både intelligenskvot(IQ) och emotionellkvot(EQ) finns med påvisas exempelvis då en användare ställer frågan ”Vad har Kina för area?” där boten genom IQ vet att svaret är 9.6 miljoner kvadratkilometer men för användarvänligheten vill svara på ett mer mänskligt sätt och då med sin EQ svarar ”Arean är 9.6 miljoner kvadratkilometer, vilket är ungefär samma storlek som USA.” Skulle boten bara svarat med siffrorna skulle den inte tillgodose det emotionella behovet hos användaren.

Cameron G. et al. undersöker hur botar kan användas som stöd för personer som lider av psykiska problem. iHelpr [14] utvecklades, med hjälp av botframework och LUIS, för att per-soner skall kunna göra ett självtest där boten är programmerad att hjälpa inom områden som depression, ångest, sömn, självkänsla och stress. Personerna får svara på frågor med hjälp av knappar och fritext där personens problem graderas enligt en skala och slutligen samman-ställs resultatet och olika åtgärdsalternativ presenteras. Om personen bedöms behöva hjälp presenteras nummer och annan kontaktinformation till lämplig institution. Cameron G. et al. utvärderade programmet med hjälp av testare som jobbade med mental hälsa. Metoden för testningen baserades på frågor skapade av Chatbottest.com samt ett SUS, System Usabili-ty Scale, som anpassades för att passa boten. Resultatet visade på att det fanns områden där boten presterade bättre än andra. Områden där boten presterade mindre bra var felhantering samt botens förmåga att förstå vad användaren svarade i fritext. Slutligen konstateras det att LUIS har en begränsning när det gäller felhantering av ord och att ett externt stavningspro-gram bör användas samt att möjligheten att använda sig av fler språk kan vara önskvärt.

3

Metod

Detta kapitel presenterar metoden som användes för att implementera boten samt metoden för att testa och utvärdera den.

3.1

Installation och utvecklingsverktyg

Vissa av verktygen som användes var rekommenderade av Combitech och andra verktyg valdes för att de var kompatibla med Microsofts egna tjänster och plattformar. All kodning gjordes i Visual Studio Community 2019 version 16.3. Denna utvecklingsmiljö valdes då den är skapad för att utvecklare ska kunna koda, testa och distribuera program på ett och samma ställe. Dessutom är det den utvecklingsmiljön som anställda på Combitech använder sig av i det dagliga arbetet. Visual Studios är skapat av Microsoft och är därmed kompatibel med alla deras tjänster. NuGet paketen som installerades i Visual Studio finns beskrivna i tabell 3.1. För att kunna testa boten lokalt installerades Bot Framework Emulator version 4.6.0. Därefter lad-dades ngrok ner och konfigurerades med emulatorn. När allt var installerat konfigurerades boten i Azure med Microsoft Graph så att den kunde komma åt Combitech anställdas ka-lendrar. Därefter sattes LUIS upp och tränades med entiteter och exempelfraser för att boten skulle kunna känna igen olika varianter av uttryck som användare kunde tänkas använda.

3.2. Implementation

Tabell 3.1: Tabell över alla paket som installerades i Visual Studio

Paket Användning

Microsoft.Graph Tillåter att information hämtas eller

skickas till Office 365 Azure AD och andra Microsoft tjänster

Microsoft.Recognizer.Text.DataTypes.TimexExpression Ger möjlighet till parsning och ut-värdering av TIMEX uttryck Microsoft.Bot.Builder.Teams Innehåller utvidgningar av SDK för

att utveckla botar för Teams. Microsoft.Bot.Builder.Integration.AspNet.Core Biblioteket integrerar Bot Builder

SDK med ASP.NET Core

Microsoft.Bot.Builder.Dialogs Implementerar .NET Simple Dialog klasser

Microsoft.Bot.Builder.AI.Luis Middleware och Recognizers för LUIS och Bot Builder SDK

Microsoft.Azure.ActiveDirectory.GraphClient .NET klient bibliotek för Azure AD Graph API

BotAuth Grundpaket för autentisering och

hanterar flödet av OAuth

3.2

Implementation

Efter installationerna skapades ett nytt projekt i Visual Studios. Baserat på beskrivningen av mallarna i avsnitt 2.8.1 valdes Echo Bot som start-mall då den lämpade sig till nybörjare samt att den tack vare sin simplicitet gick att anpassa med nödvändiga funktioner. Projektet delades upp i flera olika filer beroende på funktion för att göra det enkelt att ändra eller fylla på med fler funktioner. Basen som användes för implementationen var Microsofts Teams Conversation Bot. Den är skapad från Bot Framework v4 och har grundfunktionerna för att hålla en konversation i Teams. Den innehåller funktioner som installerar och konfigurerar boten för att den ska fungera med Teams.

Utifrån dessa grunderna utvecklades sedan projektet för att passa behoven för chatboten. Dialogen delades upp i flera filer för att lättare hantera hur boten skulle gå vidare i varje fall. De olika dialogerna som skapades var ”Main Dialog”, ”Booking Dialog”, ”MeetingTime Di-alog”, ”View Calendar DiDi-alog”, ”Cancel and Help Dialog” och ”Logout Dialog”. Dialogerna innehåller vattenfallssteg för att boten enkelt ska kunna ta sig vidare i konversationen och vet vilken information den behöver få från användaren. Skulle boten redan ha fått all information kommer den hoppa till slutsteget och avsluta dialogen. Projektet är uppdelat i många filer för att det enkelt ska gå att ändra funktioner utan att behöva ändra alla steg för att komma fram till en specifik funktion.

Genom Microsoft Graph gick det att få tillgång till medarbetarnas kalendrar och på så sätt kunde boten kontrollera om bokningar var möjliga eller inte och utifrån det skapa en bokning som lades till i kalendern för alla som skulle närvara vid mötet om bokningen var möjlig.

När en funktion skapats, testades den genom Bot Framework Emulator och ngrok för att lokalt se om ändringar behövde göras utan att behöva publicera boten. Detta gjordes för varje ny funktion tills en fullt fungerande bot skapats.

3.2.1

LUIS konfiguration

LUIS används för att läsa av det användaren skriver och tolka den skrivna texten. Tre olika in-tents sattes upp för att tolka användaren: ”BookMeeting”, ”FindMeetingTime” samt ”None”. Varje intention kopplades till ett antal fraser där LUIS tolkar texten och identifierar olika entiteter i fraserna. En fras i ”BookMeeting” kan kopplas till intentionen genom att bara ha

3.3. Testning

”Book” i frasen. Texten kan kompletteras genom att skriva med en emailadress, en DateTime-typ eller ett rum som är en entitet skapad för detta arbete.

3.2.2

Main Dialog

MainDialog hanterar inloggningen på företagskontot, i detta fall krävs det ett Combitech-konto. Här hanterar OAuth 2.0 autentiseringen av kontot samt begär nödvändiga åtkomster till data som boten använder. Till exempel krävs det att boten får tillgång till användarens kalender. MainDialog startar huvuddialogen och här bestämmer användaren om denne vill Boka ett möte eller hitta lediga mötestider. Om LUIS inte hittar en passande intention an-vänds ett standardsvar där boten påpekar att den inte kunde uppfatta intentionen och ber användaren att omformulera texten.

3.2.3

Booking Dialog

Om intentionen i ”MainDialog” var ”Book Meeting” tar ”BookingDialog” över. Informatio-nen som är given i föregående dialog sparas som en variabel och skickas med i den nya dialogen. Denna dialog använder sig av prompts för att få information från användaren. Ex-empelvis för att fråga efter ett datum för en mötesbokning så används en prompt där svaret förväntas vara en DateTime variabel och skulle det inte vara det promptas frågan igen tills användaren skrivit rätt.

3.2.4

MeetingTime Dialog

På samma sätt som i ”Booking Dialog” funkar det i denna dialog. Om intentionen i ”Main-Dialog” var ”Find Meeting” tar ”MeetingTime”Main-Dialog” över. Informationen som är given i föregående dialog sparas som en variabel och skickas med i den nya dialogen.

3.2.5

Cancel and Help Dialog

Denna dialog svarar på tre kommandon från användaren. ”restart/rebook/redo” gör att boten glömmer all tidigare angiven information och startar om mötesbokning-en.”quit/exit/cancel” avslutar den pågående dialogen och returnerar användaren till ”Main-Dialog”. ”help/?” skickar för tillfället bara ut ett hjälpmeddelande men det går att implemen-tera en QnA-bot som kan svara på användarens frågor.

3.2.6

Logout Dialog

Om användaren skickar ”logout” loggas användaren ut från sitt företagskonto och boten av-slutas. Om användaren vill göra en ny mötesbokning eller liknande måste användaren logga in på nytt.

3.3

Testning

Baserat på 2.11 valdes lämpliga testpersoner ut. Testpersonerna bestod av fem medarbetare på Combitech i Mjärdevi, Linköping i varierande ålder, varierande erfarenhet och varierande anställningstid på Combitech. Dessa fick i uppgift att utföra en mötesbokning med systemet de använder för tillfället, Microsoft Outlook, och efter det med chatboten. Eftersom boten testades lokalt var de inte inloggade på sitt egna konto och fick då i uppgift att boka ett mö-te med sig själva valfri tid. Den enda informationen som gavs var att i chatbomö-ten behövde förfrågan skrivas på engelska, endast mailadresser med ’combitech.com’ var tillåtna och att läsa instruktionerna i chatboten. Tiden det tog att göra mötesbokningar i de olika systemen

3.4. Utvärdering

mättes samtidigt som de olika misstagen användarna gjorde noterades. Sedan fick testper-sonerna fritt berätta om sin upplevelse och vad de tyckte var bra och dåligt samt önska lite förbättringsförslag. Ett par frågor som ställdes om personerna var lite få-ordiga var:

• Hur upplevde du att det var att boka ett möte med boten? • Vilka fördelar tycker du att boten har över Outlook?

• Vad tycker du om att boten använder engelska istället för svenska?

• Skulle du kunna tänka dig att använda boten igen för att boka ett möte? Om ja, varför? Om nej, varför inte?

3.4

Utvärdering

Boten kommer att utvärderas enligt Reiss punkter i 2.11. Resultatet från diskussionerna med testarna samt botens prestation kom att ligga som grund för att avgöra hurvida boten är användarvänlig eller inte. Botens prestation analyserades tillsammans med testarnas olika misstag och framgångar. Därefter identifierades rätt kategori i Reiss lista för att för att förstå i vilken kategori boten fungerar bra och mindre bra. Därefter kan möjliga förbättringar inom de olika områdena presenteras.

4

Resultat

Nedan presenteras resultatet av implementationen samt resultatet av testningen av systemet.

4.1

Implementation

Resultatet av implementationen var en fungerande bot som kunde boka möten med personer som hade ett konto på Combinet. Boten kunde även föreslå mötestider då alla personer var lediga samt att det finns ett mötesrum ledigt. I LUIS finns olika bestämda intentioner som denne är upplärd att koppla till olika nyckelord som anges av användaren. Dessa intentioner och korresponderande nyckelord och fraser redovisas i tabell 4.1

Tabell 4.1: Tabell över entiteter och fraser som LUIS kopplar till intentioner

Intention Entiteter

BookMeeting book

book meeting FindMeetingTime find

find meeting

find available meeting Default uppfylls om inget

stäm-mer in på ovan

4.1.1

Uppstart

När boten startas välkomnas användaren och denne uppmanas att skriva valfri text för att starta. När användaren skickat en text uppmanas användaren att logga in på sitt konto med sin Outlook-kopplade mailadress. När detta är slutfört skickar boten ett meddelande där denne undrar vad användaren vill göra och ger även förslag på fraser som kan användas. Boten kan boka ett möte och hitta lediga mötestider.

4.1. Implementation

Figur 4.1: Startdialog med boten

4.1.2

Boka möte

För att kunna boka ett möte krävs det att användaren anger ett antal parametrar. LUIS känner automatiskt igen vilken typ av information som anges. Det som måste anges är, datum, tid, rum och mailadresser på personen eller personerna man vill bjuda in i mötet. Frasen ”book meeting” kan följas av dessa parametrar för att göra klart bokningen.

Figur 4.2: Bokningsdialog där all information ges direkt

Om alla parametrar inte anges kommer boten att fråga efter detta tills den har all nödvän-dig information.

4.1. Implementation

Figur 4.3: Dialog för bokning av möte

I båda fallen, illustrerade i figur 4.2 och 4.3, kan användaren välja att skicka med en möte-stitel och ett meddelande till deltagarna men användaren kan även välja att lämna det blankt. Till sist skickar boten ett meddelande med all ifylld information för att bekräfta att den in-samlade datan stämmer där användaren får klicka på knappar för ”ja” eller ”nej”.

4.1. Implementation

Om användaren anger att informationen stämmer går boten in och kollar att både den som skapar bokningen och personen eller personerna som ska närvara på mötet är lediga på angiven tid och datum samt att mötesrummet är ledigt. Om allt ser bra ut skapar boten mötet och lägger in det i respektive kalender. Därefter startar boten om dialogen och användaren kan på nytt välja vad denne vill göra. Skulle användaren välja att informationen inte stäm-mer komstäm-mer boten, vid händelse att användaren klickar på ”nej”, starta om och återgå till startdialogen.

Figur 4.5: Kontroll och bekräftelse av bokning

Skulle ett problem uppstå vid kontroll om mötet går att boka, exempelvis om en av deltagarna är upptagen eller om mötesrummet är upptaget, skickar botten ett meddelande med alternativa tider då personerna och rummet är ledigt som personen kan boka.

4.1. Implementation

Figur 4.6: Konversation då mötet inte går att boka

4.1.3

Hitta mötestider

Om en person vill hitta en ledig mötestid kan personen skriva in frasen ”find meeting times” följt av mailadressen på personerna denne vill hitta mötestider med.

4.1. Implementation

Figur 4.8: Dialog för att hitta ledig tid och bokning av möte

Om inga mailadresser anges kommer boten att fråga efter dessa. Då presenteras lediga mötestider för de angivna personerna i rum som är lediga. Dessa alternativ går att boka. Al-ternativen som visas är inom ett visst tidsintervall som går att ändra på. Det visas endast fem förslag på tider som både bokaren och de som ska närvara är lediga. Slutligen får användaren valet att ange en mötestitel och ett meddelande till deltagarna.

4.2. Testning

4.2

Testning

Först presenteras tiderna det tog för de olika personerna att boka ett möte i de två systemen. Därefter presenteras personernas tankar och åsikter om boten.

Tabell 4.2: Hur långt tid det tog för de olika personerna att skapa ett möte med boten och i Outlook

Person Outlook Bot

1 2:05 1:27

2 0:36 4:12

3 0:46 2:56

4 0:22 1:52

5 0:43 2:01

Person 1 hade aldrig bokat ett möte i Outlook, som Combitech använder idag. Personen tyckte att boten var smidig, tydlig och att det gick snabbt. Mötet i Outlook var svårare att boka första gången då det krävdes ett par försök innan personen hittade rätt ställe att starta mötesbokningen på. Däremot var det inte, enligt testaren, svårt att förstå hur man startade mötesbokningen i boten. Det var till botens fördel att den använde engelska som språk men testaren reflekterade över att det kanske skulle vara otydligt och möjligtvis svårare för äldre att lära sig. Personen önskade att det fanns en hjälpfunktion så att man visste vad man skulle kunde skriva och hur det i så fall skulle skrivas.

Person 2 var en van användare av det nuvarande systemet och reflekterade över att det antagligen var därför det gick snabbare att boka ett möte där. Personen tyckte att det be-hövdes en tydligare introtext för att snabbare lära sig att använda boten samt mer info vid felhantering, speciellt vid tid och datum hantering då det kan vara väldigt olika från pro-gram till propro-gram. Personen påpekade även att fördelen med Outlook är att folk kan ställa in sina kalendrar efter personligt önskemål (språk, tidszon och format). Fördelarna med boten kanske inte låg i just mötesbokningen men den skulle kunna vidareutvecklas till en allmän sökfunktion för att hitta sådant och få svar på sådant en vanligtvis inte hittar så enkelt. An-vändaren matade in tiden och datumet fel ett flertalet gånger och gjorde många stavfel under försöket.

Person 3 ansåg att boten var enkel att använda så länge man visste hur man skulle ut-trycka sig så den förstod. Även person 3 var en van användare av Outlook och ansåg att mötesbokning kanske inte var det boten skulle passa bäst till då det är så enkelt i Outlook. Om den skulle kunna vidareutvecklas för att göra mindre enkla saker som att se lediga kon-ferensrum på andra orter och kunna boka dem, kunna söka i kurskatalogen efter relevanta kurser för just den som söker skulle det vara mer användbart. Boten var, enligt personen, väldigt enkel att använda men man måste bara få en genomgång av syntaxen samt vad boten kan göra. Där föreslog personen att det skulle räcka med en lista med kommandon som boten känner igen och vad dessa gör. Även person 3 matade in datumen och tiden på ett felaktigt format ett par gånger innan rätt format tillslut angavs.

Person 4 är relativt van vid mötesbokning i Outlook men tycker att det är något krång-ligt. Personen påpekade att som det ser ut idag kan rummen bokas innan man vet om de är lediga och påpekade att det kunde ge upphov till att det tar väldigt långt tid att genomföra en bokning. Detta eftersom att det kan kräva ett par turer fram och tillbaka för att hitta ett ledigt rum. Det gjorde att personen tyckte det var mycket bra att man kunde se om rummet var ledigt direkt med boten. Det framgick även att personen tyckte det skulle vara kul om man skulle kunna prata in istället för att behöva skriva och att man inte skulle behöva spe-cificera dag utan boten ger förslag på möjliga tider. När personen visades denna funktion i boten blev personen glatt överraskad och tyckte att detta var en jättebra funktion som under-lättade bokande av möten. Detta eftersom boten direkt gav förslag på tider då både rum och deltagare var lediga.

4.3. Utvärdering

Person 5 är också en relativt van mötesbokare i Outlook men menar på att det går snab-bare för att man vet hur det funkar. Precis som person 4, uttryckte denna person att det som är krångligt i Outlook är att man måste vänta på ett bekräftelsemail innan man vet om bok-ningen gått igenom. Om bokbok-ningen inte gått igenom måste man göra om hela processen så personen tyckte det var mycket bra att man fick reda på det direkt. Dock uttryckte personen att det skulle varit bra om boten gav förslag på personer så man inte måste skriva in hela mailadressen då det är tidskrävande och det riskerar att bli fel. Även denna person efterfrå-gade möjligheten att få förslag på tider att ha möten. Då presenterades den funktionen i boten och responsen blev samma som för föregående person.

4.3

Utvärdering

Här presenteras en utvärdering av botens användarvänlighet baserat på de genomförda tes-terna som presenteras i 4.2 samt Reiss tio punkter som presenteras i 2.11.

Funktionalitet:Boten var funktionell och fungerade som det var tänkt att den skulle göra. Knappar och liknande funkade som de skulle och skickade vidare testaren till det tänkta steget.

Mottaglighet:Boten brister i feedbacken den ger. När en användare avslutat ett steg ges ingen respons eller feedback på det användaren gör utan den går direkt vidare till nästa steg.

Ergonomi:Boten kan inte sägas vara särskilt ergonomisk då den inte visar viktiga saker tydligare än mindre viktigare saker. Boten använder sig dock inte av några inbakade hyper-länkar som generellt sett är svåra att identifiera.

Lättillgänglighet:Allt som användaren kan tänkas behöva för att boka ett möte finns im-plementerat för användaren att använda. Knapparna som användaren använder är placerade bredvid rutan där användaren skriver vilket gör det enkelt och lättillgängligt att använda.

Idiotsäkerhet: Inom denna kategorin visade boten sina brister. Tillexempelvis gick det inte att mata in text på fel format mer än två gånger innan boten avslutade mötesbokningen och återgick till startmeddelandet. Boten uppmanar inte användaren att skriva på ett visst sätt men den ger en varning i form av ett felmeddelande om användaren inte gör som denne ska. Däremot gör inte boten aktivt någonting för att förhindra användaren från att göra fel.

Visibilitet:Den informationen användaren behöver för att genomföra bokningen finns och är synlig. Men användare gör hellre än att analysera och undersöka. Därför tenderade vital information att missas för att den var inbakad tillsammans med annan information.

Begriplighet:Även begriplighet är ett område där boten inte presterar lika starkt. Boten tillhandahåller information och uppmaningar med kommandon till användaren men det är inte begripligt alltid vad som är möjligt och hur saker kan skrivas. Exempelvis uppfattade inte en enda testare att all information som boten behövde för att kunna boka ett möte kunde anges i ett enda kommando.

Logik:Tyvärr var testarna många gånger tvungna att fundera på hur de skulle göra saker eller hur saker förväntades att det skulle göras. Däremot var anledningarna till varför de skulle uppge informationen tydlig.

Konsekvent: Boten var konsekvent i det att den efterfrågar samma information för att boka ett möte som exempelvis Outlook. Det är väl etablerat vad en användare måste ange: datum, tid, plats, vilka som ska närvara och möjligtvis anledning till mötet. I detta anseende visste användarna vad för information de förväntades uppge.

Förutsägbarhet:Tyvärr är inte boten förutsägbar första gången den används. Hur många steg som krävdes av testarna för att genomföra en bokning var inte förutsägbart. Efter att man matat in en starttid är det visserligen förutsägbart att den kommer att fråga efter en sluttid eller hur länge mötet ska vara. Men efter det är det inte självklart eller förutsägbart att den frågar efter mötesrum eller liknande. Boten är förutsägbar i det att användaren förväntar sig att viss information måste anges i en mötesbokning och detta är precis vad boten frågar efter.

5

Diskussion och Analys

Följande kapitel diskuterar och analyserar resultatet och presenterar svårigheter och problem som upptäcktes under arbetets gång.

5.1

Resultat

Nedan följer en diskussion av resultatet av implementation samt resultatet av testningen som är underlag för frågeställningarna.

5.1.1

Implementation

Implementationen tog lång tid att få att fungera bra då det tog tid att hitta vilka av Micro-softs egna funktioner som skulle användas och även hur de skulle användas för att fungera för chatboten. Problem uppkom även då vi började med att använda oss av en ’Dialog Bot’ men insåg senare att för att det skulle fungera för Teams var vi tvungna att använda ’Teams Conversation Bot’. Efter dessa problem lösts var det enklare att gå vidare med implementa-tionen. Ett annat problem som stöttes på var att boten fungerade som den skulle lokalt men inte i Teams. När boten skulle kolla autentiseringen för användaren gick det ej att komma vidare till själva kontrollen. Troligtvis berodde detta på säkerhetsfunktioner inom Combinet. Möjligtvis skulle detta gå att lösa genom mer testning och hjälp från säkerhetsavdelningen på Combitech, då vi inte hade tid för detta såg vi istället till att boten fungerade tillräckligt bra för att kunna testas lokalt.

Skillnaden på Outlook och boten när det kommer till att boka möten är sättet som datan matas in. I Outlook får användaren klicka runt med musen för att boka ett möte även om viss textinmatning förekommer. I boten är det tvärt om, vissa klick med musen förekommer men det är till största del genom textinmatning användaren ger information till boten. Dessutom använder Outlook AI-funktionalitet för att ge förslag på personer att bjuda in till mötet me-dan boten saknar den funktionaliteten. Datum och tid finns färdigformaterat i Outlook där användaren endast behöver klicka på önskad dag och tid. Boten kräver att användaren ma-tar in dessa på ett format som LUIS stödjer. Dessa skillnader ger upphov till att resultaten för testningen, som presenteras i 5.1.2, blir stora.

5.1. Resultat

5.1.2

Testning

Endast baserat på tiderna som presenterades i tabell 4.2 är det tydligt att det tog längre tid att boka ett möte med boten än vad det tog att boka ett möte i Outlook. Intervjuerna med testpersonerna gav en inblick i de svårigheter som uppstår vid användandet av en bot jämfört med ett väletablerat system.

En av testpersonerna hade aldrig bokat ett möte i Outlook vilket gjorde det till ett utmärkt tillfälle att testa hur enkelt det var att lära sig mötesbokningar i systemen. Det visade sig att det tog längre tid att boka ett möte första gången i Outlook. Detta beror möjligen på att det inte finns några instruktionen för hur en mötesbokning ska skapas utan det gäller att testa sig fram och läsa på de olika knapparna. Tillexempel var det inte helt självklart att man startar processen att boka ett möte genom att trycka på ”New Items” eller att dubbelklicka på önskad dag. Däremot hade personen inte något problem med att starta mötesbokningen i boten. Detta då boten endast presenterade möjliga aktioner och kommandot för att starta dessa olika processer. De andra personerna var vana mötesbokare vilket blev tydligt då de genomförde processen i Outlook utan några större hinder.

En stor anledning till att det tog längre tid för personerna att boka ett möte med boten var för att den informationen de gav till boten inte var den samma som boten förväntade sig. Detta härstammar från att boten är känslig för fel då den inte är intelligent nog att förstå vad användaren egentligen menar. Även om LUIS generellt sett kan tolka intentioner som är skrivna i olika ordföljder så är den mer känslig när det gäller felstavningar. Om LUIS förväntar sig datum på formatet ”YYYY-MM-DD” så kommer den inte kunna tolka ”YYYY– MM-D”, ”YYY-MM-DD” eller en variant av dessa. I Outlook finns även funktionen att söka efter en mailadress om användaren bara känner till personens namn men denna funktion finns inte i boten. Detta gör risken att skriva fel mailadress stor.

En annan faktor till att boten var mindre tidseffektiv än Outlook är att hjälputskrifterna inte var detaljerade nog eller gav inte den informationen testarna önskade. Detta är ytter-ligare ett symptom på att LUIS är känslig för när det kommer till det förväntade formatet. Exempelvis påpekade en användare att det var oklart i vilket format tid och datum skulle matas in vilket gjorde att förvirring uppstod när användaren matade in i ett format som inte stöddes av LUIS. Detta skedde upprepade gånger innan personen tillslut skrev på ett god-känt format. Även om personen fick meddelanden om att både timmar och minuter behövde inkluderas gav inte boten information om vilket format tiden skulle skrivas på.

Ytterligare en anledning till att det tog längre tid att använda boten är att det tar läng-re tid att skriva en text än att klicka på en knapp. Knappar är dessutom mer interaktivt för användaren än textinmatning. Det tar betydligt längre tid att skriva ”2020-01-22’ följt av ett enter-tecken än att klicka på en knapp med datumet redan ifyllt. I Outlook finns även funk-tionen att klicka på det önskade datumet i kalendern och då är datumet redan förifyllt. Det är inte bara skriva text som tar långt tid, det tar även tid att läsa skrivna instruktioner vilket är en bidragande faktor till att boten är mindre tidseffektiv.

5.1.3

Förbättringsförslag

För att motverka att boten är känslig för stavfel och liknande skulle ett stavningsprogram behöva inkorporeras för att minska risken att LUIS får fel information. Detta skulle kunna vara en relativt enkel lösning då boten idag bara stödjer engelska och stavningsprogram för det engelska språket är väldigt välutvecklade. Däremot skulle det kunna bli problem om andra språk skall användas. Den dagen svenska stöds i LUIS finns det risk att det inte finns stavningsprogram som är lika välutvecklade i det svenska språket som är enkla att integrera. En stor förbättringsåtgärd som behöver införas i boten för att öka användarvänligheten rör felutskrifterna. Som implementerare som testat funktionen ett flertalet gånger blir man blind för fel som en förstagångsanvändare kommer göra. Det skulle behövas en kontinuerlig dialog med testare för att arbeta fram en ideal felutskrift. Dels behöver användaren få tydlig

5.1. Resultat

information om varför inmatningen inte godtogs och hur boten förväntar sig att inmatningen ser ut. Den förväntade inmatningen behöver urskilja sig från övriga texten för att lätt kunna urskiljas. Ett förslag är att fetmarkera det önskade formatet, tyvärr är det dock inte möjligt att fetmarkera en viss del av texten i C#. En annan möjlighet är att skriva det önskade formatet direkt i uppmaningen för att minska behovet av hjälputskrifter och felhantering.

Figur 5.1: Föslag på utskrift för instruktioner för att minska risken att skriva på fel format

Istället för att skriva ”When do you want the meeting to start?” skulle instruktionen vara ”When do you want the meeting to start? State the time as HH:MM”. Se figur 5.1 för ett exem-pel. Förutsatt att användarna läser instruktionerna noggrant skulle detta minska behovet av förtydligande hjälputskrifter.

Ett annat förslag på förbättringsåtgärder är att inte använda fritextinmatning eller minska användandet av fritext för att försöka minska risken för fel. I dagsläget finns det två alternativ användaren kan välja mellan, boka möten eller hitta lediga mötestider. Boten skulle då kunna presentera knappar med alternativen för att minska risken för fel. Även tiderna skulle kunna presenteras med knappar även om det blir betydligt fler knappar. Problemet som skulle kun-na uppstå med det är att det kan bli rörigt och vissa alterkun-nativ, så som mailadresser, är svårt att presentera med knappar. Ett alternativ på detta är att använda funktionen för att hitta lediga mötestider istället för funktionen för att boka ett möte. De personer som testade den gav feedbacken att det var mycket snabbare och smidigare att använda. Då bokas mötet ge-nom 3-4steg jämfört med 3-8 steg där det dessutom finns mer utrymme för fel då användaren måste skriva mer text.

Ett annat förslag för att öka användarvänligheten och minsta tidsåtgången är att boten skickar ut ett formulär att fylla i, i ett enda steg. Exempel på detta illustreras i figur 5.2. Om användaren meddelar boten att denne vill boka ett möte imorgon kan boten skicka ut ett for-mulär där den efterfrågar all nödvändig information med datum redan ifyllt där användaren fortfarande har möjlighet att ändra informationen. Då kan problemen med formaten åtgärdas då det är enkelt att kontrollera redan vid inmatning om formatet stämmer. Då får användaren en tydlig överblick över vad som efterfrågas samtidigt som denne har möjlighet att korrigera fel innan användaren skickar in informationen. Detta minskar antalet steg som användaren måste utföra innan ett möte kan bokas.

5.1. Resultat

Figur 5.2: Föslag på upplägg där boten efterfrågar bokningsinformation via formulär.

Boten kom att använda mycket fritextinmatning tidigt i implementationen istället för knappar. Detta gjordes då det var ett önskemål från handledaren på Combitech att använda-ren skulle kunna skriva hela kommandot med all nödvändig information och boka ett möte. Detta ledde till att boten inte använder sig av knappar i samma utsträckning som den annars skulle kunna ha gjort.

5.1.4

Övergripande kommentarer

Majoriteten av testarna är vana Outlook användare och har bokat möten många gånger vilket gör att det har blivit en vana och de är väl införstådda i hur det fungerar. Alla testare påpe-kade att det skulle gå betydligt enklare och snabbare att boka ett möte om de skulle göra om det. Inlärningskurvan var inte svår men det finns en tröskel som användare måste ta sig över första gången de bokar ett möte.

Efter diskussionen med testarna stod det klart att en bot inte var lämplig för mötesbokning även om ett par av dem kunde tänka sig att använda boten för att boka möten. Det finns andra områden som boten skulle funka bättre inom, till exempel hyra bil i carpoolen, vilket är något som de flesta gör väldigt sällan. Fördelen med att ha denna funktion hos boten skulle då vara för att de anställda inte vet hur de bokar en bil och de då kan använda boten för att göra det. En viktigt faktor i detta är att det är svårt att byta ut ett så väletablerat system som Outlook som många använder dagligen. Där vet personerna hur saker funkar, därför går det snabbt. Skulle boten införas skulle den kunna användas för att utföra uppgifter som användare tycker är svåra eller onödigt tidskrävande, inte för att utföra basala vardagsuppgifter.

Om boten ändå skall användas för att utföra uppgifter som går att lösa i Outlook skulle boten kunna användas som ett komplement till nuvarande system istället för att ersätta des-sa. Detta skulle kunna göras genom att integrera Boten med Microsoft Teams där Combitechs anställda idag chattar med varandra. Istället för att då behöva byta program till Outlook när ett möte skall bokas kan användaren istället, med ett kommando, kalla på boten och boka ett möte direkt. Det skulle även kunna tänkas vara möjligt att boten automatiskt hämtar maila-dresserna från Teams-chatten så att användaren slipper mata in dessa. Ett alternativ skulle då kunna finnas där användaren får valmöjligheten att ange ytterligare deltagare. Dessutom kan funktionen att hitta mötestider vara ytterligare ett steg i att effektivisera den processen om boten automatiskt skulle kunna hämta chatt-deltagarnas mailadresser. Då skulle användaren endast kunna kalla på boten för att hitta mötestider och då få färdiga förslag som bara skulle