Joel Spolsky (2000. április 10.)
Fordította: Sipos Róbert
Eredeti oldal

Környezetünk kézben tartása boldoggá tesz

A legtöbb általam ismert keménykötésű C++ programozó utálja a felhasználói felület programozását. Ez meglep, mert szerintem az UI (Felhasználói Felület - User Interface) létrehozása könnyű, egyszerű és szórakoztató. Könnyű, mert legtöbbször nincs bonyolultabb programozási ismeretre szükség annál, mint hogy hogyan rakjunk egy négyzetet egy másik közepébe; egyszerű, mert amikor hibát vétünk, azonnal látjuk és rögtön korrigálni tudjuk valamint szórakoztató is, mert az eredmény azonnal látható és úgy érezzük, hogy szinte kézzel gyúrjuk össze a programot.

Azt hiszem, a legtöbb programozó félelme az UI programozásától abból ered, hogy félnek az UI tervezésétől. Úgy gondolják, hogy a felület tervezése olyasmi, mint a grafikus munka: valamiféle ködös folyamat, aminek során kreatív, sört vedelő, feketébe öltözött piercinges emberek jól kinéző művészi cuccokat csinálnak. A programozók szeretik magukat analitikus, logikusan gondolkodó embernek hinni: erősek a racionalitásokban, de gyengék művészi téren. Tehát úgy gondolják, nem tudnak felhasználói felületet tervezni. Nos, én tulajdonképpen meg vagyok róla győződve, hogy a felhasználói felület tervezése logikus, racionális folyamat, nem pedig olyan rejtélyes valami, amihez művészeti főiskolás diploma és neonlila haj kellene. Lehet racionálisan gondolkodni a felhasználói felületekről és vannak egyszerű szabályok, amiket bárhol alkalmazhatunk, hogy a programunk felületét jobbá tegyük.

Nem fogok a Zen és az UI tervezés művészetéről szónokolni. Ez nem művészet, nem buddhizmus, csupán néhány egyszerű szabály, amiket racionálisan és következetesen alkalmazni lehet. Ez az esszé programozók számára készült. Szerintem neked nem arra van szükséged, hogy elmagyarázzam, hogyan kell egy menüsort összehozni, inkább arról beszélek, mit tegyél abba a menübe. Az első axiómát, amit megtanítok a jó UI tervezéséről nem lesz nehéz megérteni.

Az első igazi munkahelyem egy nagy pékségben volt, ahol hat kenyérdagasztó működött. Minden két gépsorhoz tartozott egy dagasztó, ami 180 kiló tésztát termelt, ezeket bal vagy jobb oldalra lehetett irányítani:

kep1

Legalábbis ez volt a terv. Valójában a 3. dagasztó és a 3. és 5. gépsor sem készült még el. Így hát az elrendezés a következőképpen nézett ki:

kep1

A figyelmes olvasók észrevesznek valamit: hogyan került el a 2. dagasztótól a tészta a 6. gépsorhoz? Nos itt jöttem én a képbe. Akár hiszed, akár nem, az én munkám az volt, hogy a 2. dagasztó mellett álltam, amint kijött a gépből, elkaptam a 180 kiló tésztát egy hatalmas fürdőkádszerű kerekes talicskával és eltalicskáztam a 6. gyártósorhoz majd egy csörlőszerű szerkezettel kiemeltem a tésztát a gyártósorra. Ezt kellett csinálnom tízpercenként este 10-től reggel 4-ig.

De persze voltak egyéb bonyodalmak is. A gyártósor nem tudta kezelni egyben a 180 kiló tésztát, úgyhogy egy nagy késsel fel kellett vágnom 10 darabra. Nem is részletezem...

Az első nap persze teljesen kivoltam. Lehetetlennek tűnt folytatni. Minden csontom fájt. A testemnek még olyan helyein is fájdalmat éreztem, amiről addig nem is tudtam, hogy létezik.

Először is nem tudtam megfelelően ellátni a gyártósort tésztával. Minden egyes alkalommal, amikor megszakadt a tésztaellátás, az nagy rést okozott a soron. Amikor ilyen üres rész is bement a sütőbe, (ami állandó energiát használt fel kevesebb mennyiségű kenyér megsütésére) az ugyanakkor bekerült kenyér mind megégett. Néha a gyártósor beragadt és megállt, a dagasztó viszont nem, így folyamatosan annak a kockázata állt fenn, hogy kifogyok a kerekes tárolókból. Amikor ez végül megtörtént, feltisztítottam a padlót majd bekentem zsírral, oda kiborítottam a tésztát, hogy később aztán összekaparjam. Na nem mintha ez megoldotta volna a problémát, mert ha a tészta 30 percnél tovább állt, akkor megkelt és már nem lehetett belőle rendes kenyeret sütni. Ekkor fel kellett szeletelni 5 kilós darabokra és újra belekeverni a többibe jövőbeli feldolgozásra.

Nagyjából egy hét múlva már annyira belejöttem, hogy ha jól emlékszem, 10 percenként két perc pihenőre is jutott időm. Kitaláltam egy pontos beosztást és megtanultam, hogyan utasítsam a dagasztót leállásra, amikor a gyártósor beragadt.

És elkezdtem rajta gondolkodni, hogy - mintha csak a tamponreklám foglalkoztatna - mi történik a rosszabb napokon.

Egyszer észrevettem, hogy az egyik talicskának rosszak a kerekei; nem forognak rendesen. Néha nem is arra ment, amerre szerettem volna és nekitoltam mindennek. De ez még csak kicsit volt bosszantó. Néha, amikor meghúztam a láncot, ami felemeli a kádat a talicskáról, megvágott egy kiálló vas. Egy másik apró bosszúság. Néha, amikor az üres talicskával szaladtam vissza a dagasztóhoz, hogy elkapjam az új adag tésztát, kicsit megcsúsztam a zsíros padlón. Persze nem estem el, ez csak egy újabb apró bosszantó dolog volt.

Persze voltak kis győzelmeim is. Megtanultam, hogy kell pontosan időben érkezni a tésztakészítéshez, úgyhogy a friss tészta pont akkorra érkezett a gépsorhoz, amikor az előző elkészült. Így a lehető legfrissebb tésztából a legjobb kenyér készült. Néhány győzelmem még ennél is kisebb volt: megláttam kis tésztadarabkákat a falon, amelyek a dagasztóból estek oda és rászáradtak. A farzsebemben hordott kaparóval levakartam és a szemétbe dobtam őket. IGEN! A tészták szeletekre vágása néha egészen gyorsan és könnyedén sikerült. Apró elégedett pillanatok voltak ezek, amikor a körülöttem álló világot sikerült felügyelet alatt tartani, még ha szerény mértékben is.

Hát ilyenek voltak azok a napok. Néhány apró bosszúság, néhány apró öröm. De ezek összeadódtak. Még a legkisebb, szinte jelentéktelen bosszúság is befolyásolja a hangulatot. Az érzelmeket nem az esemény jelentősége, hanem a minősége határozza meg.

Rájöttem, hogy a megelégedett napok azok voltak, amikor sokkal több sikerélményem volt, mint bosszúságom.

Évekkel később, amikor főiskolára kerültem, megtanultam egy fontos pszichológiai elméletet, amit Dr. Martin E. P. Seligman talált ki és Tanult Tehetetlenségnek hívnak. Ez az elmélet - évek kutatómunkájának eredményeként - azt mondta ki, hogy a depresszió nagy része abból az érzésből adódik, hogy nem tudod kontrollálni a környezetedet. Minél jobban érzed, hogy ura vagy a munkádnak és a körülötted történteknek, annál boldogabbnak érzed magad. Amikor frusztráltnak, dühösnek, zaklatottnak érzed magad, az lehet, hogy azért van, mert valami olyan dolog történt - akár még csak valami egészen kicsi is - amit nem tudsz befolyásolni. Például a billentyűzeteden a szóköz bilentyű nem működik megfelelően. Amikor gépelsz, néhány szó egybeíródik. Ez dühítő lesz, mert amikor leütöd ezt a billentyűt, semmi nem történik. A bejárati ajtó zárja nem tökéletes. Újabb apró frusztráló dolog. Ezek a dolgok összeadódnak és elégedetlenné tesznek bennünket a mindennapokban. Még ha olyan apróságnak tűnnek is, amik nem érdemelnek figyelmet (hiszen Afrikában az emberek éheznek, az ég szerelmére, akkor mit idegeskedjek én egy nyavajás szóköz miatt), akkor is befolyásolják a hangulatunkat.

Ennyi bevezető után térjünk vissza a számítógépekhez. Képzeljünk el egy átlagos haladó Windows felhasználót, mondjuk Petit. Amikor a felhasználói felületeken dolgozunk, segít ha a képzeletbeli felhasználó helyébe gondoljuk magunkat. Minél élethűbb az elképzelt felhasználó, annál inkább el tudod képzelni, hogyan használja a termékedet. Peti könyvelő egy műszaki könyvkiadónál, hat éve használ Windowst az irodában és néha otthon is. Eléggé hozzáértő és gyakorlott. Saját maga telepíti a programokat, számítógépes magazint olvas és még néhány egyszerű Word makrót is képes megírni, hogy segítsen a titkárnőknek számlákat küldeni. Van internete otthon is. Peti sosem használt Macintosht. "Túl drágák" - mondja - "megvehetsz egy 2 GHz-es PC-t 2 giga rammal ugyanannyi pénzből, mint egy..." Oké, Peti, értjük!

Egy nap Peti barátnője, Rozi megkéri, hogy segítsen neki egy számítógépes problémában. Neki viszont Macintosh iBook-ja van, mert szereti az áttetsző hátteret. Amikor Peti leül a Macintosh elé, hamar dühbe gurul. "Utálom ezeket a cuccokat" - mondja. Persze végül segít Rozinak, de ingerlékeny lesz. "A Macintoshnak annyira idétlen a felhasználói felülete". Idétlen? Miről beszélsz? Hiszen mindenki tudja, hogy a Macintoshnak aztán tényleg elegáns felhasználói felülete van, nem? A könnyű használhatóság megtestesítője, nem?

Nos itt van a probléma analízise az én szemszögemből:

A Macintishon amikor egy ablakot mozgatni akarsz, meg kell fogni a szélét az egérrel. Windowson a címsorát kell megragadni. Amikor a szélét mozgatod, az ott az átméretezésre szolgál. Amikor Peti megpróbál segíteni Rozinak, megpróbálja átméretezni az ablakot azzal, hogy a jobb oldalát megragadja. Bosszantó módon azonban ahelyett, hogy átméreteződne, az egész ablak elmozdul.

Windowson ha egy dialógusablak megjelenik, Enter vagy szóköz billentyű leütésével be lehet zárni. Macen a szóköz nem működik. Általában az egérrel kell kattintani. Amikor egy üzenetablakot kap, Peti megpróbálja bezárni azt a szóközzel, ahogyan az elmúlt hat évben is tette. Először semmi nem történik. Anélkül, hogy tudatában lenne, Peti erősebben rácsap a szóközre, mert azt gondolja, a baj az, hogy a Mac nem érzékelte az előző leütést. Nos tulajdonképpen érzékelte, csak épp nem foglalkozott vele! Végül kénytelen az egeret használni. Újabb apró bosszúság.

Peti azt is megtanulta, hogy az Alt+F4 bezárja az ablakot. Macen ez a hangerőt módosítja. Egyszer csak Peti az Internet Explorer ikonra akar kattintani a desktopon, amit épp egy másik ablak eltakar. Így hát leüti az Alt+F4-et, hogy bezárja az ablakot és azonnal kettőt kattintson az ikonon, amint megjelenik. Az Alt+F4 megemeli a hangerőt, de nem zárja be az ablakot, úgyhogy a dupla klikk a bezárni kívánt ablak ezközsávján lévő Help gombot éri, így megjelenik a Súgó ablak, úgyhogy most már két ablak is nyitva van, amit be kell zárnia.

Újabb kellemetlen meglepetés. De gondolj bele: ezek összeadódnak. A nap végére Peti ingerlékeny és rosszkedvű lesz. Amikor megpróbálta a dolgokat irányítani, azok nem reagáltak. A szóköz és az Alt+F4 tulajdonképpen "nem működött", mintha tönkrement volna. Az ablak nem engedelmeskedett: amikor megpróbálta átméretezni, egy kis csínytevés történt, mert elmozdult ahelyett, hogy átméreteződött volna. Rossz ablak! Mégha ezek a dolgok csak tudatalattiak is, a végső eredmény az lesz, hogy az irányíthatatlanság érzete tehetetlenséggé, az pedig rosszkedvé válik. "A saját gépem a jó" - mondja Peti - "Pont úgy van minden beállítva, ahogy én szeretem. De ezeket a vacak Maceket nehéz használni. Folyamatosan bosszantanak. Ha az Apple a Newtonokra szánt évek alatt inkább a MacOS-en dolgozott volna az oprendszer nem lenne ekkora zagyvaság."

