Ett nytt Friendlyreader

Transkript

1 Linköpings universitet Institutionen för datavetenskap Kognitionsvetenskapliga programmet Kandidatuppsats 18 hp Vårterminen 2019 ISRN-nummer: LIU-IDA/KOGVET-G 19/007 SE Ett nytt Friendlyreader implementationen av ett gränssnitt med fokus på språkteknologiska funktioner Malin Wängelin Examinator: Robert Eklund Handledare: Arne Jönsson Datum Linköpings universitet Linköping Sverige

2 Upphovsrätt Detta dokument hålls tillgängligt på Internet eller dess framtida ersättare från publiceringsdatum 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 kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning 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 upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida Copyright The publishers will keep this document online on the Internet or its possible replacement from the date of publication barring exceptional circumstances. The online availability of the document implies permanent permission for anyone to read, to download, or to print out single copies for his/her 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 procedures for publication and for assurance of document integrity, please refer to its www home page: c Malin Wängelin.

3 Sammanfattning Syftet med detta arbete var att implementera ett fungerande verktyg för att underlätta läsning av text med fokus riktat mot språkteknologiska funktioner. Det digitala verktyget Friendlyreader är framtaget för att underlätta läsning av text för individer med lässvårigheter, som exempelvis kan bero på dyslexi eller en funktionsnedsättning. Detta arbete har genom en förstudie kartlagt vilken funktionalitet som efterfrågas och finns tillgänglig hos liknande verktyg som ämnar att underlätta läsning. Detta har legat till grund för implementationen av ett funktionellt gränssnitt som bygger på språkteknologiska funktioner som tillhandahålls från en fjärrservern genom SAPIS REST API. Under implementationen togs beslutet att göra funktionaliteten samverkande för att skapa ett mer flexibelt verktyg. Detta innebär att text som exempelvis blivit förenklad även kan bli sammanfattad, funktionaliteten utgår således från textens aktuella utformning och inte dess original. Implementationen genomgick tester där all funktionalitet med fokus på språkteknologi fick ett godkänt resultat. Abstract The purpose of this project was to implement a functioning tool to facilitate reading of text with a focus on language technology. The digital tool Friendlyreader is designed to facilitate reading of text for individuals with reading difficulties, which may be due to, for example, dyslexia or a disability. This work has mapped out the functionality that is requested and is available from similar tools that are intended to facilitate reading. This has been the basis for the implementation of a functional interface based on language technology features provided from a remote server through the SAPIS REST API. During the implementation, the decision was made to make the functionality work together to create a more flexible tool. This means that text that has been simplified, for example, can also be summarized. The functionality is based on the current design of the text and not its original. The implementation went through tests where all functionality with a focus on language technology got an approved result.

4 Innehåll Upphovsrätt Sammanfattning 1 Inledning Relaterat arbete Syfte Avgränsningar Bakgrund Förenkla text Sammanfatta text Textkomplexitetsmätning Synonymer Teori Krav Kravinsamling Kravanalys Gränssnittsdesign Återkoppling Ångra handling Design för alla Test Dynamiska tester Testfall Förstudie Metod Kravinsamling Kravanlys Resultat och Diskussion Kravinsamling Kravanalys Implementation Språkteknologisk funktionalitet Förenkla text Sammanfatta text Visa synonymer Textinformation och textkomplexitet Textens viktigaste meningar Få texten uppläst Grafiska anpassningar Återställa texten till dess original

5 5.2 Gränssnittsdesign Återkoppling Test Metod Resultat Diskussion Förstudie Implementation Test Framtida arbete Slutsats 34 Referenser 35 Bilagor 36 A Kravspecifikation 37 B Testspecifikation 39 C Felrapport 49

6 Tabeller 1 Resulterande krav från kartläggning av funktionaliteten hos Friendlyreader Resulterande krav från kartläggning av funktionaliteten hos TeCST 12 3 Krav baserade på tidigare studier Krav baserade på liknande verktyg Användarkrav Systemkrav Gränssnittskrav Resultat från testfall

7 Figurer 1 Gränssnittet hos den nya implementationen av Friendlyreader Sidomeny och förenklingsregler Synonymer till ordet förklaringar uppvisas Positiv och negativ återkoppling på användarens handlingar där en förfrågan skickas till servern

8 1 Inledning Att läsa och förstå text är något som utgör en väsentlig del av våra liv och en skicklighet vi lär oss tidigt i livet för att senare använda oss av för att skaffa ny kunskap. Svenska statistiskmyndigheten (SCB) deltog 2013 i en internationell studie där färdigheter hos vuxna personer undersöktes. Denna studie visade att cirka 13 % av den svenska befolkningen har en läsfärdighet på nivå 1. Individer på den nivån kan läsa kortare texter med tillgång till ett grundläggande ordförråd där det inte är säkert att dessa personer kan ta till sig innebörden av en text eller förstå dess struktur. Enligt myndigheten för tillgängliga medier har mer än en halv miljon svenskar problematik med att läsa tryckt text, något som kan bero på funktionsnedsättning, dyslexi eller en sjukdom som gör det svårt att koncentrera sig på text (MTM, 2019). Detta kan medföra att fler personer med denna problematik rör sig till digitala medier som exempelvis talböcker och taltidningar, för att utnyttja sina andra sinnen. Man kan se att elektroniskt material ökar inom den akademiska sektorn då mycket material är webb- eller datorbaserat (Nandhini & Balasundaram, 2013). Detta medför en viss problematik; detta material behöver fortfarande vara läsbart och förståeligt för alla, något som möjliggör för språkteknologi att skapa bättre förutsättningar för personer med denna svårighet. Man har i tidigare studier sett att exempelvis ha möjligheten att sammanfatta en text är betydelsefullt för personer med lässvårigheter (Gajria, Jitendra, Sood & Sacks, 2009). För att öka denna inkludering har projektet DigInclude initierats och syftar till att förbättra offentlig sektors digitala tillgänglighet för medborgare med särskilda behov (Jönsson, 2018). Detta projekt har tagit fram två webbaserade tjänster; TeCST, med syftet att underlätta för skribenter att skriva lättlästa texter samt Friendlyreader, ett läsverktyg framtaget för att underlätta läsning för personer med läs- och skrivsvårigheter. Detta inkluderar personer med nedsatt syn, dyslexi, funktionsnedsättning samt personer som är nya till det svenska språket. I Friendlyreader erbjuds bland annat möjligheten att sammanfatta, förenkla samt mäta komplexiteten hos text. Vad som gör en text lätt att läsa är inte detsamma för alla, oavsett kognitiv nedsättning eller inte. Att ta fram ett verktyg som är anpassat för så många som möjligt är utmaning. Ett steg på vägen är att undersöka vilken typ av funktionalitet som efterfrågas hos personer med lässvårigheter för att implementera det i ett digital verktyg som Friendlyreader, något som detta arbete ämnar att göra. 1.1 Relaterat arbete Projektet Begriplig text har undersökt vad som gör en text enkel att läsa och förstå med målet att upplysa skribenter och journalister och hjälpa dem att skriva texter som är mer inkluderande (Hedberg, Eltebo, Lundgren, Rydin & Kilsved, 2018). Förutom intresse och första intrycket av en text så lyfter projektet fram olika grafiska anpassningar av text som avgörande faktorer om en läsare beslutar att fortsätta läsa en text eller inte. Det kan exempelvis vara viktigt att texten har tydliga ingångar, mellanrubriker, luft mellan stycken och 1

