Joel on Software

Joel on Software Joel despre Software

 

Designul interfetei utilizator pentru programatori
Capitolul 1
Capitolul 2
Capitolul 3
Capitolul 4
Capitolul 5
Capitolul 6
Capitolul 7
Capitolul 8
Capitolul 9

Alte articole din "Joel on Software" in Romaneste

Alte articole din "Joel on Software" in engleza

Scrie-i autorului (numai in engleza)

 

Designul interfetei utilizator pentru programatori
Capitolul 6: Proiectand pentru oameni care au lucruri mai bune de facut cu viata lor


De Joel Spolsky
Tradus de catre Cosmin Calian
26 Aprilie, 2000

Cand proiectezi interfete utilizator, e o buna idee sa ai doua principii in minte:

  1. Utilizatorii nu au manualul, si daca l-ar avea, nu l-ar citi.
  2. De fapt, utilizatorii nu pot citi nimic, si daca ar putea, nu ar vrea.

Aceasta nu este, de fapt, realitatea, dar ar trebui sa actionezi ca si cum ar fi realitatea, caci iti va face programul mai simplu si prietenos. Proiectand cu aceste idei in minte, se cheama  respectarea utilizatorului, care inseamna sa nu ai mult respect fata de utilizator. Confuz? Sa iti explic.

Ce inseamna sa faci ceva usor de folosit ? O modalitate de a evalua asta este sa vezi ce procentaj de utilizatori normali sunt capabili sa termine sarcini intr-un interval dat de timp. De exemplu, sa presupunem ca scopul programului tau este sa permita oamenilor sa converteasca fotografii de camera digitala intr-un album web foto. Daca asezi un grup de utilizatori medii in fata programului tau si le ceri tuturor sa execute aceasta sarcina, atunci cu cat mai utilizabil e programul tau, cu atat mai ridicat va fi procentajul de utilizatori care vor fi capabili sa creeze cu succes un album web foto. Luand-o stiintific, imagineaza-ti 100 utilizatori normali. Ei nu sunt neaparat familiarizati cu calculatoarele. Au o multime de diverse talente, dar unii din ei  clar nu au talente in domeniul calculatoarelor. Unii din ei sunt neatenti in timp ce incearca sa iti foloseasca programul. Telefonul suna. CE? Copilul plange. CE? Si pisica tot sare pe birou si se joaca cu mouse-ul. NU TE POT AUZI!

Ei, chiar fara a trece prin acest experiment, pot spune cu destula incredere ca unii dintre utilizatori pur si simplu vor esua in a duce la bun sfarsit sarcina, sau le va lua o extraordinara cantitate de timp pentru a o face. Nu vreau sa spun ca acesti utilizatori sunt prosti . Dimpotriva, sunt probabil extrem de inteligenti, sau poate sunt atleti desavarsiti, dar vis-à-vis de programul tau, nu isi folosesc toate capacitatile motorii si toti neuronii la utilizarea lui. Obtii doar cam 30% din atentia lor, deci trebuie sa te descurci cu un utilizator care, din punctul de vedere al calculatorului, nu pare sa fie intreg la minte.

Utilizatorii nu citesc manualul.

In primul rand, ei de fapt nu au manualul. S-ar putea sa nu existe  un manual. Daca exista unul, s-ar putea ca utilizatorul sa nu il aiba, din toate felurile de motive logice: sunt in avion; folosesc o versiune demo downloadata de pe site-ul tau web; sunt acasa iar manualul este la servici; departamentul lor de informatica nu le-a dat niciodata manualul. Chiar daca au manualul, sincer, nu il vor citi doar daca chiar nu au de ales. Cu  foarte putine exceptii, utilizatorii nu vor imbratisa manualul tau si nu il vor rasfoi inainte de a inceape sa foloseasca software-ul tau. In general, utilizatorii tai incearca sa faca ceva, si vad citirea manualului ca pe o pierdere de vreme, sau macar cel putin, ca o diversiune care ii impiedica sa isi termine treaba.

