O abordare pragmatica spre aplicarea conceptului psihologic de model mental

O abordare pragmatica spre aplicarea conceptului psihologic de model mental

In sectiunea precedenta, am incercat sa expunem pe scurt unele dintre cele mai relevante definitii ale modelelor mentale. Deoarece in acest volum ne centram pe interactiunea om-calculator, ne vom axa pe proiectarea si analiza sistemelor interactive. Pentru aceasta, avem nevoie de o abordare pragmatica ce ne permite sa aplicam descoperirile psihologiei in intelegerea interactiunii dintre sisteme si utilizatorii umani. O abordare pragmatica poate fi derivata din analize ca cea a lui Norman (1983). Autorul considera a fi model mental orice tip de reprezentare mentala ce se dezvolta in interactiune cu sistemul si face posibila si faciliteaza interactiunea cu sistemul. De fapt, Van der Veer (1990) a gasit ca mai multe reprezentari pot fi folosite de catre subiecti diferiti in situatii identice.

a. Punctul nostru de vedere asupra modelelor mentale

Urmand aceasta abordare pragmatica, ideile noastre despre modelele mentale pot fi descrise dupa cum urmeaza. In timp ce lucreaza cu sistemul, utilizatorii activeaza un model mental construit in WM din cunostintele anterioare (stocate in LTM) pe care le au in aceasta situatie si din informatia pe care o primesc din mediu (in principal de la sistem si din cerintele sarcinii). In timp ce se confrunta cu noul sistem, singurele cunostinte anterioare disponibile se bazeaza pe experienta anterioara cu alte sisteme similare. In functie de natura sistemului, aceste cunostinte anterioare pot fi mai mult sau mai putin potrivite situatiei. Acest lucru duce la proiectarea noului sistem astfel incat acesta sa fie capabil sa comunice informatia corecta despre modul de folosire, in principal prin intermediul interfetei sau al imaginii sistemului. Cu alte cuvinte, imaginea sistemului ar trebui sa poata sa ofere informatia necesara pentru a dezvolta modelul mental potrivit al utilizatorului. Pe de alta parte, proiectarea trebuie sa ia in calcul limitele si procesele WM, pentru a preveni supraincarcarea informatiei si confuzia utilizatorului si pentru a ii asista sa aiba cunostinte disponibile oricand sunt cerute de actiunea adecvata situatiei. Urmatoarea intrebare pe care trebuie sa o solutionam este aceea a tipului de cunostinte care trebuie reprezentate in interfata sistemului.

b.     Modelul mental "potrivit"

In acest moment, este important sa elaboram ideea modelului mental "potrivit". Dupa cum am declarat mai devreme, un model mental al utilizatorului nu este o descriere acurata a sistemului si a modului de lucru cu el, ci o versiune simpla a sistemului. De fapt, modelul mental al utilizatorului nu este nici complet, nici corect in detaliu. In acord cu Norman (1983), luam in calcul limitele pe care modelele mentale le au (vezi explicatiile despre ideile lui Norman in sectiunea 2). Consideram ca un model mental a fi potrivit atata timp cat este aplicabil din punct de vedere functional pentru a planifica si executa o sarcina cu sistemul, precum si suficient din punct de vedere functional pentru a evalua rezultatele actiunilor noastre si a interpreta orice actiune neasteptata a sistemului.

c.      Cum sa proiectam pentru un model mental potrivit?

Urmarind abordarea pragmatica, pentru a intelege rolul jucat de modelele mentale in imbunatatirea procesului de proiectare este necesar sa analizam:

1.     Ce trebuie sa stie utilizatorii pentru a folosi sistemul in sarcina lor. Utilizatorii trebuie sa inteleaga, adica sa aiba destule cunostinte si sa primeasca destula informatie de la sistem  pentru a dezvolta un model mental adecvat oricand au nevoie de el. Aceasta inseamna ca trebuie sa poata intelege functionalitatile relevante ale sistemului pentru ceea ce fac, si sa poata intelegere dialogul necesar pentru a folosi cu adevarat sistemul. Vom intra in detalii privind tipul de cunostinte de care au nevoie utilizatorii in sectiunea 1.

2.     Ce tipuri diferite de utilizatori sunt (cand se aplica) pentru ca sistemul sa fie proiectat. De exemplu, In proiectarea unui bancomat, sunt mai multe roluri ale utilizatorilor care trebuie considerate:

(a)   clientul care vrea sa retraga banii si vrea sa inteleaga cum sa opereze cu cardul si cu codul PIN;

(b)   angajatii bancii care trebuie sa reaprovizioneze cu bancnote si hartie pentru chitante, precum si sa-si mentina performanta;

(c)    anumiti avocati care trebuie sa analizeze daca o tranzactie privind contul clientului poate fi rezultatul unei utilizari frauduloase a bacnomatului, pentru care ei trebuie sa inteleaga procesul si numarul inregistrarilor de tranzactii.

Desigur, oamenii cu rolul (b) sau (c) pot, in anumite situatii, sa joace si rolul (a). In sectiunea 4.2 vom mentiona analiza rolurilor ca parte a analizei sarcinilor.

3.     Care sunt cerintele pe baza carora inginerii sa construiasca. Aici trebuie sa exploram ce tipuri de cunostinte trebuie sa specifice proiectantii pentru a face ca sistemul sa poata fi folosit. Proiectantii trebuie sa dezvolte specificatii din punctul de vedere al posibilului utilizator. Primul tip de specificatii care trebuie dezvoltat este centrarea pe cunostintele necesare viitorului utilizator. In 2.1. vom numi aceste specificatii ca MVU (Masina Virtuala a Utilizatorului) si vom elabora pe baza elementelor ei. In proiectarea sistemelor interactive complexe, consideram situatia in care utilizatorii trebuie sa joace diferite roluri (caracterizate de sarcini tipice), fiecare dintre ele, prin definitie, necesitand diferite cunostinte pentru aplicarea sistemului in munca lor. Pentru fiecare rol, proiectantii trebuie sa specifice cunostintele de care utilizatorul cu rolul respectiv are nevoie pentru a manui sistemul pentru sarcinile specifice rolului. Cu alte cuvinte, proiectantii trebuie sa dezvolte un model de sistem bazat pe combinarea MVU pentru diverse roluri. Astfel, specificand un "singur" (si complet) sistem interactiv, va insemna specificarea unor diferite MVU sau structuri de cunostinte necesare diverselor tipuri de utilizatori, mai mult sau mai putin suprapuse. Acest ultim model combinat este echivalent cu ceea ce Norman (1983) a etichetat drept "model conceptual" (vezi 2.1.1.). Modelul conceptual se refera la cunostintele necesare utilizatorilor ca intreg pentru a folosi eficient sistemul. Doar bazandu-ne pe acest model conceptual, proiectarea software-ului sau a hardware-ului trebuie sa inceapa.

1. De ce tip de cunostinte au nevoie utilizatorii

In timp ce pentru utilizatorul uman, sistemul ca atare este un "obiect" mai mult sau mai putin monolitic, pentru proiectant este deosebit de important sa afle ce tip de cunostinte este necesar si, deci, trebuie specificat. In primul rand, sistemul trebuie sa foloseasca un limbaj care sa fie inteles clar si imediat de utilizator in relatie cu intentiile sale si cu sarcina. Dar in sistemele interactive, este nevoie de cunostinte mult mai complexe. Utilizatorii trebuie sa fie capabili sa creeze un model mental a ceea ce se petrece in interactiune, bazandu-se pe cunostintele disponibile in memoria umana si pe informatiile oferite de sistem in momentul potrivit. Si, asa cum vom vedea, pentru a facilita procedura de proiectare, este important sa se specifice cunostintele necesare si informatia ce trebuie oferita, ca o faza de inceput a proiectarii sistemului.

