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
6. peatükk: Disain inimestele, kel on oma eluga parematki teha


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

Kasutajaliidest projekteerides on hea alati meeles pidada kahte printsiipi:

  1. Kasutajatel pole manuaali, ja isegi kui neil oleks, siis nad ei loeks seda.
  2. Tegelikult ei suuda kasutajad midagi lugeda, ja isegi kui nad suudaks, siis ei tahaks nad seda teha.
Rangelt võttes pole tegemist faktidega, kuid sa peaksid käituma nii, nagu oleksid need faktid, sest see muudab sinu programmi kergemaks ja sõbralikumaks. Neist printsiipidest lähtuv projekteerimine tähendab kasutaja respekteerimist, mis sisuliselt aga tähendab respekti puudmist kasutaja suhtes. Segaduses? Selgitame asja.

Mida tähendab millegi hõlpsalt kasutatavaks tegemine? Üks viis tulemuse mõõtmiseks on vaadata, mitu protsenti tegelikest kasutajatest on võimelised ülesannetega etteantud aja jooksul hakkama saama. Oletame näiteks, et sinu programmi eesmärgiks on võimaldada inimestel oma digitaalkaamera fotod veebis asuvaks fotoalbumiks konverteerida. Kui sa paned rühma keskmisi kasutajaid seda ülesannet lahendama oma programmi abil, siis mida lihtsamini kasutatav su programm on, seda kõrgem protsent kasutajaid suudab fotoalbumi edukalt valmistada. Teaduslikumaks lähenemiseks kujuta ette 100 tegeliku maailma kasutajat, kes ei ole tingimata arvutiga sina peal. Neil võib olla mitmesuguseid andeid, kuid mõned nende seast ei ole andekad arvutite alal. Mõnesid neist häiritakse sel ajal, kui nad püüavad sinu programmi kasutada. Telefon heliseb. MIDA? Laps nutab. MIDA? Ja kass hüppab jälle lauale ja ajab hiirt taga. MA EI KUULE SIND!

Isegi seda eksperimenti läbi tegemata, võin ma teatud kindlusega kinnitada, et mõned kasutajad lihtsalt ei suuda ülesandega hakkama saada või siis nõuab see neilt ilmatuma aja. Ma ei taha öelda, et need kasutajad oleksid rumalad . Vastupidi, nad võivad olla vägagi intelligentsed või näiteks täiuslikud sportlased, kuid vis-à-vis sinu programmiga ei pühenda nad kõiki oma motoorseid oskuseid ja ajurakke programmi kasutamiseks. Sa pälvid ainult umbes 30% nende tähelepanust, nii et arvuti seisukohalt pead sa hakkama saama kasutajaga, kes ei mängi täispakiga.

 
Kasutajad ei loe manuaale
Esiteks neil pole manuaali. Seda ei pruugi üldse olemas olla. Ja kui on, siis ei pruugi seda mingil põhjusel käepärast olla: nad on lennukis; nad kasutavad veebilehelt allalaaditud demoversiooni; nad on kodus ning manuaal on töö juures; IT osakond pole neile kunagi manuaali andnudki. Isegi juhul, kui manuaal on olemas, siis ausalt öeldes ei võta nad seda enne kätte, kui neil tõesti midagi muud üle ei jää. Kui väga vähesed erandid välja arvata, ei võta kasutajad manuaale õhtul voodisse kaasa ja ei loe neid läbi enne sinu tarkvara kasutamist. Üldjuhul püüavad sinu kasutajad midagi korda saata, midagi ära teha, ja nad peavad manuaali lugemist oma aja raiskamiseks või siis vähemalt segavaks faktoriks oma ülesande täitmisel.

Ainuüksi fakt, et sa praegu seda raamatut loed, näitab, et sa kuulud kõrgelt haritud eliidi hulka. Jah, ma tean, et inimesed, kes arvuteid kasutavad, on üldiselt võimelised lugema, kuid ma kinnitan, et suur osa neist peab lugemist mingiks majapidamistööks. Manuaal võib olla kirjutatud keeles, mis ei ole nende emakeel ning nad ei pruugi seda piisavalt vallata. Nad võivad olla lapsed! Nad suudavad manuaali dešifreerida, kui nad tõesti peavad, aga mitte mingil juhul ei hakka nad seda tegema enne, kui teist võimalust pole. Kasutajad loevad manuaali ainult vajaduse korral ja vajadust mööda.

