Protejarea utilizatorului - tratarea mesajelor de eroare

PROTEJAREA UTILIZATORULUI

Sfarsitul erorilor

Eliminarea casetei de mesaj de eroare

Eliminarea mesajelor de eroare nu implica doar respingerea codului care in mod curent arata caseta de mesaj de eroare lasand insa ca programul sa crape daca problema apare. Programele noastre ar trebui modificate astfel incat sa nu fie susceptibile la aceasta problema. Mesajele de eroare nu pot fi smulse din program pur si simplu. Trebuie inlocuita 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 intai sa eliminam posibilitatea ca utilizatorul sa greseasca devci trebuie schimbata mentalitatea despre mesajele de eroare. In loc sa presupunem ca mesajele de eroare sunt normale ele trebuie gandite 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 plangeri de la utilizator nu inseamna ca sunt multumiti cu mesajele de eroare pe care le intalnesc.

Casete de dialog de tip buletin

Familiara caseta de mesaj de eroare este in mod normal un dialog modal care opreste toate procesele anterioare ale programului pana cand 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 in 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, raportand starea unei proceduri de durata. In timpul procesului dialogul ofera utilizatorului un buton CANCEL pentru terminare daca acesta se razgandeste 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 in alta parte nu-l va putea vedea sau il 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 aceste casete de mesaje de eroare alerteaza utilizatorul asupra problemelor serioase. Aceasta este o greseala de conceptie larg raspandita. Majoritatea casetelor de mesaj de eroare informeaza utilizatorul despre inabilitatea programului de a lucra in mod flexibil.

In 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 cand utilizatorul a esuat in atingerea unui nivel de perfectiune apropiat de cel al UCP-ului, atitudine numita silicon sanctimon. Cand 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 decat 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. Cand utilizatorii vad o caseta de mesaj de eroare este ca si cand 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 punand in program astfel de interactiuni. Multi proiectanti si programatori de interfete utilizator lucreaza facand aceasta greseala de conceptie pornind de la ideea ca oamenilor fie le place, fie au nevoie sa li se spuna atunci cand gresesc. Presupunand ca oamenilor le place sa li se spuna cand gresesc ignora natura umana. Multi se simt agasati si deranjati cand sunt atentionati de greselile facute si ar prefera sa nu stie cand au gresit.

O metoda se eliminare a mesajelor de eroare este ca atunci cand se receptioneaza un input, programul sa presupuna ca probabil el este cel care nu a inteles si nu ca utilizatorul nu este bine informat. Daca ne gandim bine majoritatea buletinelor de eroare raporteaza utilizatorului cand programul ajunge confuz. Marea majoritate a programatorilor gandesc ca utilizatorii fac greseli si in consecinta isi 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 impiedicati sa mai introduca numere invalide. In loc sa obligam utilizatorul sa tasteze alegerea sa vom prezenta o lista de alternative posibile din care sa aleaga.

Utilizatorii calculatoarelor nu arata intelegere 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 incapatanarea programului de a trata lucrurile intr-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 in fata unor grupuri de utilizatori ca mesajele de eroare ar trebui sa dispara acestia in general vor fi de acord. Daca insa am face aceeasi afirmatie in fata programatorilor acestia vor protesta vehement. Aceasta intareste convingerea ca prezenta casetelor cu mesaje de eroare se datoreaza in principal programatorilor si nu utilizatorilor. Acest lucru aminteste de o dezbatere simulara inceputa odata cu lucrarile lui Edsgar Dijkstra, inventatorul programarii structurate, care a dovedit ca instructiunea Goto poate fi eliminata din limbajele de programare de nivel inalt. Programatorii anilor 70 si cei care au utilizat limbajul de asamblare aveau posibilitatea de a sari aleator si fara urma oriunde in 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 in ceea ce priveste intelegerea si intretinerea 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 in cazul utilizarii casetelor de mesaje de eroare. Cand 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 cat 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 in mod frecvent si usor la sau de la retele.

Este cumva o eroare daca incercati sa imprimati doar pentru a afla ca nu este conectata nici o imprimanta ? Este o eroare daca fisierul pe care-l editati rezida in mod normal pe un drive care nu mai este abordabil? Sa fie oare o eroare daca modem-ul de comunicatie nu mai este introdus in calculator? Se considera ca aceste imprejurari mentionate mai sus nu trebuie tratate ca erori. Daca incercam 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 cand se reconecteaza la o imprimata, cat timp are documente neimprimate in coada sa de asteptare. Acesta trebuie sa fie un aspect normal de zi cu zi nu o eroare. Este exact la fel si in cazul fisierelor. Cea mai frecventa cauza a mesajelor de eroare consta in a raspunde utilizatorului care solicita o resursa anume si care nu este disponibila. Eroarea poate fi eliminata asigurand ca programul sa nu ofere utilizatorului lucruri care n-ar putea fi prezente. Daca programul ofera in locul campurilor 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 in realizarea unui job si care intrerupe 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 intotdeauna 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 inseamna 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, spunand utilizatorului totul. Programul trebuie sa ofere cel putin o solutie implementata chiar acolo in 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 intr-o stare de lucru, incluzand si informatii de genul - cam cat 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 decat impecabila.

