Universitatea de Vest din Timişoara, Facultatea de Matematică şi Informatică, Informatică Română

Lucrare de licență
Asistent software pentru realizarea prototipului UI
Coordonator ştiinţific: Conf. Dr. Cristina Mîndruță Absolvent: Feier Laura

Timișoara, 2011

UNIVERSITATEA DE VEST DIN TIMIŞOARA, FACULTATEA DE MATEMATICĂ ŞI INFORMATICĂ, INFORMATICĂ ROMÂNĂ

Lucrare de licență
Asistent software pentru realizarea prototipului UI
Coordonator ştiinţific: Conf. Dr. Cristina Mîndruță

Absolvent: Feier Laura

Timișoara, 2011

.

Observing the impact that the user interface has on end-users is the key in designing good and easy-to-use software. Infomation Architecture.Abstract Nowadays. GUI prototyping is not just a whim or an experimental technique. Interaction Design. Software Assistant for UI Prototype Design is a tool built specifically to facilitate the creation of semi-functional GUI prototypes. The outcome of the analysis process is the UI prototyping. . Prototyping is an excellent means for generating ideas about how a user interface can be designed. it offers a series of features for developers through the quick and efficient creation of mock-up screens. Furthermore. but a necessity in the process of designing the user interface of a software application. All this can be done in an early stage of software development through the process of User Experience which incorporates several analysis and observational methods and several concepts from many domains such as Visual Design. and it helps to evaluate the quality of a solution at an early stage. which is precisely the goal of any developer.

.

........4 2....... 3 2... 26 Roluri în construirea de UI ....................................................................................................... 11 Experiența utilizatorului vs.................................................................................................................. 37 Analiza punerii în aplicare a tool-urilor .....................2 Date generale .............. 39 4 Prototiparea interfețelor utilizator ...........5 2.... 5 Știința și design-ul .............................................. 21 Viitorul uzabilității și UX ....................................................................9 4........................... 31 Clasificarea prototipurilor interfeţei cu utilizatorul ............................................ 1 User Experience ............ 8 Fațetele UX ...................................10 5 Descrierea aplicației ...........................7 2....................................................................................................................................................................................................................... 26 Procesul proiectării experienței utilizator .........................6 2............................................................................................. 20 Importanța UX .........3 2............. 30 4.................................9 3 Istoric ........ 33 Analiza punerii în aplicare a prototipurilor ................. 31 Clasificarea tool-urilor de prototipare a interfeţei cu utilizatorul ......................................... 28 Abordări ale prototipării interfeței cu utilizatorul ..................................................................................................................................................................................................................................5 4................................................2 4. 6 Ciclul și modelul UX .8 4......................3 4.................................1 2...... 3 UX pentru organizații mici și mari ................................................... 35 Strategii de dezvoltare şi procesul de prototipare .........................................................1 5............1 3....... 32 Proiecte analizate ........ 34 Obiective pentru construcția de prototipuri ...............................................1 4........3 3...................................2 3.........................................................................2 2.............7 4................8 2.............. 40 Structura interfeței grafice ..6 4............... 39 Concluzii ............................................................................................... 36 De la prototipuri la sistemul dorit ....................................................................................................... 4 Definirea conceptului .........................4 4.......... 25 3.................................... 22 Proiectarea centrată pe utilizator ............................................................................................ Interacțiunea utilizatorului .............................................................................. 40 5.............Cuprins 1 2 Introducere .....4 Definirea conceptului ................................................. 40 ........................ 25 Modele și abordări ....................................................................................................

.............................................................................................3 5.......................... 41 Concepte............................. arhitecturi și detalii de implementare....................................................5....... 44 Concluzii ....................... 55 Bibliografie.......................................................................... 56 ............................................4 6 7 Funcționalități .......................

aeroporturi. Aceasta se bazează pe experiența utilizatorului și le permite acestora să furnizeze informații despre ce funcționează cum s-a anticipat și ce nu. vehicule. produsul poate fi excelent dar va fi sortit eșecului. specialiștii în uzabilitate se concentrează asupra interfeței utilizator. schițarea UI(User Interface Design) este cunoscută deasemenea și ca Human-Computer Interaction(HCI) . Astfel. Aplicat în software-ul computațional. impactul interfeței utilzator asupra utilizatorului devine crucial iar scopul dezvoltatorilor produsului devine producerea de software profesional și ușor de utilizat. O proiectare UI oprimă necesită o abordare sistematică a procesului de proiectare a unui produs.1 Introducere Multe inovații tehnologice se bazează pe proiectarea interfeței utilizator în scopul de a crește complexitatea tehnică la un produs utilizabil. Acesta este momentul în care interfața produsului intră în procesul de proiectare(design). Astfel. Desigur că pentru a maximiza eficiența și pentru rentabilitate este necesară o menținere strânsă a legăturii de muncă de la începutul proiectului până la lansarea acestuia. Obiectivul principal al acestei lucrări este de a prezenta un mod de schițare rapidă a interfețelor utilizator: prototiparea. Deși oamenii asociază de multe ori termenul de Interface Design domeniului computațional. În cazul în care utilizatorii găsesc software-ul mult prea încărcat. O interfaţă utilitzator bună face diferenţa între acceptarea unui produs software pe piaţă si eşecul lui. Experiența utilizatorului(User Experience) și modul în care decurge experimentarea produsului final cu ajutorul utilizatorului este cheia acceptării produsului pe piață. În timp ce inginerii produsului se concentrează asupra tehnologiei. Avioane militare. proiectarea. mult prea dificil de utilizat sau mult prea greu de înțeles. Doar după ce reparațiile au fost realizate se poate spune că un produs este considerat un produs cu o interfață utilizator optimă. acesta se referă deasemenea și la produsele în care utilizatorul interacționează cu controale și afișaje. Deşi pare evident faptul că proiectarea UI are cel mai mare impact în dezvoltarea pe piaţă(şi nu numai) a unui produs software. sunt câteva din produsele care permit aplicabilitatea de User Interface Design. este de cel mai multe ori ignorat. și periferice. Doar tehnologia nu poate câștiga accceptarea utilizatorilor și comercializarea ulterioară. Pentru a asigura performanța optimă a produsului este necesară o testare de utilizabilitate. echpamente audio. am creat o aplicație care se comportă ca un asistent pentru utilizatorul ce va dori crearea de prototipuri UI funcționale pentru 1 .

a le trimite în faza de testare a utilizabilității. prin care se vor colecta datele esențiale proiectării pe baza experienței utilizatorului ce va testa prototipul. 2 .

Cu timpul. Studiul oficial a apărut de pe mai multe fronturi. Sindicatele europene și scandinave ale forței de muncă a emis studii de cercetare în domeniul ergonomic și al sănătății profesionale. Aceste constatări au condus cercetătorii la întrebările: Care este semnificația și impactul limitărilor umane asupra proiectării sistemelor? Ce se poate face în privința acestor limitări? La început principiile de bază ale UX erau doar niște simple observații. proiectanții de odinioară nu gândeau astfel conceperea lor. Factorii umani au inceput să apară în jurul celui de-al doilea Război Mondial când cercetătotii au realizat faptul că interacțiunea oamenilor cu sistemele tehnice nu a necesitat un efort foarte mare. Operatorii sistemelor tehnice. din punct de vedere istoric. de Don 3 .2 User Experience User Experience(UX) mai este cunoscut și sub numele de User Experience Design. industria nu a ajuns la această abordare decât abia prin anii ’90. la baza sa. Astfel. controlat și cu interfețe cât mai plăcute de utilizatori. toata atenția îndreptându-se pe producerea de sisteme mult mai ușor de învățat. putem arunca o scurtă privire asupra perioadei celui de-al doilea Război Mondial când interacțiunea cu sistemele tehnice a devenit o chestiune de viață și moarte. practice și plăcute din punct de vedere vizual. prin anii 1980 în timp ce alții consideră că începutul a fost mult mai devreme. un concept sau mai bine spus. o filosofie conform căreia toate produsele și serviciile trebuie proiectate astfel încât să fie ușor de utilizat. atunci când viețile lor depindeau de rezultate exacte și fiabile.’90 proiectarea centrată pe utilizator a luat o amploare și mai mare mai ales din punct de vedere al importanței. au atins într-un final limitări umane evidente.1 Istoric Începuturile UX-ului este un subiect destul de contestabil. Deși pare un mod evident de a adopta acest concept în proiectarea serviciilor și produselor. Cărți ca ―The Design of Everyday Things‖. De fapt. UX reprezintă. 2. Unii designeri de UX consideră că originea disciplinei a apărut odată cu proiectarea centrată pe utilizator. Cu timpul calculatoarele s-au răspandit tot mai mult în locurile de muncă iar în anii ’80 . Corporațiile au prins interes în domeniu în momentul în care eficiența și câștigurile productivității au devenit semnificative când utilizatorii nu mai aveau nevoie de cursuri de formare și învățare a sistemelor tehnice. subiectul a trecut de la factorii umani la proiectarea centrată pe utilizator. Inițial cercetătorii sau axat pe hardware dar studiile au migrat la software.

cercetători.Norman și ―Designing Web Usability‖. proiectanților și multor altora. farmecul interfeței utilizator și proiectarea din punct de vedere vizual. UX a devenit un set de discipline destul de diferite ce includeau contribuții ale inginerilor.2 Multiple T-shaped Professionals 4 . noțiunea de UX pe care o știm astăzi nu era încă stabilită. Acesta nu este neapărat un lucru adevărat. Cu cât mai multe organizații au adoptat proiectarea centrată pe utilizator. următoarele discipline reprezintă în momentul de față setul de profesioniști care alcătuiesc domeniul de User Experience: ingineri.2 UX pentru organizații mici și mari Deseori discuțiile despre UX și ce discipline implică acesta lasă impresia că UXul este destinat doar organizațiilor foarte mari. În final. Dacă privim lucrurile din punct de vedere al resurselor umane desigur că organizațiile mai mari își permit să aplice setul de profesioniști menționat mai devreme dar asta nu înseamnă neapărat că organizațiile mai mici nu pot lansa procesul de proiectare centrat pe utilizator. de Jakob Nielsen au întâlnit o audiența vastă. cu atât mai multă atenție a început să se acorde detaliilor dincolo de uzabilitate. Uzabilitatea pune accent pe faptul ca orice interfață utilizator trebuie să fie eficace. Figura 2. UX a început să includă și alte teme. psihologilor. testeri. printre care discuții despre emoțiile utilizatorilor. psihologi. Chiar și cu deținerea unei popularități considerablile. Este mult mai important înțelegerea procesului decât acordarea de angajamente pentru fiecare rol. Ele au ajutat la explicarea principiilor proiectării centrate pe utilizator și la expunerea uzabilității. proiectanți grafici și vizuali. mai străine.1 T-shaped UX Professional Figura 2. Cheia pentru echipele de dimensiuni mai reduse este de a nu porni procesul de dezvoltare imediat ci de înțelege foarte bine ce doresc să construiască defapt. 2. eficientă și satisfăcătoare pentru utilizator. Acest lucru se poate face foarte ușor cu o cercetare pe internet după aplicații existente și deasemenea cu stabilirea clară a locului unde sunt plasate cerințele utilizatorului.