9 breda rader för att underlätta läsning. Projektet har även visat att möjligheten att kunna förstora texten är efterfrågat hos bland annat personer med dyslexi och språkstörningar. En av projektets exempelläsare, Lova, har svårigheter med att läsa text och är i behov att ett läsverktyg. Två saker hon prioriterar som viktiga är att få texten sammanfattad och att det viktigaste ska komma först. Detta menar denna exempelläsare är viktigt för att förstå och läsa text. Samma behov återfinns hos de flesta av projektets framtagna exempelläsare. En exempelläsare är ingen identifierbar person utan representerar en tänkbar läsare från projektets deltagargrupper där förmågor och egenskaper är en sammanställning från projektets resultat. Denna beskrivning är mycket lik den som Arvola (2014) använder för att förklara personor. Även projektet EasyReader (2012), som är riktat mot personer med lässvårigheter, har tagit fram personor som uttrycker liknande behov. Frida, projektets primärpersona, uttrycker att hon ibland läser en sammanfattning av texten först. Att veta vad texten handlar om underlättar för Frida när det kommer till att förstå textens innehåll. Finns det ingen sammanfattning tillgänglig kan ett språkteknologiskt verktyg likt en textsammanfattare lösa detta problem. I dagsläget finns det inte många verktyg som erbjuder denna funktionalitet, något som skulle kunna hjälpa skribenter, men främst underlätta läsning av texter som inte initialt är utformade på ett lättläst sätt. Detta möjliggör för individer med lässvårigheter att ta till sig ett större antal texter. 1.2 Syfte Denna studie har riktat fokus mot språkteknologisk funktionalitet hos verktyg som ska underlätta läsning av text. Genom att undersöka vilken typ av funktionalitet som efterfrågas av användare och finns hos andra verktyg ämnar detta arbete implementera ett mer funktionellt gränssnitt för verktyget Friendlyreader. Syftet med arbetet var att implementera ett fungerande verktyg och genom tester säkerställa att implementationen var fungerande. 1.3 Avgränsningar Flertalet studier med fokus på användare inom målgruppen för Friendlyreader var redan utförda och av denna anledningen utfördes ingen användarundersökning utan dessa studier inkluderas i den förstudien som låg till grund för implementationen. Fokus för arbetet var att implementera språkteknologiska funktioner och visualisera dem i ett gränssnitt. Detta är således ett arbete inriktat mot utveckling och inte design. 2

10 2 Bakgrund Friendlyreader använder sig av SAPIS REST API, ett API som tillhandahåller olika språkteknologiska funktioner från en fjärrserver (Falkenjack, Rennes, Fahlborg, Johansson & Jönsson, 2017). Dessa funktioner är framtagna för att göra text lättare att förstå och innefattar textförenkling, textsammanfattning, textkomplexitetsmätning, samt synonymer. 2.1 Förenkla text Syftet med att förenkla text är att minska komplexiteten hos en text för att öka förståelsen hos läsaren (Rennes & Jönsson, 2015). Att kunna förenkla text automatiskt kan anses fördelaktigt då utförandet av en sådan manuell process är tidskrävande. Verktyget som används för att förenkla text kallas StilLett och innehåller flera typer av förenklingar, dessa används i Friendlyreader: 1. Passiv till aktiv form 2. Citatomvändning 3. Rak ordföljd 4. Meningsuppdelning 5. Proximering Att ändra från passiv till aktiv form innebär att subjektet i den passiva meningen blir till ett objekt i den aktiva meningen, ordet av, tas bort och s-slut försvinner (Rennes & Jönsson, 2015). Att utföra en citatomvändning innebär att ändra plats hos talaren i ett citat, exempelvis från sa Lisa till Lisa sa. Denna regel genomförs genom att försöka identifiera citattecken följt av ord som antyder att ett citat har yttrats, exempelvis sade eller utbrast. Lyckadas detta identifieras så byter verbfrasen plats med substantivfrasen. Att förenkla texten genom Rak ordfölj innebär att satser som är initierade med adverb eller adjektiv förändrar ordföljden. Meningen Igår köpte Maja en glass förändras då till Maja köpte en glass igår. Regeln Meningsuppdelning delar upp en meningar genom att identifiera kommatecken och delar upp meningen från detta skiljetecken. Sist kvarstår proximering. Denna regel ämnar att föra texten psykologiska närmare användaren (Kousta, 2016), exempelvis genom att byta ut man mot du. För att se de språkteknologiska regler som ligger till grund för de olika operationerna hänvisas till Rennes och Jönsson (2015). 2.2 Sammanfatta text Den automatiska textsammanfattaren som används i Friendlyreader kallas Cog- Sum. CogSum är extraktionsbaserad och sammanfattar text genom att identifiera de viktigaste meningarna hos en text genom distributionssemantik (Smith, 3

11 Danielsson & Jönsson, 2012). Meningarna rangordnas och presenteras sedan som en komprimerad version av originalet. För att utföra detta använder sammanfattaren en ordrymdsmodell kallad Random Indexing (RI) som är tränad på ordvektorer och ovan på den modellen används sedan en variation av algoritmen PageRank för att extrahera de meningar som delar den viktigaste informationen. 2.3 Textkomplexitetsmätning Scream är en separat service som omfattar 117 komplexitetsmått och kan nås genom SAPIS (Falkenjack m. fl., 2017). En del av dessa komplexitetsmått används i Friendlyreader för att illustrera textkomplexitet i ett diagram. I detta diagram uppvisas exempelvis läsbarhetsmått som ordvariationsindex (OVIX) och läsbarhetsindex (LIX). Ordvariationsindex är ett mått på hur många unika ord som förekommer i en text i förhållande till textens alla ord (Rybing & Smith, 2010). Läsbarhetsindex används som ett mått för att ge en uppfattning om hur lätt eller svår en text är att läsa (Björnsson, 1968). Utöver dessa mått uppvisas även genomsnittlig meningslängd, genomsnittlig ordlängd, andel bisatser, meningsdjup samt SweVoc (Total) i diagrammet. 2.4 Synonymer Tidigare studier har visat att personer med dyslexi upplever problem med komplexa ord, exempelvis ovanliga eller långa ord (Rello, Baeza-Yates, Bott & Saggion, 2013). För att underlätta för personer med denna svårighet att läsa kan man erbjuda synonymer som ersättning för ord som upplevs som svåra utan att förstöra meningsbyggnaden. Den synonymfunktion som finns i Friendlyreader använder Synlex lexikon (Kann, 2013), som är en öppen källa och innehåller ungefär synonympar (Rennes & Jönsson, 2015). På lexikonets webbsida finns det möjlighet för allmänheten att betygsätta hur korrekt två synonympar anses vara. Resultatet från dessa betygsättningar kan sedan hämtas från en frekvenslista. Detta lexikon använder sig Friendlyreader av för att identifiera vilka av orden i texten som har synonymer och hämtar sedan ut de synonymer med högst frekvens. 4