Így van Peti, mi jobban tudjuk. Az általános benyomás annak ellenére alakult ki, hogy tény, a Macintosht valóban egyszerű használni - a Mac használók szerint. Hiszen teljesen mindegy, valójában melyik gomb szolgál arra, hogy bezárjunk egy ablakot. A Microsoft programozói - aki feltételezhetően lemásolták a Mac felületét - talán azt gondolták, hogy egy szuper új funkciót adnak hozzá azzal, ha az ablak átméretezése lehetővé válik a széle mozgatásával. A MacOS 8.0 programozói viszont azt gondolták, hozzáadnak egy szuper új funkciót azzal, hogy az ablakok mozgatását lehetővé teszik a szélük megragadásával.

A legtöbb felhasználói felületekből kiinduló flame pont rossz dologra összpontosít [flame: internetes fórumokon előforduló heves, de sehová nem vezető vita - A ford.]. A Windows a jobb, mert több lehetőséget ad arra, hogy átméretezzük az ablakot! És? Ez egyáltalán nem lényeges. A lényeg az, hogy a felület úgy reagál-e, ahogyan a felhasználó elvárja? Ha nem, akkor a felhasználó tehetetlennek fogja magát érezni és úgy fogja gondolni, hogy a dolgok kicsúsznak a keze közül, pont mint ahogy én éreztem, amikor a talicska kerekei nem arra fordultak, amerre én szerettem volna és nekiment a falnak.

Az UI nagyon fontos, mert az összbenyomáson kereszül az érzelmeket és a felhasználó hangulatát befolyásolja. Ha rossz, akkor a felhasználó úgy érzi, nem tudja használni a programot, elégedetlen lesz és ezért a te szoftveredet fogja okolni. Ha az UI jó és a dolgok úgy működnek, ahogy a felhasználó várja, akkor jókedvű lesz, hiszen képes kis győzelmek elérésére. Hé! Sikerült berippelni a CD-t! Működik! Szuper a program!

Hogy az embereket elégedetté tegyük, hagyni kell, hogy úgy érezzék, teljesen felügyelik a környezetüket. Hogy ezt tegyük, pontosan kell értelmezni a tetteiket. A felületnek úgy kell működnie, ahogyan elvárják, hogy működnie kellene.

Ennek alapján itt van a legalapvetőbb axióma minden felhasználói felület tervezéséhez:

Egy felhasználói felület akkor jól tervezett, ha a program úgy reagál, ahogyan azt a felhasználó várja.

Ahogy Hillel mondta, minden más részletkérdés. A jó felület tervezésének minden más szabálya ebből következik.

Kitalálni, mit is várnak

Amikor egy új felhasználó elkezdi használni a programot, nem teljesen üres lappal kezd hozzá. Már vannak elvárásai, elképzelései, hogy hogyan működhet a program. Ha már használt hasonlót korábban, azt fogja gondolni, hogy ez hasonlóan működik. Ha már használt bármilyen mást programot korábban, akkor azt fogja gondolni, hogy a te programod is megfelel bizonyos általános követelményeknek. Valószínűleg lesznek intelligens elgondolásai arról, hogy a felhasználói felületnek hogyan kell működnie. Ezt hívják felhasználói, vagy mentális modellnek: van valami elképzelése arról, hogy a program mit fog számára nyújtani.

A programnak is van egy "mentális modellje", csak ez kódolva van bitekben, amelyeket majd a CPU fogja szépen szorgalmasan végrehajtani. Ezt program modellnek hívják és ez A Törvény. Ahogy megtanultuk az előző fejezetből, ha a program modellje azonos a felhasználói modellel, akkor sikeres felhasználói felületet terveztünk.

Lássunk egy példát. A Microsoft Word-ben (és más szövegszerkesztőkben is) amikor beszúrsz egy képet a dokumentumba, a kép tulajdonképpen be lesz illesztve ugyanabba a fájlba, ami a dokumentumot is tartalmazza. Csak létrehozod a képet, behúzod a dokumentumba aztán törlöd az eredeti képfájlt, de a kép attól még benne marad a doksiban.

Nos a HTML nem így működik. A HTML dokumentumoknak a képeket különálló fájlokban kell tárolniuk. Ha veszünk egy olyan felhasználót, aki már használt szövegszerkesztőt de semmit nem tud a HTML-ről és leültetjük egy olyan WYSIWYG HTML szerkesztő elé, mint a FrontPage, majdnem biztosan azt fogja gondolni, hogy a kép a fájlban fog tárolódni. Akár nevezhetnénk ezt felhasználói modell-tehetetlenségnek is.

Így aztán lesz egy szerencsétlen ellentmondás a felhasználói modell (a kép a fájlban tárolódik) és a program modell (a képet külön fájlban kell tárolni) között, de az UI lesz a felelős a problémákért.

Ha egy FrontPage-szerű programot tervezel, már meg is találtad az első UI problémádat. Nem módosíthatod a HTML-t. Valamit tenni kell, hogy a program modellt összhangba hozzuk a felhasználói modellel.

Két lehetőséged van. Megpróbálhatod megváltoztatni a felhasználói modellt, de ez igencsak nehéz lesz. Leírhatod a problémákat a felhasználói útmutatóban, de mindenki tudja, hogy a felhasználók nem olvasnak útmutatókat és azt is, hogy talán nem is kellene, hogy olvassanak. Feldobhatsz egy kis popup ablakot, amiben megjelenik, hogy a képfájlt nem fogod beágyazni, de ez két problémát is okoz: bosszantó lesz a tapasztalt felhasználóknak és hát a felhasználók nem olvassák el a dialógusablakokat sem (erről majd még a 6. fejezetben lesz szó).

Ha a hegy nem megy Mohamedhez... a legjobb választás majdnem mindig az, hogy a felhasználói modell helyett a program modell változtatod meg. Talán amikor beillesztenek egy képet, tárolni kellene a képről egy másolatot a fájlhoz tartozó könyvtár egyik alkönyvtárában, így némileg megfelelhetünk annak a felhasználói elképzelésnek, hogy a kép átmásolódik (így az eredeti biztonságosan letörölhető).

Honnan tudjuk, hogy mi a felhasználói modell?

Hát ezt egyszerű kideríteni. Csak meg kell kérdezni! Válassz ki véletlenszerűen öt embert az irodában, barátaid közül vagy a családodból és mondd el nekik nagyvonalakban, hogy mit csinál a program ("ez egy olyan progi, amivel weblapokat lehet csinálni"). Aztán vázold fel a helyzetet: "Van egy weboldalad, amin dolgozol és egy fenykep.jpg nevű képfájlod. Be tudod illeszteni a képfájlt a weboldalba." Aztán tegyél fel néhány kérdést, ami alapján meghatározhatod a felhasználói modellt. "Mi legyen a képpel? Amikor törlöd a fenykep.jpg-t, a weblap még mindig mutassa azt?"

Egyik barátom egy fotóalbum programon dolgozik. Miután beilleszted a fotókat, a program egy csomó előnézeti képet mutat: pici másolatát minden egyes képnek. Ezeknek a kis előnézeti képeknek az előállítása elég hosszú ideig tart, különösen ha sok fotót kell feldolgozni, így arra gondolt, elmenti ezeket a képeket valahová a lemezre, így csak egyszer kell őket létrehozni. Ennek persze rengeteg módja elképzelhető. Akár egy nagy elonezet nevű fájlban is lehetne őket tárolni. El lehetne tárolni ezeket külön-külön fájlokban is egy elonezetek nevű alkönyvtárba. Meg lehetne jelölni rejtett fájlokként is, hogy a felhasználó ne is tudjon róluk. A barátom kiválasztotta azt a módszert, ami szerinte a legjobb kompromisszum: minden fenykep.jpg nevű fájlról az előnézeti képet egy fenykep_e.jpg nevű fájlban tárolja ugyanabban a könyvtárban. Ha a felhasználó létrehoz egy albumot 30 képpel, akkor mire kész lesz, az előnézeti képekkel együtt 60 fájl lesz ugyanabban a könyvtárban.

Hetekig lehetne a különböző elképzelések előnyeiről és hátrányairól vitatkozni, de van egy sokkal tudományosabb módja is a megoldás keresésének. Csak kérdezz meg egy csapat felhasználót, hogy szerintük mi lenne a legcélszerűbb hely az előnézeti képek mentésére. Természetesen sokuk nem fogja tudni, másokat nem fog érdekelni, de ha sok embert megkérdezel, akkor találhatsz egyfajta konszenzusos megoldást. A legnépszerűbb választás lesz a legjobb felhasználói modell és rajtad áll, hogy a program modellt mennyire tervezed ennek megfelelően.

Aztán a következő lépés, hogy leteszteld az elképzeléseidet. Csinálj egy modellt vagy egy prototípust a felhasználói felületedből és add oda néhány embernek, hogy próbálja ki. Ahogy a feladatokon végig haladnak, kérdezd meg, mit gondolnak, hogy működik ez az egész. A cél az, hogy kitaláld, mit is várnak. Ha a feladat az, hogy "illessz be egy képet", és azt látod, hogy megpróbálják húzd és ejtsd módszerrel bevinni a programodba, akkor rájössz, hogy jó lesz, ha ezt a funkciót implementálod. Ha a Beilleszt menüt választják, akkor rájöhetsz, hogy jobb lesz egy Kép menüpont abban a menüben. Ha a karakterkészlet eszközsávon kicserélik a "Times New Roman" szöveget "Kép beillesztése" szövegre, akkor talán azt látod, hogy valaki még nem ismeri a GUI-t és parancssori felületet vár.

Hogy hány felhasználóra van szükséged a teszthez? "Minél több, annál jobb" juthat eszedbe, ami tudományosnak tűnik. De ez a gondolat rossz. Majdnem mindenki, aki használhatósági teszteket csinál, azt vallja, hogy öt-hat ember már elegendő. Ezek után már ugyanazokat az eredményeket fogod kapni újra és újra és minden egyes új felhasználóval csak az idődet pocsékolod.

Nincs szükség hivatalosan kinéző laboratóriumra, nincs szükséged arra, hogy felhasználókat hívj fel "az utcáról" - egyszerűen csinálsz egy 50%-os próbát, vagyis megszólítod a következő utadba kerülő embert és megkéred, csinálja végig a használhatósági tesztet. Ügyelj rá, hogy ne fecsegj túl sokat, de mondd el neki, hogy működnek a dolgok. Kérd meg, hogy gondolkodjon hangosan és tegyél fel neki egyszerű kérdéseket, így próbáld megtalálni mentális modelljét.

Ha a program modellje nem triviális, akkor ez talán nem a felhasználói modell.

Amikor 6 éves voltam, apukám megvette nekem a világ egyik legelső zsebszámológépét, a HP-35-öset és megpróbált meggyőzni arról, hogy ebben belül egy számítógép van. Arra gondoltam, ez nem valószínű. A Star Trek-ben minden számítógép akkora volt, mint egy szoba és nagy szalagos meghajtóik voltak. Arra gondoltam, van valami logikus kapcsolat a billentyűzeten lévő gombok és a kijelzőn lévő LED-ek között, ami valami matematikailag helyes eredményt ad. (Hé! Még csak 6 éves voltam.)

Fontos tény, hogy a felhasználói modellek nem túl bonyolultak. Amikor az emberek megpróbálják kitalálni, hogy egy program hogyan is működik, valami egyszerű dologra gondolnak, nem pedig valami összetett folyamatra.

Ülj le egy Macintosh elé, nyiss meg két Excel táblát és egy Word dokumentumot. Majdnem minden kezdő felhasználó azt fogja gondolni, hogy az ablakok függetlenek egymástól, hiszen annak néznek ki:

kep2

A felhasználói modell szerint ha a Spreadsheet 1-re kattintok, akkor azt az ablakot hozom előtérbe. Viszont az történik, hogy a Spreadsheet 2 fog előtérbe kerülni, ami szinte mindenkinek bosszantó meglepetés:

kep3

Amint kiderült, a Microsoft Excel program modellje szerint vannak láthatatlan munkafüzeteid külön minden alkalmazáshoz és az ablakok ezekhez a láthatatlan munkafüzetekhez vannak ragasztva. Amikor az Excelt előtérbe hozod, minden az Excelhez tartozó ablak az előtérbe fog kerülni.

Na ne... Láthatatlan munkafüzetek... Szerinted mennyi az esélye, hogy a felhasználói modell tartalmazni fogja a láthatatlan munkafüzetek elképzelését? Valószínűleg nulla. Az új felhasználókat meg fogja lepni ez a viselkedés.

Egy másik példája a Microsoft Windows világának az Alt+Tab kombináció, ami a "következő" ablakra vált. A legtöbb felhasználó valószínűleg azt gondolja, hogy ez egyszerűen csak az összes elérhető ablak között váltogat egymás után. Ha van A, B és C ablakod (A az aktív), akkor az Alt+Tab biztosan a B-re vált. Egy újabb Alt+Tab meg a C-re. Nos ami valójában történik az, hogy a következő Alt+Tab visszavált az A-ra. Az egyetlen lehetőség, hogy a C ablakra válts az, hogy leütöd az Alt-ot és Tab-ot nyomsz kétszer. Ez az egész jó arra, hogy két ablak között váltogass, de szinte senki sem ezt fogja várni, mert ez egészen egyszerűen komplikáltabb, mint a lépjünk mindig a következő ablakra modell.

