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)

Kui Macintosh oli veel uus nähtus, töötas Bruce "Tog" Tognazzini kasutajaliidese veeru toimetajana Apple'i arendajate ajakirjas. Ta lahkas seal mitmeid huvitavaid lugejakirjades tõstatatud UI disaini probleeme. See veerg jätkub tänase päevani tema veebilehel. Artiklid on ka kokku kogutud, illustreeritud ning avaldatud paari suurepärase raamatuna, näiteks Tog on Software Design, mis on üsna lõbus ning samas suurepärane sissejuhatus UI projekteerimisse. ("Tog on Interface" oli isegi parem, kuid seda enam ei trükita)

Tog leiutas mõiste "miilikõrgune menüüriba" selgitamaks, miks Macintoshi ekraani ülaservas asuvat menüüriba on nõnda palju kergem kasutada, kui Windowsi analoogseid alati programmiakna sees paiknevaid menüüribasid. Kui sa tahad osutada Windowsi File-menüüle, on sinu sihtmärk umbes pool tolli lai ja veerand kõrge. Sa pead nii vertikaal- kui ka horisontaalsuunas üsna täpselt hiirt liigutama ja positsioneerima.

Macintoshil seevastu võid sa lajatada hiire ekraani ülaossa, pööramata tähelepanu sellele, kui kõrgele sa teda parasjagu lükkad, see lihtsalt peatub ekraani servas. Tähelepanu peab pöörama ainult hiire horisontaalsele positsioneerimisele, menüüvaliku klõpsamine on selle võrra lihtsam.

Sellest põhimõttest juhindudes esitab Tog viktoriiniküsimuse: millised viis punkti ekraanil on hiirega kõige lihtsamini osutatavad? Vastus: kõik neli ekraani nurka (sinna saab hiire ilma igasuguse sihtimiseta ühe raksuga lükata) ja hiire praegune asukoht (hiir on juba õiges kohas).

Miilikõrguse menüüriba printsiip on hästi tuntud, kuid ilmselt mitte päris iseenesestmõistetav, sest Windows 95 meeskond ignoreeris seda täielikult Start nupu puhul, mis asub peaaegu, aga mitte päris, ekraani vasakus alumises nurgas. Tegelikult on ta umbes 2 pikseli kaugusel alumisest ja 2 pikseli kaugusel vasakust servast. Niisiis, kirjutab Tog, paari pikseli pärast Microsoft sõna otseses mõttes "haaras kaotuse võidu lõugade vahelt," mille tulemusena on stardinupu tabamine palju raskem. See oleks võinud olla ruutmiiline nupp, ilma igasuguste probleemideta hiirega tabatav. Mingil mulle arusaamatul põhjusel see aga nii ei ole. Jumal aidaku meid.

Eelmises peatükis oli juttu sellest, et kasutajad vihkavad lugemist ning väldivad seda, kui nad vähegi suudavad oma ülesandega hakkama saada. Samamoodi:

 

Kasutajatel on raske hiirt kontrollida.

1. Inimesed kasutavad mõnikord ebamugavaid osutusvahendeid, mida on tavalisest hiirest raskem kontrollida, nagu näiteks juhtkuulid, juhtplaadid ja Thinkpadi pisikesed punased jublakad.
2. Mõnikord kasutavad inimesed hiirt kehvades oludes - täiskuhjatud laud; määrdunud kuul tekitab jõnkse; hiir on odav viiedollariline kloon, mis lihtsalt ei tööta korralikult.
3. Mõned inimesed ei ole arvutiga sina peal ning neil pole veel hiire kasutamiseks vajalikud motoorsed oskused välja arenenud.
4. Mõned inimesed ei omanda kunagi hiire täpseks kasutamiseks vajalikke motoorseid oskusi ja ei saagi omandama. Neil võib olla artriit, värinad, karpaaltunneli sündroom; nad võivad olla väga noored või väga vanad; või siis on tegemist mingi muu põhjusega.
5. Paljude inimeste jaoks on äärmiselt raske topeltklõpsu sooritamine ilma seejuures hiirt nihutamata. Programme käivitada püüdes liigutavad nad tihti ekraanil ikoone ühest kohast teise. Sellised inimesed tunneb ära sassis ja segamini töölaua järgi, sest pooltel kordadel, kui nad üritanud midagi käivitada, on see lõppenud ikooni liigutamisega.
6. Isegi kui teisi põhjuseid mitte arvestada, siis tundub hiire kasutamine inimestele aeglasena. Kui sunnid inimest hiirega mitmesammulist operatsiooni tegema, siis võib ta tunda end takerdununa, see omakorda tekitab tunde, et UI ei reageeri piisavalt hästi, mis, nagu sa nüüdseks peaksid teadma, tekitab meelehärmi ja masendust.