Lõpptulemuseks on see, et sul pole eriti muud valikut, kui projekteerida oma tarkvara nii, et seda saaks ilma manuaalita kasutada. Ainus erand, mida ma ette kujutada suudan, on see, kui kasutajad ei tunne valdkonda -- nad ei saa aru, milleks programm üldse mõeldud on, ning on seetõttu valmis õppima. Suurepäraseks näiteks on Intuiti väga populaarne väikeettevõtete raamatupidamisprogramm QuickBooks. Paljud selle programmi kasutajad on väikeettevõtete omanikud, kellel pole raamatupidamisest erilist ettekujutust. QuickBooks'i juhend arvestab sellega ja eeldab, et kasutajale tuleb õpetada raamatupidamise põhitõdesid. Sellest pole lihtsalt pääsu. Juhul, kui inimene juba raamatupidamist tunneb, on tal QuickBooksi siiski väga lihtne ka ilma juhendita kasutada.

Tegelikult ei loe kasutajad midagi.

See võib kõlada veidi ülepakutult, aga kasutushõlpsuse teste tehes näed sa kohe, et on olemas üsna palju kasutajaid, kes lihtsalt ei loe ekraanile kuvatud sõnu. Nad lihtsalt ei loe kuvatud veateate teksti. See võib sinus, kui programmeerijas, hämmeldust tekitada, sest sa kujutad ette, nagu peaksid kasutajaga dialoogi. Hei, sina! Sa ei saa seda faili avada, sest me ei toeta seda failiformaati! Praktika näitab aga, et mida rohkem sõnu dialoogiaknas on, seda vähem kasutajaid neid loeb.

See fakt, et kasutajad juhendeid ei loe, on viinud paljud tarkvaraprojekteerijad arvamusele, et nad peavad harima kasutajaid käigu pealt asju seletades. Sa näed seda programmides igal pool. Põhimõtteliselt on kõik korras, kuid inimeste vastumeelsus lugemise suhtes tähendab seda, et sa tekitad endale ise probleeme. Kogenud UI projekteerijad püüavad dialoogis asuvate sõnade arvu miinimumini viia, et suurendada nende lugemise tõenäosust. Kui ma töötasin Junos, siis UI inimesed said sellest põhimõttest aru ja püüdsid kirjutada lühikesi, selgeid ja lihtsaid teateid. Kahjuks oli firma tegevdirektor õppinud inglise filoloogiat Ivy League kolledžis; tal puudus igasugune ettevalmistus UI disaini ja tarkvara projekteerimise vallas, kuid ta oli täiesti kindel, et on hea proosatoimetaja. Seega pani ta professionaalsete UI projekteerijate sõnastusele veto ning lisas ohtralt oma teksti. Tüüpiline Juno dialoog näeb välja nii:

(Häälesta modem. Modemid, mida Juno sinu arvutist leidis, on toodud allpool asuvas nimekirjas. Palun klõpsa selle modemi nimel, mida soovid kasutada Junoga ühenduse loomiseks. Kui sa peaksid soovima modemeid lisada, eemaldada või häälestada, klõpsa "Halda modemeid" nupul. Kui nimekirjas pole ühtegi modemit, siis tuleb sul modem installeerida (klõpsates "Halda modemeid" nupul) või võtta Junoga ühendust võrgu kaudu, et Junot registreerida või kasutada.)

Võrdle seda Windowsi analoogilise dialoogiga:

Sulle võib intuitiivselt tunduda, et Juno versioon 80 sõna instruktsioonidega on "ülekaalukalt parem" (s.t. kergemini kasutatav) 5 sõnaga Windowsi omast. Tegelikkuses seda laadi asjade kasutushõlpsuse teste tehes ilmneb, et

  • enamik kogenud kasutajaid ignoreerivad instruktsioone. Nad on veendunud, et tunnevad asja ning neil pole aega juhendeid lugeda.
  • enamik algajaid ignoreerivad instruktsioone. Neile ei meeldi liiga palju lugeda ja nad eeldavad, et vaikeväärtused on sobivad.
  • ülejäänud algajad üritavad kohusetundlikult instruktsioone lugeda (mõned neist teevad seda ainult seetõttu, et tegemist on kasutushõlpsuse testiga ja nad tunnevad teatud kohusetunnet), kuid satuvad tihti segadusse suure sõnade arvu ning mõistete hulga tõttu. Nii et isegi kui nad algul olid üsna kindlad, et suudavad dialoogi kasutada, siis instruktsioonide lugemine viis neid rohkem segadusse.