In alineatele urmatoare vom explica tipurile de cunostinte pe care trebuie sa le aiba utilizatorii pentru a interactiona cu sistemul complex. De fapt, utilizatorii au nevoie de doua tipuri de cunostinte:

1. Ce poate sa faca sistemul pentru ei, mai precis care este "functionalitatea" sistemului. Sectiunea aceasta va detalia acest aspect.

2. Cum sa comunice cu sistemul. Acest tip de cunostinte este denumit "dialog".

Ambele tipuri de cunostinte trebuie luate in considerare separat de catre proiectanti, deoarece ambele duc la specificatii separate ale proiectarii UMV. Pe de alta parte, deciziile asupra ambelor tipuri de specificatii ale proiectarii ar trebui sa se faca pe baza relatiilor dintre ele, adica dialogul ar trebui sa se "potriveasca" functionalitatii. De exemplu, daca se intentioneaza ca functionalitatea sa ofere comunicare sincrona intre un utilizator si alta persoana, dialogul ales trebuie sa ofere un mod "natural" de comunicare om-la-om. Vorbirea ar putea fi mai naturala decat textul scris si textul scris ar putea fi mai natural decat alegerile din meniu pentru a indica tipul actelor vorbirii. In sectiunea IV a acestui volum, dialogul va fi tratat in detaliu. Din punctul de vedere al utilizatorului, aproape nu va exista o distinctie clara intre functionalitate si dialog. Utilizatorul va avea nevoie de un model mental adecvat pentru a desfasura sarcina cu sistemul, care pentru el consta in aplicarea unui dialog pentru a avea acces la functionalitate.

In paragrafele urmatoare, vom arata diferite tipuri de cunostinte necesare utilizatorilor pentru a construi un model mental adecvat cu privire la functionalitate.

1.1. Ce se intampla in spatele ecranului

In mare masura, utilizatorului nu-i va pasa de "ce e inauntru". Pentru multi utilizatori din prezent si majoritatea celor viitori, sistemele de operare, procesoarele, capacitatea memoriei, viteza de transfer, etc., sunt total irelevante atata timp cat performanta sistemului este acceptabila din punctul de vedere al capacitatii umane de procesare a informatiilor. Daca anumite procese "interne" iau mai mult de cateva secunde sau nu pot fi prevazute de utilizator, sistemul ar trebui sa ii aduca la cunostinta utilizatorului exact aceasta, si nimic altceva. Pe de alta parte, anumite lucruri care au loc in spatele ecranului sunt necesare pentru intelegerea interactiunii si realizarea cu succes a sarcinii propuse (ex: "acest obiect este inca pe clipboard-ul meu?", "dosarul original este neatins dupa ce am facut operatiunea de salvare?"). Acest tip de cunostinte este intr-adevar necesar pentru posibilii utilizatori (utilizatorii care compun texte in "MS-word", in acest exemplu).

1.2. Ce se intampla in acest computer

Sistemele interactive curente rareori sunt de sine statatoare ("stand-alone"). Chiar daca masina este conectata la lumea exterioara doar prin schimbarea dischetei, utilizatorii trebuie sa stie motivele pentru anumite evenimente neasteptate si sa ia masuri de interactiune sigura, de incredere si eficienta cu "agentii" externi. In cazul unor conexiuni mai sofisticate, utilizatorii (depinde de rolurile si sarcinile lor) trebuie sa inteleaga aspecte ale conexiunii locale si la nivel global, si ale procedurilor corecte (semnaturi, autentificari, etc.). In anumite tipuri de sarcini, locatia prezenta a anumitor procese trebuie sa fie cunoscuta si inteleasa ("codul meu pin este transportat prin retea la banca sau este validat local la terminal?").

1. Ce structura organizationala se afla in spatele computerului meu

In cazul sistemelor interactive folosite in numar din ce in ce mai mare, utilizatorul si masina nu sunt izolati sau deconectati de la sistem. Un utilizator trebuie sa inteleaga ca alti utilizatori, unii cu rol identic, altii cu roluri diferite, sunt jucatori ai aceluiasi joc, influentand procesul total. Utilizatorii trebuie sa stie ca alti utilizatori cu un anumit rol, se descurca cu procesele de lucru sau isi pot monitoriza actiunile. In plus, utilizatorii trebuie sa inteleaga ca altii, cu diverse roluri, vor avea "drepturi" diferite in relatie cu obiectul sistemului ("cine poate sa verifice sau sa modifice sau sa stearga email-ul pe care tocmai l-am trimis?").

1.4. Ce domeniu al sarcinii este disponibil prin computerul meu

Sistemele interactive sunt destinate sarcinii utilizatorului. Dar faptul ca IT este folosit pentru a sustine sarcina cere o intelegere clara din partea utilizatorului a acelei parti a domeniului sarcinii care este disponibila pentru delegarea masinii si ce ar trebui/poate sa fie facut mai bine in alte moduri ("traditionale?"). De exemplu, daca un grup e designeri vestimentari aplica un sistem interactiv pentru munca lor, cateva sarcini pot fi delegate cu o valoare adaugata considerabila. O modificare benefica in domeniul sarcinii ar putea fi facilitatea de a cauta baze de date multimedia ale unor videoclipuri din spectacolele de prezentare a modei, imagini ale oamenilor si locatii pe care hainele intentioneaza sa le serveasca, interviuri cu potentiali clienti, lucrari de arta caracteristice mediului cultural al posibililor cumparatori, etc. Pana acum, poate deoarece mijloacele media potrivite nu sunt disponibile inca, alte parti ale domeniului sarcinii nu sunt sustinute suficient. Exemple de sarcini din acest domeniu sunt evaluarea calitatii texturii materialului sau schitele impresioniste ale procesului de miscare a hainelor intr-o etapa anterioara chiar dezvoltarii indeajuns de detaliate pentru ca un manechin sa fie adecvat "imbracat".

1.5. Care sunt procesele si aspectele legate de timp pentru delegarea de sarcini computerului meu

Un aspect specific al aplicarii IT pentru a sustine sisteme interactive este acela ca tehnologia are o scala a timpului diferita de cea umana a procesarii informatiei. In multe cazuri, aceasta duce la fenomene triviale cum ar fi sisteme ce ofera reactii la cerintele utilizatorului uimitor de repede sau, din contra, enervant de lent si de neprevazut. O problema si mai grava are loc cand computerul este o fatada pentru procese a caror caracteristici temporale sunt, prin definitie, sau intentionat, la o scala non-umana (Hoc, 1989). De fapt problema poate lua una dintre formele: 1) procesul este ,,lent'' in furnizarea feed-back-ului (monitorizarea proceselor din fabricile chimice), dar utilizatorul trebuie sa anticipeze rezultatul anterior actiunilor, in vederea optimizarii continuarii proceselor; 2) procesul este ,, rapid'' in indeplinirea sarcinilor ireversibile (ex. delegarea anumitor operatii de zbor pilotului automat) si, in consecinta, utilizatorul urmeaza sa aprecieze consecintele expectate in toate detaliile care afecteaza siguranta si fidelitatea. In fapt, ambele cazuri prezentate mai sus, necesita acelasi tip de intelegere si cunostinte despre utilizator. Anumite cazuri inregistrate, in care pilotii au ajuns sa se "lupte" cu pilotii automati sunt ilustratii ale situatiilor in care acest tip de cunostinte nici macar nu au fost luate in considerare. Acelasi lucru poate fi identificat in inregistrari ale dezastrelor din uzinele nucleare in care consecintele delegarii sarcinii nu au fost modelate si unde, in consecinta, indici de eroare erau complet inadecvati si au avut o influenta negativa asupra procesului uman de luare a deciziilor.

