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
9. peatükk: Tootekujunduse protsess


Joel Spolsky
Tõlkinud Paavo Helde
Toimetanud Anti Veeranna
9. mai 2000

Siiani oleme rääkinud hea disaini põhimõtetest, kuid need võimaldavad ainult olemasolevat disaini hinnata ja parandada. Kuidas aga välja mõelda, milline see kuramuse disain üleüldse olema peaks? Paljud inimesed kirjutavad pikki funktsionaalseid kirjeldusi kõigi võimaluste kohta, mida nad välja mõelda suudavad. Seejärel ehitavad nad need ühekaupa valmis ja paigutavad menüüdesse (või veebilehele). Kui nad lõpetavad, sisaldab programm (või veebisait) küll kogu soovitud funktsionaalsust, kuid see ei voola õigesti. Inimesed istuvad arvuti taha ning ei taipa, mida programm teeb või kuidas oma eesmärke saavutada.

Microsofti lahendus sellele probleemile kannab nime "Tegevuspõhine planeerimine". (Niipalju kui ma tean, on see mõiste leiutatud Mike Conte poolt Exceli meeskonnas, kellel sai asjast aga villand ja kes alustas oma teist karjääri võidusõiduauto piloodina). Võtmeküsimuseks on siinkohal kasutaja poolt sooritatavate tegevuste leidmine ja nende lihtsalt teostatavaks muutmine. Kõige parem on seda selgitada näite varal.

Oled otsustanud luua veebisaidi, mille abil saab saata tervituskaarte. Probleemile naiivselt lähenedes võiksid sa välja tulla sellise nimekirjaga:

1. Lisa kaardile tekst
2. Lisa kaardile pilt
3. Vali teegist valmiskujundusega kaart
4. Saada kaart:
           a. e-posti teel
           b. välja trükkides 
Kogemuse puudumine parema lahenduse välja töötamiseks viib tüüpilise Macintoshi kasutajaliideseni aastast circa 1984: programmi käivitades on ekraanil tühi kaart pluss menüüvalikud teksti ja pildi lisamiseks, kaartide teegist laadimiseks ja ära saatmiseks. Kasutajal ei jää muud üle, kui maha istuda ja püüda menüüsid lapates selgusele jõuda, millised käsud olemas on ja kuidas neid kaardi koostamiseks rakendada tuleks.

Seevastu tegevusepõhine planeerimine ütleb, et alustada tuleb tegevuste nimekirjaga, mida kasutajad võivad sooritada tahta. Niisiis vestled sa potentsiaalsete kasutajatega ja tuled välja tegevuste esikolmikuga:

  1. Sünnipäevaõnnitlus
  2. Peokutse
  3. Aastapäevatervitus
Selle asemel, et programmeerija kombel mõelda, millised võimalused on vajalikud kaardi koostamiseks, mõtled sa asja nüüd asja üle kasutaja vaatevinklist - millised on need tegevused, mida kasutaja sooritab, ehk siis täpsemalt:
  1. Sünnipäevakaardi saatmine
  2. Peo planeerimine ja külaliste kutsumine
  3. Aastapäevakaardi saatmine
Äkitselt tulevad pähe igasugu uued ideed. Tühja kaardiga alustamise asemel võiksid sa alustada näiteks sellise menüüga:
 
Mida sa teha soovid? 
  • Saata sünnipäevaõnnitlust
  • Saata aastapäevakaarti 
  • Saata peokutset 
  • Alustada tühja kaardiga 
Korraga tundub kasutajatele sinu programm palju sõbralikum, sest see juhib neid tegevuse sooritamiseks vajalikke samme pidi, ilma menüüdes sobramise vaevata. (Muidugi eksisteerib risk, et kui sa ei vali tegevusi õigesti, võid sa eemale peletada või segadusse ajada kasutajaid, kes muidu suutnuks sinu programmi kasutada näiteks Hanukah kaardi saatmiseks, kuid ei näinud selleks võimalust. Niisiis hoolitse selle eest, et valiksid tegevused, mis kataksid suurema osa soovitud sihtgrupist.)

Juba nende kolme tegevuse peale vaatamine toob mõttesse mõned suurepärased täiendused. Näiteks, kui sa saadad sünnipäevaõnnitlust või aastapäevakaarti, siis tahaksid sa võib-olla, et sulle seda järgmisel aastal meelde tuletataks, niisiis võiks lisada märkeruudu "Tuleta mulle aasta pärast meelde". Peokutse omakorda nõuab RSVP-sid, nii et võiks lisada täienduse RSVP-de elektrooniliseks registreerimiseks. Mõlemad ideed tunduvad peaaegu iseenesestmõistetavad, kui programmi võimaluste asemel vaadeldakse kasutaja tegevusi.

See oli muidugi triviaalne näide; tõsiste programmide puhul on tegevuspõhise planeerimise efekt palju suurem. Isegi siis, kui sa mingit programmi nullist üles ehitad, on sul juba olemas mingi nägemus sellistest tegevustest. Sellise nägemuse saavutamine ei ole üldse raske, koos kolleegidega väikese ajurünnaku korraldamine ja potentsiaalsete tegevuste välja selgitamine ei nõua peaaegu mingit vaeva. Seejärel saab otsustada, millistele neist keskenduda. Üldine disain paraneb märgatavalt, kui sunnid end neid tegevusi paberil ritta seadma.

