PROTEJAREA UTILIZATORULUI - INTERFETE

PROTEJAREA UTILIZATORULUI - INTERFETE

Sfârsitul erorilor

Eliminarea casetei de mesaj de eroare

Eliminarea mesajelor de eroare nu implica doar respingerea codului care în mod curent arata caseta de mesaj de eroare lasând însa ca programul sa crape daca problema apare. Programele noastre ar trebui modificate astfel încât sa nu fie susceptibile la aceasta problema. Mesajele de eroare nu pot fi smulse din program pur si simplu. Trebuie înlocuita metoda mesaj de eroare pentru protectia soft-ului, printr-un soft mai atent, mai amabil, mai robust de prevenire a aparitiei conditiilor de eroare. Pentru a elimina mesajul de eroare trebuie mai întâi sa eliminam posibilitatea ca utilizatorul sa greseasca devci trebuie schimbata mentalitatea despre mesajele de eroare. În loc sa presupunem ca mesajele de eroare sunt normale ele trebuie gândite ca solutii anormale pentru probleme rare si trebuie tratate ca ultimo element de sprijin.

Utilizatorii nu doresc niciodata mesaje de eroare, ei doresc sa previna consecintele greselilor facute ceea ce este diferit de a spune ca nu doresc mesaje de eroare. Don Norman puncteaza faptul ca adesea oamenii se invinuiesc de erorile proiectarii produsului, iar faptul ca nu avem plângeri de la utilizator nu înseamna ca sunt multumiti cu mesajele de eroare pe care le intalnesc.

Casete de dialog de tip buletin

Familiara caseta de mesaj de eroare este în mod normal un dialog modal care opreste toate procesele anterioare ale programului pâna când utilizatorul lanseaza o comanda de terminare - de exemplu apasarea butonului OK. Numim acest tip de mesaj de eroare buletin de blocare (blocking bulletin) deoarece programul nu poate continua fara interventia utilizatorului. Exista si posibilitatea ca un program sa puna o caseta de dialog în mod unilateral pe care apoi sa o retraga. Numim acest tip de mesaj de eroare buletin de suport (sustaining bulletin) deoarece dialogul dispare iar programul continua fara interventia utilizatorului. Buletinele de suport sunt utilizate frecvent drept casete de dialog de proces, raportând starea unei proceduri de durata. În timpul procesului dialogul ofera utilizatorului un buton CANCEL pentru terminare daca acesta se razgândeste sau devine nerabdator. Buletinele de suport sunt folosite pentru a raporta erori. Un program care construieste un mesaj de eroare pentru a raporta o problema poate corecta problema sau poate detecta faptul ca problema a disparut.

Un mesaj de eroare trebuie sa opreasca programul, daca nu o face utilizatorul s-ar putea sa nu fie capabil sa-l citeasca complet sau daca se uita în alta parte nu-l va putea vedea sau îl va percepe doar cu coada ochiului si va devi suspicios ca a pierdut ceva important. Singura justificare pentru o caseta de dialog de tip buletin suport este aceea de a raporta un proces, ea nu trebuie utilizata niciodata pentru a raporta erori sau informatii.

Oprirea prelucrarii

Deci mesajele de eroare trebuie sa opreasca prelucrarea printr-o caseta de dialog modala. Majoritatea proiectantilor de interfete utilizator - fiind programatori - considera ca 333b16d aceste casete de mesaje de eroare alerteaza utilizatorul asupra problemelor serioase. Aceasta este o greseala de conceptie larg raspândita. Majoritatea casetelor de mesaj de eroare informeaza utilizatorul despre inabilitatea programului de a lucra în mod flexibil.

În zilele de debut ale tehnicii de calcul programatorii au acceptat ca modalitatea corespunzatoare prin care software-ul trebuie sa interactioneze cu utilizatorul este de a solicita input si de a abandona când utilizatorul a esuat în atingerea unui nivel de perfectiune apropiat de cel al UCP-ului, atitudine numita silicon sanctimon. Când se pune problema factorului uman soft-ul trebuie sa presupuna ca input-ul este corect pur si simplu pentru faptul ca omul este mai important decât codul. Programul poate sti care este stare lucrurilor din interiorul calculatorului dar numai utilizatorul este acela care stie care este starea lucrurilor din lumea reala. Când utilizatorii vad o caseta de mesaj de eroare este ca si când cineva le-ar spune agasant si tare - Fatal error buddy That input realy sucked ! - ceea ce nimanui nu-i place. Este extrem de neinspirat sa proiectam interfete utilizator punând în program astfel de interactiuni. Multi proiectanti si programatori de interfete utilizator lucreaza facând aceasta greseala de conceptie pornind de la ideea ca oamenilor fie le place, fie au nevoie sa li se spuna atunci când gresesc. Presupunând ca oamenilor le place sa li se spuna când gresesc ignora natura umana. Multi se simt agasati si deranjati când sunt atentionati de greselile facute si ar prefera sa nu stie când au gresit.

O metoda se eliminare a mesajelor de eroare este ca atunci când se receptioneaza un input, programul sa presupuna ca probabil el este cel care nu a înteles si nu ca utilizatorul nu este bine informat. Daca ne gândim bine majoritatea buletinelor de eroare raporteaza utilizatorului când programul ajunge confuz. Marea majoritate a programatorilor gândesc ca utilizatorii fac greseli si în consecinta îsi concep mesajele de eroare ca instrumente de corectare a actiunilor utilizatorului. A face imposibil ca utilizatorul sa greseasca este cea mai buna modalitate de a elimina mesajele de eroare. Folosind pentru introducerea datelor gizmo-uri cu limitare, utilizatorii sunt împiedicati sa mai introduca numere invalide. În loc sa obligam utilizatorul sa tasteze alegerea sa vom prezenta o lista de alternative posibile din care sa aleaga.

