Disskusion
I diskussionsdelen tar jag upp de funderingar som framkommit under arbetes gång samt gör en del reflektioner på help desken som fenomen i sig.
Begreppen användbarhet och funktionalitet
En intressant skillnad när man arbetar med material som behandlar människa datorinteraktion (MDI), som detta nog får ses vara en del i, är skillnaden mellan begreppen användbarhet och funktionalitet. Båda dessa begrepp är intressanta i studier av MDI och dess underliggande vetenskaper. Om man i begreppet användbarhet ser efter vad en användare vill göra med ett visst system så ser man i funktionaliteten vad användaren faktiskt kan göra med systemet. Dessa båda begrepp är på ett sätt tätt sammanbundna men kan på ett annat sätt vara direkta motpoler. Användbarhet kan bara testas mot (med) en faktisk användare, begreppet i sig är bundet till användaren. Skillnaden mot funktionaliteten är att den senare är statiskt bundet till systemet i sig. Systemets funktionalitet kan vara komplett då den alltid följer den specifikation systemet har.
I många fall av konstruerande av applikationer så blandas dessa begrepp alltför lätt ihop. Konstruktörerna ser till den fulländade funktionalitet som deras system faktiskt har, men när produkten kommer ut är den ur användbarhetssynpunkt en katastrof. En användare som inte ser möjligheterna med det system som sätts framför denne kommer inte att ta sig tid eller ens vilja lära sig det nya systemet.
Det enda som kan lösa de konflikter då användaren inte ser möjligheterna och konstruktörerna inte användarens begränsningar är kommunikation. En kontinuerlig feedback från användaren till konstruktören är det enda sättet att få fram en fungerande applikation. Återigen är huvudpunkten att sätta användaren i centrum, då konstruktören måste ses som mer flexibel och bör kunna anpassa systemet till användaren. Ett belysande exempel är ofta de felmeddelanden som kan dyka upp på skärmen när man arbetar. Om dessa bara vore formulerade med användaren i åtanke istället för med oförståeliga koder så skulle dessa var mer användbara och till och med tjäna sitt syfte. Felmeddelanden är ofta svåra att förstå och de lämnar sällan eller aldrig den feedback som är nödvändig för att man skal förstå problemet eller lära sig vad man skall göra för att det inte skall upprepas. En idé kanske skulle vara om man kunde dra och släppa lämpligt felmeddelande på en hjälpapplikation.
Help desk - att angripa symtom istället för orsak
Egentligen får konstruerandet av en help desk ses som ett misslyckande. I alla fall om den är avsedd för direkt felsökning av ett företags produkter. Egentligen borde dessa vara så anpassade till den användare som den riktar sig till att felsökning inte borde vara nödvändig, och om den skulle finnas vara inbyggd i själva applikationen.
Detta är naturligtvis en ouppnåelig utopi, fel kommer förmodligen alltid att finnas vilken vara som än produceras. Det kan dock vara värt att ha i åtanke innan man släpper ut något, det kan vara bättre att lägga några extra arbetsveckor för att slippa en alltför stor uppföljningskostnad. Men visst vore det otroligt bra om ett system fungerade från början och saknade grund till missuppfattningar.
Ett mer idealt sätt att använda sig av help desken vore i så fall att använda den som medium för utveckling och uppföljning. Att från en bestämd help desk kunna se vad för möjligheter det finns att utveckla sig inom ett visst område eller se vad som händer i utvecklingen kring en vara.
Användaren och gränssnittsutveckling
Utvecklingen inom användarvänlighet och MDI har egentligen gått otroligt snabbt. Det finns dock fortfarande väldigt mycket kvar att göra innan människan kan fullt utnyttja de fördelar som en dator eller maskin kan ge henne.
De första systemen som grundade sig enbart på kommando språk stängde så gott som helt ute nybörjare och gjorde datorn helt ointaglig för den breda allmänheten. Datorn var då enbart något för de väldigt intresserade eller de som hade den bästa utbildningen inom området. Språken finns förvisso kvar men då enbart inom utbildning och forskning. Användningsområdet för slutanvändaren är så gott som obefintligt. En av de största nackdelarna med kommando baserade system är att de ställer alldeles förstora minnes krav på användaren, då denne måste hålla alternativ och valmöjligheter i huvudet.
Nästa steg är de så kallade menysystemen som är uppbyggda på trädstrukturer (jfr TLC). Fördelen som dessa system innebar var att man minskade minnes kraven betydligt så användaren snabbt blev varse vilka valmöjligheter som fanns till buds. Nackdelen är de navigeringsproblem som man inte kom åt, det var lätt att tappa bort sig i menyerna. Denna modell utvecklade sig emellertid till det vi är mer vana vid i dag som exempelvis MacOS och (till viss del) Windows. Utvecklingen har rört sig mot en direkt manipulation i form av användarkontroll och WYSIWYG gränssnitt.
Dessvärre har vi en bit kvar till en komplett människa-dator interaktion. Utvecklingen driver på och man jobbar mer och mer med att sätta slutanvändaren i centrum. Den framtid som logiskt skulle följa denna utveckling är maskiner som förstår och kan tolka det dagliga språk som vi använder. Detta skulle göra att användaren skulle kunna få en direkt feedback och exakta och direkta svar på frågeformuleringar. En help desk som förstår naturliga språk och som kan presentera informationen på samma sätt vore den ideala lösningen.
För att föra disskusionen framåt och inriktningen på vidare vetenskap åt rätt håll är ett lämplig förhållningssätt att ha en bred forskning. Genom att låta utvecklingen inom de kognitiva vetenskaperna gå hand i hand med utvecklingen av system och programvara kan man nå en närmare förståelse av människors förhållande till maskiner i allmänhet och datorer i synnerhet. Det är nödvändigt att den kognitiva forskningen delar med sig mer av den kunskap de har till systemutvecklarna, och att dessa i sin tur är öppna för den kunskap som faktiskt finns. För att göra båda grupperna mer medvetna om detta är studier av liknande typ som den här nödvändiga, studier där båda vetenskaperna presenteras och ställs mot varandra.