Tegevusepõhine planeering on veelgi olulisem, kui valmistud välja laskma juba kasutusel oleva toote järgmist versiooni. Sellisel juhul oleks hea jälgida kliente, et kindlaks teha, milleks nad programmi kasutavad.

Exceli versioonide 1.0-4.0 välja töötamise ajal oli enamik Microsoft töötajaid seisukohal, et kõige levinum kasutaja tegevus on finantsalaste kui-siis stsenaaariumite läbi mängimine. Muudetakse näiteks inflatsiooniprotsenti ja uuritakse selle mõju kasumile.

Kui asusime projekteerima Excel 5.0-i, mis oli esimene peamiselt tegevusepõhist lähenemist kasutav versioon, piisas meile viie kliendi jälgimisest, mõistmaks, et tohutu hulk inimesi kasutas Excelit lihtsate nimekirjade koostamiseks. Nad ei sisestanud mingeid valemeid ega teinud mingeid arvutusi! Me ei olnud sellist võimalust varem isegi unes näinud. Nimekirjade koostamine osutus kaugelt kõige populaarsemaks Excelis tehtavaks tegevuseks. See avastus viis meid terve posu nimekirjade koostamist lihtsamaks tegevate uuenduste sisse toomisele: kergem sorteerimine, automaatne andmesisestus, AutoFilter nimekirjast väljavõtete tegemiseks, ning ka mitme-kasutaja vahendid, mille abil saavad mitu inimest korraga nimekirja kallal töötada, sellal kui Excel automaatselt kõik kokku paneb.

Excel 5 projekteerimise ajal tõi Lotus turule "uue laine" tabelarvutusprogrammi nimega Improv. Pressiteate järgi oli Improvi näol tegemist terve uue tabelarvutusprogrammide põlvkonnaga, mis pidi minema pühkima kõik varemolnu. Mitmete veidrate juhuste tõttu oli Improv alguses saadaval ainult NeXT-il, mis kohe päris kindlasti ei tulnud müüginumbritele kasuks, samas paljud, muidu arukad, inimesed uskusid, et Improv tähendab NeXT-i jaoks sama, mis VisiCalc Apple II jaoks: et see on killer app, mis sunnib kasutajaid minema ja ostma endale täiesti uue riistvara selle uue programmi kasutamiseks.

Improv on nüüdseks kõigest reaalune märge ajalooõpikutes. Otsige seda veebist, ja kõik, mida te leiate, on mõne ülekorrastatud laoruumi haldajate poolt  mingil põhjusel veebi üles pandud tolmu koguvate asjade inventuur.

Miks see nii läks? Aga sellepärast, et Improvis oli lihtsate nimekirjade koostamine praktiliselt võimatu. Improvi projekteerijad arvasid, et tabelarvutusprogramme kasutatakse komplitseeritud mitmemõõtmeliste finantsmudelite koostamiseks. Kui nad oleksid vaid inimestelt küsinud, siis oleksid nad avastanud, et mitmemõõtmelistest finantsmudelidest hoopis levinum on lihtsate nimekirjade koostamine ja et Improvis on see sulaselge piin, kui mitte täiesti võimatu.

Niisiis on tegevusepõhine planeerimine abiks juba rakenduse algstaadiumis, kui sa saad ainult oletada, mida inimesed võiksid teha tahta. Veelgi kasulikum on see uut versiooni ette valmistades, sest siis on sul oma klientide tegevusest juba ettekujutus olemas.

Veel üks näide, seekord veebist. deja.com alustas mahuka otsitava Useneti indeksina nimega dejanews. Esialgne kasutajaliides koosnes peamiselt ühest tekstikastist ja kirjast "Otsi Usenetist miskit"; ja see oligi kõik. 1999. aastal näitas veidi tegevusepõhist planeerimist, et üks sagedasemaid tegevusi oli toote või teenuse kohta info kogumine, stiilis millise-auto-ma-peaksin-ostma. Deja organiseeriti täielikult ümber ning nüüd sarnaneb see rohkem tootehinnangute kogumise teenusele: võimalus Useneti otsinguteks on peaaegu täiesti peidetud. See küll ärritas seda väikest kasutajate hulka, kes kasutasid veebi info leidmiseks selle kohta, kas nende Matrox-i videokaart töötab Redhat Linux 5.1 all, kuid rõõmustas palju rohkearvulisemat kasutajaskonda, kes tahtis lihtsalt osta parimat digitaalkaamerat.

Tegevuspõhise planeerimise teine hea omadus on see, et see võimaldab koostada nimekirja asjadest, mida mitte teha. Mis tahes liiki tarkvara loomisel on paratamatu, et sulle tuleb pähe kolm korda rohkem ideesid, kui sa teostada jõuad. Üks parimaid meetodeid terade ja sõkalde eraldamiseks on vaadata, millised võimalused teevad kõige sagedamini sooritatavad tegevused lihtsamaks.