2. Ce tip de intelegere a cunostintelor utilizatorilor este necesar proiectantilor

Tinand cont de tipurile diferite de cunostinte necesare utilizatorilor pentru a opera un sistem constituie punctul de plecare, dar proiectantii au nevoie de mai mult decat atat. Ei trebuie sa dezvolte un stil adecvat de dialog care sa se potriveasca cu functionalitatea ca si cu situatia. Proiectarea tehnologiei este astfel tradusa in construirea "perspectivei" modelelor de cunostinte, unde prescriptia nu este realizata pentru utilizatori ci pentru inginerii care vor trebui sa implementeze sistemul. Bineinteles, in prescrierea cunostintelor, intelegerea la nivelul ergonomiei cognitive a procesarii informatiei de catre oameni sunt de o importanta capitala. Sistemul trebuie sa fie usor de inteles si utilizat, cerand cel mai scazut nivel de efort din partea utilizatorului. Mai mult, pentru proiectanti exista, in afara functionalitatii si dialogului, o a treia componenta de care trebuie sa se ocupe: reprezentarea sistemului pentru utilizatori (vezi 2.1.1. unde facem referire la conceptul lui Norman de "imagine a sistemului"). Uneori utilizatorii au nevoie de informatii suplimentare in vederea crearii modelului mintal care sa se potriveasca situatiei actuale. Daca proiectantul nu se poate astepta ca aceasta informatiei sa fie accesibila imediat utilizatorului (adica aceasta nu se afla in memoria de lucru) interfata poate sa o ofere. Sa presupunem ca utilizatorul incearca sa afle informatii de pe site-ul web al companiei de cai ferate Olandeze, si trebuie sa indice numele localitatii-destinatie. Uneori orasele au mai multe nume. De exemplu, in Olanda exista un oras (Haga, sau The Hague in engleza), care in olandeza poate sa fie chemat "Den Haag" sau "s-Gravenhage". Proiectantii versiunii anterioare a site-ului web au implementat un singur nume pentru destinatia in cauza. Daca utilizatorul trebuie sa indice numele destinatiei, acesta va fi foarte recunoscator daca va putea alege in loc sa ghiceasca ce nume va fi acceptat de sistem. Reprezentarea este o facilitate importanta la modul general pentru oferirea informatiei necesare utilizatorilor in dezvoltarea unui model mintal valid al situatiei in care se afla. Din motive ca cele ilustrate aici, reprezentarea este o a treia problema importanta care trebuie luata in considerare de proiectanti in specificarea MVU.

Analiza: Efectele consumului de alcool Analiza: Identitatea de secui

3 Modelarea masinii virtuale a utilizatorului

Multe tehnici de specificare/ descriere au fost dezvoltate pentru a asista (si provoca) designerii in specificarea unui model conceptual adecvat (sau pentru a construi MVU) a unui sistem. Cele mai multe tehnici se bazeaza cel putin partial pe psihologia cognitiva (GOMS, TAG, CCT, precum si modelele dezvoltate din acestea). Luam drept exemplu User Action Notation (UAN - Notarea Actiunii Utilizatorului) (Hix & Hartson, 1993) pentru specificarea si analizarea detaliilor tehnologiei. Pare un candidat excelent pentru formalizarea cunostintelor utilizatorului  necesare in utilizarea sistemului, deci, pentru specificarea MVU. Una dintre caracteristicile principale ale UAN este faptul ca ajuta designerii sa considere separat aspecte diferite ale MVU: functionalitate sistemului este specificata prin ceea ce in UAN apare sub indicatia "conexiunea cu computatia". Diferite componente ale UAN specifica diferite aspecte care trebuie tratate atunci cand se ia in considerare dialogul. "Actiunile utilizatorului" descriu parte dialogului realizata de utilizator in vreme ce "starea interfetei" si "actiunile interfetei" descriu aspecte ale dialogului realizate de sistem. "Starea interfetei" face referire la aspecte ale dialogului care nu sunt vizibile la un anumit moment dar care sunt relevante pentru utilizator astfel incat acesta sa inteleaga. Aspecte ale dialogului care sunt imediat vizibile utilizatorului si apartin aspectului reprezentational, sunt numite "actiuni ale interfetei" in UAN.

La inceput, UAN (Hix & Hartson, 1993) permite specificarea urmatoarelor aspecte:

• Toate "actiunile utilizatorului" la nivelul key-strokes (apasarea butonului mouse-ului, inputul vocal, desenele de pe drawing pads, etc.). Acestea sunt exact activitatile pe care utilizatorul trebuie sa le faca intr-o anumita situatie si, deci, actiunile care ar trebui ghidate de un model mintal adecvat.
• "feedbackul interfetei" face referire la elementele semnificative care vor fi prezentate utilizatorului ca miscari ale cursorului, luminari, bipuri, etc. Aceste intrari permit designerului sa specifice locatia, secventa si semnificatia tuturor actiunilor sistemului adresate utilizatorului. De vreme ce in situatia de azi, utilizatorul este confruntat cu evenimente ale sistemului indicate de actiuni ale agentilor sistemului sau ale altor utilizatori, "feedbackul interfetei" are nevoie sa fie schimbat de termenul "actiunea interfetei", reprezentat de o coloana specifica. Din punctul de vedere al utilizatorului sistemul actioneaza fie ca reactie  la comportamentul utilizatorului, fie ca rezultat al actiuni unui alt agent. Designerii ar trebui sa retina ca este important pentru utilizator sa aiba un model mintal clar in interpretarea actiunilor sistemului. Sistemul ar putea doar sa reactioneze, de ex., dand utilizatorului feedback despre starea unei comenzi de tiparire care tocmai a fost data de utilizator. Ca alternativa, un eveniment neasteptat poate avea loc care sa provoace comportamentul utilizatorului (ca alarma unui sistem de siguranta, primirea unui nou email, sau o alerta de la sistemul fluxului muncii despre o noua sarcina). Fiecare dintre situatiile din aceste exemple va necesita instantierea/ utilizarea modelului mintal pentru acea ocazie specifica.
• "informatii despre starea interfetei", menite sa descrie starea interfetei si schimbarile de stare care e relevant sa fie cunoscute de catre utilizator (ca "PIN-ul este verificat cu informatii continute pe banda magnetica a cardului"). In aceasta fanta (?) trebuie specificata toata informatia de care utilizatorul are nevoie pentru a intelege si pentru a dezvolta un model mintal valid al interactiunii si ale efectelor acesteia.
• "conexiunea cu computatia" in masura in care este relevant pentru utilizator sa stie, ca "suma de X este extrasa acum din contul dumneavoastra". Din nou, aceasta fanta (?) trebuie sa permita specificarea a tot ceea ce este relevant pentru utilizator, despre ceea ce se intampla "in spatele ecranului" (vezi. 1).