Juno oli selgelt üle igasuguse piiri mikro-juhitud. Asja juurde tulles, kui sa oled inglise filoloog Columbia ülikoolist, siis mängid sa täiesti erinevas kirjanduse liigas, kui keskmine Joe ning peaksid olema eriti ettevaatlik abistavate dialoogide sõnastamisel. Lühenda, suru kokku, lihtsusta, viska minema sulgudes olevad komplitseeritud konstruktsioonid ning testi kasutushõlpsust. Ära mitte mingil juhul kirjuta tekste, mis meenutavad Ivy League teaduskonna memosid. Isegi sõna "palun" lisamine dialoogile, mis võib küll tunduda abistav ning viisakas, takerdab inimesi: suurenenud sõnamaht vähendab mõõdetaval hulgal nende inimeste hulka, kes teksti läbi loevad.

Teine tähtis moment on see, et paljud inimesed kardavad arvuteid. Sa arvatavasti tead seda, kas pole nii? Aga sa ei pruugi endale tagajärgi ette kujutada. Vaatlesin kord, kuidas üks mu sõber üritas Junost väljuda. Mingil põhjusel tekkis tal sellega probleeme. Junost väljudes ilmub selline dialoog:

Ta klõpsas "No" ning üllatus, kui Juno kinni ei läinud. Ainuüksi see fakt, et Juno tema tegevuse kohta kinnitust küsis, pani teda koheselt arvama, et ta on midagi valesti teinud. Tavaliselt, kui programm palub sul midagi kinnitada, tähendab see seda, et sa proovid teha midagi, mida võid hiljem kahetseda. Ta eeldas, et kui juba arvuti tema otsust küsitavaks pidas, siis oli arvutil kindlasti õigus, sest arvutid on ju lõppude lõpuks arvutid ja tema on vaid inimene, ja nii ta siis klõpsaski "No".

On see siis tõesti liiga palju nõutud - 11 viletsat sõna läbi lugeda? Tuleb nii välja. Esiteks, kuna Junost väljumisega ei kaasne millegi kustutamist, oleks Juno lihtsalt ilma kinnitust küsimata pidanud kinni minema, nii nagu iga teine GUI programm. Isegi juhul, kui sa oled veendunud, et väljumise kinnitamine on kriitilise tähtsusega, saaksid sa seda teha kahe sõnaga 11 asemel:

Ilma täiesti ebavajaliku "tänamise" ja kahtlustäratava fraasita "kas olete kindel?" tekitab see dialoog tõenäoliselt vähem probleeme. Kahte sõna loevad kasutajad kindlasti, kehitavad õlgu ning klikivad "Yes" nuppu.

Selge see, et Juno väljumiskinnitus saab komistuskiviks mõnelegi kasutajale, ütled sa, aga kas maksab siis sellest nii suurt numbrit teha? Igaüks on lõppude lõpuks suuteline programmist väljuma. Aga selles seisnebki erinevus programmide vahel, mida on võimalik kasutada, ja mida on kerge kasutada. Isegi targad ja kogenud kasutajad hindavad segadusseaetud algajate jaoks tehtud asju. Hotellivannidel on suured käepidemed. Need on seal puuetega inimeste jaoks, kuid siiski kasutavad kõik neid vannist välja ronimiseks. Need teevad elu lihtsamaks ka heas füüsilises vormis inimestele.

Järgmises peatükis räägin ma veidi hiirest. Nii nagu kasutajad ei taha ega suuda lugeda, pole mõned neist ka eriti osavad hiire käsitsemisel, nii et sul tuleb ka seda arvesse võtta.



> 7. peatükk

Artikli algupärane nimi inglise keeles on User Interface Design for Programmers Chapter 6: Designing for People Who Have Better Things To Do With Their Lives  

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