Már akkor is elég nehéz a program modellt összhangba hozni a felhasználói modellel, ha ezek egyszerűek. Amikor a modellek bonyolultak, ez még nehezebb. Próbáld meg kiválasztani mindig a legegyszerűbb modellt.

Lehetőségek

Amikor bemész egy étterembe és meglátsz egy olyan feliratot, hogy "Kutyát bevinni tilos", talán azt gondolod, hogy Étterem Úr nem szereti a kutyákat, így amikor az éttermet építtette, egyszerűen csak kitette ezt a jelet.

Hát ha ez így van, akkor kellene egy "Kígyót bevinni tilos" tábla is, mert a kígyókat meg aztán már senki nem szereti. És kellene egy "Elefántot bevinni tilos" jel is, mert összetörnék a székeket, amikor le akarnának ülni.

A valódi ok történelmi: ez egy tábla, ami jelzi, hogy az emberek régebben megpróbálták bevinni a kutyáikat az étterembe.

A legtöbb korlátozó jel pont azért létezik, mert a korábbi tulajdonosoknak már elegük volt abból, hogy bizonyos emberek elkövettek X dolgot, így hát csináltak egy jelet, megkérvén őket, hogy ne tegyék. Ha meglátogatsz egy régi, mondjuk 50 éves éttermet, mint a Yankee Doodle-t New Haven-ben, a falak tele vannak jelzésekkel, mint például "Ne rakja a hátizsákját a pultra", melyek a legmegbízhatóbb embertani bizonyítékai annak, hogy valaha az emberek elég sokszor rátették a pultra a hátizsákjukat. A jelzés életkorából meg lehet állapítani, mikor volt a hátizsák népszerű a helyi fiatalok körében.

Persze néha nehezebb rájönni az okokra. "Kérem ne vigyen üvegpalackot a parkba" - ez jelentheti azt, hogy valaki mezítláb sétálva törött üvegdarabba lépvén elvágta a lábát korábban és ezt elegendő oknak látta, hogy beperelje a várost.

A szoftvernek is van hasonló archeológiai emléke: úgy hívják, hogy Beállítások ablak. Csak nyisd meg az Eszközök-Beállítások ablakot és láthatod azoknak a paramétereknek a történetét, amelyeken a tervezők elgondolkodtak a tervezés során. Induláskor nyissuk meg a legutolsó fájlt, amin a felhasználó dolgozott? Igen! Nem! Aztán következik egy két hetes vita, de senki nem akarja megsérteni mások érzéseit, így a programozó betesz egy #ifdef fordításvezérlőt, míg a tervezők megvívják a csatájukat. Végül persze úgy döntenek, hogy beteszik beállításként.

De még az sem kell, hogy vita legyen két ember között: ez egyvalaki dilemmája is lehet. Például nem tudod eldönteni, hogy az adatbázist méretre vagy sebességre optimalizáld-e. Biztosan bosszantott már fel a történelemnek kétségtelenül az egyik leggagyibb "varázsló" ablaka a Windowsban. Ez az ablak annyira hülye, hogy még külön díjat is érdemelne. A díjak egy teljesen új kategóriáját. Ez az ablak akkor jön fel, amikor megpróbálsz valamit keresni a Help-ben:

kep4

A legelső probléma ezzel, hogy zavaró. Megpróbálsz keresni egy kifejezést a súgóban. Ebben a pillanatban épp fütyülsz rá, hogy az adatbázis épp kicsi, nagy, testre szabott vagy csokibevonatú-e. Viszont ebben a pillanatban ez az idióta ablak épp fontoskodó oktatást tart neked arról, hogy létre kell hoznia egy listát (vagy adatbázist). Három bekezdés is van rajta, ebből kettő teljes mértékben összezavar. Ott van a fájdalmasan béna kifejezés: "a súgó fájl(ok)". Tényleg? Mintha attól kellene óvakodnod, hogy lehet egynél több fájlod is. Mintha ez lenne a legcsekélyebb különbség. A dialógusablakon dolgozó programozót kétségtelenül aggasztotta a tény, hogy akár súgó fájl(ok) létrehozása is lehetséges és pontatlan lenne a súgó fájl kifejezés sima használata. Szerinted?

De most komolyan! Szerinted azok az emberek akik ebben a pillanatban épp segítséget kérnek, pont ilyen rejtélyek között tudnak majd dönteni? Sőt, még a gyakorlottabb felhasználók, a programozók MSc diplomával is, akik mindent tudnak az indexelésről meg az adatbázisokról is képtelenek lesznek eldönteni, hogy valójában vajon mire is kértek tőlük választ.

De hogy a dolog még rosszabb legyen, ez nem csak egy egyszerű dialógusablak, á, nem! Ez egy varázsló (egy második lappal, ami csak valami olyasmit mondhat, hogy "köszönjük, hogy alávetette magát ennek a fölösleges időpazarlásnak"). Különben elég egyértelmű, hogy a tervezőknek volt valami elképzelésük arról, melyik a legjobb választás, de ennek ellenére kitalálták ezt a fárasztó varázslót, hogy ráadásul még több lehetőséget is felajánlhassanak.

Ez pedig a felület-tervezés második nagy szabályához vezet bennünket:

Minden alkalommal, amikor egy lehetőséget ajánlasz a felhasználónak, arra kéred, hogy döntsön valamiben.

A felhasználó megkérése, hogy döntsön, önmagában még nem rossz dolog. A választás szabadsága csodálatos. Az emberek szeretnek eszpresszókávé alapú italokat rendelni a Starbucksnál, hiszen olyan sokféle közül választhatnak. Egy nagy Valencia kávét extra forrón!

Baj akkor van, amikor olyan döntéseket kérünk tőlük, ami nem érdekli őket. A súgó fájlok esetében az emberek a súgóra kíváncsiak, mert valami problémájuk akadt olyasmivel, amit valóban meg akarnak oldani, mint például hogy megírjanak egy születésnapi meghívót. A meghívóírás viszont sajnos megszakadt, mert nem tudják, hogy kell fejjel lefelé szálló léggömböket vagy valami hasonlókat nyomtatni, így meg akarják nézni a súgóban. Erre valami idegesítő súgóindexelő-motor programozónak a Microsoftnál - aki ráadásul el van telve saját fontosságának képzetével - támadt az a teljesen agyament ötlete, hogy megszakítsa a felhasználót és elkezdjen neki kiselőadást tartani arról, hogy kell listákat (vagy adatbázist) építeni. Ennek az egész dolognak semmi köze nincs a szülinapi meghívóhoz, viszont garantálja, hogy az ember össze legyen zavarva.

És hidd el: az emberek sokkal kevesebb dologgal törődnek, mint azt gondolnád. Arra használják a programodat, hogy valami feladatot megcsináljanak. A feladat érdekli őket. Ha ez egy grafikus program, akkor valószínűleg azt akarják, hogy minden képpontot tetszés szerint módosíthassanak. Ha ez egy weblap készítő program, akkor biztos lehetsz benne, hogy az oldalukat addig akarják farigcsálni, amíg pont olyan nem lesz, amit elképzeltek.

Viszont nem fogja őket érdekelni, hogy a program eszközsávja az ablak alján vagy tetején van-e. Nem fogja őket érdekelni, hogy a súgó fájl indexelt-e. Egy csomó dolog nem fogja őket érdekelni és a tervezők kötelessége, hogy ezeket a döntéseket megtegyék helyettük, így a felhasználókat ne kelljen zaklatni velük. Az arrogancia csúcsa, amikor a fejlesztő nem képes gondolkodni rajta, hogy vajon melyik megoldás a valóban legjobb és inkább áthárítja a felelősséget a használóra. (És még rosszabb, amikor megpróbálja elrejteni a tényt, hogy a felhasználót bonyolult döntésre kényszeríti azzal, hogy az egészet egy varázslóval leplezi, mint ahogyan a WinHelp teszi. Mintha a felhasználó teljesen bolond lenne, így egy kicsi, kétlépéses mini tanfolyamon kell végigvezetni ahhoz, hogy képes legyen megfontolt választ adni.)

Arról beszéltünk, hogy a tervezés a döntéshozatal művészete. Amikor egy szemetest tervezel a sarokra, egymásnak ellentmondó feltételek gyűrűjében kell döntéseket hoznod. Nehéznek kell lennie, hogy ne fújja el a szél. Könnyűnek kell lennie, hogy a szemetes könnyen felemelhesse. Nagynak kell lennie, hogy sok szemetet tudjon tárolni. Kicsinek kell lennie, hogy ne akadályozza az arra járókat. Amikor tervezel valamit és megpróbálod a felelősséget a felhasználóra hárítani azzal, hogy őt kényszeríted döntésre, akkor valójában nem végzed el a munkádat. Valaki majd csinál egy egyszerűbb programot, ami sokkal kevésbé lesz tolakodó, a legtöbb ember pedig azt fogja kedvelni.

Amior 1990-ben kijött a Microsoft Excel 3.0, ez volt az első alkalmazás, amiben feltűnt egy új funkciót: az eszközsáv. Ésszerű újdonság volt, az emberek megkedvelték és mindenki más lemásolta - olyan mértékben elterjedt, hogy ma már alig lehet látni enélküli programot.

Az eszközsáv olyan sikeres lett, hogy az Excel csapata kutatásokat végzett egy speciális Excel verzióval, amit néhány embernek szétosztottak. Ez a verzió statisztikát vezetett arról, hogy melyek azok a funkciók, amiket az emberek leggyakrabban használnak és ezeket az adatokat elküldte a Microsoft-nak. A következő verzióban még egy sornyi eszköztárgombot adtak a programhoz, ezúttal viszont azokkal a funkciókkal, amelyeket az emberek a leggyakrabban használnak. Remek ötlet!

A baj akkor kezdődött, amikor elfelejtkeztek arról, hogy leállítsák az eszköztár-csapatot, akik nem tudták, hol a határ. Most már arra kérnek, hogy szabd testre a saját eszközsávodat. Arra csináltak egy kényszerítő lehetőséget, hogy képes legyél az eszközsávot bárhová a képernyőre mozgatni. Aztán azon kezdtek el gondolkodni, hogy a menüsor valójában csak egy speciális eszközsáv, amin ikonok helyett szövegek vannak, így azt is el lehessen mozgatni bárhová a képernyőn. Testreszabhatóság szteroidokkal. A probléma: senkit nem érdekel! Soha senkivel nem találkoztam még, aki a menüsort az ablak tetején kívül máshol is el tudta volna képzelni. Rossz vicc: ha a Fájl menüre akarsz kattintani és véletlenül egy picit túlságosan balra ragadod meg, akkor elrántod az egész menüsort és rámozgatod az egyetlen helyre, ahová valószínűleg sosem akartad volna mozgatni: az épp szerkesztett dokumentumra.

kep5

Láttál már ilyet? És ráadásul amikor elköveted ezt a hibát, nem világos, hogy mit is kell tenni a visszaállításhoz. Tehát itt van egy olyan lehetőség (a menüsor mozgatása), amit senki nem akar (na jó, talán az emberek 0,1%-a vágyna rá), de ami majdnem mindenkinek az útjában áll.

Egy nap egyik barátom felhívott, hogy problémája van az e-mail küldéssel. Mint mondta, szürke lett a képernyő fele.

Szürke a képernyő fele?

Öt percbe telt, míg telefonon keresztül rájöttem, mi történt: véletlenül megragadta a Windows eszközsávot a képernyő jobb oldalán és átméretezte:

kep6

Na ez pont olyan dolog, amit senki nem csinálna szándékosan. Rengeteg számítógéphasználó van, akik nem tudnák ezt visszaállítani. Ez egy olyan alapvető hiba, mint amikor véletlenül megváltoztatod egy program beállításait és nem tudod, hogyan állítsd vissza. Megdöbbentő, hogy sok ember újratelepít szoftvereket, amikor a dolgok elkezdenek rendellenesen viselkedni, mert azt legalább tudják, hogy kell újratelepíteni. (Persze meg kellett tanulni előbb eltávolítani, mert különben valószínű, hogy a legtöbb hibás beállítás visszajön.)

"De várjunk csak!" - mondhatnád - "Fontos, hogy legyenek beállítások azoknak a profi felhasználóknak, akik testre akarják szabni a környezetüket!" Nos ez valójában nem is olyan fontos, mint hinnéd. Ez arra emlékeztet engem, amikor elkezdtem Dvorak billentyűzetet használni. A baj az volt, hogy nem egy gépet használok, hanem sokfélét. Más emberek számítógépeit is használom. Elég rendszeresen használok három számítógépet a munkahelyemen, aztán három másikat otthon. A munkahelyi tesztlaborban megint másikat. Az a baj, hogy amikor beállítottam a környezetet, azt nem lehetett továbbvinni, így hát az egész nem érte meg a macerát.

A legprofibb felhasználók rendszeresen több gépet használnak, amiket néhány évente fejlesztenek is, az oprendszerüket is rendszeresen újratelepítik. Igaz, megtalálták, hogy teljesen át lehet konfigurálni a billentyűzetet a Word alatt, meg is változtattak mindent a saját ízlésüknek megfelelően, de amint frissítettek Windows 95-re, ezek a beállítások elvesztek és akkor már különben sem voltak ugyanazon a projekten és így lassacskán leszoktak arról, hogy mindent újrakonfiguráljanak. Sok "power user" barátomat megkérdeztem erről és az derült ki, hogy csak alig néhányuk végez el több testreszabást a legalapvetőbbeken kívül, amelyek ahhoz szükségesek, hogy a rendszer könnyebben kezelhető legyen.