Insasi faptul ca citesti cartea asta te situeaza intr-un grup de oameni de elita extrem de culti. Da, stiu, oamenii care folosesc calculatoarele sunt in mare masura capabili sa citeasca, dar iti garantez ca un mare procentaj din ei gasesc cititul o corvoada. Limba in care e scris manualul s-ar putea sa nu fie cea nativa, si s-ar putea sa nu fie absolut fluenti. S-ar putea sa fie copii! Ei pot descifra manualul daca chiar trebuie, dar sigur nu-l vor citi daca nu e nevoie. Utilizatorii citesc manualul doar-la-timp, pe o principiul strict nevoie-de-stiut.

Consecinta tuturor acestora, este ca probabil nu o sa ai de ales decat sa proiectezi software-ul tau astfel incat in primul rand sa nu aiba nevoie de un manual. Singura exceptie care imi trece prin minte este daca utilizatorii tai nu au nici o cunostinta in domeniu -- nu chiar inteleg pentru ce este menit programul, dar stiu ca ar ar fi bine sa il invete. Un foarte bun exemplu al acesteia este extra cunoscutul program de contabilitate pentru mici afaceri QuickBooks al Intuit. Multi din oamenii care folosesc acest program sunt proprietari de mici afaceri care pur si simplu nu au idee ce implica contabilitatea. Manualul pentru QuickBooks presupune asta, si presupune ca va trebui sa invete oamenii principiile de baza in contabilitate. Altfel nu se poate. Totusi, daca stii contabilitate, QuickBooks e usor de folosit fara manual.

De fapt, utilizatorii nu citesc nimic

Asta ar putea suna cam neplacut, dar vei vedea, cand faci teste de utilizabilitate, ca exista destul de putin utilizatori care citesc cuvintele pe care le afisezi pe ecran. Daca apare un error box de orice fel, pur si simplu nu il vor citi. Asta ar putea fi nelinistitor pentru tine ca programator, pentru ca te imaginezi pe tine insuti avand un dialog cu utilizatorul. Hei, utilizatorule! Nu poti deschide fisierul acela, nu suportam formatul acela de fisier! Totusi, experienta arata ca, cu cat mai multe cuvinte pui in acel dialog box, cu atat mai putini oameni il vor citi de fapt.

Faptul ca utilizatorii nu citesc manualul a determinat multi designeri software sa presupuna ca vor trebui sa educe utilizatorii descriind lucrurile pe masura ce ele se desfasoara. Vezi asta peste tot in programe. In principiu, e OK, dar in realitate, aversiunea oamenilor fata de citit aproape intodeauna iti va crea probleme. Designerii UI experientati efectiv incearca sa minimizeze numarul de cuvinte in dialoguri pentru a spori sansele ca dialogul sa fie citit. Cand am lucrat la Juno, oamenii de la UI intelegeau acest principiu si incercau sa scrie text scurt, clar si simplu. Din nefericire, CEO-ul companiei era licentiat in engleza la un colegiu Ivy League (grup de colegii din nord-estul Statelor Unite cu o buna reputatie); nu avea pregatire in designul UI sau in ingineria software, dar sigur se credea bun editor de proza. Astfel, a respins formularea facuta de designeri UI profesionisti si a adaugat o gramada din limbuteniile lui. Un dialog tipic in Juno arata ca acesta:

Compara aceea cu dialogul echivalent din Windows:

Intuitiv, ai putea crede ca versiunea Juno, cu instructiuni de 80 cuvinte, ar fi "superioara" (i.e., mai usor de folosit) decat versiunea Windows, cu instructiuni de 5 cuvinte. In realitate, cand faci teste de utilizabilitate pe acest gen de lucru, vei afla ca

  • utilizatorii avansati sar peste instructiuni. Ei presupun ca stiu cum sa foloseasca lucrurile si nu au timp sa citeasca instructiuni complicate
  • majoritatea utilizatorilor novici sar peste instructiuni. Nu le place sa citeasca prea mult si spera ca setarile implicite vor fi OK
  • restul utilizatorilor novici care o fac, cu seriozitate, incearca sa citeasca instructiunile (dintre care unii le citesc doar pentru ca e un test de utilizabilitate si se simt obligati)  sunt deseori derutati de numarul extrem de cuvinte si concepte. Deci chiar daca erau destul de increzatori ca vor fi capabili sa utilizeze dialogul cand a aparut prima data, instructiunile de fapt i-a derutat si mai mult.