12 3 Teori I detta avsnitt presenteras teoretisk information om krav, gränssnittsdesign samt test. 3.1 Krav Innan man påbörjar utvecklingen av ett nytt system vill man undersöka hur det ska användas av målgruppen och vad systemet skall kunna göra (Sommerville, 2005). Processen för att ta reda på detta kallas för kravteknik (eng. Requirements engineering). Ett krav är en beskrivning av vad systemet ska kunna göra och på vilket sätt, men även vad systemet inte ska klara av. De specificerade kraven ska reflektera den tänkta målgruppens mål och behov (Sommerville, 2011). Wiktorin (2018, s. 196) definierar krav på följande sätt: Ett krav är en önskvärd egenskap eller funktion hos ett IT-system eller en produkt. I denna del presenteras ett tillvägagångssätt för att ta fram krav för ett system, detta inkluderar en kravinsamling och en kravanalys Kravinsamling Ett tillvägagångssätt för att identifiera krav som kommer att ställa på ett system, gränssnitt eller interaktionen mellan användare och system är att utföra en kravinsamling. Detta är en process där information samlas in om nuvarande och liknande verktyg för att identifiera användar- och systemkrav från informationskällor, exempelvis systemdokumentation, intressenter och användare (Sommerville, 2011). Denna information samlas vanligtvis in genom intervjuer, scenarion eller användarfall. Intervjuer är ofta ett effektivt sätt att få en bra överblick hur målgruppen använder ett system eller vilka problem som de upplever. För att få ut så mycket som möjligt från intervjuer kan det vara effektivt att både använda sig av stängda och öppna intervjuer. Vilket innebär att en intervju utförs med ett antal förutbestämda frågor men även utan fördefinierad agenda. Detta för att utforska bredden av problem hos ett system utan att begränsa sig till de förutbestämda frågorna. Detta kan bidra till en bättre förståelse för de behov som användarna har. Användandet av scenarion kan göra denna förståelse ännu djupare. Det är vanligt att personer har lättare att få en förståelse för användandet av ett system när det kan sättas i vardagliga kontexter, något som kan bidra till att kraven blir mer detaljerade. Ett scenario beskriver exempel på hur interaktionen sker mellan användaren och systemet. Ofta inkluderar ett scenario ett naturligt tillvägagångsätt av användandet, användarens förväntningar, vad som kan gå fel och hur detta hanteras. Slutligen finns användarfall som ett tillvägagångssätt för att identifiera krav. Användarfall specificeras i UMLdiagram och innehåller i dess mest simpla form information om aktören i en interaktion, vilken typ av interaktion som utförs samt beskrivning av interaktionen. Under en kravinsaming kan flera eller ett av tillvägagångssätten användas för att identifiera krav. 5

13 3.1.2 Kravanalys De krav som identifieras under kravinsamlingen behöver analyseras för att se om de är möjliga att utföra från ett system- och tidsperspektiv (Sommerville, 2011). En sådan process kräver förhandling och prioritering av krav. Samtliga krav som identifierats under insamlingen skall analyseras. Kravspecifikationen är vad som senare fungerar som en utgångspunkt för utvecklingsarbetet av ett nytt system. Specifikationen beskriver då vad systemet ska kunna klara av samt vilken tjänst systemet erbjuder. Målet är att specifikationen ska reflektera behovet hos användaren. Det är av stor betydelse att kraven inkluderade i specifikationen formuleras på ett sätt så att de blir testbara. Detta innebär att problemet beskrivs snarare än att en lösning presenteras (Ostroff & Torshizi, 2007) och en framtida implementation kan således testas mot kravspecifikationen. Man vill fokusera på att formulera vad kravet omfattar så att det även går att avgöra till vilken grad ett krav är uppfyllt i det slutliga systemet (Wiktorin, 2018). Ett välformulerat krav är inte tvetydigt och ska inte kunna misstolkas, man bör i största möjliga utsträckning undvika missförstånd. Detta är särskilt viktigt när det gäller krav som kategoriseras som systemkrav då denna typ av krav riktar sig mot de individer som sköter utvecklingen av systemet (Sommerville, 2011). Kraven bör även benämnas som skall- och bör-krav för att förmedla vilken nivå kravet har. Det är av betydelse att följa riktlinjer för användandet av ord i krav för att förmedla dess innebörd på ett korrekt sätt. Ett skall-krav innebär att det är ett absolut krav och måste finnas med i den färdiga tjänsten (Bradner, 1997). Ett krav som inte är ett absolut krav är rekommenderat och kallas bör-krav. Ett sådant krav kan ignoreras från specifikationen under vissa omständigheter så länge som de fulla konsekvenserna av detta beslut tas i beaktning och övervägs noggrant. För att få en bra överblick av det som systemet klarar av och den tjänst som systemet erbjuder på olika abstraktionsnivåer bör specifikationen delas upp mellan olika typer av krav, exempelvis användaroch systemkrav. Att göra en sådan uppdelning är mycket effektiv i ett kommunikationssyfte och innebär att de beskrivs med olika detaljeringsgrad efter vem som ska läsa kraven (Sommerville, 2011). Användarkraven beskriver i naturligt språk de tjänster som systemet förväntas ge till systemanvändare medan systemkrav är mer detaljerade beskrivningar av systemets funktioner och operativa begränsningar. Den främsta felkällan vid utveckling av IT-system uttrycker Martin (1984, i Eriksson, 2008) är krav. Hela 56 % av felen som vanligtvis uppstår vid utveckling av IT-system grundar sig i kravspecifiktationen, något som tyder på hur viktig denna process är för ett lyckat utvecklingsarbete. 6