Minden alkalommal, amikor felajánlasz egy lehetőséget, a felhasználót arra kéred, hogy döntsön. Ez azt jelenti, hogy el kell gondolkodnia valamin és arról döntenie kell. Ez nem feltétlenül rossz dolog, de általában jobb, ha minimálisra szorítod az ilyen esetek számát.

Ez viszont nem jelenti azt, hogy szedjünk ki minden választási lehetőséget. Vannak, amikről az emberek szeretnek dönteni: például hogy nézzen ki a dokumentumuk vagy a honlapjuk, vagy bármi más, ami fontos része annak, amin dolgoznak. Ezekben a részekben lehetsz aprólékos: nagyszerű, ha az embereknek választási lehetőséget ajánlasz fel, hiszen annál jobban fogják kedvelni a programot. És van még egy további kategória is, amit az emberek szeretnek: a lehetőség, hogy látható dolgok kinézetét megváltoztassák anélkül, hogy azok viselkedését módosítanák. Mindenki szereti a WinAmp skineket, mindenki képet állít be desktop háttérnek. Mivel ezek a lehetőségek kihatnak a megjelenítésre anélkül, hogy a funkcionalitást megváltoztatnák és mivel a felhasználóknak ezekkel nem kötelező törődni, mert enélkül is el tudják végezni a dolgukat, ezek a lehetőségek jók.

Minták és hasonlatok

Nem könnyű olyan programot fejleszteni, aminek a program modellje megegyezik a felhasználói modellel. Néha a megrendelőnek konkrét elképzelése van arról, hogy hogyan működjön a program és mit csináljon. Ilyen esetekben elég, ha megmutatod a felhasználónak, hogy mi hogy működik. A grafikus felületek esetén ennek egy gyakori módszere a hasonlatok alkalmazása. De nem minden hasonlat megfelelő, így fontos, hogy megértsd, miért is működnek, mert így el tudod dönteni egyről, jó-e vagy nem.

A leghíresebb hasonlat, amit gyakran használnak a Windows és Macintosh esetében, a "desktop hasonlat". Itt vannak ezek az aranyos mappák, benne csinos fájlokkal, amiket lehet ide-oda mozgatni. Megfogsz egy fájlt az egyik mappában és áthúzod egy másikba. Ez a hasonlat tulajdonképpen azért működik, mert a mappák kis képei tulajonképpen a valódi mappákra emlékeztetik az embereket, amiből egyenesen következik, hogy dokumentumokat tudnak beléjük tenni.

Íme egy képernyőmentés a Kai's Photo Soap programból. Vajon kitalálod, hogy lehet nagyítani benne?

kep7

Nem nehéz. A nagyítóüveg egyértelművé teszi. Az emberek tudni fogják, hogy nagyjából hogy fog működni. És nem fognak tartani tőle, hogy a nagyítás majd az eredeti képet is nagyítja, hiszen azt egy valódi nagyító sem tenné.

Egy hasonlat, még egy kevésbé sikerült is sokkal jobban működik, mintha egyáltalán nem lenne hasonlat. Ki tudod találni, hogyan működik a nagyítás a Microsoft Word-ben?

kep8

Két kis nagyító is van a felületen, de egyikük valami rejtélyes ok miatt a nyomtatási előnézet gombja, a másik meg a (ki tudja, pontosan mire is szolgáló) dokumentumtérképé. Itt a nagyítás megváltoztatására egy kis legördülő menü szolgál, ami jelenleg 100%-ot mutat. Egyáltalán nincs hasonlat használva, így a felhasználónak sokkal nehezebb rájönni, hogyan kell nagyítani. Ez persze nem feltétlenül rossz dolog, hiszen a nagyítás talán nem is olyan fontos szövegszerkesztés közben, hogy annyi teret kapjon, mint a Kai programjában. De fogadni mernék rá, hogy több Kai használó fog tudni nagyítani, mint Word használó.

kep9 Egy rosszul választott hasonlat viszont már rosszabb, mintha egyáltalán nem is használnánk hasonlatot. Emlékszel a táskára a Windows 95-ben? Ez a kis aranyos ikon éveken keresztül elfoglalt két négyzetcentiméternyi helyet minden felhasználó asztalán, amíg a Microsoft egyszercsak rá nem jött, hogy igazából senkit nem érdekel. Mégpedig azért, mert ez egy rossz hasonlat. Azért gondolták, hogy legyen egy "táska", mert bele lehet másolni fájlokat, amiket haza szeretnél vinni. De hát amikor fájlokat szeretnél hazavinni, akkor úgyis egy kislemezre másolod rá [manapság már pendrive-ra - A ford.]. Akkor tehát az aktatáska helyett nem inkább a floppyra másolnád? Sosem értettem ezt az aktatáskát. Soha nem is használtam. [Ugyanakkor a floppy ikon még ma is minden programban a mentést jelenti. Lassan viszont felnő egy generáció, ami még életében nem látott kislemezt. Érdekes kihívás a GUI tervezőknek... - A ford.]

Minták

A jól megtervezett tárgyakról már ránézésre meg lehet állapítani, hogyan kell használni őket. Bizonyos ajtók elején egy nagy fémlap helyezkedik el a könyököd magasságában. Az egyetlen dolog, amit ezekkel a fémlapokkal csinálni tudsz, hogy meglököd. Donald Norman szavaival élve a fémlap vár a meglökésre. Más ajtókon lekerekített kilincsek vannak, amelyek szintén egyértelműen működnek. Még azt is magától értetődőnek vesszük, hogyan kell megfogni ezeket. A kilincs vár arra, hogy használd.

Más tárgyak nincsenek ennyire jól megtervezve és nem lehet egyből kitalálni a használatukat. A legjobb példa a CD tokja, amit ujjaink közé kell fogni és egy bizonyos irányban meg kell nyomni. Magáról a tok alakjáról nem lehet erre következtetni. Ha nem ismered a trükkjét, nagyon bosszantó, mert akkor nem tudod kinyitni.

A legjobb módja egy minta létrehozásának, hogy az emberi kéz ellentettjének megfelelő kialakítást tervezel. Nézd meg például, hogy a (különben is remek) Kodak DC-290-es digitális fényképezőgép hogy néz ki elölről és hátulról:

kep10a kep10

Elől egy nagy gumi markolat látható, amihez pont illeszkednek az emberi ujjak. Hátul pedig a bal alsó sarokban bemélyedés van, ami pont olyan, mint egy ujjnak a helye. Amikor bal hüvelykujjadat oda teszed, bal mutatóujjad a fényképező elejét fogja a lencse és egy másik gumibütyök között. Ez olyan komfortos érzést ad, amit nem érezhettél azóta, mióta gyerkként a nagyujjadat szoptad (a másikat meg az orrod köré tetted).

A Kodak mérnökei megpróbálnak meggyőzni, hogy a fényképezőt két kézzel fogd olyan pozícióban, ami biztosítja, hogy stabil lesz és még véletlenül sem takarod el a lencsét. Ennek a gumi burkolatnak nincs külön funkcionalitása, egyetlen szándéka arra ösztönözni, hogy helyesen fogd a fényképezőgépet.

A jó számítógépes UI is használ ilyen mintákat. Nagyjából 10 éve volt, hogy minden gomb háromdimenzióssá vált. Szürke keretek használatával úgy tűnnek, mintha kiemelkednének a képernyőből. Ez pedig nemcsak jól néz ki, hanem fontos jellemző is, mert a 3D gombok arra ösztönöznek, hogy megnyomd őket. Mintha kiállnának a monitorból és arra várnának, hogy rákattintva működésbe hozzuk. Sajnos manapság sok weboldal (nem törődve a mintákkal) a funkcionalitás helyett inkább a menő külsőt választja és így néha gondolkodni kell azon, hogy melyik is a megnyomható gomb. Nézd meg ezt a bannert:

kep11

A "GO" és a "Login" gombok kiemelkednek a háttérből és pont úgy néznek ki, hogy rájuk lehet kattintani. A Site Map és a Help gombok viszot nem tűnnek megnyomhatónak, sőt pont úgy néznek ki, mint a QUOTES felirat, ami viszont nem gomb funkcionalitású.

kep12 Körülbelül négy éve az ablakok jobb alsó sarkában megjelent három kis rece, ami pont úgy néz ki mint valami markolat mintája. Pont olyan, mint amit valaki egy csúszkára rakna, hogy elősegítse a mozgatását. Szinte kéri, hogy fogjuk meg és húzzuk el, így növelve az ablak méretét.

A minták utolsó és egyben talán legjobb példájaként szolgáljon a híres fülekkel ellátott dialógusablak. Emlékszel a régi Mac-es vezérlőpultra?

kep13

Az ötlet az volt, hogy a bal oldali görgethető listából kiválasztva egy ikont a jobb oldali terület megváltozik. Valamilyen okból ez az indirekt kapcsolat rendkívül logikusnak tűnt a programozó számára aki kitalálta, de sok felhasználó mégsem értette a működését. Többek között nem találták ki, hogyan görgessék el a listát, hogy az első 4 ikonon kívül a többit is lássák. De még rosszabb, hogy a legtöbb ember nem értette meg, hogy kapcsolat van az ikonok és a dialógusablak között. Az ikonok úgy néznek ki, mintha csak egy választható lehetőség lennének.

1992 körül ezek a felületek kezdtek eltűnni és megjelentek helyettük a fülekkel ellátott dialógusablakok:

kep14

Ez a dialógusablak remek példája a mintának. Erről a képről egyértelmű, hogy van hat tabfüled, egyértelmű, hogy most épp melyiket is látod és az is, hogy hogyan tudsz a többire váltani. Amikor a Microsoft először elkezdte vizsgálni a fülekkel ellátott dialógusablakokat, a használhatóság a régi Mac-es 30%-ról 100%-ra nőtt. Ez azt jelenti, hogy minden egyes tesztelő ki tudta találni, hogy működik. Az eszköz nagy sikerét és a tényt látva, hogy a Windowsba beépítve gyakorlatilag ingyen elérhető lett minden fejlesztő számára szinte csoda, hogy még mindig látni olyan alkalmazásokat, amik nem használják ki. Ezek a programok azóta is használhatósági problémáktól szenvednek.

Következetesség és egyéb koboldok

A Microsoft Office fő programjai, mint a Word és az Excel a semmiből születtek a Microsoftnál, másokat meg külső cégektől vettek meg (ilyen például a FrontPage a Vermeertől vagy a Visio a Visiotól). Mi ezekben a közös? Hogy eredetileg is úgy tervezték őket, mintha Microsoft Office alkalmazások lennének.

A döntés, hogy vetélkedjenek az Office felületével nemcsak egy fricska volt a Microsoftnak, de az is lehet, hogy direkt így akarták felajánlani a céget neki, bár kétségtelen, hogy Charles Ferguson, aki a FrontPage-et fejlesztette, nem habozott bevallani a Microsofttal szembeni ellenszenvét; folyamatosan könyörgött a bíróságnak, hogy tegyenek valamit a redmondi sakálokkal (egészen addig, míg el nem adta a cégét nekik. Azután a helyzete egy kicsit bonyolultabb lett). Vermeer és a Visio viszont úgy tűnik főleg azért másolta le az Office felületét, mert célszerűnek látták: egyszerűbb és gyorsabb volt, mint újra feltalálni a kereket.

Amikor Mike Mathieu csoportvezető a Microsoftnál letöltötte a FrontPage-et Vermeer honlapjáról és kipróbálta, az pont úgy működött mint egy Word. Mivel a program pont úgy működött, ahogy várta, sokkal könnyebb volt használni. A könnyű kezelhetőség pedig azonnal kedvező benyomást gyakorolt rá.

Így az MS ebből a kedvező benyomásból kiindulva képes volt nagyjából 150 millió dollárt fizetni. Persze a te célod talán valamivel szerényebb, a te vásárlóid a kedvező benyomásért lehet, hogy csak 39 dollárt adnak, de a lényeg ugyanaz: a következetesség könnyű használhatóságot eredményez, ami jó benyomást kelt és több pénzt jelent.

Persze nehéz megmondani, hogy milyen mértékű következetességre van szükségük az embereknek ahhoz, hogy könnyen megtanuljanak egy programot és az széles körben elterjedjen. A grafikus felületek elterjedése előtt minden programnak újra fel kellett találni a felhasználói felülettel kapcsolatos legalapvetőbb dolgokat is. Még egy egyszerű kilépés műveletnek is - amit pedig minden program tartalmaz - teljesen különböző megvalósításai léteztek. Akkoriban az emberek elvi kérdést csináltak abból, hogy mindent megjegyezzenek (vagy legalább a kilépés parancsát). Futtatni tudták az összes programot, aminek megtanulták a használatát. Az Emacs fanatikusai, ha egyszer véletlenül összeakadtak a vi-al bemagolták, hogy ":q!" (vagy valami hasonló), a vi használói meg megjegyezték a "C-x C-c" kombinációt (az Emacs egészen sajátos módon használta a vezérlőkaraktereket). A DOS világban még a WordPerfect-et sem tudtad használni, hacsak nem volt nálad az a jellegzetes műanyag billentyűkiosztás-minta, ami eszedbe juttatta, hogy mit csinál az Alt+Ctrl+F3. Én az F7-et tudtam fejből, ami kilépett az egészből.

