6.3 Värdering
6.3.10 Slutlig version av användargränssnittet
Eftersom inga problem påträffades med användargränssnittet i den tredje versionen av programmet bestämde vi att detta användargränssnitt fick vara det slutgiltiga.
Kapitel 7
Problem som har uppstått
I detta kapitel beskrivs några av de större problem som vi träffade på.
7.1 Utvecklingsmiljön
I början tog det ett tag innan vi lärde oss att bemästra Eclipse och Tomcat och hur dessa kunde integreras. Det tog också ett tag att lära sig att leva med diverse odokumenterade funktioner hos Eclipse. Bland annat verkar sökfunktionen i filerna bara fungera ibland (det är fortfarande oklart un- der vilka förhållanden en positiv prognos kan utfärdas) liksom funktionen som genererar JavaDoc-kommentarer utifrån hur metoderna och klasser- na är skapade.
7.2 Teckenkodning
Ett återkommande problem var teckenkodningen. Vi har konsekvent an- vänt oss av UTF-8. Första gången problemen uppstod var när vi skulle
skriva ner enkätundersökningsdata till en fil. Det tog ett tag innan vi hade lärt oss att hitta felet med hjälp av Eclipses avlusningsfunktioner men när vi började med det gick det lättare och då kunde vi lokalisera felet.
Under felsökningen kom vi även på att vi kunde ha ett filter1 som be- stämde vilken teckenkodning den till servern inkommande begäran (eng.
request) skulle ha, vilket vi använder med gott resultat.
1URL: http://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/
servlet/Filter.html
Andra teckenkodningsproblem uppstod till exempel i den så kalla- de properties2-filen där vi nu använder HTML-beteckningen3 för å, ä och ö i de flesta textsträngarna, men för de som ska skrivas in i e- postmeddelanden använder vi unicode-teckensekvenser för å, ä, ö4för att e-postmeddelandet ska bli korrekt.
I koden för att generera JavaScriptens dialogrutor kan vi inte heller skriva å, ä eller ö utan skriver istället unicode-teckensekvenser som ovan för att å, ä och ö ska visas korrekt i webbläsaren.
7.3 Validering av formulärdata
Det var relativt enkelt att validera de statiskt skapade formulären, där vi använder en egenskapad böna av klassen ValidatingDynaAc- tionForm. Den utökar DynaActionFormmen har en egen validerings-
metod som anropas innan datat sparas. Om valideringen hittade fel visas formuläret igen med de korrekta data som användaren skrev in samt ett meddelande om vilka data som var felaktiga.
Det går till så att valideringsmetoden returnerar ett objekt av klassen
ActionErrorsinnehållandes felmeddelanden specificerade i properties-
filen vilka automatiskt presenteras på sidan med formuläret där koden
<html:errors/>finns påJSP-sidan. Man kan använda flera felmedde-
landen till varje webbsida och det går även att bestämma var på sidan man vill att de ska placeras.
Först försökte vi använda det till Struts medföljande valideringsram- verket men vi kunde inte använda detta tillsammans med våra Action- klasser som utökar DispatchAction. Vi valde därför att frångå valide-
ringsramverket.
7.3.1 Validering av enkätsvar
Det var betydligt svårare att validera de dynamiskt skapade formulären som utgör enkäterna eftersom de skapas under programmets körning och vi därför inte vet vad vi kan förvänta oss för indata. Detta löste sig bland annat genom att en tom sträng skickas om svar ej fyllts i, förutom för flervalsfrågor. Vid radioknappar fick vi lägga till ett gömt formulärfält
2URL: http://java.sun.com/j2se/1.5.0/docs/api/java/util/
Properties.html
3Till exempel skrivs å somå 4Till exempel skrivs å som \u00E5.
7.4. Begrepp i användargränssnitt 63
med samma namn som radioknapparna för att fältet skulle synas i sva- ret. Tvärtemot vad vi först trodde skickas det första påträffade svaret till fältet med det namnet tillbaka till servern. Det innebär att det gömda fältet måste vara efter radioknapparna. Om respondenten inte ger något svar på en fråga med radioknappar skickas således en tom sträng.
Validering av numeriska data löstes genom att i formulärelementets namn ange villkoren för detta.
Det enda alternativet för att validera på serversidan som vi hittade var att använda så kallade map-backed forms, det vill säga bönor som utö- kar klassen ActionFormoch som innehåller en TreeMapsom automa-
tiskt fylls upp med formulärdatat. För att den skulle fyllas upp krävdes att formulärelementen namngavs enligt ett visst mönster. I vårt fall sätter vi namnen tillvalue(x)därxär unikt för varje fråge och underfråga. Då
måste även metoder som hetergetValueochsetValuefinnas i bönan.
Bönan innehåller även en valideringsmetod som anropas när valideringen ska genomföras.
Det fungerade fint att flytta in formulärdatat i bönorna men det var svårare att läsa tillbaka dem om ett fel hade uppstått. Det löste vi genom att iJSP-sidan som visar upp enkäten fylla upp formuläret igen om de hade
fyllts i tidigare.
7.4 Begrepp i användargränssnitt
Det har varit svårt att sätta ett namn på kombinationen av en enkät och en målgrupp. I rapporten har vi valt att använda ordet enkätundersökning men det kan vi inte räkna med att våra användare förstår. Det svåra för våra testanvändare låg i att förstå att en enkät i sig inte går att använda som en enkätundersökning, utan att man måste ha med en målgrupp, och att vi då kallar denna kombination för enkätundersökning. Istället för ”un- dersökning” funderade vi kring termen ”kombinera enkät och målgrupp” men det faller sig inte heller helt naturligt. Användaren kanske inte för- står varför han eller hon ska kombinera en enkät och en målgrupp? Den är dessutom klumpig att använda i brödtexten och på knappar. Att förkorta termen till ”kombination” känns inte heller som ett bra sätt att tydliggö- ra vad vi menar. Slutligen kom vi fram till att gruppen av frågor skulle benämnas ”frågor” istället för ”enkät”, och att det som vi tidigare kalla- de ”enkätundersökning” och ”undersökning” numera är synonymt med ordet ”enkät”.
Det är viktigt att vår valda term används konsekvent i användargräns- snittet, och vi använder alltså termen ”enkät” i menyer, instruktioner,
Kapitel 8
Resulterande produkter
I det här kapitlet presenterar vi vårt resultat, det vill säga de färdiga webb- applikationerna. En diskussion om hur kraven har uppnåtts finns i kapitel 9.
8.1 Användargränssnitt
Vårt användargränssnitt utgörs avHTML-kod på olika webbsidor som tol-
kas av användarens webbläsare. I några fall har vi lagt till JavaScript, men dessa förbättrar användarvänligheten och är inte nödvändiga. Vi har även en bild, men den är inte heller nödvändig för att systemet ska kunna an- vändas. Gränssnittet fungerar bra även om användaren inte använder en skärm utan en punktdisplay för att tillgodogöra sig gränssnittet. Tangent- bord eller motsvarande krävs för att mata in text och navigera, men musen behövs inte.
Vi har provat applikationerna i några vanliga webbläsare och det har fungerat bra. Applikationerna kräver inte attCSSanvänds och de fungerar
även i den textbaserade webbläsaren Lynx.
Skärmbilder av användargränssnittet finns i bilaga G. Gränssnittet vi- sar hur hela applikationen är tänkt att se ut, men vi har inte implementerat all funktionalitet. Vi valde att skapa hela gränssnittet för att det skulle vara lättare att utvärdera det med testanvändarna.