Tema: IT: Praktiserad tankeriktighet

Program blir intuitiva och användarvänliga om de tillämpar metaforer och arbetssätt korrekt, inte annars.

Det som gör program användarvänliga och tankeriktiga är i grunden två saker. Det ena är att de använder rätta grafiska symboler. Det är det mest påtagliga och därför fokuserar man lätt på det. Lika viktigt är dock att rätt symboler används i rätt sammanhang och ett korrekt arbetssätt. Men det är betydligt svårare att bedöma. Just därför är de än viktigare att fokusera på. Arbetssättet som skapar dessa lättillgängliga och lätthanterliga program brukar jag formulera som ett antal dygder:

Användaren styr programmet, inte tvärtom:

Gamla program hade en styrd arbetsgång. Om man satt och registrerade en order och en ny kund ringde in fanns bara två alternativ. Slänga den påbörjade ordern eller låta kunden vänta tills dess att den var klar. Ett modernt program ska låta användaren ha kvar den påbörjade ordern och ända kunna påbörja en ny.

Förlåtande attityd:

Tyvärr utnyttjar användaren ofta en liten del av ett programs potential. Den kunskap som utbildningen gav försvinner snabbt. Det är därför viktigt att programmet bejakar utforskande. Det måste vara möjligt att undersöka innebörden av olika menykommandon, gå in och titta i olika dialogrutor, öppna olika fönster med mera utan att programmet låser användaren eller att data skadas. Ett skräckexempel är när en dialogruta inte låter sig stängas förrän vissa uppgifter matats in. Trots att de uppgifterna inte fanns där tidigare.

Varningar för oåterkalleliga fel:

En del saker är oåterkalleliga, som om programmet måste stänga en påbörjad och olagrad verifikation när dialogrutan för utskrifter ska tas fram. Det går inte att lita på att användaren är införstådd med att det inregistrerade nu försvinner. Därför måste programmet varna henne innan det oåterkalleliga sker.

Datorn ska minnas åt användaren:

Datorer är oerhört bra på att minnas ett myller av små saker. Med människan förhåller det sig precis tvärtom. Därför ska datorn minnas sådant åt dig. Finns det underliggande information till ett registreringsfält bör det framgå med en knapp eller liknande. Det ska inte ligga fördolt i en handbok eller vara de initierade förunnat.

Hjälpsamt program:

Hjälpsamheten ska vara som en servil engelsk butler. Osynlig när den inte behövs men plötsligt närvarande när behov uppstår, som vid varningar och felmeddelanden. Ett servilt program inte bara underrättar oss om felet, det talar också om varför felet uppstod och vad som kan göras för att åtgärda det. Viktigt här är att meddelandets innebörd och de handlingsalternativ som ges är otvetydiga. Man får inte vara osäker på vad som händer om Ja-knappen trycks in.

Överskådlig programstruktur:

Äldre program hade en snårig struktur och var hierarkiska. Stod man i en funktion och ville se menyalternativen för en annan gick inte det. Istället fick den första funktionen stängas, du fick gå till den övergripande menyn och ned i en annan förgrening. Det var svåröverskådligt och svårframkomligt. Därför ska en menystruktur vara platt och överskådlig. Du ska kunna komma åt hela strukturen och inte känna dig osäker över vad som är vad, som att det finns flera faktureringsrutiner. Därför bör det inte finnas extra menyer som hoppar fram under olika omständigheter eller att menyinnehåll som byts ut så att man inte känner igen sig. En fara här är Windows 95 och de höger-musklick-menyer som finns. Grunden är att alla kommandon ska finnas i programmenyn. Knappar, snabbtangenter och högermusmenyer ska bara vara genvägar för dem. Inget annat.

Lättstyrt för nybörjare och erfarna:

Användarens datorvana ska inte spela någon roll. Den oerfarne ska kunna navigera genom hela programmet med musen. För den vane är det ett långsamt sätt. Därför ska så gott som hela programmet också kunna styras från tangentbordet. Hur det sker ska också framgå, som att kortkommandon (Alt-tangenten och bokstav, som Alt + A för Arkivmenyn) är understrykna i menyer och på fältbeteckningar samt att snabbkommandon är utskrivna i menyerna (Kontrolltangent och bokstav, som Ctrl+P).

Guider, sammanhangskänslig hjälpfunktion och bra dokumentation:

Trots enhetligt arbetssätt och metaforer kan det finnas situationer där det här inte räcker till. En komplex uppgift kan då delas upp i flera steg och läggas i en serie dialogrutor där användaren guidas steg för steg till det färdiga resultatet. En annan viktig funktion är hjälpfunktionen. Den bör inte bara finnas utan vara sammanhangskänslig. Det vill säga känna av i vilket sammanhang markören befinner sig. Står den i faktureringsfönstret bör den öppna just det avsnittet i hjälpfunktionen. Bäst är när den går ett steg till och även känner av vilket fält markören står i. Hjälptextens utformning är också ett bortglömt kapitel. En del nöjer sig med en kort förklaring. Men den bör tala om tre saker. En utförlig förklaring av fältets uppgift, var informationen i övrigt används samt var eventuella grundparametrar ändras.

Ett program som tidigt hade en suverän hjälpfunktion var Compact. Stod markören på fältet sort (som styck, par eller paket) i artikelregisterfönstret och jag kallade på hjälp hände det här: Endast text om det här fältet kom fram, det vill säga jag slapp söka mig fram. Texten gav en utförlig information om vad som avsågs, vilka andra moduler som skulle användas informationen och var jag kunde lägga upp nya sortbeteckningar om jag inte var nöjd med de som fanns. Jag minns att jag så snabbt utfört en del testfunktioner utan att riktigt veta hur det gått till. Det var hela tiden så enkelt att bli upplyst att jag aldrig behövde lära mig hur det skulle göras!

Ett framgångsrikt grafiskt gränssnitt bygger alltså i första hand på att programmet fungerar enligt de här och liknande dygder. Därefter kommer att de använder rätt grafiska metaforer på ett riktigt sätt.

Förutom de här dygderna bygger grafiska gränssnitt på repetition. Även om mycket krut har lagts på intuitiva funktioner så framgår det inte med ens. Det är istället genom upprepat bruk som användaren sakta men säkert lär sig hur datorn och alla programmen fungerar. Erfarenheter från ett program kan till exempel tillämpas i ett annat. Erfarenheterna därifrån kan tillämpas i ånyo ett eller i det första, och så vidare.

Problemet är att det metodiska arbetssättet inte är synligt utan tarvar att dels känner till principerna av vilka vi angett de viktigaste ovan, dels inte låter sig förblindas av allt prat om användarvänlighet utan försöker att bedöma just programmets förhållningssätt.

De här omdömena gällde när testerna utfördes. Gränssnitten kan sedan dess ha ändrats både till det sämre och det bättre. Leverantörerna till Hogia Art och Workoffice ville inte delta i test utfört under sommaren 96.

Erik Philipson , förlaget IDG, International Data Group