De nemcsak ez jelent problémát, hanem az apró következetlenségek is: például a felülírás és a beszúrás kombinációja is nagy bosszúságot tud okozni. Annyira sokszor használtam, hogy megjegyeztem: a Ctrl+Z a Windowsban a visszavonás művelete, viszont amikor Emacs-et használtam, állandóan lekicsinyítettem vele az ablakot, mert ott meg azt jelenti. (Vicces, hogy az Emacs pont azért használja a Ctrl+Z-t az ablak kicsinyítésére, hogy konzisztens maradjon a csh-val, a Unix-ok c shelljével). És ez csak egy azok közül a nagyobb bosszúságok közül, amik jelentősen hozzátesznek az elégedetlenség érzéséhez.

Hadd hozzak egy kisebb példát is: a Pico és az Emacs is a Ctrl+K-t használja a sorok törléséhez, de van egy apró különbség, ami széttöri a szerkesztett dokumentumot Pico-ban. Biztos vagyok benne, hogy neked is számtalan ilyen példád van.

A Macintosh régi napjaiban, amikor még nem volt Microsoft Windows, az Apple hittérítői azt mondták mindenkinek, hogy egy átlagos Mac használó több különféle programot használ, hogy a munkáját elvégezze, mint egy átlagos DOS használó. Nem emlékszem pontosan a számokra, de valami olyasmi rémlik, hogy 1 vagy 2 volt a DOS program száma és 12 a Mac program száma. És ennek az volt az oka, hogy sokkal könnyebb volt megtanulni egy új programot a Mac-en, mert mindegyik hasonlóképpen működött.

A következetesség egy alapvető szabálya a jó UI tervezésnek, de ez is csak egy továbbgondolása a "program modell legyen ugyanaz, mint a felhasználói modell" alapelvnek, mert a felhasználó alapvetően úgy gondolja, hogy a programok hasonlóképpen működnek. Ha már megtanulta, hogy a dupla kattintás egy szövegen azt jelenti, hogy egy szót kijelölök, akkor ha mutatsz neki egy olyan programot, amit még sosem látott, azt fogja gondolni, hogy abban is azt jelenti. És ha a kettős kattra a program nem ezt vagy nem csak ezt fogja csinálni (például elkezdi keresni a szót a szótárban), az egy használhatósági problémát jelent.

De ha a következetesség annyira egyértelműen hasznos, akkor miért pazarolom az időmet (és a tiedet) arra, hogy ennyit beszéljek az előnyeiről? Sajnos egyrészt az erő sötét oldala a következetesség ellen harcol másrészt a programozók és a tervezők alapvetően szeretnek kreatívok lenni.

Én lennék az utolsó, aki azt mondja, hogy ne legyél kreatív, de sajnos a felhasználói felületek egyszerűre való tervezése azt jelenti, hogy a kreativitásodat valami más területen kell kamatoztatnod. A legtöbb UI-hez kapcsolódó döntésben ahelyett, hogy mindent a nulláról találsz ki inkább nézd meg, hogy más programok mit hogyan csinálnak és próbáld meg azt leutánozni olyan pontosan, amennyire csak lehetséges. Ha egy dokumentum-szerkesztő programot vagy valami hasonlót csinálsz, akkor legjobb, ha megnézed például a Microsoft Word-öt és lemásolod ugyanazokat a billentyűkombinációkat ami közös a te programoddal. A használóid közül néhány Ctrl+S-t fog használni a mentéshez, néhányuk Alt+F,S-t, mások Alt, F, S-t (nem tartva nyomva az Alt-ot). Egy másik csoport felhasználó a floppy ikont fogja keresni az eszközsávon és arra kattint. Különben mind a négy lenne a legjobb, mert egyébként egyes felhasználók valami olyan dolgot fognak kapni, amit nem szeretnének.

Láttam olyan cégeket is, amiknek a vezetősége büszke volt arra, hogy mindent direkt máshogy csinált, mint a Microsoft. "Csak mert a Microsoft csinálja, még nem biztos, hogy az a jó" - hencegtek vele és aztán nekiálltak egy olyan felületet létrehozni, ami teljesen más volt mint az, amit az emberek már ismertek. Mielőtt te is elkezded felmondani a "csak mert a Microsoft csinálja, még nem biztos, hogy az a jó" mantrát, vegyél figyelembe két dolgot:

Ahhoz, hogy olyan programot csinálj, aminek jó a felhasználói felülete, a vallásodat az ajtón kívül kell hagynod. A Microsoft persze talán nem az egyetlen cég, akiktől másolni lehet. Ha például netes könyváruházat csinálsz akkor jó, ha az oldal legalábbis szemantikailag azonos az Amazonnal. Az Amazon a bevásárlókosarad tartalmát kb. 90 napig megtartja. Te gondolhatod azt, hogy baromira okos vagy és kiürítheted a kosár tartalmát minden 24 órában. Amikor ezt teszed, egészen biztosan lesz legalább egy Amazonról jött vásárlód, aki betesz a bevásárló kosarába valamit, aztán két hét múlva visszajön azt feltételezve, hogy az még mindig benne van. Amikor látja, hogy már nincs, vesztettél egy vásárlót.

Amikor csúcskategóriájú képszerkesztőt csinálsz profiknak, biztos lehetsz benne, hogy a felhasználók 90%-a már ismerni fogja az Adobe Photoshop-ot, úgyhogy legjobb, ha a funkcionalitás átfedő részében a te programod is úgy viselkedik majd, mint a Photoshop. Ha nem így teszel, akkor az emberek azt fogják mondani, hogy a programodat nehéz használni (akkor is, ha te azt gondolod, valójában könnyebb) mert az nem úgy viselkedik, ahogy elvárták.

Van egy másik népszerű irányzat is: újrafeltalálni azokat a kontrolokat, amik a Windowsal jönnek. Még csak nem is kell a Netscape 6-ra gondolni. Volt idő, amikor egy programról első ránézésre meg lehetett állapítani, ha a Borland C++ fordítójával csinálták, mert nagy kövér OK gombokat használtak óriási zöld pipával. De még ez sem volt olyan gáz, mint a Kai's Photo Soap:

kep15

Persze jól néz ki, de az áthúzott O (ami tulajdonképpen a Nem-et jelenti) engem pont az OK-ra emlékeztet, ráadásul a Windowsban az OK gomb általában a bal oldalon van, úgyhogy sikerült magam felbosszantani rajta, hogy folyamatosan a rossz gombot nyomtam meg. Az egyetlen előnye, hogy a mindenki más által használt OK és Mégsem gombok helyett vicces ikonokat használsz, hogy megmutathatod, milyen kreatív vagy. Ha az emberek hibákat vétenek a Kai kreativitása miatt, nos ez az ára annak, ha az ember egy művészre bízza magát. (Van egy másik probléma is ezzel a dialógusablakkal, mégpedig az, hogy nincs hagyományos címsora, amivel az ablakot mozgatni lehetne a képernyőn. Úgyhogy ha az ablak valami olyat takar el, amit látni szeretnél ahhoz, hogy meg tudd válaszolni a kérdését akkor nincs szerencséd.)

Sokat lehet tenni azért, hogy legyen egy letisztult, jól kinéző felhasználói felületed. A Kai-hoz hasonló szép arculat magára irányítja a figyelmet. A trükk az, hogy ezt úgy tegyük meg, hogy közben ne szegjük meg a szabályokat. Megváltoztathatod egy kicsit a dialógusablakok kinézetét, de a funkcionalitásukat nem.

Amikor a Juno első verzióját kiadták, volt egy normál bejelentkező képernyője, amin meg lehetett adni a felhasználói nevet és a jelszót. Miután megadtad a nevet, a Tab leütésével mehettél a jelszó mezőre.

Volt Junonál egy őrült projekt manager, akinek sokkal nagyobb tapasztalata volt a Unixok használatában, mint a Windowséban, és amikor ő a felhasználói nevét beírta, az Enterrel szeretett volna a jelszó mezőre népni (a Tab helyett). Persze amikor kezdő Windows felhasználóknak írsz programot, egy Unix programozó talán nem a legjobb mintája egy leendő felhasználónak, de ez a manager kitartóan ragaszkodott ahhoz, hogy az enternek a következő mezőre kell váltania, nem pedig az OK gombot aktiválni. "Csak mert a Microsoft így csinálja, nem biztos, hogy ez a jó" - hajtogatta.

Így aztán a programozók egy csomó időt töltöttek vele, hogy írjanak egy bámulatosan bonyolult dialógusablakot, ami megkerüli a Windows alapértelmezett működését. (Következetlennek lenni majdnem mindig több munkát jelent, mint megfelelni a célplatform alapértelmezett működésének.) Ennek az új ablaknak a kódja elég zavaros volt, nem sikerült jól portolni, amikor 16-ról 32 bites Windowsra álltak át. Nem azt csinálta, amit az emberek vártak. És amikor a projekthez új programozók csatlakoztak, nem értették, hogy minek van külön alosztály a dialógusablakokhoz.

Egyébként már nagyon sok programozó próbált újraírni számos általános Windows kontrolt a gomboktól a gördítősávokon keresztül a menükig (az MS Office csapat kedvenc időtöltése volt ezek újraimplementálása). A Netscape 6.0 egészen addig ment, hogy minden egyes Windows kontrolt újraírt! Ez persze számos előre nem látható hibát produkált. A legjobb példa erre a szerkesztőmező. Amikor újraimplementálod a szerkesztőmezőt vannak olyan dolgok, amelyekről fogalmad sincs, hogy hozzá tartoznak (például a Kínai nyelv támogatása vagy a Windows kétirányú változatai, amelyek a jobbról balra való gépelést támogatják). Ezek a dolgok egyszercsak nem fognak működni, mert nem tudják kezelni az újraírt szerkesztőmezőt. Néhány tesztelő, aki látta a Netscape 6.0 kiadásra jelölt verzióját, meg is jegyezte, hogy az URL mező - ami szintén a Netscape saját komponensét használta - nem támogatja a szokványos szerkesztési funkciókat, mint például a jobb egérgombos helyi menüt.

Amikor anti-Microsoft fundamentalistákkal vagy egy kreatív grafikus tervezővel vitatkozol, hajlamosak Emersont helytelenül idézni: "A következetesség az ész gonosz koboldja." A valódi idézet: "Az őrült következetesség az ész gonosz koboldja." A jó UI tervezők a következetességet intelligens módon alkalmazzák és bár ez talán nem mutatja meg olyan jól kreativitásukat, hosszú távon mégis megelégedettebbé teszi a felhasználókat.

Tervezni olyanoknak, akik jobban boldogulnak az élet más területein

Amikor felhasználói felületet tervezel jó, ha két dolgot észben tartasz:

Ezek persze az igazat megvallva nem mindig igaz tények de jobb, ha úgy tekintesz rájuk mintha azok lennének, mert egyszerűbbé és barátságosabbá teszik a programjaidat. Ezeket észben tartva fejleszteni azt jelenti, hogy tiszteled a felhasználót, ezt pedig úgy érjük el, hogy nem mutatunk sok tiszteletet a felhasználó felé. Összezavarodtál? Hadd magyarázzam meg.

Mit jelent az, ha valamit egyszerű használhatóságra terveznek? Egy jó példa ennek mérésére, hogy megvizsgálod, az átlagos felhasználók mennyi idő alatt tudnak elvégezni egy bizonyos feladatot. Vegyük például, hogy a programod digitális fényképezőgépek képeit konvertálja webes fotóalbummá. Ha összehívsz egy csapat átlagos felhasználót és megkéred őket, hogy végezzék el vele ezt a feladatot, akkor annál használhatóbb a programod, minél több felhasználó képes vele sikeresen fotóalbumot készíteni. Legyünk tudományosak: képzelj el 1000 embert. Még az sem szükséges, hogy jártasak legyenek a számítógépek kezelésében. Lehet köztük mindenféle tehetség, de nyilvánvaló, hogy sokuknak nem lesz tehetsége a számítógépek kezeléséhez. Néhányuk zavart lesz, amikor megpróbálják használni a programodat: csöng a telefon... Mi? Sír a gyerek... Mi? Aztán a macsaka felugrik az asztalra, elkezd az egérrel játszani. Mit is mondtál?...

Én ilyen élmények nélkül is ki merem jelenteni, hogy néhány ember nem fogja tudni megcsinálni a feladatot vagy túl sok időre lesz hozzá szüksége. De nem állítanám, hogy ezek az emberek hülyék. Sőt ellenkezőleg, ők talán intelligensek vagy tökéletes sportolók, de sajnos egyszerűen képtelenek tehetségüket és agysejtjeiket a te programod használatának szolgálatába állítani. Vagy a figyelmüknek csak 30%-át tudtad megszerezni így be kell érned egy olyan felhasználóval, aki - legalábbis a gép szemszögéből nézve - buta.

A felhasználók nem olvassák el a használati útmutatót.

Először is: tulajdonképpen nincs is meg nekik a használati útmutató. Talán nem is létezik használati útmutató. Vagy ha létezik is, nincs meg egészen praktikus okokból: épp repülőgépen ülnek; csak egy, a honlapodról letöltött demó verziót használnak; vagy esetleg épp otthon vannak, az útmutató meg a munkahelyen; vagy esetleg a rendszergazda oda sem adta nekik az útmutatót. De még ha meg is van nekik, akkor is biztos lehetsz benne, hogy nem fogják elolvasni, hacsak már egyáltalán nincs más lehetőségük. Nagyon kevés kivétellel az emberek nem kezdik el átnyálazni a dokumentációt, mielőtt elkezdenének használni egy programot. Az emberek általában elkezdenek valami feladatot megoldani és a doksi olvasását egyszerűen időpocséklásnak tekintik vagy jobb esetben korlátozó tényezőnek, ami akadályozza őket a megfelelő munkavégzésben.

Már az a tény is, hogy elolvasod ezt a cikket, a rendkívül olvasott, művelt emberek elit csoportjába helyez téged. [Arról már nem is beszélve, aki lefordította... - A ford.] Persze tudom, hogy azok akik számítógépeket használnak nagyjából tudnak olvasni, de garantálom neked, hogy nagy százalékuk az olvasást szenvedésnek tartja. A nyelvezet pedig, amelyen az útmutató íródott ráadásul még eléggé nehézkes is, úgyhogy csak akadozva tudják olvasni. Mintha gyerekek lennének! Talán kibogarásszák az útmutatót ha valóban szükséges de egészen biztos, hogy kényszer nélkül nem olvassák el. A felhasználók csak szigorú, muszáj, hogy kell alapon olvasnak útmutatót és csak akkor, ha már nincs más lehetőség.

Ennek pedig az az eredménye, hogy nincs más választásod, mint úgy megtervezni a programodat, hogy a lehető legkevesebb olvasásra legyen szükség a használatához. Az egyetlen kivétel, ha a leendő felhasználóknak semmi előismeretük nincs a dologról, ha tényleg semmi fogalmuk nincs, hogy mit kellene a programnak csinálnia, de úgy gondolják, hogy meg kell tanulniuk. Ennek egy remek példája az Intuit roppantul népszerű kisvállalkozásoknak szánt könyvelőprogramja, a QuickBooks. Ennek rengeteg felhasználója olyan ember, akinek kisvállalkozása van de fogalma sincs róla, hogy mi fán terem a könyvelés. A QuickBook útmutatója feltételezi ezt és feltételezi, hogy neki kell megtanítani az embereket a könyvelés alapelveire. Nincs más lehetősége. Viszont ha már tudsz könyvelni, akkor a QuickBooks használata remekül fog menni az útmutató elolvasása nélkül is.

Valójában a felhasználók semmit nem olvasnak el.

Ez kicsit durvának tűnik, de amikor használhatósági teszteket csinálsz látni fogod, mennyire így van: vannak emberek, akik egyszerűen nem olvassák el a szavakat, amiket kiírsz nekik a képernyőre. Ha feldobsz nekik valami hibaüzenetet vagy hasonlót, egyszerűen nem fogják elolvasni. Programozóként ez talán zavarba ejtő lehet számodra, mert úgy képzeled, hogy a dialógusablakokon keresztül kommunikálsz a felhasználóval. Hé, felhasználó! Nem tudod megnyitni azt a fájlt, mert nem támogatjuk ezt a formátumot! A tapasztalat azt mutatja, hogy minél több szót pakolsz ki egy ablakba, annál kevesebb ember lesz, aki azt elolvassa.

A tény, hogy ez emberek nem olvasnak használati útmutatót vezetett el ahhoz a következetetéshez, hogy akkor talán oktassuk ki őket a folyamatok közben. Ezt nagyon sok programban tapasztalhatod. Elvben ez rendben is lenne, de a valóságban az emberek olvasástól való idegenkedése miatt ez a módszer megintcsak bajos. A gyakorlott UI tervezők a lehető legkevesebb szót használják a dialógusablakokba kerülő szövegekben, hogy növeljék az esélyét annak, azt valóban el is olvassák. Amikor a Junon dolgoztam, a felület programozói megértették ezt és megpróbáltak rövid, egyszerű, világos üzeneteket írni. Sajnos a cég vezetője angol szakra járt az Ivy Szövetségi főiskolán és még csak elképzelése sem volt az UI tervezésről vagy a szoftvermérnökségről, ellenben úgy gondolta, hogy nagyon jó prózai tehetsége van. Így hát elkezdett tiltakozni a profi UI tervezők által kitalált szövek ellen és lecserélte azokat saját szóáradatára. A Junoban egy tipikus dialógusablak így nézett ki:

kep16

Na most hasonlítsd ezt össze a Windowséval:

kep17

Persze azt hihetné az ember, hogy a 80 szavas Juno útmutató "fejlettebb" (vagyis könnyebb használni), mint a Windows 5 szavas verziója. Valójában amikor használhatósági teszteket végzel velük, kiderül, hogy

Így hát a Juno értelmetlenül túlkontrollált lett. Sőt, ha te angol szakra jártál a Columbia egyetemen, akkor biztos lehetsz benne, hogy teljesen más nyelvet beszélsz, mint az átlag Joe és nagyon óvatosnak kell lenned a dialógusablakok segítő szándékú megszövegezésében. Rövidítsd le, egyszerűsítsd le, szabadulj meg a bonyolult összetett mondatoktól és csinálj használhatósági tesztet. És ne használj olyan kifejezéseket, amiket az egyetemi nyelvtani kurzusokon hallottál. Még egy "kérem" szó hozzáadása is, ami talán segítőkésznek és előzékenynek tűnik lelassítja az embert, a szavak halmozása pedig jól mérhető mértékben csökkenteni kezdi azok számát, akik valóban elolvassák a szöveget.

A másik lényeges dolog, hogy sokakat megfélemlítenek a számítógépek. Ezzel te is tisztában vagy, nem? De valószínűleg nem fogtad még fel ennek a következményeit. Megfigyeltem egyik barátomat, aki ki akart lépni a Junoból. Bizonyos okokból apróbb problémái akadtak. Észrevettem, hogy amikor ki akar lépni belőle, a következő ablak jelent meg (Köszönjük, hogy a Juno-t használta. Valóban ki szerete lépni?):

kep18

A Nem-re kattintott, aztán meglepődött, hogy a program nem lépett ki. A tényből, hogy a Juno megkérdezte valóban ki akar-e lépni, azt gondolta, valamit rosszul csinált. Általában amikor egy program arra kér, hogy erősíts meg egy döntést az azért van, mert valami olyasmit akarsz tenni, amit jobb, ha még egyszer átgondolsz. Ő feltételezte, hogy ha a gép megerősítő kérdést tesz fel, akkor biztosan igaza van, mert hát a számítógépek gépek ő meg csak egyszerű ember, így hát gyorsan a "Nem"-re kattintott.

Túl nagy kérés az emberektől, hogy elolvassanak 11 nyamvadt szót? Nos úgy tűnik az. Először is mivel a Junoból való kilépésnél nincs törlendő dolog, mindenféle kérdezés nélkül ki kellett volna hogy lépjen, mint bármilyen másik rendes program. De még ha meggyőződésed is, hogy fontos, hogy az embereket kilépés előtt megkérdezzük, akkor is meg tudod azt tenni 11 helyett mindössze két szóval (Kilép?):

kep19

A teljesen szükségtelen elköszönő üzenet és a bűntudatot ébresztő "biztos ebben?" szöveg nélkül ez a dialógusablak sokkal kevesebb problémát okoz. Az emberek biztosan elolvassák azt a két szót, aztán az igenre kattintanak.

Mondhatnád, hogy ha a Juno kilépési üzenete gondot okoz egy-két embernek, ez olyan nagy ügy? A végén úgyis mindenki rájön, hogy kell kilépni. Ez igaz, csak gondolj a különbségre két program között, az egyiket lehetséges használni, a másikat meg könnyű használni. Te melyiket választanád? Még az ügyes, tapasztalt, haladó felhasználók is méltányolni fogják azokat a megoldásokat, amelyekkel a zavart, járatlan, kezdő felhasználók életét akarod megkönnyíteni. A hotelben lévő fürdőkádaknak nagy fogódzkodói vannak. Ezek kifejezetten a mozgássérült emberek számára vannak ott, de mindenki használhatja őket a kádból való kikelésnél. Könnyebbé teszik az életet.

A következő fejezetben az egérről fogok egy kicsit beszélni. Mint ahogyan egyes emberek nem akarnak vagy nem tudnak olvasni, másoknak az egér használata okoz problémát, úgyhogy rájuk is gondolni kell.

Tervezni olyanoknak, akik jobban boldogulnak az élet más területein 2

Amikor a Macintosh még új volt, Bruce "Tog" Tognazzininak volt egy rovata az Apple fejlesztők magazinjában az UI-ról. Az emberek felvetettek számos érdekes felülettel kapcsolatos problémát, amit ő megvitatott. Ez a rovat még ma is megvan a honlapján. Aztán könyvet is írt, például a szórakoztató hangvételű Tog on Software Design-t, ami nagyszerű bevezetés a grafikus felületek tervezésébe. (A Tog on Interface még jobb, de az már nem kapható.)

Tog találta ki a kilométeres menüsor koncepcióját, hogy bemutassa miért van a Macintoshon a menü a képernyő tetején, ami sokkal könnyebben használható, mint a Windows megoldása, ahol a menüsor a programok ablakában van. Amikor a Fájl menüt akarod megnyitni a Windowsban akkor egy centi széles, jó fél centi magas négyzetet kell eltalálni. Mind vízszintesen, mind függőlegesen elég pontos pozicionálásra van szükség.

Macintoshon viszont elég a képernyő tetejére navigálni, nem kell függőlegesen is olyan pontosan pozicionálni, hiszen a képernyő tetején úgyis megáll az egér. Van egy szintén egy centi széles, viszont egy kilométer magas célpont. Innentől kezdve csak a vízszintes pozícionálásra kell ügyelni, a helyzet egyszerűsödik.

Ennek alapján Tog feltett egy találós kérdést: melyik az öt legkönnyebben elérhető pont a képernyőn? A válasz: a négy sarok (ahová egyszerűen oda tudod nyomni az egeret mindenféle pozicionálás nélkül) valamint az a pozíció, ahol az egér jeleneg is elhelyezkedik.

Ez a kilométeres menüsor elmélet már elég ismert volt, de úgy tűnik mégsem volt teljesen kézenfekvő, mert a Windows 95 csapata teljesen figyelmen kívül hagyta a Start gomb esetén. Ez ugyanis a bal alsó sarokban van, de nem teljesen! Valójában 2-2 képpont távolságra van az alsó és a bal oldali határtól is! Néhány képpont kedvéért a Microsoft a versenyben "a biztos pozícióból vesztett". Mint Tog leírta, ez sokkal nehezebbé teszi a Start gomb eltalálását, pedig kihasználhatták volna a mérföldes menü elméletét. Valami rejtélyes oknál fogva nem tették. Ettől kezdve bízzuk magunkat Istenre.

Az előző fejezetben arról írtam, hogy a felhasználók utálnak olvasni és mindenáron el akarják kerülni az olvasást. Hasonlóképpen:

A felhasználók nem tudják túl jól használni az egeret.

Persze ez nem azt jelenti, hogy egyáltalán nem tudják használni. Csak annyit akarok vele mondani, hogy ajánlatos úgy tervezni a programodat, hogy ne legyen szükség túl nagy pontosságú egérmozgatásra a kezeléshez. Ennek a 6 leglényegesebb oka:

A régi szép időkben, amikor az Excelen dolgoztam, a laptopoknak még nem volt beépített mutatóeszközük, így a Microsoft csinált egy hanyattegeret, amit a billentyűzet szélére lehetett csíptetni. Egy hagyományos egeret az ujjakal és a csuklóval lehet mozgatni. Ez hasonlatos az íráshoz és általános iskolában elég jó készséget alakítanak ki erre a tevékenységre. De egy hanyattegeret csak az ujjakkal lehet irányítani. Így aztán sokkal nehezebb pontosan navigálni vele, mint egy egérrel. A legtöbb ember egy egérrel 1-2 képpont pontossággal tud navigálni. Ugyanez hanyattegérnél 3-4 képpont. Az Excel csapatban állandóan azt szajkóztam az embereknek, hogy próbálják ki az újonnan kitalált felületüket hanyattegérrel is, így megtapasztalhatják azt az érzést, amit az érez, aki az egérrel sem tud pontosan dolgozni.

A legördülő menü különösen sok gondot okozott nekem. Valahogy így néz ki:

kep20

Amikor a nyílra kattintasz, akkor lenyílik:

kep21