semnificative și valoroase ale interacțiunii om-calculator. întrebarea evidentă ce urmează se referă la rolurile minime necesare pentru scheletul unei echipe UX. Aceste trei roluri pune totul într-o poziție de start foarte bună în legătură cu conceptele corecte și necesare.2). 2. UX reprezintă totalitatea aspectelor cu care vine în contact utilizatorul unui produs. ajută foarte mult la competența echipei. Ergonomics of human system interaction . UX scoate în evidență aspectele experiențiale. Un profesionist ―T-shaped‖ are cunoștiințe și abilități din toate disciplinele UX și este specialist doar în unul din ele (vezi Figura 2. sistem sau serviciu‖. simțurile în relația cu produsul respectiv. Altfel spus. se menționează trei factori ce influențează UX-ul: sistemul. acțiunile. Mai departe echipa poate învăța noi discipline sau poate angaja noi membrii în echipă pentru a umple golurile.Deși echipele mici sunt conștiente de faptul că nu sunt în măsură să angajeze toți oamenii care să îndeplinească toate aspectele necesare unei echipe UX. adică ―criteriul de uzabilitate poate fi folosit pentru a evalua aspectele experienței utilizator‖. angajând un profesionist UX din modelul ―T-shaped Professional‖. UX este deasemenea un domeniu dinamic deoarece se modifică de-a lungul timpului odată cu schimbările circumstanțelor. Nota 3 al standardului sugerează că abilitatea de utilizare se adresează aspectelor UX-ului. percepția. ISO 9241-2101 definește experiența utilizator ca ―totalitatea percepțiilor și răspunsurilor unei persoane ce rezultă din utilizarea sau anticiparea utilizării unui produs. utilizatorul și contextul de utilizare. afective. sistem sau serviciu. Experiența utilizator se referă defapt la starea de emoție pe care o simte o persoană utilizând un anumit produs. Ca și notițe adiționale ale definiției date de ISO.3 Definirea conceptului Peste tot internet-ul găsim definiții mai mult sau mai puțin teoretice. oferă o acoperire expertă în cât mai multe discipline posibile (vezi Figura 2. Organizațiile care funcționează după modelul ―T-shaped‖ dar cu profesioniști multiplii. Dr. Din păcate standardul nu oferă alte explicații pentru clarificarea relației dintre experiența utilizator 1 ISO FDIS 9241-210:2009. UX este un domeniu destul de subiectiv deaorece este despre sentimentele și gândurile unui individ despre un anumit sistem. o persoană pentru modelare conceptuală și un designer (proiectant) vizual. și care îi pot influența comportamentul. dar deasemenea include percepțiile unei persoane asupra utilității.1). ușurinței de utilizare și eficienței unui sistem. Tobias Komischke (Director UX în cadrul Infragistics) sugerează să existe cel puțin o persoană pe post de analist. Desigur.Part 210: Human-centered design 5 . Tendințele de proiectare și de tehnologie din zilele noastre necesită ca obiectul de lucru să fie uimitor și să arate foarte bine chiar de la începerea procesului de producție al obiectului respectiv.

nu există o rețetă mai rapidă ce se poate urma. UX este intersecția dintre multiple domenii. o experiență cât mai eficientă. Cea mai importantă parte a științei este utilizarea metodelor științifice. Este vorba despre ciclul de luare a unei ipoteze. pentru ca teoria să poată fi absolvită va fi nevoie de dovezi colaborative. Și chiar și atunci. ușor de utilizat și învățat. Având în vedere faptul că asupra lui se aplică metode științifice nu putem spune că este o artă. la observație. la fel ca o serie de reguli sau o explicație despre cum funcționează ceva până în momentul de față. Teoria poate fi considerată ca fiind cel mai solid lucru.și uzabilitate. ca domeniu de sine stătător. cele două concepte se suprapun. Știința susține că ceea ce ne înconjoară să nu fie luat ca fiind valid sau adevărat ci ca tot ceea ce vedem să fie sprijinit de dovezi. dar nu tot timpul.4 Știința și design-ul Există multe păreri în legatură cu perspectiva din care ar putea fi văzut UX-ul: ca o știință sau ca artă. Putem astfel să comparăm cele două: metoda științifică și proiectarea UX (vezi Figura 2. Aceste semne de întrebări ajută la gândirea creativă.3). la experimentare și deasemenea la documentare.Orice ipoteză trebuie neapărat să aibe o dovadă. plăcută și lipsită de probleme. a imaginației și a creativității. util. Într-un fel seamănă cu proiectarea UX. grafică. nu este ca și coacerea unei prăjituri. aceasta trebuie pusă sub semn de întrebare. Cheia metodei științifice esțe utilizarea de cercetare a inteligenței.4). Deseori o teorie nouă este construită pe baza unei teorii deja existente. User Experience Design-ul(UXD). bazată pe idei anterioare. Singurul lucru ce lipsește este formarea ipotezei. în interacțiunile lor cu un produs sau un serviciu. de testare a ei. și nu în ultimul rând estetic. 6 . având utilizatorul ca obiect central. Pot fi implicate astfel cunoștiințe de arhitectura informației. În știință suntem învățați încă din prima zi să punem semne de întrebare asupra tuturor lucrurilor. ultima declarație. interface design. O teorie este doar într-o stare de așteptare. După cum se poate observa sunt foarte similare. Se poate întâmpla să fie necesară existența unui punct de vedere cu totul diferit. Desigur că trebuie reținut că o teorie nu este ― batută în cuie‖ ci este deschisă spre a fi schimbată. de fapt nu există. interaction design. 2. toate orientate spre a obține un produs ergonomic. Dacă există dovezi care sunt împotriva sa. cu uzabilitatea incluzând aspectele pragmatice(executarea unei sarcini) și experiența utilizator punând accent pe sentimentele și emoțiile utilizatorilor care rezultă din aspectele pragmatice și hedonice ale sistemului. de analiză a rezultatelor urmată de iterare (vezi Figura 2. În mod evident. marketing. Scopul designer-ului de UX este de a oferi utilizatorilor.

Cu toate acestea și în știință putem regăsi același moment de inovație.4 Asemănări între etapele metodei științifice și etapele proiectării UX Într-adevăr adevărata proiectare are toate aceste principii și reguli ce se pot aplica. Design-ul stimulează simțurile iar stimularea simțurilor este de obicei elementul cu care măsurăm creativitatea. acel element de creare a unui ceva bazată pe experiențe anterioare și pe mediul înconjurător. momentul de gândire ―outside the box‖. Acel ceva trebuie desigur să fie cuantificat ca ceva inteligibil de către comunitatea noastră. Metoda Științifică Metoda Științifică •Definirea problemei •Colectarea de informații •Formarea unei ipoteze •Experimentarea și testarea •Analiza output-ului •Interpretarea rezultatelor (formarea unei noi ipoteze) •Documentarea si publicarea •Revizuirea Proiectarea UX •Definirea problemei •Observarea și cercetarea •Dezvoltarea unui design •Testarea de către utilizator și prototiparea •Analiza și interpretarea rezultatelor •Documentarea •Implementarea Figura 2. Cu toate acestea cheia în acest context este faptul că proiectarea este un proces creativ nu unul analitic. se iterează și se crează modificări asupra prototipurilor utilizând rezultatele testării și 7 . momentul creativității.3 Proiectarea UX vs. se observă rezultatele. acea scânteie inovativă. Cu to ate acestea design-ul are acel element creativ. Procesul pentru acea creativitate și ce semnifică aceasta poate fi întotdeauna supus unei dezbateri. În design-ul UX se prototipează și se experimentează.Figura 2. Aceste reguli sunt ca și teoremele fundamentale în știință. lucru valabil și pentru proiectarea UX. doar că nu este deseori aplicat pe ceva ce este în mod tradițional considerat ca fiind creativ.

cum se așteaptă s-o facă și ce se așteaptă să rezulte la sfârșit? Proximitatea. Unele circumstanțe declanșează o nevoie și o așteptare corespunzătoare de satisfacție. în realitate. Cât este de ―apropiat‖ utilizatorul de partea necesară a sistemului? Conștientizarea. Și poate chiar și știința este doar design. acest ciclu ia o formă individuală. Utilizatorul poate face conexiunea între nevoile sale si parte necesară a sistemului? Indiciile sistemului se potrivesc cu așteptările utilizatorilor astfel încât să poată realiza această conexiune iar mai apoi să acționeze asupra ei? 8 . care încearcă să satisfacă speranțele. interconectat. visele. Având în vedere faptul că majoritatea principiilor UX sunt luate din inginerie care la rândul ei a luat principii din bazele metodelor științifice putem spune că.proiectările anterioare cu scopul de a găsi un design mult mai bun.5). proiectarea UX este o știință. Gestionarea așteptărilor în acel moment al ciclului devine cheia spre a oferi o ―întoarcere la experiență― satisfăcătoare ce va încânta utilizatorii (vezi Figura 2. nevoile și dorințele utilizatorilor. 2. A observat utilizatorul partea necesară a sistemului? Sau i-a fost distrasă atenția de altceva? Conexiunea. Este un ciclu. Ce se așteaptă utilizatorul să facă. Evaluare Așteptări Răspuns Proximitate Declanșator Acțiune Conștientizare Conexiune Figura 2.5 Ciclul și modelul UX Experiența utilizator nu este doar o simplă acțiune.5 Ciclul UX      Declanșatorul. Comparând rezultatele generate de interacțiunea cu sistemul și așteptările utilizatorilor. Așteptarea.

analiza competiției. utilizatorul nu va mai continua să folosescă sitemul și va încerca alte posibile căi sau va abandona ținta pentru moment. accentuarea unor grupuri. de exemplu. utilizatorul își va ajusta așteptările. acoperă toate activitățile profesioniștilor de UX. Este răspunsul cel așteptat? Satisface nevoia utilizatorului? Evaluarea. Pe baza rezultatelor comparării celor două. Desire. Dacă așteptările sunt gestionate bine și sunt îndeplinite consecvent. În Figura 2. ca de exemplu managementul. Action Noțiunea de ajustare ciclică a așteptărilor reflectă un concept din teoria jocurilor: utilitatea repetată și așteptată. Acest lucru include toate părțile ce au un interes în succesul sau eșecul produsului.   Acțiunea.6 se descrie modelul UX descris în E-Commerce Usability având ca principale avantaje următoarele:   Se bazează pe proiectarea centrată pe utilizator în standardul ISO 13407 Această abordare a proiectării centrate pe utilizator nu necesită nici o metodologie de dezvoltare specială: se poate aplica la proiecte ce utilizează tehnici de dezvoltare agilă dar și pe alte tipuri de proiecte. Se începe prin identificarea părților interesate pentru dezvoltarea noului produs. Dacă așteptările nu sunt îndeplinite. Interest. utilizatorul va continua ciclul până când nevoia inițială este îndeplinită. suportul tehnic și corpurile normative din industrie. în 5 ani. Mai departe se identifică viziunea UX a produsului: viziunea despre cum va fi văzută utilizarea produsului.  Analiza oportunității. Poate utilizatorul să execute acțiunea sau există o neconcordanță între modul în care se asteaptă să se realizeze și acțiunea concretă necesară? Răspunsul. 9 . Modelul ciclului UX sintetizează concepte din trei surse:    Conceptele lui Don Norman cu asocieri ulterioare cognitive de prezentare a unor metode Modelul AIDA din literatura de marketing – Awareness. Acest lucru oferă o proiectare-destinație care folosește la asigurarea progresului către țelurile design-ului. Utilizatorul compară răspunsul cu așteptările sale. Sistemul oferă un răspuns acțiunii utilizatorului. sondeje. Activități comune ale UX pe parcursul acestei etape includ: analiza părțlor interesate. Acest proces are patru etape principale.  Construirea contextului de utilizare. Ultimul pas al acestei etape este segmentarea pieței pentru produs în scopul de a identifica segmentul care va deveni punctul de concentrare pentru soluția de design.  Această etapă oferă contextul de afaceri a unui produs. În ciuda faptului că este o diagramă simplă.

prezentarea funcționalităților produsului și interacțiunea cu caracteristicile sale. Activitățile UX ce se utilizează de obicei în acestă etapă: ancheta contextuală. analiza incidentelor critice. Ultima parte a etapei este evaluarea uzabilității prin supunerea potențialilor clienți să realizeze anumite sarcini realistice. intervieverea utilizatorilor. a mediul în care vor folosi acest produs și a sarcinilor care vor sa le realizeze cu acest produs. analiza sarcinilor. prototipare pe hârtie sau electronică. obiectivul principal este să se creeze o descriere detaliată a clienților. începând cu schițe pe hârtie și continuând cu wireframes și prototipuri interactive. Mai departe se continuă cu dezvoltarea de arhitectură informațională: modelul conceptual al produsului. Analiza oportunității Analiza Crearea Segmenta părților viziunii UX rea pieței interesate Crearea UX Dezvoltarea de arhitectură informațională Construirea contextului de utilizare Construire Construire Identificare a profilului a profilului a de ―rute utilizatorul mediului roșii‖ ui Setarea indicatorilor de performanță Amplasarea ecranelor Evaluarea uzabilității Urmărirea utilizării de zi cu zi și îmbunătățirea continuă a produsului Figura 2.6 Modelul UX  Crearea Experienței utilizator.În această etapă. pe care echipa de management le utilizează pentru a determina dacă produsul este pregătit pentru a fi lansat. testarea uzabilității și revizuirea de către experți. jurnalele utilizatorilor. wireframing. se vor identifica rutele roșii: o listă de sarcini critice de care au nevoie utilizatorii pentru a conduce produsul spre succes. Mai departe se expun ecranele(proiectarea detaliată). Procesul începe prin dezvoltarea indicatorilor cheie de performanță a produsului: măsurători cantitative bazate pe clientul-cheie și necesitățile afacerii. În final. Această etapă este iterativă. tehnic și psihic în care va fi folosit produsul. 10 . sortare de carduri. Se începe prin construirea profilelor utilizatorilor: un set de personas ce descriu țelurile si comportamentele ale grupurilor-cheie de utilizatori a produsului. Activitățile UX ce se utilizează de obicei în acestă etapă: setarea metricii uzabilității. Mai departe se crează profilele mediului: descrierea mediului social.

Multitudinea de activități ce pot fi etichetate cu aceste două cuvinte încapsulează un spectru larg de oameni. Urmărirea utilizării în viața de zi cu zi și îmbunătățirea continuă a produsului. competențe și situații. logurile utilizării. Utilizatori / Clienți etc. Nu este nici măcar începutul sfârșitului. dacă cineva îți oferă UXD pentru o aplicație. Citatul ―Acesta nu este sfârșitul. . analiza apelurilor de sprjin. ce anume te aștepți să primești? Doar o persoană este responsabilă de UXD sau există o întreagă echipă cu această responsabilitate? Având aceste întrebări vom începe să răspundem de la conceptul de UXD. Acesta începe cu experiența – experiența utilizatorilor.6 Fațetele UX Există o mare confuzie și neînțelegere ce înconjoară termenul de ―user experience―.. În această fază se află de fapt cum este utilizat produsul în practică și se vor utiliza aceste statistici. perspective. Dacă soliciți proiectare UX (UXD) la ce anume te aștepți să primești? Similar. 2. Consumatori Parteneri / Colaboratori Membrii Investitori Părți din comunitate Producători / Creatori Agenți Persoane de decizie Figura 2. website sau intranet sau extranet. Activitățile UX ce se utilizează de obicei în acestă etapă: evaluarea la distanță. Este sfârșitul începutului. Așadar alegem ca un punct de start utilizatorul.7 Rolurile user-ului 2 Winston Churchill 11 . în vederea următoarei lansări sau chiar a următorului design a unui produs viitor..‖2 descrie cel mai bine această ultimă etapă.

Proiectarea experiențelor Gestionarea contextului tehnic Gestionarea contextului de afaceri Livrarea experiențelor Figura 2. Astfel. experiențe și cunoștiințe Fiecare utilizator are mai multe fațete și este mult mai complex decât își poate imagina. nu doar la ce spun. diferit. să se asculte punctul lor de vedere și să se recunoască ce decizii iau. De ce și ce tip de elemente vizuale le plac utilizatorilor. ce și cum. investitor. ceea ce ne spune mult mai multe. un individ deține un singur rol. ea devine o individualitate. ce preferă și/sau ce înțeleg aceștia? De ce și la ce tip de model mental. Uneori. Astfel nu este foarte util doar să existe o discuție cu utilizatorul pentru a afla cerințele sale. partener. membru. Arii de experiențe: arii diferite ce afectează calitatea comunicării 3 Jakob Nielsen . Fiecare persoană are în posesia sa un rol propriu.Alertbox 12 . Acestea fiind spuse. client.8 Experiențe. participant. consumator. Este necesar să se observe comportamentul său. Rețea de așteptări. Sau poate că persoana nu este chiar în acea situație. dar în principiu el va fii locțiitor pentru mai multe roluri ca: utilizator. Prin observare trebuie să se evalueze și să se înțeleagă de ce. de navigație sau de funcționalitate vor răspunde aceștia? Jakon Nielsen a declarat: ―Pentru proiectarea unei interfețe ușor de utilizat. Sau poate încearcă să facă testul să reușească mai mult decat încearcî să facă să îl pice. sau poate că este influențată de alți factori (de exemplu încercarea de a face pe plac testerilor). Poate că circumstanțele nu sunt realiste sau nu sunt rezonabile pentru acea persoană. creator. Susținerile utilizatorilor despre ei îșiși sunt nefiabile. parte a comunității. trebuie acordată atenție la ce fac utilizatorii. și așa mai departe (vezi Figura 2. producător.Persoana ca individualitate Fiecare persoana este caracterizată prin propria sa personalitate.7).‖3 . nici o afirmație a utilizatorilor despre ei înșiși nu sunt obiective. deoarece sunt speculațiile lor despre comportamente viitoare.

comportamentele și interacțiunile lor pentru a-și da seama de relația emoțională dintre ei și produsul ce se dorește a construi. J.experiențe viitoare așteptări clientul în prezent trecut . incluzând evenimentele subiective simțite de persoana care se confruntă cu ceea ce ne dorim să utilizeze. a crea) sunt explorate împreună. utilizatorul își aduce experiențele din trecut în interacțiunea din prezent și adaugă la acestea spertanțele și așteptările pentru viitor. a spune. În cea mai mare parte a timpului.‖4 Pesonal și individual Când vorbim despre experiențe. 4 J. acești oameni și experiențele lor sunt necunoscute. istoriile lor personale și experiențele lor. Este necesară o apreciere a clientului: călătoriile lor. Experiența Utilizator este despre cum funcționează pe exterior. luăm în considerare individualul. Experiențele sunt de moment și de scurtă durată – uneori sunt o parte dintr-un proces multi-stratificat sau sunt de sine stătătoare.Când cele trei perspective (a face. suntem în măsură să realizăm spectrul de experiență al utilizatorului/ clientului ―normal‖ pentru care lucrăm.foste experiențe securitate speranță cunoștiințe psihologie abilități simpatii / antipatii Figura 2. Dacă privim experiențele utilizatorilor ca un proces continuu. viitor . Planificarea UXD ia opiniile utilizatorilor. Acest viitor ar putea fi: interacțiunea cu tranzacțiile bancare într-un mod sigur și securizat.9 Cursul experienței: individul (utilizatorul / clientul) este întotdeauna în prezent . Jesse James Garrett a spus: ―Experiența Utilizator nu este despre modul în care un produs funcționează pe interior. Aceștia sunt influențați de foste experiențe și așteptări curente. Garrett – The Elements of User Experience 13 . atunci când utilizatorul intră în contact cu produsul și cum lucrează cu el.acționează în prezent.

În acest punct al prezentului intervine ―fagurele‖ lui Peter Morville. El va încerca tot timpul să facă referință la experiențe trecute. Ca practicanți nu putem ―picta între liniile desenate de către manager‖. lucrurile asupra cărora a acționat și lucrurile ce le-a simțit. Utilizabil. Când o persoană utilizează o aplicație. este vorba despre aprecierea nevoilor. brand și alte elemente de design emoțional. și fiecare acțiune ce o excutăm ia ambele părți în considerare. uzabilitatea este necesară dar nu suficientă. Pe scurt.10 "Fagurele" UX 14 .   Util Utilizabil Valoros Ușor de găsit Credibil Dezirabil Accesibil Figura 2. identitate. Astfel. în lumea virtuală. capabilităților și dorințelor utilizatorului nesatisfăcute într-un mod contextual. în perspectiva lui Peter Morville reprezintă:  Util. Ambele sunt combinate inseparabil. Momentul este deasemenea strâns legat de așteptările din perspectiva sa personală. ea încearcă să înțeleagă ce se întâmplă defapt. cerințelor. Misiunea de găsire a celei mai eficiente metode trebuie temperată de o apreciere a puterii și valorii de imagine. Experiențele și așteptările utilizatorilor se întâlnesc în prezent. Trebuie să avem creativitatea și curajul să ne întrebăm dacă produsul sau sistemul nostru este util și să punem în aplicare cele mai utile cunoștiințe. și totuși metodele centrate pe interfață și perspectivele interacțiunii om-calculator nu adresează toate dimensiunile design-ului. Este vorba de un pachet de experiențe ce include lucrurile pe care utilizatorul le-a văzut. abilități și soluții inovatoare.Ceea ce afectează experiența cu produsul și cu compania ce îl reprezintă se află în setul de experiențe al utilizatorului. Dezirabil. Ușurința de utilizare rămâne vitală. în lumea reală sau chiar în lucrurile mici (de exemplu: Cafeaua mea a fost rece în această dimineață). Fiecare fațetă sau calitate din .

Aici intervine din nou ―fagurele‖ lui Peter Morville. Trebuie să întelegem să proiectăm elemente ce influențează faptul că utilizatorii cred sau nu ceea ce le transmitem.  Accesibil. utilitate. Dacă UXD-ul este menit să descrie satisfacția. Așa cum și clădirile au lifturi și rampe. Fiecare din acestea își crează eficiența prin ofertele de design de la fiecare din următoarele elemente:       15 . psihologică.)?  Este ținta ușor de găsit pentru utilizator și pentru sarcina sa specifică?  Este aplicația credibilă pentru utilizator și pentru sarcina sa specifică? În planificarea UXD întreaga echipă trebuie să ia în considerare punctul de vedere al utilizatorilor cu privire la interacțiunea cu interfața utilizator pentru a putea contura relația emoțională dintre brand și potențialii clienți. Lucrul în echipă și cooperare Primul lucru în descoperire – de a inventa și proiecta pentru experiență – este de a lua în considerare un alt punct de vedere despre oamenii care cumpără și utilizează produsul sau serviciul pe care îl proiectăm.Ușor de găsit. așa și aplicațiile trebuie să fie accesibile persoanelor cu handicap (mai mult de 10% din populație). etc. Oamenii ajung să se întrebe ―Care este diferența între toți acești termeni și care este acela de care am nevoie?‖. uzabilitate și user interface design. În cazul nonprofit. human coputer interaction. Astfel este necesară o apreciere comună a ―călătoriei‖ clientului și istoriei sale personale: nu doar cu produsul sau cu produse similare. În zilele noastre acesta este un lucru bun și etic de realizat. Planificare UXD poate fi uneori un termen destul de ―alunecos‖ împreună cu mulți alți termeni care ―plutesc‖ în jurul lui: interaction design. Pentru celelalte cazuri. bucuria sau succesul utilizatorului cu o aplicație. trebuie să oferim livrabilele utilizatorilor și sarcinile specifice însoțite de cele mai bune răspunsuri la întrebările: Este aplicația utilă pentru utilizator și pentru sarcina sa specifică? Este aplicația ușor de utilizat pentru utilizator și pentru sarcina sa specifică? Este aplicația plăcută pentru utilizator și pentru sarcina sa specifică? Este aplicația valoroasă pentru utilizator și pentru sarcina sa specifică? Este aplicația accesibilă? Disponibilă pentru fiecare utilizator în parte. Fiecare element menționat mai sus constituie o componentă importantă a UX.  Valoros. dar de asemenea și cu experiențe similare. de învățare. un produs sau un website. pentru ca utilizatorii să găsească ce au nevoie. Trebuie să ne străduim să proiectăm site-uri web navigabile și obiecte ușor de localizat. UX trebuie să avanseze misiunea. indiferent de dizabilitatea sa (fizică. Dorința principală a noastră ca și proiectanți trebuie s-o reprezinte respectul. Aplicațiile trebuie să livreze o valoare sponsorilor noștrii. trebuie să contribuie până la bază și să îmbunătățească satisfacția clienților. valorificarea și înțelegerea continuității experienței și așteptării pe care le dețin utilizatorii. cu toate acestea există anumite chei esențiale care trebuie abordate. În prezent. information architecture.  Credibil. human factors engineering.

de simplitatea instrumentelor și caracteristicilor acestora. și multe altele. Acest lucru semnifică faptul că un produs este în măsură să ofere tipul de serviciu corect și exact cel așteptat de utilizator.11 Elementele proiectării și planificării UX 16 .Utilitatea se bazează pe practicabilitatea și ușurința în utilizare. Proiectarea vizuală este responsabilă de claritatea informațiilor și elementelor. Practicabilitate Uzabilitate Design de Interacțiune Design Vizual Utilizator/Client Arhitectura Informațională Accesibilitate Utilitate Figura 2. Deși accesibilitatea nu este un element de sine stătător. psihologice. Proiectarea unei interacțiuni este esențială pentru o experiență de succes și satisfăcătoare pe ansamblu. Arhitectura informațională (information architecture) este responsabilă cu claritatea informațiilor și caracteristicilor. Acest termen nu trebuie încurcat cu uzabilitatea care este utilizat în descrierea ușurinței de utilizare a unei aplicații. este important de observat că accesibilitatea are un rol important în UX pentru a crește aria de experiență. claritatea și simplicitatea informațiilor.11 descrie relația dintre elementele descrise mai sus. de învățare. Un sens al accesibilității se referă strict la persoane cu dizabilități: fizice. Figura 2. Oamenii tind să graviteze în jurul unui lucru mai ușor de utilizat indiferent pentru ce/cine a fost conceput. Astfel că proiectarea de interacțiune (interaction design) trebuie să răspundă la întrebări privind fluxul de lucru. de aspectul plăcut și interesant al interfeței și de look-and-feel-ul acesteia. logica. cu lipsa de confuzii și cu stabilirea unei curbe de învățare scurtă. Accesibilitatea este un termen obișnuit utilizat în descrierea ușurinței cu care utilizează oamenii anumite aplicații sau obiecte. instrument sau obiect de către orice tip de utilizator.

Design-ul detaliat oferă proiectarea exactă și o pre-vizualizare a comportamentului aplicației finale ce specifică ce trebuie codat. Cazurile de utilizare complete sunt mai apoi validate cu o populație de utilizatori cărora le este destinat produsul.12 Design workflow – workcycle – workspiral 17 .Procesul inovării în UXD poate fi reprezentat printr-o spirală neliniară formată din activități divergente și convergente ce se pot repeta de-a lungul timpului. În primul rând. Orice proces de proiectare începe cu o viziune. în evaluările rapide și iterative. Pentru a menține proiectul la timp. Cel mai obișnuit eșec în procesele UX este transferarea perspectivei utilizatorilor în proiectarea interfeței utilizator. la activitățile de lucru și la cerinţele utilizatorilor. Cazurile de utilizare arată pașii pentru a duce la bun sfârşit sarcinile setate ca și obiective și descrie conținutul necesar pentru a realiza interacțiunile. Acestea conduc la profilele utilizatorilor. Layout-ul dur permite experimentarea și evaluarea rapidă. Figura 2. Cu toate acestea. O preocupare principală în cazul proiectării este de a nu rămâne blocați într-o singură soluție prea devreme. o viziune nu este suficientă pentru a începe proiectarea. Acesta este un punct de control pentru a vedea dacă viziunea este realizată iar valoarea sa este clară pentru utilizatori și pentru echipa proiectului. Cheia este de a defini interacțiunea înainte. Cum am menționat mai sus. Evaluările iterative a utilizatorilor la ambele etape sunt conectate pentru a fi foarte rapide și efective în îmbunătățirea GUI-ului. și desigur în evaluările uzabilității. generând direct din interacțiunea definită. toată cercetarea (utilizatorului. diferite roluri și diferiți utilizatori. noi avem tot timpul diferite circumstanțe. Următorul pas este de a proiecta interfața utilizator. oferirea unui feedback asupra proiectării. Prin urmare este critic să înțelegem exact cerințele și nevoile utilizatorilor finali – întreaga sa experiență și așteptările sale. fără a o proiecta. Procesul UX se bazează pe cercetarea iterativă centrată pe utilizator pentru a putea înțelege utilizatorii și nevoile lor. Acest lucru se aplică în special în procesul UX. a produsului și a mediului) trebuie organizată și compactată într-o compoziție de cercetare de utilizator. Compoziția de cercetare de utilizatori conduce fluxul către cazurile de utilizare (use-case). acest pas ar trebui împărțit în două: într-un aspect structurat dur și un design exact și detaliat.

cum ar fi crearea de documente. persoana ce ia deciziile. dezvoltatorii front-end și back-end. Partea de planificare oferă un cadru. Acesta este momentul în care creativitate întâlnește așteptările. 18 . bordura unui buton sau unei iconiţe. ușurința de găsire și uzabilitatea. planificatorii. diagrame. Design-ul este considerat de obicei în contextul artei și altor eforturi creative.Ne întrebăm mereu și suntem întrebați: Care sunt livrabilele acestui proces? Livrabilele nu sunt pentru noi. clientul. Este fiecare detaliu.13). Termenul de planificare descrie procedurile formale utilizate în astfel de eforturi. ca și structura. toate acestea vor fi schimbate de planificarea UXD. etc. asupra design-ului și procesul prin care se poate ajunge la un produs bine conceput. sau hardware-ul. Partea de planificare este responsabilă cu organizarea și structurarea pentru a sprijini utilitatea. Câteodată se trece cu vederea peste acest lucru. sau look-and-feel-ul. Livrabilele sunt niște mijloace de comunicare cu mai multe persoane: manager-ul. obiectivele ce trebuie îndeplinite și strategiile ce trebui urmate. etc. Un design bun nu este doar interfața. dar în principiu pe părțile vizuale și pe stările de spirit. În final. designer-ul. sau tehnologia. Se poate spune că viziunea partajată a unei echipe are mult mai mult potențial decât cea a unei creativități individuale. pentru a discuta aspectele importante ce trebuie abordate. sau mai bine spus un framework. Punctul de vedere asupra arhitecturii informaționale. Fiecare membru al echipei ar trebui să aibă capacitatea de a gândi funcțional și de a anticipa consecințele activităților în întregul context. putem spune că este suma dintre fiecare element în parte. Când ne gândim la design în procesul UX ne axăm pe nevoile. dorințele și limitările utilizatorilor finali ai produsului conceput. Există o distincție între UXD si planificarea UX. etichetarea. sau modul în care funcționează. Un designer trebuie să ia în considerare părțile estetic-funcționale și multe alte aspecte al aplicației sau a procesului. Următoarea diagrama descrie diferite linii de lucru care ne conduc către anumite întrebări ce fiecare linie trebuie s-o îndeplinească (vezi Figura 2.

Figura 2.13 Planificarea UXD 19 .

16 Utilizatorul și interacțiunea cu elementele UX 2.14. Experiența utilizatorului cuprinde mult mai multe elemente decât interacțiunea utilizatorului. unul care se poate aplica dezvoltării de UXD și de planificare UX (vezi Figura 2. Acesta nu funcționează pentru UXD și planificarea UX. Figura 2.7 Experiența utilizatorului vs. Figura 2. În unele definiții.16). experiența utilizatorului însumează întreaga experiență 20 . în centrul oricărei echipe și de asemenea în centrul procesului trebuie să se afle persoana dominantă – utilizatorul (vezi Figura 2.15).Deseori întâlnim un plan de activități ca cel din Figura 2. Interacțiunea utilizatorului Există o diferență între experiența utilizatorului și interacțiunea utilizatorului. Figura 2.15 Planul de activități al UX Desigur.14 Plan general de activități Holger Maassen ne oferă un alt punct de vedere despre cum ar trebui să arate acest plan de activități.

unde interacțiunea este un element al acelui întreg process. O singură pată pe perete poate să reflecte asupra imaginii întregului restaurant.memorabilă din toate punctele de vedere. fiind interacțiuni cu produsul. Experiența utilizatorului începe ―out of the box‖ în unele filosofii de design. comandarea desertului și achitarea facturii sunt toate aspecte separate ale întregii experiențe de a merge la un restaurant. utilizarea efectivă a produsului. Pentru a exemplifica o să folosim o alta analogie.a unui produs. Citirea meniul. etc . ceva complet străin şi nou pentru ei. Știe clientul ce are de făcut și este experiența lui/ei placută la fiecare etapă a experienței – în fiecare dintre aceste interacțiuni? Știm cu toții că o singură interacțiune negativă poate distruge întreaga experiență. ei au ajuns să o ceară iar întrepinderile 21 . acesta este modul ideal de a crea o experiență a utilizatorului care va fi excelentă într-un mod unic și – în mod sigur.sau pentru că pur și simplu nu se potrivește cu restul de experiență a utilizatorului. Cutia este de fapt o primă interfață (este ușor de deschis? Pot să țină pasul?). Fiecare dintre aceste interacțiuni trebuie să fie testate și optimizate. Desigur trebuie să testăm interacțiunea utilizatorului și trebuie să ne asigurăm că acestea funcționează corect. Aici este momentul în care testarea experienței utilizatorului intră în joc. Utilizatoii nu numai că o așteaptă. unii oameni folosesc experiența într-un restaurant. Dar cât de bine îmbunătățesc ele și cât de bine se încadrează ele în experiența utilizatorului a produsului sau a serviciului? Cât de bine fiecare dintre interacțiuni se completează una pe alta? Vedem în continuare produse lansate și unde o singura interacțiune .8 Importanța UX Importanța experienței utilizator se află acum în fruntea tendințelor tehnologiilor și aplicațiilor. Acest lucru se poate întampla pentru că interacțiunea este prea ciudată sau pur și simplu prost concepută . În mod similar. un buton deplasat sau pierderea link-ului dorit pot fi critice pentru experiența web a unui utilizator. Acest proces se desfășoară pe parcursul tuturor articolelor pe care le deschide. toate aceste activități specifice.o singură etapă sau o parte din experiența completă – distruge întreaga experiență a utilizatorului. 2. chiar decenii. Chiar dacă testarea la acest nivel macro sau la o asemenea magnitudine ar putea părea prohibitivă. iar experiența utilizatorului include acea singură interacțiune. Click-ul pe un link este interacțiunea utilizatorului. Aceasta înseamnă faptul că gradul de utilizare a unui produs ar trebui să înceapă cu prima lor expunere în fața produsului ca și cum ar fi deschis un cadou surpriză. iar experiența de utilizare a unui produs poate dura ani întregi. Neglijența de a nu întreba clientul dacă mai dorește un pahar de vin poate să aibă ca rezultat un client nemulțumit. Aceasta îmreună cu multe alte interacțiuni ale utilizatorului și un număr de alți factori descriși complet însumează experiența utilizatorului.

rotirea și alunecarea obiectelor virtuale de-a lungului mesei. Toate site-urile.  Photosynth Photosynth creează spatii multidimensionale. să manipuleze conținutul digital prin utilizarea unor mișcări naturale.  Multi-Touch Dispozitivele bazate pe tehnologia Multi-Touch acceptă intrare de la degete multiple și de la mai multi utilizatori simultan. mobile sau desktop (vezi Figura 2. În acest univers condus de fizică. 2. stretching.17). nu trebuie să pierdem din vedere impactul pe care îl are bucuria unei experiențe web asupra produsului. cu o interfață tangibila multi-touch.  Microsoft Surface Multi-Touch-ul este totodata și nucleul lui Mircosoft Surface.9 Viitorul uzabilității și UX UX și uzabilitatea vor continua să se dezvolte. Factorul UX poate face sau distruge viabilitatea și farmecul oricărui software. Fiind receptivi la nevoile utilizatorului asigurăm succesul produsului. cu zoom și caracteristici de navigare care depășesc toate asteptările. permițând gesturi complexe. senzorul multitouch permite unui utilizator să interacționeze cu sistemul cu mai mult de un deget deodata. Aceasta este o documentație despre 5x5 m Cheoptics360 din showroomul Vizoo. inclusiv prinderea. aparatele și interfețele au un singur scop: sa fie utile pentru cei care interacționează cu ele. Cu toate acestea.  Reactable Reactable este un instrument colaborativ al muzicii electronice. În timp ce senzorul touch este un lucru obișnuit pentru punctele unice de contact. fie el aplicație Web. gesturi. Mai multi artiști controlează instrumentul simultan prin mutarea și rotirea obiectelor pe o suprafata luminoasa rotundă. fișierele importante obțin în 22 . Nu au fost folosite efecte specială pentru a edita acest film video. sau mai multor utilizatori.  BumpTop BumpTop este o nouă interfață utilizator care transformă desktop`ul uzual într-un desktop 3D glorios. o masă interactivă care permite unui utilizator.și afacerile se confruntă cu achiziția de un UX cât mai bun pentru software-ul lor.  Viitorul pentru gameri Cheoptics360 este un produs al Vizoo care poate schimba viziunea asupra tehnologiei 3D pentru totdeauna.

Figura 2.17 Importanța UX 23 .

sistem de redimensionare.sfârșit importanța pe care o merită printr-un ciudat. Platforma cea mai cunoscută și evidentă este platforma mobilă. Designerii de UX se găsesc din ce în ce mai des în situații în care proiectează pentru o gamă largă de produse dincolo de web și software pentru PC-uri. apare și nevoia de a proiecta pentru UX. 24 . Senzorii ne permit să proiectăm medii fizice care să răspundă la activitatea dorită. și în același timp satisfăcător. dar există și alte dispozitive noi. și oriunde există un procesor. aria computațională este peste tot. Pur și simplu. de la televizoare conectate la console și tablete.

UCD poate fi caracterizat ca un proces cu etape multiple de rezolvare a unei probleme care nu necesită doar designeri care să analizeze și să prezică modul în care utilizatorii vor utiliza produsul. în schimb celelalte forțează utilizatorii să își schimbe comportamentul pentru a se acomoda cu produsul. Standardul ISO 13407 (vezi Figura 3. Procesul asigură:     Implicarea timpurie a utilizatorilor O protrivire adecvată a funcțiilor cu sarcinile utilizatorilor O iterare suficientă a soluțiilor de design O abordare multi-disciplinară Există patru componente principale:     Înțelegerea și capturarea contextului de utilizare Specificarea cerințelor utilizatorului. Diferența majoră dintre alte filosofii de proiectare a produselor și cea centrată pe utilizator este că aceasta din urmă încearcă să optimizeze produsul în jurul capabilităților. cererile.1 Definirea conceptului User-centered design(UCD) este o filisofie de proiectare și deasemenea un proces în care nevoile. UCD este un proces sitematic și repetabil. ce s-a dovedit a furniza. dorințele și constrângerile utilizatorilor reprezintă nucleul atenției acordate la fiecare etapă a procesului de proiectare. întreprinderii și ale organizației Crearea de mai multe soluții conceptuale de design Validarea soluțiilor cu cerințele utilizatorilor și repetarea procesului atunci când este necesar 25 . Procesul UCD implică utilizatorul pe tot parcursul procesului de crearea al produsului sau serviciului. uzabilitate mare (ISO 9241) și UX de succes pentru clienți și utilizatori finali. necesităților sau cererilor utilizatorilor. pe parcursul multor proiecte și in multe domenii industriale. ci și să testeze validitatea ipotezei în ceea ce privește comportamentul utilizatorilor în teste din viața reală cu utilizatori concreți.1) este o versiune mult mai recentă a acestei abordări și descrie elementele a ceea ce denumește Proiectare centrată pe om (Human Centered Design).3 Proiectarea centrată pe utilizator 3. Asemenea testare este necesară deoarece proiectanților de produse le este dificil să înțeleagă intuitiv cum va decurge prima experiență a utilizatorului cu produsul și cum va arăta curba de învățare a utilizatorului.

Din 1990 exista o conferința bianuală denumită Participatory Design Conference. sortare de cărți.2 Modele și abordări UCD ajută proiectanții de software să atingă ținta produsului creat pentru utilizatori.1. specificarea utilizatorului și a necesităților organizaționale Figura 3. Cerințele utilizatorilor sunt luate în considerare chiar de la început și sunt incluse în tot ciclul de producție a sotfware-ului.Part 210: Human-centred design for interactive systems 26 . sesiuni de proiectare cu participanți. Aceasta este o tradiție scandinavă și și-a început evoluția încă din 1970. planificarea procesului centrat pe om Produs complet 2. testare de prototipuri. evaluarea design-ului în contrast cu necesitățile utilizatorului 4. Ergonomics of human-system interaction -. Poriectarea participativă.1 Priverea de ansamblu asupra modelului ISO 13 407 3. Inspirate de Cooperative Design axându-se pe participarea utilizatorilor. specificarea contextului de utilizare 5. Obținerea cerințelor 5 ISO 9241-210:2010. Modele ce urmează standardul ISO5:    Proiectarea cooperativă. 3. În contextul actual ―proiectarea centrată pe client‖ ce include câteva din ideile proiectării participative. Proiectarea contextuală. producerea soluțiilor de proiectare 3. anchete contextuale. testare de uzabilitate și multe altele. Aceste cerințte sunt notate și trecute prin metode de investigare ca: studii etnografice. Metode mult mai generale pot fi incluse: diagrame de afinitate. Implică proiectanți și utilizatori la egalitate.3 Procesul proiectării experienței utilizator 1.

o Wireframes Sunt de obicei utilizate pentru a schița structura unei pagini Web. Testarea software Este recomandată testarea prototipului UI pe utilizatori reali. Există multe tehnici și instrumente pentru a face acest lucru. este important să cunoaștem și să concentram obiectivul dezvoltării. Acest lucru ajută la identificarea și soluționarea problemelor de proiectare devreme în procesul de dezvoltare. Trebuie să discutam cu părțile interesate și cu utilizatorii pentru a afla nevoile reale. Utilizatorul primește o sarcină pe care trebuie să o rezolve iar el 27 . o Prototip Interactiv Cea mai costisitoare și reală abordare este de a crea un prototip (reutilizabil) interactiv care funcționează ca cel real. Este util doar să se schițeze interfața utilizatorului pentru a prevenii discuțiile precoce despre detaliile de design. 3. Prototipul poate fi rulat într-un player individual. Crearea și validarea prototipului UI Crearea unui prototip de interfață utilizator este un pas important pentru a face schimb de idei între utilizatori și ingineri pentru a crea o întelegere comună în privința designului interacțiunii. Trebuie apoi prioritizate sarcinile după risc și importanță și să se lucreze iterativ. Următoarele tehnici sunt foarte populare pentru evaluarea protipurilor UI: o Ghid pas cu pas Se realizează de obicei devreme la începutul unui nou proiect cu wireframes sau prototipuri pe hârtie. Se numesc Wireframes deoarece desenează doar conturul controalelor și imaginilor. care are un mecanism de feedback integrat.Expression Blend 3 Sketch Flow este o caracterestică nouă folosită pentru a crea prototipuri interactive direct în WPF. 2. Implementarea de business logic și de interfață utilizator ―brută‖ 4. Aceste nevoi ar trebui apoi reduse în termeni de caracteristici și exprimate în cazuri de utilizare (abstract) sau scenarii de utilizare (ilustrativ). Nu este nevoie de alte instrumente și infrastructură. Toata lumea își poate schița ideile pe hârtie. Toate acestea trebuie realizate de inginerul cerințelor. Acest lucru poate fi realizat cu ajutorul instrumentelor: PowerPoint sau Visio. Se poate utiliza stilul ―wiggly‖ care este integrat și care ii da prototipului un aer schițat. Unele dintre acestea sunt: o Prototipul pe hârtie Se utilizează hârtie și creion pentru a desena schițe brute ale interfeței de utilizator. Integrarea proiectării vizuale 5. o Sketch Flow . Această sarcină este de obicei a unui designer de interacțiune. dar cu date fictive.Ca în orice alt proiect software.

modelele 3D sau schemele de culori.  Designerul Grafic Designerul graphic este responsabil cu creearea unui concept grafic și cu construirea unor obiecte grafice cum ar fi pictogramele.controlează prototipul prin atingerea lui pe hârtie. El creează modelul de date. logo-urile. Figura 3. 28 . implementează business logic și le leagă pe toate pentru o vizualizare simplă. avem nevoie de un calculator cu un software de captură de ecran și un aparat de fotografiat. Ei nu ar trebui să interacționeneze cu persoana care încearcă prototipul pentru a afla unde se blocheaza și de ce.2 Procesul de proiectare centrată pe utilizator 3. o Laboratorul de uzabilitate Pentru a face un laborator de uzabilitate.  Dezvoltatorul Dezvoltatorul este responsabil cu implementarea funcționalității unei aplicatii. Cel care încearcă prototipul primește apoi o sarcină de îndeplinit iar inginerul de cerințe și inginerul de interacțiune îl urmăresc ducând la îndeplinire sarcina.4 Roluri în construirea de UI Construirea unei interfețe utilizator modernă cu o bogată experiență de utilizare necesită abilități suplimentare de la echipa de dezvoltare. Liderul de testare apoi prezintă o nouă hârtie care arată starea prototipului după interacțiune. Aceste abilități sunt descrise ca rolurile care pot fi distribuite între oamenii din echipa de dezvoltare.

Acest rol are nevoie de un set unic de abilități și este de cele mai multe ori foarte greu de găsit persoana potrivită pentru a îndeplini acest rol. El creează wireframe-uri sau schițe UI pentru a împărtăși ideile sale cu restul echipei sau cu clientul. 29 . El ia obiectele de la designerul grafic și le integreaza în interfața brută a dezvoltatorului. Designerul interacțiunii Designerul de interacțiune este responsabil pentru conținutul și fluxul interfeței utilizator. El ar trebui să își valideze munca prin a face ghiduri pas cu pas sau schițe.  Integratorul Integratorul este artistul care face legătura între designer și lumea dezvoltatorilor.

Pe parcursul ultimilor ani dezvoltarea sistemelor software cu interfață grafică extrem de interactive a devenit tot mai comună. Gordon şi Bieman au inventariat şi prezentat un sondaj al rapoartelor de experiență publicate şi nepublicate. Recent. Este foarte potrivită pentru acumularea de experienţă în aplicații noi şi pentru a sprijini dezvoltarea de software elementară sau evolutivă. academic şi militar. Multe rapoarte de experienţă privind realizarea de prototipuri au fost publicate. 6 publicat în Proas. Prototipurile sunt tot mai folosite ca o mașină de elaborare şi demonstrare a viziunilor de sisteme inovatoare. lucru care este unul dintre motivele pentru care cele mai multe dintre ele au avut succes. În această lucrare vom prezenta conceptele de bază din spatele prototipării interfeţei cu utilizatorul. o clasificare a tool-urilor de sprijin pentru aceasta şi un studiu de caz de nouă proiecte industriale majore. Acceptarea unor astfel de sisteme depinde în mare măsură de calitatea interfeței lor cu utilizatorul. Pe baza analizei noastre a acestor proiecte vom prezenta următoarele concluzii: Prototiparea este folosită într-un mod mai conştient decât în ultimii ani. Acceptarea unui astfel de sistem depinde în mare măsură de calitatea interfeței cu utilizatorul a acestuia. din 18 International Conferinţa privind Software Engineering (ICSE) Berlin. rezultând concluzii cu privire la beneficiile şi posibile probleme în domenii cum ar fi calitatea de proiectare şi gradul de participare al utilizatorilor finali. Ele ilustrează impactul prototipării atât în construirea cât și în restul procesului de dezvoltare software. Prototiparea este un mijloc excelent pentru generarea de idei despre modul în care o interfaţă de utilizator poate fi proiectată şi ajută la evaluarea calității unei soluţii într-un stadiu incipient. Ei au identificat trei tipuri de rapoarte de experienţă: comercial. Rapoartele au fost analizate din punct de vedere al procesului și al produsului.4 Prototiparea interfețelor utilizator „În ultimii ani a devenit tot mai frecventă dezvoltarea sistemelor de software cu interfață grafică și cu un nivel foarte mare de interactivitate. douăzeci şi cinci au 30 martie 1996 30 .‖6 Prototiparea este o abordare de dezvoltare folosită pentru a îmbunătăţi planificarea şi execuţia de proiecte software prin dezvoltarea de sisteme software executabile (prototipuri) în scopuri experimentale. Prototiparea reprezintă un mijloc excelent pentru generarea de idei despre modul în care o interfaţă cu utilizatorul poate fi proiectată şi ajută la evaluarea calității unei soluţii încă dintr-un stadiu incipient. Nici un proiect nu a mai aplicat o abordare tradițională pe baza ciclurilor de viaţă.

Aceasta duce la experienţa cu privire la oportunitatea şi fezabilitatea unui anume design/implementare. Există diferenţe în interpretarea "E"-urilor: explorator. prototipări de prezentare şi prototipări funcţionale. O scurtă trecere în revistă a proiectelor investigate este urmată de o analiză a aplicării abordărilor prin prototipare şi a tool-urilor. prototipuri funcţionale şi breadboards.  Prototipuri de prezentare sunt construite pentru a ilustra modul în care o aplicaţie poate rezolva cerinţele date. construirea de sisteme-pilot este de o importanţă deosebită. Prototiparea evolutivă este un proces continuu de adaptare a unui sistemaplicaţie la constrângeri organizaţionale care se schimbă rapid. În acest articol vom prezenta un studiu de caz pe nouă proiecte industriale majore în care accentul principal a fost pe prototiparea interfeței cu utilizatorul şi în care diferite instrumente au fost utilizate pentru a construi diferite tipuri de prototipuri. Ea începe cu o scurtă introducere a prototipării şi o descriere a terminologiei folosite.   4. Rezultatele sunt de obicei. de obicei. de asemenea. Deoarece ele sunt adesea folosite ca parte a propunerii de proiect. 4.Aceasta duce la discuţiile despre ceea ce ar trebui să fie realizat la o anumită sarcină şi de modul în care aceasta poate fi susţinută de către IT. Deşi în procesul de prototipare evolutivă se pot construi tot felul de prototipuri.  Prototiparea exploratorie are rolul de a clarifica cerinţele şi potenţialele soluţii. Prototiparea experimentală se axează pe realizarea tehnică a cerinţelor selectate.Acesta este motivul pentru care prototiparea interfeței cu utilizatorul este aplicată într-un număr tot mai mare de proiecte. Rezultatele sunt.  31 . experimental şi evolutiv. important să se clasifice diferitele tipuri de prototipuri care pot fi construite. Acesta nu este folosit în cadrul unui singur proiect.1 Abordări ale prototipării interfeței cu utilizatorul Pentru clasificarea abordării prototipării. Prototipuri funcționale implementează părţi de importanţă strategică atât a interfeţei cu utilizatorul cât şi a funcţionalităţii unei aplicaţii planificate. În cele ce urmează vom discuta doar abordarea de proces. Distingem două abordări diferite: abordarea de proces care se concentrează asupra procesului de dezvoltare şi a obiectivelor sale şi abordarea de produs care se concentrează asupra rezultatelor procesului.2 Clasificarea prototipurilor interfeţei cu utilizatorul Pe langă clasificarea diferitelor abordări de prototipuri este. în Europa este larg acceptat şi utilizat modelul Floyd trei "E". acestea sunt puternic axate pe interfaţa cu utilizatorul.

editoare de program şi depanatoare.3 Clasificarea tool-urilor de prototipare a interfeţei cu utilizatorul În analiza proiectelor am identificat patru categorii de tool-uri care au fost folosite pentru a construi prototipuri ale interfeţei cu utilizatorul. 4GS prevăd. Doar constructorii de interfaţă cu editor grafic sunt de interes pentru prototipare. cum ar fi generatoare de raport. 32 . de obicei.Acestea sunt construite pentru a investiga anumite aspecte de risc deosebit. mai departe vorbim despre tool-uri asemenea HyperCard-ului. Link-urile pot fi utilizate pentru a conecta rapid un set de stări ale interfeţei cu utilizatorul într-o aplicaţie-schiţă in timp ce funcţionalitatea "reală" poate fi pusă în aplicare cu script-uri. Sisteme-pilot sunt prototipuri foarte mature. Prototipurile interfeţei cu utilizatorul variază de la prototipuri de prezentare schiţă la sistemele-pilot deplin funcţionale. linkuri. cum ar fi arhitectura de sistem sau funcționalitatea unei aplicaţii planificate. tool-uri pentru proiectarea grafică a modelelor de date şi interfeţelor de utilizator. În această lucrare vom folosi frecvent termenul de "prototip al interfeţei cu utilizatorul" pentru un prototip care are rolul de a clarifica aspecte ale interfeţei cu utilizatorul. Clasificarea acestuia depinde de cum şi în ce măsură funcţionalitatea acestuia a fost pusă în aplicare. care pot fi aplicate practică.  Breadboards servesc pentru a investiga aspectele tehnice.  Tool-uri de tip HyperCard HyperCard este un tool ce asigură un mediu interactiv pentru dezvoltarea de sisteme simple de informaţii cu interfeţe grafice formate din cărţi. Ele nu sunt destinate pentru a fi evaluate de către utilizatorii finali. fie textual sau cu un editor grafic. Din acest motiv.  Constructori de interfaţă Acestea sunt tool-uri care servesc pentru a defini interfeţele utilizator la un nivel ridicat de abstractizare. vom defini pe scurt aceste categorii. script-uri de manipulare a evenimentelor. Pentru a oferi o terminologie bine definită. Ele susţin crearea şi dispunerea elementelor de interfaţă cu utilizatorul.  Sisteme din generaţia a patra Un sistem de generaţia a IV-a (4GS) este un mediu de dezvoltare complet pentru sistemele informatice. Succesul lui HyperCard a dus la dezvoltarea de clone pe diverse platforme. teancuri de cărţi. un sistem integrat de interpretare a limbaj de scripting şi diverse alte tool-uri. 4. Combinaţia de link-uri şi script-uri face HyperCard un puternic tool de prototipare. Acestea sunt ideale pentru realizarea de prototipuri de sisteme informatice. deoarece cu ele se pot construi foarte rapid prototipuri complet funcţionale.

Un furnizor de transport public intenţionează să introducă o nouă generaţie de distribuitoare automate de bilete. ci şi arhitectura întregului sistem. Account Representative Support System (ARS) O bancă mare doreşte să îmbunătăţească calitatea asistenţei lor pentru clienţi cu o nouă generație de sisteme software. 33 .4 Proiecte analizate În această secţiune vom face o scurtă prezentare a proiectelor analizate. Numele proiectului Descriere Customer Advice System (CAS) Un furnizor de software bancar dezvoltă un nou sistem de consiliere a clientului. Datorită importanţei calităţii interfaţei cu utilizatorul ca parte a licitării trebuie prezentat şi un prototip al interfeţei. Framework-urile orientate pe obiect fac posibilă dezvoltarea interfețelor utilizator bazate pe manipularea complexă directă într-un timp scurt. ce abordări au fost aplicate şi cu ce fel de tool-uri. Aceasta solicită mai multor companii să liciteze pentru contract. Tabelul 4. Ticket Vending Machine (TVM) O firmă de dezvoltare software intenţionează să adapteze unelte de dezvoltare UNIX GUI pentru Debugger standard platformei sale. Departamentul de inginerie software-ul al unei universităţi primeşte un System (PCT) contract pentru a dezvolta un astfel de sistem. Aceasta include dezvoltarea unei interfeţe grafice de utilizator (GD) pentru o linie de comandă de depanare. 4. lucru obişnuit la asemenea aplicaţii. Ele sunt potrivite pentru realizarea de prototipuri de interfeţe care nu pot fi compuse din componente standard.1 prezintă pentru fiecare proiect un acronim şi o scurtă descriere.şi tridimensionale. Framework-uri de aplicaţie orientate pe obiect Acestea sunt bibliotecile de clase care cuprind un design abstract reutilizabil pentru aplicaţii interactive centrate pe documente. imagini bi. în cadrul a două tabele. Acest lucru scade riscul de a face greșeli majore arhitecturale în timpul prototipării şi uşurează evoluţia treptată de la prototip la sistemul final. O companie specializată pe construirea de instalaţii mari de prelucrare a oţelului doreşte Project Calculation să îmbunătăţească procesul de dezvoltare cu un nou proiect de calcul şi de control al and Transaction sistemului. Obiectivul major este de a obține o interfaţă care facilitează unui consilier de clienţi accesul la sarcini complexe. O primă aplicţie este construită pentru sprijinul reprezentanţilor de cont. precum şi implementări concrete a funcţionalităţii. Un astfel de sistem trebuie să furnizeze un client cu text scris şi vorbit. Tabelul 2 arată ce fel de prototipuri au fost construite. Un asemenea framework oferă nu numai componentele interfeţei. Multimedia Sales Support System (MSS) O mare companie de automobile doreşte să afle dacă are sens să sprijine forţa de vânzări cu un sistem multimedia de sprijin al vânzărilor. precum şi filme despre produsele actuale.

1 Proiectele investigate cu privire în ansamblu ansamblu CAS TVM GD MSS prezentare Prototipuri construite funcţional breadboard sistem-pilot explorator Abordarea utilizată în prototipare experimentală evolutivă HyperCard Instrumentele utilizate instrument de construcție de intefețe 4GS framework Tabelul 4. Un departament de cercetare dezvoltă un sistem de îmbunătăţire a calităţii sistemelor Function Editor for mecatronice (sisteme compuse din piese mecanice și electronice).5 Analiza punerii în aplicare a prototipurilor După această scurtă prezentare a proiectelor investigate am rezumat constatările relevante pentru realizarea de prototipuri.SWIFT Message Editor (SME) Un furnizor de software bancar investighează cazul în care un nou mod de a gestiona mesajele inter-bancare (SWIFT) ar fi acceptat de către clienţii săi. O componentă a Technical Systems acestui sistem este o aplicație pentru specificarea interactivă. Principalul domeniu de interes este dacă actualii clienţi sunt dispuşi să utilizeze un tool interactiv pentru definirea fluxurilor mesaj. Departamentul de cercetare al unei bănci mari dezvoltă un prototip care permite Swaps-Manager (SM) comercianţilor de swap-uri să îşi definească.2 Prototipurile. simularea şi analiza (FET) sistemelor mecatronice. simuleze şi analizeze oferte complexe în timp ce acestea sunt tranzacţionate de pe telefon. Am analizat proiectele punând accent pe următoarele trei întrebări:    Care au fost motivele construcției de prototipuri? Care a fost strategia de dezvoltare globală care a dus la construirea de prototipuri? Care este relaţia dintre prototipuri şi sistemele finale? 34 . Tabelul 4. abordările utilizate şi uneltele folosite PCT ARS SME FET SM • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 4.

3). În plus.4. însă. Este important ca ele să schiţeze soluţia intenţionată şi să fie uşor transmisibile. În rezumat. Acest lucru este încurajat prin adoptarea unei abordări prin prototipare.nici un obiectiv explicit. nici vreo fază separată de analiză de informaţii la începutul proiectelor.? nu sunt menționate) În mod similar.6 Obiective pentru construcția de prototipuri Proiectele investigate arată în mod clar că prototiparea este bine adaptată pentru a dezvolta şi a comunica o viziune a viitorului sistem printre membrii echipei de dezvoltare (vezi Tabelul 4. prototipurile contribuie la creşterea probabilităţii ca divzia IT şi de management al clienţilor să ia o decizie favorizată de echipa de proiect. Surprinzător. Frecvent. Nu a fost. (+) obiectiv de importanţă secundară. Este interesant faptul că această cunoaştere specifică domeniului nu a fost realizată cu ajutorul experţilor externi. doar câteva dintre ele au beneficiat de ajutor de la un expert în interfeţe de utilizator sau de la un designer grafic. de asemenea. Întrebări tehnice pot apărea în timpul întregului proces de dezvoltare şi sunt rareori adresate exclusiv de către membrii echipei. În tot mai multe proiecte analiza zonei de aplicare este considerată o parte integrantă a procesului de dezvoltare. de obicei. consultați odată ce o viziune coerentă a fost construită. Deducem din aceste observaţii că prototiparea este un mijloc util pentru transferul de cunoştinţe între dezvoltatori şi utilizatorii finali. utilizatorii finali nu sunt consultaţi în aceste cicluri de prototipuri. Nu este o surpriză faptul că multe proiecte se concentrează pe testarea şi măsurarea calităţii aspectului aplicaţiilor. baze de date sau hardware. CAS TVM GD MSS PCT ARS SME FET SM viziuni generatoare decizie sprijinirea deciziilor evaluarea aspect şi se simt analiza de susţinere a domeniului arată fezabilitatea tehnică + + + + + + + + + ? + + + + (+) -+ ? ? + + ? + ? + + + (+) + + (+) (+) + ? + + + + + (+) + Tabelul 4. nu este important ca aceste prototipuri să modeleze aspecte specifice şi tehnice ale domeniului în detaliu.3 Goluri pentru constructii de prototipuri (+ Scopul proiectului explicit. De obicei. cum ar fi crearea de reţele. . Utilizatorii finali sunt. decât dacă aceştia sunt o parte integrantă a echipei. În multe proiecte. observaţiile sprijină ideea că atât cunoştinţe specifice domeniului cât şi cele tehnice trebuie să fie disponibile într-o echipă de proiect. următoarele tendinţe au fost observate: 35 . Experţii sunt frecvent consultaţi în domenii specifice. prototipuri au fost construite pentru a răspunde la întrebări tehnice.

Prototipurile sunt un mijloc excelent de a dobândi ambele tipuri de cunoştinţe şi de a le evalua împreună cu experţi.7 Strategii de dezvoltare şi procesul de prototipare Studiul arată în mod clar că. Aici managementul încearcă să reducă la minimum comunicarea. Aceste echipe sunt formate din dezvoltatori şi experţi în domeniul de aplicare.    Prototipurile sunt construite pentru a dezvolta strategii pentru soluţii tehnice şi specifice domeniului Acestea influenţează luarea deciziilor într-un mod care nu este posibil cu rapoarte scrise. Nu este o surpriză faptul că proiectele pe care le-am studiat nu au fost organizate într-un mod convenţional.4). Cu toate acestea. cum ar fi scenarii de utilizare. Experţii domeniului de aplicare participă în mod regulat atunci când este important să se evalueze deciziile de design. Această comunicare funcţionează numai dacă suportul adecvat este disponibil (vezi Tabelul 4. prin prevenirea comunicării între dezvoltatori şi utilizatorii finali cu excepţia de la începutul ciclului de viaţă al softwareului. Prototipurile s-au dovedit a oferi acest sprijin adecvat. în cele mai multe proiecte importanţa comunicării între dezvoltatori şi utilizatorii finali a fost recunoscută. prototipuri şi documente de dezvoltare. Atât cunoştinţele specifice domeniului cât şi cele tehnologice sunt necesare întro echipă de dezvoltare. dar ei trebuie să fie pe deplin acceptaţi şi integraţi în echipă. În cele mai multe dintre proiecte investigate a fost aplicată o strategie de dezvoltare evolutivă. Importanţa utilităţii în calitatea unei aplicaţii a fost recunoscută.nici un obiectiv explicit. . Acest lucru nu implică neapărat că aceştia din urmă trebuie să lucreze cu normă întreagă pentru proiect. Această constatare contrazice ideea care stătea la baza strategiilor convenţionale de proiect. (+) obiectiv de importanţă secundară.? nu este menţionat) Echipe interdisciplinare reprezintă o modalitate importantă de a stabili o comunicare continuă. Utilizarea prototipului în acest scop este în contradicţie cu strategiile clasice de tip "ciclu de viaţă". 4. Aceasta este o strategie care nu implică o succesiune de etape 36 .4 Strategii ale procesului de prototipare (+ Scopul explicit al proiectului. CAS TVM comunicarea utilizator-dezvoltator echipa interdisciplinară dezvoltarea evolutivă de sistem evaluarea tool-urilor + + + + + + + (+) + GD (+) MSS + (+) PCT + + ARS SME + + (+) (+) + (+) (+) (+) FET + (+) (+) SM (+) + (+) (+) Tabelul 4. specialiştii în acest domeniu nu sunt încorporaţi în echipe.

deşi acest lucru nu a fost planificat în avans. între timp existând o nouă generaţie de tool-uri de prototipuri. Într-o strategie evolutivă fazele sunt înlocuite de procese iterative în cadrul cărora prototipuri diferite sunt proiectate. evaluarea acestora trebuie să fie planificată ca parte a unei strategii de dezvoltare evolutivă în dezvoltarea de aplicaţii inovatoare. Calitatea tool-urilor de prototipare diferă mult iar setul de tool-uri disponibile se schimbă în mod constant.ciclului de viaţă. Importanţa acestui tip de comunicare este în creştere. Acest lucru are sens pentru dezvoltarea de prototipuri acolo unde tool-urile pot fi uşor interschimbate. următoarele tendinţe au fost observate:  Prototipurile sunt un mijloc important de comunicare între dezvoltator şi utilizatorul final. Din acest motiv. A fost chiar un scop secundar în mai multe proiecte să se evalueze calitatea tool-urilor de dezvoltare în timpul prototipării. Piaţa de tool-uri este încă dificil de studiat şi se modifică rapid. Obiectivele majore au fost obţinerea de informaţii experimentale cu privire la fezabilitate sau experienţă (vezi Tabelul 4.5). implementate şi evaluate în funcţie de decizii critice specifice domeniului sau decizii tehnice care trebuie luate. În rezumat. CAS sistemul-ţintă planificat sistemul-ţintă construit reutilizarea de blocuri + + - TVM + - GD + + + MSS - PCT + + + ARS - SME (-) + + FET (-) - SM (-) - - - - - (+) + 37 . cum ar fi VisualAge şi VisualBasic. Prototiparea este astăzi o parte integrantă din aceste strategii evolutive.   4. Tool-uri cum ar fi HyperCard şi-au pierdut atracţia de când am efectuat studiu. Am găsit chiar şi proiecte cu rezultate care au fost atat de convingatoare încât s-a decis să se dezvolte un sistem-ţintă.8 De la prototipuri la sistemul dorit Mai multe dintre proiectele investigate nu au avut drept ţintă un sistem final. Deciziile dacă să continue sau să abandoneze un proiect sunt de obicei luate la sfârşitul evaluării unui prototip.Se pare că înţelegerea că prototipurile sunt surse excelente de idei inovatoare chiar şi în industrie a crescut. Nesiguranţa generală despre ce tool ar trebui să fie ales şi ce tip de prototip construit a fost de asemenea observată în proiectele studiului. Un pas foarte important în numeroase proiecte a fost implementarea sistemelor-pilot pentru utilizatorii finali. Tradiţionalele abordări de tipul "ciclu de viaţă" sunt înlocuite cu strategii evolutive în proiecte axate pe construirea de sisteme user-friendly. Dintr-un punct de vedere organizatoric. comunicarea este facilitată de echipe interdisciplinare.

În proiectele investigate acest lucru a avut loc cea mai mare parte pentru interfeţele de utilizator care au fost dezvoltate cu un constructor de interfaţă grafică şi a sistemelor de informare dezvoltate cu un 4GS. În mai multe dintre proiectele investigate acest lucru a fost realizat prin împrumutarea unor dezvoltatori ai sistemului ţintă la procesul de prototipare pentru o perioadă limitată de timp. în cea mai mare parte. * da. de fezabilitate sau pentru a câştiga experienţă experimentală au fost recunoscute. este probabil să fie aruncat. tehnice sau metodologice. Ce se poate afirma este faptul că refolosirea are sens numai dacă părţile care urmează să fie refolosite sunt bune din punct de vedere tehnic. Lucrul cel mai important este de a asigura transferul de cunoştinţe între echipe. următoarele tendinţe au fost observate:  Beneficiile care rezultă din aplicarea prototipării la obţinerea informaţiilor despre dobânzii de pe piaţă. Unele organizaţii au recunoscut pericolul inerent unei astfel de abordări şi iau măsuri de precauţie. Reutilizarea de prototipuri pentru dezvoltarea unui sistem-ţintă poate fi recomandată numai în cazul în care tool-urile de dezvoltare produc prototipuri cu o arhitectură curată de sistem. dar cu planificare de transfer) Nu există nici o tendinţă clară de (părţi ale) prototipuri care urmează să fie refolosite pentru construirea sistemului-ţintă. Există o tendinţă puternică pentru o echipă să suporte întregul ciclu de dezvoltare. Din cauza lipsei de cunoştinţe multe organizaţii se ocupă încă cu echipe diferite pentru realizarea de prototipuri şi dezvoltarea sistemelor-ţintă. cât mai avantajos posibil şi.echipe separate - + * (+) - - * - - Tabelul 4.   38 . Cel puţin această problemă este recunoscută în multe companii. Unele dintre proiectele investigate nu au avut nici măcar un sistem-ţintă ca obiectiv major. Acest lucru duce frecvent la o separare între echipa care realizează prototiparea şi echipa care crează şi întreţine sistemul-ţintă. (-) improbabilă. Motivul pentru aceasta este. Nu multe echipe în marile companii tradiționale sunt în măsură să aplice prototipuri. În rezumat. deoarece dezvoltatorii nu dispun de competenţe necesare. Acest lucru poate duce la diverse probleme. Un astfel de prototip este implementat cât mai repede şi simplu.Multe prototipuri de prezentare sunt planificate să fie abandonate tocmai din acest motiv. (+) probabilă. Este important să se explice către utilizatorii finali şi către managementul lor încă de la început faptul că un prototip de prezentare ilustrează o singură viziune.5 Relaţia dintre prototip şi sistemul-ţintăt (+ explicită. strategic. în cazul în care acestea totuşi trebuie să separe echipele. prin urmare.

Consecinţa acestei constatări este că interfeţele utilizator nu ar trebui să fie derivate sau generate din kernel. Un alt aspect observat este că proiectele trebuie să fie conştiente de dihotomia sau chiar contradicţia. la nivel operativ. Singura excepţie a fost HyperCard care a fost folosit mai ales pentru punerea în aplicare a prototipurilor-schiţă. prototiparea a fost parte a unei strategii intenţionat evolutivă. există proiecte în care clienţii fac o selecţie nejustificată.9 Analiza punerii în aplicare a tool-urilor În general.4. În plus. Această abordare conştientă către prototipuri pare a fi cheia pentru procentul mare de proiecte de succes în acest studiu. În plus. există o reticenţă bine-cunoscută de a folosi tool-uri noi. Este aproape imposibil de a dezvolta software de lungă durată şi flexibil pornind de la interfaţa cu utilizatorul. În toate aceste proiecte.10 Concluzii Prototiparea este folosită în prezent mai conştient decât în ultimii ani. În cele din urmă. deoarece acele părţi de sistem care nu sunt legate de interfaţa cu utilizatorul. pentru diferite tipuri de cercetare de marketing şi studii de teren. Acest lucru este susţinut de o tendinţă actuală din domeniul tool-urilor: tot mai multe medii integrate de dezvoltare (nu instrumente CASE!) sprijină construirea atât a interfeţei cu utilizatorul cât şi a nucleului unei cereri. Multe proiecte s-au folosit de tool-uri sub nivelul optim la care se puteau folosi. Această sursă de inovare poate fi exploatat nu numai pentru proiecte software individuale. de asemenea. vor duce lipsă de substanţă. cum ar fi modelul de date. se pare că există o lipsă de cunoştinţe despre piaţa de tool-uri. cititorul ar trebui să reţină că nici unul dintre proiectele studiate nu a urmat un ciclu de viață tradițional sau o abordare în cascadă. 39 . pentru că această abordare ignoră potenţialul unei interfeţe inovatoare sau problemele importante de utilizare şi manipulare adecvată. Motivele variază: în primul rând. ci. 4. între arhitecturile şi sistemele software care au fost dezvoltate "surface down". crearea de prototipuri a fost bine planificată şi nu au fost luate ca o scuză pentru trimiterea unor sisteme semi-dezvoltate către clienţi. O tendinţă nouă în curs de dezvoltare este de a folosi prototiparea ca un vehicul pentru elaborarea şi demonstrarea viziunilor inovatoare de sistem. Ca o ilustrare. tool-urile au fost utilizate conform scopului lor stabilit de către dezvoltatori. dar obligatorie de tool-uri de dezvoltare. Dar evident trebuie să ne ferim de iluzia că tool-urile sunt bagheta magică pentru fiecare problemă de inginerie software. Nucleele domeniului specific şi piesele interactive de interfaţa ar trebui să fie dezvoltate complementar. Ele sunt utile numai în cazul în care sunt angajate într-un cadru metodologic sensibil. ca parte a unui contract.

acest instrument oferă și posibilitatea de a arăta clientului/utilizatorului modul în care poate fi utilizat software-ul ce se află în curs de proiectare. Figura 5. ambele utile pentru procesul de dezvoltare.html 40 . Având funcționalitate minimă poate fi folosit în procesul de proiectare centrată pe utilizator.1 Structura interfeței grafice a aplicației 7 8 http://code. Pe lângă schițarea de GUI a unei aplicații.8(pentru crearea interfeței grafice) Medii de proiectare: Altova UModel Biblioteci adiționale: Mac-Widgets7.com/p/macwidgets/ http://java-sl.6. dar și ca instument de creare de ecrane mock-up și diagrame de afinitate. JConnector8 5. Putem spune că acesta poate fi folosit și în proiectarea UX.google.5 Descrierea aplicației 5.2(pentru implementarea funcționalității) și Netbeans IDE 6. Aceasta permite atât schițarea de ecrane cât și vizualizarea lor. descrisă în capitolele anterioare.com/connector. În construcția acestei aplicații s-au folosit următoarele:     Limbajul de programare Java Medii de programare: Eclipse Helios Classic 3.2 Structura interfeței grafice La lansarea aplicației se va deschide o fereastră de dimensiuni maxime suportate.1 Date generale Aplicația realizată reprezintă un instrument software care crează prototipuri de interfețe utilizator.

fără nici o componentă. Bară de instrumente  Formată din mai multe butoane cu anumite funcționalități de bază. cu un conținut gol.  Se află în partea de sus.  Fiecare filă este formată din două componente:  Componenta din partea superioară conține titlul filei (la adăugarea unei noi file va aparea titlul ―* New File‖. în secțiunea de lucru.  Componenta din partea inferioară este defapt container-ul de componente.Această fereastră conține: 1. pe care se pot adăuga sau elimina componente. Acest fișier conține defapt un obiect serializat care va fi încărcat în aplicație și poziționat într-un nou tab. 5. Apare ca un panou grilă. în partea stângă aflându-se panoul cu componentele acceptate de acest container. sub bara de titlu a ferestrei 2. 41 . Un panou de componente disponibile  Format dintr-o listă de componente ierarhizate după tip (Swing containers. Utilizatorul trebuie să specifice calea către fișier și numele acestuia într-un mod interactiv cu ajutorul unui file chooser.3 Funcționalități Fiind o aplicație de sine stătătoare conține funcționalități de bază ca orice alt software. la adăugarea unei file prin operația de Open File va primi titlul fișierului care a fost deschis. Swing Controls.  Se află în partea stângă a ferestrei. sub bara de instrumente 4.  Filele se pot adăuga prin funcționalitatea de New File și se pot elimina prin accesarea butonului ―X‖ din componenta superioară a filei selectate. Zonă de editare  Formată dintr-un panou cu file. caracterul ―*‖ denotă faptul că starea părții inferioare a filei. Swing Menus.  New File – crează un nou tab. 3.  Open file – deschide un fișier aflat pe disc ce a fost creat anterior. dar conține și funcționalități speciale.  Fiind nucleul aplicației ocupă cea mai mare suprafață a ferestrei și se află în partea centrală. Mac Controls. Componente cu informații adiționale  Reprezentate de două componente (X. Mac Containers. a container-ului de componente nu a fost salvată) și un buton ce are asociat ca și acțiune eliminarea filei respective. Notes)  Componentele se adaugă în container-ul filelor din zona de editare prin operațiunea de Drag and Drop.Y) ce arată coordonatele cursorului când se află pe suprafața panoului grilă din interiorul filei selectate.

 Save – salvează într-un fișier conținutul din tab-ul ce este selectat, prin serializare. Utilizatorul are opțiunea de a alege calea și numele fișierului. Dacă fișierul este deja salvat această acțiune nu se va mai declanșa. Pentru a salva un fișier deja salvat trebuie folosită acțiunea de Save As.  Save As – este similar cu acțiunea Save doar că poate fi declanșat chiar dacă obiectul este deja salvat într-un fișier și permite re-salvarea acestuia într-un alt fișier cu nume diferit. Pe lângă funcționalitățile de bază descrise mai sus această aplicație vine cu funcționalități speciale globale dar și cu funcționalități ale componentelor din panoul de componente disponibile.  Adăugarea de componente – prin operațiunea de DnD se preia componenta dorită din panoul de componente și se plasează pe container-ul grilă al filei selectate.  Export as image – salvează container-ul de componente împreună cu componentele conținute ca fișier imagine cu extensia .png. Utilizatorului ii este permis să dea calea și numele fișierului.  Preview – permite vizualizarea ecranelor create în containerul de componente. Vor apărea doar componentele de tip container (Swing Container sau Mac Container) care au cel puțin un control legat de ele (bounded). Dacă există conexiune de la un control legat de un container ce permite o acțiune(de obicei buton) la un alt container, va aparea prima dată containerul ce are legat de el controlul cu acțiunea iar la declanșarea acțiunii acestui control va apărea containerul care a primit conexiunea respectivă. Dacă nu există conexiuni de acest gen, vor apărea toate containerele ce conțin controale legate de ele în același timp. Fiecare componentă disponibilă pentru adăugare permite anumite operații în funcție de tipul ei. În continuare vor fi prezentate operațiile speciale ce pot fi realizate asupra componentelor.  Selectarea unei componente – se realizează cu ajutorul unui click asupra componentei ce se dorește a fi selectată. În urma selecției va apărea un chenar de culoare albastră cu 8 controale de formă pătratică în jurul componentei.  Deselectarea unei componente – se realizează cu ajutorul unui click pe spațiul neocupat al panoului grilă.  Modificarea poziției și redimensionarea unei componente – se realizează asupra unei componente selectate. În urma plasării cursorului deasupra chenarului, cursorul își va schimba forma în funcție de poziția sa asupra chenarului. Dacă cursorul va fi asupra unui control al chenarului, componenta poate fi redimensionată prin operația de mouse-down și drag. În schimb, dacă cursorul nu va fi asupra unui control al chenarului dar totuși se va afla asupra acestuia, componenta poate fi mișcată, repoziționată tot prin operația mouse-

42

down și drag. În momentul operației mouse-release, componenta va primi noi margini(va avea altă dimensiune), respectiv noi coordonate. Eliminarea unei componente – se realizează prin selectarea unei componente, declanșând cu ajutorul unui click-dreapta un meniu.Pentru a elimina componenta se alege opțiunea Remove. Dacă există conexiuni de la ea sau spre ea, acestea vor fi deasemenea eliminate. Aranjarea pe un anumit strat a unei componente – se realizează alegând din meniul componentei opțiunea Move to back. În cazul în care există mai multe componente ce se suprapun și se dorește ca una din ele să apară deasupra alteia, se utilizează această opțiune care trimite componenta pe ultimul strat, lăsând celelalte componente deasupra ei. Este folosită de obicei când avem de a face cu un container și un control care dorim să îl legăm de acesta sau doar pur și simplu să amplasăm controlul deasupra container-ului. Modificarea caracteristicilor unei componente – se realizează selectând opțiunea Properties din meniul componentei. La această acțiune va apărea o fereastră de dialog de dimensiuni mai reduse care poate avea mai multe file. Există componente care au proprietăți comune și toate acestea vor avea o filă identică ca și layout, dar diferită în funcție de proprietățile actuale ale fiecărei componente(ex. JButton, JTextfield, JTextarea, JRadioButton – toate acestea au în comun un text asociat controlului, astfel ele vor avea fila comună de TextProperties de unde vor putea modifica textul, culoarea, fontul, dimensiunea fontului,etc). Conectarea a două componente – se realizează alegând din meniul componentei selectate opțiunea Connect. La alegerea acestei opțiuni toate componentele, în afară de componenta care a declanșat acțiunea, vor putea primi conexiuni. Dacă se poziționează cursorul deasupra acestor componente, în jurul lor vor apărea un chenar verde. Acest lucru denotă faptul ca ele sunt pregătite să primească conexiuni. Acționând cu un click pe componenta cu care se dorește a fi legată componenta selectată se va crea o conexiune între ele. Eliminarea unei conexiuni de la o componentă – se realizează la alegerea opțiunii Remove connection din meniul componentei selectate. În momentul alegerii acestei opțiuni, în jurul componentelor către care există conexiune va apărea un chenar roșu la poziționarea cursorului deasupra lor. Astfel ele sunt pregătite pentru a elimina conexiunea dintre componenta sursă(cea selectată) și ele(componentele destinație). Dând click conexiunea va fi eliminată. Eliminarea tuturor conexiunilor de la o componentă – se realizează la alegerea opțiunii Remove All Connections din meniul componentei selectate. La alegerea acestei opțiuni vor fi eliminate toate conexinile care pleacă din componenta selectată. Conectarea sau eliminarea de conexiuni poate fi întreruptă cu ajutorul unui clik pe spațiul neocupat al container-ului grilă. Legarea unei componente-control de o componentă-container – se realizeză în momentul alegerii opțiunii Bind To Container din meniul componentei 43

selectate. Această opțiune este activă doar dacă marginile componente-control selectate sunt conținute în întregime în marginile componentei-container. Dacă componenta-control este legată de un container iar containerul sau chiar componenta-control își modifică poziția, legarea va fi anulată. Acest lucru se întâmpla și dacă componenta-control își modifică dimensiunea astfel încât să nu mai fie conținută în totalitate de container. Componentele-container nu au în meniul lor această opțiune.  Dezlegarea unei componente-control de o componentă-container – poate fi realizată selectând opțiunea Remove binding din meniul componentei-control selectate. Această opțiune este activă doar dacă componenta-control selectată este legată de o componentă-container. Componentele-container nu au în meniul lor această opțiune.

5.4 Concepte, arhitecturi și detalii de implementare
Arhitectura Model-View-Controller Tiparul MVC este o strategie intuitivă și larg acceptată în proiectarea interfețelor utilizator. Ceea ce face MVC-ul să fie așa atractiv este faptul că descrie modul natural de a concepe anumite lucruri. Această strategie face evident faptul de a împărți codul într-un graf de obiecte format din date(modelul), UI toolkit – widget-urile specifice ce randează output-ul(view) și un set de acțiuni ce oferă ca răspuns modificări ale modelului sau al view-ului(controller). Acestea sunt cele trei preocupări de bază care permit partiționarea codului în trei grupuri logice pentru o înțelegere mai bună și o mentenanță mai ușoară. Această idee este intuitivă pentru oricine care a creat o aplicație ce include interacțiune cu utilizatori. Swing (și AWT) a inițiat utilizarea MVC în Java. Surprinzător, Swing rămâne unul din cele mai complicate și contraintuitive framework-uri cu o îndrumare destul de puțină în privința a cum se realizeză lucrurile în mod corect. Cu toate acestea, Swing pune în aplicare MVC, pe plan intern, numit model-delegate, contopind view-ul și controller-ul în UI delegate. Programatorii au rareori de a face cu partea de view/controller când crează aplicații. În schimb ei lucrează cu ceva numit componentă. Componentele Swing de sine stătătoare nu sunt parte a triadei MVC, mai degrabă ele lucrează ca și mediatori între model, view și controller. Programarea aplicațiilor Swing se bazează de fapt pe crearea de modele și construirea de componente pentru a realiza layout-ul, pe comunicarea cu subcomponente și sincronizarea modelului și a view-ului. Componentele rezultate conțin de obicei un amestec de cod ce se ocupă cu sarcinile view-ului (de exemplu painting-ul componentelor și așezarea lor pe layout), sarcinile controller-ului (desfășurarea acțiunilor), și sarcinile modelului (ambalarea obiectelor de domeniu în modele particulare).

44

prin urmare și a prototipurilor UI. view-ului și controller-ului creând o structură a codului cât mai ușor de înțeles.2). fiecare necesitând o manipulare proprie.În timp ce componentele Swing separă look-and-feel-ul de logica aplicației. 45 . Figura 5. vizualizând diagrama de dependințe între pachetele esențiale se poate obseva foarte ușor faptul că în Swing. Widget-ul nu este altceva decât un element care afișează o informație ce poate fi schimbată de utilizator și oferă un singur punct de interacțiune pentru manipularea directă a acestei informații. Astfel. fiind componenta de bază a tuturor GUIurilor. componentele Swing iau pe rând rolul de view și sunt curățate de codul modelului și al controller-ului. Modelul poate fi considerat orice clasă Java. ele pierd MVC-ul pur la nivelul aplicației și sfârșesc prin a fi un amestec de cod ce efectuează sarcini ce nu au legătură unele cu altele. În dezvoltarea acestei aplicații s-a început de la această arhitectură. În proiectarea tradițională. View-ul include doar painting-ul și așezarea componentelor în layout. Problemele devin tot mai mari în aplicații complexe unde fiecare componentă poate conține zeci de subelemente. Cu toate acestea. Principalul concept al acestui instrument software este widget-ul. rapidă și plăcută metodă de creare de prototipuri. Cea mai bună soluție găsită a fost drag-anddrop-ul de widget-uri. Construcția aplicației a pornit de la anumite concepte. există clase care pot fi considerate atât model cât și controller. s-a căutat cea mai bună. În etapa de analiză a realizării acestui soft. Astfel. Controller-ul conține logica particulară a unei componente. am încercat separarea modelului.dependințe între pachete Aruncând o primă privire asupra dependințelor între pachete putem spune că modelul modifcă view-ul iar controller-ul și modelul sunt dependente una de cealaltă.2 Structura codului . există amestecul de cod descris mai sus (vezi Figura 5.

Având în vedere faptul că am dorit să avem un număr mare de componente. După cum se poate observa în Figura 5. în această operație de DnD singurul lucru utilizat va fi proprietatea name a clasei Widget. Desigur. new Widget(JButton.SwingButton (nume_clasa_componenta_swing = nume_clasa_componenta_UIPrototype) Astfel că.model.3 Clasa Widget Proprietetatea text va fi numele simplu al clasei componentei și va fi textul ce va apărea în cadrul nodului JTree-ului. 46 . O idee principală a acestui instrument software a fost posibilitatea de a avea o diversitate largă de widget-uri pentru crearea de prototipuri și deasemenea de a putea adăuga pe viitor noi componente.swing. Aceasta este utilizată în crearea panoului de componente disponibile. ce este adăugat ca și resursă la proiect.Pornind de la acest concept am creat o clasă Widget. Toate proprietățile acestei clase se construiesc în funcție de obiectul Class dat ca parametru în cadrul constructorului (ex. acest JTree devine destul de complex.swing.components. Acest panou este format de fapt dintr-un JTree. instanțierea clasei asociate realizîndu-se cu Java Reflection.3 clasa Widget implementează interfața Transferable necesară pentru operația de DnD. Din această cauză s-a încercat automatizarea adăugării de componente la acest JTree.JButton=prototype. Figura 5. și adăugat la JTree componenta raspectivă. Fiecare nod al JTree-ului folosit este de tip DefaultMutableTreeNode căruia i se asociază ca și user-object un obiect de tipul Widget. proprietatea name va fi numele complet al clasei și va fi folosit în momentul evenimentului de drop când se va căuta în fișierul properties. prin crearea unui fișier de tip properties care are structura: javax. descrisă mai jos. pentru adăugarea unei noi componente (clasa aferentă trebuie neapărat să existe în proiect) trebuie modificat acest fișier.class) ).

Să revenim un pic asupra evenimentului de drop. acest GridPanel trebuia neapărat să aibe layout-ul nul. Desigur acest canvas. Fiecare widget transferat se transformă întro-o instanță a clasei asociate în momentul drop-ului asupra panoului grilă. În momentul drop-ului mai au loc două evenimente: în cazul în care este salvat acesta va fi setat ca fiind nesalvat deoarece starea sa s-a modificat și deasemenea se va modifica și titlul filei corespunzător panoului. utilizat pentru funcționalitatea de deselectare a tuturor componentelor și interfața MouseMotionListener utilizat pentru a actualiza componentele cu informații adiționale cu coordonatele cursorului pe GridPanel. acesta extinde clasa JLayeredPane pentru a permite suprapunerea de compunente. Orice componentă control sau container ce pot fi disponibile trebuie să extindă această clasă pentru a fi funcționale. Acesta a fost creat prin suprascrierea metodei paint din superclasa sa. adăugându-se în fața titlului simbolul ―*‖.descris mai sus. ce denotă faptul că fișierul nu este salvat. Implementarea acestei clase a pornit de la 47 . descrise tot ca și funcționalități mai sus. Astfel pentru adăugarea unei noi componente disponibile pentru aplicație se necesită existența unei clase ce extinde SwingComponent. schițare pentru crearea de prototipuri care poate fi salvată ca și imagine de tip . Acest panou grilă este o instanță a clasei GridPanel. Conceptul de zonă de desenare a dus și la modificarea felului în care arată acest panou: grila. Astfel s-a ajuns la o zonă de editare. ce tip de obiect va fi amplasat pe panoul grilă (de ex. Desigur un alt avantaj al acestei grile este și faptul că în momentul exportului ca imagine.png prin funcționalitatea de Export to image descrisă mai sus. acțiune în urma căreia se va aduce în memorie starea obiectului salvat. Acest tip de salvare se face prin serializare iar în momentul în care se dorește încarcarea unei zone de acest fel salvate anterior se va accesa butonul de Open. Nucleul acestui proiect este clasa abstractă SwingComponent ce extinde clasa JComponent. Pentru a permite poziționarea componentei la coordonatele unde s-a pozitionat cursorul în momentul evenimentului de drop. existența unei imagini de tip .gif cu același nume ca cel al Widget-ului și adăugarea nodului cu widget-ul asociat. asemănător watermark-urilor. modificarea fișierul properties. Această clasă a fost creată pornind de la conceptul de canvas. este defapt tot ceea ce va fi salvat în momentul declanșării acțiunii de Save sau Save As. Pe lânga extinderea clasei JLayeredPane. imaginea creată să fie o informație securizată. Având în vedere faptul că acest canvas trebuia să fie un container pentru toate componentele de prototipare. și toate proprietățile sale. cu toate componentele ce se află pe el. De aici provine și funcționalitatea de Move to back descrisă anterior. Această imagine este salvată ca resursă în cadrul proiectului și are același nume ca și clasa dată în constructor. adică așezarea componentelor pe mai multe layere. aceasta implementează două interfețe MouseListener. prin intermediul deserializării. pentru JButton va fi creată o instanță a clasei SwingButton) iar proprietatea icon va fi imaginea care va apărea deasemenea în cadrul nodului din JTree.

Acesta este în mod obișnuit o componentă ascunsă. Figura 5.4). JFrame). Astfel s-a ajuns la construirea unui wrapper pentru componenta concretă. ce acoperă toată suprafața unei ferestre obișnuite (ex. fie ea container. Acest wrapper este defapt un JComponent cu un layout de tip BorderLayout la care de adaugă componenta concretă. Acest border poate fi setat să apară doar la margine sau mai în interior. Acest glasspane este un JPanel care se va instanția în momentul construirii oricărei componente ce extinde SwingComponent.două intenții. clasa SwingComponent devine abstractă iar părțile ce sunt diferite sunt apelate în cadrul acestei clase prin metode abstracte declarate tot în interiorul ei. concretă) de evenimentele obișnuite. Datorită faptului că toate componentele vor avea atât funcționalități comune cât și funcționalități diferite. Astfel s-a setat un inner border 48 . O altă intenție a fost de a crea o componentă care să dețină anumite funcționalități pe care în mod normal nu le are.4 Moștenirea clasei SwingComponent Componentele Swing au disponibil un border.5). Având în vedere că nu putem opri evenimentele obișnuite fără ca acestea să nu mai funcționeze și în momentul vizualizării runtime a lor (funcționalitatea Preview) sau să putem totuși să facem să răspundă la alte evenimente dorite am găsit o soluție care rezolvă toate aceste impedimente. fie ea control. De aici s-a ajuns la o metodă prin care se poate alege o funcționalitate dintr-un set de opțiuni și operații. S-a întâlnit nevoia de a avea o componentă care să nu raspundă la evenimentele la care răspunde o componentă obișnuită de Swing atunci cănd se află pe GridPanel. Acest glasspane va fi invizibil și va avea mărimea componentei pe care se află și deasemenea ea va ascunde componenta respectivă (actuală. De aici a venit ideea de a avea un glasspane pe suprafața oricărei componente. deschizând posibilitatea de a putea să adăugăm acțiuni doar pentru evenimentele dorite (vezi Figura 5. invizibilă. Pentru a putea avea un chenar în exterior a fost necesară o altă soluție. doar că sunt definite în interiorul claselor ce o extind (vezi Figura 5. Aici intervine conceptul de glasspane.

5 Structura componentelor Clasa SwingComponent conține două proprietăți de tip Border: noBorder și resizeBorder(vezi Figura 5. Pe lângă aceste operații se vor adăuga și o serie de listeneri pentru funcționalitățile de resize(modificarea mărimii și modificarea poziției). Clasa ResizeComponentListener se ocupă cu setarea chenarului de tip ResizeBorder care conține 8 pătrățele numite grips. Această distincție între obiecte este realizată prin intermediul unui identificator de tip UUID (Universal Unique IDentifier). La modificarea cursorului se poate trage (evenimentul de drag) iar componenta se va modifica în funcție de tipul cursorului. Clasa SelectComponentListener se ocupă de lansarea meniului popup asociat fiecărei componente. de exemplu un JButton.9). connect. În funcție de tipul lor.6).pentru acest wrapper și se crează efectul de border exterior componentei concrete. acestea vor avea atât funcționalități comune. Această componentă concretă este reprezentată de proprietatea containedComponent al clasei SwingComponent. În momentul instanțierii clasei SwingComponent se vor seta marginile glasspane-ului și componentei concrete iar mai apoi vor fi adăugate componentei wrapper. unele meniuri vor avea opțiuni dezactivate sau unele vor lipsi. Acestea descrie defapt două din stările oricărei componente. având în vedere că există componente control și componente container. fiecare având asociat un ActionListener de tip ItemAction (vezi Figura 5. Componenta “înveliș” pentru border (de tip JComponent) Componenta concretă Glasspane Figura 5.un JTextArea.9). Desigur. Astfel putem avea mai multe componente cu aceleași 49 . Componenta concretă este construită prin intermediul metodei abstracte getActualComponent() care returnează instanța componentei concrete. un JPanel. Acest meniu popup conține o serie de JMenuItem. componenta pregătită pentru resize și starea ei naturală. deasupra cărora cursorul se modifică în funcție de gripul respectiv. etc. la evenimentul de click-dreapta realizat asupra glasspane-ului. cât și funcționalități distincte. fără chenar. Fiecare componentă ce se poate afla pe GridPanel este distinctă. disconnect și select (vezi Figura 5.

Acțiunea butonului de Apply este descrisă în metoda abstractă applyProperties() din clasa SwingComponent. Fereastra de dialog PropertiesDialog mai conține și două butoane. acest container ce se va adăuga la filă are o serie de componente-control utilizate pentru a putea modifica proprietățile componentei cât mai ușor.caracteristici. astfel fereastra încărcându-se mai greu doar prima dată. Acțiunea de eliminare a unei componente se face pe baza identificatorul componentei selectate. Datorită faptului că există componente ce au o serie de proprietăți comune. Primul obiect reprezintă titlul unei file iar cel de-al doilea un container de tip JPanel pentru a-l adăuga filei. dar ele să fie distincte prin id-ul lor. și urmează a fi implementată de orice clasă ce o extinde pe aceasta. în funcție de câte perechi de acest gen există. am decis ca pentru ca aceste componente să avem acest JPanel situat ca membru în clasa SwingComponent. Cele diferite vor fi situate ca și membrii în clasele ce extind SwingComponent. iar celălalt de Apply. Figura 5. Această metodă returnează o listă de perechi de obiecte. la oricare altă deschidere. La selectarea acestei opțiuni de crează o instanță a clasei PropertiesDialog. 50 . Aceasta extinde JDialog și conține un panou de file. tipurile și controlul chenarelor O altă funcționalitate interesantă a componentelor este acțiunea de Properties. unul de Cancel. Desigur. ce modifică proprietățile inițiale cu cele setate în fereastra de proprietăți. Această problemă a fost rezolvată setând aceste panouri ca fiind statice. Astfel. Acesta este construit în funcție de ce returnează metoda getTabProperties() a instanței clasei SwingComponent asupra căreia s-a declanșat acțiunea. controalele vor fi doar actualizate cu proprietățile componentei. ce închide fereastra. atâtea file vor apărea în fereastra de proprietăți. Acest lucru duce la o încărcare de o durată destul de mare.6 Structura.

urmat de deserializarea sa. Astfel. elementul fiind același. Astfel. 51 . În cazul în care se modifcă un element. Aici intervine diferența dintre deep-copy și shallow-copy. Crearea unei copii deep a unui obiect a fost realizată cu ajutorul serializării obiectului. La fel și în cazul opțiunii Remove All Connections. iar mai apoi se va apela notifyAllConnectingStopped() ce va notifica faptul că procesul de conexiune s-a încheiat iar componentele au încetat să aștepte după conexiuni. În cazul shallow-copy de va copia doar structura colecției. utilizatorul poate accesa butonul de Cancel iar proprietățile modificate nu se vor aplica asupra componentei. în momentul alegerii opțiunii Connect se va apela metoda notifyAllConnectingStarted() ce va notifica toate componentele. se vor elimina toate conexiunile care o conțin. iar colecția rezultată și cea inițială vor avea același set de elemente. Pentru a crea o conexiune este nevoie de două componente. Cel mai bun exemplu de a diferenția aceste concepte este crearea unei copii a unei colecții. automat se va modifica și elementul din copia sa shallow. getTabProperties() și applyProperties(). De exemplu în momentul actualizării controalelor din fereastra de proprietăți. aici duplicându-se toată colecția.Un punct cheie a acestei funcționalități o face metoda getCopy() din clasa SwingComponent. Acesta va permite ca în momentul poziționării cursorului asupra unei componente ce asteaptă conexiuni. sursa și destinația. cât și ca destinație. atât ca sursă. Astfel se vor elimina toți listenerii asupra componentelor și se va aduga listenerul de conexiune. ConnectComponentListener. cu excepția faptului că se poate elimina doar conexiunea de în care componenta selectată este sursă. În cadrul aplicației s-a întâlnit necesitatea unei copii deep în mai multe cazuri. Dacă se modifică în interiorul ferestrei anumite proprietăți asupra componentei. la crearea clasei asociate vor trebui implementate cele trei metode descrise mai sus: getActualComponent(). Dacă se va da click pe această componentă. Aceasta se ocupă în principal cu returnarea unei copii ―deep‖ a componentei. aceasta să apară cu chenar roșu. În cazul în care de elimină o componentă. O altă funcționalitate interesantă a aplicației este crearea de conexiuni între componente. Pentru ca aplicația să considere că o componentă este de tip container trebuie suprascrisă metoda isContainer(). se va crea conexiunea. în afară de cea care a declanșat acțiunea. care elimină toate conexiunile ce pleacă din componenta selectată. că sunt pregătite pentru a primi conexiuni. în clasa DeepCopy. Am considerat această creare de conexiuni ca fiind un proces. Acest lucru nu se întâmplă și în cazul deep-copy. pentru a crea o nouă componentă disponibilă. Dacă am fi folosit shallow-copy acest lucru nu ar fi putut fi realizat. în pachetul de utilități. Similar se realizează și eliminarea unei conexiuni.

Prin urmare dacă avem un container la care legăm un buton. Aceasta este partea cea mai importantă a aplicației. structurate într-o listă. prin acțiunea de Preview. nu și asupra componentelor-container. Aceasta returnează inițial false. acest tool devine ceva mai mult decât un instrument de schițare de prototipuri. Un control se poate lega doar în momentul în care marginile sale se află în întregime în marginile unui container. și verifică dacă nu sunt destinații în colecția de conexiuni(caz în care vor apărea toate odată) . iar la accesarea butonului va apărea cealaltă. în modul Preview. lăsând utilizatorii să interacționeze cu un prototip 52 .Figura 5. După cum se poate observa și în Figura 5. care are cel puțin o componentă legată de el. O altă funcționalitate a aplicației o reprezintă opțiunea de Bind to container. Acest instrument va putea fi folosit atât în procesul UX. În dorința de a lansa în Preview o fereastră și accesând un buton să ne apară o altă fereastră. iar containerul sau chiar componenta-control își modifică poziția astfel încât marginile controlului să nu se mai afle în interiorul marginilor containerului. deoarece cu ajutorul ei. aceasta va fi dezlegată.7 Structura conexiunilor Toate conexiunile sunt de tipul SwingConnector și extind clasa JConnector din librăria importată cu același nume. De această creare a ferestrelor se ocupă clasa PreviewActionListener care ia toate containerele ce conțin componente-control legate de ele. la lansarea în Preview va avea loc efectul dorit. Dacă o componentă este legată de un container. Momentan aceasta poate fi efectuată doar asupra componentelor-control.7 Toate conexiunile fac parte din clasa GridPanel. din panoul grilă asociat filei selectate. creând o conexiune de la un buton spre un container care are cel puțin o componentă-control legată de ea. deasemenea schițată în același GridPanel am creat metoda canHaveActionListener() în clasa SwingComponent. Această funcționalitate a fost necesară pentru a putea vizualiza runtime containerele schițate. iar acest buton va avea o conexiune către un alt container. Asfel. În cazul în care sunt se verifică dacă conexiunea vine de la o componentă ce poate avea acțiune sau nu (dacă da. va apărea într-o fereastră. Pentru funcționalitatea dorită am suprascris-o în clasa SwingButton în care va returna true. nu va apărea odată cu restul). ce are legat cel puțin un control. Fiecare container schițat. va apărea prima dată fereastra cu butonul. în momentul declanșării butonului de Preview.

adăugarea de noi componente se face foarte ușor. care pot fi folosite atât pentru a crea notițe. Figura 5. despre schițele create. am adăugat la panoul de componente disponibile niște widget-uri cu look-and-feel de Mac. Având în vedere existența unui cod destul de flexibil. Pe lângă aceste funcționalițăți. cât și in proiectarea cu diagrame de afinitate.de sistem funcțional cât și la creare de diagrame de afinitate. utile mai departe pentru programatori. prin intermediul componentelor PostIt. cu ajutorul bibliotecii Mac-Widgets. Pentru a demonstra acest lucru.8 Clasa SwingComponent 53 . pe un GridPanel se pot adăuga și componente de tip PostIt.

9 Relațiile și dependențele clase SwingComponent 54 .Figura 5.

modelele create vor începe să se contureze și să se concretizeze tot mai mult. 55 . Prototipurile sunt create/modificate pe parcursul întregului proces de dezvoltare de aplicații software. Deși prototiparea este mai frecvent utilizată în scopul de a ajuta cu design-ul de inteacțiune inițial. prin crearea sa rapidă și eficientă chiar în timp ce utilizatorul așteaptă. Prin prototipare. creare experienței utilizator. după testarea bazată pe utilizator. Astfel. Desigur că prototiparea economisește timp și bani. Ideile devin pe deplin puse în aplicare iar fidelitatea prototipurilor devine din ce în ce mai crescută. proiectanții au avut posibilitatea de a primi răspunsuri de la utilizatori foarte rapid și într-o stare incipientă a dezvoltării de software. metodele prezentate pe parcursul aceste lucrări pot fi utilizate având un mare efect asupra procesului de proiectare centrate pe utilizator.6 Concluzii Pe parcursul acestei lucrări au fost prezentat elemente de natură teoretică legate de domeniul proiectării Experienței Utilizator și potențialele beneficii aduse de instrumentele software utilizate. S-au exemplificat o serie de concepte și procese utilizate în această proiectare. pe ipoteza că schimbările viitoare vor fi din ce în ce mai puțin semnificative. prototiparea poate fi utilizată pentru a rezolva problemele descoperite la produsul final. toate acestea avînd în centrul atenției utilizatorul. prin schițe pe hârtie și continuând cu wireframes și prototipuri interactive. Procesul UX plasează prototiparea în cea mai importantă etapă a sa. care reprezintă defapt bazele a ceea ce sunt interfețele utilizator. Cu cât prototiparea se apropie de încheiere. Mai departe departamentul de dezvoltare poate continua să lucreze direct pe rezultate. Specialiștii de prototipuri interactive exploatează la maxim capabilitățile instrumentelor de creare de prototipuri și se asociază cu proiectanții UX pentru a crea comportamentul elementului individual de ecran.

R. de pe http://manwithnoblog.com/: http://experiencedynamics. Preluat pe Mai 30.org/wiki/User_experience User-centered Design. Preluat pe Mai 29. (2011. Martie 11).experiencedynamics. A. (1992).org/wiki/User-centered_design Adamchik. Preluat de pe UXRevisions . (2011. Decembrie 1).7 Bibliografie The Importance of User Experience. (fără an). Preluat pe Junie 10. (2004.wikipedia. (1984). (1984). M. 2011. Mai 13). Survey on User Interface Programming. P. 56 . Approaches to Prototyping. (1992). 2011. Septembrie 21). K..uxrevisions.A. 2011.blogs. de pe en.wikipedia.com/2010/03/31/the-scienceof-ux-design/ Bischofberger W.Your Enterprise Java Comunity: http://www. de pe http://konigi.wikipedia. 2011. 2011.. de pe http://en. de pe http://www. G..com/ux-usability/userexperience-design-process/47/ User experience.com/news/1364562/Java-GUIDevelopment-Reintroducing-MVC B. (2006.R. 2011. Springer-Verlag. Martie 31). The Science of UX Design. Prototyping– An Approach to Evolutionary System Development. Preluat pe Mai 29. Springer-Verlag.com/site_search_usability/2006/09/the_importa nce_. Brazen. A Systematic Look at Prototyping. Proceedings of the SIGCHI´92.Professional User Experience Community: http://www.wikipedia.com/notebook/history-evolutionuser-experience-design Budde R. C.theserverside. de pe The Server Side . (2009.org: http://en.org: http://en. Mai 8). Preluat pe Mai 29. Preluat pe Aprilie 29. Prototyping-Oriented Software Development– Concepts and Tools. F. The History & Evolution of User Experience Design. Barber.html User Experience Design Process.com: http://manwithnoblog. G. (2010). (2010. Budde. Java GUI Development: Reintroducing MVC. Springer Verlag. R. K. T. Myers. K.

User Experience Design.userfocus. Februarie 8). (2005. de pe LukeW .uxrevisions. (1995). de pe BoxesAndArrows: http://www.akendi. D. 2011. P. Mai 21). CRC Press.ro/ce-inseamna-de-fapt-userexperience/ User Centered Design. (1996). (http://www. T. User Experience Curriculum Diagram.pdf Morville. de pe http://www. de pe Blog . Preluat de pe http://nform.userfocus. F.infragistics. 2011. IEEE Software.Infragistics Community: http://blogs.boxesandarrows.com/publications/semantics/000029. (2004).com/ff/entry. 2011.uk/articles/ux-design-model.html User Experience vs. Preluat pe Iunie 5. tools. User Experience Diagrams.php Maassen.theotherblog. Preluat pe Iunie 10.. 2011. de pe Semantic Studios: http://semanticstudios. UX Design .com/end-to-end-experience-design-process/akendi-usercentered design-process. User interface prototyping—concepts.com/view/ux-design-planning/ McMullin. and experience. 2011. 2011. e-Commerce Usability: Tools and Techniques to Perfect the On-line Experience (ed. (2002).com/pixel8/media/p/95683. Preluat pe Mai 30. C.uk: http://www. B.aspx Smith.com/). Februarie 24). (2009.Dirk Bäumer. Communicating User Experience Design. Rapid Prototyping: Lessons. R.theotherblog. The Experience Cycle model .ro: http://uxdesign.com/user-experience-design/user-experience-vs-userinteraction/16/#more-16 Wroblewski.Professional User Experience Community: http://www. 2011. Preluat pe Mai 29.Planning Not One-man Show . de pe UXRevisions . 1st edition). (2011. L. Ce inseamna de fapt User Experience? Preluat pe Mai 29. 2011. Preluat pe Mai 31. Preluat pe Iunie 1. (2004. (2008. Travis.asp?156 57 .Do we need more UX planning teams? Preluat pe Iunie 5.com/Articles/2005/02/24/phohevdpzh/ Travis. C. Preluat pe Iunie 10.akendi. Mai 05). de pe http://www. Septembrie 7). (2005. Februarie 25). ICSE '96 Proceedings of the 18th international conference on Software engineering.Ideation + Design: http://lukew. (fără an). User Interaction. de pe http://www. Iunie 21).co.S. J.com/files/experience_cycle.com: http://www. D. Gordon.The Elements of the User's Experience.php S. Shoemaker. History of User Experience. 2011. de pe http://uxdesign. W. H. J.co. (2009.

Sign up to vote on this title
UsefulNot useful