Utilizatorii calculatoarelor nu arata întelegere fata de dificultatile cu care se confrunta programatorii. Ei nu vad rationamentele tehnice din spatele unei respingeri printr-o caseta de mesaj de eroare, tot ce vad este încapatânarea programului de a trata lucrurile într-o maniera umana. Una din cele mai mari probleme privind mesajele de eroare este faptul ca sunt raportari post facto si foarte des casetele de dialog au un buton OK prin care se solicita utilizatorului sa fie de acord cu mesajul de eroare.

Tratarea mesajelor de eroare precum GOTO-uri

Daca am afirma în fata unor grupuri de utilizatori ca mesajele de eroare ar trebui sa dispara acestia în general vor fi de acord. Daca însa am face aceeasi afirmatie în fata programatorilor acestia vor protesta vehement. Aceasta întareste convingerea ca prezenta casetelor cu mesaje de eroare se datoreaza în principal programatorilor si nu utilizatorilor. Acest lucru aminteste de o dezbatere simulara începuta odata cu lucrarile lui Edsgar Dijkstra, inventatorul programarii structurate, care a dovedit ca instructiunea Goto poate fi eliminata din limbajele de programare de nivel înalt. Programatorii anilor 70 si cei care au utilizat limbajul de asamblare aveau posibilitatea de a sari aleator si fara urma oriunde în program - ceea ce era considerat un frept fundamental si un instrument necesar pentru a obtine o performanta adecvata. Revolutia programarii structurate a aratat ca putini dintre programatorii care utilizeaza limbaje ca Basic,C, Pascal recurg la Goto-uri. De asemenea este recunoscut faptul ca un program plin de Goto-uri este un adevarat cosmar în ceea ce priveste întelegerea si întretinerea lui desi utilizarea unuia sau a doua Goto-uri ocazionale nu deranjeaza pe nimeni; dar le trateaza ca pe o ultima resursa posibila.

Ar trebui sa fie acelasi lucru si în cazul utilizarii casetelor de mesaje de eroare. Când un programator codifica o caseta de mesaj de eroare el trebuie sa stie ca are la dispozitie metode cu mult mai bune pentru a trata situatia. Trebuie ca programatorii sa realizeze ca mesajele de eroare nu sunt un drept fundamental sau un instrument necesar pentru a obtine o performanta adecvata. Toate casetele de mesaj de eroare pot fi eliminate. Daca examinam situatia din punct de vedere al faptului ca acea caseta de mesaj de eroare trebuie eliminata si ca orice altceva este subiect de modificare pentru acest obiectiv, veti vedea adevarul acestei asertiuni.

Exceptii

Pe masura ce puterea tehnologica creste portabilitatea si flexibilitatea harware-ului calculatorului cresc si ele. Windows 95 a stabilit un nou standard numit Plug-and-Play care permite retelelor si perifericelor sa fie conectate si deconenctate de la calculator fara a fi necesara scoaterea acestuia de sub tensiune. Deci sub Windows 95 este cât se poate de normal ca hardware-ul sa apara sau sa dispara ad-hoc. Imprimante, modem-uri, server-e de fisiere pot veni si pleca precum un flux-reflux. Odata cu dezvoltarea conectoarelor de retea, fara cablu, calculatoarele se vor putea atasa si dezatasa în mod frecvent si usor la sau de la retele.

Este cumva o eroare daca încercati sa imprimati doar pentru a afla ca nu este conectata nici o imprimanta ? Este o eroare daca fisierul pe care-l editati rezida în mod normal pe un drive care nu mai este abordabil? Sa fie oare o eroare daca modem-ul de comunicatie nu mai este introdus în calculator? Se considera ca 333b16d aceste împrejurari mentionate mai sus nu trebuie tratate ca erori. Daca încercam sa imprimam ceva si nici o imprimanta nu este disponibila, programul ar trebui sa trimita imaginea de imprimare pe disc. Programul Print Manager ar trebui sa indice tacit atunci când se reconecteaza la o imprimata, cât timp are documente neimprimate în coada sa de asteptare. Acesta trebuie sa fie un aspect normal de zi cu zi nu o eroare. Este exact la fel si în cazul fisierelor. Cea mai frecventa cauza a mesajelor de eroare consta în a raspunde utilizatorului care solicita o resursa anume si care nu este disponibila. Eroarea poate fi eliminata asigurând ca programul sa nu ofere utilizatorului lucruri care n-ar putea fi prezente. Daca programul ofera în locul câmpurilor de editare liste din care se poate alege, utilizatorul nu va mai putea introduce numele unui fisier care nu este disponibil. Mesajele de eroare trebuie rezervate doar pentru urgentele reale.

Casetele de dialog pentru mesajele de eroare