14 3.2 Gränssnittsdesign Detta arbete har som tidigare nämnt inte fokuserat på design men då ett nytt gränssnitt utformades så anpassades utformningen av gränssnittet efter några teorier och principer Återkoppling För att kommunicera resultatet av en handling till användaren bör tydlig återkoppling (eng. feedback) ges (Arvola, 2014). Främst handlar det om att förmedla till användaren vad som har skett och vad som kan hända härnäst. En användare förstår sig på ett system genom att interagera med det, där varje handling följs av en reaktion i en feedback-loop (Morgan-Jones, 2018). Dessa loopar finns för att förstärka förståelsen av ett system och detta är vad som gör dem viktiga. Genom att förses med återkoppling av en handling kan man som användare vara säker på att den utförts. Utan någon form av reaktion utförs handlingen ofta upprepande gånger för att säkertställa att den utförts, något som vanligtvis sker instinktivt. Att förses med en återkoppling förväntas ofta ske snabbt och direkt med en naturlig fördröjning efter en utförd handling. Det bör dock inte ske för snabbt så att användaren inte hänger med. Andra aspekter att tänka på vid återkoppling är att uppvisa den där användaren kan se den samt att ständigt uppdatera användaren med status om vad som sker Ångra handling Ofta utvecklas system så att användaren möts av en varning och behöver bekräfta en utförd handling (Raskin, 2007). Oavsett hur vi utformar varningen så kommer vi människor ändå att utföra handlingar av misstag. Istället för att bekräfta utförandet av en handling är det bättre att erbjuda användaren möjligheten att ångra handlingen (Goodwin, 2009). När man utformar en produkt eller tjänst bör man acceptera att misstag kommer att ske och bör därför förse användaren med möjligheten att ångra en handling Design för alla Konceptet Design-för-alla är en designfilosofi som innebär att design ska vara inkluderande och inte utgå från en normaliserad vy av en person utan från synsättet att varje människa är unik (Unicum, 2019). Detta innebär att man vid utformningen av produkter och tjänster tar hänsyn till mångfald för att produkten eller tjänsten ska kunna utnyttjas, användas av och höja livskvaliteten för så många som möjligt. Att följa denna designfilosofi är extra viktigt när man utformar tjänster som inte är privata och bör ses som en naturlig utgångspunkt för långsiktig hållbar samhällsutveckling. 7

15 3.3 Test Syftet med att utföra tester av en programvara är att se om det uppfyller de krav som finns specificerade samt för att identifiera fel i programmet (Eriksson, 2008). Att identifiera fel är en av de viktigaste produkterna som man får av att utföra tester, dessa fel är skillnaden mellan förväntat och faktiskt resultat (Koomen & Pol, 1999). Detta ger information och insikt i kvalitéen hos systemet och är värdefullt för att undvika problem i vidare utveckling eller eventuell lansering. Att testa är en process som är planerad, välstyrd och bör genomföras på ett strukturerat sätt. Att sätta upp en testprocess kan vara krävande men mycket lönsamt när den väl är fungerande och på plats (Eriksson, 2008). Det är vanligt att risker identifieras och en utförlig testplan och strategi utarbetas för att undvika problematik under testarbetet. Att testa alla möjliga tänkbara kombinationer hos ett system är ofta kostsamt och tidskrävande och i vissa fall omöjligt (Eriksson, 2008). Man eftersträvar att hitta en optimal testnivå för att upptäcka så många fel som möjligt, för att göra detta är det viktigt att välja rätt testdesignteknik Dynamiska tester En typ av testdesignteknik är dynamiska tester. Under sådana tester så exekveras systemet och har fokus på funktionalitet snarare än dokumentation, kod och gränssnitt (Eriksson, 2008). Positiva tester är ett dynamiskt test och en bra metod för att undersöka huruvida systemet presterar vid normal användning (Eriksson, 2008). Sådana tester utförs med kännedom om systemets funktionalitet och således i syfte att undersöka om en implementation fungerar som den ska. Negativa tester har ett motsatt syfte, sådana tester utförs för att kontrollera systemets felhantering och vad som uppstår då systemet används på ett felaktigt sätt. En annan typ av dynamiska tester är test av tillståndsövergångar. Vid sådana tester tas en tillståndstabell fram för att illustrera antal möjliga sekvenser av tillstånd som systemet kan anta och undersöka hur systemet presterar givet olika händelseförlopp (Eriksson, 2008). Syftet är att undersöka resultatet givet olika tillstånd och händelseförlopp. En kombination av testtekniker möjliggör att fler fel kan identifieras, och på så sätt får man en mer effektiv testprocess Testfall För varje krav utformas ett eller flera testfall. Ett testfall utformas med syftet att testa en särskild egenskap hos systemet och omfattar varierande information men innehåller ofta ID, rubrik, förberedelser, teststeg samt förväntat resultat (Eriksson, 2008). Att skriva en beskrivande rubrik är fördelaktigt då det blir enklare att navigera mellan testfallen. Exempelvis är rubriken Aktivera synonymer mer innehållsrik och fördelaktig än Testfall 1. Det är av stor betydelse att det förväntade resultatet formuleras på ett sätt som går att utvärdera om testfallet lyckades, är det otydligt formulerat kan det vara svårt att avgöra om 8

16 testfallet lyckats eller inte. Då kravspecifikationen bör vara formulerad på ett testbart sätt bör det förväntade resultatet gå att utläsa från de angivna kraven. Det förväntade resultatet av varje testfall skall formuleras innan utförandet av testet för att undvika påverkan av dess utfall. För att utforma testfall så utgår man från kravspecifikationen och granskar de krav som finns och skriver testfall utifrån dem (Eriksson, 2008). En del testfall kan kräva att andra testfall redan exekveras, i dessa fall kan det vara nödvändigt att skapa ett testschema för en körordning. Oavsett designteknik så behöver varje testfall inkluderas av startsituation, action samt förväntat resultat (Koomen, et al., 2006 i Wissa, 2011). Startsituationen inkluderar de förberedelser som behöver göras innan testfallet kan utföras eller anger vilket tillstånd systemet bör vara i. Action definieras av de teststeg som utförs vid testet. Teststegen kan utformas med ett förväntat resultat för varje steg, detta är inte alltid nödvändigt men bör användas i de fall ett teststeg är tidskrävande eller komplext (Eriksson, 2008). Att använda testfall är fördelaktigt då det bidrar till ett mer strukturerat tillvägagångssätt och är en bra grund för eventuella felrapporter. De utformade testfallen inkluderas sedan i en testspecifikation tillsammans med en inledning, beskrivning av testdata samt eventuella förberedelser inför utförandet av testerna. 9

17 4 Förstudie En förstudie utfördes för att undersöka vilken typ av funktionalitet som efterfrågas, finns tillgänglig och bör inkluderas i Friendlyreader. Detta undersöktes i syfte att ta fram krav som verktyget skulle implementeras efter. 4.1 Metod Utförandet av förstudien bestod av en kravinsamling samt en kravanalys för att resultera i en kravspecifikation Kravinsamling Syftet med kravinsamlingen var att identifiera de krav som speglar målen hos användarna inom målgrupperna för Friendlyreader. För att identifiera vilken funktionalitet som fanns tillgänglig så kartlades funktionaliteten hos Friendlyreader samt TeCST. Även dess möjligheter och brister dokumenterades. Från detta sammanställdes den funktionalitet som fanns och skulle bevaras hos Friendlyrerader samt vilken funktionalitet hos TeCST som kunde appliceras i Friendlyreader. Detta var den inledande delen av kravinsamlingen för att täcka upp så många krav som möjligt. Då användarstudier tidigare utförts för både Friendlyreader samt TeCST så bearbetades sedan resultatet från dessa för att identifiera fler krav. För att hitta förbättringsmöjligheter för läsverktyget samt undersöka vad som används idag inom området så kartlades funktionalitet hos liknande verktyg och krav formulerades utifrån detta. Slutligen användes även resultat från artiklar inom detta forskningsområde som informationskälla. Målet med denna process var att den skulle resultera i en samling krav som skulle ligga till grund för den kommande kravanalysen Kravanlys Målet med förstudien var att den skulle resultera i en kravspecifikation. Denna process krävde att insamlade krav analyserades för att identifiera om de var möjliga att utföra från ett system- och tidsperspektiv. Samtliga krav från insamlingen omformulerades så att problemet presenterades istället för en tänkbar lösning och på ett sådant sätt att de inte skulle kunna gå att misstolkas. Omformuleringarna utfördes med stor noggrannhet så att kravbeskrivningarna inte var tvetydiga för att undvika eventuella missförstånd. Specifikation delades även upp i tre olika typer av krav, användarkrav, systemkrav samt gränssnittskrav. Denna uppdelning gjordes för att få en bra överblick av vad systemet ska klara av och den tjänst som erbjuds på olika abstraktionsnivåer. En del av kraven valdes att delas upp som gränssnittskrav då målgruppens behov ställde höga krav på hur gränssnittet skulle kunna anpassas. Genom att dela upp dessa som en egen typ av krav blev de tydligt specificerade och riskerade således inte att misstolkas vid implementationen. 10

18 4.2 Resultat och Diskussion I detta avsnitt beskrivs de krav som identifierades i kravinsamling samt hur de valdes att prioriteras och utformas i kravanalysen Kravinsamling Kravinsamlingen resulterade i en ostrukturerad samling krav av olika typer som var i behov av att organiseras i sammanhängande grupperingar. Detta resulterade i tre olika typer av krav; funktionella, grafiska och informativa. Efter kartläggningen av funktionaliteten hos Friendlyreader kunde flertalet krav identifieras, se Tabell 1. Tabell 1: Resulterande krav från kartläggning av funktionaliteten hos Friendlyreader Kravbeskrivning Gränssnittet ska förse användaren med information om verktyget Gränssnittet ska förse användaren med visuell feedback när analysen av text pågår Gränssnittet ska stödja förändring i teckenstorlek, typsnitt, radavstånd och textbredd Gränssnittet ska tillhandahålla en läslinjal med olika utseenden och justerbar höjd Användare ska kunna se textkomplexitet illustrerat genom ett diagram Användaren ska kunna se synonymer till ord i texten Användaren ska kunna få texten uppläst Användaren ska kunna sammanfatta texten fram och tillbaka Användaren ska kunna infoga text på webbsidan Användaren ska kunna förenkla texten Kravtyp Informativt Grafiskt Grafiskt Grafiskt Funktionellt Funktionellt Funktionellt Funktionellt Funktionellt Funktionellt Efter detta moment utfördes kartläggningen av funktionaliteten hos TeCST. Efter kartläggningen kunde den funktionalitet som ansågs lämplig i Friendlyreader identifieras, se Tabell 2 11

19 Tabell 2: Resulterande krav från kartläggning av funktionaliteten hos TeCST Kravbeskrivning Användaren ska kunna se borttagna meningar från sammanfattaren Användaren ska kunna se emojis som illustrerar ordets semantiska innebörd som en synonym Användaren ska kunna anpassa textförenklingen på olika sätt Kravtyp Funktionellt Funktionellt Funktionellt I TeCST uppvisas de meningar som tagits bort när texten sammanfattas i en tabell. Denna funktionalitet fanns inte implementerad i Friendlyreader och ansågs vara något som kan hjälpa användaren att förstå hur sammanfattaren fungerar och undviker att uppleva att information går förlorad. I TeCST uppmärksammades det även att emojis används som ett komplement till synonymer. I en pilotstudie har Lindberg och Kindberg (2018) visat att emojis kan underlätta att förstå text för personer med läs- och skrivsvårigheter. Detta var enbart en pilotstudie och det finns mer att undersöka inom området men att använda emojis som komplement till synonymer anses inte kunna stjälpa förståelsen av text och gav således upphov till ytterligare ett krav. Att förenkla text var en funktionalitet som fanns implementerad i Friendlyreader, men på vilket sätt som verktyget förenklar texten var inte förmedlat till användaren. I TeCST kunde man som användare välja hur texten skulle förenklas. De alternativ som fanns att välja mellan var; rak ordföljd, passiv till aktiv, proximering, citatomvändning samt meningsuppdelning. Att addera denna valmöjlighet ger ett mer anpassningsbart verktyg där användaren själv kan få besluta enligt vilken typ av regel som texten ska förenklas efter då alla användare inte har behov av samma typ av förenkling. Detta adderades som ett krav till kravinsamlingen, användaren ska kunna anpassa textförenklingen på olika sätt. Detta förser även användaren med möjligheten att utforska olika textförenklingar av text. Majoriteten av de slutsatser som tidigare studier har resulterat i har legat till grund för den funktionalitet som var implementerad i Friendlyreader i den inledande fasen av detta projekt. Projektet Begriplig text (Hedberg m. fl., 2018) har undersökt vad som gör en text lätt respektive svår att läsa genom att undersöka behoven hos personer med kognitiva nedsättningar, bland annat personer med dyslexi och utvecklingsstörning. Resultatet från detta projekt riktar främst fokus mot grafiska förändringar hos en text, som exempelvis radavstånd, textbredd samt teckenstorlek och hur detta underlättar läsning. Detta var funktionalitet som redan fanns implementerad hos Friendlyreader. Projektet har även kommit fram till att personer inom dessa målgrupper uppskattar att möjligheten att sammanfatta texten samt även att första intrycket av en text kan avgöra om läsaren väljer att läsa den eller inte. Detta styrker betydelsen av att ha en välfungerande sammanfattningsfunktion i ett verktyg som ämnar att underlätta läsning. En text som vid första anblick ser svårläst ut behöver nödvändigtvis inte vara det, med hjälpa av språkteknologiska funktioner kan den bli lättare att läsa. Om meta-data om en text kan presenteras för användaren kan det 12

