Documente online.
Username / Parola inexistente
  Zona de administrare documente. Fisierele tale  
Am uitat parola x Creaza cont nou
  Home Exploreaza
Upload


loading...



















































PROTEJAREA UTILIZATORULUI - INTERFETE

Informatica




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.



FIG28

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.

FIG29

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.



loading...











Document Info


Accesari: 685
Apreciat:

Comenteaza documentul:

Nu esti inregistrat
Trebuie sa fii utilizator inregistrat pentru a putea comenta


Creaza cont nou

A fost util?

Daca documentul a fost util si crezi ca merita
sa adaugi un link catre el la tine in site

Copiaza codul
in pagina web a site-ului tau.




Coduri - Postale, caen, cor

Politica de confidentialitate

Copyright © Contact (SCRIGROUP Int. 2020 )