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
Abstract
Nowadays, GUI prototyping is not just a whim or an experimental technique, but a necessity in the process of designing the user interface of a software application. Observing the impact that the user interface has on end-users is the key in designing good and easy-to-use software, which is precisely the goal of any developer. 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, Infomation Architecture, Interaction Design. 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, and it helps to evaluate the quality of a solution at an early stage. Software Assistant for UI Prototype Design is a tool built specifically to facilitate the creation of semi-functional GUI prototypes. Furthermore, it offers a series of features for developers through the quick and efficient creation of mock-up screens.
Cuprins 1
Introducere ................................................................................................................ 1
2
User Experience ........................................................................................................ 3
3
4
2.1
Istoric ................................................................................................................. 3
2.2
UX pentru organizații mici și mari .................................................................... 4
2.3
Definirea conceptului ......................................................................................... 5
2.4
Știința și design-ul ............................................................................................. 6
2.5
Ciclul și modelul UX ......................................................................................... 8
2.6
Fațetele UX ...................................................................................................... 11
2.7
Experiența utilizatorului vs. Interacțiunea utilizatorului ................................. 20
2.8
Importanța UX ................................................................................................. 21
2.9
Viitorul uzabilității și UX ................................................................................ 22
Proiectarea centrată pe utilizator ............................................................................. 25 3.1
Definirea conceptului ....................................................................................... 25
3.2
Modele și abordări ........................................................................................... 26
3.3
Procesul proiectării experienței utilizator ........................................................ 26
3.4
Roluri în construirea de UI .............................................................................. 28
Prototiparea interfețelor utilizator ........................................................................... 30 4.1
Abordări ale prototipării interfeței cu utilizatorul ............................................ 31
4.2
Clasificarea prototipurilor interfeţei cu utilizatorul ......................................... 31
4.3
Clasificarea tool-urilor de prototipare a interfeţei cu utilizatorul .................... 32
4.4
Proiecte analizate ............................................................................................. 33
4.5
Analiza punerii în aplicare a prototipurilor ...................................................... 34
4.6
Obiective pentru construcția de prototipuri ..................................................... 35
4.7
Strategii de dezvoltare şi procesul de prototipare ............................................ 36
4.8
De la prototipuri la sistemul dorit .................................................................... 37
4.9
Analiza punerii în aplicare a tool-urilor ........................................................... 39
4.10 5
Concluzii ...................................................................................................... 39
Descrierea aplicației ................................................................................................ 40 5.1
Date generale ................................................................................................... 40
5.2
Structura interfeței grafice ............................................................................... 40
5.3
Funcționalități .................................................................................................. 41
5.4
Concepte, arhitecturi și detalii de implementare.............................................. 44
6
Concluzii ................................................................................................................. 55
7
Bibliografie.............................................................................................................. 56
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. Doar tehnologia nu poate câștiga accceptarea utilizatorilor și comercializarea ulterioară. Experiența utilizatorului(User Experience) și modul în care decurge experimentarea produsului final cu ajutorul utilizatorului este cheia acceptării produsului pe piață. Acesta este momentul în care interfața produsului intră în procesul de proiectare(design). În timp ce inginerii produsului se concentrează asupra tehnologiei, specialiștii în uzabilitate se concentrează asupra interfeței utilizator. 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. Aplicat în software-ul computațional, proiectarea, schițarea UI(User Interface Design) este cunoscută deasemenea și ca Human-Computer Interaction(HCI) . Deși oamenii asociază de multe ori termenul de Interface Design domeniului computațional, acesta se referă deasemenea și la produsele în care utilizatorul interacționează cu controale și afișaje. Avioane militare, vehicule, aeroporturi, echpamente audio, și periferice, sunt câteva din produsele care permit aplicabilitatea de User Interface Design. O proiectare UI oprimă necesită o abordare sistematică a procesului de proiectare a unui produs. Pentru a asigura performanța optimă a produsului este necesară o testare de utilizabilitate. 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. Doar după ce reparațiile au fost realizate se poate spune că un produs este considerat un produs cu o interfață utilizator optimă. Deşi pare evident faptul că proiectarea UI are cel mai mare impact în dezvoltarea pe piaţă(şi nu numai) a unui produs software, este de cel mai multe ori ignorat. O interfaţă utilitzator bună face diferenţa între acceptarea unui produs software pe piaţă si eşecul lui. În cazul în care utilizatorii găsesc software-ul mult prea încărcat, mult prea dificil de utilizat sau mult prea greu de înțeles, produsul poate fi excelent dar va fi sortit eșecului. Astfel, impactul interfeței utilzator asupra utilizatorului devine crucial iar scopul dezvoltatorilor produsului devine producerea de software profesional și ușor de utilizat. Obiectivul principal al acestei lucrări este de a prezenta un mod de schițare rapidă a interfețelor utilizator: prototiparea. Astfel, 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
2 User Experience User Experience(UX) mai este cunoscut și sub numele de User Experience Design. UX reprezintă, la baza sa, 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, practice și plăcute din punct de vedere vizual. Deși pare un mod evident de a adopta acest concept în proiectarea serviciilor și produselor, din punct de vedere istoric, proiectanții de odinioară nu gândeau astfel conceperea lor. De fapt, industria nu a ajuns la această abordare decât abia prin anii ’90.
2.1 Istoric Începuturile UX-ului este un subiect destul de contestabil. Unii designeri de UX consideră că originea disciplinei a apărut odată cu proiectarea centrată pe utilizator, prin anii 1980 în timp ce alții consideră că începutul a fost mult mai devreme. Astfel, 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. 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, atunci când viețile lor depindeau de rezultate exacte și fiabile, au atins într-un final limitări umane evidente. 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. Cu timpul, subiectul a trecut de la factorii umani la proiectarea centrată pe utilizator. 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. 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. Inițial cercetătorii sau axat pe hardware dar studiile au migrat la software, toata atenția îndreptându-se pe producerea de sisteme mult mai ușor de învățat, controlat și cu interfețe cât mai plăcute de utilizatori. Cu timpul calculatoarele s-au răspandit tot mai mult în locurile de muncă iar în anii ’80 - ’90 proiectarea centrată pe utilizator a luat o amploare și mai mare mai ales din punct de vedere al importanței. Cărți ca ―The Design of Everyday Things‖, de Don
3
Norman și ―Designing Web Usability‖, de Jakob Nielsen au întâlnit o audiența vastă. Ele au ajutat la explicarea principiilor proiectării centrate pe utilizator și la expunerea uzabilității. Chiar și cu deținerea unei popularități considerablile, noțiunea de UX pe care o știm astăzi nu era încă stabilită. Uzabilitatea pune accent pe faptul ca orice interfață utilizator trebuie să fie eficace, eficientă și satisfăcătoare pentru utilizator. Cu cât mai multe organizații au adoptat proiectarea centrată pe utilizator, cu atât mai multă atenție a început să se acorde detaliilor dincolo de uzabilitate. UX a început să includă și alte teme, mai străine, printre care discuții despre emoțiile utilizatorilor, 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, psihologilor, proiectanților și multor altora. În final, următoarele discipline reprezintă în momentul de față setul de profesioniști care alcătuiesc domeniul de User Experience: ingineri, psihologi, cercetători, proiectanți grafici și vizuali, testeri.
2.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. Acesta nu este neapărat un lucru adevărat. 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. Este mult mai important înțelegerea procesului decât acordarea de angajamente pentru fiecare rol. 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. 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.
Figura 2.1 T-shaped UX Professional
Figura 2.2 Multiple T-shaped Professionals
4
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, angajând un profesionist UX din modelul ―T-shaped Professional‖, ajută foarte mult la competența echipei. 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.1). Organizațiile care funcționează după modelul ―T-shaped‖ dar cu profesioniști multiplii, oferă o acoperire expertă în cât mai multe discipline posibile (vezi Figura 2.2). Desigur, întrebarea evidentă ce urmează se referă la rolurile minime necesare pentru scheletul unei echipe UX. Dr. Tobias Komischke (Director UX în cadrul Infragistics) sugerează să existe cel puțin o persoană pe post de analist, o persoană pentru modelare conceptuală și un designer (proiectant) vizual. 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. Aceste trei roluri pune totul într-o poziție de start foarte bună în legătură cu conceptele corecte și necesare. Mai departe echipa poate învăța noi discipline sau poate angaja noi membrii în echipă pentru a umple golurile.
2.3 Definirea conceptului Peste tot internet-ul găsim definiții mai mult sau mai puțin teoretice. Experiența utilizator se referă defapt la starea de emoție pe care o simte o persoană utilizând un anumit produs, sistem sau serviciu. UX scoate în evidență aspectele experiențiale, afective, semnificative și valoroase ale interacțiunii om-calculator, dar deasemenea include percepțiile unei persoane asupra utilității, ușurinței de utilizare și eficienței unui sistem. UX este un domeniu destul de subiectiv deaorece este despre sentimentele și gândurile unui individ despre un anumit sistem. UX este deasemenea un domeniu dinamic deoarece se modifică de-a lungul timpului odată cu schimbările circumstanțelor. 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, sistem sau serviciu‖. Altfel spus, UX reprezintă totalitatea aspectelor cu care vine în contact utilizatorul unui produs, și care îi pot influența comportamentul, percepția, acțiunile, simțurile în relația cu produsul respectiv. Ca și notițe adiționale ale definiției date de ISO, se menționează trei factori ce influențează UX-ul: sistemul, utilizatorul și contextul de utilizare. Nota 3 al standardului sugerează că abilitatea de utilizare se adresează aspectelor UX-ului, adică ―criteriul de uzabilitate poate fi folosit pentru a evalua aspectele experienței utilizator‖. Din păcate standardul nu oferă alte explicații pentru clarificarea relației dintre experiența utilizator 1
ISO FDIS 9241-210:2009. Ergonomics of human system interaction - Part 210: Human-centered design
5
și uzabilitate. În mod evident, cele două concepte se suprapun, 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. User Experience Design-ul(UXD), ca domeniu de sine stătător, de fapt nu există. UX este intersecția dintre multiple domenii, având utilizatorul ca obiect central. Pot fi implicate astfel cunoștiințe de arhitectura informației, marketing, interaction design, interface design, grafică, toate orientate spre a obține un produs ergonomic, util, ușor de utilizat și învățat, și nu în ultimul rând estetic. Scopul designer-ului de UX este de a oferi utilizatorilor, în interacțiunile lor cu un produs sau un serviciu, o experiență cât mai eficientă, plăcută și lipsită de probleme.
2.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ă. Având în vedere faptul că asupra lui se aplică metode științifice nu putem spune că este o artă. În știință suntem învățați încă din prima zi să punem semne de întrebare asupra tuturor lucrurilor. Aceste semne de întrebări ajută la gândirea creativă, bazată pe idei anterioare, la observație, la experimentare și deasemenea la documentare. Ș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.Orice ipoteză trebuie neapărat să aibe o dovadă. Și chiar și atunci, pentru ca teoria să poată fi absolvită va fi nevoie de dovezi colaborative. Teoria poate fi considerată ca fiind cel mai solid lucru, ultima declarație. Desigur că trebuie reținut că o teorie nu este ― batută în cuie‖ ci este deschisă spre a fi schimbată. Dacă există dovezi care sunt împotriva sa, aceasta trebuie pusă sub semn de întrebare. O teorie este doar într-o stare de așteptare, la fel ca o serie de reguli sau o explicație despre cum funcționează ceva până în momentul de față. Deseori o teorie nouă este construită pe baza unei teorii deja existente, dar nu tot timpul. Se poate întâmpla să fie necesară existența unui punct de vedere cu totul diferit. Cea mai importantă parte a științei este utilizarea metodelor științifice. Este vorba despre ciclul de luare a unei ipoteze, de testare a ei, de analiză a rezultatelor urmată de iterare (vezi Figura 2.3). Cheia metodei științifice esțe utilizarea de cercetare a inteligenței, a imaginației și a creativității; nu este ca și coacerea unei prăjituri, nu există o rețetă mai rapidă ce se poate urma. Într-un fel seamănă cu proiectarea UX. Putem astfel să comparăm cele două: metoda științifică și proiectarea UX (vezi Figura 2.4). După cum se poate observa sunt foarte similare. Singurul lucru ce lipsește este formarea ipotezei.
6
Figura 2.3 Proiectarea UX vs. Metoda Științifică Metoda Științifică
Proiectarea UX
•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
•Definirea problemei •Observarea și cercetarea •Dezvoltarea unui design •Testarea de către utilizator și prototiparea •Analiza și interpretarea rezultatelor •Documentarea •Implementarea
Figura 2.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, lucru valabil și pentru proiectarea UX. Aceste reguli sunt ca și teoremele fundamentale în știință. Cu to ate acestea design-ul are acel element creativ, acea scânteie inovativă, acel element de creare a unui ceva bazată pe experiențe anterioare și pe mediul înconjurător. Acel ceva trebuie desigur să fie cuantificat ca ceva inteligibil de către comunitatea noastră. Procesul pentru acea creativitate și ce semnifică aceasta poate fi întotdeauna supus unei dezbateri. Cu toate acestea cheia în acest context este faptul că proiectarea este un proces creativ nu unul analitic. Design-ul stimulează simțurile iar stimularea simțurilor este de obicei elementul cu care măsurăm creativitatea. Cu toate acestea și în știință putem regăsi același moment de inovație, momentul de gândire ―outside the box‖, momentul creativității, doar că nu este deseori aplicat pe ceva ce este în mod tradițional considerat ca fiind creativ. În design-ul UX se prototipează și se experimentează, se observă rezultatele, se iterează și se crează modificări asupra prototipurilor utilizând rezultatele testării și 7
proiectările anterioare cu scopul de a găsi un design mult mai bun. 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ă, în realitate, proiectarea UX este o știință. Și poate chiar și știința este doar design.
2.5 Ciclul și modelul UX Experiența utilizator nu este doar o simplă acțiune. Este un ciclu, interconectat, care încearcă să satisfacă speranțele, visele, nevoile și dorințele utilizatorilor. Comparând rezultatele generate de interacțiunea cu sistemul și așteptările utilizatorilor, acest ciclu ia o formă individuală. 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.5). Evaluare
Așteptări
Proximitate
Răspuns
Declanșator
Conștientizare
Acțiune
Conexiune
Figura 2.5 Ciclul UX
Declanșatorul. Unele circumstanțe declanșează o nevoie și o așteptare corespunzătoare de satisfacție. Așteptarea. Ce se așteaptă utilizatorul să facă, cum se așteaptă s-o facă și ce se așteaptă să rezulte la sfârșit? Proximitatea. Cât este de ―apropiat‖ utilizatorul de partea necesară a sistemului? Conștientizarea. A observat utilizatorul partea necesară a sistemului? Sau i-a fost distrasă atenția de altceva? Conexiunea. 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
Acțiunea. 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. Sistemul oferă un răspuns acțiunii utilizatorului. Este răspunsul cel așteptat? Satisface nevoia utilizatorului? Evaluarea. Utilizatorul compară răspunsul cu așteptările sale. Pe baza rezultatelor comparării celor două, utilizatorul își va ajusta așteptările. Dacă așteptările sunt gestionate bine și sunt îndeplinite consecvent, utilizatorul va continua ciclul până când nevoia inițială este îndeplinită. Dacă așteptările nu sunt îndeplinite, utilizatorul nu va mai continua să folosescă sitemul și va încerca alte posibile căi sau va abandona ținta pentru moment. 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, Interest, Desire, Action Noțiunea de ajustare ciclică a așteptărilor reflectă un concept din teoria jocurilor: utilitatea repetată și așteptată.
În Figura 2.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. În ciuda faptului că este o diagramă simplă, acoperă toate activitățile profesioniștilor de UX. Acest proces are patru etape principale.
Analiza oportunității.
Această etapă oferă contextul de afaceri a unui produs. Se începe prin identificarea părților interesate pentru dezvoltarea noului produs. Acest lucru include toate părțile ce au un interes în succesul sau eșecul produsului, ca de exemplu managementul, suportul tehnic și corpurile normative din industrie. Mai departe se identifică viziunea UX a produsului: viziunea despre cum va fi văzută utilizarea produsului, de exemplu, în 5 ani. Acest lucru oferă o proiectare-destinație care folosește la asigurarea progresului către țelurile design-ului. 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. Activități comune ale UX pe parcursul acestei etape includ: analiza părțlor interesate, analiza competiției, sondeje, accentuarea unor grupuri.
Construirea contextului de utilizare.
9
În această etapă, obiectivul principal este să se creeze o descriere detaliată a clienților, a mediul în care vor folosi acest produs și a sarcinilor care vor sa le realizeze cu acest produs. Se începe prin construirea profilelor utilizatorilor: un set de personas ce descriu țelurile si comportamentele ale grupurilor-cheie de utilizatori a produsului. Mai departe se crează profilele mediului: descrierea mediului social, tehnic și psihic în care va fi folosit produsul. În final, se vor identifica rutele roșii: o listă de sarcini critice de care au nevoie utilizatorii pentru a conduce produsul spre succes. Activitățile UX ce se utilizează de obicei în acestă etapă: ancheta contextuală, intervieverea utilizatorilor, analiza sarcinilor, jurnalele utilizatorilor, analiza incidentelor critice. Analiza oportunității
Crearea UX
Analiza Crearea Segmenta părților viziunii UX rea pieței interesate
Dezvoltarea de arhitectură informațională
Setarea indicatorilor de performanță
Construirea contextului de utilizare Construire Construire Identificare a profilului a profilului a de ―rute utilizatorul mediului roșii‖ ui
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.
Această etapă este iterativă. Procesul începe prin dezvoltarea indicatorilor cheie de performanță a produsului: măsurători cantitative bazate pe clientul-cheie și necesitățile afacerii, pe care echipa de management le utilizează pentru a determina dacă produsul este pregătit pentru a fi lansat. Mai departe se continuă cu dezvoltarea de arhitectură informațională: modelul conceptual al produsului, prezentarea funcționalităților produsului și interacțiunea cu caracteristicile sale. Mai departe se expun ecranele(proiectarea detaliată), începând cu schițe pe hârtie și continuând cu wireframes și prototipuri interactive. Ultima parte a etapei este evaluarea uzabilității prin supunerea potențialilor clienți să realizeze anumite sarcini realistice. Activitățile UX ce se utilizează de obicei în acestă etapă: setarea metricii uzabilității, sortare de carduri, prototipare pe hârtie sau electronică, wireframing, testarea uzabilității și revizuirea de către experți.
10
Urmărirea utilizării în viața de zi cu zi și îmbunătățirea continuă a produsului.
Citatul ―Acesta nu este sfârșitul. Nu este nici măcar începutul sfârșitului. Este sfârșitul începutului.‖2 descrie cel mai bine această ultimă etapă. În această fază se află de fapt cum este utilizat produsul în practică și se vor utiliza aceste statistici, perspective, în vederea următoarei lansări sau chiar a următorului design a unui produs viitor. Activitățile UX ce se utilizează de obicei în acestă etapă: evaluarea la distanță, logurile utilizării, analiza apelurilor de sprjin.
2.6 Fațetele UX Există o mare confuzie și neînțelegere ce înconjoară termenul de ―user experience―. Multitudinea de activități ce pot fi etichetate cu aceste două cuvinte încapsulează un spectru larg de oameni, competențe și situații. Dacă soliciți proiectare UX (UXD) la ce anume te aștepți să primești? Similar, dacă cineva îți oferă UXD pentru o aplicație, website sau intranet sau extranet, 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. Așadar alegem ca un punct de start utilizatorul.
Utilizatori / Clienți etc. ...
Consumatori
Parteneri / Colaboratori
Membrii
Investitori
Părți din comunitate
Producători / Creatori
Persoane de decizie Agenți
Figura 2.7 Rolurile user-ului 2
Winston Churchill
11
Persoana ca individualitate Fiecare persoana este caracterizată prin propria sa personalitate. Astfel, ea devine o individualitate. Fiecare persoană are în posesia sa un rol propriu, diferit. Uneori, un individ deține un singur rol, dar în principiu el va fii locțiitor pentru mai multe roluri ca: utilizator, consumator, client, investitor, producător, creator, participant, partener, parte a comunității, membru, și așa mai departe (vezi Figura 2.7). Rețea de așteptări, experiențe și cunoștiințe Fiecare utilizator are mai multe fațete și este mult mai complex decât își poate imagina. Astfel nu este foarte util doar să existe o discuție cu utilizatorul pentru a afla cerințele sale. Este necesar să se observe comportamentul său, să se asculte punctul lor de vedere și să se recunoască ce decizii iau. Prin observare trebuie să se evalueze și să se înțeleagă de ce, ce și cum. De ce și ce tip de elemente vizuale le plac utilizatorilor, ce preferă și/sau ce înțeleg aceștia? De ce și la ce tip de model mental, 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, trebuie acordată atenție la ce fac utilizatorii, nu doar la ce spun. Susținerile utilizatorilor despre ei îșiși sunt nefiabile, deoarece sunt speculațiile lor despre comportamente viitoare.‖3 . Acestea fiind spuse, nici o afirmație a utilizatorilor despre ei înșiși nu sunt obiective. Poate că circumstanțele nu sunt realiste sau nu sunt rezonabile pentru acea persoană. Sau poate că persoana nu este chiar în acea situație, sau poate că este influențată de alți factori (de exemplu încercarea de a face pe plac testerilor). Sau poate încearcă să facă testul să reușească mai mult decat încearcî să facă să îl pice, ceea ce ne spune mult mai multe.
Gestionarea contextului tehnic
Proiectarea experiențelor
Livrarea experiențelor
Gestionarea contextului de afaceri
Figura 2.8 Experiențe. Arii de experiențe: arii diferite ce afectează calitatea comunicării
3
Jakob Nielsen - Alertbox
12
Când cele trei perspective (a face, a spune, a crea) sunt explorate împreună, suntem în măsură să realizăm spectrul de experiență al utilizatorului/ clientului ―normal‖ pentru care lucrăm. Jesse James Garrett a spus: ―Experiența Utilizator nu este despre modul în care un produs funcționează pe interior. Experiența Utilizator este despre cum funcționează pe exterior, atunci când utilizatorul intră în contact cu produsul și cum lucrează cu el.‖4 Pesonal și individual Când vorbim despre experiențe, luăm în considerare individualul, incluzând evenimentele subiective simțite de persoana care se confruntă cu ceea ce ne dorim să utilizeze. 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. Dacă privim experiențele utilizatorilor ca un proces continuu, utilizatorul își aduce experiențele din trecut în interacțiunea din prezent și adaugă la acestea spertanțele și așteptările pentru viitor. Acest viitor ar putea fi: interacțiunea cu tranzacțiile bancare într-un mod sigur și securizat. Planificarea UXD ia opiniile utilizatorilor, 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. În cea mai mare parte a timpului, acești oameni și experiențele lor sunt necunoscute. Este necesară o apreciere a clientului: călătoriile lor, istoriile lor personale și experiențele lor.
viitor - experiențe viitoare așteptări
clientul în prezent
securitate
trecut - foste experiențe speranță cunoștiințe
abilități
simpatii / antipatii
psihologie
Figura 2.9 Cursul experienței: individul (utilizatorul / clientul) este întotdeauna în prezent - acționează în prezent. Aceștia sunt influențați de foste experiențe și așteptări curente.
4
J. J. Garrett – The Elements of User Experience
13
Ceea ce afectează experiența cu produsul și cu compania ce îl reprezintă se află în setul de experiențe al utilizatorului, în lumea virtuală, în lumea reală sau chiar în lucrurile mici (de exemplu: Cafeaua mea a fost rece în această dimineață). Astfel, este vorba despre aprecierea nevoilor, cerințelor, capabilităților și dorințelor utilizatorului nesatisfăcute într-un mod contextual. Este vorba de un pachet de experiențe ce include lucrurile pe care utilizatorul le-a văzut, lucrurile asupra cărora a acționat și lucrurile ce le-a simțit. Experiențele și așteptările utilizatorilor se întâlnesc în prezent. Ambele sunt combinate inseparabil, și fiecare acțiune ce o excutăm ia ambele părți în considerare. Când o persoană utilizează o aplicație, ea încearcă să înțeleagă ce se întâmplă defapt. El va încerca tot timpul să facă referință la experiențe trecute. Momentul este deasemenea strâns legat de așteptările din perspectiva sa personală. În acest punct al prezentului intervine ―fagurele‖ lui Peter Morville. Fiecare fațetă sau calitate din , în perspectiva lui Peter Morville reprezintă:
Util. Ca practicanți nu putem ―picta între liniile desenate de către manager‖. 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, abilități și soluții inovatoare. Utilizabil. Ușurința de utilizare rămâne vitală, și totuși metodele centrate pe interfață și perspectivele interacțiunii om-calculator nu adresează toate dimensiunile design-ului. Pe scurt, uzabilitatea este necesară dar nu suficientă. Dezirabil. Misiunea de găsire a celei mai eficiente metode trebuie temperată de o apreciere a puterii și valorii de imagine, identitate, brand și alte elemente de design emoțional.
Util Utilizabil
Dezirabil Valoros
Ușor de găsit
Accesibil Credibil
Figura 2.10 "Fagurele" UX
14
Ușor de găsit. Trebuie să ne străduim să proiectăm site-uri web navigabile și obiecte ușor de localizat, pentru ca utilizatorii să găsească ce au nevoie. Accesibil. Așa cum și clădirile au lifturi și rampe, așa și aplicațiile trebuie să fie accesibile persoanelor cu handicap (mai mult de 10% din populație). În zilele noastre acesta este un lucru bun și etic de realizat. Credibil. Trebuie să întelegem să proiectăm elemente ce influențează faptul că utilizatorii cred sau nu ceea ce le transmitem. Valoros. Aplicațiile trebuie să livreze o valoare sponsorilor noștrii. În cazul nonprofit, UX trebuie să avanseze misiunea. Pentru celelalte cazuri, trebuie să contribuie până la bază și să îmbunătățească satisfacția clienților. În prezent, 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, indiferent de dizabilitatea sa (fizică, psihologică, de învățare, etc.)? 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. Astfel este necesară o apreciere comună a ―călătoriei‖ clientului și istoriei sale personale: nu doar cu produsul sau cu produse similare, dar de asemenea și cu experiențe similare. 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. Dorința principală a noastră ca și proiectanți trebuie s-o reprezinte respectul, valorificarea și înțelegerea continuității experienței și așteptării pe care le dețin utilizatorii. Planificare UXD poate fi uneori un termen destul de ―alunecos‖ împreună cu mulți alți termeni care ―plutesc‖ în jurul lui: interaction design, information architecture, human coputer interaction, human factors engineering, utilitate, uzabilitate și user interface design. Oamenii ajung să se întrebe ―Care este diferența între toți acești termeni și care este acela de care am nevoie?‖. Dacă UXD-ul este menit să descrie satisfacția, bucuria sau succesul utilizatorului cu o aplicație, un produs sau un website, cu toate acestea există anumite chei esențiale care trebuie abordate. Aici intervine din nou ―fagurele‖ lui Peter Morville. Fiecare element menționat mai sus constituie o componentă importantă a UX. Fiecare din acestea își crează eficiența prin ofertele de design de la fiecare din următoarele elemente:
15
Utilitatea se bazează pe practicabilitatea și ușurința în utilizare. Acest lucru semnifică faptul că un produs este în măsură să ofere tipul de serviciu corect și exact cel așteptat de utilizator. Arhitectura informațională (information architecture) este responsabilă cu claritatea informațiilor și caracteristicilor, cu lipsa de confuzii și cu stabilirea unei curbe de învățare scurtă. Proiectarea unei interacțiuni este esențială pentru o experiență de succes și satisfăcătoare pe ansamblu. Astfel că proiectarea de interacțiune (interaction design) trebuie să răspundă la întrebări privind fluxul de lucru, logica, claritatea și simplicitatea informațiilor. Proiectarea vizuală este responsabilă de claritatea informațiilor și elementelor, de simplitatea instrumentelor și caracteristicilor acestora, de aspectul plăcut și interesant al interfeței și de look-and-feel-ul acesteia. Accesibilitatea este un termen obișnuit utilizat în descrierea ușurinței cu care utilizează oamenii anumite aplicații sau obiecte. Acest termen nu trebuie încurcat cu uzabilitatea care este utilizat în descrierea ușurinței de utilizare a unei aplicații, instrument sau obiect de către orice tip de utilizator. Un sens al accesibilității se referă strict la persoane cu dizabilități: fizice, psihologice, de învățare, și multe altele. Deși accesibilitatea nu este un element de sine stătător, este important de observat că accesibilitatea are un rol important în UX pentru a crește aria de experiență. Oamenii tind să graviteze în jurul unui lucru mai ușor de utilizat indiferent pentru ce/cine a fost conceput. Figura 2.11 descrie relația dintre elementele descrise mai sus. Practicabilitate
Uzabilitate
Design de Interacțiune
Design Vizual
Utilizator/Client
Accesibilitate
Utilitate
Figura 2.11 Elementele proiectării și planificării UX
16
Arhitectura Informațională
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. Orice proces de proiectare începe cu o viziune. Acest lucru se aplică în special în procesul UX. Cu toate acestea, o viziune nu este suficientă pentru a începe proiectarea. Cum am menționat mai sus, noi avem tot timpul diferite circumstanțe, diferite roluri și diferiți utilizatori. Prin urmare este critic să înțelegem exact cerințele și nevoile utilizatorilor finali – întreaga sa experiență și așteptările sale. Procesul UX se bazează pe cercetarea iterativă centrată pe utilizator pentru a putea înțelege utilizatorii și nevoile lor. Cel mai obișnuit eșec în procesele UX este transferarea perspectivei utilizatorilor în proiectarea interfeței utilizator. Cheia este de a defini interacțiunea înainte, fără a o proiecta. În primul rând, toată cercetarea (utilizatorului, a produsului și a mediului) trebuie organizată și compactată într-o compoziție de cercetare de utilizator. Acestea conduc la profilele utilizatorilor, la activitățile de lucru și la cerinţele utilizatorilor. Compoziția de cercetare de utilizatori conduce fluxul către cazurile de utilizare (use-case). 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. Cazurile de utilizare complete sunt mai apoi validate cu o populație de utilizatori cărora le este destinat produsul. Acesta este un punct de control pentru a vedea dacă viziunea este realizată iar valoarea sa este clară pentru utilizatori și pentru echipa proiectului. Următorul pas este de a proiecta interfața utilizator, generând direct din interacțiunea definită. O preocupare principală în cazul proiectării este de a nu rămâne blocați într-o singură soluție prea devreme. Pentru a menține proiectul la timp, acest pas ar trebui împărțit în două: într-un aspect structurat dur și un design exact și detaliat. Layout-ul dur permite experimentarea și evaluarea rapidă. Design-ul detaliat oferă proiectarea exactă și o pre-vizualizare a comportamentului aplicației finale ce specifică ce trebuie codat. Evaluările iterative a utilizatorilor la ambele etape sunt conectate pentru a fi foarte rapide și efective în îmbunătățirea GUI-ului, oferirea unui feedback asupra proiectării, în evaluările rapide și iterative, și desigur în evaluările uzabilității.
Figura 2.12 Design workflow – workcycle – workspiral
17
Ne întrebăm mereu și suntem întrebați: Care sunt livrabilele acestui proces? Livrabilele nu sunt pentru noi, planificatorii. Livrabilele sunt niște mijloace de comunicare cu mai multe persoane: manager-ul, persoana ce ia deciziile, clientul, designer-ul, dezvoltatorii front-end și back-end, etc. Câteodată se trece cu vederea peste acest lucru. 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.13). Un design bun nu este doar interfața, sau look-and-feel-ul, sau tehnologia, sau hardware-ul, sau modul în care funcționează. Este fiecare detaliu, ca și structura, etichetarea, bordura unui buton sau unei iconiţe. În final, putem spune că este suma dintre fiecare element în parte. Se poate spune că viziunea partajată a unei echipe are mult mai mult potențial decât cea a unei creativități individuale. Acesta este momentul în care creativitate întâlnește așteptările. Punctul de vedere asupra arhitecturii informaționale, asupra design-ului și procesul prin care se poate ajunge la un produs bine conceput, toate acestea vor fi schimbate de planificarea UXD. Există o distincție între UXD si planificarea UX. Design-ul este considerat de obicei în contextul artei și altor eforturi creative. 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, dar în principiu pe părțile vizuale și pe stările de spirit. Un designer trebuie să ia în considerare părțile estetic-funcționale și multe alte aspecte al aplicației sau a procesului. Partea de planificare oferă un cadru, sau mai bine spus un framework. Termenul de planificare descrie procedurile formale utilizate în astfel de eforturi, cum ar fi crearea de documente, diagrame, etc. pentru a discuta aspectele importante ce trebuie abordate, obiectivele ce trebuie îndeplinite și strategiile ce trebui urmate. Partea de planificare este responsabilă cu organizarea și structurarea pentru a sprijini utilitatea, ușurința de găsire și uzabilitatea. 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.
18
Figura 2.13 Planificarea UXD
19
Deseori întâlnim un plan de activități ca cel din Figura 2.14. Acesta nu funcționează pentru UXD și planificarea UX.
Figura 2.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, unul care se poate aplica dezvoltării de UXD și de planificare UX (vezi Figura 2.15).
Figura 2.15 Planul de activități al UX
Desigur, în centrul oricărei echipe și de asemenea în centrul procesului trebuie să se afle persoana dominantă – utilizatorul (vezi Figura 2.16).
Figura 2.16 Utilizatorul și interacțiunea cu elementele UX
2.7 Experiența utilizatorului vs. Interacțiunea utilizatorului Există o diferență între experiența utilizatorului și interacțiunea utilizatorului. Experiența utilizatorului cuprinde mult mai multe elemente decât interacțiunea utilizatorului. În unele definiții, experiența utilizatorului însumează întreaga experiență
20
a unui produs, unde interacțiunea este un element al acelui întreg process. Click-ul pe un link este interacțiunea utilizatorului, iar experiența utilizatorului include acea singură interacțiune. Aceasta îmreună cu multe alte interacțiuni ale utilizatorului și un număr de alți factori descriși complet însumează experiența utilizatorului. Experiența utilizatorului începe ―out of the box‖ în unele filosofii de design, iar experiența de utilizare a unui produs poate dura ani întregi, chiar decenii. 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ă, ceva complet străin şi nou pentru ei. Cutia este de fapt o primă interfață (este ușor de deschis? Pot să țină pasul?). Acest proces se desfășoară pe parcursul tuturor articolelor pe care le deschide, utilizarea efectivă a produsului, etc , toate aceste activități specifice, fiind interacțiuni cu produsul. Fiecare dintre aceste interacțiuni trebuie să fie testate și optimizate. Pentru a exemplifica o să folosim o alta analogie, unii oameni folosesc experiența într-un restaurant. Citirea meniul, comandarea desertului și achitarea facturii sunt toate aspecte separate ale întregii experiențe de a merge la un restaurant. Ș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ță. Neglijența de a nu întreba clientul dacă mai dorește un pahar de vin poate să aibă ca rezultat un client nemulțumit. O singură pată pe perete poate să reflecte asupra imaginii întregului restaurant. În mod similar, un buton deplasat sau pierderea link-ului dorit pot fi critice pentru experiența web a unui utilizator. Desigur trebuie să testăm interacțiunea utilizatorului și trebuie să ne asigurăm că acestea funcționează corect. 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 - o singură etapă sau o parte din experiența completă – distruge întreaga experiență a utilizatorului. Acest lucru se poate întampla pentru că interacțiunea este prea ciudată sau pur și simplu prost concepută - sau pentru că pur și simplu nu se potrivește cu restul de experiență a utilizatorului. Aici este momentul în care testarea experienței utilizatorului intră în joc. Chiar dacă testarea la acest nivel macro sau la o asemenea magnitudine ar putea părea prohibitivă, acesta este modul ideal de a crea o experiență a utilizatorului care va fi excelentă într-un mod unic și – în mod sigur- memorabilă din toate punctele de vedere.
2.8 Importanța UX Importanța experienței utilizator se află acum în fruntea tendințelor tehnologiilor și aplicațiilor. Utilizatoii nu numai că o așteaptă; ei au ajuns să o ceară iar întrepinderile
21
și afacerile se confruntă cu achiziția de un UX cât mai bun pentru software-ul lor. Factorul UX poate face sau distruge viabilitatea și farmecul oricărui software, fie el aplicație Web, mobile sau desktop (vezi Figura 2.17).
2.9 Viitorul uzabilității și UX UX și uzabilitatea vor continua să se dezvolte. Toate site-urile, aparatele și interfețele au un singur scop: sa fie utile pentru cei care interacționează cu ele. Fiind receptivi la nevoile utilizatorului asigurăm succesul produsului. Cu toate acestea, nu trebuie să pierdem din vedere impactul pe care îl are bucuria unei experiențe web asupra produsului.
Viitorul pentru gameri
Cheoptics360 este un produs al Vizoo care poate schimba viziunea asupra tehnologiei 3D pentru totdeauna. Aceasta este o documentație despre 5x5 m Cheoptics360 din showroomul Vizoo. Nu au fost folosite efecte specială pentru a edita acest film video.
Reactable
Reactable este un instrument colaborativ al muzicii electronice, cu o interfață tangibila multi-touch. Mai multi artiști controlează instrumentul simultan prin mutarea și rotirea obiectelor pe o suprafata luminoasa rotundă.
Multi-Touch
Dispozitivele bazate pe tehnologia Multi-Touch acceptă intrare de la degete multiple și de la mai multi utilizatori simultan, permițând gesturi complexe, inclusiv prinderea, stretching, rotirea și alunecarea obiectelor virtuale de-a lungului mesei. În timp ce senzorul touch este un lucru obișnuit pentru punctele unice de contact, senzorul multitouch permite unui utilizator să interacționeze cu sistemul cu mai mult de un deget deodata.
Microsoft Surface
Multi-Touch-ul este totodata și nucleul lui Mircosoft Surface, o masă interactivă care permite unui utilizator, sau mai multor utilizatori, să manipuleze conținutul digital prin utilizarea unor mișcări naturale, gesturi.
Photosynth
Photosynth creează spatii multidimensionale, cu zoom și caracteristici de navigare care depășesc toate asteptările.
BumpTop
BumpTop este o nouă interfață utilizator care transformă desktop`ul uzual într-un desktop 3D glorios. În acest univers condus de fizică, fișierele importante obțin în
22
Figura 2.17 Importanța UX
23
sfârșit importanța pe care o merită printr-un ciudat, și în același timp satisfăcător, sistem de redimensionare. 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. Platforma cea mai cunoscută și evidentă este platforma mobilă, dar există și alte dispozitive noi, de la televizoare conectate la console și tablete. Senzorii ne permit să proiectăm medii fizice care să răspundă la activitatea dorită. Pur și simplu, aria computațională este peste tot, și oriunde există un procesor, apare și nevoia de a proiecta pentru UX.
24
3 Proiectarea centrată pe utilizator 3.1 Definirea conceptului User-centered design(UCD) este o filisofie de proiectare și deasemenea un proces în care nevoile, cererile, dorințele și constrângerile utilizatorilor reprezintă nucleul atenției acordate la fiecare etapă a procesului de proiectare. 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, ci și să testeze validitatea ipotezei în ceea ce privește comportamentul utilizatorilor în teste din viața reală cu utilizatori concreți. 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. 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, necesităților sau cererilor utilizatorilor, în schimb celelalte forțează utilizatorii să își schimbe comportamentul pentru a se acomoda cu produsul. Procesul UCD implică utilizatorul pe tot parcursul procesului de crearea al produsului sau serviciului. UCD este un proces sitematic și repetabil, ce s-a dovedit a furniza, pe parcursul multor proiecte și in multe domenii industriale, uzabilitate mare (ISO 9241) și UX de succes pentru clienți și utilizatori finali. Standardul ISO 13407 (vezi Figura 3.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). 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, î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
1. planificarea procesului centrat pe om
Produs complet
2. specificarea contextului de utilizare
5. evaluarea design-ului în contrast cu necesitățile utilizatorului
3. specificarea utilizatorului și a necesităților organizaționale 4. producerea soluțiilor de proiectare
Figura 3.1 Priverea de ansamblu asupra modelului ISO 13 407
3.2 Modele și abordări UCD ajută proiectanții de software să atingă ținta produsului creat pentru utilizatori. Cerințele utilizatorilor sunt luate în considerare chiar de la început și sunt incluse în tot ciclul de producție a sotfware-ului. Aceste cerințte sunt notate și trecute prin metode de investigare ca: studii etnografice, anchete contextuale, testare de prototipuri, testare de uzabilitate și multe altele. Metode mult mai generale pot fi incluse: diagrame de afinitate, sortare de cărți, sesiuni de proiectare cu participanți. Modele ce urmează standardul ISO5:
Proiectarea cooperativă. Implică proiectanți și utilizatori la egalitate. Aceasta este o tradiție scandinavă și și-a început evoluția încă din 1970. Poriectarea participativă. Inspirate de Cooperative Design axându-se pe participarea utilizatorilor. Din 1990 exista o conferința bianuală denumită Participatory Design Conference. Proiectarea contextuală. În contextul actual ―proiectarea centrată pe client‖ ce include câteva din ideile proiectării participative.
3.3 Procesul proiectării experienței utilizator 1. Obținerea cerințelor
5
ISO 9241-210:2010. Ergonomics of human-system interaction -- Part 210: Human-centred design for interactive systems
26
Ca în orice alt proiect software, este important să cunoaștem și să concentram obiectivul dezvoltării. Trebuie să discutam cu părțile interesate și cu utilizatorii pentru a afla nevoile reale. Aceste nevoi ar trebui apoi reduse în termeni de caracteristici și exprimate în cazuri de utilizare (abstract) sau scenarii de utilizare (ilustrativ). Trebuie apoi prioritizate sarcinile după risc și importanță și să se lucreze iterativ. Toate acestea trebuie realizate de inginerul cerințelor. 2. 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. Această sarcină este de obicei a unui designer de interacțiune. Este util doar să se schițeze interfața utilizatorului pentru a prevenii discuțiile precoce despre detaliile de design. Există multe tehnici și instrumente pentru a face acest lucru. 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. Nu este nevoie de alte instrumente și infrastructură. Toata lumea își poate schița ideile pe hârtie. o Wireframes Sunt de obicei utilizate pentru a schița structura unei pagini Web. Se numesc Wireframes deoarece desenează doar conturul controalelor și imaginilor. Acest lucru poate fi realizat cu ajutorul instrumentelor: PowerPoint sau Visio. o Sketch Flow - Expression Blend 3 Sketch Flow este o caracterestică nouă folosită pentru a crea prototipuri interactive direct în WPF. Se poate utiliza stilul ―wiggly‖ care este integrat și care ii da prototipului un aer schițat. Prototipul poate fi rulat într-un player individual, care are un mecanism de feedback integrat. o Prototip Interactiv Cea mai costisitoare și reală abordare este de a crea un prototip (reutilizabil) interactiv care funcționează ca cel real, dar cu date fictive. 3. Implementarea de business logic și de interfață utilizator ―brută‖ 4. Integrarea proiectării vizuale 5. Testarea software Este recomandată testarea prototipului UI pe utilizatori reali. Acest lucru ajută la identificarea și soluționarea problemelor de proiectare devreme în procesul de dezvoltare. 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. Utilizatorul primește o sarcină pe care trebuie să o rezolve iar el 27
controlează prototipul prin atingerea lui pe hârtie. Liderul de testare apoi prezintă o nouă hârtie care arată starea prototipului după interacțiune. o Laboratorul de uzabilitate Pentru a face un laborator de uzabilitate, avem nevoie de un calculator cu un software de captură de ecran și un aparat de fotografiat. 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. Ei nu ar trebui să interacționeneze cu persoana care încearcă prototipul pentru a afla unde se blocheaza și de ce.
Figura 3.2 Procesul de proiectare centrată pe utilizator
3.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. Aceste abilități sunt descrise ca rolurile care pot fi distribuite între oamenii din echipa de dezvoltare.
Dezvoltatorul
Dezvoltatorul este responsabil cu implementarea funcționalității unei aplicatii. El creează modelul de date, implementează business logic și le leagă pe toate pentru o vizualizare simplă.
Designerul Grafic
Designerul graphic este responsabil cu creearea unui concept grafic și cu construirea unor obiecte grafice cum ar fi pictogramele, logo-urile, modelele 3D sau schemele de culori.
28
Designerul interacțiunii
Designerul de interacțiune este responsabil pentru conținutul și fluxul interfeței utilizator. El creează wireframe-uri sau schițe UI pentru a împărtăși ideile sale cu restul echipei sau cu clientul. 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. El ia obiectele de la designerul grafic și le integreaza în interfața brută a dezvoltatorului. 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.
29
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. Acceptarea unui astfel de sistem depinde în mare măsură de calitatea interfeței cu utilizatorul a acestuia. 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. Î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. 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. Nici un proiect nu a mai aplicat o abordare tradițională pe baza ciclurilor de viaţă, lucru care este unul dintre motivele pentru care cele mai multe dintre ele au avut succes. Prototipurile sunt tot mai folosite ca o mașină de elaborare şi demonstrare a viziunilor de sisteme inovatoare.‖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. Este foarte potrivită pentru acumularea de experienţă în aplicații noi şi pentru a sprijini dezvoltarea de software elementară sau evolutivă. Multe rapoarte de experienţă privind realizarea de prototipuri au fost publicate. Ele ilustrează impactul prototipării atât în construirea cât și în restul procesului de dezvoltare software. Recent, Gordon şi Bieman au inventariat şi prezentat un sondaj al rapoartelor de experiență publicate şi nepublicate. Ei au identificat trei tipuri de rapoarte de experienţă: comercial, academic şi militar. Rapoartele au fost analizate din punct de vedere al procesului și al produsului, 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. Pe parcursul ultimilor ani dezvoltarea sistemelor software cu interfață grafică extrem de interactive a devenit tot mai comună. Acceptarea unor astfel de sisteme depinde în mare măsură de calitatea interfeței lor cu utilizatorul. 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. 6
publicat în Proas. din 18 International Conferinţa privind Software Engineering (ICSE) Berlin, douăzeci şi cinci au 30 martie 1996
30
Acesta este motivul pentru care prototiparea interfeței cu utilizatorul este aplicată într-un număr tot mai mare de proiecte. Î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. O scurtă trecere în revistă a proiectelor investigate este urmată de o analiză a aplicării abordărilor prin prototipare şi a tool-urilor.
4.1 Abordări ale prototipării interfeței cu utilizatorul Pentru clasificarea abordării prototipării, în Europa este larg acceptat şi utilizat modelul Floyd trei "E". Există diferenţe în interpretarea "E"-urilor: explorator, experimental şi evolutiv. 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. În cele ce urmează vom discuta doar abordarea de proces.
Prototiparea exploratorie are rolul de a clarifica cerinţele şi potenţialele soluţii.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. Rezultatele sunt de obicei, prototipări de prezentare şi prototipări funcţionale. Prototiparea experimentală se axează pe realizarea tehnică a cerinţelor selectate.Aceasta duce la experienţa cu privire la oportunitatea şi fezabilitatea unui anume design/implementare. Rezultatele sunt, de obicei, prototipuri funcţionale şi breadboards. Prototiparea evolutivă este un proces continuu de adaptare a unui sistemaplicaţie la constrângeri organizaţionale care se schimbă rapid. Acesta nu este folosit în cadrul unui singur proiect. Deşi în procesul de prototipare evolutivă se pot construi tot felul de prototipuri, construirea de sisteme-pilot este de o importanţă deosebită.
4.2 Clasificarea prototipurilor interfeţei cu utilizatorul Pe langă clasificarea diferitelor abordări de prototipuri este, de asemenea, important să se clasifice diferitele tipuri de prototipuri care pot fi construite.
Prototipuri de prezentare sunt construite pentru a ilustra modul în care o aplicaţie poate rezolva cerinţele date. Deoarece ele sunt adesea folosite ca parte a propunerii de proiect, acestea sunt puternic axate pe interfaţa cu utilizatorul. 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.
31
Breadboards servesc pentru a investiga aspectele tehnice, cum ar fi arhitectura de sistem sau funcționalitatea unei aplicaţii planificate.Acestea sunt construite pentru a investiga anumite aspecte de risc deosebit. Ele nu sunt destinate pentru a fi evaluate de către utilizatorii finali. Sisteme-pilot sunt prototipuri foarte mature, care pot fi aplicate practică.
Î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. Prototipurile interfeţei cu utilizatorul variază de la prototipuri de prezentare schiţă la sistemele-pilot deplin funcţionale.
4.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. Pentru a oferi o terminologie bine definită, vom defini pe scurt aceste categorii.
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, teancuri de cărţi, linkuri, script-uri de manipulare a evenimentelor. Combinaţia de link-uri şi script-uri face HyperCard un puternic tool de prototipare. 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. Succesul lui HyperCard a dus la dezvoltarea de clone pe diverse platforme. Din acest motiv, mai departe vorbim despre tool-uri asemenea HyperCard-ului.
Constructori de interfaţă
Acestea sunt tool-uri care servesc pentru a defini interfeţele utilizator la un nivel ridicat de abstractizare, fie textual sau cu un editor grafic. Ele susţin crearea şi dispunerea elementelor de interfaţă cu utilizatorul. Doar constructorii de interfaţă cu editor grafic sunt de interes pentru prototipare.
Sisteme din generaţia a patra
Un sistem de generaţia a IV-a (4GS) este un mediu de dezvoltare complet pentru sistemele informatice. 4GS prevăd, de obicei, tool-uri pentru proiectarea grafică a modelelor de date şi interfeţelor de utilizator, un sistem integrat de interpretare a limbaj de scripting şi diverse alte tool-uri, cum ar fi generatoare de raport, editoare de program şi depanatoare. Acestea sunt ideale pentru realizarea de prototipuri de sisteme informatice, deoarece cu ele se pot construi foarte rapid prototipuri complet funcţionale.
32
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, precum şi implementări concrete a funcţionalităţii, lucru obişnuit la asemenea aplicaţii. Framework-urile orientate pe obiect fac posibilă dezvoltarea interfețelor utilizator bazate pe manipularea complexă directă într-un timp scurt. Ele sunt potrivite pentru realizarea de prototipuri de interfeţe care nu pot fi compuse din componente standard. Un asemenea framework oferă nu numai componentele interfeţei, ci şi arhitectura întregului sistem. 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.
4.4 Proiecte analizate În această secţiune vom face o scurtă prezentare a proiectelor analizate, în cadrul a două tabele. Tabelul 4.1 prezintă pentru fiecare proiect un acronim şi o scurtă descriere. Tabelul 2 arată ce fel de prototipuri au fost construite, ce abordări au fost aplicate şi cu ce fel de tool-uri. Numele proiectului Descriere Customer Advice System (CAS)
Un furnizor de software bancar dezvoltă un nou sistem de consiliere a clientului. Obiectivul major este de a obține o interfaţă care facilitează unui consilier de clienţi accesul la sarcini complexe.
Ticket Vending Machine (TVM)
Un furnizor de transport public intenţionează să introducă o nouă generaţie de distribuitoare automate de bilete. Aceasta solicită mai multor companii să liciteze pentru contract. Datorită importanţei calităţii interfaţei cu utilizatorul ca parte a licitării trebuie prezentat şi un prototip al interfeţei.
O firmă de dezvoltare software intenţionează să adapteze unelte de dezvoltare UNIX GUI pentru Debugger standard platformei sale. Aceasta include dezvoltarea unei interfeţe grafice de utilizator (GD) pentru o linie de comandă de depanare. 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. Un astfel de sistem trebuie să furnizeze un client cu text scris şi vorbit, imagini bi- şi tridimensionale, precum şi filme despre produsele actuale.
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. Departamentul de inginerie software-ul al unei universităţi primeşte un System (PCT) contract pentru a dezvolta un astfel de 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. O primă aplicţie este construită pentru sprijinul reprezentanţilor de cont.
33
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. Principalul domeniu de interes este dacă actualii clienţi sunt dispuşi să utilizeze un tool interactiv pentru definirea fluxurilor mesaj.
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). O componentă a Technical Systems acestui sistem este o aplicație pentru specificarea interactivă, simularea şi analiza (FET) sistemelor mecatronice. Departamentul de cercetare al unei bănci mari dezvoltă un prototip care permite Swaps-Manager (SM) comercianţilor de swap-uri să îşi definească, simuleze şi analizeze oferte complexe în timp ce acestea sunt tranzacţionate de pe telefon. Tabelul 4.1 Proiectele investigate cu privire în ansamblu ansamblu
CAS TVM GD MSS prezentare Prototipuri construite
•
• •
funcţional breadboard
•
•
•
•
•
•
•
•
•
experimentală
•
•
Instrumentele utilizate
•
instrument de construcție de intefețe
• •
•
• •
•
•
• •
•
evolutivă
•
•
FET SM
• •
•
explorator
HyperCard
ARS SME
•
sistem-pilot
Abordarea utilizată în prototipare
PCT
•
•
•
•
•
•
•
•
•
•
• •
• •
4GS
• •
framework Tabelul 4.2 Prototipurile, abordările utilizate şi uneltele folosite
4.5 Analiza punerii în aplicare a prototipurilor După această scurtă prezentare a proiectelor investigate am rezumat constatările relevante pentru realizarea de prototipuri. 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
4.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.3). Frecvent, utilizatorii finali nu sunt consultaţi în aceste cicluri de prototipuri, decât dacă aceştia sunt o parte integrantă a echipei. Utilizatorii finali sunt, de obicei, consultați odată ce o viziune coerentă a fost construită. 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.3 Goluri pentru constructii de prototipuri (+ Scopul proiectului explicit, (+) obiectiv de importanţă secundară, - nici un obiectiv explicit,? nu sunt menționate)
În mod similar, 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. De obicei, nu este important ca aceste prototipuri să modeleze aspecte specifice şi tehnice ale domeniului în detaliu. Este important ca ele să schiţeze soluţia intenţionată şi să fie uşor transmisibile. Nu este o surpriză faptul că multe proiecte se concentrează pe testarea şi măsurarea calităţii aspectului aplicaţiilor. Surprinzător, însă, doar câteva dintre ele au beneficiat de ajutor de la un expert în interfeţe de utilizator sau de la un designer grafic. În tot mai multe proiecte analiza zonei de aplicare este considerată o parte integrantă a procesului de dezvoltare. Este interesant faptul că această cunoaştere specifică domeniului nu a fost realizată cu ajutorul experţilor externi. Nu a fost, de asemenea, nici vreo fază separată de analiză de informaţii la începutul proiectelor. Deducem din aceste observaţii că prototiparea este un mijloc util pentru transferul de cunoştinţe între dezvoltatori şi utilizatorii finali. În plus, 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. Acest lucru este încurajat prin adoptarea unei abordări prin prototipare. În multe proiecte, prototipuri au fost construite pentru a răspunde la întrebări tehnice. Întrebări tehnice pot apărea în timpul întregului proces de dezvoltare şi sunt rareori adresate exclusiv de către membrii echipei. Experţii sunt frecvent consultaţi în domenii specifice, cum ar fi crearea de reţele, baze de date sau hardware. În rezumat, următoarele tendinţe au fost observate:
35
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. Importanţa utilităţii în calitatea unei aplicaţii a fost recunoscută. Cu toate acestea, specialiştii în acest domeniu nu sunt încorporaţi în echipe. Atât cunoştinţele specifice domeniului cât şi cele tehnologice sunt necesare întro echipă de dezvoltare. Prototipurile sunt un mijloc excelent de a dobândi ambele tipuri de cunoştinţe şi de a le evalua împreună cu experţi. Utilizarea prototipului în acest scop este în contradicţie cu strategiile clasice de tip "ciclu de viaţă".
4.7 Strategii de dezvoltare şi procesul de prototipare Studiul arată în mod clar că, în cele mai multe proiecte importanţa comunicării între dezvoltatori şi utilizatorii finali a fost recunoscută. Această comunicare funcţionează numai dacă suportul adecvat este disponibil (vezi Tabelul 4.4). Prototipurile s-au dovedit a oferi acest sprijin adecvat. Această constatare contrazice ideea care stătea la baza strategiilor convenţionale de proiect. Aici managementul încearcă să reducă la minimum comunicarea, prin prevenirea comunicării între dezvoltatori şi utilizatorii finali cu excepţia de la începutul ciclului de viaţă al softwareului. Nu este o surpriză faptul că proiectele pe care le-am studiat nu au fost organizate într-un mod convenţional. CAS TVM
GD
MSS
PCT
(+)
+
+
+
(+)
-
comunicarea utilizator-dezvoltator
+
+
echipa interdisciplinară
+
+
dezvoltarea evolutivă de sistem
+
+
(+)
evaluarea tool-urilor
+
-
-
+
ARS SME
FET
SM
+
+
(+)
+
(+)
-
+
+
(+)
(+)
(+)
(+)
-
(+)
(+)
(+)
(+)
Tabelul 4.4 Strategii ale procesului de prototipare (+ Scopul explicit al proiectului, (+) obiectiv de importanţă secundară, - nici un obiectiv explicit,? nu este menţionat)
Echipe interdisciplinare reprezintă o modalitate importantă de a stabili o comunicare continuă. Aceste echipe sunt formate din dezvoltatori şi experţi în domeniul de aplicare. Acest lucru nu implică neapărat că aceştia din urmă trebuie să lucreze cu normă întreagă pentru proiect, dar ei trebuie să fie pe deplin acceptaţi şi integraţi în echipă. Experţii domeniului de aplicare participă în mod regulat atunci când este important să se evalueze deciziile de design, prototipuri şi documente de dezvoltare, cum ar fi scenarii de utilizare. În cele mai multe dintre proiecte investigate a fost aplicată o strategie de dezvoltare evolutivă. Aceasta este o strategie care nu implică o succesiune de etape 36
ciclului de viaţă. Într-o strategie evolutivă fazele sunt înlocuite de procese iterative în cadrul cărora prototipuri diferite sunt proiectate, implementate şi evaluate în funcţie de decizii critice specifice domeniului sau decizii tehnice care trebuie luate. Deciziile dacă să continue sau să abandoneze un proiect sunt de obicei luate la sfârşitul evaluării unui prototip. Un pas foarte important în numeroase proiecte a fost implementarea sistemelor-pilot pentru utilizatorii finali. Calitatea tool-urilor de prototipare diferă mult iar setul de tool-uri disponibile se schimbă în mod constant. Tool-uri cum ar fi HyperCard şi-au pierdut atracţia de când am efectuat studiu, între timp existând o nouă generaţie de tool-uri de prototipuri, cum ar fi VisualAge şi VisualBasic. 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. A fost chiar un scop secundar în mai multe proiecte să se evalueze calitatea tool-urilor de dezvoltare în timpul prototipării. Acest lucru are sens pentru dezvoltarea de prototipuri acolo unde tool-urile pot fi uşor interschimbate. În rezumat, următoarele tendinţe au fost observate:
Prototipurile sunt un mijloc important de comunicare între dezvoltator şi utilizatorul final. Importanţa acestui tip de comunicare este în creştere. Dintr-un punct de vedere organizatoric, comunicarea este facilitată de echipe interdisciplinare. Tradiţionalele abordări de tipul "ciclu de viaţă" sunt înlocuite cu strategii evolutive în proiecte axate pe construirea de sisteme user-friendly. Prototiparea este astăzi o parte integrantă din aceste strategii evolutive. Piaţa de tool-uri este încă dificil de studiat şi se modifică rapid. Din acest motiv, evaluarea acestora trebuie să fie planificată ca parte a unei strategii de dezvoltare evolutivă în dezvoltarea de aplicaţii inovatoare.
4.8 De la prototipuri la sistemul dorit Mai multe dintre proiectele investigate nu au avut drept ţintă un sistem final. Obiectivele majore au fost obţinerea de informaţii experimentale cu privire la fezabilitate sau experienţă (vezi Tabelul 4.5).Se pare că înţelegerea că prototipurile sunt surse excelente de idei inovatoare chiar şi în industrie a crescut. 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ă, deşi acest lucru nu a fost planificat în avans. CAS
TVM
sistemul-ţintă planificat
+
-
sistemul-ţintă construit
+ -
reutilizarea de blocuri
GD
MSS
PCT
ARS
+
-
+
-
+
+
-
+
-
+
-
+
37
SME
FET
SM
(-)
(-)
(-)
-
+
-
-
-
+
(+)
+
echipe separate
-
+
*
(+)
-
-
*
-
-
Tabelul 4.5 Relaţia dintre prototip şi sistemul-ţintăt (+ explicită, (+) probabilă, (-) improbabilă, * da, 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ă. 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. Î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. Motivul pentru aceasta este, în cea mai mare parte, strategic. 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. Un astfel de prototip este implementat cât mai repede şi simplu, cât mai avantajos posibil şi, prin urmare, este probabil să fie aruncat. Nu multe echipe în marile companii tradiționale sunt în măsură să aplice prototipuri, deoarece dezvoltatorii nu dispun de competenţe necesare, tehnice sau metodologice. Acest lucru duce frecvent la o separare între echipa care realizează prototiparea şi echipa care crează şi întreţine sistemul-ţintă. Acest lucru poate duce la diverse probleme. Unele organizaţii au recunoscut pericolul inerent unei astfel de abordări şi iau măsuri de precauţie, în cazul în care acestea totuşi trebuie să separe echipele. Lucrul cel mai important este de a asigura transferul de cunoştinţe între echipe. Î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 rezumat, 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ţă, de fezabilitate sau pentru a câştiga experienţă experimentală au fost recunoscute. Unele dintre proiectele investigate nu au avut nici măcar un sistem-ţintă ca obiectiv major. 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.Multe prototipuri de prezentare sunt planificate să fie abandonate tocmai din acest motiv. 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ă. Cel puţin această problemă este recunoscută în multe companii.
38
4.9 Analiza punerii în aplicare a tool-urilor În general, tool-urile au fost utilizate conform scopului lor stabilit de către dezvoltatori. Singura excepţie a fost HyperCard care a fost folosit mai ales pentru punerea în aplicare a prototipurilor-schiţă. Multe proiecte s-au folosit de tool-uri sub nivelul optim la care se puteau folosi. Motivele variază: în primul rând, se pare că există o lipsă de cunoştinţe despre piaţa de tool-uri. În plus, există o reticenţă bine-cunoscută de a folosi tool-uri noi. În cele din urmă, există proiecte în care clienţii fac o selecţie nejustificată, dar obligatorie de tool-uri de dezvoltare, ca parte a unui contract. Un alt aspect observat este că proiectele trebuie să fie conştiente de dihotomia sau chiar contradicţia, între arhitecturile şi sistemele software care au fost dezvoltate "surface down". Este aproape imposibil de a dezvolta software de lungă durată şi flexibil pornind de la interfaţa cu utilizatorul, deoarece acele părţi de sistem care nu sunt legate de interfaţa cu utilizatorul, vor duce lipsă de substanţă. Consecinţa acestei constatări este că interfeţele utilizator nu ar trebui să fie derivate sau generate din kernel, cum ar fi modelul de date, pentru că această abordare ignoră potenţialul unei interfeţe inovatoare sau problemele importante de utilizare şi manipulare adecvată. Nucleele domeniului specific şi piesele interactive de interfaţa ar trebui să fie dezvoltate complementar. 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. Dar evident trebuie să ne ferim de iluzia că tool-urile sunt bagheta magică pentru fiecare problemă de inginerie software. Ele sunt utile numai în cazul în care sunt angajate într-un cadru metodologic sensibil.
4.10 Concluzii Prototiparea este folosită în prezent mai conştient decât în ultimii ani. Ca o ilustrare, 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ă. În toate aceste proiecte, prototiparea a fost parte a unei strategii intenţionat evolutivă, la nivel operativ. În plus, 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. Această abordare conştientă către prototipuri pare a fi cheia pentru procentul mare de proiecte de succes în acest studiu. O tendinţă nouă în curs de dezvoltare este de a folosi prototiparea ca un vehicul pentru elaborarea şi demonstrarea viziunilor inovatoare de sistem. Această sursă de inovare poate fi exploatat nu numai pentru proiecte software individuale, ci, de asemenea, pentru diferite tipuri de cercetare de marketing şi studii de teren.
39
5 Descrierea aplicației 5.1 Date generale Aplicația realizată reprezintă un instrument software care crează prototipuri de interfețe utilizator. Aceasta permite atât schițarea de ecrane cât și vizualizarea lor. Având funcționalitate minimă poate fi folosit în procesul de proiectare centrată pe utilizator. Pe lângă schițarea de GUI a unei aplicații, 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. Putem spune că acesta poate fi folosit și în proiectarea UX, descrisă în capitolele anterioare, dar și ca instument de creare de ecrane mock-up și diagrame de afinitate, ambele utile pentru procesul de dezvoltare. În construcția acestei aplicații s-au folosit următoarele:
Limbajul de programare Java Medii de programare: Eclipse Helios Classic 3.6.2(pentru implementarea funcționalității) și Netbeans IDE 6.8(pentru crearea interfeței grafice) Medii de proiectare: Altova UModel Biblioteci adiționale: Mac-Widgets7, JConnector8
5.2 Structura interfeței grafice La lansarea aplicației se va deschide o fereastră de dimensiuni maxime suportate.
Figura 5.1 Structura interfeței grafice a aplicației 7 8
http://code.google.com/p/macwidgets/ http://java-sl.com/connector.html
40
Această fereastră conține: 1. Bară de instrumente Formată din mai multe butoane cu anumite funcționalități de bază, dar conține și funcționalități speciale. Se află în partea de sus, sub bara de titlu a ferestrei 2. Zonă de editare Formată dintr-un panou cu file. 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‖; la adăugarea unei file prin operația de Open File va primi titlul fișierului care a fost deschis; caracterul ―*‖ denotă faptul că starea părții inferioare a filei, a container-ului de componente nu a fost salvată) și un buton ce are asociat ca și acțiune eliminarea filei respective. Componenta din partea inferioară este defapt container-ul de componente, pe care se pot adăuga sau elimina componente. Apare ca un panou grilă. 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. Fiind nucleul aplicației ocupă cea mai mare suprafață a ferestrei și se află în partea centrală, în partea stângă aflându-se panoul cu componentele acceptate de acest container. 3. Un panou de componente disponibile Format dintr-o listă de componente ierarhizate după tip (Swing containers, Swing Controls, Swing Menus, Mac Containers, Mac Controls, Notes) Componentele se adaugă în container-ul filelor din zona de editare prin operațiunea de Drag and Drop. Se află în partea stângă a ferestrei, sub bara de instrumente 4. Componente cu informații adiționale Reprezentate de două componente (X,Y) ce arată coordonatele cursorului când se află pe suprafața panoului grilă din interiorul filei selectate.
5.3 Funcționalități Fiind o aplicație de sine stătătoare conține funcționalități de bază ca orice alt software. Open file – deschide un fișier aflat pe disc ce a fost creat anterior. Acest fișier conține defapt un obiect serializat care va fi încărcat în aplicație și poziționat într-un nou tab, în secțiunea de lucru. Utilizatorul trebuie să specifice calea către fișier și numele acestuia într-un mod interactiv cu ajutorul unui file chooser. New File – crează un nou tab, cu un conținut gol, fără nici o componentă.
41
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
În timp ce componentele Swing separă look-and-feel-ul de logica aplicației, 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. Problemele devin tot mai mari în aplicații complexe unde fiecare componentă poate conține zeci de subelemente, fiecare necesitând o manipulare proprie. În proiectarea tradițională, componentele Swing iau pe rând rolul de view și sunt curățate de codul modelului și al controller-ului. View-ul include doar painting-ul și așezarea componentelor în layout. Modelul poate fi considerat orice clasă Java. Controller-ul conține logica particulară a unei componente. În dezvoltarea acestei aplicații s-a început de la această arhitectură. Astfel, am încercat separarea modelului, view-ului și controller-ului creând o structură a codului cât mai ușor de înțeles. Astfel, vizualizând diagrama de dependințe între pachetele esențiale se poate obseva foarte ușor faptul că în Swing, există amestecul de cod descris mai sus (vezi Figura 5.2).
Figura 5.2 Structura codului - 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ă. Cu toate acestea, există clase care pot fi considerate atât model cât și controller. Construcția aplicației a pornit de la anumite concepte. Principalul concept al acestui instrument software este widget-ul, fiind componenta de bază a tuturor GUIurilor, prin urmare și a prototipurilor UI. 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. În etapa de analiză a realizării acestui soft, s-a căutat cea mai bună, rapidă și plăcută metodă de creare de prototipuri. Cea mai bună soluție găsită a fost drag-anddrop-ul de widget-uri.
45
Pornind de la acest concept am creat o clasă Widget. Aceasta este utilizată în crearea panoului de componente disponibile. Acest panou este format de fapt dintr-un JTree. Având în vedere faptul că am dorit să avem un număr mare de componente, acest JTree devine destul de complex. 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. Din această cauză s-a încercat automatizarea adăugării de componente la acest JTree, prin crearea unui fișier de tip properties care are structura: javax.swing.JButton=prototype.model.components.swing.SwingButton (nume_clasa_componenta_swing = nume_clasa_componenta_UIPrototype)
Astfel că, pentru adăugarea unei noi componente (clasa aferentă trebuie neapărat să existe în proiect) trebuie modificat acest fișier, ce este adăugat ca și resursă la proiect, ș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. După cum se poate observa în Figura 5.3 clasa Widget implementează interfața Transferable necesară pentru operația de DnD. Desigur, în această operație de DnD singurul lucru utilizat va fi proprietatea name a clasei Widget, descrisă mai jos, instanțierea clasei asociate realizîndu-se cu Java Reflection. Toate proprietățile acestei clase se construiesc în funcție de obiectul Class dat ca parametru în cadrul constructorului (ex. new Widget(JButton.class) ).
Figura 5.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, 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,
46
descris mai sus, ce tip de obiect va fi amplasat pe panoul grilă (de ex. 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. Această imagine este salvată ca resursă în cadrul proiectului și are același nume ca și clasa dată în constructor. Astfel pentru adăugarea unei noi componente disponibile pentru aplicație se necesită existența unei clase ce extinde SwingComponent, modificarea fișierul properties, existența unei imagini de tip .gif cu același nume ca cel al Widget-ului și adăugarea nodului cu widget-ul asociat. Să revenim un pic asupra evenimentului de drop. Fiecare widget transferat se transformă întro-o instanță a clasei asociate în momentul drop-ului asupra panoului grilă. Acest panou grilă este o instanță a clasei GridPanel. Această clasă a fost creată pornind de la conceptul de canvas. Astfel s-a ajuns la o zonă de editare, schițare pentru crearea de prototipuri care poate fi salvată ca și imagine de tip .png prin funcționalitatea de Export to image descrisă mai sus. Desigur acest canvas, cu toate componentele ce se află pe el, și toate proprietățile sale, este defapt tot ceea ce va fi salvat în momentul declanșării acțiunii de Save sau Save As, descrise tot ca și funcționalități mai sus. 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, acțiune în urma căreia se va aduce în memorie starea obiectului salvat, prin intermediul deserializării. Având în vedere faptul că acest canvas trebuia să fie un container pentru toate componentele de prototipare, acesta extinde clasa JLayeredPane pentru a permite suprapunerea de compunente, adică așezarea componentelor pe mai multe layere. De aici provine și funcționalitatea de Move to back descrisă anterior. Pentru a permite poziționarea componentei la coordonatele unde s-a pozitionat cursorul în momentul evenimentului de drop, acest GridPanel trebuia neapărat să aibe layout-ul nul. Î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, adăugându-se în fața titlului simbolul ―*‖, ce denotă faptul că fișierul nu este salvat. Conceptul de zonă de desenare a dus și la modificarea felului în care arată acest panou: grila. Acesta a fost creat prin suprascrierea metodei paint din superclasa sa. Desigur un alt avantaj al acestei grile este și faptul că în momentul exportului ca imagine, imaginea creată să fie o informație securizată, asemănător watermark-urilor. Pe lânga extinderea clasei JLayeredPane, aceasta implementează două interfețe MouseListener, 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. Nucleul acestui proiect este clasa abstractă SwingComponent ce extinde clasa JComponent. Orice componentă control sau container ce pot fi disponibile trebuie să extindă această clasă pentru a fi funcționale. Implementarea acestei clase a pornit de la 47
două intenț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. 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. 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. 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. Aici intervine conceptul de glasspane. Acesta este în mod obișnuit o componentă ascunsă, invizibilă, ce acoperă toată suprafața unei ferestre obișnuite (ex. JFrame). De aici a venit ideea de a avea un glasspane pe suprafața oricărei componente, fie ea control, fie ea container. Acest glasspane va fi invizibil și va avea mărimea componentei pe care se află și deasemenea ea va ascunde componenta respectivă (actuală, concretă) de evenimentele obișnuite, deschizând posibilitatea de a putea să adăugăm acțiuni doar pentru evenimentele dorite (vezi Figura 5.5). Acest glasspane este un JPanel care se va instanția în momentul construirii oricărei componente ce extinde SwingComponent. Datorită faptului că toate componentele vor avea atât funcționalități comune cât și funcționalități diferite, 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, doar că sunt definite în interiorul claselor ce o extind (vezi Figura 5.4).
Figura 5.4 Moștenirea clasei SwingComponent
Componentele Swing au disponibil un border. Acest border poate fi setat să apară doar la margine sau mai în interior. Pentru a putea avea un chenar în exterior a fost necesară o altă soluție. Astfel s-a ajuns la construirea unui wrapper pentru componenta concretă. Acest wrapper este defapt un JComponent cu un layout de tip BorderLayout la care de adaugă componenta concretă. Astfel s-a setat un inner border
48
pentru acest wrapper și se crează efectul de border exterior componentei concrete. Componenta concretă este construită prin intermediul metodei abstracte getActualComponent() care returnează instanța componentei concrete, de exemplu un JButton, un JPanel,un JTextArea, etc. 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. 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), connect, disconnect și select (vezi Figura 5.9).
Componenta “înveliș” pentru border (de tip JComponent)
Componenta concretă
Glasspane
Figura 5.5 Structura componentelor
Clasa SwingComponent conține două proprietăți de tip Border: noBorder și resizeBorder(vezi Figura 5.6). Acestea descrie defapt două din stările oricărei componente, componenta pregătită pentru resize și starea ei naturală, fără chenar. Clasa ResizeComponentListener se ocupă cu setarea chenarului de tip ResizeBorder care conține 8 pătrățele numite grips, deasupra cărora cursorul se modifică în funcție de gripul respectiv. 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, la evenimentul de click-dreapta realizat asupra glasspane-ului. Acest meniu popup conține o serie de JMenuItem, fiecare având asociat un ActionListener de tip ItemAction (vezi Figura 5.9). Desigur, având în vedere că există componente control și componente container, acestea vor avea atât funcționalități comune, cât și funcționalități distincte. În funcție de tipul lor, unele meniuri vor avea opțiuni dezactivate sau unele vor lipsi. Fiecare componentă ce se poate afla pe GridPanel este distinctă. Această distincție între obiecte este realizată prin intermediul unui identificator de tip UUID (Universal Unique IDentifier). Astfel putem avea mai multe componente cu aceleași
49
caracteristici, dar ele să fie distincte prin id-ul lor. Acțiunea de eliminare a unei componente se face pe baza identificatorul componentei selectate.
Figura 5.6 Structura, tipurile și controlul chenarelor
O altă funcționalitate interesantă a componentelor este acțiunea de Properties. La selectarea acestei opțiuni de crează o instanță a clasei PropertiesDialog. Aceasta extinde JDialog și conține un panou de file. 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. Această metodă returnează o listă de perechi de obiecte. Primul obiect reprezintă titlul unei file iar cel de-al doilea un container de tip JPanel pentru a-l adăuga filei. Astfel, în funcție de câte perechi de acest gen există, atâtea file vor apărea în fereastra de proprietăți. Desigur, 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. Acest lucru duce la o încărcare de o durată destul de mare. Această problemă a fost rezolvată setând aceste panouri ca fiind statice, astfel fereastra încărcându-se mai greu doar prima dată, la oricare altă deschidere, controalele vor fi doar actualizate cu proprietățile componentei. Datorită faptului că există componente ce au o serie de proprietăți comune, 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. Fereastra de dialog PropertiesDialog mai conține și două butoane, unul de Cancel, ce închide fereastra, iar celălalt de Apply, ce modifică proprietățile inițiale cu cele setate în fereastra de proprietăți. Acțiunea butonului de Apply este descrisă în metoda abstractă applyProperties() din clasa SwingComponent, și urmează a fi implementată de orice clasă ce o extinde pe aceasta.
50
Un punct cheie a acestei funcționalități o face metoda getCopy() din clasa SwingComponent. Aceasta se ocupă în principal cu returnarea unei copii ―deep‖ a componentei. Aici intervine diferența dintre deep-copy și shallow-copy. Cel mai bun exemplu de a diferenția aceste concepte este crearea unei copii a unei colecții. În cazul shallow-copy de va copia doar structura colecției, iar colecția rezultată și cea inițială vor avea același set de elemente. În cazul în care se modifcă un element, automat se va modifica și elementul din copia sa shallow, elementul fiind același. Acest lucru nu se întâmplă și în cazul deep-copy, aici duplicându-se toată colecția. În cadrul aplicației s-a întâlnit necesitatea unei copii deep în mai multe cazuri. De exemplu în momentul actualizării controalelor din fereastra de proprietăți. Dacă se modifică în interiorul ferestrei anumite proprietăți asupra componentei, utilizatorul poate accesa butonul de Cancel iar proprietățile modificate nu se vor aplica asupra componentei. Dacă am fi folosit shallow-copy acest lucru nu ar fi putut fi realizat. Crearea unei copii deep a unui obiect a fost realizată cu ajutorul serializării obiectului, urmat de deserializarea sa, în clasa DeepCopy, în pachetul de utilități. Astfel, pentru a crea o nouă componentă disponibilă, la crearea clasei asociate vor trebui implementate cele trei metode descrise mai sus: getActualComponent(), getTabProperties() și applyProperties(). Pentru ca aplicația să considere că o componentă este de tip container trebuie suprascrisă metoda isContainer(). O altă funcționalitate interesantă a aplicației este crearea de conexiuni între componente. Pentru a crea o conexiune este nevoie de două componente, sursa și destinația. Am considerat această creare de conexiuni ca fiind un proces. Astfel, în momentul alegerii opțiunii Connect se va apela metoda notifyAllConnectingStarted() ce va notifica toate componentele, în afară de cea care a declanșat acțiunea, că sunt pregătite pentru a primi conexiuni. Astfel se vor elimina toți listenerii asupra componentelor și se va aduga listenerul de conexiune, ConnectComponentListener. Acesta va permite ca în momentul poziționării cursorului asupra unei componente ce asteaptă conexiuni, aceasta să apară cu chenar roșu. Dacă se va da click pe această componentă, se va crea conexiunea, 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. Similar se realizează și eliminarea unei conexiuni, cu excepția faptului că se poate elimina doar conexiunea de în care componenta selectată este sursă. La fel și în cazul opțiunii Remove All Connections, care elimină toate conexiunile ce pleacă din componenta selectată. În cazul în care de elimină o componentă, se vor elimina toate conexiunile care o conțin, atât ca sursă, cât și ca destinație.
51
Figura 5.7 Structura conexiunilor
Toate conexiunile sunt de tipul SwingConnector și extind clasa JConnector din librăria importată cu același nume. După cum se poate observa și în Figura 5.7 Toate conexiunile fac parte din clasa GridPanel, structurate într-o listă. O altă funcționalitate a aplicației o reprezintă opțiunea de Bind to container. Momentan aceasta poate fi efectuată doar asupra componentelor-control, nu și asupra componentelor-container. Un control se poate lega doar în momentul în care marginile sale se află în întregime în marginile unui container. Dacă o componentă este legată de un container, iar containerul sau chiar componenta-control își modifică poziția astfel încât marginile controlului să nu se mai afle în interiorul marginilor containerului, aceasta va fi dezlegată. Această funcționalitate a fost necesară pentru a putea vizualiza runtime containerele schițate, prin acțiunea de Preview. Fiecare container schițat, care are cel puțin o componentă legată de el, în momentul declanșării butonului de Preview, va apărea într-o fereastră. În dorința de a lansa în Preview o fereastră și accesând un buton să ne apară o altă fereastră, deasemenea schițată în același GridPanel am creat metoda canHaveActionListener() în clasa SwingComponent. Aceasta returnează inițial false. Pentru funcționalitatea dorită am suprascris-o în clasa SwingButton în care va returna true. Asfel, creând o conexiune de la un buton spre un container care are cel puțin o componentă-control legată de ea, la lansarea în Preview va avea loc efectul dorit. Prin urmare dacă avem un container la care legăm un buton, iar acest buton va avea o conexiune către un alt container, ce are legat cel puțin un control, în modul Preview, va apărea prima dată fereastra cu butonul, iar la accesarea butonului va apărea cealaltă. De această creare a ferestrelor se ocupă clasa PreviewActionListener care ia toate containerele ce conțin componente-control legate de ele, din panoul grilă asociat filei selectate, și verifică dacă nu sunt destinații în colecția de conexiuni(caz în care vor apărea toate odată) . În cazul în care sunt se verifică dacă conexiunea vine de la o componentă ce poate avea acțiune sau nu (dacă da, nu va apărea odată cu restul). Aceasta este partea cea mai importantă a aplicației, deoarece cu ajutorul ei, acest tool devine ceva mai mult decât un instrument de schițare de prototipuri. Acest instrument va putea fi folosit atât în procesul UX, lăsând utilizatorii să interacționeze cu un prototip
52
de sistem funcțional cât și la creare de diagrame de afinitate, prin intermediul componentelor PostIt. Pe lângă aceste funcționalițăți, pe un GridPanel se pot adăuga și componente de tip PostIt, care pot fi folosite atât pentru a crea notițe, despre schițele create, utile mai departe pentru programatori, cât și in proiectarea cu diagrame de afinitate. Având în vedere existența unui cod destul de flexibil, adăugarea de noi componente se face foarte ușor. Pentru a demonstra acest lucru, am adăugat la panoul de componente disponibile niște widget-uri cu look-and-feel de Mac, cu ajutorul bibliotecii Mac-Widgets.
Figura 5.8 Clasa SwingComponent
53
Figura 5.9 Relațiile și dependențele clase SwingComponent
54
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, toate acestea avînd în centrul atenției utilizatorul. Procesul UX plasează prototiparea în cea mai importantă etapă a sa, creare experienței utilizator, prin schițe pe hârtie și continuând cu wireframes și prototipuri interactive. Prin prototipare, 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. Desigur că prototiparea economisește timp și bani, prin crearea sa rapidă și eficientă chiar în timp ce utilizatorul așteaptă. Cu cât prototiparea se apropie de încheiere, modelele create vor începe să se contureze și să se concretizeze tot mai mult. Ideile devin pe deplin puse în aplicare iar fidelitatea prototipurilor devine din ce în ce mai crescută, pe ipoteza că schimbările viitoare vor fi din ce în ce mai puțin semnificative. Deși prototiparea este mai frecvent utilizată în scopul de a ajuta cu design-ul de inteacțiune inițial, metodele prezentate pe parcursul aceste lucrări pot fi utilizate având un mare efect asupra procesului de proiectare centrate pe utilizator. Astfel, după testarea bazată pe utilizator, prototiparea poate fi utilizată pentru a rezolva problemele descoperite la produsul final. Prototipurile sunt create/modificate pe parcursul întregului proces de dezvoltare de aplicații software. 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. Mai departe departamentul de dezvoltare poate continua să lucreze direct pe rezultate, care reprezintă defapt bazele a ceea ce sunt interfețele utilizator.
55
7 Bibliografie The Importance of User Experience. (2006, Septembrie 21). Preluat pe Junie 10, 2011, de pe http://www.experiencedynamics.com/: http://experiencedynamics.blogs.com/site_search_usability/2006/09/the_importa nce_.html User Experience Design Process. (2010). Preluat de pe UXRevisions - Professional User Experience Community: http://www.uxrevisions.com/ux-usability/userexperience-design-process/47/ User experience. (2011, Mai 8). Preluat pe Mai 29, 2011, de pe en.wikipedia.org: http://en.wikipedia.org/wiki/User_experience User-centered Design. (2011, Mai 13). Preluat pe Mai 29, 2011, de pe http://en.wikipedia.org: http://en.wikipedia.org/wiki/User-centered_design Adamchik, A. (2004, Decembrie 1). Java GUI Development: Reintroducing MVC. Preluat pe Aprilie 29, 2011, de pe The Server Side - Your Enterprise Java Comunity: http://www.theserverside.com/news/1364562/Java-GUIDevelopment-Reintroducing-MVC B.A. Myers, M. R. (fără an). Survey on User Interface Programming. Proceedings of the SIGCHI´92. Barber, G. (2010, Martie 31). The Science of UX Design. Preluat pe Mai 30, 2011, de pe http://manwithnoblog.com: http://manwithnoblog.com/2010/03/31/the-scienceof-ux-design/ Bischofberger W.R., P. G. (1992). Prototyping-Oriented Software Development– Concepts and Tools. Springer-Verlag. Brazen, T. (2009, Martie 11). The History & Evolution of User Experience Design. Preluat pe Mai 29, 2011, de pe http://konigi.com/notebook/history-evolutionuser-experience-design Budde R., K. K. (1992). Prototyping– An Approach to Evolutionary System Development. Springer-Verlag. Budde, R. K. (1984). Approaches to Prototyping. Springer Verlag. C., F. (1984). A Systematic Look at Prototyping.
56
Dirk Bäumer, W. R. (1996). User interface prototyping—concepts, tools, and experience. ICSE '96 Proceedings of the 18th international conference on Software engineering. F., C. (2011, Februarie 8). Ce inseamna de fapt User Experience? Preluat pe Mai 29, 2011, de pe http://uxdesign.ro: http://uxdesign.ro/ce-inseamna-de-fapt-userexperience/ User Centered Design. (http://www.akendi.com/). Preluat pe Iunie 10, 2011, de pe http://www.akendi.com/end-to-end-experience-design-process/akendi-usercentered design-process.php Maassen, H. (2008, Mai 21). UX Design - Planning Not One-man Show - Do we need more UX planning teams? Preluat pe Iunie 5, 2011, de pe BoxesAndArrows: http://www.boxesandarrows.com/view/ux-design-planning/ McMullin, J. (2004). The Experience Cycle model - The Elements of the User's Experience. Preluat de pe http://nform.com/files/experience_cycle.pdf Morville, P. (2004, Iunie 21). User Experience Design. Preluat pe Iunie 5, 2011, de pe Semantic Studios: http://semanticstudios.com/publications/semantics/000029.php S.S. Gordon, J. B. (1995). Rapid Prototyping: Lessons. IEEE Software. Shoemaker, C. (2009, Mai 05). History of User Experience. Preluat pe Mai 29, 2011, de pe Blog - Infragistics Community: http://blogs.infragistics.com/pixel8/media/p/95683.aspx Smith, T. (2005, Februarie 24). User Experience Curriculum Diagram. Preluat pe Mai 30, 2011, de pe http://www.theotherblog.com: http://www.theotherblog.com/Articles/2005/02/24/phohevdpzh/ Travis, D. (2002). e-Commerce Usability: Tools and Techniques to Perfect the On-line Experience (ed. 1st edition). CRC Press. Travis, D. (2009, Septembrie 7). Communicating User Experience Design. Preluat pe Iunie 1, 2011, de pe http://www.userfocus.co.uk: http://www.userfocus.co.uk/articles/ux-design-model.html User Experience vs. User Interaction. (fără an). Preluat pe Iunie 10, 2011, de pe UXRevisions - Professional User Experience Community: http://www.uxrevisions.com/user-experience-design/user-experience-vs-userinteraction/16/#more-16 Wroblewski, L. (2005, Februarie 25). User Experience Diagrams. Preluat pe Mai 31, 2011, de pe LukeW - Ideation + Design: http://lukew.com/ff/entry.asp?156
57