20 eventuellt ge användaren en chans att göra en mer kvalificerad bedömning om texten kommer att läsas eller inte. I TeCST presenteras meta-data om texten för användaren, något som ansågs behjälpligt för skribenter. Denna data kunde anses värdefull även för målgruppen hos Friendlyreader och detta resulterade i ett ytterligare krav, se Tabell 3. Friendlyreader presenterade komplexitetmått baserat på text för användaren, men gav inga förklaringar för innebörden hos dessa begrepp. För att användare ska kunna ta till sig dessa behöver gränssnittet förse användaren med förklaringar över begrepp som kan underlätta beslutet om en text kommer att läsas eller inte, även detta resulterade i ett krav. Projektet Begriplig text (Hedberg m. fl., 2018) har skribenter som målgrupp, då resultatet förhoppningsvis ska underlätta att skriva texter som möjliggör att fler individer kan tillgodogöra sig dem. Trots att projektet har en annan målgrupp än Friendlyreader så belyser de svårigheter hos personer inom målgruppen för Friendlyreader. Resultatet från projektet visar att olika grupper vill anpassa text på olika sätt, vilket tyder på att verktyget behöver inkludera funktionalitet som stödjer behovet hos samtliga målgrupper. I en tidigare utförd pughanalys, en typ av värderingsmatris, av Vegelius (2011) med syfte att välja ut designkoncept presenterades behov och krav hos målgrupperna för Friendlyreader. Denna analys visade att de viktigaste kraven hos användarna var följande: 1. Sammanfatta texten 2. Förstå texten 3. Läsa originaltexten 4. Se vilka meningar som är viktigast Detta belyste återigen av hur stor vikt det är för användarna inom dessa målgrupper att ha möjligheten att sammanfatta text. Vad en användare behöver för att förstå texten varierar efter dess behov och att hitta en lösning på ett sådant problem är således inte en enkel utmaning utan något som verktygets varierande funktionalitet förhoppningsvis kan lösa genom att försöka identifiera så många behov hos personer inom målgruppen som möjligt. Att ha möjligheten att läsa originaltexten samt att se vilka meningar som är viktigast gav upphov till två nya krav, se Tabell 3 Tabell 3: Krav baserade på tidigare studier Kravbeskrivning Gränssnittet ska förse användaren med förklaringar av komplexitetsbegrepp Användaren ska kunna se meta-data om texten Användaren ska kunna se textens viktigaste meningar Användaren ska kunna gå tillbaka till originaltexten Kravtyp Informativt Funktionellt Funktionellt Funktionellt 13

21 Efter att ha undersökt liknande verktyg och tjänster som ämnar att underlätta läsning av text, kunde flera gemensamma funktioner identifieras. Två av dessa tjänster, TTSREADER (Ttsreader, 2017) och Ginger (Ginger Software, 2019), har fokuserat på att läsa upp text för användaren. TTSREADER är en webbaserad tjänst och Ginger är en mjukvara som kan implementeras i webbläsaren eller användas för filer. Båda tjänsterna erbjuder uppläst text av personer med olika kön, på olika språk och i olika takter. Utöver detta hade tjänsterna som gemensam funktion att den mening som uppläses markeras. Detta gav upphov till ett nytt krav. Friendlyreader har sedan tidigare haft funktionen att få text uppläst och även projektet Begriplig text (Hedberg m. fl., 2018) har visat att få texten uppläst samtidigt som man läser kan hjälpa förståelsen. Grammarly är en AI-driven produkt som hjälper användaren att upptäcka exempelvis stavfel och grammatiska fel i sitt skrivande (Grammarly Inc., 2019). Produkten kan användas genom att klistra in text i en texteditor eller installera den direkt i en webbläsare. Denna produkt är inte avsedd för att underlätta läsning men gav upphov till en möjlig funktionalitet hos Friendlyreader. När ett ord är exempelvis felstavat blir det rödmarkerat av Grammarly och produkten erbjuder då alternativa stavningar som passar bättre. Denna möjlighet gavs även i Friendlyreader genom att presentera synonymer för ord. Dock fanns inte möjligheten att byta ut ett ord mot en synonym likt man kan byta ut ett felstavat mot ett rättstavat i Grammarly. Detta resulterade i ytterligare ett funktionellt krav, användaren skall kunna byta ut ord mot synonymer. För att användaren ska tillåtas att utforska denna funktionalitet fanns behovet av att ångra utbytet av ett ord mot en synonym. Detta resulterade i ytterligare ett krav baserat på teori om att ångra handlingar enligt bland annat Goodwin (2009), se Tabell 4. Tabell 4: Krav baserade på liknande verktyg Kravbeskrivning Den text som uppläses ska markeras mening för mening Användaren ska kunna byta ut ord mot synonymer Användaren ska kunna ångra utbytet av ett ord mot en synonym Kravtyp Funktionellt Funktionellt Funktionellt 14

22 4.2.2 Kravanalys Kravanalysen utfördes med kravinsamlingen som underlag och inga av de insamlade kraven valdes att tas bort utan samtliga krav inkluderades i den slutliga kravspecifikationen. Den slutliga kravspecifikation utgick från användarkraven och gavs ett nummer mellan 1 och 17. Systemkrav samt gränssnittskrav gavs ett nummer för att enkelt se vilket användarkrav de tillhörde, exempelvis systemkrav 2.1 tillhörde användarkrav 2. En del av användarkrav var beroende av varandra, detta specificeras under kolumnen Beroenden. Detta innebar att ett användarkrav krävde att ett annat krav redan var implementerat, se tabell 5. 15

