Joel on Software

Joel on Software Joel tarkvarast

 

Kasutajaliidese disain programmeerijatele
1. peatükk
2. peatükk
3. peatükk
4. peatükk
5. peatükk
6. peatükk
7. peatükk
8. peatükk
9. peatükk

Veel "Joel on Software" artikleid eesti keeles

Veel "Joel on Software" artikleid inglise keeles

Kirjuta autorile (ainult inglise keeles)

 

Kasutajaliidese disain programmeerijatele
3. peatükk: Valikud


Joel Spolsky
Tõlkinud Paavo Helde
Toimetanud Anti Veeranna
12. aprill 2000

Nähes restorani sisenedes silti "Koertega sisenemine keelatud" võid oletada, et silt on seal seetõttu, et Mr. Restoranile koerad ei meeldi; niisiis pani ta oma restorani rajades välja sellise sildi.

Kui see oleks asja iva, siis peaks seal olema ka silt "Madudega sisenemine keelatud". Lõppude lõpuks ei meeldi maod ju kellelegi. Ja silt "Elevantidega sisenemine keelatud," sest elevandid lõhuksid istuda üritades toolid ära.

Sildi tegelik põhjus on ajaloone: see on märk, mis näitab, et inimestel oli kombeks oma koeri restorani kaasa võtta.

Enamik keelumärke on paigaldatud seetõttu, et valduse omanikul sai kõrini X tegevust sooritavatest inimestest ja seetõttu pani ta üles seda keelava sildi. Astudes mõnda viiekümne aasta vanusesse mamma-papa söögikohta, nagu näiteks Yankee Doodle New Havenis, märkad et seinad on kaetud siltidega stiilis "Palun ära pane oma seljakotti letile". See on omamoodi antropoloogiline tõend selle kohta, et paljud külastajatel oli kombeks oma seljakotte letile panna. Sildi vanuse järgi saab kindlaks teha, mis ajal seljakotid kohalike üliõpilaste seas populaarsed olid.

Mõnikord on selguse saamine raskem. "Palun ärge tooge klaaspudeleid parki" võib tähendada, et keegi on kord paljajalu murul kõndides klaasikildudele astudes end vigastanud ja ehk isegi linna kohtusse kaevanud.

Ka tarkvara juures kohtab selliste arheoloogiliste jälgede analoogi; seda nimetatakse suvandite (Options) dialoogiks. Ava Tools | Options dialoogiaken ning sa näed vaidluste ajalugu, mida tarkvara projekteerijad programmi arendamise käigus pidasid. Kas peaksime automaatselt avama viimase faili, mille kallal kasutaja töötas? Jah! Ei! Toimub kahenädalane debatt, kellegi tundeid ei taheta solvata, programmeerija lisab koodi enesekaitseks #ifdef direktiivi, samal ajal kui projekteerijad asja üle vaidlevad. Lõpuks jäetakse asi kasutaja otsustada.

See ei pruugi isegi olla kahe inimese vaheline debatt; see võib olla ka sisemine dilemma. Ma lihtsalt ei suuda otsustada, kas optimeerida andmebaasi suuruse või kiiruse suhtes. Lõpuks ilmuvadki sellised asjad nagu näiteks ilmselgelt kõige idiootlikum viisard (Wizard) Windowsi operatsioonisüsteemi ajaloos. See dialoog on niivõrd jabur, et vääriks lausa mingit sorti auhinda. Tervet uut auhinnakategooriat. See dialoog ilmub siis, kui püüad spikrifailist (Help) midagi otsida:

Selle dialoogi esimene probleem on selles, et ta on häiriv. Sul on vaja abiinfot leida. Sel hetkel on kama kaks, kas andmebaas on väike, suur, erinõudmistele kohandatud või šokolaadiglasuuriga. See neetud dialoog aga üritab pidada väikest pedantset loengut selle kohta, et ta peab tekitama mingi nimestiku (või andmebaasi). Teksti on umbes kolme lõigu jagu ning enamik sellest on täiesti segadusseajav. Siin leidub piinlikult kohmakas fraas "your help file(s)". Tegemist võib nimelt olla ühe või enamate failidega. Justkui nende arv sulle karvavõrdki korda läheks. Justkui see oleks ääretult oluline. Aga selle dialoogiakna välja töötanud programmeerija oli ilmselt uskumatult häiritud mõtte juures, et tegemist võib olla rohkema kui ühe spikrifailiga ja sel juhul oleks ju vale öelda lihtsalt "fail", kas pole nii?

Ma pigem ei hakkagi rääkima sellest, et spikrifailist abi lootvad inimesed ei saa niikuinii säärastest nüanssidest aru. Isegi kogenud kasutajad, arvutiteaduse diplomiga programmeerijad, kes teavad kõike täistekstindeksite kohta, ei suudaks aru saada, milliste valikute vahel neil tegelikult on palutud valida.