Na most gondolkodj el azon, hány kattintásra van szükség, hogy kiválassz egy lehetőséget, mondjuk a Times New Roman-t. Először is a nyílra kell kattintani. Aztán a görgetősávot használva óvatosan le kell navigálnod a Times New Roman-ig. Ezeket a menüket gyakran úgy tervezik, hogy csak egy-két lehetőséget mutassanak egy időben, így ez a görgetés nem túl egyszerű művelet, különösen ha sok karakterkészleted van. Óvatosan meg kell ragadni a csúszkát (ami olyan apró mozgást igényel, ami valószínűleg sokaknak nem megy), vagy pedig folyamatosan kattintgatni kell az alsó nyílra esetleg a csúszka és a nyíl közötti üres sávra, ami - ha a csúszka már túlságosan leért - nem működik tovább és ez még idegesítőbb lehet. Ha pedig eltéveszted, kezdheted előlről. Na most ezt szorozd be mondjuk tízzel, ha a leveled minden bekezdését valami különleges karakterrel szeretnéd kezdeni és meglátod, hogy mennyire ideges leszel tőle.

Ez a vacak legördülő menü azért is ennyire bosszantó, mert lenne egy egyszerű megoldás: csak olyan nagyra kellene méretezni a legördülő részt, hogy tartalmazzon minden elérhető opciót. A menüknek a 90%-a nem használja ki még az egyébként rendelkezésre álló területet sem, ami bűn. Ha nincs elég hely a szerkesztőmező és a képernyő alja között, akkor is addig kellene a menünek nőnie, amíg minden elem látható nem lesz, még ha így a képernyő felső részétől az alsó részéig terjedne is. És ebben az esetben, ha még mindig nem fér ki minden elem, akkor a görgetésnek úgy kellene működnie, ha az egérrel teljesen lentre vagy teljesen fentre navigálunk, nem pedig az icipici csúszkát kellene elkapni.

Ja, és ne várd el tőlem, hogy a szerkesztőmező jobb oldalán lévő pici nyílra kattintsak. Nyíljon le a menü akkor, ha bárhová a szerkesztőmezőbe kattintok. Ez sokszorosára növelné a klikkelhető területet és sokkal könnyebb lenne eltalálni az egérkurzorral.

Az egérhasználat további problémája: a szerkesztődobozok. Talán már feltűnt, hogy Macintoshon majdnem minden szerkesztődoboz a Chicago-nak nevezett kövér, széles betűtípust használja, ami elég csúnyának tűnik és meglepő, hogy hogyan adhattak ki a kezükből a grafikusok ilyet. A grafikusok (csakúgy, mint a felhasználói felület tervezői) vékony, változó szélességű karakterkészletekben gondolkodnak, amelyek sokkal jobban néznek ki és könnyebb őket elolvasni. Ez így is van. Csakhogy a grafikusok a képességeiket papíron, nem pedig képernyőn sajátították el. Amikor a szöveg szerkesztésére van szükség, az azonos szélességű karaktereknek van egy nagy előnye a változó szélességűekkel szemben: könnyebb észrevenni és kijelölni a keskeny betűket, mint amilyen például az "l" vagy az "i". Ezt akkor értettem meg igazán, amikor egy 60 éves embert láttam, aki épp azon küzdött, hogy a lakóhelyének utcáját szerkessze. Az utca a Fillmore Street volt. Mi 8 pontos Arial karaktereket használtunk, úgyhogy a szerkesztőmező valahogy így nézett ki:

kep22

Jól látszik, hogy az I és az L betűk tulajdonképpen egy képpont szélesek. A különbség a kisbetűs I és a kisbetűs L között épp egy képpont. (Az RN és az M közötti különbséget kisbetűk között szintén nehéz észrevenni, úgyhogy a szerkesztőmező akár mondjuk Fillrnore-t is tartalmazhatott volna.)

Nagyon kevés az olyan ember, aki észrevette volna, hogy ezt a címet elírja mondjuk Flilmore-ra vagy Fiilmore-ra vagy akár Fillrnore-ra és még ha észre is veszi, igencsak nehézkesen tudná használni az egeret ahhoz, hogy kijelölje a hibás karaktert a javításhoz. Ja, és egészen bizonyosan sokat küszködne a két képpont széles villogó kurzorral is. El lehet képzelni, hogy mennyivel könnyebb lenne az egész, ha félkövér karakterkészletet használnának (ugyanez Courier Bold karakterkészlettel):

kep23

Persze, én is tudom, hogy ez több helyet foglal és nem néz ki olyan jól a grafikusaid szemében. De ne foglalkozz vele! Sokkal könnyebb használni és nagyobb megelégedettséget ad gépelés közben, mert tiszta, éles, érthető és sokkal könnyebb szerkeszteni.

elvalaszto

A programozók fejében általában a következő dolog be van égetve: csak három szám létezik: 0, 1 és n. Ha az n lehetséges, akkor az összes n "nagyjából ugyanolyan". Ez a gondolat abból a (valószínűleg igaz) hiedelemből származik, hogy a kódban a 0-n és 1-en kívül ajánlatos minden más konstanst kerülni. (Az ezeken kívüli számok mágikus számok. Most nem akarok belemenni ennek a tárgyalásába.)

A programozók hajlamosak azt feltételezni, hogy ha a programodban meg lehet nyitni több dokumentumot, akkor valójában végtelen számú dokumentumot meg lehet nyitni (nyilván a memória korlátain belül), vagy legalábbis 232 dokumentumot, ami az egyetlen olyan mágikus szám, amit a programozók elfogadnak. Hajlamosak lenézni az olyan programot, ami például csak 20 dokumentumot képes egyszerre megnyitni. Miért pont 20? Ez még nem is 2-nek a hatványa!

Az összes n nagyjából ugyanolyan tulajdonságából levezethető másik következmény, hogy a programozók haljamosak azt gondolni, ha a felhasználónak engedélyezett az ablakok mozgatása és átméretezése, akkor teljes méretű szabadságot kell nekik ebben adni, akár az utolsó képpontig. Hogy az ablakot a képernyő tetejéről 2 képpontal lejjebb pozicionáljuk vagy pont a képernyő tetejére, az "nagyjából ugyanolyan".

De ez nem így van. Amint kiderült, elég sok oka van annak, ha az ember az ablakot épp a képernyő tetejére szeretné pozicionálni (maximalizálja a képernyő hasznos területét), de nem sok oka van annak, hogy a képernyő tetejétől 2 képponttal lejjebb tegye a többi ablak fölé. Úgyhogy a 0 sokkal valószínűbb, mint a 2.

A Nullsoftnál a WinAmp programozói valahogyan elkerülték a szokásos programozói gondolkodást, ami bennünket már egy évtizede mérgezett. A WinAmpnak van egy remek tulajdonsága. Amikor az ablakot a képernyő valamelyik széle közelébe húzod, akkor automatikusan odarántódik pont a képernyő széléhez. És ez pont az, amit akarsz, mert a 0 sokkal valószínűbb, mint a 2. (Különben a Juno főablakának is van egy hasonló tulajdonsága: ez az egyetlen program, amit eddig láttam, ami "be van zárva" a képernyőre, vagyis nem lehet a képernyő területén kívülre mozgatni.)

Ezekkel a megoldásokkal ugyan elvesztünk egy kis rugalmasságot, de cserébe kapunk egy olyan felületet, ami tudomásul veszi, hogy az egér pontos használata nem egyszerű. Ez a fejlesztés (amit minden program kihasználhatna) az ablakok kezelésének problémáit intelligens módon próbálja megoldani. Vizsgáld meg közelről a saját felhasználói felületedet és add meg nekünk ezt a kényelmet. Gondolj ránk úgy, mint ügyetlen gorillákra vagy legalábbis okos orángutánokra, akik bajban vannak az egérrel.

Tervezni olyanoknak, akik jobban boldogulnak az élet más területein 3

A grafikus felhasználói felületek egyik korai alapelve az volt, hogy nem kell az embereket olyan dolgok megjegyzésére kényszeríteni, amit a gép is meg tud jegyezni helyettük. Ennek klasszikus példája a Fájl Megnyitása dialógusablak, ami tartalmazza a fájlok listáját és nem az emberektől várja el, hogy mindig megadják a fájl pontos nevét. Sokkal jobban emlékszünk olyan dolgokra, amik valamihez kapcsolódnak és sokkal inkább szeretünk egy listából választani, mint hogy mindig mindent pontosan fejből kelljen megadni.

Egy másik példa maga a menü. Azért találták ki a menüt, hogy ne kelljen minden parancsot fejben tartani, hanem az elérhető funkciók legyenek felsorolva egy helyen. És pont emiatt nem jobbak a parancssori felületek a GUI-nál, mondjon neked bármit is Linux-fanatikus barátod. A parancssori felület olyan, mintha meg kellene tanulni Koreaiul ahhoz, hogy a McDonalds Szöuli éttermében BigMac-et rendelj. Menüs felületet használni olyan, mintha rá tudnál mutatni arra a kajára, amit szeretnél és ne kelljen elgondolkodni azon, hogy hogy is van a paprikás krumpli malájul. Ugyanazt az információt tanulás nélkül is át lehet adni.

Nézd meg a fájlkiválasztás műveletét egy tipikus grafikus programban:

kep24

A Windows 98 szerencsére behozta az előnézeti képek támogatását, úgyhogy onnantól ezt már így látni:

kep25

Ez jelentősen megkönnyíti a kívánt fájl megkeresését és megnyitását, még arra sincs szükség, hogy fejben a képekhez neveket rendeljünk.

A minimális emlékezés alapelv jól megfigyelhető működés közben az automatikus kiegészítésnél is. Ha elkezdesz valamit begépelni, akkor egyes programok megbecsülik, hogy mit is akarsz írni:

kep26

Ebben a példában amint elkezded beírni, hogy "F", az Excel kitalálja, hogy valószínűleg azt írod, hogy Férfi, mert már korábban is beírtad azt abba az oszlopba és megpróbálja befejezni a szót. De az "érfi" ki van jelölve, úgyhogy ha mégsem azt akarod írni, hogy Férfi, akkor tovább gépeléssel eltűnik és bekerül az, amit oda szántál.

Viszont a Microsoft talán már kicsit túllőtt a célon ezzel a kitalálósdival a Word-nél, ahogy azt már sokan tapasztalhatták, például:

kep27

Tervezni olyan embereknek, akik jobban elboldogulnak az élet más területein
Összefoglalás

A korábbi fejezetekben három alapelvet mutattam be:

Úgy tűnhet, én azt képzelem, az emberek hülyék. Ez nem így van. A felhasználókkal szembeni tiszteletlenség legjobb példája inkább az arrogáns Microsoft Bob nevű program. [A Microsoft 1995-ös elképzelése az igazán felhasználóbarát felhasználói felületről, ami azonban már túl gyermetegre sikerült - A ford.] Ezt később persze a szemétbe is dobták mert senki nem volt vele megelégedve.

De el kell mondani, hogy létezik másféle, sokkal rosszabb arrogancia is a szoftvertervezésben: az a hozzáállás, hogy "az én szoftverem nagyon király, az embereknek csak az agyukat kell hozzáigazítani". Ez a fajta pofátlanság elég közkeletű a nyílt szoftveres világban. Hé, a Linux ingyenes! Ha nem vagy elég okos, hogy kisilabizáld, akkor nem is érdemled meg, hogy használhasd!

Az emberi hajlam azonban harang alakú görbéhez hasonló. Vásárlóid nagyjából 98%-a képes használni egy tv-készüléket. Nagyjából 70%-uk képes használni a Windowst. 15%-uk képes használni a Linuxot, 1%-uk képes programozni, de csak 0,1%-uk képes olyan nyelveken programozni, mint a C++. És csak 0,01%-uk képes megérteni a Microsoft ATL programozását [C++ nyelven írt osztálykönyvtár a Windowshoz - A ford.]. (És ők kivétel nélkül szakállasak és szemüveget viselnek.)

Ebből a görbéből az következik, hogy ha egy picit is lejjebb engeded a lécet, mondjuk 10%-al egyszerűbbre tervezed a program használatát, már akkor is drámaian, mondjuk 50%-al növelheted azon emberek számát, akik képesek használni.

Úgyhogy nem gondolom, hogy az emberek ostobák, de azt gondolom, hogy ha úgy tervezel programokat, hogy azt még hülyéknek is könnyű használni, akkor olyan programot csinálsz, amit mindenki könnyen tud használni és az emberek körében népszerű lesz. És meg leszel lepődve, hogy egy apró használhatósági fejlesztés mennyivel több vásárlót jelent.

Jó módszere egy program vagy egy még sosem látott dialógusablak használhatósági tesztjének, ha butaként kezeljük. Ne olvasd el a dialógusablakokban a szöveget. A működésről feltételezz dolgokat ellenőrzés nélkül. Próbáld meg az egeret csak egy ujjal használni. Csinálj sok hibát. Nézd meg, hogy a program azt teszi-e, amit akarsz vagy legalábbis nem száll-e el ezeknek a hatására. Legyél türelmetlen. Ha nem tudod megcsinálni azonnal amit akarsz, akkor add fel. Ha a felület nem áll ellen ennek a megközelítésnek, akkor használhatod munkára is.

Egy termék tervezésének folyamata