Kujuteldavad kasutajad.

Kõik parimad professionaalsed UI projekteerijad nõustuvad ühes asjas: enne kasutajaliidese kujunduse juurde asumist tuleb välja mõelda ja kirjeldada mõned kujuteldavavad kasutajad. Sul on ehk meeles, et selle raamatu sissejuhatuses oli juttu Pete'i-nimelise kujuteldavast kasutajast:
Pete on arveametnik tehnikakirjastuses. Ta on kasutanud Windowsi kuus aastat tööl ja natuke kodus. Ta on päris kompetentne ning orienteerub tehnilistes küsimustes hästi. Ta installeerib oma tarkvara ise; ta loeb PC Magazine'i ja on isegi kirjutanud mõned lihtsad Wordi makrod aitamaks oma kontori sekretärineiudel arveid välja saata. Tal on kodus püsiühendus. Pete ei ole kunagi kasutanud Macintoshi. "Nad on liiga kallid," seletab ta teile, "sama raha eest võiksite saada 700 MHz PC 128 mega mäluga..." OK, Pete. Me saime sinust aru.
Seda kirjeldust lugedes inimese kuju lausa kerkib silme ette. Ma oleksin võinud välja mõelda ka hoopis teist tüüpi kasutaja:
Patricia on inglise filoloogia professor ja ta on kirjutanud mitmeid populaarseid luulekogumikke. Ta on kasutanud arvuteid tekstitöötluseks 1980. aastast alates, kuid seejuures on tal kogemusi ainult Note Bene (see on iidne akadeemiline tekstitöötlusprogramm) ja Microsoft Wordiga. Ta ei taha kulutada oma aega arvuti tööpõhimõtete omandamiseks ja ta kaldub salvestama kõiki oma dokumente sellesse kataloogi, kuhu nad satuksid siis, kui tal poleks aimugi kataloogide olemasolust.
Tarkvara projekteerimine Pete'i jaoks on ilmselt üsna erinev samast tegevusest Patricia jaoks. Patricia omakorda erineb üpriski Mike'ist, 16-aastasest tegelasest, kes jooksutab kodus Linuxit, lobiseb tundide kaupa IRC-s ja ei kasuta vabatahtlikult "Micro$ofti" tarkvara.

Selliste kasutajate leiutamine muudab disaini sobivuse hindamine palju hõlpsamaks. Paljud programmeerijad kalduvad ülehindama tüüpilise kasutaja suutlikkust lahenduste välja mõtlemiseks. Iga kord, kui ma kirjutan käsuridade raskest kasutatavusest, satun ma vältimatult e-posti turmtule alla. Väidetakse, et käsurealiidesed on supervõimsad, sest nendega saab teha asju nagu 'gunzip foo.tar.gz | tar xvf -'. Aga niipea kui järgi mõelda selle üle, kuidas Patriciat saada trükkima "gunzip...", siis selgub, et seda tüüpi kasutajaliidesest ei oleks talle iial mingit abi. Mõtlemine "reaalsele" isikule varustab sind vajaliku empaatiaga sellele isikukule vajalike võimaluste projekteerimiseks. (Loomulikult, kui sul on käsil Linuxi varundustarkvara kogenud süsteemiadministraatoritele, siis tuleb sul ette kujutada "Franki", kes keeldub Windowsi puudutamast (ta räägib sellest ainult kui "operatsioonisüsteemist" jutumärkides), kes kasutab isiklikult modifitseeritud versiooni tcsh-st ja jooksutab päev läbi X11-t nelja mosaiiki paigutatud xterm-iga (ja 11 xperf-iga).

Kokkuvõttes nõuab hea tarkvara projekteerimine kuut sammu:

Mõtle välja mõned kasutajad

Selgita välja olulised tegevused

Selgita välja kasutajamudel -- kasutaja ettekujutus nende tegevuste sooritamisest

Koosta kujunduse esimene mustand

Käi oma disain veel ja veel kord üle, muutes seda järjest lihtsamaks, kuni see on sinu kujuteldavatele kasutajatele selgelt jõukohane.

Jälgi tegelikke kasutajaid oma programmi kasutamas. Pane tähele kohti, kus neil tekib raskusi -- need on tõenäoliselt kohad, kus programmimudel ei vasta kasutajamudelile.

Hea kasutajaliides aitab tarkvara paremini müüa, kuid see valmistab ka inimestele head meelt, sest neile meeldib oma ülesandega hakkama saada. Seetõttu ongi kasutajaliidese projekteerimine sedavõrd rahuldust pakkuv valdkond. Kus mujal avaneks sulle võimalus miljoneid inimesi natukenegi õnnelikumaks teha?

>  Selle raamatu trükiversioon on mahukam, sisaldades seitset lisapeatükki, mis pole veebis kättesaadavad. Seda saab lugeda isegi rannas, ilma et peaks kartma liiv sattumist sinu läptopi klahvide vahele.





Artikli algupärane nimi inglise keeles on User Interface Design for Programmers Chapter 9: The Process of Designing a Product  

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