23 Tabell 5: Användarkrav Nummer Kravbeskrivning Beroenden 1 Användaren skall kunna föra in text på webbsidan 2 Användaren skall kunna analysera texten 3 Användaren skall kunna se textens viktigaste 2 meningar 4 Användaren skall kunna sammanfatta 2 texten fram och tillbaka 5 Användaren bör kunna se borttagna 2; 4 meningar från sammanfattaren 6 Användaren skall kunna förenkla texten 2 på olika sätt 7 Användaren bör ges förslag på meningsförenklingar 2 8 Användaren skall kunna se och ändra 2 ord med synonymer 9 Användaren bör kunna se emojis som 2 illustrerar ordets semantiska innebörd som en synonym. 10 Användaren skall kunna ångra utbytet av ett ord mot en synonym 2 11 Användaren skall kunna få texten uppläst 12 Användaren skall kunna se textkomplexitet 2 illustrerat genom ett diagram 13 Användaren skall kunna se meta-data 2 om texten 14 Användaren skall kunna gå tillbaka till det initiala analyserade tillståndet 15 Användaren skall kunna ändra grafiska funktioner hos texten 16 Användaren skall kunna använda verktyg för att underlätta läsning av text 17 Användaren skall kunna läsa information om verktyget Specifikationen resulterade i ett antal bör-krav, för användarkraven var det följande; nummer 5. Användare bör kunna se borttagna meningar från sammanfattaren, 7. Användaren bör ges förslag på meningsförenklingar och 9. Användaren bör kunna se emojis som illustrerar ordets semantiska innebörd som en synonym.. Att användaren skulle kunna se borttagna meningar från sammanfattaren var ett krav som uppstod då detta var en funktionalitet som fanns implemente- 16

24 rad i TeCST. Det var svårt att avgöra hur användbar denna funktionalitet är för användare inom målgruppen för Friendlyreader och av den anledningen kändes kravet inte prioriterat och angavs som ett bör-krav. För att möjliggöra att flera av resterande krav kunde implementeras togs beslutet att göra nummer 7 till ett bör-krav. Användaren skall kunna förenkla texten men att meningsförslag skall ges prioriterades ned. Att se emojis som synonymer till ord är en funktionalitet som fanns implementerad i TeCST men några stora undersökningar som stödjer användandet av detta fanns inte. Av den anledningen ansågs detta komplement till Friendlyreader vara ett bör-krav. Nedan följer Tabell 6 och Tabell 7 innehållandes system- och gränssnittskraven. Tabell 6: Systemkrav Nummer Kravbeskrivning 1.1 Systemet skall möjliggöra att infoga text på webbsidan 2.1 Om texten inte kan analyseras skall användaren informeras efter några sekunder 2.2 Systemet skall returnera en lista över meningar och deras betydelseordning 2.3 Systemet skall returnera en lista med meningar och dess förenklingsförslag 2.4 Systemet skall returnera synonymer. 2.5 Systemet bör kunna hantera emojis 2.6 Systemet skall returnera information om textkomplexitet och meta-data 6.1 Systemet skall returnera förenklade meningar baserat på användarinmatning 10.1 Systemet skall kunna hålla reda på tillståndsövergångar för historikfunktionalitet 14.2 Systemet skall alltid behålla initialtillståndet 17

25 Tabell 7: Gränssnittskrav Nummer Kravbeskrivning 2.7 Gränssnittet skall förse användaren med visuell feedback när analysen är pågående 11.1 Texten som uppläses bör markera den aktuella meningen 12.1 Gränssnittet skall visa förklaringar av komplexitetmått 15.1 Gränssnittet skall stödja förändring i teckensnittsstorlek, typsnitt, radavstånd och textbredd Gränssnittet skall tillhandahålla en läslinjal med olika utseenden och justerbar höjd Systemkrav 2.5 prioriterades som ett bör-krav då användarkrav 9 gavs samma prioritering och de båda berör emojis. Även gränssnittskrav 11.1 prioriterades som ett bör-krav då inget mer än att funktionaliteten fanns hos ett liknande verktyg med uppläsning av text som enda fokus och inget annat från kravinsamlingen kunde motivera att få den aktuella meningen markerad under läsning kan underlätta läsning så prioriterades detta som ett bör-krav. Se Bilaga A för en komplett sammanställning av den slutgiltiga kravspecifikationen. 18

26 5 Implementation Implementationen av det nya gränssnittet skapades i HTML, CSS och Java- Script. Dessa tre språk används vanligtvis vid frontend-utveckling, den typ av utveckling som direkt relaterar till webbläsaren (Niederst Robbins, 2018). HTML står för HyperText Markup Language och är ett markup-språk. Det används för att skapa och strukturera upp webbsidedokument. I HTML anges de komponenter som dokumentet består av. CSS står för Cascading Style Sheets och används för att beskriva utseendet hos komponenterna på hemsidan, exempelvis färg, storlek och placering. JavaScript (JS) är ett skriptspråk som adderar interaktivitet och beteende till en webbsida (Niederst Robbins, 2018) och är det mest använda programmeringsspråket idag (Toledo, 2018). Majoriteten av implementationen skapades i JS och användes då det är ett lätt men väldigt kraftigt skriptspråk. Användandet av JS-ramverk är vanligt och förser utvecklaren med mallar och färdiga komponenter som kan användas (Morris, 2019). En av fördelarna med att använda ramverk är att man undviker att utveckla allt från grunden, men framförallt så tillhandahåller ramverk hjälp och kan minska tiden som utvecklingsprocessen tar (Hjelm, 2015). Däremot kan det vara svårt och tidskrävande att lära sig ett ramverk och inte alltid nödvändigt för att utveckla en grundläggande applikation. Då framtida utveckling av Friendlyreader mest sannolikt kommer att ske av en annan individ togs beslutet att inte använda något ramverk då detta hade förutsatt kunskap hos den individen inom det valde ramverket. Kravspecifikationen fungerade som utgångspunkt vid implementationen. 5.1 Språkteknologisk funktionalitet Vid ett tidigt skede i implementationen blev det uppenbart att de framtagna kraven krävde ett mer flexibelt gränssnitt för att stödja den utökade funktionaliteten angiven i kravspecifikationen. Beslutet togs då att utgå från en ny grunddesign, se Figur 1. Flertalet av kraven i specifikationen var baserade på funktionalitet som redan fanns implementerad i Friendlyreader och mycket kod kunde således bevaras med en del anpassningar efter det nya gränssnittet. Alla de krav i specifikationen som prioriterades som skall-krav lyckades implementeras under utvecklingsarbetet men samtliga bör-krav hann inte implementeras och beslutet togs att fördröja dessa till framtida utvecklingsarbete av verktyget. 19