Bár a jó tervezés alapelveiről beszélgettünk, az alapelvek csak iránymutatást adnak arra nézve, hogy egy már létező tervet hogyan kell értékelni és továbbfejleszteni. De! Hogy a fenébe találom ki, hogy egy új felület hogy nézzen ki? Sok ember hosszú, funkcionális leírást ír az összes kigondolt funkcióról. Aztán egyenként megtervezik az arculatot és ráaggatják egy menüre (vagy egy honlapra). Amikor kész vannak, a program vagy a honlap tartalmazza az összes elgondolt funkciót, de igazából nem áll össze az egész. Ekkor aztán elgondolkodnak, hogy hogyan lehetne megcsinálni, amit elterveztek, de nincs ötletük.

Erre a problémára a Microsoft a Tevékenység Alapú Tervezést (Activity Based Planning) találta ki. (Amennyire én tudom, ezt Mike Conte találta ki az Excelen dolgozó csapatban, aki aztán megunta azt a munkát és autóversenyző lett.) Ennek a lényege az, hogy találjuk ki, a felhasználó milyen tevékenységet szeretne elvégezni és koncentráljunk arra, hogy ezt minél egyszerűbben megtehesse. Ezt legjobban egy példával lehet bemutatni.

Mondjuk eldöntötted, hogy csinálsz egy weboldalt, aminek segítségével az emberek üdvözlőkártyákat tudnak csinálni. A hagyományos, "naiv" megközelítéssel valami következő funkciólistád lesz:

Ha nem akarunk komlyabban elgondolkodni a problémán, akkor egy tipikus 1984-beli Macintosh felülethez fogunk jutni: a program egy üres kártyával indul, menüpontok lesznek a szöveg, kép beillesztésére, kártyaminta betöltésére és a kártya küldésére. A felhasználó meg leül, kikeresi a menüből amit akar, megpróbál végigmenni rajta, hogy milyen lehetőségek vannak aztán kisilabizálja, hogy hogyan lehet ezeknek az atomi műveleteknek a segítségével megcsinálni egy kártyát.

A tevékenység alapú tervezéssel viszont úgy kell elindulnunk, hogy megnézzük, a felhasználó milyen műveleteket akar elvégezni. Megkérdezed a potenciális felhasználókat és összeírod a következő három legfontosabb dolgot:

Most pedig ahelyett, hogy programozószemmel vizsgálnánk meg a dolgot (vagyis hogy milyen funkciókra van szükség, hogy elkészítsünk egy kártyát), felhasználói szemmel nézzük meg, vagyis hogy a felhasználó miket akar csinálni vele:

Ha ezt végiggondolod, sokminden eszedbe fog jutni. Egy üres kártya helyett egy ehhez hasonló menüvel is lehetne indítani:

Mit szeretnél tenni?

Ezután a felhasználók sokkal könnyebbnek fogják találni a programod használatát, nem kell egyből a menüt túrni, mivel a program tulajdonképpen végigvezeti őket egy feladat elvégzésén. (Persze van benne kockázat, hiszen ha a feladatokat nem elég körültekintően állítottad össze, akkor bizonyos felhasználók zavarba fognak jönni. Például ha valaki húsvéti üdvözlőlapot szeretne csinálni és nem találja a listában, akkor elképzelhető, hogy másfelé fog keresgélni. Úgyhogy a lehetőségeket érdemes a megcélzott piac szerint összeállítani.)

A példában kiválasztott három lehetőségben gondolkodva néhány hasznos új fukció is eszünkbe juthat. Például ha szülinapi vagy évfordulós üdvözlőkártyát szeretnének küldeni akkor jó lenne, ha jövőre ugyanezen a napon a program figyelmeztetne erre. Úgyhogy lehetne egy jelölőnégyzetet is oda tenni "emlékeztess jövőre" szöveggel. És ha egy bulimeghívóra van lehetőség visszajelezni, akkor lehetne csinálni egy olyan funkciót, ami automatikusan összegyűjti a visszajelzéseket a felhasználóktól. Ezek a funkciók mind abból a gondolatmenetből következnek, hogy a felhasználók milyen tevékenységeket fognak elvégezni, nem pedig abból, hogy a programnak milyen funkciókat kellene támogatni.

Ez a példa elég egyszerű, de egy komoly alkalmazásnak még több előnye származik a tevékenység alapú tervezésből. Hiszen akkor is van elképzelésed arról, hogy mit fognak a felhasználók csinálni, ha teljesen nulláról kezded a program tervezését. És nem is túl bonyolult a felhasználó helyébe képzelve magunkat végiggondolni, hogy mit is akarunk csinálni, hiszen akár egy kis megbeszélés is elegendő a munkatársakkal, ahol lejegyzed a lehetséges tevékenységeket, aztán eldöntöd, hogy melyekre akarsz igazán koncentrálni. De ha csak magadban gondolod végig ezeket és papíron lejegyzed az ötleteidet, már az is sokat segíthet.

A tevékenység alapú tervezés még fontosabb akkor, ha egy olyan programon dolgozol, aminek korábbi verzióját már használják. Csak meg kell figyelni néhány felhasználót, hogy mire is használják a programot.

Az Excel 1.0-tól 4.0-ig tartó időben a Microsoftnál úgy gondolták, hogy a legtöbbet használt funkció az üzleti "mi lenne, ha?"-szerű dolgok vizsgálata. Például megváltoztatják egy táblában az inflációs rátát és megnézik, hogy ez miként befolyásolja a jövedelmezőséget.

Amikor az Excel 5.0-t terveztük, az első fő kiadás során komoly tevékenység alapú tervezést végeztünk: körülbelül öt vásárlót figyeltünk meg, és kiderült, hogy az emberek csak arra használják az Excelt, hogy listákat tároljanak bennük. Egyáltalán nem írtak bele semmiféle képleteket és semmiféle számítást nem végeztek vele! Erre sosem gondoltunk korábban. A listák tárolása az Excelben sokkal népszerűbb feladat volt, mint bármi más. Ez pedig arra késztetett minket, hogy létrehozzunk egy csomó új funkciót, ami a listák kezelését egyszerűbbé teszi: könnyebb rendezést, automatikus adatmeghatározást, az AutoFilter funkciót, ami segít benne, hogy a listának csak egy részét lehessen látni és többfelhasználós funkciókat, amelyek segítenek benne, hogy egy listán egyszerre több ember is dolgozzon, miközben a háttérben az Excel mindent szépen elrendez.

Amíg az Excel 5 tervezése folyt, a Lotus megjelentette az "új paradigmán" alapuló táblázatkezelőjét, az Improvot. A sajtóban megjelent hírek alapján az Improv a táblázatkezelők teljesen új generációjának tűnt, ami mindent elavulttá tesz, ami korábban volt. Valami fura okból az Improv először a NeXT gépén jelent meg, ami persze nem segítette az elterjedését, de sokan úgy gondolták, hogy az Improv lesz az a NeXT számára, mint ami a VisiCalc volt az Apple II számára: a gyilkos alkalmazás, ami miatt az emberek megvesznek egy számítógépet, csak hogy futtathassák a programot.

Az Improv ma már csak egy lábjegyzet a történelemben. A weben keresve az egyetlen hivatkozás egy túlszervezett raktárkezelőre mutat, ami egy csomó szemetet tartalmazó raktárkészletet tartalmazó weboldal.

Miért? Mert az Improvban szinte lehetetlen volt egyszerűen csak listákat létrehozni. Az Improv tervezői úgy gondolták, hogy az emberek azért használnak táblázatkezelőket, hogy bonyolult, többdimenziós üzleti modelleket kezeljenek. Nos ha megkérdeztek volna valakit, akkor rájöttek volna, hogy a listák kezelése sokkal jobban elterjedt, mint a többdimenziós üzleti modellek készítése és ez az Improvban nagyon nehézkesen ment, sőt néha lehetetlen volt.

A tevékenység alapú tervezés tehát segít az alkalmazás első verziójának megírásakor is, amikor feltételezéseket kell tenni arról, hogy az emberek mit akarnak csinálni, de még nagyobb segítség, amikor tovább akarod fejleszteni a programot, mert segít megérteni, hogy a vásárlóid mit is csinálnak vele.

A webről egy másik példa a deja.com fejlődése, ami a Usenet óriási kereshető indexelőjének indult dejanews néven. Az eredeti felületen volt egy szerkesztőmező és egy szöveg: "Keresés a Usenetben". És ennyi. 1999-ben egy kis tevékenység alapú tervezés (ABP) segítségével rájöttek, hogy az egyik leggyakoribb felhasználói tevékenység a "milyen kocsit vegyek"-szerű termékre vagy szolgáltatásra való keresés. A Deja teljesen átszervezte magát és ma már inkább egy termékalapú keresési szolgáltatás, a Usenet-keresési funkció szinte teljesen el lett rejtve. Kis számú felhasználót, akik arra használták korábban, hogy megkeressék, az ő Matrox videokártyájuk megy-e RedHat Linux 5.1 alatt, persze felháborított a változás, de sokkal több ember viszont, akik csak meg akarták venni a legtutibb digitális fényképezőt, megelégedetten használta.

Az ABP-vel kapcsolatos másik nagyszerű dolog az, hogy rájöhetsz, mit nem kell tudnia a programodnak. Amikor bármilyen szoftvert csinálsz, a valóság az, hogy háromszor annyi funkciót tervezel el, mint amennyire van is idő megvalósítani. És ha megnézed, melyik funkcióra van szüksége a legfontosabb tevékenységeknek, akkor könnyebben eldöntheted, hogy melyiket valósítsd meg és melyiket ne.

Képzeletbeli felhasználók

Az ipar legjobb UI tervezői egyetértenek egy dologban: ki kell találnod egy képzeletbeli felhasználót, mielőtt az UI tervezésébe fognál. Még emlékezhetsz a cikk elejére, ahol Peti volt a mi képzeletbeli fehasználónk:

Peti könyvelő egy műszaki könyvkiadónál, hat éve használ Windowst az irodában és néha otthon is. Eléggé hozzáértő és gyakorlott. Saját maga telepíti a programokat, számítógépes magazint olvas és még néhány egyszerű Word makrót is képes megírni, hogy segítsen a titkárnőknek számlákat küldeni. Van internete otthon is. Peti sosem használt Macintosht. "Túl drágák" - mondja - "megvehetsz egy 2 GHz-es PC-t 2 giga rammal ugyanannyi pénzből, mint egy..." Oké, Peti, értjük!

Amikor ezt elolvasod, már magad elé is tudod képzelni Petit. Én különben egy másfajta felhasználótípust is magam elé tudok képzelni:

Anna angol irodalomprofesszor, már írt néhány sikeres könyvet a költészetről. 1980 óta használ számítógépeket szövegszerkesztésre, bár csak két ilyen programot ismer, az egyik a Nota Bene (egy ókori akadémiai szövegszerkesztő) és a Microsoft Word. Semmi kedve időt fecseréleni arra, hogy megtanulja, hogy működnek a számítógépek és hajlamos rá, hogy minden dokumentumát egy könyvtárban tárolja, mintha semmi fogalma nem lenne arról, mik azok az alkönyvtárak.

Nyilvánvaló, hogy Peti számára szoftvert tervezni egészen más kihívást jelent, mint Anna számára és szintén más feladatot jelent szoftvert tervezni a 16 éves Pisti számára, aki Linuxot használ otthon, órákig beszélget IRC-n és elutasítja a "Micro$oft" szoftvereit.

Amikor elképzeled ezeket a felhasználóat, a megfelelő felület kiválasztása sokkal egyszerűbb lesz. Sok programozó hajlamos túlbecsülni az átlagos felhasználók képességét arra, hogy maguktól rájöjjenek dolgokra. Akármikor, ha írok valamit arról, hogy a parancssor nehezen használható, azonnal emailek özönét kapom, hogy a parancssor mennyire erőteljes eszköz, mert olyan dolgokat tudsz vele csinálni, mint "gunzip foo.tar.gz | tar xvf-". De ha magam elé képzelem, amint Anna elkezdi begépelni, hogy "gunzip..." egyértelművé válik, hogy ez a kezelőfelület soha nem fog megfelelni az ő igényeinek. Ha elképzelsz egy valódi embert, az megadja neked azt a beleélő képességet, ami lehetővé teszi, hogy olyan szoftvert csinálj, ami megfelel az ő igényeinek. (Persze ha Linuxos backup szoftvert írsz képzett rendszergazdáknak, akkor inkább "Zoli"-ra gondolj, akit kiráz a hideg, ha Windows közelébe kell menni, amit ő különben is csak idézőjeles operációs rendszernek tart, saját egyénileg módosított tcsh shelljét használja és az X11-et négy mozaikszerűen elrendezett xterm ablakkal használja egész nap. És körülbelül 11 xperfs-el.)

Összefoglalva tehát a jó szoftvertervezés hat lépésen alapul:

A jó felhasználói felület eladja a szoftvert, de elégedetté és így boldogabbá is teszi az embereket, mert az emberek boldogok lesznek, amikor sikerül elvégezniük azt a feladatot, amit szeretnének. És ezért jó, ha az ember jártas az UI tervezésében. Hiszen hol máshol lenne rá lehetőséged, hogy emberek millióit egy kicsit boldogabbá tedd?