Cateva puncte in plus trebuie adaugate acestui tip de specificare a MVU, mai ales cat e nevoie de preciziune si integritate in legatura cu cunostintele care sunt relevante pentru utilizator pentru ca sa aiba modelul mintal optim intr-un anumit moment al interactiunii. In multe cazuri de interactiune, utilizatorii stiu, sau ar trebui sa stie, ca exista conditii pentru inceperea interactiunii, sau, in alte cuvinte, doar in anumite situatii interactiunea are sens. O extensie utila a instrumentelor de specificare sau formalizare, este specificarea acestor cunostinte ale utilizatorilor ca un descriptor optional pre-stare sau pre-conditie cum este numit in MAD (Scapin & Pierret-Golbreick, 1989). Acesta determina designerii sa descrie cunostinte relevante ale utilizatorilor despre starea pre-conditiilor sistemului pentru ca interactiunea sa aiba sens. De exemplu, cand se sterge un fisier acesta trebuie selectat mai intai.

In unele sisteme exista subsarcini repetitive ca parte a dialogului. Selectarea unui obiect inainte de operarea asupra lui (vedeti paragraful anterior) este un exemplu. Identificarea utilizatorilor inainte de orice tranzactie a carei efecte se rasfrang direct asupra contului, este un exemplu din sistemul bancar. Formalizari ca UAN pot fi adaptate astfel incat sa determine designerii sa specifice interactiuni modulare separate pentru piese reutilizabile ale dialogului. Tehnici ca GOMS ofera aceasta caracteristica standard. Astfel de modelari ajuta la proiectarea cu mai mare consistenta a interfetei, si face designerul constient de structura de cunostinte (si de "chunk-urile de cunostinte) pe care utilizatorii trebuie sa le aiba activate ca parte a modelelor lor mentale. Reutilizarea actiunilor generice este de dorit deoarece poate imbunatatii usurinta de invatare sistemului.

Pentru a face ritmul usor de inteles din punctul de vedere al utilizatorului si pentru a le permite sa dezvolte un model mintal care sa ii ghideze prin sistem in timpul unui proces, orice formalism am alege trebuie sa indice in mod clar cum relatiile temporale se realizeaza intre actiunile utilizatorului si cele ale sistemului:

Simultaneitatea: In acest caz evenimentele sistemului se considera ca au loc in acelasi moment cu actiunea realizata de utilizator, din punctul acestuia de vedere, ca apasarea butonului mouseului si aratarea animatiei corespunzatoare a inconului pe ecran. Designerii ar trebui sa faca aceasta relatie clara utilizatorului prin reprezentarile sistemului. Chiar daca apasarea butonului este procesata de sistem pe durata a cateva milisecunde si este transformata in animatie, pentru utilizator dorim sa sugeram ca actiunea sa de apasare a butonului este conectata in mod direct cu efectul vizibil.

Evenimente consecutive: Acestea ar trebui intelese de catre utilizator ca ocupand o ordine temporala. Secventa este relevanta fie datorita unei relatii cauzale dintre evenimente fie pentru ca diferite procese au loc in interfata si natura exacta a interfetei (locatia in timp a unui proces fiind intrerupta de un alt proces) este relevanta pentru intelegerea sistemului de catre utilizator.

In unele cazuri este foarte important sa modelam actiunea mintala al utilizatorului. Indeosebi daca utilizatorul trebuie sa ia decizii pe baza comparatiei, sau reamintirii cunostintelor sau pe baza rationamentului care implica cunostinte. GOMS a fost una dintre primele tehnici utilizate pentru a modela aceasta. Un set limitat de operatori mentali relevanti este necesar. Figura 7 prezinta cativa operatori mentali utili.

Designerii ar trebui sa se simta liberi in a adauga (si sa intrebe psihologul) cand este necesar. Daca actiunile mentale sunt specificate atunci actiuni ale interfetei pot avea loc in acelasi timp. Aceasta poate fi specificat prin intentia de a asista actiunea mentala (de ex. oferirea de informatii necesare pentru luarea deciziei, prezentarea unei animatii pentru a arata ca sistemul inca asteapta ca utilizatorul sa ia decizia). Cand utilizate, actiunile mentale pot sa ofere intelegerea aspectelor cognitive necesare, si designerul poate fi constient de necesitatea ca utilizatorul sa ia o decizie cu ajutorul elementelor vizibile pe ecran sau din memoria de lucru.

Simboluri                      Semnificatii

WM                   Working Memory

LTM                   Long Term Memory

Recall (x,y)                            Recuperarea lui x din memoria de tip y

Retain (x,y)      Stocheaza x in memoria tip y

Forget (x,y)                           X nu mai trebuie mentinut in memoria de lucru

Find (x,y)          Gaseste x in mediul y (ex. in interfata)

Choose (x,y)                          Alege din x setul de y

FiguraO lista sugerata de actiuni mentale care pot fi specificate in relatie cu MVU

Exista doua reguli pentru relatia dintre actiunile mentale si alte actiuni:

Actiunile mentale nu sunt actiuni reale (fizice) ale utilizatorului catre lumea externa (inclusiv interfata) si pentru aceasta, actiunile interfetei nu pot fi cauzate de ele. Aceasta inseamna ca o actiune a interfetei pe aceeasi linie sau sub actiunea mentala nu este niciodata efectul actiunii mentale ci al unei actiuni a utilizatorului sau al unui eveniment superior actiuni mentale. Cu toate acestea, se poate ca actiunea mentala sa fie facilitata de cunostintele prezentate prin intermediul interfetei. Designerii pot sa fie determinati sa considere acest tip de facilitare tocmai prin specificarea actiunilor mentale.

Actiunea mentala in sine poate fi relationata cu una dintre actiunile interfetei, in functie de contextul actiunii mentale. Structura secventiala a actiunii interfetei, ca citirea identitatii persoanei care incearca sa stabileasca o conexiune telefonica cu o alta persoana. In astfel de cazuri este relationata cu pre-starea interfetei si trebuie explicit specificata ca atare.

Un aspect important in evaluarea aspectelor sistemelor interactive este "usurinta invatarii" ("Ease of learning"), care este relationata cu probleme de design ca numarul regulilor diferite pe care utilizatorii trebuie sa le aplice/implementeze. Daca un sistem are nevoie de mai putine reguli pentru aceeasi functionalitate, sistemul este mai usor de invatat, si utilizatorii vor fi capabili sa aplice reguli chiar si in situatiile noi, prin dezvoltarea instantanee a unui model mintal bazat pe analogie sau pe expectanta consistentei.  Acest fenomen a fost utilizat in diferite limbaje formale de specificare. De exemplu, in TAG (Task Action Gramar) descrierea unei interfete a unui instrument necesita un dictionar al sarcinilor simple. Sarcinile simple sunt definite ca fiind aplicatii ale unei singure reguli. Fiecare intrare in dictionarul sarcinilor simple asociaza o denumire a unui concept cu o serie de valori-caracteristici (Green et a., 1988). De exemplu, o sarcina simpla poate fi miscarea cursorului inainte cu un caracter, si regula pentru aceasta (in cazul unui editor Emax) este "misca "- Pentru alte directii sau alte unitati (linie, paragraf) o alta valoare caracteristica poate fi introdusa in aceeasi regula. Pentru MS Office 2000, de exemplu, aceasi regula poate fi aplicata pentru salvarea unui document, a unei baze de date, a unei imagini, etc.

Paralelismul este o problema in sistemele complexe interactive in care multi utilizatori lucreaza impreuna, sincron sau asincron. In Sage & Johnson (1998), acest tip de cooperare este modelat prin unirea a doua tabele UAN intr-un singur tabel. Totusi, din punctul de vedere al utilizatorului, aceasta nu este relevant si toate aspectele pot fi adecvat modelate doar prin includerea procesului cooperarii si comunicarii ca parte a UVM. Utilizatorul este in interactiune cu sistemul, iar anumite evenimente sunt cauzate (si ar trebui intelese ca atare) de un alt utilizator care abordeaza actualul utilizator prin intermediul sistemului. Modelul mental al utilizatorului va contine ideea ca exista interactiune cu alte persoane prin intermediul sistemului. Utilizatorii vor fi, in mod normal, plictisiti de problema de integrare a dialogurilor diferitelor persoane, pe care designerul o are.

O ultima observatie legata de specificarea actiunilor interfetei. In UAN aceasta coloana specifica actiunile interfetei ca elemente de cunostinte si specifica si formatul lor. Aceasta este necesar pentru a specifica ce informatie este pusa la dispozitia utilizatorului. Totusi, nu este indeajuns sa se specifice intreaga UVM. O specificare aditionala trebuie sa consiste din schite care arata layout-ul artefactului final (de exemplu layoutul ecranului), grafica si culorile, etc. In unele cazuri schite tridimensionale ca mock-up-urile de carton sunt necesare, iar in alte cazuri sunt necesare videoclipuri si sunete, etc.

In sectiunea de fata am aratat care sunt aspectele necesare pentru specificarea UVM din punctul de vedere al ceea de ce are nevoie utilizatorul pentru a intelege si a-si crea un model mentala adecvat. In fapt, toate aspectele mentionate au fost incorporate intr-o versiune recenta a UAN care a fost dezvoltata de Venema (1999). In figura 8 aveti un exemplu:

Figura 8 Un exemplu al unei interactiuni specificate in notatii UAN dupa extinderea acesteia de catre Venema (1999)

Exemplul din figura 8 face referire la primirea unui nou email si posibilitatea ca utilizatorul sa citeasca acest email sau sa amane citirea lui. In UAN formalismul necesar specificarii are forma unui template, care ajuta deisgnerii sa ia in considerare toate elementele relevante ale UVM (bineinteles, orice parte a formalismului care nu s-ar aplica trebuie lasata necompletata).

Ÿ       Partea de sus a templatului permite declararea unei conditii initiale a dialogului pentru orice conditie despre care utilizatorul ar trebui sa fie informat (la cest nivel de specificare nu trebuie sa ne face griji cu privire la conditiile tehnice). In acest caz: utilizatorul trebuie sa inteleaga ca emailul functioneaza ca un proces de fundal, chiar daca nimic nu este indicat pe ecran. In plus, nu exista nici un mesaj necitit in casuta postala. Aceasta cunostinta este relevanta pentru initierea unui model mental in momentul in care interfata ofera informatii despre primirea unui nou mesaj.

Ÿ       In plus, partea de sus permite informatie verbala aditionala, menita sa ofere o descriere punctata a templatului, precum si sa descrie orice alte aspecte relevante pentru utilizator, aspecte care nu ar putea fi incluse in deschizaturi normale. In acest caz: utilizatorul trebuie sa inteleaga ca un nou mesaj ar putea sa fie primit in timpul manipularii primului mesaj, si ar trebui sa fie capabil sa-si ajusteze modelul mental in consecinta daca dialogul reincepe.

Ÿ       Coloana din stanga indica actiunile pe care utilizatorul trebuie sa le realizeze. In acest caz acestea sunt reactii la initiativa sistemului (coloana 2): utilizatorul trebuie sa aleaga fie sa accepte sa citeasca mesajul fie sa amane citirea noului mesaj. Decizia se poate baza pe modelul mental al utilizatorului asupra sarcinii din situatia actuala inclusiv urgenta activitatilor concurente. Decizia utilizatorului este, in sine, invizibila si poate sa nu fie inclusa in specificare fara ca aceasta sa modifice semnificatia pentru design. Dar poate fi utila pentru ca designerul sa inteleaga faptul alegerii si posibilele cerinte pentru cunostintele necesare. Pe baza aceasta, designerul poate, in fapt, sa decida sa specifice reprezentarea pe ecran a unui element care sa reaminteasca amanarea actiunii (fie actiunea care era in curs de desfasurare in momentul primirii mesajului fie amanarea citirii acestuia). Dupa specificarea deciziei utilizatorului, urmatoarea banda de timp (sub urmatoarea linie orizontala) arata actiunea fizica a utilizatorului, indreptata spre interfata: fie apasa butonul pentru "da" fie cel pentru "nu".

Ÿ       A doua coloana arata actiunea interfetei. In acest caz, interfata preia initiativa de a anunta utilizatorul ca un nou mesaj a fot primit si prin oferirea de informatii pentru alegerea pe care utilizatorul va trebui sa o faca In momentul in care utilizatorul realizeaza actiunea, interfata oglindeste aceasta prin prezentarea miscarii pointerului si prin oferirea noului mesaj in cazul in care utilizatorul se hotaraste pentru aceasta varianta. Aceasta coloana indica, de fapt, fie toata informatia pe care interfata o pune la dispozitia utilizatorului in orice moment al interactiunii, fie toata informatia care se schimba (de exemplu "ASCUNDE_MESAJ"). Templatul cere exactitate in acest punct, dar, daca este necesar, schite pentru clarificarea detaliilor reprezentarii ar trebui adaugate.

Ÿ       A treia coloana prezinta specificarea tuturor cunostintelor despre starea interfetei relevante pentru utilizator. In cazul exemplului nostru, aceasta este informatia despre procesele in curs de desfasurare in care utilizatorul ar putea fi implicat (care este amanat, care se desfasoara in aceasta faza a dialogului). Cand interfata nu arata in mod explicit statutul proceselor relevante pentru utilizator, este necesara precizarea ca utilizatorul trebuie sa aiba in vedere, de exemplu, sa-si ajusteze modelul mental al ceea ce trebuie facut in viitor si al ceea ce trebuie facut in momentul prezent.

Ÿ       Ultima coloana arata orice schimbare in tehnologia care sta la baza, in retea, sau alte parti ale sistemului pe care utilizatorul ar trebui sa le inteleaga. In cazul nostru aceasta face referire la statutul casutei postale in legatura cu mesajele necitite.

Concluzia generala a acestei sectiuni este ca un formalism de modelare ales bine poate servi la persuadarea designerilor sa ia in considerare toate aspectele UVM, si sa specifice acestea din punctul de vedere al cunostintelor si reprezentarilor relevante petnru utilizator. In fapt, specificarea din figura 8 este echivalenta cu modelul mental "ideal"al unui utilizator expert in situatia data.

4 Proiectarea pentru utilizatori si sarcini

In aceasta sectiune vom arata relatia dintre tehnicile de design, pe de-o parte, si rolul modelelor mentale ale utilizatorului si cunostinte, pe de alta parte. O mare varietate de abordari ale designului au fost dezvoltate pentru sistemele interactive. In acest material vom sublinia doar anumite faze ale designului care au o relatie puternica cu cunostintele utilizatorului. In sectiunea 4.1 ne vom centra pe colectarea si modelarea cunostintelor despre domeniul sarcinii, precum si pe activitatile necesare dezvoltarii si imaginarii noii lumi a sarcinii. Continutul specific al modelelor de sarcina din punctul de vedere al reprezentarii cunostintelor utilizatorului va fi tratat in sectiunea 42. Cunostintele utilizatorului si aspectele modelelor mentale ale specificatiilor detaliate au fost deja luate in considerare de vreme ce conceptul UVM este centrul preocuparii noastre pentru modelele mentale ale utilizatorilor viitori. In 4.3 vom indica doar pe scurt modelarea UVM ca proces pentru specificarea viitoarelor cunostinte ale utilizatorilor despre sistem. In final, in 4.4 investigam relatia cu tehnicile de evaluare timpurii sau de sfarsit (in timpul analizei de sarcina ca si in timpul specificarilor si dezvoltarii UVM).

4.1 Analiza de sarcina ca proces pentru analizarea cunostintelor utilizatorilor

De cele mai multe ori, procesul de design incepe cu o analiza extensiva a sarcinii. Primul model de sarcina astfel realizat este un model descriptiv de sarcina si este utilizat prin analiza situatiei actuale a sarcinii. Un posibil model secundar de sarcina este un model prescriptiv pentru sistemul in curs de proiectare.

Toate abordarile analizei de sarcina inceput cu una sau mai multe tehnici pentru colectarea, modelarea si analiza cunostintelor despre sarcina . Cunostintele legate de sarcina, in cazul sistemelor interactive complexe, pot fi colectate atat de la persoane individuale (experti ai sarcinii) cat si de la comunitati de practica (prin utilizarea metodelor etnografice, analiza documentelor, etc.). Modelele de sarcina, fie ca descriu situatia existenta, sau o imaginare a lumii viitoare, sunt modele ale cunostintelor. In primul caz sunt descriptive, chiar daca vor inspira re-designul prin etalarea problemelor, erorilor, inconsistentelor si dorintelor. In cel din urma caz, acestea sunt baza pentru designul de detaliu, oferind cunostinte de care comunitatile viitoare de utilizatori vor avea nevoie astfel incat sistemul dorit sa fie dezvoltat, implementat si utilizat cu succes. Preferam sa despartim cele doua tipuri de modele de sarcina pentru a ne asigura ca nu amestecam realitatea cu virtualul.

1. Analiza situatiei actuale a sarcinii (modelul de sarcina 1)

In multe cazuri, designul unui nou sistem este determinat de situatia actuala a sarcinii. Fie modul actual de realizare a sarcinii nu este considerat a fi cel optim, sau se asteapta ca noua tehnologie sa permita imbunatatiri fata de metodele actuale. O analiza sistematica a situatiei actuale poate ajuta in formularea cerintelor pentru design, si, in acelasi timp, va permite evaluarea designului mai tarziu in cadrul procesului de evaluare. In toate situatiile in care o versiune "actuala" a situatiei sarcinii exista, merita sa fie modelata. In cele mai multe cazuri, o combinatie intre metodele clasice HCI este necesara, ca interviurile structurate si alte tehnici de origine psihologica (Johnson & Johnson, 1991), ca si metode relationate cu domeniul CSCW cum ar fi analiza etnografica sau analiza interactiunii. Prima categorie de tehnici ne va ajuta in modelarea cunostintelor (baza modelelor mentale in uz) identificate la utilizatorii individuali, al doua categorie de tehnici permite identificarea "cunostintelor de grup" care ar putea fi relationate, dar nu este identica cu, conceptul de modele mentale impartasite

2. Imaginarea lumii viitoare a sarcinii (Modelul de sarcina 2)

Multe metode de design din domeniul HCI care incep cu modelarea sarcinii sunt structurate intr-o serie de pasi. Dupa descrierea situatiei actuale (modelul de sarcina 1) metoda cere re-designul structurii sarcinii pentru a include solutiile tehnologice pentru probleme si raspunsurile tehnologice pentru cerinte. Johnson & Johnson (1991) ofera un exemplu al unei abordari sistematice in care un al doilea model de sarcina este definit in mod explicit in timpul deciziilor de design. Modelul de sarcina 2 va fi formulat la modul general si va fi structurat in mod asemanator modelului anterior, dar, asa cum am mentionat anterior, in acest caz nu este considerat un model descriptiv al cunostintelor utilizatorului. Totusi, daca rezultatul final al designului este implementarea modelului de sarcina 2 (in forma sa finala, consistent cu designul final) poate fi aplicat ca un model prescriptiv. Acesta de fineste in fapt cunostintele pe care un utilizator expert a noii tehnologii ar trebui sa le posede pentru a fi capabil sa dezvolte modele mentale adecvate in noi situatii reale de munca.

4.2 Modelarea cunostintelor utilizatorilor despre sarcina pentru sisteme interactive complexe

Pentru modelarea oricarui tip de cunostinte este necesar un cadru conceptual, pentru a declara cat mai clar care tipuri de entitati sunt relevante pentru aplicarea cunostintelor modelate si care tipuri de relatii sunt relevante pentru analiza. Reprezentarea modelelor de sarcina, din punctul nostru de vedere, ar trebui sa permita designerului sa inteleaga in mod complet toate aspectele relevante ale cunostintelor in domeniul pentru care este construit sistemul. Modelele de sarcina vor oferi intelegerea cunostintelor de background existente (modelul de sarcina 1) sau care ar trebui sa fie disponibile (modelul de sarcina 2), fie in memoria de lunga durata fie in situatia data inclusiv in interfata, pentru ca utilizatorii sa dezvolte modele mentale adecvate cand interactioneaza cu sistemul. Diferitele puncte de vedere despre cunostintele despre sarcina, asa cum sunt prezentate in HCI (de ex. Johnson & Johnson, 1991) si CSCW (Jordan & Henderson, 1995) ne arata ca complexul de cunostinte trebuie analizat din diferite puncte de vedere:

Ÿ       De vreme ce sistemele actuale si viitoare vor avea in mod frecvent utilizatori multiplii cu roluri diferite, modelele de sarcina trebuie sa acopere cunostintele utilizatorilor si comunitatilor de practici ale agentilor implicati si relatiile lor organizationale.

Ÿ       In al doilea rand, modelele de sarcina trebuie sa cuprinda munca pentru care sistemul este intentionat sa fie utilizat, in toate detaliile relevante.

Ÿ       In plus, modelele de sarcina trebuie sa modeleze aspecte ale situatiei de munca care sunt relevante pentru ca utilizatorii sa dezvolte un model mental in situatiile efective.

Mai mult, fiecare aspect al cunostintelor se relationeaza cu celelalte. Modeland cunostintele despre sarcina in aceasta maniera, designerii pot gasi sustinerea necesara pentru analiza si specificarea diferitelor puncte de vedere, in vreme ce construiesc sisteme care pot fi utilizate pentru mentinerea consistentei si completitudinii.

Cele trei puncte de vedere reprezinta o integrare a principalelor puncte de interes din domeniile HCI si CSCW. Ambele campuri ale designului sunt considera agenti ("utilizatori" vs. "utilizatori aflati in cooperare" sau grupuri de utilizatori) si munca (activitati sau sarcini, respectiv obiectivele sau scopurile "interactiunii" si a muncii in colaborare). Mai mult, mai ales in CSCW este accentuata situatia in care sustinerea tehnologica trebuie incorporata. In HCI aceasta este doar ocazional luata in considerate, si mai mult implicit. In aceasta sectiune vom mentiona sumar cadrul conceptual pe care l-am adoptat pentru cunostintele despre sarcina. Aceasta este structura elementelor cunostintelor care sunt relevante pentru intelegerea cunostintelor de background ale utilizatorilor pentru modelele mentale in timpul utilizarii sistemelor interactive.

1. Agentii

In reprezentarea domeniului sarcinii pentru cei mai multi, "agentii" sunt persoane, fie indivizi fie grupuri, dar agenti pot sa fie si sistemele, fie cele relativ simple (robotul telefonic) sau complexe (serviciul impozite). In specificarea cunostintelor relevante ale utilizatorului pentru domeniul sarcinii, trebuie sa facem distinctia intre actori, ca indivizi sau sisteme care actioneaza, si rolurile pe care acestea le joaca. Actorii trebuie descrisi impreuna cu caracteristicile relevante pentru sarcina (de ex. pentru actorii umani limba pe care o vorbesc, situatia abilitatilor de dactilografiere sau experienta cu "MS-windows" -  de vreme ce aceasta este relevant pentru utilizatori cand este vorba de delegarea sarcinilor). Rolurile indica faptul ca numite subseturi de sarcini sunt alocate uni actor. In consecinta, rolurile sunt generice pentru lumea sarcinii. Acelasi rol poate fi realizat de mai multi actori, nu doar unul, si un singur actor poate avea mai multe roluri in acelasi timp. Si fiecare actor trebuie sa fie constient de rolul pe care oamenii (actorii) cu care colaboreaza sau comunica il au. Cunostintele relevante ale utilizatorului despre organizare se refera la relatia intre actori si roluri in relatie cu alocarea sarcinii: delegarea si mandatarea responsabilitatilor de la un rol la altul este parte a organizarii.

2. Munca

Cunostintele utilizatorilor despre munca fac referire atat la aspectul structural cat si la cel dinamic, deci vom utiliza sarcina ca si concept de baza. Utilizatorii ar trebui sa cunoasca relatia intre sarcini, atat in relatie cu alte sarcini (sub-sarcini si supra-sarcini) si in relatie cu aspectele cauzale si temporale (sarcinile pot determina alte sarcini sau realizarea unei sarcini poate fi o pre-conditie pentru performanta in alta sarcina). Sarcinile complexe pot fi impartite intre actori si roluri. Aceasta inseamna ca o persoana poate delega o subsarcina unei alte persoane, probabil in relatie cu un rol adecvat. De exemplu, un manager care organizeaza un proces major de schimbare (o sarcina de nivel superior) va cere secretarei sa organizeze intalnirile, sa colectioneze documentele, etc. (toate acestea fiind subsarcini ale sarcinii originale). In mod normal, oamenii vor realiza sarcina pentru ca doresc sa atinga un scop, chiar puteam defini sarcina ca o activitate realizata de agenti pentru atingerea scopului. Pe de alta parte, oamenii adesea pot alege diferite sarcini pentru atingerea unui scop, in functie de conditiile situationale. O situatie speciala poate sa apara daca sarcina este determinata de un eveniment din situatia initiala care nu este relationat in mod normal cu domeniul sarcinii (de exemplu o pana de curent, sau intreruperi cauzate de o calamitate). Mai ales daca acest eveniment este comunicat prin sistemul care trebuie proiectat, trebuie permis utilizatorilor sa isi dezvolte un model mintal instantaneu pentru a face fata conditiilor exceptionale. In final, trebuie sa facem distinctia intre sarcini si actiuni: oamenii adesea realizeaza actiuni cu semnificatie care nu au un scop in sine. De exemplu, cand cineva apasa o tasta cu comanda "inapoi" ("return") pe tastatura, acest lucru este realizat intentionat. Dar semnificatia poate sa varieze: mergi la celula urmatoare din acelasi rand (intr-un tabel), insereaza un caracter "intoarcere" in firul textului (in modalitatea input a unui procesor word), sfarsitul comenzii (in limbaj UNIX), etc. Aceste activitati cu semnificatie sunt denumite "actiuni". Utilizatorii trebuie sa le cunoasca si sa le inteleaga, dar nu vor avea un scop pentru a le realiza ca atare. In reproiectare se poate analiza schimbarea actiunilor, omiterea unora, si, mai ales, alegerea lor astfel incat sa fie consistente si usor de invatat si utilizat.

Nivelul unitar al sarcinilor necesita o atentie speciala. Cel mai elementar nivel al sarcinii pe care oamenii sunt capabili sa il ia in considerare atunci cand fac referire la munca pe care o realizeaza, este adesea denumit "sarcina unitara" (Card et al, 1983). Sarcinile unitare sunt elemente importante in orice cunostinte legate de sarcina pe care le are utilizatorul fiind cea mai mica activitate pe care utilizatorii le au in repertoriul propriu pentru atingerea scopurilor. Daca cineva intreaba pe altcineva despre propriile sarcini, sarcinile unitare sunt cele mai mici sarcini pe care oamenii le mentioneaza. Card et al. (1983) sustin ca sarcinile unitare pot fi identificate in comportamentul real al utilizatorilor prin observarea timpului pe care oamenii il petrec "in asteptare" inaintea realizarii urmatoarei actiuni a dialogului. Daca acest timp depaseste o anumita perioada (1,35 sec.) aceasta indica ca este nevoie de un efort cognitiv considerabil intre secventele de dialog, deci transferul unei noi sarcini unitare poate fi inferat. Sarcinile unitare pot fi adesea relationate cu un rol. Pentru managerul care organizeaza o intalnire, invitarea participantilor poate fi o sarcina unitara (realizata prin delegarea sarcinii secretarei). Pentru secretara, invitatia reprezinta o sarcina complexa, care trebuie descompusa in scris scrisori, identificarea adreselor, punerea scrisorilor in plicuri, si asa mai departe. Pentru ea sarcina unitara ar fi punerea plicurilor inchise intr-o cutie postala.

Pentru a putea utiliza un sistem utilizatorii trebuie sa inteleaga (si uneori sa invete) relatia intre sarcinile unitare si functionalitatea pe care sistemul o ofera. Daca utilizatorul decide sa delege o sarcina unitara sistemului, modelul mintal trebuie sa ofere cunostintele despre actiunile utilizatorului si intelegerea rezultatului actiunilor sistemului. In fapt, dialogul specificat in figura 8 face referirea la o sarcina unitara care ar putea fi etichetata "accepta citirea unui nou mesaj sau amanarea pentru citire mai tarziu".

3. Situatia

Utilizatorii necesita cunostinte despre sarcina pentru a dezvolta un model mental pentru actiune. Deci proiectantii trebuie sa adune si sa modeleze aceste cunostinte relevante, ceea ce inseamna detectarea si descrierea aspectelor relevante ale mediului (fizic, conceptual sau social) si ale obiectelor din mediu. In acest cadru conceptual, "obiectele" nu sunt definite in sensul "metodelor orientate spre obiecte". Fiecare lucru care este relevant pentru utilizator in cadrul muncii intr-o anumita situatie este un obiect din punctul de vedere al analizei muncii; chiar si mediul poate fi un obiect. Obiectele pot fi lucruri fizice sau conceptuale (non-materiale) ca mesajele, gesturile, povestile sau semnaturile. Oamenii in situatia sarcinii au nevoie cunostinte despre obiectele din mediul muncii. Obiectele pot fi schimbate (sau distruse sau create) ca rezultat al sarcinii. De asemenea, obiectele pot fi relevante pentru conditiile sarcinii. De exemplu, obiectele "mesaj" si "casuta postala" sunt necesare ca elemente in modelul mental al utilizatorului despre sistemul de trimitere al mesajelor electronice ("daca exista deja mesaje in casuta postala pe care nu le-am citit, nu ma astept ca sistemul sa ma atentioneze cand un nou mesaj este receptionat"). Istoricul evenimentelor trecute relevante in situatia de sarcina este parte a mediului real daca acestea joaca un rol in conditiile pentru executia sarcinii ("daca tocmai am lucrat cu mesajele nou venite, ma astept ca sistemul sa ma atentioneze la primirea unui mesaj nou").

4. Specificarea detaliilor tehnologiei: Masina Virtuala a Utilizatorului (UVM)

Dupa activitatea de modelare a sarcinii urmatorul pas al proiectarii este specificarea noului sistem. Modelul de sarcina 2 descrie noua lume a sarcinii in care sistemul va fi situat. De acolo, detaliile tehnologiei si sarcinile de baza care implica interactiunea cu noul sistem trebuie dezvoltate. Din punctul nostru de vedere (proiectarea pentru intelegerea, cunostintele si modelele mentale ale utilizatorilor), procesul specificarii detaliilor tehnologiei trebuie sa duca la o descriere detaliata a sistemului in masura in care este relevant pentru utilizatorul final. Precum a fost indicat si inainte, MVU include atat semantica tehnologiei (potrivirea dintre functionalitatea oferita de sistem utilizatorului cu sarcina delegata), sintaxa (potrivirea dialogului pentru delegarea sarcinii sistemului), si reprezentarile perceptibile ale sistemului (ceea ce Norman numeste "imaginea sistemului).

La trecerea de la modelul de sarcina 2 la designul MVU, sarcinile si obiectele modelate in modelul de sarcina 2 determina prima schita a aplicatiei. Structura obiectului sau sarcinii este utilizata pentru crearea principalelor display-uri si a structurii navigationale. De aici incolo, rafinarea iterativa a procesului are loc, ghidata de diferite tehnici de evaluare care vor fi discute in sectiunile urmatoare.

Reprezentari ale designului detaliat

Pentru reprezentarea MVU am argumentat deja ca UAN si dezvoltarile sale ca fiind buni candidati. Dar exista si alte familii de tehnici care pot fi utilizate in modelarea specificatiilor detaliate ale MVU, ca variante ale GOMS, TAG, etc. Cititorul trebuie sa tina cont de faptul ca nu oricare dintre abordarile si formalismele de modelare mentionate este capabil sa acopere aspectele relevante ale cunostintelor legate de reprezentare. Cel putin diferite tipuri de tehnici de "schitare" trebuie adaugate (vezi 3). Din acest punct de vedere, cauza principala pentru alegerea oricarei reprezentari este permiterea si provocarea proiectantilor in aceasta faza a designului sa ia in considerare si sa specifice toate cunostintele relevante pe care un utilizator ar trebui sa le aiba la indemana, in momentul aplicarii sistemului in cauza. Specificarea acestor cunostinte va ajuta la aprecierea modului in care utilizatorii viitori vor fi capabili sa dezvolte modele mentale ale situatiei reale de utilizare, ce si cum trebuie sa invete, si cum poate sistemul sa le ajute in aceste activitati.

4.4. Evaluarea designului din perspectiva modelelor mentale a utilizatorilor

Evaluarea in timpul designului sistemelor interactive este prezentata si in alt capitol al acestui volum. Aici, vom lua in considerare doar evaluarea in relatie cu intrebarile care privesc cunostintele si modelele mentale ale viitorilor utilizatori. Problema principala are doua parti:

(1)     cum sa fie reprezentate specificatiile timpurii si tarzii astfel incat semnificatia sistemului pentru utilizatorii viitori poate fi facuta cat mai clar, si

(2)     cum sa fie explorate modelele mentale ale utilizatorilor finali intr-o faza relativ timpurie (inainte ca designul sistemului sa fie complet si sistemul sa fie implementat).

Evaluarea timpurie poate fi realizata prin inspectarea specificatiilor designului sau prin realizarea unor sesiuni de walkthrough cu designerii si/sau utilizatorii. Dar independent de faptul daca "evaluatorii" sunt specialisti in proiectare care preiau perspectiva utilizatorilor potentiali, sau utilizatori "reali" (viitori), problema principala este oferirea unei reprezentari optime a deciziilor de proiectare luate pana la momentul respectiv. O reprezentare "optima", dupa parerea noastra, este o reprezentare care il ajuta pe evaluator, pe utilizatorul viitor sau pe alti participanti, sa inteleaga designul "imaginat". Cu alte cuvinte, reprezentarile ar trebui sa permita o dezvoltare a modelelor mentale a sistemului ce va fi, chiar daca doar unele parti ale acestuia, idei brute sau schite vagi sunt specificate deocamdata.

Reprezentari formale ca UAN, GOMS, etc., chiar daca sunt utile datorita preciziei si lipsei de ambiguitate si pentru documentarea si analizarea deciziilor de design, sunt de cele mai multe ori nepotrivite pentru a-i face pe altii (mai ales pe utilizatori) sa inteleaga cu adevarat sistemul sau situatia pe care dorim sa o dezvoltam. In toate cazurile de evaluare timpurie sau tarzie, trebuie sa confruntam evaluatorii cu specificatiile de design realizate pana acum, chiar daca este vorba doar de lumea viitoare a sarcinii (modelul de sarcina 2) sau daca face referire la detalii ale MVU ca prezentarea dialogului sau a sistemului. Trebuie sa reprezenta deciziile de design astfel incat evaluatorul sa poata intelege fragmentul de design pe care il evalueaza. Cu alte cuvinte, pentru a permite evaluatorului sa-si dezvolte un model mintal adecvat al lumii avute in vedere a sarcinii sau a detaliului de design pe care dorim sa-l evaluam, trebuie sa reprezentam intentiile si specificatiile designului astfel incat:

Acestea sa arate intentiile pe care le avem atat de precis cat permite starea actuala;

Ofera evaluatorului sentimentul sau intelegerea libertatii de interpretare pentru deciziile care nu au fost luate inca sau pentru punctele in care interpretarea intuitiva poate fi necesara pentru intelegerea impactului designului pentru utilizator.

Tocmai din aceste motive evaluarea timpurie necesita reprezentari ca scenarii, schite, "story-bards", si video clipuri, in vreme ce evaluarea tarzie trebuie sa se bazeze pe cazuri de utilizare ("use cases") detaliate combinate cu prototipuri interactive (totusi, in multe cazuri doar ale unor parti ale sistemului). Toate acestea il vor ajuta pe utilizator sau pe evaluatorul expert sa isi dezvolte un model mintal al sistemului, permitand reactii sau eventuale interactiuni care ii ajuta pe designeri sa evalueze potrivirea dintre tehnologia avuta in vedere si modelul mintal.

Pe de alta parte, evaluarea ideilor designului timpuriu sau tarziu necesita strangerea si inregistrarea modelelor mentale, cunostintelor, sentimentelor si comportamentelor  utilizatorilor (sau evaluatorilor). Exista numeroase metode de evaluare, tratate in alt capitol al acestei carti si care nu vor fi repetate aici. Din punctul de vedere al cunostintelor, invatarii si modelelor mentale, cele mai multe dintre acestea vor oferi o intelegere importanta. In sectiunea urmatoare a acestui capitol, ne vom centra pe instrumentele specifice pentru evaluarea modelelor mentale care sunt dezvoltate prin oferirea evaluatorilor (sau utilizatorilor) prin confruntarea cu specificatiile timpurii de design, in forma scenariilor, etc.