Gestiunea exceptiilor

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

Alerte

Atunci cand 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 intr-o alta fereastra pentru acest lucru. Daca programul considera o actiune nejustificata el ar trebui sa marturiseasca acest lucru in acelasi loc in care are loc actiunea nu intr-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 in figura alaturata este un exemplu clasic privind felul in care alertele se tin scai de utilizator.

Dialogul Find forteaza deja utilizatorul sa apese Cancel atunci cand s-a terminat cautarea dar o caseta de alerta supraimpusa intrerupe fluxul butoanelor - intai se apasa OK din alerta, apoi CANCEL din Find.

Daca informatia asteptata de alerta era construita in 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 cateva forme pentru facilitatea casetelor de mesaj intr-o singura linie de cod. Construirea unui afisaj de stare animat in interfata unui program poate necesita o mie sau multe linii de cod. Intr-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 in 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

Cand un program nu se simte increzator in actiunile sale adesea solicita utilizatorului aprobarea actiunilor sale printr-o caseta de dialog - aceasta se numeste confirmare (confirmation) si arata la fel ca in figura de mai jos.

Uneori confirmarea este oferita astfel incat 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 in schimb o confirmare pentru a da utilizatorului alternativa. Confirmarile vin intotdeauna 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 in soft atunci cand programatorul ajunge intr-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. In 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. In timpul dezvoltarii programului, programatorii detecteaza numeroase situatii cand simt ca nu pot da o rezolvare adecvata, in aceste locuri vor insera coduri de transfer al responsabilitatii si pot introduce casete de dialog de confirmare. Programatorii nu considera ca dialogurile de confirmare fac parte din interfata utilizator, insa fac parte integranta !

Referitor la mesajele de confirmare - ele merg doar atunci cand sunt neasteptate. Acest lucru nu este remarcabil pana cand nu este examinat in context. Cand confirmarile sunt oferite in locuri uzuale utilizatorul se va deprinde repede cu acestea si le va indeparta fara sa se mai uite; astfel ca indepartarea acestora devine o rutina la fel ca si aparitia lor. In cazul in 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 indeparta. Pentru ca aceste casete de confirmare sa mearga ele trebuie sa apara doar atunci cand sunt asteptate. Deci confirmarea trebuie sa apara doar atunci cand utilizatorul a apasat aproape definitiv pe butonul NO si sa nu apara niciodata atunci cand utilizatorul (pare ca) apasa pe butonul YES.

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

Ea apare de fiecare data cand dorim sa spunem YES deci cand apasam intotdeauna 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 cand 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 langa 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 intreba. 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. In loc sa intrebe in avans printr-o caseta de confirmare sa lasam utilizatorul sa lanseze comanda Stop&Undo asupra acelor rare ocazii cand actiunile programului nu sunt la momentul corespunzator.

Majoritatea situatiilor pe care in 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 intr-un director temporar unde sa fie pastrat cam o luna inainte de a fi sters fizic. De fapt Recycle Bin din Windows 95 foloseste aceasta strategie, exceptand acea parte care sterge automat dupa o luna - utilizatorului ii revine sarcina de trata manual aceasta problema.

