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 4: Accesibilitati si metafore


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

Dezvoltarea unei interfete utilizator a carui model program se potriveste cu modelul utilizator nu este usoara. Uneori, utilizatorii tai s-ar putea sa nu  aiba o perspectiva concreta despre modul in care programul functioneaza si despre ceea ce ar trebui sa faca. In aceste cazuri, va trebui sa gasesti cai de a-i oferi utilizatorului indicii despre cum functioneaza ceva. Cu interfetele grafice, o metoda obisnuita de a rezolva aceasta problema este folosirea metaforelor. Dar nu toate metaforele sunt la fel, si este important de inteles de ce metaforele functioneaza, astfel incat, stii daca ai ales una buna.

Cea mai faimoasa metafora este "metafora birou (desktop)" folosita in Windows si Macintosh. Ai aceste mici dosare cu mici fisiere in ele, pe care le poti trage incoace-incolo. Poti trage un fisier dintr-un dosar in altul pentru a-l muta. In masura in care aceasta metafora functioneaza, este deoarece micile imagini de dosare, de fapt le amintesc oamenilor de dosare, ceea ce ii face sa isi dea seama ca pot pune documente in ele.

Aici e un screenshot din Kai's Photo Soap. Poti ghici cum sa faci zoom in? 

 

Nu-i foarte greu. Lupa este o metafora din lumea reala. Oamenii stiu ce ar trebui sa faca. Si nu exista teama ca operatia de zoom schimba de fapt marimea imaginii din fundal, din moment ce aceasta nu-i ceea ce face o lupa.

O metafora, chiar una imperfecta, functioneaza mult mai bine decat cand nu ai una deloc. Iti poti da seama cum sa faci zoom in cu Microsoft Word-ul?

Word-ul are doua lupe minuscule in interfata lor, dar una din ele este pentru butonul de "Print Preview"(dintr-un oarecare motiv), iar cealalta este pentru butonul "Document Map", ce-o fi si acela. Adevaratul mod de a schimba nivelul de zoom aici este cu dropdown box-ul care acum arata "100%". Nu-i o incercare de metafora, deci este mai greu pentru utilizatori sa ghiceasca cum sa faca zoom. Aceasta nu este neaparat un lucru rau; operatia de zoom nu este probabil destul de importanta pentru o aplicatie de procesare text pentru a justifica asa mult spatiu de ecran cat ii da Kai. Dar e mai mult ca sigur ca mai multi utilizatori Kai vor fi capabili sa faca zoom decat utilizatori Word.

O metafora, prost aleasa, este mai rau decat a nu avea deloc o metafora. Iti amintesti servieta din Windows 95? Aceast mic icon dragut ocupa un inch patrat sau cam asa pe desktopul tuturor timp de cativa ani pana cand Microsoft si-a dat seama ca nimeni nu o dorea. Si nimeni nu o dorea, deoarece era o metafora incompleta. Ar fi trebuit sa fie o "servieta", unde pui fisierele de dus acasa. Dar cand luai fisierele acasa, tot trebuia sa le pui pe un floppy disk. Deci, le pui in servieta sau pe un floppy disk? Nu-s sigur. Nu inteleg metafora servieta. Nu am putut-o niciodata face sa mearga.

Accesibilitati

Obiectele bine proiectate isi fac inteles modul de functionare doar uitandu-te la ele. Unele usi au placi mari de metal la nivelul mainii. Singurul lucru care il poti face unei placi de metal este sa o impingi. In cuvintele lui Donald Norman, placa face accesibila impingerea. Alte usi au manere mari, rotunjite care te fac sa vrei sa le tragi. Unele chiar iti sugereaza cum sa iti pui mana pe maner. Manerul face accesibila tragerea. Te face sa doresti sa o tragi.

Alte obiecte nu sunt proiectate asa bine si nu ai putea spune ce ar trebui sa faci. Exemplul quintesential este cutia de CD, care iti cere sa iti plasezi degetele mari doar asa si sa tragi intr-o anumita directie. Nimic din designul cutiei nu ar indica cum ar trebui sa o deschizi. Daca nu stii smecheria, e foarte frustrant, deoarece cutia nu se deschide nicicum.