Minu arvates üks häirivamaid UI elemente on rippliitboks. See näeb välja nii:

Kui klõpsad noolega nupul, siis tuleb boks lahti:

Mõtle sellele, kui palju täpseid hiireklõpse on vaja, et valida näiteks Times New Roman. Esiteks tuleb klõpsata noolenupul. Seejärel tuleb kerimisriba kasutades ettevaatlikult kerida, kuni Times New Roman nähtavale ilmub. Paljud sellised ripploendid on hooletult projekteeritud nii, et korraga on nähtavad ainult kaks või kolm rida, nii et kerimine pole sugugi lihtne, eriti sii, kui fonte on palju. Selleks tuleb kas ettevaatlikult liugurit nihutada (mis nii väikese liikumisulatuse juures tõenäoliselt ei õnnestu), klõpsata korduvalt teisel alla-noolega nupul või proovida klõpsata liuguri ja alumise noolenupu vahel --- see aga lakkab töötamast, kui liugur jõuab piisavalt madalale, mis omakorda ärritab sind veelgi. Lõpuks, kui oled saanud Times New Roman valiku nähtavale, pead sa sellel klõpsama. Kui mööda paned, tuleb kõike uuesti otsast alata. Korruta seda nüüd kümnega, kui tahad näiteks kasutada tavalisest erinevat fonti iga peatüki esimese tähe jaoks ja tõeline masendus ongi garanteeritud..

See rippliitboks ajab isegi veel rohkem vihale, sest probleemile on olemas väga lihtne lahendus: ripploend tuleb lihtsalt teha nii pikaks, et ta mahutaks kõiki valikud. 90% olemasolevatest ripploenditest ei kasuta isegi allpool asuvat vaba ruumi ära, see on lausa häbiasi. Kui ekraani alumise servani pole piisavalt ruumi, peaks ripploend kasvama ülespoole, kuni ta mahutab kõik valikud, isegi kui ta peaks selleks ulatuma füüsilise ekraani ülemisest servast alumisse. Ja kui kõik valikud ikkagi ära ei mahu, las see loend kerib end automaatselt, kui hiir servale läheneb, et vabastada vaene kasutaja kerimisribaga mässamisest.

Samuti pole vaja sundida mind klõpsama tibatillukesel noolenupul tekstiboksist paremal; lase mul klõpsata kus iganes. See suurendab klõpsamise sihtmärki umbes kümme korda ja teeb selle hiirega tabamise palju hõlpsamaks.

Vaatame veel üht hiirega seotud probleemi: tekstibokse. Sa oled võib-olla märganud, et peaaegu kõik Macintoshi tekstiboksid kasutavad rasvast laia fonti
nimega Chicago, mis näeb välja üpris inetu ja ajab kujundajaid marru. Kunstilised kujundajad (vastupidiselt UI kujundajatele)  on õppinud, et peenikesed muutlaiusega fondid on maitsekamad, näevad paremad välja ning neid on kergem lugeda. Kõik see on tõsi. Aga kunstilised kujundajad on oma oskused omandanud paberil, mitte ekraanil. Kui sul on vaja teksti redigeerida, omandab fikseeritud font olulise eelise muutlaiusega fondiga võrreldes: peenikesi kitsaid tähti nagu "1" ja "i" on kergem eristada ning märkida. Ma sain selle õppetunni, kui vaatasin 60-aastast meest, kes kasutushõlpsuse testis püüdis vaevaliselt redigeerida oma tänava nime, milleks oli Fillmore Street või siis midagi sellesarnast. Me kasutasime 8-punktist Ariali, nii et tekstiboks nägi välja selline:

Pane tähele, et I ja L-id on sõna otseses mõttes ühe pikseli laiused. Väike I ja väike L erinevad täpselt ühe pikseli võrra. (Samuti on väiketähtedes peaaegu võimatu näha erinevust "RN" ja "M" vahel, nii et selles tekstiboksis võiks sama hästi olla kirjas Fillrnore.)

Väga vähesed inimesed märkaksid, et nad on kogemata sisestanud Flilmore või Fiilmore või Fillrnore, ja isegi sel juhul näeksid nad põrgumoodi vaeva, et märkida hiirega vigane täht ja seda parandada. Üksikute tähtede valimine on raske isegi vilkuva tekstikursoriga, mis on kaks pikselit lai.Võrdle, kuipalju kergem oleks see olnud, kui oleksime kasutanud laia rasvast fonti (siinkohal näitena toodud Courier Bold):

Kena, see võtab rohkem ruumi ja sinu kujundajate arvates ei näe eriti tasemel välja. Aga lepi sellega! Seda on palju kergem kasutada; see lihtsalt tundub parem, sest kasutaja saab trükkides terava, selge teksti, mida on lihtsam redigeerida.

Programmeerijate seas on levinud selline mõttemall: eksisteerib ainult kolm arvu: 0, 1 ja n. Kui n on lubatud, siis on kõik n-i väärtused võrdselt võimalikud. See mõttemall tuleb (tõenäoliselt õigest) uskumusest, et koodis ei tohiks esineda mingeid konstante peale 0 ja 1. (Muid konstante peale 0 ja 1 kutsutakse "maagilisteks arvudeks". Ma parem ei hakkagi seda geštalti rohkem kommenteerima.)

Nii näiteks kalduvad programmeerijad arvama, et kui programm lubab avada korraga mitu dokumenti, siis peab ta lubama avada korraga lõpmata palju dokumente (niipalju kui parajasti mällu mahub), või siis vähemalt 2^32 - ainus maagiline arv, mida programmeerijad tunnustavad. Programmeerija kaldub põlglikult suhtuma programmi, mis võimaldab avada 20 dokumenti. Mis 20? See pole isegi kahe aste!

Võrdvõimalike n-de teine efekt on see, et programmeerijad kalduvad arvama, et kui kasutajatel on lubatud aknaid suurendada ja nihutada, siis peaks neil olema täielik vabadus akende paigutamisel, kuni viimase pikselini välja. On ju akna paigutamine kahe pikseli kaugusele ekraani servast "sama tõenäoline" kui akna paigutamine täpselt ekraani serva.

See ei ole siiski nii. On olemas palju häid põhjusi akna paigutamiseks täpselt ekraani serva (see ju kasutab ekraani kasuliku pinna maksimaalselt ära), kuid pole ühtki põhjust akna paigutamiseks kahe pikseli kaugusele servast. Niisiis on 0 tegelikkuses palju tõenäolisem kui 2.

WinAmpi programeerijad Nullsoftis on suutnud seda, meid ülejäänuid juba terve aastakümne kammitsenud, mõttekrampi vältida. Kui lohistada aken mõne pikseli kaugusele ekraani servast, siis haakub see automaatselt täpselt ekraani serva. See on tõenäoliselt täpselt see, mida sa tahtsid, sest 0 on niivõrd palju tõenäolisem kui 2. (Juno peaaknal on sarnane omadus: see on minu teada ainus rakendus, mis on ekraanil "kasti suletud" ja mida ei saa seetõttu serva taha lohistada.)

Sa kaotad veidi paindlikkuses, kuid vastukaaluks saad kasutajaliidese, mis tunnistab, et hiire täpne kontrollimine on raske ning ei vaeva sellega kasutajat. See uuendus (mida peaksid kasutama kõik programmid) kergendab mõistlikul moel akende haldamist. Uuri oma kasutajaliidest põhjalikult ja lase meil kõigil end vabalt tunda. Eelda, et me oleme gorillad või ehk arukad orangutangid ning et meil tõesti on hiirega raskusi.