 |
|
|
|
 |
||
Fel och brister |
||||||
| Smålands- tidningen 1 feb 99 |
För ett par år sedan använde jag ofta Telias automatiska telefonväckning för att säkert komma ur sängen om jag skulle passa en tid, resa bort eller så. Tjänsten var ganska väl utformad, tyckte jag, med en behaglig kvinnoröst som beskrev vad jag skulle göra och framför allt bekräftade när beställningen var riktig. En morgon lyckades jag vakna strax innan telefonväckningen skulle ringa, masade mig ur sängen och gick till telefonen för att försöka avbeställa väckningen. Ingen mening med att resten av familjen vaknar om jag redan är uppe, tänkte jag. Jag slog upp telefonkatalogen och följde anvisningarna. Men i stället för min vanliga kvinna som lugnande sade att väckningen var avbeställd fick jag höra en oartikulerad mansröst som sade "Svaret är nej" flera gånger i tät följd. Nej vadå? Nej, väckningen är inte avbeställd? Eller nej, väckningen kommer inte att utföras? Inte lätt att genomskåda, speciellt inte klockan fem på morgonen. Det visade sig en liten stund senare - när telefonen ringde - att det betydde "nej, det gick inte att avbeställa väckningen". Jag skulle gissa att tiden var för knapp mellan min avbeställning och den begärda väckningstiden. Kanske hade begäran redan skickats vidare och kunde därför inte avbeställas. Mansrösten jag hörde (svaret är nej - svaret är nej - svaret är nej) var förmodligen en av teknikerna som ursprungligen byggde väckningstjänsten och lade in sin egen röst som ett slags standardmeddelande när det inte gick att utföra en begäran. När de testade tjänsten innan installation glömde de kanske fallet med en för sent inkommen avbeställning. En småsak, kan tyckas. Systemet fungerade ju ändå riktigt efter sina tekniska förutsättningar. Förmodligen uppfyllde det specifikationen också. Men det finns alldeles för många exempel på sådana fel i datorsammanhang. Meddelanden, texter, bilder, funktioner som förvirrar och försvårar användningen, även om de är tekniskt korrekta. Tyvärr är det fortfarande vanligt att man formulerar kraven på ett nytt IT-system helt och hållet i termer av teknisk funktion. Det finns historiska skäl till det: ursprungligen var utveckling av informationsteknik en framför allt teknisk uppgift. Man utvecklade i många fall system för att själv använda dem, som räknehjälpmedel eller register. Tanken om en användare utan specialkunskaper och utan något större intresse för systemets tekniska uppbyggnad var ganska främmande. Ett annat, mer praktiskt skäl till att inrikta en specifikation på tekniska funktioner är att den blir ganska lätt att kontrollera när systemet levereras. Om man däremot ställer krav på att det ska gå att använda det blivande systemet blir det genast svårare, och därmed dyrare. Man måste ta reda på vilka som är tänkta att använda systemet, till vad, och i vilka sammanhang. Sedan gäller det att testa det nya systemet under utveckling, för att kunna fånga upp användbarhetsproblemen medan det fortfarande går att göra något åt dem. I takt med att datoranvändningen sprids bland människor utan specialkunskaper ökar kraven på användbarhet och begriplighet. Standardiseringsorgan, konsumentorganisationer och opinionsbildare inom området arbetar aktivt för att formulera och stödja rimliga användningskrav. Men ännu är det en bit kvar. Tänk om bilhandlaren skulle sälja en splitter ny bil med kommentaren "Kom ihåg att du bromsar med högra pedalen på den här modellen. Inga problem, du lär dig snart. Vadå? Helljus? Det kommer i nästa release. Du kan uppgradera i juni." Naturligtvis otänkbart i den mogna bilbranschen, men inom IT-området ser man kunder acceptera motsvarande villkor varje dag.
|
|||||