O caseta de mesaj de eroare bine formata trebuie sa fie: politicoasa, clarificatoare, de ajutor. Sa nu uitam ca o caseta de mesaj de eroare este de fapt programul care raporteaza esecul sau în realizarea unui job si care întrerupe utilizatorul pentru aceasta. Caseta de mesaj de eroare trebuie sa fie politicoasa - ea nu trebuie nici macar sa sugereze utilizatorului ca el este cel care a provocat problema; clientul are întotdeauna dreptate. Utilizatorul poate introduce date aiurea dar programul trebuie sa faca tot ce poate pentru a da utilizatorului ce a solicitat. Programul are responsabilitatea de a proteja utilizatorul chiar daca acesta face o actiune necorespunzatoare. Consideram pentru exemplificare fereastra aplicatiei Word care contine fereastra cu urmatorul mesaj de eroare - Too many Word documents are open. Please close a window.

Caseta de mesaj de eroare trebuie sa clarifice problema pentru utilizator. Aceasta înseamna ca trebuie sa dea acele informatii necesare pentru a lua o decizie corespunzatoare rezolvarii problemei . E nevoie ca scopul programului sa fie clar - care sunt alternativele, ce va face programul implicit, care informatii s-au pierdut; programul fiind cel care trebuie sa trateze aceste lucruri amintite mai sus, spunând utilizatorului totul. Programul trebuie sa ofere cel putin o solutie implementata chiar acolo în caseta de dialog. De fapt ar trebui sa ofere butoane care sa aiba grija de rezolvarea problemei prin mai multe modalitati.

Daca o imprimanta lipseste, caseta de mesaj ar trebui sa ofere optiuni pentru a deferi imprimarea catre o alta imprimanta selectata.

Daca o baza de date este neutilizabila ar trebui sa ofere posibilitatea de a o reconstrui într-o stare de lucru, incluzând si informatii de genul - cam cât timp ar dura procesul si care ar putea fi efectele colaterale provocate.

Figura alaturata reprezinta un exemplu de mesaj de eroare rezonabil. De remarcat faptul ca este politicos, clarificator si de ajutor.

Nici macar nu sugereaza utilizatorului faptul ca atitudinea acestuia este altfel decât impecabila.

Gestiunea exceptiilor

Exista o alta categorie de conditii pe care le denumim global exceptii (exceptions). Ca si erorile acestea opresc prelucrarea în mod stupid dar nu raporteaza proasta functionare. Exceptiile se împart în doua varietati de baza - alerte si confirmari. O alerta atentioneaza utilizatorul asupra actiunilor programului în timp ce confirmarile dau utilizatorului autoritatea de a trece peste aceasta actiune.

Alerte

Atunci când progamul exercita o autoritate cu care nu se simte confortabil informeaza adesea utilizatorul despre actiunile sale - numim aceasta o alerta (alert). Chiar daca o alerta este justificata de ce trebuie sa mergem într-o alta fereastra pentru acest lucru. Daca programul considera o actiune nejustificata el ar trebui sa marturiseasca acest lucru în acelasi loc în care are loc actiunea nu într-o caseta de dialog separata. Ratiunea alertelor este aceea ca ele informeaza utilizatorul. Este foarte util ca utilizatorul sa fie informat dar nu pe cheltuiala unei interactiuni netede si cursive.

Alerta prezentata în figura alaturata este un exemplu clasic privind felul în care alertele se tin scai de utilizator.

Dialogul Find forteaza deja utilizatorul sa apese Cancel atunci când s-a terminat cautarea dar o caseta de alerta supraimpusa întrerupe fluxul butoanelor - întâi se apasa OK din alerta, apoi CANCEL din Find.

Daca informatia asteptata de alerta era construita în dialogul Find, efortul utilizatorului ar fi fost redus la jumatate. Pentru proiectantii de interfete utilizator aceasta reprezinta o economie buna.

Alertele sunt numeroase deoarece sunt usor de creat. Majoritatea limbajelor ofera câteva forme pentru facilitatea casetelor de mesaj într-o singura linie de cod. Construirea unui afisaj de stare animat în interfata unui program poate necesita o mie sau multe linii de cod. Într-o astfel de situatie nu ne asteptam ca programatorii sa aleaga solutia corecta. Proiectantii trebuie sa se asigure sa specifice precis unde anume sunt raportate informatiile la suprafata aplicatiei.

Software-ul are nevoie sa informeze utilizatorul referitor la actiunile sale. El trebuie sa aiba lumini, masuratori sau alte gizmo-uri construite în interfata care sa faca starea informationala disponibila utilizatorului daca acesta o doreste. Pentru o actiune nesolicitata nu este indicat sa se puna o alerta, dar a pune o alerta pentru o actiune solicitata este stupid!

Confirmari

Când un program nu se simte încrezator în actiunile sale adesea solicita utilizatorului aprobarea actiunilor sale printr-o caseta de dialog - aceasta se numeste confirmare (confirmation) si arata la fel ca în figura de mai jos.

Uneori confirmarea este oferita astfel încât utilizatorul sa aiba ocazia de a ghici una din doua actiuni ale sale. Uneori programul simte ca nu este competent sa ia o decizie si foloseste în schimb o confirmare pentru a da utilizatorului alternativa. Confirmarile vin întotdeauna de la program si niciodata de la utilizator. Deci exceptiile sunt o reflectare a modelului de implementare si nu sunt reprezentative pentru scopul utlizatorului. Toate casetele de dialog de confirmare pot fi eliminate doar prin schimbarea atitudinii programului. Confirmarile ajung sa fie scrise în soft atunci când programatorul ajunge într-un impas de codificare. Acesta realizeaza ca este punctul de a face o actiune marcanta si simte ca utilizatorul ar dori sa aiba controlul acestei actiuni.