Mai bine decat sa actionam in graba si sa fortam utilizatorul sa recurga la Undo ne putem asigura ca programnul sa ofere utilizatorului in mod direct informatiile suficiente si adecvate astfel incat acesta sa nu lanseze niciodata o comanda necorespunzatoare. Programul ar trebui sa utilizeze feedback vizual bogat astfel incat utilizatorul sa fie informat in mod constant. Putem sa ii oferim utilizatorului protectie prin marcaje consistente si clare. Putem construi gizmo-urile izolate, colorate intens, plasate langa listbox-uri care dezvaluie totul despre datele respective. Cu mult mai uzuale decat actiunile reversibile sunt acele actiuni care sunt usor reversibile dar care sunt inca 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 in 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 isi protejeaza propriile creatii, iar mesajele de eroare sunt simptomele acestei protectii, dar proiectarea imperativa este cea care aduce programul in 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 in software. Programatorii ridica bariere in interfata utilizator astfel incat datele proaste sa nu patrunda niciodata in program. Aceasta stare pur interna se numeste in mod uzual integritatea datelor (data integrity). Integritatea datelor arata ca exista o lume de informatii haotice care inainte de a ajunge in calculator trebuie filtrate si curatate. Soft-ul trebuie sa aiba o bariera de protectie. Toate datele sunt facute valide in punctul de intrare. Orice lucru care nu se incadreaza sau este suspect este respins, dar datele care au trecut de bariera de protectie se presupune ca au satisfacut criteriile riguroase. Odata ajuse inauntru se presupun valide. Avantajul este acela ca odata ajunse in 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 - in loc sa tinem datele proaste in 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 in mod robust - numim aceasta imunitatea datelor (data immunity). In 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 hartie dar in lumea reala apar unele probleme. E vorba in special de datele corecte din momentul introducerii acestora mai degraba decat atunci cand si daca este nevoie de datele corecte. Imunitatea datelor nu tolereaza datele proaste atunci cand e nevoie de date corecte. Totusi tolereaza date proaste in sistem atunci cand 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 atat de larg raspandita si acceptata ca proiectare software buna incat hegemonia ei este rareori pusa sub semnul intrebarii. 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, intiparesc in tot ce fac in mod inconstient principiul integritatii datelor.

Pentru a implementa imunitatea datelor programele trebuie invatate sa se uite in context inainte de a face ceva si sa solicite ajutor. Majoritatea soft-ului realizeaza orbeste operatiile aritmetice asupra numerelor fara sa le examineze mai intai. Conform integritatii datelor programul presupune ca un camp numeric trebuie sa contina un numar. Trebuie sa invatam 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; insa 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 incat atunci cand si daca utilizatorul ajunge sa examineze problema sa gaseasca note complete si clare despre ce s-a intamplat si care sunt pasii pe care i-a facut programul. Integritatea datelor ajuta la reducerea solicitarii programatorului nespunand nimic din ceea ce face pentru utilizator.

Feedback auzibil

In mediile de introducere a datelor functionarii profesionisti in introducerea datelor - operatori, culegatori, dactilografe - stau cu orele in fata ecranelor video si introduc date. Acestia urmaresc mai degraba textul documentului de introdus decat ecranul video. Daca se intampla sa introduca ceva eronat ei trebuie informati atat auditiv cat si vizual. Nu discutam despre beep-ul care acompaniaza casetele de mesaj de eroare.

Atunci cand utilizarea cu succes a instrumentelor produce sunet numim aceasta feedback auzibil pozitiv (positive audible feedback). Ori de cate 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 in 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 cand se intampla ceva rau se numelte feedback auzibil negativ (negative audible feedback). Feedbak-ul negativ are cateva lucruri impotriva sa. Deoarece el este emis in momentul cand s-a descoperit problema in 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 cand sa stie cand lucrurile merg bine. Ei au nevoie sa stie cand anume actioneaza cum trebuie dar asta nu inseamna ca le si place sa tot auda asta.

In mod garantat sistemele de feedback negativ sunt mai putin apreciate decat 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 in general prefera audio. In 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, tastand formule intr-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 in 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 in mod constant feedback auditiv pozitiv astfel incat programul va incepe sa actioneze ca un partener ajutindu-l sa fie constient de starea activitatii sale. Deci cat de serioasa este pierderea datelor? In situatia culegerii datelor, a sari un camp este ceva serios dar de obicei campul va fi introdus mai degraba gresit decat omis. Programul poate ajuta usor ca functionarul sa detecteze problema si sa o schimbe intr-o intrare valida fara a opri prelucrarea. Daca functionarul este determinat sa omita campurile necesare problema este functionarul si nu programul. Windows 95 ofera un exemplu cat se poate de rezonabil pentru axioma - verificam nu editam - chiar in 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 in urma un raport al progresului sau pana 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 putand 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 gandita 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 atat de cotidiene incat daca le gandim 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 razgandeasca. Secretul proiectarii unui Undo reusit este a-l crea presupunand ca acesta suporta o parte normala din setul de lucru zilnic al instrumentelor programului Undo trebuie proiectat astfel incat sa fie mai putin un instrument pentru reversul erorilor si mai mult unul pentru a suporta explorarea. In 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 - in 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 reprezentand o parte neplacuta si vag dizgratioasa pentru job-ul programatorului.

