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 2: Intelege asteaptarile lor


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

Cand utilizatori noi incep sa foloseasca un program, acestia nu vin fara o experienta anterioara. Ei au unele perspective asupra modului in care cred ei ca programul va functiona. Daca au mai folosit inainte un software similar, vor crede ca va functiona ca celalalt software. Daca au folosit inainte  vre-un  software, vor crede ca software-ul tau se conformeaza unor oarecare conventii obisnuite. S-ar putea sa aiba presupuneri inteligente despre cum UI-ul va functiona. Acesta este numit modelul utilizator: este interpretarea lor mintala a ceea ce programul face pentru ei.

Programul, de asemenea, are un "model mental", doar ca acesta este codat in biti si va fi executat cu religiozitate de CPU. Acesta este numit modelul program , si este Legea. Dupa cum am invatat in  Capitolul Unu, daca modelul program este similar cu modelul utilizator, ai o interfata utilizator de succes.

Hai sa luam un exemplu. In Microsoft Word (si in majoritatea procesoarelor de text), cand introduci o imagine in document, imaginea este de fapt inglobata in acelasi fisier cu documentul insasi. Poti crea imaginea, o "tragi" in document, apoi  stergi fisierul original imagine , dar imaginea tot va ramane in document.

Ei, HTML-ul nu te lasa sa faci asta. Documentele HTML trebuie sa isi pastreze imaginile din ele intr-un fisier separat. Daca iei un utilizator care este obisnuit cu procesoarele de text, si nu stie nimic despre HTML, si il asezi in fata unui editor WYSIWYG HTML dragut ca FrontPage-ul, aproape sigur vor crede ca imaginea va fi pastrata in fisier. Numeste asta  inertia modelului utilizator, daca doresti.

Deci avem un nefericit conflict al modelului utilizator (imaginea va fi inglobata) cu modelul program (imaginea trebuie sa fie intr-un fisier separat), si UI-ul e obligat sa cauzeze probleme.

Daca proiectezi un program cum ar fi FrontPage-ul, tocmai ai descoperit prima ta problema de UI. Nu poti schimba HTML-ul. La ceva trebuie renuntat pentru a aduce la acelasi nivel modelul program cu modelul utilizator.

Ai doua optiuni. Poti incerca sa schimbi modelul utilizator. Aceasta se dovedeste a fi remarcabil de greu. Ai putea explica lucruri in manual, dar toata lumea stie ca utilizatorii nu citesc manuale, si probabil nici nu ar trebui sa le citeasca. Poti afisa un mic dialog box in care sa explici ca fisierul imagine nu va fi inglobat, dar asta genereaza doua probleme: e enervanta pentru utilizatorii avansati, si utilizatorii nu citesc nici mesajele din dialog box-uri (vom vorbi mai mult despre asta in Capitolul Sase). 

Deci, daca muntele nu vine la Mohamed ... cea mai buna alegere a ta va fi aproape intodeauna sa schimbi modelul program, nu modelul utilizator. Poate cand insereaza imaginea, ai putea face o copie a imaginii intr-un subdirector sub fisierul document, astfel incat cel putin poti respecta idea utilizatorului ca imaginea este copiata (iar originalul poate fi sters in siguranta).

Cum stiu eu care e modelul utilizator?

Asta se dovedeste a fi relativ usor. Intreaba-i doar! Alege la intamplare cinci oameni din birou, sau prieteni, sau din familie si spune-le in termeni generali ce face programul tau("e un program pentru creare de pagini web"). Apoi descrie situatia: "Ai o pagina de web la care lucrezi, si un fisier cu o imagine numit Imagine.JPG. Inserezi imaginea in pagina ta web." Apoi intreaba-i cate ceva pentru a incerca sa ghicesti modelul lor utilizator. "Unde a ajuns imaginea? Daca stergi Imagine.JPG, va fi capabila in continuare pagina web sa afiseze imaginea?"

Un prieten de-al meu lucreaza la o aplicatie foto-album. Dupa ce iti introduci pozele, aplicatia iti arata o multime de imagini mici: mici copii a fiecarei poze. Ei, generarea acestor mici copii ia mult timp, in special daca ai o multime de poze, si atunci el doreste sa pastreze imaginile mici pe harddisk undeva astfel incat ele trebuie sa fie generate o singura data. Exista o multime de moduri in care ar putea sa faca asta. Ar putea fi pastrate toate intr-un singur fisier mare numit Imagini_mici . Ar putea fi toate pastrate in fisiere separate, intr-un subdirector numit Imagini_mici. Ar putea fi marcate ca fisiere ascunse in sistemul de operare astfel incat utilizatorii nu stiu nimic despre ele. Prietenul meu a ales o solutie care el a considerat-o cea mai potrivita: a pastrat varianta mica a fiecarei imagini imagine.JPG intr-un nou fisier numit imagine_m.JPG  in acelasi director. Daca ti-ai facut un album cu 30 de poze, cand terminai, existau 60 de fisiere in director incluzand copiile mici ale imaginilor.

Ai putea dezbate saptamani despre avantajele si dezavantajele diferitelor scheme de a pastra imaginile, dar se pare ca exista un mod mai stiintific de a o face. Intreaba doar cativa utilizatori unde cred ei ca imaginile mici vor fi pastrate. Desigur, multi din ei nu vor stii sau nu le va pasa, sau nu s-au gandit la asta, dar daca intrebi mai multi oameni, vei incepe sa vezi ceva consens. Cea mai populara alegere este cel mai bun model utilizator, si depinde de tine sa faci modelul program sa se potriveasca cu el.

Mai departe, trebuie sa iti testezi teoriile. Construieste un model sau un prototip a interfetei utilizator si da catorva oameni niste sarcini de indeplinit. In timp ce lucreaza la sarcini, intreaba-i ce cred ei ca se intampla. Scopul tau e sa iti dai seama la ce se asteapta. Daca sarcina de indeplinit este "insereaza o imagine", si ii vei vedea ca incearca sa traga imaginea in programul tau, iti vei da  seama ca ai face bine sa suporti drag and drop. Daca merg in meniul Insert, iti vei da seama ca ar fi mai bine sa ai o intrare Imagine in meniul Insert. Daca merg la toolbarul Font si inlocuiesc cuvantul "Times New Roman" cu cuvintele "Insereaza imagine", ai gasit o relicva careia nu i-au fost prezentate inca GUI-rile si se asteapta la o interfata linie de comanda.

De cati utilizatori ai nevoie pentru a testa interfata ta? Instinctul ti-ar putea spune "cu cat mai multi, cu atat mai bine", care are sens pentru experimentele stiintifice. Dar instinctul se inseala. Aproape oricine isi castiga painea din teste de utilizabilitate crede ca cinci sau sase utilizatori sunt deajuns. Dupa asta, vei incepea sa vezi aceleasi rezultate din nou si din nou, si orce alti utilizatori aditionali sunt doar o pierdere de vreme.

N-ai nevoie de un laborator de un laborator de utilizabilitate formal, si nu e nevoie sa iti aduci utilizatoriii "de pe strada" -- poti face "teste de utilizabilitate de doi bani" unde doar alegi urmatoarea persoana pe care o vezi si o rogi sa faca un mic test de utilizabilitate. Ai grija sa nu le spui cum sa faca lucrurile. Roaga-i sa gandeasca cu voce tare  si lanseaza intrebari deschise pentru a descoperi modelul lor mintal.

Daca modelul tau program nu e trivial, probabil nu e modelul utilizator.

Cand eram de 6 ani, tata a adus acasa unul din primele calculatoare de buzunar din lume, un HP-35, si a incercat sa ma convinga ca avea un computer inauntru. M-am gandit ca era putin probabil. Toate computerele din Star Trek erau de marimea unei camere si aveau unitati mari de banda magnetica. M-am gandit ca era doar o corelatie desteapta intre taste si elementele individuale ale afisajului LED care se intampla sa produca rezultate matematice corecte. (Hei, aveam 6 ani!).

O importanta regula empirica este ca modelele utilizator nu sunt foarte complexe. Cand oamenii trebuie sa ghiceasca cum va functiona un program, tind mai degraba sa ghiceasca lucruri simple decat lucruri complicate. 

Aseaza-te la un Macintosh. Deschide doua spreadsheeturi Excel si un document Word. Aproape orice utilizator novice va presupune ca ferestrele sunt independente. Ele arata independente:

Modelul utilizator zice ca facand click pe Spreadsheet 1 va aduce acea fereastra in fata. Ce se intampla  de fapt e ca Spreadsheet 2 va veni in fata, o surpriza frustranta pentru aproape oricine:

Dupa cum se vede, modelul program al Microsoft Excel zice ca "ai aceste sheet-uri invizibile, una pentru fiecare aplicatie iar ferestrele sunt 'lipite' de acele sheet-uri invizibile. Cand aduci Excel-ul in prim plan, toate celelalte ferestre din excel se vor muta de asemenea in fata."

Coreeeect. Sheet-uri invizibile. Ce sanse sunt ca modelul utilizator sa includa conceptul de sheet-uri invizibile? Probabil cam zero. Astfel, utilizatorii noi vor fi surprinsi de acest comportament.

Un alt exemplu din lumea Microsoft Windows este combinatia de taste Alt+Tab care comuta la "urmatoarea" fereastra. Majoritatea utilizatorilor vor presupune probabil ca aceasta doar comuta intre toate ferestrele disponibile. Daca ai ferestrele A, B, si C, cu A activa, Alt+Tab ar trebui sa te mute in B. Alt+Tab inca o data te va muta in C. Ce se intapla de fapt, este ca al doilea Alt+Tab te muta inapoi in A. Singurul mod de a ajunge in C este sa tii apasat Alt si sa apesi Tab de doua ori. E un mod dragut de a comuta intre doua aplicatii, dar aproape nimeni nu isi da seama, pentru ca e un model putin mai complicat decat modelul roteste-intre-ferestrele-disponibile.

E si asa destul de greu sa faci modelul program conform cu modelulul utilizator, cand modelele sunt simple. Cand modelele devin complexe, este chiar mai putin probabil. Deci alege cel mai simplu model posibil.



> Capitolul 3

Acest articol a aparut initial in engleza cu numele User Interface Design for Programmers Chapter 2: Figuring Out What They Expected  

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