27 (a) Första sidan (b) Läsvyn Figur 1: Gränssnittet hos den nya implementationen av Friendlyreader Funktionalitet som förändrar textens innehåll på något sätt är funktionerna Sammanfatta text, Förenkla text samt Visa synonymer. Under implementationen togs beslutet att göra dessa samverkande. Något som innebar att funktionaliteten inte utgick från originaltexten utan från den aktuella utformningen av texten. En text som var sammanfattad kunde således förenklas utifrån sin nuvarande utformning. Detta beslut togs för att skapa ett mer användbart och flexibelt verktyg Förenkla text Att möjliggöra för användaren att förenkla text var specificerat i krav 6 i kravspecifiktionen. I den tidigare versionen av Friendlyreader förenklades texten utifrån de fem regler som presenterades i teorin. I den nya implementationen skapades valmöjligheten för användaren att välja på vilket sätt texten skall förändras. Detta presenterades genom fem olika checkboxar där samtliga förenklingsregler är förvalda, se Figur 2. Under dessa checkboxar implementerades en knapp där användaren kunde välja att trycka på knappen och därmed skickades en förfrågan till servern med den aktuella texten som finns i textfältet och de valda förenklingsreglerna som argument. 20

28 (a) Sidomeny (b) Förenklingsregler Figur 2: Sidomeny och förenklingsregler En lyckad förfrågan till servern returnerade en datastruktur innehållandes de meningar med förenklingsförslag som lyckades identifieras. För varje mening fanns information om vilken förenklingsregel som var aktuell, exempelvis från passiv till aktiv form, originalmeningen samt en mening som var förenklad enligt angiven regel. För att ersätta den aktuella texten med de förenklingsförlag kontrollerades först vilka meningar i texten som hade förenklingar. Meningarna jämfördes då från den aktuella texten med den originalmening som inkluderades i datastrukturen som skickades från servern. I de fall där en mening stämde överens hämtades förenklingsförlaget från datastrukturen för den aktuella meningen och ersatte dess original i texten som skall uppvisas för användaren. Efter att hela texten bearbetats och meningar ersatts med förenklingsförslag presenterades sedan den nya texten för användaren i textfältet. Funktionen för att förenkla text implementerades samverkande med resterande funktioner och utgick därmed från textens aktuella utformning. Detta innebär att om texten sedan tidigare var exempelvis sammanfattad utgick funktionen från den sammanfattade texten och inte den ursprungliga. 21

29 5.1.2 Sammanfatta text Även sammanfattaren implementerades för att samverka med resterande funktioner och utgick därmed även från textens aktuella tillstånd. När denna funktion valdes i sidomenyn skickades en förfrågan genom SAPIS till Scream för att få information om textens storlek. Denna information var nödvändig för att ge ett maxvärde till det dragreglage (eng. slider) som användes för att anpassa storleken på den sammanfattade texten. Detta dragreglade uppvisades när funktionen valdes från sidomenyn. Ett förfrågan skickades även till servern med den aktuella texten för att få tillbaka en rangordning av textens meningar. Vid en lyckad förfrågan till servern returnerades två olika listor. En lista där varje element representerades av en mening från texten samt en ytterligare lista innehållandes siffror som representerade meningarnas rangordning. Varje mening var placerad på samma index i listan som dess rangordning i den andra listan. Storleken på den sammanfattade texten anpassades efter det värde som användaren angett genom dragreglaget, värdet representerade därmed antalet meningar som den sammanfattade texten skulle innehålla. Valde således användaren att sammanfatta texten till exempelvis 20 meningar av 40 totalt så exkluderades de 20 meningar med lägst rank från texten. Att implementera sammanfattaren på detta sätt bevarade en så sammanhängande text som möjligt. Implementationen av draggreglaget möjliggjorde för användaren att sammanfatta texten fram och tillbaka utan att skicka upprepande förfrågningar till servern då all information fanns kvar på klientsidan Visa synonymer För att uppvisa synonymer för användaren hämtades textens aktuella utformning och skickades som en förfrågan till servern. Denna förfrågan är den mest tidskrävande av funktionerna, baserat på textens storlek kunde det ta lite längre tid för att servern att bearbeta förfrågan. Vid en lyckad förfrågan så returnerades en datastruktur med information om de ord i texten som synonymer lyckades identifieras för. I datastrukturen fanns information om vilka ord som synonymer hittades för, alla de synonymer som identifierades för respektive ord samt vilken frekvensnivå varje synonym hade. En hög frekvensnivå innebar att synonymen ansågs väl passande. Från denna information extraherades de tre synonymer med högst nivå för respektive ord för att presentera detta för användaren i gränssnittet. De ord som hade synonymer upplystes genom en gul understrykning. Detta designval kommunicerade till användaren vilka ord som hade synonymer, något som var inspirerat från Grammarly, både i utseendet men även att synonymer uppvisades under ordet. Genom att föra musen över ett understruket ord uppvisades synonymförslagen. När användaren hovrade över synonymerna ändrades bakgrunds- och textfärg samt muspekaren blev till en hand för att förmedla till användaren att dessa olika ordrutor var tryckbara, se Figur 3. Genom att trycka på en av synonymerna skedde ett utbyte i texten mellan ordet och den valda synonymen. 22

30 Figur 3: Synonymer till ordet förklaringar uppvisas Då ett av kraven i specifikationen var möjligheten att ångra ett utbytt ord så implementerades detta genom en tillståndsmaskin framtagen av Holmstedt (2019). Denna tillståndsmaskin höll reda på textens versioner och skapade ett ursprungstillstånd vid aktivering av synonymer och sedan ett nytt tillstånd efter varje utbyte mot en synonym. På så vis kunde användaren enkelt återgå till en tidigare version av texten genom att trycka på den ångra-ikon som uppvisades i huvudmenyn. Denna funktion implementerades således kronologiskt, vilket innebär att det alltid var det senaste tillståndet som återgavs. Möjligheten att ångra utbytet av en synonym var endast möjligt i det tillstånd då synonymer var aktiverade. Valde användaren att inaktivera synonymer för att aktivera dem på nytt igen skickades en ny förfrågan till servern och ett nytt ursprungstillstånd skapades av tillståndsmaskinen. De tidigare ersatta orden kunde då inte ångras. Detta beror på att implementationen inte håller reda på om texten förändrats mellan det att förfrågningar skickats till servern för att hämta synonymer och kan således inte veta om de tidigare tillstånden är aktuella eller inte. Synonymer kunde implementerades som samverkande med resterande funktionalitet genom att låta en ny förfrågan skickas till servern med den aktuella texten när användaren valde att aktivera synonymer. Detta var nödvändigt då synonymer används i det syfte att underlätta för personer att förstå komplexa ord utan att förstöra meningsbyggnaden. Har användaren valt att sammanfatta eller förenkla en text utesluter detta inte att komplexa eller långa ord förblir i texten där användarens behov av synonymer kvarstår. Med denna samverkande implementation tillåter det användaren att visa synonymer för orden i en sammanfattad eller förenklad text. 23