O contributie semnificativa pe care Undo o aduce utilizatorului este pur psihologica - il incurajeaza. In mod curios, adesea utilizatorii nu se gandesc la Undo pana cand nu au nevoie de el. Desi comun in 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. Cand 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 atat o componenta procedura cat 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 intre 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 in prezent sunt Undo simplu si Undo multiplu. Undo simplu (single undo) este varianta de baza inversand in 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 in ordine invers temporala.

In mod normal Undo este invocat printr-un element de meniu sau un buticon avand o eticheta nemodificabila. Utilizatorul stie ca actionand 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 in ToolTips este un compromis acceptabil. Marea limitare a unui Undo pe un singur nivel, apare atunci cand utilizatorul nu remarca imediat greseala. In unele programe orice click de mouse, oricat 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. Selectand Undo in mod repetat fiecare actiune poate fi inversata in 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, adancimea acesteia putand fi setata de utilizator ca o preferinta in avans. De ficare data cand este invocat Undo, se realizeaza undo incremental adica inversarea celei mai recente operatii, inlocuirea sau eliminarea datelor daca este necesar si indepartarea 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 in 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 in 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 intr-un Undo multiplu. Daca utilizatorul doreste sa revina inapoi vreo duzina de operatii sau chiar mai multe, el apasa butonul Undo de cateva ori asteptand ca lucrurile sa revina la normal. In acest caz se poate intampla sa apese pe Undo de mai multe ori caz in care se trece peste situatia dorita. Redo rezolva aveasta problema permitand Undo pentru Undo punand inapoi ultima actiune buna. Practic Redo nu este altceva mai mult decat 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 intregului document in stilul in care o camera de luat vederi capteaza o imagine instantaneu. Metoda implica intregul document ea este implementata intotdeauna utilizand direct sistemul de fisiere. Marea diferenta dintre milestoning si alte sisteme Undo este faptul ca utilizatorul trebuie sa solicite in mod expres aceasta metoda prin salvarea documentului. Odata ce a facut aceasta poate trece la modificarea originalului in deplina siguranta. Daca mai tarziu 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 suportandu-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 intregul document in starea sa curenta.

Pasul in care se revine la versiunea milestoned precedenta este ceea ce numim intoarcere (reversion). Facilitatea de intoarcere 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 impreuna cu alte cateva informatii despre fiecare versiune precum ora si ziua cand a fost inregistrata, numele persoanei care a facut inreistrarea, lungimea si alte cateva note optionale introduse de utilizator. Utilizatorul ar putea alege una din aceste versiuni, programul putand reveni la aceasta indepartand orice schimbari interpuse.

O varianta relativa de milestoning si de intoarcere este cea pe care o numim congelare (freezing). Opus cu milestoning congelarea implica blocarea datelor in document astfel incat acestea sa nu poata fi modificate. Orice a fost introdus devine nemodificabil desi pot fi adaugate noi date. Paragrafele existente sunt de neatins insa altele noi pot fi adaugate intre cele vechi. Aceasta metoda este cu mult mai utila pentru un grafic decat pentru un document text.

In casetele de dialog nu sunt functii Undo individuale. In schimb Undo este o functie globala stans legata de program care inverseaza ultima actiune referitor la ceea ce s-a facut prin manipulare directa intr-o caseta de dialog. Acest lucru face ca Undo sa fie problematic pentru obiectele incluse (embedded) care folosesc modelul OLE. Daca utilizatorul face modificari intr-un spreadsheet inclus intr-un document Word apoi face click in 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 incetand 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 il opresc fara a salva datele nu pot face Undo. Sunt insa multe operatii care desi nu pot fi trucate ca un Undo sunt usor reversibile. De exemplu cand salvam pentru prima data un document ni se permite in 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 inseamna realizarea unui alt fisier sub un nume nou lasandu-l pe cel vechi nemodificat sub vechiul sau nume. E drept ca schimbarea numelui de fisier este o caracteristica Undo dorita in mod frecvent. Deoarece nu se incadreaza in viziunea traditionala a Undo-ului ca proceduri de inversare cate 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 intr-un combobox din toolbar. Putem examina lista pentru a vedea operatiile trecute si a selecta cateva asupra carora dorim sa facem Undo. Totusi nu procedam asa ci mai degraba inversam toate operatiile pana in punctul dorit inclusiv. Odata ce am selectat una sau mai multe operatii pentru a le aplica Undo, lista operatiunilor inversabile este acum disponibila in ordine inversa in combobox-ul Redo, care lucreaza la fel ca Undo. Putem selecta la fel de multe operatii, cate dorim pentru a le face Redo, iar toate operatiile pana in 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 il 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 isi 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.