Cea mai buna cale de a crea o accesibilitate este de a oglindi forma mainii umane in "spatiul negativ". Examineaza indeaproape (excelenta) camera digitala Kodak DC-290, vazuta aici din fata si din spate:

In fata, poti vedea un maner mare din cauciuc care arata ca si cum degetele de la mana ta dreapta s-ar potrivi acolo. Si mai inteligent, in spate, in coltul stanga jos, poti vedea o indentare care arata remarcabil de similar cu o amprenta. Cand iti pui degetul mare stang acolo, degetul aratator stang se curbeaza confortabil in fata camerei, intre lentila si alta protuberanta de cauciuc. Iti da un fel de sentiment de confort care nu l-ai mai simtit de cand iti sugeai degetul mare (si iti curbai degetul aratator in jurul nasului). 

Inginerii de la Kodak doar incearca sa te convinga sa tii camera cu ambele maini, intr-o pozitie care asigura camerei o pozitie mai stabila si chiar impiedica degetele ratacite sa blocheze lentilele din greseala. Toate acest cauciuc nu este functional, unicul lui scop este sa te incurajeze sa tii camera corect.

Interfetele calculator UI bune folosesc de asemenea acesibilitati. Cam acum zece ani, majoritatea butoanelor au devenit "3D". Folosind umbre gri, ele par sa iasa din ecran. Aceasta nu este doar pentru a arata grozav: este important deoarece butoanele 3D fac accesibila impingerea. Arata ca si cum sunt iesite in afara si arata ca si cum modul de a le utiliza este de a face click pe ele. Din nefericire, multe site-uri web in zilele noastre (neconstiente de valoarea accesibilitatilor) au mai degraba butoane care arata grozav decat butoane care arata apasabile; ca urmare, uneori trebuie sa cauti bine pentru a-ti da seama unde sa faci click. Priveste acest banner web:

Butoanele "Go" si "Login" ies inafara si arata ca si cum ai putea face click pe ele. Butoanele Site Map si Help nu arata asa clickabile, de fapt, ele arata exact ca si labelul QUOTES care nu e clickabil.

 Cam acum patru ani, multor ferestre au sa le inmugureasca trei mici creste in coltul dreapta jos. Arata ca si acel gen de lucru pe care cineva l-ar pune pe un comutator pentru a mari aderenta. Face accesibila tragerea. Pur si simplu te implora sa fie tras pentru a intinde fereastra.

In cele din urma, unul din cele mai bune exemple de accesibilitati este faimosul "dialog tabular". Iti amintesti vechiul control panel de pe Mac?

Idea era sa alegi una din icoanele din lista (scroolabila) din stanga. In timp ce faci click pe icon, partea dreapta a ecranului se schimba. Dintr-un oarecare motiv, acest tip de indirectare era incredibil de logic programatorilor care l-au proiectat, dar multi utilizatori nu il intelegeau. Printre altele, lumea rar isi dadea seama cum sa faca scroll la lista pentru a vedea mai mult decat primele 4 control panel-uri. Dar mai critic, majoritatea oamenilor nu intelegea ca exista o conexiune intre icon-uri si dialog. Icon-urile de fapt arata ca si cum sunt una dintre optiuni.

Incepand cam din 1992, aceste interfete au inceput sa dispara, pentru a fi inlocuite cu o noua inventie numita dialoguri tabulare:

Dialogurile tabulare sunt o excelenta accesibilitate. Este intr-adevar evident din aceasta imagine ca ai sase taburi; este intr-adevar evident in ce tab te afli, si este intr-adevar evident cum sa comuti intr-un alt tab. Cand Microsoft a testat intaia oara utilizabilitatea interfat dialog tabular, utilizabilitatea a crescut cam de la 30% (felul vechiului Mac) la 100%. Literalmente fiecare tester a fost capabil sa inteleaga dialogurile tabulare. Dat fiind remarcabilul succes al acestei metafore, si al faptului ca sursa cod pentru dialoguri tabulare este incorporata in Windows si e disponibila aproape gratuit, e o minune ca inca vezi aplicatii care nu profita de ele. Aceste aplicatii sufera de reale probleme de utilizabilitate, pentru ca refuza sa accepte si sa acorde atentie ideilor noi.



> Capitolul 5

Acest articol a aparut initial in engleza cu numele User Interface Design for Programmers Chapter 4: Affordances and Metaphors  

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