Uneori actiunea marcanta se bazeaza pe anumite conditii detectate de program dar adesea se bazeaza pe o comanda lansata de utilizator. De obicei confirmarea va aparea dupa ce utilizatorul a lansat comanda care fie este nerecuperabila fie are rezultate ce pot provoca o alarma inoportuna. În ambele cazuri programatorul paseaza responsabilitatea utilizatorului ceea ce este gresit. Obiceiul de a transfera utilizatorului responsabilitatea este cunoscut ca si oprirea prelucrarii cu stupiditate. Chiar daca programul a gasit o conditie de exceptie din punctul de vedere al utilizatorului este tot stupiditate. În timpul dezvoltarii programului, programatorii detecteaza numeroase situatii când simt ca nu pot da o rezolvare adecvata, în aceste locuri vor insera coduri de transfer al responsabilitatii si pot introduce casete de dialog de confirmare. Programatorii nu considera ca 333b16d dialogurile de confirmare fac parte din interfata utilizator, însa fac parte integranta !

Referitor la mesajele de confirmare - ele merg doar atunci când sunt neasteptate. Acest lucru nu este remarcabil pâna când nu este examinat în context. Când confirmarile sunt oferite în locuri uzuale utilizatorul se va deprinde repede cu acestea si le va îndeparta fara sa se mai uite; astfel ca îndepartarea acestora devine o rutina la fel ca si aparitia lor. În cazul în care apare o situatie cu totul neobisnuita si periculoasa care ar trebui sa atraga atentia, utilizatorul va merge mai departe si din obisnuinta o va îndeparta. Pentru ca aceste casete de confirmare sa mearga ele trebuie sa apara doar atunci când sunt asteptate. Deci confirmarea trebuie sa apara doar atunci când utilizatorul a apasat aproape definitiv pe butonul NO si sa nu apara niciodata atunci când utilizatorul (pare ca) apasa pe butonul YES.

Caseta de dialog de confirmare prezentata mai jos este una clasica. Ea apare atunci când apasam butonul DELETE.

Ea apare de fiecare data când dorim sa spunem YES deci când apasam întotdeauna butonul YES. Daca vreodata spunem NO nu vom remarca de loc faptul ca era o caseta de dialog.

Ironia casetei de dialog de confirmare din figura prezentata este aceea ca adesea avem probleme cu aceasta caseta când determinam care sunt stilurile pe care preferam sa le stergem si pe care sa le pastram.

Poate ca era mai bine sa existe un simbol grafic lânga numele stilurilor care sunt utilizate si astfel sa se renunte la confirmare. De asemenea daca butonul DELETE ar fi fost separat de butoanele OK si CANCEL sansa de a apasa pe un buton necorespunzator ar fi redusa considerabil.

Exista trei axiome care ne spun cum sa eliminam casetele de dialog de confirmare. Cea mai buna cale este de a respecta dictonul care spune - fa nu întreba. Evident ca daca programul face ceva ce utilizatorului nu-i place trebuie sa aiba abilitatea de a inversa operatia. Fiecare aspect al actiunilor programului trebuie sa fie reversibil. În loc sa întrebe în avans printr-o caseta de confirmare sa lasam utilizatorul sa lanseze comanda Stop&Undo asupra acelor rare ocazii când actiunile programului nu sunt la momentul corespunzator.

Majoritatea situatiilor pe care în mod curent le consideram neprotejate prin Undo de fapt pot fi foarte bine protejate. Un exemplu ar fi stergerea sau suprascrierea unui fisier. Fisierul poate fi mutat într-un director temporar unde sa fie pastrat cam o luna înainte de a fi sters fizic. De fapt Recycle Bin din Windows 95 foloseste aceasta strategie, exceptând acea parte care sterge automat dupa o luna - utilizatorului îi revine sarcina de trata manual aceasta problema.

Mai bine decât sa actionam în graba si sa fortam utilizatorul sa recurga la Undo ne putem asigura ca programnul sa ofere utilizatorului în mod direct informatiile suficiente si adecvate astfel încât acesta sa nu lanseze niciodata o comanda necorespunzatoare. Programul ar trebui sa utilizeze feedback vizual bogat astfel încât utilizatorul sa fie informat în mod constant. Putem sa îi oferim utilizatorului protectie prin marcaje consistente si clare. Putem construi gizmo-urile izolate, colorate intens, plasate lânga listbox-uri care dezvaluie totul despre datele respective. Cu mult mai uzuale decât actiunile reversibile sunt acele actiuni care sunt usor reversibile dar care sunt înca protejate prin casete de confirmare de rutina. Confirmarea prezenata anterior (Confirm File Delete) e un specimen tipic al acestei categorii. Nu este nici un motiv de a cere confirmarea pentru a muta în Recycle Bin; singura ratiune pentru care Recycle Bin exista este aceea de a implementa facilitatea de Undo pentru fisierele sterse, deci aceasta caseta de confirmare opreste prelucrarea.

Protejarea integritatii si imunitatii datelor

Marea majoritate a programelor nu protejeaza din greu utilizatorul ci mai degraba se protejeaza pe sine. Programatorii îsi protejeaza propriile creatii, iar mesajele de eroare sunt simptomele acestei protectii, dar proiectarea imperativa este cea care aduce programul în forma de a genera astfel de simptome. Proiectarea imperativa este caracterizata prin scopul de a nu lasa niciodata ca datele corupte si neclare sa ajunga în software. Programatorii ridica bariere în interfata utilizator astfel încât datele proaste sa nu patrunda niciodata în program. Aceasta stare pur interna se numeste în mod uzual integritatea datelor (data integrity). Integritatea datelor arata ca exista o lume de informatii haotice care înainte de a ajunge în calculator trebuie filtrate si curatate. Soft-ul trebuie sa aiba o bariera de protectie. Toate datele sunt facute valide în punctul de intrare. Orice lucru care nu se încadreaza sau este suspect este respins, dar datele care au trecut de bariera de protectie se presupune ca au satisfacut criteriile riguroase. Odata ajuse înauntru se presupun valide. Avantajul este acela ca odata ajunse în baza de date, codul nu mai trebuie sa se mai preocupe de verificari succesive, repetitive privind validitatea sau corectitudinea datelor.

O alta abordare complet diferita pentru protejarea soft-ului sensibil este urmatoarea - în loc sa tinem datele proaste în afara sistemului programatorul trebuie sa faca sistemul imun la inconsistentele si golurile de informatii. Aceasta metoda implica scrierea unui cod mult mai destept, mai sofisitcat care sa poata manevra toate permutarile de date în mod robust - numim aceasta imunitatea datelor (data immunity). În mod traditional programatorii au folosit integritatea datelor si au dispretuit imunitatea datelor deoarece necesita un cod mai complex. Integritatea datelor este un concept bun pe hârtie dar în lumea reala apar unele probleme. E vorba în special de datele corecte din momentul introducerii acestora mai degraba decât atunci când si daca este nevoie de datele corecte. Imunitatea datelor nu tolereaza datele proaste atunci când e nevoie de date corecte. Totusi tolereaza date proaste în sistem atunci când prostia" nu conteaza.

Integritatea datelor cere ca toate datele sa fie scuturate la usa iar tot ce nu corespunde sa fie detectat. O data intrate datele sunt bune. Singura ratiune de a suspecta datele la intrare este de a face lucrurile mai simple pentru programator si calculator; utilizatorul nu conzeaza. Integritatea datelor este atât de larg raspândita si acceptata ca proiectare software buna încât hegemonia ei este rareori pusa sub semnul întrebarii. O mare parte din toata arta si stiinta administrarii, gestiunii si programarii bazelor de date de bazeaza pe presupunerea ca integritatea datelor este mentinuta cu siguranta. Programatorii care scriu software centrat pe utilizator care este axat pe baze de date, întiparesc în tot ce fac în mod inconstient principiul integritatii datelor.

Pentru a implementa imunitatea datelor programele trebuie învatate sa se uite în context înainte de a face ceva si sa solicite ajutor. Majoritatea soft-ului realizeaza orbeste operatiile aritmetice asupra numerelor fara sa le examineze mai întâi. Conform integritatii datelor programul presupune ca un câmp numeric trebuie sa contina un numar. Trebuie sa învatam programele sa creada ca utilizatorul va introduce ceea ce crede el ca se introduce, iar daca utilizatorul doreste sa corecteze o va face fara insistenta paranoica cunoscuta; însa programul se poate uita dupa asistenta oriunde pe calculator. Exista oare un modul care stie sa dea sens numeric unui text alfabetic sau o istorie a corectiilor care sa arunce lumina asupra intentiilor utilizatorului Daca toate acestea esueaza programul trebuie sa adauge adnotari la date astfel încât atunci când si daca utilizatorul ajunge sa examineze problema sa gaseasca note complete si clare despre ce s-a întâmplat si care sunt pasii pe care i-a facut programul. Integritatea datelor ajuta la reducerea solicitarii programatorului nespunând nimic din ceea ce face pentru utilizator.

Feedback auzibil

În mediile de introducere a datelor functionarii profesionisti în introducerea datelor - operatori, culegatori, dactilografe - stau cu orele în fata ecranelor video si introduc date. Acestia urmaresc mai degraba textul documentului de introdus decât ecranul video. Daca se întâmpla sa introduca ceva eronat ei trebuie informati atât auditiv cât si vizual. Nu discutam despre beep-ul care acompaniaza casetele de mesaj de eroare.

Atunci când utilizarea cu succes a instrumentelor produce sunet numim aceasta feedback auzibil pozitiv (positive audible feedback). Ori de câte ori apasam o tasta auzim un zgomot fad dar pozitiv. Producatorii de tastaturi puteau sa le faca silentioase dar nu au procedat asa deoarece depindem de feedback-ul auzibil care sa ne spuna ce facem. Adevarata valoare a feedback-ului auzibil pozitiv consta în faptul ca absenta sa este un indicator-problema extrem de eficient.

Casetele de mesaje de eroare sunt exemple de beedback negativ care spun ca utilizatorul a facut ceva gresit. Dar linistea asigura faptul ca utilizatorul stie asta fara sa i se spuna ceva despre esec. E remarcabil de eficient deoarece soft-ul nu trebuie sa insulte utilizatorul pentru a termina task-ul. Emiterea zgomotului atunci când se întâmpla ceva rau se numelte feedback auzibil negativ (negative audible feedback). Feedbak-ul negativ are câteva lucruri împotriva sa. Deoarece el este emis în momentul când s-a descoperit problema în mod natural are caracteristicile unei alarme. Alarmele sunt proiectate pentru a fi tipatoare, discordante si perturbante. Aspectul cel mai blestemat al feedback-ului auzibil negativ este implicatia faptului ca succesul trebuie semnalat prin liniste. Oamenilor le place când sa stie când lucrurile merg bine. Ei au nevoie sa stie când anume actioneaza cum trebuie dar asta nu înseamna ca le si place sa tot auda asta.

În mod garantat sistemele de feedback negativ sunt mai putin apreciate decât cele de feedback pozitiv. Data fiind alegerea dintre nici un zgomot fata de zgomot, pentru feedback negativ oamenii vor prefera prima situatie. Data fiind alegerea dintre nici un zgomot fata de zgomot neplacut pentru feedback pozitiv oamenii vor alege dupa situatia personala si dupa gust. Data fiind alegerea dintre nici un zgomot fata de zgomote placute pentru feedback pozitiv, oamenii în general prefera audio. În functie de situatie feedback-ul auzibil trebuie sa fie facut la volumul corect. Majoritatea calculatoarelor nu ofera controale de volum ca urmare sunetul este fie prea tare fie prea slab. Odata cu Windows 95 care ofera un control de volum standard unul dintre obstacolele pentru un feedback auzibil benefic a fost depasit.

Pierderea datelor

S-a constatat ca ceea ce doare cel mai tare pe oricine este pierderea informatiilor; nimeni nu doreste asa ceva. Daca aplicatia este una de productivitate utilizatorul va interactiona cu programul iar rezultatele erorii sale vor deveni aparente. Daca utilizatorul este un functionar care introduce date tot timpul, tastând formule într-un program de culegere de date a firmei, folosind foarte multe ore acest program el va avea un al saselea simt si astfel dintr-o privire aruncata pe ecran va sti exact daca datele introduse au fost proaste, mai ales daca programul utilizeaza mijloace nemodale vizuale si auditive pentru a-l tine informat despre starea datelor.

Sa nu uitam ca programul va ajuta - nu va cere utilizatorului sa introduca informatii în gizmo-uri nelimitate. Numere sau parti de numere care trebuie sa fie valide nu vor fi tastate oricum ci vor fi introduse prin intermediul unui tip de lista. Programul va oferi utilizatorului în mod constant feedback auditiv pozitiv astfel încât programul va începe sa actioneze ca un partener ajutîndu-l sa fie constient de starea activitatii sale. Deci cât de serioasa este pierderea datelor? În situatia culegerii datelor, a sari un câmp este ceva serios dar de obicei câmpul va fi introdus mai degraba gresit decât omis. Programul poate ajuta usor ca functionarul sa detecteze problema si sa o schimbe într-o intrare valida fara a opri prelucrarea. Daca functionarul este determinat sa omita câmpurile necesare problema este functionarul si nu programul. Windows 95 ofera un exemplu cât se poate de rezonabil pentru axioma - verificam nu editam - chiar în procedura sa de instalare. Programul nu numai ca este suficient de destept pentru a se adapta la situatii neasteptate dar pastreaza note interne bogate privind progresul sau. Daca cumva crapa programul lasa în urma un raport al progresului sau pâna la aparitia problemei, iar ultima intrare din raport atrage atentia asupra a ceea ce nu a mers. Data viitoare programul fie va omite task-ul ofensator sau va considera altul diferit pentru a rezolva problema. Majoritatea sistemelor de prelucrare a informatiilor sunt cu adevarat tolerante la informatiile care lipsesc, ele putând fi reconstruite din alte parti ale datelor introduse. De fapt sistemele de prelucrare a informatiei pot lucra foarte bine si cu date lipsa

UNDO

Asistarea explorarii

Undo este facilitatea traditionala gândita pentru eliberarea tuturor utilizatorilor de necazuri. Deoarece oamenii gresesc tot timpul Undo este o facilitate care exista pentru folosinta lor exclusiva. Nu numai ca oamenii fac greseli acesta sunt sunt atât de cotidiene încât daca le gândim ca erori sau o comportare anormala vom devia de la proiectarea software. Undo permite utilizatorului sa inverseze una sau mai multe actiuni precedente daca se decide sa se razgândeasca. Secretul proiectarii unui Undo reusit este a-l crea presupunând ca acesta suporta o parte normala din setul de lucru zilnic al instrumentelor programului Undo trebuie proiectat astfel încât sa fie mai putin un instrument pentru reversul erorilor si mai mult unul pentru a suporta explorarea. În principal erorile sunt actiuni singulare, incorecte si neintentionate. Prin contrast explorarea este o serie lunga de probe si pasi unele care pot fi pastrate iar altele abandonate.

Undo este unul din exercitiile cele mai dificile din practica dezvoltarii software. Nu este foarte algoritmic - în cartile de stiinta calculatoarelor nu se gasesc prea multe discutii referitoare la Undo - dar este necesara adaugarea la un program a unei facilitati deosebite care implica implementarea unui cod complex. Undo nu este computer-like, calculatoarele negresind niciodata aceasta fiind si una din atractiile carierei de programator. Undo este un lucru uman si trateaza natura umana supusa greselii reprezentând o parte neplacuta si vag dizgratioasa pentru job-ul programatorului.

O contributie semnificativa pe care Undo o aduce utilizatorului este pur psihologica - îl încurajeaza. În mod curios, adesea utilizatorii nu se gândesc la Undo pâna când nu au nevoie de el. Desi comun în industria software nu exista o terminologie adecvata pentru a descrie tipurile de Undo existente; se utilizeaza termenul generic de Undo. O actiune utilizator tipica dintr-o aplicatie tipica are o componenta procedura - ce face utilizatorul - si o componenta de date optionala - care sunt informatiile afectate. Când utilizatorul solicita o functie Undo componenta procedura a actiunii este inversata si daca actiunea avea o componenta de date optionala - datele adaugate sau sterse se utilizator - datele vor fi sterse respectiv adaugate. Numim functiile care au atât o componenta procedura cât si una de date drept actiuni incrementale (incremental actions) sau incrementale (incrementals).

Majoritatea functiilor care permit Undo sunt transformari care nu implica date cum ar fi operatia de reformatare a unui paragraf dintr-un procesor de text sau operatia de rotatie dintr-un program de desenare. Ambele operatii anterior mentionate actioneaza asupra datelor dar nici una nu adauga sau nu sterge date. Numim astfel de functii care au doar o componenta procedura drept actiuni de tip procedura (procedure actions) sau procedurale (procedurals). Majoritatea functiilor Undo existente nu fac discriminari între procedurale si incrementale ci inverseaza pur si simplu cea mai recenta actiune.

UNDO simplu si multiplu

Cele doua tipuri de Undo cele mai familiare utilizate în prezent sunt Undo simplu si Undo multiplu. Undo simplu (single undo) este varianta de baza inversând în mod nerepetabil efectele celei mai recente actiuni a utilizatorului indiferent ca este incrementala sau procedurala. Aceasta facilitate este foarte eficienta deoarece este usor de operat. Interfata utilizator este simpla si clara usor de descris si de tinut minte. Este cel mai frecvent Undo implementat si optim pentru multe programe. Undo multiplu (multiple Undo) este repetabil - se poate inversa mai mult de o actiune precedenta în ordine invers temporala.

În mod normal Undo este invocat printr-un element de meniu sau un buticon având o eticheta nemodificabila. Utilizatorul stie ca actionând acest buton va face Undo pe ultima operatie dar nu exista nici o indicatie despre ce operatie e vorba - acesta e un Undo orb (blind Undo). Daca elementul include descrieri text sau vizuale ale unei operatii particulare care va fi facuta Undo acesta este un Undo explicativ (explanatory Undo). Un Undo explicativ este mult mai usor de pus pe un element de meniu dar cu mult mai dificil de pus pe un buticon, desi a pune o explicatie în ToolTips este un compromis acceptabil. Marea limitare a unui Undo pe un singur nivel, apare atunci când utilizatorul nu remarca imediat greseala. În unele programe orice click de mouse, oricât de inocenta ar parea aceasta functie determina ca functia Undo sa uite ultimul lucru inteligibil pe care l-a facut utilizatorul. Raspunsul la slabiciunea Undo-ului de un singur nivel a fost crearea unei implementari pe mai multe nivele a aceluiasi Undo incremental. Programul salveaza fiecare actiune pe care o face utilizatorul. Selectând Undo în mod repetat fiecare actiune poate fi inversata în ordinea opusa invocarii originale.

Orice program care are facilitatea Undo trebuie sa tina minte ultima operatie a utilizatorului si daca este aplicabil sa ascunda datele modificate. Daca programul implementeaza Undo multiplu el trebuie sa tina o stiva a operatiilor, adâncimea acesteia putând fi setata de utilizator ca o preferinta în avans. De ficare data când este invocat Undo, se realizeaza undo incremental adica inversarea celei mai recente operatii, înlocuirea sau eliminarea datelor daca este necesar si îndepartarea operatiei de restaurate de pe stiva. Majoritatea functiilor Undo tin minte ce face utilizatorul, functie cu functie si separa actiunile utilizatorului de functiile individuale. Fiecare apasare a butonului Undo inverseaza în mod precis o functie din comportare. Inversarea bazata pe functie dupa functie reprezinta un model mental corespunzator pentru rezolvarea majoritatii   problemelor simple provocate de utilizator prin introduceri eronate.

REDO

Redo este practic inversul lui Undo si exista în mod special pentru ca este usor de implementat daca programatorul a facut deja efortul de a implementa Undo. Multe din programele care implementeaza Undo simplu trateaza ultima actiune inversata ca pe una asupra careia se poate face Undo. De fapt aceasta este o a doua invocare a functiei Undo pentru o functie Redo. Scopul real al functiei Redo este de a evita situatiile ce apar într-un Undo multiplu. Daca utilizatorul doreste sa revina înapoi vreo duzina de operatii sau chiar mai multe, el apasa butonul Undo de câteva ori asteptând ca lucrurile sa revina la normal. În acest caz se poate întâmpla sa apese pe Undo de mai multe ori caz în care se trece peste situatia dorita. Redo rezolva aveasta problema permitând Undo pentru Undo punând înapoi ultima actiune buna. Practic Redo nu este altceva mai mult decât un substituent pentru instrumente de vizualizare mai bune dintr-un Undo explicativ.

Modalitati de implementare Undo

O modalitate de implementare ar fi sa se tina cont de forma simpla a unui Undo care se conformeaza modelului utilizatorului - Tocmai am facut ceva iar acum doresc sa nu fi facut; doresc sa apas un buton si sa fac un Undo pe ultimul lucru realizat. O alta modalitate de implementare este milestoning care implica realizarea unei copii a întregului document în stilul în care o camera de luat vederi capteaza o imagine instantaneu. Metoda implica întregul document ea este implementata întotdeauna utilizând direct sistemul de fisiere. Marea diferenta dintre milestoning si alte sisteme Undo este faptul ca utilizatorul trebuie sa solicite în mod expres aceasta metoda prin salvarea documentului. Odata ce a facut aceasta poate trece la modificarea originalului în deplina siguranta. Daca mai târziu se decide ca modificarile nu erau necesare poate reveni la copia salvata - deci la o versiune precedenta. Conceptul de milestoning este excelent, multe dintre instrumentele existente suportându-l pentru codul sursa, din nefericire nici un program nu suporta acest concept direct pentru utilizator. Daca milestoning ar fi redat printr-un model utilizator nebazat pe sistemul de fisiere implementarea ar fi mai usoara si gestiunea sa la fel de simpla. Un singur buticon ar fi salvat întregul document în starea sa curenta.

Pasul în care se revine la versiunea milestoned precedenta este ceea ce numim întoarcere (reversion). Facilitatea de întoarcere este foarte simpla - poate exista un element de meniu Revert to Milestone considerat ca parte dintr-un Undo care trebuie sa ofere mai multa informatie. De obicei ar trebui sa arate o lista a versiunilor salvate, disponibile ale acelui document împreuna cu alte câteva informatii despre fiecare versiune precum ora si ziua când a fost înregistrata, numele persoanei care a facut înreistrarea, lungimea si alte câteva note optionale introduse de utilizator. Utilizatorul ar putea alege una din aceste versiuni, programul putând reveni la aceasta îndepartând orice schimbari interpuse.

O varianta relativa de milestoning si de întoarcere este cea pe care o numim congelare (freezing). Opus cu milestoning congelarea implica blocarea datelor în document astfel încât acestea sa nu poata fi modificate. Orice a fost introdus devine nemodificabil desi pot fi adaugate noi date. Paragrafele existente sunt de neatins însa altele noi pot fi adaugate între cele vechi. Aceasta metoda este cu mult mai utila pentru un grafic decât pentru un document text.

În casetele de dialog nu sunt functii Undo individuale. În schimb Undo este o functie globala stâns legata de program care inverseaza ultima actiune referitor la ceea ce s-a facut prin manipulare directa într-o caseta de dialog. Acest lucru face ca Undo sa fie problematic pentru obiectele incluse (embedded) care folosesc modelul OLE. Daca utilizatorul face modificari într-un spreadsheet inclus într-un document Word apoi face click în documentul Word si apoi invoca un Undo va fi inversata cea mai recenta actiune Word nu cea mai recenta actiune din spreadsheet. Este un esec din punct de vedere al jonctiunii dintre spreadsheet si documentul Word, functia Undo încetând de a mai fi globala si devine modala. Aceasta nu e o problema Undo ci o problema OLE.

Operatii ce nu pot fi facute Undo

Unele operatii nu pot fi facute Undo deoarece implica unele actiuni precum activarea unui device care nu este sub controlul direct al programnului. Un astfel de exemplu ar fi urmatorul - o data ce un mesaj e-mail a fost trimis nu se poate reveni, inversa deci nu pot face Undo. La fel daca scot calculatorul de sub tensiune sau îl opresc fara a salva datele nu pot face Undo. Sunt însa multe operatii care desi nu pot fi trucate ca un Undo sunt usor reversibile. De exemplu când salvam pentru prima data un document ni se permite în majoritatea programelor sa alegem numele; dar aproape nici un program nu ne lasa sa redenumim acel fisier. Evident putem face Save As. sub un alt nume dar aceasta înseamna realizarea unui alt fisier sub un nume nou lasându-l pe cel vechi nemodificat sub vechiul sau nume. E drept ca schimbarea numelui de fisier este o caracteristica Undo dorita în mod frecvent. Deoarece nu se încadreaza în viziunea traditionala a Undo-ului ca proceduri de inversare câte una la un moment dat, nu se furnizeaza o functie Undo pentru setarea numelui fisierului.

Undo explicativ

Din versiunea 6.0 Microsoft Word for Windows poseda un Undo neobisnuit, numit Undo multiplu de grup (group multiple Undo). Acesta este multinivel si arata o descriere contextuala a fiecarei operatii din stiva Undo într-un combobox din toolbar. Putem examina lista pentru a vedea operatiile trecute si a selecta câteva asupra carora dorim sa facem Undo. Totusi nu procedam asa ci mai degraba inversam toate operatiile pâna în punctul dorit inclusiv. Odata ce am selectat una sau mai multe operatii pentru a le aplica Undo, lista operatiunilor inversabile este acum disponibila în ordine inversa în combobox-ul Redo, care lucreaza la fel ca Undo. Putem selecta la fel de multe operatii, câte dorim pentru a le face Redo, iar toate operatiile pâna în acel punct vor fi refacute.

Pentru acest lucru programul ofera doua aspecte vizuale. Daca utilizatorul selecteaza de exemplu al cincilea element din lista acel element din lista si cele patru care îl preced vor fi marcate (highlight). De asemenea textul legenda va spune - Undo 5 actions. Referitor la modul cum a fost construit acest text legenda de catre programatori, faptul ca el a trebuit sa fie adaugat indica faptul ca utilizatorii aplicau un model mental diferit. Utilizatorii îsi imaginau ca putea desfasura lista pur si simplu si sa aleaga o singura actiune din cele trecute pentru Undo. Programul nu ofera aceasta optiune ca urmare au fost puse semne.