Taga targemaks, see ei ole isegi dialoog... see on viisard (mille teine lehekülg lihtsalt ütleb parafraseerides midagi stiilis "Aitäh, et võtsite osa sellest teie aja kasutust raiskamisest". On ka üpris ilmne, et programmeerijatel oli mingi arvamus selle kohta, milline valik on parim; nad on ju lõppude lõpuks võtnud vaevaks üht neist soovitada.

See toob meid kasutajaliidese disaini teise peamise reeglini:

 
Iga kord kui pakud kasutajale valikuvõimalusi, sunnid sa teda otsustama.
Kasutajalt otsustamise nõudmine ei ole iseenesest halb. Valikuvabadus võib olla imetore. Inimesed armastavad tellida espressojooke Starbucksis, sest nad saavad sealjuures teha nii palju valikuid. Gränd-pool-kohvi-riibutud-moka-Valencia-munavahuga. Ekstra tuline!

Probleem tekib siis, kui paluda kasutajatel teha valikuid, millest nad ei hooli. Infofaile kasutatakse selleks, et leida abi mingi probleemi juures, selleks et saada hakkama mingi asjaga, millega nad tõepoolest tahavad hakkama saada, näiteks sünnipäevakutse tegemisega. Sünnipäevakutsete tegemine on aga õnnetul kombel takerdunud, sest nad ei oska trükkida kõnemullidesse teksti jalad ülespidi, või midagi muud sellesarnast. Niisiis otsivad nad abi spikrist. Nüüd aga julgeb mingi tülikas Microsofti spikrifailide indekseerimismootori programmeerija, kellel on ülepaisutatud arusaamine iseenda tähtsusest kogu asja juures, häbitult veel kord kasutajat katkestada ja hakata talle õpetama, kuidas teha nimestikke (või andmebaase). See teine katkestamise tase pole üldse seotud sünnipäevakutsetega ning on lihtsalt määratud kasutajat segadusse ajama ja lõpuks välja vihastama.

Usu mind, kasutajad hoolivad palju vähematest asjadest kui sa ette kujutad. Nad vajavad sinu tarkvara selleks, et hakkama saada mingi ülesandega. Nad hoolivad oma ülesandest. Kui tegemist on pilditöötlusprogrammiga, siis tahavad nad tõenäoliselt kontrollida iga pikslit viimase detailini. Kui tegemist on töövahendiga veebilehekülgede koostamiseks, siis võid kindel olla, et neil on kinnisidee selle kohta, kuidas veebilehekülg välja peab nägema.

Samas ei hooli nad karvavõrdki sellest, kas programmi enda tööriistariba on akna ülemises või alumises servas. Nad ei hooli sellest, kuidas spikrifaili indekseeritakse. Nad ei hooli paljudest asjadest, ning disaineri kohus on teha need otsused nende eest. Tarkvara projekteerija poolt on häbematuse tipp anda mingid asjad kasutaja otsustada lihtsalt sellepärast, et projekteerija ei suutnud ise asja üle piisavalt järgi mõelda ning parimat valikut välja selgitada. (Veel halvem on püüe varjata kasutajale raske valiku andmise fakti vormistades selle viisardina, nagu WinHelp'i arendajad tegid. Justkui kasutaja oleks idioot, kes vajab väikest kahesammulist minikursust neile pakutud valikute osas, et teha põhjendatud otsus.)

Öeldakse, et projekteerimine on valikute tegemise kunst. Kavandades kõnniteele paigutatavat prügikasti, pead tegema valikuid vastuoluliste nõudmiste vahel. Kast peab olema raske, et tuul seda ära ei puhuks. Kast peab olema kerge, et prügivedaja jaksaks seda tühjaks kallata. Kast peab olema suur, et mahutada palju prügi. Kast peab olema väike, et mitte jalakäijatele ette jääda. Kui projekteerid programmi ja proovid vastutust enda pealt ära veeretada, nõudes kasutajalt millegi otsustamist, siis tõenäoliselt ei täida sa oma kohuseid. Keegi teine teeb lihtsama programmi, mis teeb väiksema sekeldamisega sama asja ära, ja see meeldib kasutajate enamikule rohkem.

Kui 1990. a. ilmus Microsoft Excel 3.0, oli see esimene programm, mis kasutas uut vahendit - tööriistariba. See oli mõistlik uuendus, meeldis inimestele ja kõik kopeerisid seda - tänapäeval kohtab harva ilma tööriistaribata programmi.

Tööriistariba oli nii edukas, et Exceli meeskond tegi väliuuringuid, kasutades mõningatele kasutajatele välja jagatud spetsiaalset Exceli versiooni, mis pidas arvet enim kasutatud käskude üle ja saatis kokkuvõtted tagasi Microsofti. Järgmises versioonis lisati veel üks rida tööriistanuppe, mis sisaldas kõige sagedamini kasutatavaid käske. Suurepärane.

Häda oli selles, et keegi ei märganud tööriistariba meeskonda õigel ajal laiali saata ning viimane ei paistnud ise ka aru saavat, millal on tark lõpetada. Nad tahtsid anda sulla võimalust tööriistariba mugandada. Nad tahtsid anda sulle võimalust lohistada seda suvalisse kohta ekraanil. Seejärel tuli neile mõte, et menüüriba on tegelikult sama asi, ainult et ikoonide asemel on sõnad; niisiis andsid nad sulle ka võimaluse lohistada menüüriba suvalisse kohta ekraanil. Mugandamine steroididel. Probleem: keegi ei hooli! Ma pole iial kohanud kedagi, kes tahaks oma menüüriba näha kuskil mujal kui akna ülemises servas. See-eest ootab meid (halb) nali: kui proovid avada Fail-menüüd ja haarad eksikombel menüüribast kinni veidi liiga vasakult, siis jääb terve menüüriba sulle pihku ja satub tõenäoliselt ainsasse kohta, kus sa seda näha ei taha: blokeerima dokumenti, millega parasjagu töötad.

Mitu korda saoled sellist pilti näinud? Ja kui sa oled selle eksikombel tekitanud, ei ole sugugi lihtne aru saada, mida sa täpselt tegid või kuidas seda parandada. Niisiis on meil valikuvõimalus (menüü liigutamiseks), mida keegi ei vaja (kui ehk 0.1% inimkonnast välja arvata), aga mis jääb jalgu peaaegu igaühele.

Ühel päeval helistas mulle sõber. Tal oli probleeme meili saatmisega. Pool ekraanist on hall, ütles ta.

Pool ekraanist hall?

Mul võttis viis minutit, et telefoni teel aru saada, mis oli juhtunud. Ta oli eksikombel tirinud Windowsi stardiriba ekraani paremale küljele ning seejärel eksikombel seda laiemaks vedanud:

Sellist asja ei tee keegi tahtlikult . Ja leidub palju arvutikasutajaid, kes ei suuda end sellest segadusest välja aidata; definitsiooni järgi, muutes ekslikult mõnd seadistust oma programmis, pole sul aimugi, kuidas endist olukorda taastada. On hämmastav, kui paljud inimesed installeerivad oma tarkvara maha ja uuesti peale, kui programm hakkab veidralt käituma - seda nad vähemalt oskavad teha. (Nad on õppinud esmalt maha installeerima, sest muidu ilmuvad vigased seaded tõenäoliselt lihtsalt tagasi).

"Mine nüüd!" ütled sa. "On oluline, et kogenud kasutajatel oleks olemas võimalus keskkonda oma käe järgi seada!" Tegelikkuses pole see nii oluline kui arvatakse. See tuletab mulle meelde, kuidas ma püüdsin üle minna Dvoraki klaviatuurile. Häda on selles, et ma ei kasuta ühte arvutit. Ma kasutan erinevaid arvuteid. Ma kasutan teiste inimeste arvuteid. Ma kasutan üsna regulaarselt kolme arvutit kodus ja kolme töö juures. Ma kasutan ka testimislabori arvuteid töö juures. Oma keskkonna mugandamise juures on see häda, et muudatused ei levi, nii et see ei tasu üldse vaeva.

Kõige kogenumad kasutajad töötavad regulaarselt mitme arvutiga; nad uuendavad oma arvuteid iga paari aasta tagant ning installeerivad oma opsüsteeme iga kolme nädala tagant üle. On tõsi, et esimesel korral, kui nad taipasid, et võivad Wordis klaviatuuri täielikult ümber defineerida, muutsid nad tõesti kõik endale meelepäraseks, kuid niipea kui nad läksid üle Windows 95-le, läksid need seaded kaotsi ja nagunii ei olnud need samasugused kui töö juures, nii et lõpuks nad lihtsalt loobusid programmide ümberkonfigureerimisest. Olen küsinud selle kohta paljude tuttavate "oskuskasutajate" käest; peaaegu keegi neist ei muganda programme rohkem, kui süsteemi mõistlikult tööle saamiseks hädavajaliku miinimumi ulatuses.

Iga kord, kui esitad kasutajale valikuvõimaluse, sunnid sa kasutajat otsustama. See tähendab, et neil tuleb millegi üle järgi mõelda ja otsusele jõuda. See ei ole tingimata halb, kuid üldiselt peaksid sa püüdma kasutajate poolt tehtavate valikute arvu miinimumini viia.

See ei tähenda, et tuleks likvideerida kõik valikud. On palju valikuid, mida kasutajad peavad nii või teisiti tegema: mismoodi nende dokumendid peavad välja nägema, kuidas nende veebileheküljed peavad töötama ja kõik muu, mis on otseselt seotud kasutaja tööga. Nendes valdkondades ära hoia end tagasi: on tore anda inimestele valikuvabadust, mil moel iganes ja mida rohkem, seda parem. On olemas veel üks sort valikuid, mis inimestele meeldivad: võimalus muuta millegi visuaalset väljanägemist, ilma et funktsionaalsus muutuks. Igaüks armastab WinAmp'i kesti, igaüks paneb oma töölaua taustaks pildi. See on näide headest valikutest, sest need valikud mõjutavad ainult välimust aga mitte programmi tööd. Kasutajatel on täielik vabadus neid ignoreerida ja ikkagi oma tööga hakkama saada.



> 4. peatükk

Artikli algupärane nimi inglise keeles on User Interface Design for Programmers Chapter 3: Choices  

Joel Spolsky on Fog Creek Software asutaja. See on väike tarkvarakompanii New York Citys. Ta on lõpetanud Yale'i ülikooli ja töötanud programmeerija ning juhina Microsoftis, Viacomis ja Junos.


Need leheküljed esitavad üksikisiku seisukohti.
Kogu sisu Copyright ©1999-2005 Joel Spolsky. Kõik õigused reserveeritud.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky