Link¨
opings universitet
Institutionen f¨
or datavetenskap
Kognitionsvetenskapliga programmet
Kandidatuppsats 18 hp
V˚
arterminen 2019
ISRN-nummer: LIU-IDA/KOGVET-G–19/007–SE
Ett nytt Friendlyreader
– implementationen av ett gr¨
anssnitt med
fokus p˚
a spr˚
akteknologiska funktioner
Malin W¨
angelin
Examinator: Robert Eklund
Handledare: Arne J¨
onsson
Datum 2019-06-06
Link¨
opings universitet
581 83 Link¨
oping
Upphovsr¨
att
Detta dokument h˚alls tillg¨angligt p˚a Internet – eller dess framtida ers¨attare – fr˚an publiceringsdatum under f¨oruts¨attning att inga extraordin¨ara
omst¨andigheter uppst˚ar. Tillg˚ang till dokumentet inneb¨ar tillst˚and f¨or var och en att l¨asa, ladda ner, skriva ut enstaka kopior f¨or enskilt bruk och att anv¨anda det of¨or¨andrat f¨or ickekommersiell forskning och f¨or undervisning. ¨Overf¨oring av upphovsr¨atten vid en senare tidpunkt kan inte upph¨ava detta tillst˚and. All annan anv¨andning av dokumentet kr¨aver upphovsmannens medgivande. F¨or att garantera ¨aktheten, s¨akerheten och tillg¨angligheten finns l¨osningar av tek-nisk och administrativ art. Upphovsmannens ideella r¨att innefattar r¨att att bli n¨amnd som upphovsman i den omfattning som god sed kr¨aver vid anv¨andning av dokumentet p˚a ovan beskrivna s¨att samt skydd mot att dokumentet ¨andras eller presenteras i s˚adan form eller i s˚adant sammanhang som ¨ar kr¨ankande f¨or upphovsmannens litter¨ara eller konstn¨arliga anseende eller egenart. F¨or ytterli-gare information om Link¨oping University Electronic Press se f¨orlagets hemsida http://www.ep.liu.se/.
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 anyo-ne 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. Sub-sequent 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 authentici-ty, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described abo-ve and to be protected against infringement. For additional information about the Link¨oping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/.
c
Sammanfattning
Syftet med detta arbete var att implementera ett fungerande verktyg f¨or att underl¨atta l¨asning av text med fokus riktat mot spr˚akteknologiska funktioner. Det digitala verktyget Friendlyreader ¨ar framtaget f¨or att underl¨atta l¨asning av text f¨or individer med l¨assv˚arigheter, som exempelvis kan bero p˚a dyslexi eller en funktionsneds¨attning. Detta arbete har genom en f¨orstudie kartlagt vilken funktionalitet som efterfr˚agas och finns tillg¨anglig hos liknande verktyg som ¨
amnar att underl¨atta l¨asning. Detta har legat till grund f¨or implementationen av ett funktionellt gr¨anssnitt som bygger p˚a spr˚akteknologiska funktioner som tillhandah˚alls fr˚an en fj¨arrservern genom SAPIS REST API. Under implemen-tationen togs beslutet att g¨ora funktionaliteten samverkande f¨or att skapa ett mer flexibelt verktyg. Detta inneb¨ar att text som exempelvis blivit f¨orenklad ¨
aven kan bli sammanfattad, funktionaliteten utg˚ar s˚aledes fr˚an textens aktuella utformning och inte dess original. Implementationen genomgick tester d¨ar all funktionalitet med fokus p˚a spr˚akteknologi fick ett godk¨ant 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 Friend-lyreader 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 fea-tures 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.
Inneh˚
all
Upphovsr¨att Sammanfattning 1 Inledning 1 1.1 Relaterat arbete . . . 1 1.2 Syfte . . . 2 1.3 Avgr¨ansningar . . . 2 2 Bakgrund 3 2.1 F¨orenkla text . . . 3 2.2 Sammanfatta text . . . 3 2.3 Textkomplexitetsm¨atning . . . 4 2.4 Synonymer . . . 4 3 Teori 5 3.1 Krav . . . 5 3.1.1 Kravinsamling . . . 5 3.1.2 Kravanalys . . . 6 3.2 Gr¨anssnittsdesign . . . 7 3.2.1 ˚Aterkoppling . . . 7 3.2.2 ˚Angra handling . . . 7 3.2.3 Design f¨or alla . . . 7 3.3 Test . . . 8 3.3.1 Dynamiska tester . . . 8 3.3.2 Testfall . . . 8 4 F¨orstudie 10 4.1 Metod . . . 10 4.1.1 Kravinsamling . . . 10 4.1.2 Kravanlys . . . 104.2 Resultat och Diskussion . . . 11
4.2.1 Kravinsamling . . . 11 4.2.2 Kravanalys . . . 15 5 Implementation 19 5.1 Spr˚akteknologisk funktionalitet . . . 19 5.1.1 F¨orenkla text . . . 20 5.1.2 Sammanfatta text . . . 22 5.1.3 Visa synonymer . . . 22
5.2 Gr¨anssnittsdesign . . . 25 5.2.1 ˚Aterkoppling . . . 25 6 Test 27 6.1 Metod . . . 27 6.2 Resultat . . . 27 7 Diskussion 29 7.1 F¨orstudie . . . 29 7.2 Implementation . . . 30 7.3 Test . . . 31 7.4 Framtida arbete . . . 32 8 Slutsats 34 Referenser 35 Bilagor 36 A Kravspecifikation 37 B Testspecifikation 39 C Felrapport 49
Tabeller
1 Resulterande krav fr˚an kartl¨aggning av funktionaliteten hos
Fri-endlyreader . . . 11
2 Resulterande krav fr˚an kartl¨aggning av funktionaliteten hos TeCST 12 3 Krav baserade p˚a tidigare studier . . . 13
4 Krav baserade p˚a liknande verktyg . . . 14
5 Anv¨andarkrav . . . 16
6 Systemkrav . . . 17
7 Gr¨anssnittskrav . . . 18
Figurer
1 Gr¨anssnittet hos den nya implementationen av Friendlyreader . . 20 2 Sidomeny och f¨orenklingsregler . . . 21 3 Synonymer till ordet f¨orklaringar uppvisas . . . 23 4 Positiv och negativ ˚aterkoppling p˚a anv¨andarens handlingar d¨ar
1
Inledning
Att l¨asa och f¨orst˚a text ¨ar n˚agot som utg¨or en v¨asentlig del av v˚ara liv och en skicklighet vi l¨ar oss tidigt i livet f¨or att senare anv¨anda oss av f¨or att skaffa ny kunskap. Svenska statistiskmyndigheten (SCB) deltog 2013 i en internationell studie d¨ar f¨ardigheter hos vuxna personer unders¨oktes. Denna studie visade att cirka 13 % av den svenska befolkningen har en l¨asf¨ardighet p˚a niv˚a 1. Indivi-der p˚a den niv˚an kan l¨asa kortare texter med tillg˚ang till ett grundl¨aggande ordf¨orr˚ad d¨ar det inte ¨ar s¨akert att dessa personer kan ta till sig inneb¨orden av en text eller f¨orst˚a dess struktur. Enligt myndigheten f¨or tillg¨angliga medi-er har mmedi-er ¨an en halv miljon svenskar problematik med att l¨asa tryckt text, n˚agot som kan bero p˚a funktionsneds¨attning, dyslexi eller en sjukdom som g¨or det sv˚art att koncentrera sig p˚a text (MTM, 2019). Detta kan medf¨ora att fler personer med denna problematik r¨or sig till digitala medier som exempelvis talb¨ocker och taltidningar, f¨or att utnyttja sina andra sinnen. Man kan se att elektroniskt material ¨okar inom den akademiska sektorn d˚a mycket material ¨ar webb- eller datorbaserat (Nandhini & Balasundaram, 2013). Detta medf¨or en viss problematik; detta material beh¨over fortfarande vara l¨asbart och f¨orst˚aeligt f¨or alla, n˚agot som m¨ojligg¨or f¨or spr˚akteknologi att skapa b¨attre f¨oruts¨attningar f¨or personer med denna sv˚arighet. Man har i tidigare studier sett att exempel-vis ha m¨ojligheten att sammanfatta en text ¨ar betydelsefullt f¨or personer med l¨assv˚arigheter (Gajria, Jitendra, Sood & Sacks, 2009).
F¨or att ¨oka denna inkludering har projektet DigInclude initierats och syf-tar till att f¨orb¨attra offentlig sektors digitala tillg¨anglighet f¨or medborgare med s¨arskilda behov (J¨onsson, 2018). Detta projekt har tagit fram tv˚a webbaserade tj¨anster; TeCST, med syftet att underl¨atta f¨or skribenter att skriva l¨attl¨asta tex-ter samt Friendlyreader, ett l¨asverktyg framtaget f¨or att underl¨atta l¨asning f¨or personer med l¨as- och skrivsv˚arigheter. Detta inkluderar personer med nedsatt syn, dyslexi, funktionsneds¨attning samt personer som ¨ar nya till det svenska spr˚aket. I Friendlyreader erbjuds bland annat m¨ojligheten att sammanfatta, f¨orenkla samt m¨ata komplexiteten hos text. Vad som g¨or en text l¨att att l¨asa ¨
ar inte detsamma f¨or alla, oavsett kognitiv neds¨attning eller inte. Att ta fram ett verktyg som ¨ar anpassat f¨or s˚a m˚anga som m¨ojligt ¨ar utmaning. Ett steg p˚a v¨agen ¨ar att unders¨oka vilken typ av funktionalitet som efterfr˚agas hos personer med l¨assv˚arigheter f¨or att implementera det i ett digital verktyg som Friendly-reader, n˚agot som detta arbete ¨amnar att g¨ora.
1.1
Relaterat arbete
Projektet Begriplig text har unders¨okt vad som g¨or en text enkel att l¨asa och f¨orst˚a med m˚alet att upplysa skribenter och journalister och hj¨alpa dem att skriva texter som ¨ar mer inkluderande (Hedberg, Eltebo, Lundgren, Rydin &
breda rader f¨or att underl¨atta l¨asning. Projektet har ¨aven visat att m¨ojligheten att kunna f¨orstora texten ¨ar efterfr˚agat hos bland annat personer med dyslexi och spr˚akst¨orningar. En av projektets exempell¨asare, ”Lova”, har sv˚arigheter med att l¨asa text och ¨ar i behov att ett l¨asverktyg. Tv˚a saker hon prioriterar som viktiga ¨ar att f˚a texten sammanfattad och att det viktigaste ska komma f¨orst. Detta menar denna exempell¨asare ¨ar viktigt f¨or att f¨orst˚a och l¨asa text. Samma behov ˚aterfinns hos de flesta av projektets framtagna exempell¨asare. En exempell¨asare ¨ar ingen identifierbar person utan representerar en t¨ankbar l¨asare fr˚an projektets deltagargrupper d¨ar f¨orm˚agor och egenskaper ¨ar en sam-manst¨allning fr˚an projektets resultat. Denna beskrivning ¨ar mycket lik den som Arvola (2014) anv¨ander f¨or att f¨orklara personor. ¨Aven projektet EasyReader (2012), som ¨ar riktat mot personer med l¨assv˚arigheter, har tagit fram personor som uttrycker liknande behov. ”Frida”, projektets prim¨arpersona, uttrycker att hon ibland l¨aser en sammanfattning av texten f¨orst. Att veta vad texten handlar om underl¨attar f¨or Frida n¨ar det kommer till att f¨orst˚a textens inneh˚all. Finns det ingen sammanfattning tillg¨anglig kan ett spr˚akteknologiskt verktyg likt en textsammanfattare l¨osa detta problem. I dagsl¨aget finns det inte m˚anga verktyg som erbjuder denna funktionalitet, n˚agot som skulle kunna hj¨alpa skribenter, men fr¨amst underl¨atta l¨asning av texter som inte initialt ¨ar utformade p˚a ett l¨attl¨ast s¨att. Detta m¨ojligg¨or f¨or individer med l¨assv˚arigheter att ta till sig ett st¨orre antal texter.
1.2
Syfte
Denna studie har riktat fokus mot spr˚akteknologisk funktionalitet hos verktyg som ska underl¨atta l¨asning av text. Genom att unders¨oka vilken typ av funktio-nalitet som efterfr˚agas av anv¨andare och finns hos andra verktyg ¨amnar detta arbete implementera ett mer funktionellt gr¨anssnitt f¨or verktyget Friendlyrea-der. Syftet med arbetet var att implementera ett fungerande verktyg och genom tester s¨akerst¨alla att implementationen var fungerande.
1.3
Avgr¨
ansningar
Flertalet studier med fokus p˚a anv¨andare inom m˚algruppen f¨or Friendlyre-ader var redan utf¨orda och av denna anledningen utf¨ordes ingen anv¨ andar-unders¨okning utan dessa studier inkluderas i den f¨orstudien som l˚ag till grund f¨or implementationen. Fokus f¨or arbetet var att implementera spr˚akteknologiska funktioner och visualisera dem i ett gr¨anssnitt. Detta ¨ar s˚aledes ett arbete in-riktat mot utveckling och inte design.
2
Bakgrund
Friendlyreader anv¨ander sig av SAPIS REST API, ett API som tillhandah˚aller olika spr˚akteknologiska funktioner fr˚an en fj¨arrserver (Falkenjack, Rennes, Fahl-borg, Johansson & J¨onsson, 2017). Dessa funktioner ¨ar framtagna f¨or att g¨ora text l¨attare att f¨orst˚a och innefattar textf¨orenkling, textsammanfattning, text-komplexitetsm¨atning, samt synonymer.
2.1
F¨
orenkla text
Syftet med att f¨orenkla text ¨ar att minska komplexiteten hos en text f¨or att ¨
oka f¨orst˚aelsen hos l¨asaren (Rennes & J¨onsson, 2015). Att kunna f¨orenkla text automatiskt kan anses f¨ordelaktigt d˚a utf¨orandet av en s˚adan manuell process ¨
ar tidskr¨avande. Verktyget som anv¨ands f¨or att f¨orenkla text kallas StilLett och inneh˚aller flera typer av f¨orenklingar, dessa anv¨ands i Friendlyreader:
1. Passiv till aktiv form 2. Citatomv¨andning 3. Rak ordf¨oljd 4. Meningsuppdelning 5. Proximering
Att ¨andra fr˚an passiv till aktiv form inneb¨ar att subjektet i den passiva me-ningen blir till ett objekt i den aktiva meme-ningen, ordet ”av”, tas bort och s-slut f¨orsvinner (Rennes & J¨onsson, 2015). Att utf¨ora en citatomv¨andning inneb¨ar att ¨andra plats hos talaren i ett citat, exempelvis fr˚an ”sa Lisa” till ”Lisa sa”. Denna regel genomf¨ors genom att f¨ors¨oka identifiera citattecken f¨oljt av ord som antyder att ett citat har yttrats, exempelvis ”sade” eller ”utbrast”. Lyckadas detta identifieras s˚a byter verbfrasen plats med substantivfrasen. Att f¨orenkla texten genom Rak ordf¨olj inneb¨ar att satser som ¨ar initierade med adverb eller adjektiv f¨or¨andrar ordf¨oljden. Meningen ”Ig˚ar k¨opte Maja en glass” f¨or¨andras d˚a till ”Maja k¨opte en glass ig˚ar”. Regeln Meningsuppdelning delar upp en me-ningar genom att identifiera kommatecken och delar upp meningen fr˚an detta skiljetecken. Sist kvarst˚ar proximering. Denna regel ¨amnar att f¨ora texten psy-kologiska n¨armare anv¨andaren (Kousta, 2016), exempelvis genom att byta ut ”man” mot ”du”.
F¨or att se de spr˚akteknologiska regler som ligger till grund f¨or de olika ope-rationerna h¨anvisas till Rennes och J¨onsson (2015).
Danielsson & J¨onsson, 2012). Meningarna rangordnas och presenteras sedan som en komprimerad version av originalet. F¨or att utf¨ora detta anv¨ander sam-manfattaren en ordrymdsmodell kallad Random Indexing (RI) som ¨ar tr¨anad p˚a ordvektorer och ovan p˚a den modellen anv¨ands sedan en variation av algoritmen PageRank f¨or att extrahera de meningar som delar den viktigaste informationen.
2.3
Textkomplexitetsm¨
atning
Scream ¨ar en separat service som omfattar 117 komplexitetsm˚att och kan n˚as ge-nom SAPIS (Falkenjack m. fl., 2017). En del av dessa komplexitetsm˚att anv¨ands i Friendlyreader f¨or att illustrera textkomplexitet i ett diagram. I detta dia-gram uppvisas exempelvis l¨asbarhetsm˚att som ordvariationsindex (OVIX) och l¨asbarhetsindex (LIX). Ordvariationsindex ¨ar ett m˚att p˚a hur m˚anga unika ord som f¨orekommer i en text i f¨orh˚allande till textens alla ord (Rybing & Smith, 2010). L¨asbarhetsindex anv¨ands som ett m˚att f¨or att ge en uppfattning om hur l¨att eller sv˚ar en text ¨ar att l¨asa (Bj¨ornsson, 1968). Ut¨over dessa m˚att upp-visas ¨aven genomsnittlig meningsl¨angd, genomsnittlig ordl¨angd, andel bisatser, meningsdjup samt SweVoc (Total) i diagrammet.
2.4
Synonymer
Tidigare studier har visat att personer med dyslexi upplever problem med kom-plexa ord, exempelvis ovanliga eller l˚anga ord (Rello, Baeza-Yates, Bott & Sag-gion, 2013). F¨or att underl¨atta f¨or personer med denna sv˚arighet att l¨asa kan man erbjuda synonymer som ers¨attning f¨or ord som upplevs som sv˚ara utan att f¨orst¨ora meningsbyggnaden. Den synonymfunktion som finns i Friendlyreader anv¨ander Synlex lexikon (Kann, 2013), som ¨ar en ¨oppen k¨alla och inneh˚aller ungef¨ar 80 000 synonympar (Rennes & J¨onsson, 2015). P˚a lexikonets webbsida finns det m¨ojlighet f¨or allm¨anheten att betygs¨atta hur korrekt tv˚a synonympar anses vara. Resultatet fr˚an dessa betygs¨attningar kan sedan h¨amtas fr˚an en fre-kvenslista. Detta lexikon anv¨ander sig Friendlyreader av f¨or att identifiera vilka av orden i texten som har synonymer och h¨amtar sedan ut de synonymer med h¨ogst frekvens.
3
Teori
I detta avsnitt presenteras teoretisk information om krav, gr¨anssnittsdesign samt test.
3.1
Krav
Innan man p˚ab¨orjar utvecklingen av ett nytt system vill man unders¨oka hur det ska anv¨andas av m˚algruppen och vad systemet skall kunna g¨ora (Sommerville, 2005). Processen f¨or att ta reda p˚a detta kallas f¨or kravteknik (eng. Requirements engineering). Ett krav ¨ar en beskrivning av vad systemet ska kunna g¨ora och p˚a vilket s¨att, men ¨aven vad systemet inte ska klara av. De specificerade kraven ska reflektera den t¨ankta m˚algruppens m˚al och behov (Sommerville, 2011). Wiktorin (2018, s. 196) definierar krav p˚a f¨oljande s¨att:
”Ett krav ¨ar en ¨onskv¨ard egenskap eller funktion hos ett IT-system eller en produkt.”
I denna del presenteras ett tillv¨agag˚angss¨att f¨or att ta fram krav f¨or ett system, detta inkluderar en kravinsamling och en kravanalys.
3.1.1 Kravinsamling
Ett tillv¨agag˚angss¨att f¨or att identifiera krav som kommer att st¨alla p˚a ett sy-stem, gr¨anssnitt eller interaktionen mellan anv¨andare och system ¨ar att utf¨ora en kravinsamling. Detta ¨ar en process d¨ar information samlas in om nuvaran-de och liknannuvaran-de verktyg f¨or att identifiera anv¨andar- och systemkrav fr˚an in-formationsk¨allor, exempelvis systemdokumentation, intressenter och anv¨andare (Sommerville, 2011). Denna information samlas vanligtvis in genom intervjuer, scenarion eller anv¨andarfall. Intervjuer ¨ar ofta ett effektivt s¨att att f˚a en bra ¨
overblick hur m˚algruppen anv¨ander ett system eller vilka problem som de upple-ver. F¨or att f˚a ut s˚a mycket som m¨ojligt fr˚an intervjuer kan det vara effektivt att b˚ade anv¨anda sig av st¨angda och ¨oppna intervjuer. Vilket inneb¨ar att en intervju utf¨ors med ett antal f¨orutbest¨amda fr˚agor men ¨aven utan f¨ordefinierad agenda. Detta f¨or att utforska bredden av problem hos ett system utan att begr¨ansa sig till de f¨orutbest¨amda fr˚agorna. Detta kan bidra till en b¨attre f¨orst˚aelse f¨or de be-hov som anv¨andarna har. Anv¨andandet av scenarion kan g¨ora denna f¨orst˚aelse ¨
annu djupare. Det ¨ar vanligt att personer har l¨attare att f˚a en f¨orst˚aelse f¨or anv¨andandet av ett system n¨ar det kan s¨attas i vardagliga kontexter, n˚agot som kan bidra till att kraven blir mer detaljerade. Ett scenario beskriver exempel p˚a hur interaktionen sker mellan anv¨andaren och systemet. Ofta inkluderar ett sce-nario ett naturligt tillv¨agag˚angs¨att av anv¨andandet, anv¨andarens f¨orv¨antningar, vad som kan g˚a fel och hur detta hanteras. Slutligen finns anv¨andarfall som ett tillv¨agag˚angss¨att f¨or att identifiera krav. Anv¨andarfall specificeras i
UML-3.1.2 Kravanalys
De krav som identifieras under kravinsamlingen beh¨over analyseras f¨or att se om de ¨ar m¨ojliga att utf¨ora fr˚an ett system- och tidsperspektiv (Sommerville, 2011). En s˚adan process kr¨aver f¨orhandling och prioritering av krav. Samtliga krav som identifierats under insamlingen skall analyseras. Kravspecifikationen ¨ar vad som senare fungerar som en utg˚angspunkt f¨or utvecklingsarbetet av ett nytt system. Specifikationen beskriver d˚a vad systemet ska kunna klara av samt vil-ken tj¨anst systemet erbjuder. M˚alet ¨ar att specifikationen ska reflektera behovet hos anv¨andaren. Det ¨ar av stor betydelse att kraven inkluderade i specifikatio-nen formuleras p˚a ett s¨att s˚a att de blir testbara. Detta inneb¨ar att problemet beskrivs snarare ¨an att en l¨osning presenteras (Ostroff & Torshizi, 2007) och en framtida implementation kan s˚aledes testas mot kravspecifikationen. Man vill fokusera p˚a att formulera vad kravet omfattar s˚a att det ¨aven g˚ar att avg¨ora till vilken grad ett krav ¨ar uppfyllt i det slutliga systemet (Wiktorin, 2018). Ett v¨alformulerat krav ¨ar inte tvetydigt och ska inte kunna misstolkas, man b¨or i st¨orsta m¨ojliga utstr¨ackning undvika missf¨orst˚and. Detta ¨ar s¨arskilt viktigt n¨ar det g¨aller krav som kategoriseras som systemkrav d˚a denna typ av krav riktar sig mot de individer som sk¨oter utvecklingen av systemet (Sommerville, 2011). Kraven b¨or ¨aven ben¨amnas som skall- och b¨or-krav f¨or att f¨ormedla vil-ken niv˚a kravet har. Det ¨ar av betydelse att f¨olja riktlinjer f¨or anv¨andandet av ord i krav f¨or att f¨ormedla dess inneb¨ord p˚a ett korrekt s¨att. Ett skall-krav inneb¨ar att det ¨ar ett absolut krav och m˚aste finnas med i den f¨ardiga tj¨ansten (Bradner, 1997) . Ett krav som inte ¨ar ett absolut krav ¨ar rekommenderat och kallas b¨or-krav. Ett s˚adant krav kan ignoreras fr˚an specifikationen under vis-sa omst¨andigheter s˚a l¨ange som de fulla konsekvenserna av detta beslut tas i beaktning och ¨overv¨ags noggrant. F¨or att f˚a en bra ¨overblick av det som syste-met klarar av och den tj¨anst som systemet erbjuder p˚a olika abstraktionsniv˚aer b¨or specifikationen delas upp mellan olika typer av krav, exempelvis anv¨ andar-och systemkrav. Att g¨ora en s˚adan uppdelning ¨ar mycket effektiv i ett kom-munikationssyfte och inneb¨ar att de beskrivs med olika detaljeringsgrad efter vem som ska l¨asa kraven (Sommerville, 2011). Anv¨andarkraven beskriver i na-turligt spr˚ak de tj¨anster som systemet f¨orv¨antas ge till systemanv¨andare medan systemkrav ¨ar mer detaljerade beskrivningar av systemets funktioner och opera-tiva begr¨ansningar. Den fr¨amsta felk¨allan vid utveckling av IT-system uttrycker Martin (1984, i Eriksson, 2008) ¨ar krav. Hela 56 % av felen som vanligtvis upp-st˚ar vid utveckling av IT-system grundar sig i kravspecifiktationen, n˚agot som tyder p˚a hur viktig denna process ¨ar f¨or ett lyckat utvecklingsarbete.
3.2
Gr¨
anssnittsdesign
Detta arbete har som tidigare n¨amnt inte fokuserat p˚a design men d˚a ett nytt gr¨anssnitt utformades s˚a anpassades utformningen av gr¨anssnittet efter n˚agra teorier och principer.
3.2.1 ˚Aterkoppling
F¨or att kommunicera resultatet av en handling till anv¨andaren b¨or tydlig ˚ ater-koppling (eng. feedback ) ges (Arvola, 2014). Fr¨amst handlar det om att f¨ormedla till anv¨andaren vad som har skett och vad som kan h¨anda h¨arn¨ast. En anv¨andare f¨orst˚ar sig p˚a ett system genom att interagera med det, d¨ar varje handling f¨oljs av en reaktion i en feedback-loop (Morgan-Jones, 2018). Dessa loopar finns f¨or att f¨orst¨arka f¨orst˚aelsen av ett system och detta ¨ar vad som g¨or dem viktiga. Genom att f¨orses med ˚aterkoppling av en handling kan man som anv¨andare vara s¨aker p˚a att den utf¨orts. Utan n˚agon form av reaktion utf¨ors handlingen ofta upprepande g˚anger f¨or att s¨akertst¨alla att den utf¨orts, n˚agot som vanligtvis sker instinktivt. Att f¨orses med en ˚aterkoppling f¨orv¨antas ofta ske snabbt och direkt med en naturlig f¨ordr¨ojning efter en utf¨ord handling. Det b¨or dock inte ske f¨or snabbt s˚a att anv¨andaren inte h¨anger med. Andra aspekter att t¨anka p˚a vid ˚aterkoppling ¨ar att uppvisa den d¨ar anv¨andaren kan se den samt att st¨andigt
uppdatera anv¨andaren med status om vad som sker. 3.2.2 ˚Angra handling
Ofta utvecklas system s˚a att anv¨andaren m¨ots av en varning och beh¨over be-kr¨afta en utf¨ord handling (Raskin, 2007). Oavsett hur vi utformar varningen s˚a kommer vi m¨anniskor ¨and˚a att utf¨ora handlingar av misstag. Ist¨allet f¨or att bekr¨afta utf¨orandet av en handling ¨ar det b¨attre att erbjuda anv¨andaren m¨ojligheten att ˚angra handlingen (Goodwin, 2009). N¨ar man utformar en pro-dukt eller tj¨anst b¨or man acceptera att misstag kommer att ske och b¨or d¨arf¨or f¨orse anv¨andaren med m¨ojligheten att ˚angra en handling.
3.2.3 Design f¨or alla
Konceptet Design-f¨or-alla ¨ar en designfilosofi som inneb¨ar att design ska va-ra inkludeva-rande och inte utg˚a fr˚an en normaliserad vy av en person utan fr˚an syns¨attet att varje m¨anniska ¨ar unik (Unicum, 2019). Detta inneb¨ar att man vid utformningen av produkter och tj¨anster tar h¨ansyn till m˚angfald f¨or att pro-dukten eller tj¨ansten ska kunna utnyttjas, anv¨andas av och h¨oja livskvaliteten f¨or s˚a m˚anga som m¨ojligt. Att f¨olja denna designfilosofi ¨ar extra viktigt n¨ar man utformar tj¨anster som inte ¨ar privata och b¨or ses som en naturlig utg˚angspunkt f¨or l˚angsiktig h˚allbar samh¨allsutveckling.
3.3
Test
Syftet med att utf¨ora tester av en programvara ¨ar att se om det uppfyller de krav som finns specificerade samt f¨or att identifiera fel i programmet (Eriksson, 2008). Att identifiera fel ¨ar en av de viktigaste produkterna som man f˚ar av att utf¨ora tester, dessa fel ¨ar skillnaden mellan f¨orv¨antat och faktiskt resultat (Koomen & Pol, 1999). Detta ger information och insikt i kvalit´een hos systemet och ¨ar v¨ardefullt f¨or att undvika problem i vidare utveckling eller eventuell lansering. Att testa ¨ar en process som ¨ar planerad, v¨alstyrd och b¨or genomf¨oras p˚a ett strukturerat s¨att. Att s¨atta upp en testprocess kan vara kr¨avande men mycket l¨onsamt n¨ar den v¨al ¨ar fungerande och p˚a plats (Eriksson, 2008). Det ¨
ar vanligt att risker identifieras och en utf¨orlig testplan och strategi utarbetas f¨or att undvika problematik under testarbetet.
Att testa alla m¨ojliga t¨ankbara kombinationer hos ett system ¨ar ofta kost-samt och tidskr¨avande och i vissa fall om¨ojligt (Eriksson, 2008). Man efterstr¨avar att hitta en optimal testniv˚a f¨or att uppt¨acka s˚a m˚anga fel som m¨ojligt, f¨or att g¨ora detta ¨ar det viktigt att v¨alja r¨att testdesignteknik.
3.3.1 Dynamiska tester
En typ av testdesignteknik ¨ar dynamiska tester. Under s˚adana tester s˚a exekve-ras systemet och har fokus p˚a funktionalitet snarare ¨an dokumentation, kod och gr¨anssnitt (Eriksson, 2008).
Positiva tester ¨ar ett dynamiskt test och en bra metod f¨or att unders¨oka huruvida systemet presterar vid normal anv¨andning (Eriksson, 2008). S˚adana tester utf¨ors med k¨annedom om systemets funktionalitet och s˚aledes i syfte att unders¨oka om en implementation fungerar som den ska. Negativa tester har ett motsatt syfte, s˚adana tester utf¨ors f¨or att kontrollera systemets felhantering och vad som uppst˚ar d˚a systemet anv¨ands p˚a ett felaktigt s¨att.
En annan typ av dynamiska tester ¨ar test av tillst˚ands¨overg˚angar. Vid s˚adana tester tas en tillst˚andstabell fram f¨or att illustrera antal m¨ojliga sekven-ser av tillst˚and som systemet kan anta och unders¨oka hur systemet presterar givet olika h¨andelsef¨orlopp (Eriksson, 2008). Syftet ¨ar att unders¨oka resulta-tet givet olika tillst˚and och h¨andelsef¨orlopp. En kombination av testtekniker m¨ojligg¨or att fler fel kan identifieras, och p˚a s˚a s¨att f˚ar man en mer effektiv testprocess.
3.3.2 Testfall
F¨or varje krav utformas ett eller flera testfall. Ett testfall utformas med syftet att testa en s¨arskild egenskap hos systemet och omfattar varierande information men inneh˚aller ofta ID, rubrik, f¨orberedelser, teststeg samt f¨orv¨antat resultat (Eriksson, 2008). Att skriva en beskrivande rubrik ¨ar f¨ordelaktigt d˚a det blir enklare att navigera mellan testfallen. Exempelvis ¨ar rubriken ”Aktivera syno-nymer” mer inneh˚allsrik och f¨ordelaktig ¨an ”Testfall 1”. Det ¨ar av stor betydelse att det f¨orv¨antade resultatet formuleras p˚a ett s¨att som g˚ar att utv¨ardera om testfallet lyckades, ¨ar det otydligt formulerat kan det vara sv˚art att avg¨ora om
testfallet lyckats eller inte. D˚a kravspecifikationen b¨or vara formulerad p˚a ett testbart s¨att b¨or det f¨orv¨antade resultatet g˚a att utl¨asa fr˚an de angivna kraven. Det f¨orv¨antade resultatet av varje testfall skall formuleras innan utf¨orandet av testet f¨or att undvika p˚averkan av dess utfall.
F¨or att utforma testfall s˚a utg˚ar man fr˚an kravspecifikationen och grans-kar de krav som finns och skriver testfall utifr˚an dem (Eriksson, 2008). En del testfall kan kr¨ava att andra testfall redan exekveras, i dessa fall kan det vara n¨odv¨andigt att skapa ett testschema f¨or en k¨orordning. Oavsett designtek-nik s˚a beh¨over varje testfall inkluderas av startsituation, action samt f¨orv¨antat resultat (Koomen, et al., 2006 i Wissa, 2011). Startsituationen inkluderar de f¨orberedelser som beh¨over g¨oras innan testfallet kan utf¨oras eller anger vilket tillst˚and systemet b¨or vara i. Action definieras av de teststeg som utf¨ors vid testet. Teststegen kan utformas med ett f¨orv¨antat resultat f¨or varje steg, detta ¨
ar inte alltid n¨odv¨andigt men b¨or anv¨andas i de fall ett teststeg ¨ar tidskr¨avande eller komplext (Eriksson, 2008).
Att anv¨anda testfall ¨ar f¨ordelaktigt d˚a det bidrar till ett mer strukturerat tillv¨agag˚angss¨att och ¨ar en bra grund f¨or eventuella felrapporter. De utformade testfallen inkluderas sedan i en testspecifikation tillsammans med en inledning, beskrivning av testdata samt eventuella f¨orberedelser inf¨or utf¨orandet av tes-terna.
4
F¨
orstudie
En f¨orstudie utf¨ordes f¨or att unders¨oka vilken typ av funktionalitet som efter-fr˚agas, finns tillg¨anglig och b¨or inkluderas i Friendlyreader. Detta unders¨oktes i syfte att ta fram krav som verktyget skulle implementeras efter.
4.1
Metod
Utf¨orandet av f¨orstudien bestod av en kravinsamling samt en kravanalys f¨or att resultera i en kravspecifikation.
4.1.1 Kravinsamling
Syftet med kravinsamlingen var att identifiera de krav som speglar m˚alen hos anv¨andarna inom m˚algrupperna f¨or Friendlyreader. F¨or att identifiera vilken funktionalitet som fanns tillg¨anglig s˚a kartlades funktionaliteten hos Friendly-reader samt TeCST. ¨Aven dess m¨ojligheter och brister dokumenterades. Fr˚an detta sammanst¨alldes den funktionalitet som fanns och skulle bevaras hos endlyrerader samt vilken funktionalitet hos TeCST som kunde appliceras i Fri-endlyreader. Detta var den inledande delen av kravinsamlingen f¨or att t¨acka upp s˚a m˚anga krav som m¨ojligt. D˚a anv¨andarstudier tidigare utf¨orts f¨or b˚ade Friendlyreader samt TeCST s˚a bearbetades sedan resultatet fr˚an dessa f¨or att identifiera fler krav. F¨or att hitta f¨orb¨attringsm¨ojligheter f¨or l¨asverktyget samt unders¨oka vad som anv¨ands idag inom omr˚adet s˚a kartlades funktionalitet hos liknande verktyg och krav formulerades utifr˚an detta. Slutligen anv¨andes ¨aven resultat fr˚an artiklar inom detta forskningsomr˚ade som informationsk¨alla. M˚alet med denna process var att den skulle resultera i en samling krav som skulle ligga till grund f¨or den kommande kravanalysen.
4.1.2 Kravanlys
M˚alet med f¨orstudien var att den skulle resultera i en kravspecifikation. Denna process kr¨avde att insamlade krav analyserades f¨or att identifiera om de var m¨ojliga att utf¨ora fr˚an ett system- och tidsperspektiv. Samtliga krav fr˚an in-samlingen omformulerades s˚a att problemet presenterades ist¨allet f¨or en t¨ankbar l¨osning och p˚a ett s˚adant s¨att att de inte skulle kunna g˚a att misstolkas. Om-formuleringarna utf¨ordes med stor noggrannhet s˚a att kravbeskrivningarna inte var tvetydiga f¨or att undvika eventuella missf¨orst˚and.
Specifikation delades ¨aven upp i tre olika typer av krav, anv¨andarkrav, systemkrav samt gr¨anssnittskrav. Denna uppdelning gjordes f¨or att f˚a en bra ¨
overblick av vad systemet ska klara av och den tj¨anst som erbjuds p˚a olika ab-straktionsniv˚aer. En del av kraven valdes att delas upp som gr¨anssnittskrav d˚a m˚algruppens behov st¨allde h¨oga krav p˚a hur gr¨anssnittet skulle kunna anpassas. Genom att dela upp dessa som en egen typ av krav blev de tydligt specificerade och riskerade s˚aledes inte att misstolkas vid implementationen.
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.
4.2.1 Kravinsamling
Kravinsamlingen resulterade i en ostrukturerad samling krav av olika typer som var i behov av att organiseras i sammanh¨angande grupperingar. Detta resul-terade i tre olika typer av krav; funktionella, grafiska och informativa. Efter kartl¨aggningen av funktionaliteten hos Friendlyreader kunde flertalet krav iden-tifieras, se Tabell 1.
Tabell 1: Resulterande krav fr˚an kartl¨aggning av funktionaliteten hos Friendly-reader
Kravbeskrivning Kravtyp
Gr¨anssnittet ska f¨orse anv¨andaren med information om verktyget
Informativt Gr¨anssnittet ska f¨orse anv¨andaren med visuell
feed-back n¨ar analysen av text p˚ag˚ar
Grafiskt Gr¨anssnittet ska st¨odja f¨or¨andring i teckenstorlek,
typsnitt, radavst˚and och textbredd
Grafiskt Gr¨anssnittet ska tillhandah˚alla en l¨aslinjal med olika
utseenden och justerbar h¨ojd
Grafiskt Anv¨andare ska kunna se textkomplexitet illustrerat
genom ett diagram
Funktionellt Anv¨andaren ska kunna se synonymer till ord i texten Funktionellt Anv¨andaren ska kunna f˚a texten uppl¨ast Funktionellt Anv¨andaren ska kunna sammanfatta texten fram och
tillbaka
Funktionellt Anv¨andaren ska kunna infoga text p˚a webbsidan Funktionellt Anv¨andaren ska kunna f¨orenkla texten Funktionellt Efter detta moment utf¨ordes kartl¨aggningen av funktionaliteten hos TeCST. Efter kartl¨aggningen kunde den funktionalitet som ans˚ags l¨amplig i Friendlyre-ader identifieras, se Tabell 2
Tabell 2: Resulterande krav fr˚an kartl¨aggning av funktionaliteten hos TeCST
Kravbeskrivning Kravtyp
Anv¨andaren ska kunna se borttagna meningar fr˚an sammanfattaren
Funktionellt Anv¨andaren ska kunna se emojis som illustrerar
or-dets semantiska inneb¨ord som en synonym
Funktionellt Anv¨andaren ska kunna anpassa textf¨orenklingen p˚a
olika s¨att
Funktionellt
I TeCST uppvisas de meningar som tagits bort n¨ar texten sammanfattas i en tabell. Denna funktionalitet fanns inte implementerad i Friendlyreader och ans˚ags vara n˚agot som kan hj¨alpa anv¨andaren att f¨orst˚a hur sammanfatta-ren fungerar och undviker att uppleva att information g˚ar f¨orlorad. I TeCST uppm¨arksammades det ¨aven att emojis anv¨ands som ett komplement till sy-nonymer. I en pilotstudie har Lindberg och Kindberg (2018) visat att emojis kan underl¨atta att f¨orst˚a text f¨or personer med l¨as- och skrivsv˚arigheter. Detta var enbart en pilotstudie och det finns mer att unders¨oka inom omr˚adet men att anv¨anda emojis som komplement till synonymer anses inte kunna stj¨alpa f¨orst˚aelsen av text och gav s˚aledes upphov till ytterligare ett krav. Att f¨orenkla text var en funktionalitet som fanns implementerad i Friendlyreader, men p˚a vilket s¨att som verktyget f¨orenklar texten var inte f¨ormedlat till anv¨andaren. I TeCST kunde man som anv¨andare v¨alja hur texten skulle f¨orenklas. De alterna-tiv som fanns att v¨alja mellan var; rak ordf¨oljd, passiv till aktiv, proximering, citatomv¨andning samt meningsuppdelning. Att addera denna valm¨ojlighet ger ett mer anpassningsbart verktyg d¨ar anv¨andaren sj¨alv kan f˚a besluta enligt vil-ken typ av regel som texten ska f¨orenklas efter d˚a alla anv¨andare inte har behov av samma typ av f¨orenkling. Detta adderades som ett krav till kravinsamlingen, anv¨andaren ska kunna anpassa textf¨orenklingen p˚a olika s¨att. Detta f¨orser ¨aven anv¨andaren med m¨ojligheten att utforska olika textf¨orenklingar av text.
Majoriteten av de slutsatser som tidigare studier har resulterat i har legat till grund f¨or den funktionalitet som var implementerad i Friendlyreader i den inle-dande fasen av detta projekt. Projektet Begriplig text (Hedberg m. fl., 2018) har unders¨okt vad som g¨or en text l¨att respektive sv˚ar att l¨asa genom att unders¨oka behoven hos personer med kognitiva neds¨attningar, bland annat personer med dyslexi och utvecklingsst¨orning. Resultatet fr˚an detta projekt riktar fr¨amst fokus mot grafiska f¨or¨andringar hos en text, som exempelvis radavst˚and, textbredd samt teckenstorlek och hur detta underl¨attar l¨asning. Detta var funktionalitet som redan fanns implementerad hos Friendlyreader. Projektet har ¨aven kom-mit fram till att personer inom dessa m˚algrupper uppskattar att m¨ojligheten att sammanfatta texten samt ¨aven att f¨orsta intrycket av en text kan avg¨ora om l¨asaren v¨aljer att l¨asa den eller inte. Detta styrker betydelsen av att ha en v¨alfungerande sammanfattningsfunktion i ett verktyg som ¨amnar att underl¨atta l¨asning. En text som vid f¨orsta anblick ser sv˚arl¨ast ut beh¨over n¨odv¨andigtvis inte vara det, med hj¨alpa av spr˚akteknologiska funktioner kan den bli l¨attare att l¨asa. Om meta-data om en text kan presenteras f¨or anv¨andaren kan det
eventuellt ge anv¨andaren en chans att g¨ora en mer kvalificerad bed¨omning om texten kommer att l¨asas eller inte. I TeCST presenteras meta-data om texten f¨or anv¨andaren, n˚agot som ans˚ags behj¨alpligt f¨or skribenter. Denna data kunde anses v¨ardefull ¨aven f¨or m˚algruppen hos Friendlyreader och detta resulterade i ett ytterligare krav, se Tabell 3. Friendlyreader presenterade komplexitetm˚att baserat p˚a text f¨or anv¨andaren, men gav inga f¨orklaringar f¨or inneb¨orden hos dessa begrepp. F¨or att anv¨andare ska kunna ta till sig dessa beh¨over gr¨anssnittet f¨orse anv¨andaren med f¨orklaringar ¨over begrepp som kan underl¨atta beslutet om en text kommer att l¨asas eller inte, ¨aven detta resulterade i ett krav.
Projektet Begriplig text (Hedberg m. fl., 2018) har skribenter som m˚algrupp, d˚a resultatet f¨orhoppningsvis ska underl¨atta att skriva texter som
m¨ojligg¨or att fler individer kan tillgodog¨ora sig dem. Trots att projektet har en annan m˚algrupp ¨an Friendlyreader s˚a belyser de sv˚arigheter hos personer inom m˚algruppen f¨or Friendlyreader. Resultatet fr˚an projektet visar att olika grupper vill anpassa text p˚a olika s¨att, vilket tyder p˚a att verktyget beh¨over inkludera funktionalitet som st¨odjer behovet hos samtliga m˚algrupper.
I en tidigare utf¨ord pughanalys, en typ av v¨arderingsmatris, av Vegelius (2011) med syfte att v¨alja ut designkoncept presenterades behov och krav hos m˚algrupperna f¨or Friendlyreader. Denna analys visade att de viktigaste kraven hos anv¨andarna var f¨oljande:
1. Sammanfatta texten 2. F¨orst˚a texten 3. L¨asa originaltexten
4. Se vilka meningar som ¨ar viktigast
Detta belyste ˚aterigen av hur stor vikt det ¨ar f¨or anv¨andarna inom dessa m˚algrupper att ha m¨ojligheten att sammanfatta text. Vad en anv¨andare beh¨over f¨or att f¨orst˚a texten’varierar efter dess behov och att hitta en l¨osning p˚a ett s˚adant problem ¨ar s˚aledes inte en enkel utmaning utan n˚agot som verktygets varierande funktionalitet f¨orhoppningsvis kan l¨osa genom att f¨ors¨oka identifiera s˚a m˚anga behov hos personer inom m˚algruppen som m¨ojligt. Att ha m¨ojligheten att l¨asa originaltexten samt att se vilka meningar som ¨ar viktigast gav upphov till tv˚a nya krav, se Tabell 3
Tabell 3: Krav baserade p˚a tidigare studier
Kravbeskrivning Kravtyp
Gr¨anssnittet ska f¨orse anv¨andaren med f¨orklaringar av komplexitetsbegrepp
Informativt Anv¨andaren ska kunna se meta-data om texten Funktionellt
Efter att ha unders¨okt liknande verktyg och tj¨anster som ¨amnar att un-derl¨atta l¨asning av text, kunde flera gemensamma funktioner identifieras. Tv˚a av dessa tj¨anster, TTSREADER (Ttsreader, 2017) och Ginger (Ginger Soft-ware, 2019), har fokuserat p˚a att l¨asa upp text f¨or anv¨andaren. TTSREADER ¨
ar en webbaserad tj¨anst och Ginger ¨ar en mjukvara som kan implementeras i webbl¨asaren eller anv¨andas f¨or filer. B˚ada tj¨ansterna erbjuder uppl¨ast text av personer med olika k¨on, p˚a olika spr˚ak och i olika takter. Ut¨over detta hade tj¨ansterna som gemensam funktion att den mening som uppl¨ases markeras. Det-ta gav upphov till ett nytt krav. Friendlyreader har sedan tidigare haft funktio-nen att f˚a text uppl¨ast och ¨aven projektet Begriplig text (Hedberg m. fl., 2018) har visat att f˚a texten uppl¨ast samtidigt som man l¨aser kan hj¨alpa f¨orst˚aelsen. Grammarly ¨ar en AI-driven produkt som hj¨alper anv¨andaren att uppt¨acka exempelvis stavfel och grammatiska fel i sitt skrivande (Grammarly Inc., 2019). Produkten kan anv¨andas genom att klistra in text i en texteditor eller installera den direkt i en webbl¨asare. Denna produkt ¨ar inte avsedd f¨or att underl¨atta l¨asning men gav upphov till en m¨ojlig funktionalitet hos Friendlyreader. N¨ar ett ord ¨ar exempelvis felstavat blir det r¨odmarkerat av Grammarly och produkten erbjuder d˚a alternativa stavningar som passar b¨attre. Denna m¨ojlighet gavs ¨
aven i Friendlyreader genom att presentera synonymer f¨or ord. Dock fanns inte m¨ojligheten att byta ut ett ord mot en synonym likt man kan byta ut ett felstavat mot ett r¨attstavat i Grammarly. Detta resulterade i ytterligare ett funktionellt krav, anv¨andaren skall kunna byta ut ord mot synonymer. F¨or att anv¨andaren ska till˚atas att utforska denna funktionalitet fanns behovet av att ˚angra utbytet av ett ord mot en synonym. Detta resulterade i ytterligare ett krav baserat p˚a teori om att ˚angra handlingar enligt bland annat Goodwin (2009), se Tabell 4.
Tabell 4: Krav baserade p˚a liknande verktyg
Kravbeskrivning Kravtyp
Den text som uppl¨ases ska markeras mening f¨or mening
Funktionellt Anv¨andaren ska kunna byta ut ord mot synonymer Funktionellt Anv¨andaren ska kunna ˚angra utbytet av ett ord mot
en synonym
4.2.2 Kravanalys
Kravanalysen utf¨ordes med kravinsamlingen som underlag och inga av de in-samlade kraven valdes att tas bort utan samtliga krav inkluderades i den slutliga kravspecifikationen. Den slutliga kravspecifikation utgick fr˚an anv¨andarkraven och gavs ett nummer mellan 1 och 17. Systemkrav samt gr¨anssnittskrav gavs ett nummer f¨or att enkelt se vilket anv¨andarkrav de tillh¨orde, exempelvis system-krav 2.1 tillh¨orde anv¨andarkrav 2. En del av anv¨andarkrav var beroende av varandra, detta specificeras under kolumnen ”Beroenden”. Detta innebar att ett anv¨andarkrav kr¨avde att ett annat krav redan var implementerat, se tabell 5.
Tabell 5: Anv¨andarkrav
Nummer Kravbeskrivning Beroenden
1 Anv¨andaren skall kunna f¨ora in text p˚a webbsidan
2 Anv¨andaren skall kunna analysera texten
3 Anv¨andaren skall kunna se textens vik-tigaste meningar
2 4 Anv¨andaren skall kunna sammanfatta
texten fram och tillbaka
2 5 Anv¨andaren b¨or kunna se borttagna
meningar fr˚an sammanfattaren
2; 4 6 Anv¨andaren skall kunna f¨orenkla texten
p˚a olika s¨att
2 7 Anv¨andaren b¨or ges f¨orslag p˚a
me-ningsf¨orenklingar
2 8 Anv¨andaren skall kunna se och ¨andra
ord med synonymer
2 9 Anv¨andaren b¨or kunna se emojis som
illustrerar ordets semantiska inneb¨ord som en synonym.
2
10 Anv¨andaren skall kunna ˚angra utbytet av ett ord mot en synonym
2 11 Anv¨andaren skall kunna f˚a texten
uppl¨ast
12 Anv¨andaren skall kunna se textkom-plexitet illustrerat genom ett diagram
2 13 Anv¨andaren skall kunna se meta-data
om texten
2 14 Anv¨andaren skall kunna g˚a tillbaka till
det initiala analyserade tillst˚andet 15 Anv¨andaren skall kunna ¨andra grafiska
funktioner hos texten
16 Anv¨andaren skall kunna anv¨anda verk-tyg f¨or att underl¨atta l¨asning av text 17 Anv¨andaren skall kunna l¨asa
informa-tion om verktyget
Specifikationen resulterade i ett antal b¨or-krav, f¨or anv¨andarkraven var det f¨oljande; nummer 5. Anv¨andare b¨or kunna se borttagna meningar fr˚an samman-fattaren, 7. Anv¨andaren b¨or ges f¨orslag p˚a meningsf¨orenklingar och 9. Anv¨andaren b¨or kunna se emojis som illustrerar ordets semantiska inneb¨ord som en syno-nym.. Att anv¨andaren skulle kunna se borttagna meningar fr˚an sammanfattaren var ett krav som uppstod d˚a detta var en funktionalitet som fanns
implemente-rad i TeCST. Det var sv˚art att avg¨ora hur anv¨andbar denna funktionalitet ¨ar f¨or anv¨andare inom m˚algruppen f¨or Friendlyreader och av den anledningen k¨andes kravet inte prioriterat och angavs som ett b¨or-krav. F¨or att m¨ojligg¨ora att flera av resterande krav kunde implementeras togs beslutet att g¨ora nummer 7 till ett b¨or-krav. Anv¨andaren skall kunna f¨orenkla texten men att meningsf¨orslag skall ges prioriterades ned. Att se emojis som synonymer till ord ¨ar en funktio-nalitet som fanns implementerad i TeCST men n˚agra stora unders¨okningar som st¨odjer anv¨andandet av detta fanns inte. Av den anledningen ans˚ags detta kom-plement till Friendlyreader vara ett b¨or-krav. Nedan f¨oljer Tabell 6 och Tabell 7 inneh˚allandes system- och gr¨anssnittskraven.
Tabell 6: Systemkrav Nummer Kravbeskrivning
1.1 Systemet skall m¨ojligg¨ora att infoga text p˚a webbsi-dan
2.1 Om texten inte kan analyseras skall anv¨andaren in-formeras efter n˚agra sekunder
2.2 Systemet skall returnera en lista ¨over meningar och deras betydelseordning
2.3 Systemet skall returnera en lista med meningar och dess f¨orenklingsf¨orslag
2.4 Systemet skall returnera synonymer. 2.5 Systemet b¨or kunna hantera emojis
2.6 Systemet skall returnera information om textkom-plexitet och meta-data
6.1 Systemet skall returnera f¨orenklade meningar base-rat p˚a anv¨andarinmatning
10.1 Systemet skall kunna h˚alla reda p˚a till-st˚ands¨overg˚angar f¨or historikfunktionalitet
Tabell 7: Gr¨anssnittskrav Nummer Kravbeskrivning
2.7 Gr¨anssnittet skall f¨orse anv¨andaren med visuell feed-back n¨ar analysen ¨ar p˚ag˚aende
11.1 Texten som uppl¨ases b¨or markera den aktuella me-ningen
12.1 Gr¨anssnittet skall visa f¨orklaringar av komplexi-tetm˚att
15.1 Gr¨anssnittet skall st¨odja f¨or¨andring i teckensnitts-storlek, typsnitt, radavst˚and och textbredd.
15.2 Gr¨anssnittet skall tillhandah˚alla en l¨aslinjal med oli-ka utseenden och justerbar h¨ojd
Systemkrav 2.5 prioriterades som ett b¨or-krav d˚a anv¨andarkrav 9 gavs sam-ma prioritering och de b˚ada ber¨or emojis. ¨Aven gr¨anssnittskrav 11.1 prioritera-des som ett b¨or-krav d˚a inget mer ¨an att funktionaliteten fanns hos ett liknande verktyg med uppl¨asning av text som enda fokus och inget annat fr˚an kravin-samlingen kunde motivera att f˚a den aktuella meningen markerad under l¨asning kan underl¨atta l¨asning s˚a prioriterades detta som ett b¨or-krav.
Se Bilaga A f¨or en komplett sammanst¨allning av den slutgiltiga kravspecifi-kationen.
5
Implementation
Implementationen av det nya gr¨anssnittet skapades i HTML, CSS och Java-Script. Dessa tre spr˚ak anv¨ands vanligtvis vid frontend-utveckling, den typ av utveckling som direkt relaterar till webbl¨asaren (Niederst Robbins, 2018). HTML st˚ar f¨or HyperText Markup Language och ¨ar ett markup-spr˚ak. Det anv¨ands f¨or att skapa och strukturera upp webbsidedokument. I HTML anges de komponenter som dokumentet best˚ar av. CSS st˚ar f¨or Cascading Style She-ets och anv¨ands f¨or att beskriva utseendet hos komponenterna p˚a hemsidan, exempelvis f¨arg, storlek och placering. JavaScript (JS) ¨ar ett skriptspr˚ak som adderar interaktivitet och beteende till en webbsida (Niederst Robbins, 2018) och ¨ar det mest anv¨anda programmeringsspr˚aket idag (Toledo, 2018). Majori-teten av implementationen skapades i JS och anv¨andes d˚a det ¨ar ett l¨att men v¨aldigt kraftigt skriptspr˚ak.
Anv¨andandet av JS-ramverk ¨ar vanligt och f¨orser utvecklaren med mallar och f¨ardiga komponenter som kan anv¨andas (Morris, 2019). En av f¨ordelarna med att anv¨anda ramverk ¨ar att man undviker att utveckla allt fr˚an grun-den, men framf¨orallt s˚a tillhandah˚aller ramverk hj¨alp och kan minska tiden som utvecklingsprocessen tar (Hjelm, 2015). D¨aremot kan det vara sv˚art och tidskr¨avande att l¨ara sig ett ramverk och inte alltid n¨odv¨andigt f¨or att utveckla en grundl¨aggande applikation. D˚a framtida utveckling av Friendlyreader mest sannolikt kommer att ske av en annan individ togs beslutet att inte anv¨anda n˚agot ramverk d˚a detta hade f¨orutsatt kunskap hos den individen inom det valde ramverket.
Kravspecifikationen fungerade som utg˚angspunkt vid implementationen.
5.1
Spr˚
akteknologisk funktionalitet
Vid ett tidigt skede i implementationen blev det uppenbart att de framtagna kraven kr¨avde ett mer flexibelt gr¨anssnitt f¨or att st¨odja den ut¨okade funktio-naliteten angiven i kravspecifikationen. Beslutet togs d˚a att utg˚a fr˚an en ny grunddesign, se Figur 1. Flertalet av kraven i specifikationen var baserade p˚a funktionalitet som redan fanns implementerad i Friendlyreader och mycket kod kunde s˚aledes bevaras med en del anpassningar efter det nya gr¨anssnittet. Alla de krav i specifikationen som prioriterades som skall-krav lyckades implemen-teras under utvecklingsarbetet men samtliga b¨or-krav hann inte implementeras och beslutet togs att f¨ordr¨oja dessa till framtida utvecklingsarbete av verktyget.
(a) F¨orsta sidan
(b) L¨asvyn
Figur 1: Gr¨anssnittet hos den nya implementationen av Friendlyreader Funktionalitet som f¨or¨andrar textens inneh˚all p˚a n˚agot s¨att ¨ar funktionerna Sammanfatta text, F¨orenkla text samt Visa synonymer. Under implementatio-nen togs beslutet att g¨ora dessa samverkande. N˚agot som innebar att funktio-naliteten inte utgick fr˚an originaltexten utan fr˚an den aktuella utformningen av texten. En text som var sammanfattad kunde s˚aledes f¨orenklas utifr˚an sin nuvarande utformning. Detta beslut togs f¨or att skapa ett mer anv¨andbart och flexibelt verktyg.
5.1.1 F¨orenkla text
Att m¨ojligg¨ora f¨or anv¨andaren att f¨orenkla text var specificerat i krav 6 i krav-specifiktionen. I den tidigare versionen av Friendlyreader f¨orenklades texten uti-fr˚an de fem regler som presenterades i teorin. I den nya implementationen skapa-des valm¨ojligheten f¨or anv¨andaren att v¨alja p˚a vilket s¨att texten skall f¨or¨andras. Detta presenterades genom fem olika checkboxar d¨ar samtliga f¨orenklingsregler ¨
ar f¨orvalda, se Figur 2. Under dessa checkboxar implementerades en knapp d¨ar anv¨andaren kunde v¨alja att trycka p˚a knappen och d¨armed skickades en f¨orfr˚agan till servern med den aktuella texten som finns i textf¨altet och de valda f¨orenklingsreglerna som argument.
(a) Sidomeny (b) F¨orenklingsregler
Figur 2: Sidomeny och f¨orenklingsregler
En lyckad f¨orfr˚agan till servern returnerade en datastruktur inneh˚allandes de meningar med f¨orenklingsf¨orslag som lyckades identifieras. F¨or varje mening fanns information om vilken f¨orenklingsregel som var aktuell, exempelvis fr˚an passiv till aktiv form, originalmeningen samt en mening som var f¨orenklad en-ligt angiven regel. F¨or att ers¨atta den aktuella texten med de f¨orenklingsf¨orlag kontrollerades f¨orst vilka meningar i texten som hade f¨orenklingar. Meningarna j¨amf¨ordes d˚a fr˚an den aktuella texten med den originalmening som inkludera-des i datastrukturen som skickainkludera-des fr˚an servern. I de fall d¨ar en mening st¨amde ¨
overens h¨amtades f¨orenklingsf¨orlaget fr˚an datastrukturen f¨or den aktuella me-ningen och ersatte dess original i texten som skall uppvisas f¨or anv¨andaren. Efter att hela texten bearbetats och meningar ersatts med f¨orenklingsf¨orslag presenterades sedan den nya texten f¨or anv¨andaren i textf¨altet.
Funktionen f¨or att f¨orenkla text implementerades samverkande med reste-rande funktioner och utgick d¨armed fr˚an textens aktuella utformning. Detta inneb¨ar att om texten sedan tidigare var exempelvis sammanfattad utgick funk-tionen fr˚an den sammanfattade texten och inte den ursprungliga.
5.1.2 Sammanfatta text ¨
Aven sammanfattaren implementerades f¨or att samverka med resterande funk-tioner och utgick d¨armed ¨aven fr˚an textens aktuella tillst˚and. N¨ar denna funk-tion valdes i sidomenyn skickades en f¨orfr˚agan genom SAPIS till Scream f¨or att f˚a information om textens storlek. Denna information var n¨odv¨andig f¨or att ge ett maxv¨arde till det dragreglage (eng. slider ) som anv¨andes f¨or att anpas-sa storleken p˚a den sammanfattade texten. Detta dragreglade uppvisades n¨ar funktionen valdes fr˚an sidomenyn. Ett f¨orfr˚agan skickades ¨aven till servern med den aktuella texten f¨or att f˚a tillbaka en rangordning av textens meningar.
Vid en lyckad f¨orfr˚agan till servern returnerades tv˚a olika listor. En lista d¨ar varje element representerades av en mening fr˚an texten samt en ytterligare lista inneh˚allandes siffror som representerade meningarnas rangordning. Varje mening var placerad p˚a samma index i listan som dess rangordning i den and-ra listan. Storleken p˚a den sammanfattade texten anpassades efter det v¨arde som anv¨andaren angett genom dragreglaget, v¨ardet representerade d¨armed an-talet meningar som den sammanfattade texten skulle inneh˚alla. Valde s˚aledes anv¨andaren att sammanfatta texten till exempelvis 20 meningar av 40 totalt s˚a exkluderades de 20 meningar med l¨agst rank fr˚an texten. Att implemente-ra sammanfattaren p˚a detta s¨att bevarade en s˚a sammanh¨angande text som m¨ojligt. Implementationen av draggreglaget m¨ojliggjorde f¨or anv¨andaren att sammanfatta texten fram och tillbaka utan att skicka upprepande f¨orfr˚agningar till servern d˚a all information fanns kvar p˚a klientsidan.
5.1.3 Visa synonymer
F¨or att uppvisa synonymer f¨or anv¨andaren h¨amtades textens aktuella utform-ning och skickades som en f¨orfr˚agan till servern. Denna f¨orfr˚agan ¨ar den mest tidskr¨avande av funktionerna, baserat p˚a textens storlek kunde det ta lite l¨angre tid f¨or att servern att bearbeta f¨orfr˚agan. Vid en lyckad f¨orfr˚agan s˚a returnera-des en datastruktur med information om de ord i texten som synonymer lyckareturnera-des identifieras f¨or. I datastrukturen fanns information om vilka ord som synonymer hittades f¨or, alla de synonymer som identifierades f¨or respektive ord samt vilken frekvensniv˚a varje synonym hade. En h¨og frekvensniv˚a innebar att synonymen ans˚ags v¨al passande. Fr˚an denna information extraherades de tre synonymer med h¨ogst niv˚a f¨or respektive ord f¨or att presentera detta f¨or anv¨andaren i gr¨anssnittet.
De ord som hade synonymer upplystes genom en gul understrykning. Detta designval kommunicerade till anv¨andaren vilka ord som hade synonymer, n˚agot som var inspirerat fr˚an Grammarly, b˚ade i utseendet men ¨aven att synonymer uppvisades under ordet. Genom att f¨ora musen ¨over ett understruket ord uppvi-sades synonymf¨orslagen. N¨ar anv¨andaren hovrade ¨over synonymerna ¨andrades bakgrunds- och textf¨arg samt muspekaren blev till en hand f¨or att f¨ormedla till anv¨andaren att dessa olika ordrutor var tryckbara, se Figur 3. Genom att trycka p˚a en av synonymerna skedde ett utbyte i texten mellan ordet och den valda synonymen.
Figur 3: Synonymer till ordet f¨orklaringar uppvisas
D˚a ett av kraven i specifikationen var m¨ojligheten att ˚angra ett utbytt ord s˚a implementerades detta genom en tillst˚andsmaskin framtagen av Holmstedt (2019). Denna tillst˚andsmaskin h¨oll reda p˚a textens versioner och skapade ett ursprungstillst˚and vid aktivering av synonymer och sedan ett nytt tillst˚and efter varje utbyte mot en synonym. P˚a s˚a vis kunde anv¨andaren enkelt ˚aterg˚a till en tidigare version av texten genom att trycka p˚a den ˚angra-ikon som uppvisades i huvudmenyn. Denna funktion implementerades s˚aledes kronologiskt, vilket inneb¨ar att det alltid var det senaste tillst˚andet som ˚atergavs. M¨ojligheten att ˚angra utbytet av en synonym var endast m¨ojligt i det tillst˚and d˚a synonymer var aktiverade. Valde anv¨andaren att inaktivera synonymer f¨or att aktivera dem p˚a nytt igen skickades en ny f¨orfr˚agan till servern och ett nytt ursprungstillst˚and skapades av tillst˚andsmaskinen. De tidigare ersatta orden kunde d˚a inte ˚angras. Detta beror p˚a att implementationen inte h˚aller reda p˚a om texten f¨or¨andrats mellan det att f¨orfr˚agningar skickats till servern f¨or att h¨amta synonymer och kan s˚aledes inte veta om de tidigare tillst˚anden ¨ar aktuella eller inte.
Synonymer kunde implementerades som samverkande med resterande funk-tionalitet genom att l˚ata en ny f¨orfr˚agan skickas till servern med den aktuella texten n¨ar anv¨andaren valde att aktivera synonymer. Detta var n¨odv¨andigt d˚a synonymer anv¨ands i det syfte att underl¨atta f¨or personer att f¨orst˚a komplexa ord utan att f¨orst¨ora meningsbyggnaden. Har anv¨andaren valt att sammanfatta eller f¨orenkla en text utesluter detta inte att komplexa eller l˚anga ord f¨orblir i texten d¨ar anv¨andarens behov av synonymer kvarst˚ar. Med denna samverkan-de implementation till˚ater det anv¨andaren att visa synonymer f¨or orden i en sammanfattad eller f¨orenklad text.
5.1.4 Textinformation och textkomplexitet
F¨or att krav 12 Anv¨andaren skall kunna se textkomplexitet illustrerat genom ett diagram och 13 Anv¨andaren skall kunna se meta-data om texten skulle uppfyllas beh¨ovde information h¨amtas fr˚an servern genom Scream. Att se textinformation och textkomplexitet var tv˚a separata funktion med olika knappar placerade i sidomenyn men samma typ av f¨orfr˚agan skickades till Scream och informationen extraherades fr˚an responsen p˚a samma s¨att. Valde anv¨andaren att se textinfor-mation och en f¨orfr˚agan till servern var lyckad k¨ordes en funktion f¨or att extra-hera information fr˚an servern, att utf¨ora detta var inte komplext d˚a responsen returnerar olika spr˚akteknologiska v¨arden baserade p˚a texten som enkelt kunde h¨amtas genom olika variabler. Funktionen h¨amtade s˚aledes information genom olika variabler och placerade ut informationen i en tabell som presenterades f¨or anv¨andaren. F¨or funktionen textinformation s˚a uppvisades antal tokens, me-ningar, ord samt LIX och OVIX-v¨arde. Dessa v¨arden ans˚ags mest relevanta f¨or verktygets m˚algrupper, n˚agot som eventuellt kan beh¨ova utv¨arderas i framtida anv¨andarstudier.
Samma typ av f¨orfr˚agan skickades f¨or att se textkomplexitet men den ef-terf¨oljande funktionen skilde sig. F¨or att illustrera textkomplexitet i ett diagam kunde den funktion som utf¨orde detta i den gamla versionen bevaras. Den-na funktion tar enbart in den respons som gavs fr˚an servern vid en lyckad f¨orfr˚agan och anpassades p˚a s˚a vis okomplicerat till det nya gr¨anssnittet. Vid en lyckad f¨orfr˚agan uppvisades ett diagram ¨over textkomplexitet under knap-pen f¨or ”Visa textkomplexitet”. Den graf som illustrerar textens komplexitet anv¨ander sig av bland annat LIX, OVIX och meningsdjup. Dessa begrepp pre-senteras med en f¨orklaring av dess inneb¨ord f¨or att skapa en st¨orre f¨orst˚aelse f¨or grafen. Detta implementerades efter krav nummer 12.1, Gr¨anssnittet skall visa f¨orklaringar av komplexitetsm˚att. Resterande komplexitetsm˚att som var in-kluderade i grafen, genomsnittlig meningsl¨angd, genomsnittlig ordl¨angd, andel bisatser och SweVoc, ans˚ags vedertagna.
5.1.5 Textens viktigaste meningar
F¨or att identifiera textens viktigaste meningar skickades samma f¨orfr˚agan till servern som f¨or sammanfattaren. Skillnaden vid implementationen f¨or denna funktionalitet var presentationen av responsen. F¨or denna funktion s˚a presen-terades meningarna efter dess betydelseordning i en lista i sidomenyn under knappen f¨or funktionaliteten. Detta inneb¨ar att den meningen som rangordna-des som viktigaste presenterarangordna-des f¨orst och efter f¨oljde resterande meningar efter dess rangordning. Antalet meningar kunde justeras genom ett dragreglage d¨ar ett maxv¨arde p˚a 10 stycken meningar implementerades.
5.1.6 F˚a texten uppl¨ast
Funktionen f¨or att f˚a texten uppl¨ast kunde helt bevaras fr˚an den tidigare im-plementationen. En anpassning gjordes f¨or att funktionen skulle k¨oras efter interaktion mellan anv¨andaren och knappen ”F˚a texten uppl¨ast” i sidomenyn. Funktionen tar enbart in text som argument och anpassades s˚a att den utgick fr˚an den aktuella texten i textf¨altet.
5.1.7 Grafiska anpassningar
D˚a den nya implementationen fr¨amst fokuserade p˚a samverkande och ut¨okad funktionalitet utf¨ordes ingen f¨or¨andring av de grafiska anpassningarna. Koden fr˚an den tidigare versionen kunde s˚aledes bevaras i stor utstr¨ackning med f˚a justeringar f¨or att anpassa till det nya gr¨anssnittet. Likt resterande funktiona-litet aktiverades grafiska anpassningar fr˚an sidomenyn men vid val av denna funktionalitet visade sig en ny meny med samtliga anpassningar samlade. Ut-formningen f¨or denna meny och dess funktionalitet bevarades fr˚an den tidigare versionen och implementerades i ett tidigt skede av utvecklingsarbetet.
5.1.8 ˚Aterst¨alla texten till dess original
Enligt krav 14.2 skall systemet alltid beh˚alla initialtillst˚andet. F¨or att uppfylla detta krav sparades den text som klistrades in p˚a webbsidan som en variabel i str¨angformat. Krav 14, Anv¨andaren skall kunna g˚a tillbaka till det initiala ana-lyserade tillst˚andet, kunde uppfyllas genom att byta ut den aktuella texten mot originalet som d˚a fanns sparad som en variabel. Denna funktionalitet fick ett st¨orre v¨arde d˚a stor del av funktionaliteten i Friendlyreader implementerades som samverkande. Detta m¨ojliggjorde f¨or anv¨andaren att g˚a tillbaka till original-texten och f¨or¨andra den p˚a nytt utan att beh¨ova f¨ornya webbsidan. I sidomenyn fanns alternativet ”˚Aterst¨all texten” och genom att klicka p˚a den kunde texten s˚aledes ˚aterst¨allas.
5.2
Gr¨
anssnittsdesign
Nedan f¨oljer en beskrivning av implementationen av ˚aterkoppling baserat p˚a teori om gr¨anssnittsdesign.
5.2.1 ˚Aterkoppling
F¨or att f¨orse anv¨andaren med feedback p˚a handlingar implementerades tre olika funktioner. Under den tid som en f¨orfr˚agan till servern bearbetades s¨anktes opaciteten hos textf¨altet och en laddningssymbol uppvisades f¨or att f¨ormedla till anv¨andaren att en analys ¨ar p˚ag˚aende, n˚agot som var specificerat under krav 2.7. Detta implementerades enligt teori om att f¨orse anv¨andaren med ˚aterkoppling
En laddningssymbol f¨ormedlar d¨armed systemets status till anv¨andaren och undviker att anv¨andaren f¨ors¨oker skicka ytterligare en f¨orfr˚agan till servern.
I de fall d˚a f¨orfr˚agan till servern var lyckad uppvisades positiv ˚aterkoppling till anv¨andaren. Detta f¨ormedlades genom en att en gr¨on ruta uppvisades med en beskrivande text, exempelvis ”Texten ¨ar f¨orenklad”. Denna ˚aterkoppling gavs direkt efter att en f¨orfr˚agan till servern gett ¨onskv¨ard repsons. Rutan uppvi-sades genom en animering d¨ar opaciteten gick fr˚an 0 till 100 procent ¨over 800 millisekunder. Efter 1200 millisekunder f¨orsvann rutan genom samma typ av ani-mering. Denna animering implementerades f¨or att ge ˚aterkopplingen en naturlig f¨ordr¨ojning. Att f¨orse anv¨andaren med ˚aterkoppling p˚a en utf¨ord handling var inte inkluderat som ett krav i kravspecifikationen men valdes att implemente-ras f¨or att undvika att anv¨andaren skickar upprepande f¨orfr˚agningar till servern i on¨odan. D˚a en f¨orfr˚agan till servern inte kunde utf¨oras och s˚aledes inte var lyckad uppvisades ˚aterkoppling till anv¨andaren p˚a samma s¨att fast med en r¨od ruta och texten ”N˚agonting gick fel”, se Figur 4.
(a) Positiv ˚aterkoppling (b) Negativ ˚aterkoppling
Figur 4: Positiv och negativ ˚aterkoppling p˚a anv¨andarens handlingar d¨ar en f¨orfr˚agan skickas till servern
6
Test
F¨or att unders¨oka om den nya implementationen av Friendlyreader fungerar enligt vad som var angivet i kravspecifikationen utf¨ordes tester f¨or att s¨akerst¨alla systemets funktionalitet.
6.1
Metod
Dynamiska tester utf¨ordes f¨or att kvalitetss¨akra funktionaliteten hos Friendly-reader. D˚a fokus genom detta arbete har varit riktat mot funktionalitet och inte mot design s˚a valdes denna typ av testteknik f¨or att n¨arma sig en optimal test-niv˚a. De typer av tester som utf¨ordes var positiva tester, negativa tester samt test av tillst˚ands¨overg˚angar. D˚a stor del av implementationen fokuserat p˚a sam-verkan av de viktigaste funktionerna utf¨ordes test av tillst˚ands¨overg˚angar som ett komplement till resterande tester. F¨or de positiva samt negativa testerna anv¨andes testfall som tillv¨agag˚angss¨att, detta ¨ar det mest f¨orekommande s¨att att utf¨ora dynamiska tester. Vid test av tillst˚ands¨overg˚angar var en utformad tillst˚andstabell utg˚angspunkten f¨or testerna.
Vanligtvis identifieras risker med testarbetet och en utf¨orlig testplan och strategi utarbetas men d˚a den nya implementationen av Friendlyreader inte ¨ar lanserad i nul¨aget och inte ¨ar s¨arskilt omfattande ignorerades detta och test-arbetet utgick enbart fr˚an testfall. I de framtagna testfallen f¨or Friendlyreader inkluderades kravreferens f¨or att identifiera vilket eller vilka krav som unders¨oks vid varje testfall. De angivna teststegen i respektive testfall f¨or Friendlyreader utformades utan f¨orv¨antat resultat, detta ans˚ags inte n¨odv¨andigt d˚a testfallen inte var s¨arskilt komplexa eller tidskr¨avande.
Den testdata som var framtagen f¨or testerna kom fr˚an Wikipedia. De krav som fanns f¨or testdata var att den beh¨ovde minst inneh˚alla 10 meningar samt vara en text med riktigt inneh˚all, inte p˚ahittade ord, f¨or att analyser skul-le fungera. Detta f¨or att exempelvis identifiera synonymer. Den testdata som anv¨andes inneh¨oll 13 meningar och behandlade ¨amnet kognitionsvetenskap. De testfall som inte fick ett f¨orv¨antat resultat dokumenterades i en felrapport.
Genomf¨orandet av testerna utgick fr˚an en utformad testspecifikation, se Bi-laga B.
6.2
Resultat
Nedan f¨oljer resultatet fr˚an genomf¨orandet av testerna, se Tabell 8. I tabellen anges resultatet ”OK” om det f¨orv¨antade resultatet st¨amde ¨overens med det verkliga och resultatet ”Ej OK” om det inte st¨amde ¨overens.
Tabell 8: Resultat fr˚an testfall ID Resultat TF-01 OK TF-02 OK TF-03 OK TF-04 OK TF-05 OK TF-06 OK TF-07 OK TF-08 OK TF-09 OK TF-09 OK TF-10 OK TF-11 OK TF-12 OK TF-13 OK TF-14 OK TF-15 Ej OK TF-16 Ej OK TF-17 Ej OK TF-18 OK T ¨O-01 OK T ¨O-02 OK T ¨O-03 OK T ¨O-04 OK T ¨O-06 OK T ¨O-06 OK
Som tabellen visar s˚a st¨amde det f¨orv¨antade resultatet ¨overens med det verk-liga resultatet f¨or majoriteten av testfallen. De testfall som inte fick resultatet OK var TF-15, TF-16 samt TF-17. Testfallen syftade att unders¨oka om imple-mentationen uppfyllde krav 15, 15.1, 15.2. Dessa krav behandlade f¨or¨andring av textens bredd samt anv¨andningen av l¨aslinjalen. F¨or att se felbeskrivning av testfallen som inte lyckades se felrapporten, Bilaga C.
7
Diskussion
Syftet med detta arbete har varit att identifiera vilken funktionalitet som ef-terfr˚agas fr˚an personer med l¨as- och skrivsv˚arigheter och implementera detta i Friendlyreader f¨or att sedan s¨akerst¨alla att funktionaliteten fungerar som den ska. I detta avsnitt diskuteras resultatet fr˚an arbetets tre olika faser; f¨orstudie, implementation och test. ¨Aven rekommendationer f¨or framtida arbete presen-teras.
7.1
F¨
orstudie
Under genomf¨orandet av kravinsamlingen blev det tydligt att de behov som anv¨andarna uppvisat fr¨amst har fokus p˚a det grafiska, n¨ar det finns flera spr˚ ak-teknologiska metoder att ta hj¨alp av men som de inte uttrycker lika starkt behov av. Detta kan bero p˚a att de inte ¨ar medvetna om att denna typ av teknologi finns tillg¨anglig. De flesta verktyg som finns tillg¨angliga idag f¨or att underl¨atta l¨asning av text har fokus p˚a grafiska anpassningar eller att f˚a texten uppl¨ast, vilket kan inneb¨ara att dessa personer inte kommit i kontakt med ett verktyg baserat p˚a spr˚akteknologiska funktioner. Som tidigare presenterat i av-snitt 3.1.1 ¨ar en stor felk¨alla vid utveckling av IT-system kraven inkluderade i kravspecifikationen. Det kan bero p˚a flera olika anledningar, exempelvis att fel personer deltar i kravinsamlingen. Trots att de personer som exempelvis delta-git i projektet Begriplig text ¨ar inkluderade i verktygets m˚algrupper s˚a ¨ar dessa m˚algrupper s˚a breda att det ¨ar sv˚art att samla in krav f¨or samtligas behov. ¨Ar dessutom dessa individer inte medvetna om de m¨ojligheter som spr˚akteknologi kan medf¨ora ¨ar det sv˚art att efterfr˚aga n˚agonting man inte vet existerar. Av just denna anledningen vill jag belysa betydelsen av det fokus som detta arbete har haft.
En av de fr¨amsta utg˚angspunkterna f¨or f¨orstudien var interna rapporter och studier. Detta kan medf¨ora viss problematik d˚a samtliga rapporter inte ¨
ar publicerade vilket g¨or f¨orstudien sv˚ar att replikera. Eftersom att de studier som utf¨orts specifikt unders¨okt TeCST och Friendlyreader kan dess resultat ¨
aven vara sv˚ara att generalisera i ett st¨orre perspektiv. Detta beh¨over dock inte enbart ses som en nackdel. D˚a stor del av kravinsamlingen grundat sig i dessa studier som ¨ar utf¨orda f¨or projektet DigInclude ¨ar dess resultat h¨ogst relevant f¨or just detta arbete och med stor s¨akerhet ¨ar studiernas resultat applicerbart p˚a Friendlyreader.
Tre av de krav som identifierades under kravinsamlingen kom fr˚an kart-l¨aggning av funktionalitetens hos TeCST. Utav dessa tre krav implementerades det som prioriterades som skall-krav, 6. Anv¨andaren skall kunna f¨orenkla texten p˚a olika s¨att. D˚a TeCST har som tidigare n¨amnt har en annan m˚algrupp ¨an Friendlyreader och denna funktionalitet som nu finns implementerad hos