Ei, Juno era evident micro-administrata inafara limitelor bunului simt. Mai relevant, daca esti un licentiat in engleza la Columbia, atunci ai cu totul alt nivel de pregatire decat omul obisnuit, si ar trebui sa fi foarte atent cu redactarea dialogurilor care iti par utile. Scurteaza-le, fa-le mai usor de inteles, simplifica, scapa de explicatiile complicate din paranteze, si testeaza utilizabilitatea. Dar nu scrie lucruri care arata ca biografii de facultate din Ivy League. Chiar adaugarea cuvantului "va rog" la un dialog, care ar putea parea util si politicos, va incetini utilizatorii: volumul crescut al redactarii va micsora, printr-un procentaj semnificativ, numarul oamenilor care citesc textul.

Alta idee importanta este ca multi oameni sunt intimidati de calculatoare. Probabil stii asta, asa-i? Dar s-ar putea sa nu iti dai seama de implicatiile acesteia. Ma uitam cum o prietena incerca sa iasa din Juno. Dintr-un oarecare motiv chiar avea putine dificultati. Am observat ca la incercarea de a iesi din Juno, urmatorul dialog apare:

Ea apasa No , si era cam surprinsa ca Juno nu se inchidea. Insasi faptul ca Juno punea la indoiala alegerea ei o faceau imediat sa presupuna ca facea ceva gresit. De obicei, cand programele te cer confirmarea unei comenzi, este pentru ca esti pe cale de a face ceva care ai putea regreta. Ea a presupus ca daca calculatorul punea la indoiala judecata ei, atunci calculatorul trebuie sa fi avut dreptate, deoarece, pana la urma, calculatoarele sunt calculatoare iar ea era doar un om, si astfel apasa "No."

E prea mult sa ceri oamenilor sa citeasca 11 cuvinte nenorocite? Eh, aparent. In primul rand, cum iesirea din Juno nu are efecte de stergere, Juno ar fi trebuit sa iasa fara a astepta confirmarea, ca toate celelalte programe GUI care exista. Dar chiar daca esti convins ca e crucial ca oamenii sa confirme inainte de a iesi, ai putea-o face in doua cuvinte in loc de 11:

Fara absolut nenecesarul "multumesc" si generatorul de remuscari "sunteti sigur?", acest dialog este mult mai putin probabil sa creeze probleme. Utilizatorii sigur vor citi cele doua cuvinte, vor zice "aaa, clar!" programului, si vor izbi tasta Yes.

Sigur, dialogul de confirmare a iesirii din Juno incurca cativa oameni, zici tu, dar e asta o asa mare problema? Oricine va reusi pana la urma sa iasa din program. Dar in asta consta diferenta intre un program care e posibil de folosit si un program care e usor de folosit. Chiar si utilizatorii destepti, experimentati, avansati vor aprecia lucrurile pe care le faci pentru a fi mai usor pentru utilizatorii neatenti, neexperimentati, incepatori. Cazile de baie din hoteluri au bare mari prinse de perete. Sunt puse doar pentru a ajuta oamenii cu disabilitati, dar toata lumea le foloseste oricum pentru a iesi din cada. Fac viata mai usoara chiar pentru cei cu o buna forma fizica.

In urmatorul capitol, voi vorbi putin despre mouse. Exact ca utilizatorii care nu citesc/nu vor citi/nu pot citi, unii nu sunt foarte buni la folosirea mouse-ului, deci trebuie sa ii ajuti.



> Capitolul 7

Acest articol a aparut initial in engleza cu numele User Interface Design for Programmers Chapter 6: Designing for People Who Have Better Things To Do With Their Lives  

Joel Spolsky este fondatorul Fog Creek Software, o mica firma de software din New York City. El a absolvit Universitatea Yale si a lucrat ca programator si manager la Microsoft, Viacom si Juno.


Continutul acestor pagini reprezinta opinia unei singure persoane.
Tot continutul Copyright ©1999-2005 de Joel Spolsky. Toate Drepturile Rezervate.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky