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 9: Procesul de proiectare al unui produs


De Joel Spolsky
Tradus de catre Cosmin Calian
9 Mai, 2000



Am vorbit despre principiile unui bun design, dar principiile doar iti dau o cale de a evalua si a imbunatati un design existent. Dar... cum iti dai seama ce design ar trebui sa fie in primul rand? Multa lume scrie vaste documentatii functionale a tuturor caracteristicilor la care s-au gandit. Apoi o proiecteaza pe fiecare, si o agata de un element din meniu (sau pagina web). Cand au terminat, programul (sau site-ul web) are toata functionalitatea pe care au dorit-o, dar nu are cursivitatea potrivita. Lumea se aseaza jos si nu stiu ce face, si nu stiu cum sa finalizeze ceea ce doresc.

Solutia Microsoft la aceasta este ceva numit Planificarea Bazata pe  Activitate. (Din cate stiu eu, acest concept a fost inventat de Mike Conte din echipa Excel, care s-a plictisit de asta si a ales o a doua cariera ca pilot de curse de masini). Idea esentiala e sa intelegi activitatea care o face utilizatorul, si sa te concentrezi in a usura realizarea acelei activitati. Asta este cel mai bine ilustrata cu un exemplu.

Te-ai decis sa faci un site web care permite oamenilor sa creeze felicitari. Folosind o abordare oarecum naiva, ai putea veni cu o lista de caracteristici ca aceasta:

1. Adauga text la felicitare
2. Adauga imagine la felicitare
3. Ia felicitare preproiectata din biblioteca
4. Trimite felicitare:
           a. Folosind emailul
           b. Prin tiparirea ei 

Din lipsa oricarui alt mod mai bun de gandire asupra problemei, aceasta s-ar putea transforma intr-o interfata utilizator tipica Macintosh, din circa-1984: un program care incepe cu o felicitare goala, cu elemente de meniu pentru adaugare text, imagini, incarcare felicitari din biblioteca, si trimitere felicitari. Si apoi ce va trebui sa faca utilizatorul este sa se aseze si sa se uite prin meniuri, incercand sa inteleaga toate comenzile disponibile, si apoi sa-si faca propria sinteza despre cum sa puna la un loc aceste comenzi atomice pentru a crea o felicitare.

Ei, planificarea bazata pe activitate zice e nevoie sa propui  o lista de activitati pe care utilizatorii le-ar putea face. Deci, vorbesti cu potentialii tai utilizatori, si propui aceasta lista "top trei":

  1. Felicitare de zi de nastere
  2. Invitatie la petrecere 
  3. Felicitare aniversara 

Acum, in loc sa te gandesti la programul tau ca un programator (in termeni a ce caracteristici e necesar sa ai pentru a crea o felicitare), te gandesti la el ca utilizatorul, in termeni de, ce activitati face utilizatorul, specific:

  1. Trimitere felicitare de zi de nastere
  2. Planificare petrecere, si invitare oameni la ea 
  3. Trimitere felicitare aniversara 

Dintr-o data, tot felul de idei se vor imbulzi in capul tau. In loc de a incepe cu o felicitare goala, ai putea incepe cu un meniu ca acesta:

Ce doresti sa faci?
  • Trimite o felicitare de zi de nastere 
  • Trimite o felicitare aniversara 
  • Trimite o invitatie la petrecere 
  • Incepe cu o felicitare goala 

Dintr-o data utilizatorii vor gasi ca e mult mai usor sa inceapa sa foloseasca programul tau, fara a mai fi nevoiti sa caute prin meniuri, din moment ce programul tau aproape ii va indruma prin pasi pentru a duce la bun sfarsit activitatea. (Exista riscul ca daca nu ai ales activitatile corect, vei nemultumi sau deruta utilizatori care ar fi putut incepe sa foloseasca programul tau, sa zicem, pentru a trimite o felicitare de Hanukah, dar nu vad asta ca o optiune. Deci fi atent in alegerea activitatilor care acopera majoritatea pietei care vrei sa o tintesti.)

Doar privind lista noastra de trei activitati iti vin in minte cateva functionalitati grozave pe care s-ar putea sa vrei sa le adaugi. De exemplu, daca trimiti o felicitare de zi de nastere sau aniversara, ai putea vrea sa iti fie amintit la anul sa trimiti o felicitare la aceeasi persoana... deci ai putea adauga un checkbox care spune "aminteste-mi la anul". Si o invitatie la petrecere are nevoie de confirmare RSVP (Répondez s'il vous plait), astfel ai putea adauga o functionalitate care iti permite sa colectezi electronic de la oameni confirmarile RSVP. Amandoua din aceste idei de functionalitati rezulta din examinarea  activitatii care utilizatorii o executa in loc de examinarea de functionalitati in aplicatie.

Acest exemplu este trivial; pentru orice aplicatie serioasa, recompensele planificarii bazate pe activitate sunt chiar mai mari. Cand proiectezi un program de la zero, tu deja ai o viziune a ce activitati vor desfasura utilizatorii tai. Identificarea acestei viziuni nu e grea deloc, nu ia aproape nici un efort pentru a face putin brainstorming cu colegii, a scrie o lista cu activitati potentiale, si apoi a decide pe care doresti sa te concentrezi. Dar fortandu-te sa enumeri aceste activitati pe hartie iti va ajuta enorm designul general. 

Planificarea bazata pe activitate este chiar mai importanta cand lucrezi la versiunea doi a unui produs pe care lumea deja il foloseste. Aici, ar putea fi o chestiune a observa o mostra de clienti pentru a vedea la ce folosesc program tau. 

In zilele lui Excel 1.0 pana la 4.0, majoritatea lumii de la Microsoft credea ca majoritatea utilizatorilor obisnuiti facea scenarii financiare ce-ar fi-daca, unde faci lucruri cum ar fi sa schimbi rata de inflatie pentru a vedea cum asta iti avecteaza profitabilitatea. 

Cand proiectam Excel 5.0, prima versiune majora care folosit proiectarea bazata pe activitate, a trebuit doar sa observam cam cinci clienti folosind produsul inainte sa ne dam seama ca un numar enorm de oameni foloseste Excel-ul doar pentru a tine liste. Ei nu introduc nici o formula si nu fac nici un calcul! Noi nici macar nu ne-am gandit la asta inainte. Tinutul de liste s-a dovedit a fi de departe mai popular decat orice alta activitate cu Excel-ul. Si asta ne-a facut sa inventam o intreaga gramada de functionalitati care facea mai usor tinutul de liste: sortare mai usoara, introducere de date automata, functionalitatea AutoFilter care te ajuta sa vezi o portiune din lista ta, si functionalitati multi-utilizator care permiteau catorva oameni sa lucreze pe aceeasi lista in acelasi timp, in timp ce Excel-ul automat ii reconciliaza pe toti.

In timp ce Excel 5 era proiectat, Lotus lansase o "noua paradigma" de spreadsheet numit Improv. Conform declaratiilor de presa, Improv era o cu totul noua generatie de  spreadsheet, care urma sa spulbere orice existase inainte. Din diferite stranii motive, Improv a fost mai intai disponibil pe NeXT, care cu siguranta nu a ajutat vanzarile, dar o gramada de oameni destepti au crezut ca Improv va fi fata de NeXT ceea ce VisiCalc a fost fata de Apple II: va fi aplicatia criminala care face oamenii sa mearga si sa cumpere tot hardware-ul nou doar pentru a rula un program.

Desigur, Improv este acum o nota de subsol in istorie. Cauta despre el pe web, si singurele linkuri care le vei gasi sunt de la acei manageri de depozitare foarte supra-organizati care, din oarece motiv, au facut un site web cu un inventar a tuturor lucrurilor prafuite pe care le au.

De ce? Deoarece in Improv, era aproape imposibil de facut liste. Designerii lui Improv au crezut ca lumea foloseste spreadsheet-uri pentru a crea complicate modele financiare multi-dimensionale. Pana la urma, daca intrebau lumea, ar fi descoperit ca facutul listelor era mult frecvent decat modelele financiare multi-dimensionale, iar in Improv, facutul listelor era o absoluta  corvoada, daca nu chiar imposibil.

Deci planificarea bazata pe activitate este de ajutor in versiunea initiala a aplicatiei tale, unde trebuie sa faci presupuneri despre ce doresc utilizatorii sa faca, dar este si mai utila cand planifici upgrade-ul, deoarece intelegi ce fac clientii tai.

Alt exemplu, de pe web, este evolutia lui deja.com , care a inceput ca un enorm, index cautabil al Usenet-ului numit dejanews. Interfata originala practic avea un edit box si spunea "cauta in Usenet blah," si asta era totul. In 1999 putina planificare bazata pe activitate a aratat ca o activitate utilizator frecventa era informarea despre un produs sau serviciu, de tipul "ce masina ar trebui sa cumpar". Deja a fost complet reorganizat, iar azi, este mai mult un serviciu de cautare opinii despre un produs: functionalitatea de cautare a Usenet-ului este aproape complet ascunsa. Asta a enervat un mic grup de utilizatori care foloseau site-ul pentru a cauta daca placa lor video Matrox mergea cu Redhat Linux 5.1, dar a multumit mult mai numeroasa populatie de utilizatori care doar vroiau sa cumpere cea mai buna camera digitala.

Celalalt lucru grozav despre planificarea bazata pe activitate este ca iti permite sa faci o lista a ce functionalitati sa nu faci. Cand creezi orice fel de software, realitatea este ca vei sugera de trei ori mai multe functionalitati decat ai timp sa faci. Si una din cele mai bune cai de a decide ce functionalitati sa  implementezi, si ce functionalitati sa lasi afara, este de a evalua ce functionalitati suporta cele mai importante activitati ale utilizatorului.

Utilizatori imaginari.

Cei mai buni designeri UI din industrie sunt cu totii de acord asupra unui lucru: trebuie sa inventezi si sa descrii cativa utilizatori imaginari inainte sa iti proiecta UI-ul. Poate iti amintesti, in  introducerea la aceasta carte, am introdus un utilizator imaginar Petrica:

Petrica este un contabil pentru o editura tehnica, care a folosit Windows-ul timp de sase ani la birou si putin acasa. Este destul de competent si tehnic. Isi instaleaza singur programele; citeste PC Magazine, si chiar a programat cateva macrouri Word pentru a ajuta secretarele din biroul lui sa trimita facturi. Isi pune modem de cablu acasa. Petrica nu a folosit niciodata un Macintosh. "Sunt prea scumpe," iti va spune. "Poti sa-ti iei un PC la 700 Mhz cu 128 Megi de RAM cu pretul unui..." OK, Petrica. Intelegem.

Cand citesti asta, aproape iti poti imagina un utilizator. As fi putut de asemenea inventa un cu totul alt tip de utilizator:

Patricia este o profesoara de engleza care a scris cateva carti de poezie bine primite. A inceput sa foloseasca calculatoarele pentru procesare text din 1980, cu toate ca singurele doua programe pe care le-a folosit vreodata sunt Nota Bene (un antic procesor de text academic) si Microsoft Word. Nu vrea sa piarda vremea invatand teoria despre cum functioneaza calculatoarele, si tinde sa isi pastreze toate documentele ei in orice director se nimereste, asta daca nu stiai despre directoare.

Evident, a proiecta software pentru Petrica este destul de diferit fata de a proiecta software pentru Patricia, care in schimb e destul de diferita de Mike, un tanar de 16 ani care ruleaza Linux acasa, vorbeste ore intregi pe IRC, si nu foloseste software "Micro$oft".

Cand inventezi acesti utilizatori, a te gandi daca designul tau este potrivit devine mult mai usor. De exemplu, o multime de programatori tind sa supraestimeze abilitatea utilizatorului tipic de a intelege lucrurile. De cate ori scriu ceva despre interfetele linie de comanda ca fiind greu de folosit, primesc inevitabila contraofensiva de emailuri zicand ca interfetele linie de comanda sunt ultra-potente pentru ca poti face lucruri cum ar fi 'gunzip foo.tar.gz | tar xvf -'. Dar deindata ce trebuie sa te gandesti la a o pune pe Patricia sa tasteze "gunzip..." devine evident ca acel tip de interfata pur si simplu nu o sa ii serveasca niciodata nevoilor ei. A te gandi la o persoana "reala"  iti da empatia de care ai nevoie pentru a crea o functionalitate care serveste nevoii acelei persoane. (Bineinteles, daca faci software de backup in Linux pentru sysadmini avansati, e nevoie sa inventezi un personaj cum ar fi "Frank" care refuza sa atinga Windows-ul, pe care il pomeneste doar ca un "sistem de operare" in ghilimele, foloseste propria lui versiune modificata personal de tcsh, si ruleaza X11-le acoperit intreaga zi cu patru xterm-uri. Si cam 11 xperfs-uri.)

Pentru a rezuma, proiectarea unui software bun iti ia cam sase pasi:

  1. Inventeaza niste utilizatori 

  2. Identifica activitatile importante

  3. Identifica modelul utilizator  -- cum se va asteapta utilizatorul sa finalizeze acele activitati

  4. Traseaza prima schita a designului

  5. Itereaza asupra designului tau din nou si din nou, facandu-l mai usor si mai usor, pana cand e compatibil cu abilitatile utilizatorilor tai imaginari

  6. Urmareste utilizatori reali incercand sa foloseasca software-ul tau. Observa zonele unde lumea are dificultati, care probabil iti evidentiaza zonele unde modelul program nu se potriveste cu modelul utilizator.

UI-ul bun vinde software-ul, dar in acelasi timp face oamenii fericiti, pentru ca oamenii sunt fericiti cand finalizeaza sarcina care au dorit sa o finalizeze. De aceea designul UI este un domeniu care iti ofera o extrema satisfactie. Unde in alta parte vei avea o sansa sa faci milioane de oameni putintel mai fericiti?





Acest articol a aparut initial in engleza cu numele User Interface Design for Programmers Chapter 9: The Process of Designing a Product  

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