}w!"#$%&'()+,-./012345<ya

Transkript

1 }w!"#$%&'()+,-./012345<ya MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Návrh uživatelského rozhraní aplikace pro správu úkolů DIPLOMOVÁ PRÁCE Bc. Pavel Maček Brno, podzim 2010

2 Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: doc. Ing. Jiří Sochor, CSc. ii

3 Poděkování Na tomto místě bych chtěl poděkovat doc. Jiřímu Sochorovi za jeho cenné rady a nadhled během konzultací. Dále chci poděkovat Lucii Tokárové, Ondřeji Válkovi, své rodině a Darkovi Kočárovi za jejich obrovskou podporu. iii

4 Shrnutí Cílem práce je prostudovat postupy používané při návrhu grafického uživatelského rozhraní desktopových aplikací a předvést vybrané postupy při návrhu konkrétního programu. Student prozkoumá různé metodiky uživatelského výzkumu, analýzy, návrhu a teorii vizuálního designu uživatelských rozhraní. Navrhne postup tvorby rozhraní programu pro organizaci úkolů založeného na metodice GTD (z anglického Get Things Done ). Výstupem práce budou testovací prototypy vysoké úrovně a grafický návrh aplikace. iv

5 Klíčová slova Návrh GUI, uživatelský výzkum, použitelnost, ux, analýza, ui, uživatelské testování, prototyp, grafický design, drátěné modely, Goal-Centered Design v

6 Obsah 1 Úvod Desktopové aplikace GTD Tvorba uživatelského rozhraní v malém týmu Orientace na uživatele vs. Orientace na funkcionalitu Goal-Directed Design Potřeby uživatele Identifikace cílů Proces návrhu Goal-Directed Design vs. Activity-Centered Design Role designéra uživatelského rozhraní Informační architekt Interakční designér Výzkumník uživatelů Visuální designér Uživatel a uživatelské rozhraní Lidské charakteristiky důležité pro design Pamět Visuální vnímání Pozornost Cyklus lidské aktivity Lidská chyba Mentální model Zkušenost uživatelů Proces tvorby GUI v malém týmu Výzkum Úvodní specifikace Konkurenční analýza Uživatelský výzkum Kvalitativní Kvantitativní Analýza a specifikace Afinní diagramy Persony Specifikace požadavků Návrh interakcí Diagram případů užití Procesní diagramy Skicování Drátěné modely vi

7 4.3.5 Prototypy Návrhové vzory Vizuální návrh Vizuální styl Barevná paleta Písmo Grafické prvky Animace Ikonografie Grafické návrhy obrazovek Vyhodnocení Heuristická analýza Uživatelské testování Tvorba GUI programu pro organizaci úkolů Výzkum Úvodní specifikace Konkurenční analýza Uživatelský výzkum Průzkum Rozhovory Analýza a specifikace Afinitní diagramy Persony Specifikace požadavků Návrh interakcí Diagram případů užití Skicování Drátěné modely Prototyp Přeskládání úkolů tažením Našeptávač Nástroje pro tvorbu prototypu Vizuální návrh Grafické návrhy obrazovek Ikonografie Vyhodnocení Uživatelské testování Testování ve fázi skic Testování prototypu Závěr Literatura A Obsah CD vii

8 B Pokyny ke spuštění prototypu C Obrazová příloha viii

9 Kapitola 1 Úvod Cílem této diplomové práce je popsat postup vývoje grafického uživatelského rozhraní desktopové aplikace v malém týmu. Nesnažím se popsat definitivní metodu. Určuji důležité části, které by neměli při vývoji orientovaném na uživatele chybět. Teoretické studium prakticky aplikuji při tvorbě GUI 1 programu Done aplikace pro organizaci úkolů podle metody GTD (z anglického Get Things Done ). Jedná se o program určený jednotlivcům, který pomáhá s organizací osobních i pracovních úkolů a povinností. V práci se zabývám pouze těmi fázemi vývoje, které se přímo váží na tvorbu grafického uživatelského rozhraní. Cílem práce není návrh systémové a databázové struktury, i když je možné některé dokumenty (případy užití) v těchto fázích použít. Vycházím převážně z anglické literatury a primárních zdrojů, sekundární zdroje využívám pouze jako doplňující. 1.1 Desktopové aplikace Termín desktopová aplikace nebo desktopový software se používá u programů určených pro osobní počítače a notebooky. Kromě programů určených pro desktop jsou v dnešní době rozlišovány ještě webové a mobilní aplikace. Samostatnou skupinu tvoří i tzv. integrované systémy (z anglického Embedded Systems ), které jsou používané například ve spotřební elektronice a průmyslových zařízeních. Desktopové aplikace je dále možné dělit podle jejich účelu, použitého vzhledu a množství času, jaké uživatel s programem stráví [5]. Tyto charakteristiky významně ovlivňují postoj uživatele k aplikaci a tedy i výslednou použitelnost produktu. 1.2 GTD Get Things Done je metoda organizace práce a času vytvořená Davidem Allen. Podle Allena není člověk uzpůsoben tomu, aby si pamatoval všechny úkoly a závazky [2]. Proto navrhuje využití systému seznamů, ve kterém jsou tyto úkoly uloženy, a na který se může člověk spolehnout. Činnosti se částečně automaticky připomínají, pokud je třeba je vykonat. Člověk na ně tedy nemusí myslet. Následující diagram popisuje proces organizace úkolů podle GTD: 1. Grafické uživatelské rozhraní (z anglického Graphical User Interface ). 1

10 1.2. GTD Záležitosti Schránka Co je to? Je to realizovatelné? Ne Koš Ano Někdy/možná (termínový pořadač) Projekty (plánování) Více kroků Jaký bude další krok? Informace (k vyhledání kdykoliv bude potřeba) Projektové plány (zhodnotit další kroky) Jeden krok Méně než 2 minuty Kolik zabere času? Více než 2 minuty Udělejte to Delegujte to Odložte na později Čekám ( na práci někoho dalšího) Kalendář (udělat v určitý čas) Další kroky (udělat v nejbližší době) 2 Obrázek 1.1: Diagram procesu organizace úkolů podle metody GTD.

11 Kapitola 2 Tvorba uživatelského rozhraní v malém týmu I když pro návrh desktopových aplikací existuje mnoho metodik, jsou z velké části popsány pro projekty v podnikovém sektoru. Takové prostředí se svými prostředky a cíli výrazně liší od malého nezávislého týmu vyvíjejícího pro koncového uživatele. Pro malý tým je časté, že se různé role v projektu spojují a prolínají. Častěji také dochází k zanedbávání principů návrhu orientovaného na uživatele, jelikož je k dispozici méně zdrojů. Je tedy důležité vybrat vhodné metodiky, aby náklady na vývoj byly co nejmenší a přínos orientace na uživatele co největší. Pro potřeby této práce definuji malý tým jako pracovní skupinu s velikostí do pěti členů. Jeho součástí je kromě programátorů a projektového manažera i designér uživatelského rozhraní. Mezi časté charakteristiky takového týmu patří: [9] Dochází ke spojení a prolínání týmových rolí Je velmi častá úzká spolupráce mezi jednotlivými členy Je časté použití ad-hoc postupů namísto formálních metodik Není pravděpodobná vysoká hierarchizace Z těchto vlastností je možné usuzovat, že:[9] Existují menší nároky na dokumentaci, kterou připravuje designér pro vývojáře Vzrůstá důležitost dobrých mezilidských vztahů Existuje prostor pro experimentování s novými postupy Je možná iterace v rámci návrhu Malý tým není vhodný pro vývoj kritických a robustních projektů Je častý vývoj pro koncového uživatele Tyto charakteristiky ovlivňují výrazně proces návrhu rozhraní. Použité metody musí být iterativní, nesmí spoléhat zbytečně na dokumentaci a musí dovolovat velkou variabilitu. Metodiky se u malých projektů vyskytují zřídka ve své čisté podobě [17], proto je důležité použít postup dostatečně flexibilní, který je možné přizpůsobit konkrétnímu projektu. Dokumentace musí být jednoduše srozumitelná pro všechny členy týmu. 3

12 2.1. ORIENTACE NA UŽIVATELE VS. ORIENTACE NA FUNKCIONALITU 2.1 Orientace na uživatele vs. Orientace na funkcionalitu Návrh orientovaný na uživatele (z anglického "User Centered Design") je znám již přes třicet let. I přesto pořád převažuje vývoj zaměřený slepě na funkcionalitu programu místo na potřeby uživatele [5]. V podnikovém sektoru může být úspěšná i aplikace, která neplní cíle uživatelů, ale plní obchodní cíle společnosti. Při vývoji pro koncového uživatele musí úspěšná aplikace řešit problémy uživatelů, ne zadavatele, obchodního zástupce, nebo programátora. Jinak by si uživatelé program nekoupili a nepoužívali. Obecně známým a z části pravdivým faktem je, že orientace na uživatele je drahá [3]. Aktivity uživatelského výzkumu, prototypování a podobně, vyžadují mnoho času a prostředků. Proto se nabízí otázka, zdali se toto úsilí navíc vyplatí. Existuje několik důvodů proč je důležité intenzivně se zajímat o potřeby budoucích uživatelů: Použitelnost a efektivita Tyto vlastnosti jsou pro interaktivní systémy velmi důležité. Zejména pro aplikace určené koncovému uživateli. Nezahrnují pouze produktivitu, tj. rychlost s jakou uživatel provádí dané úkony, ale také přijatelnost. Přijatelnost označuje, do jaké míry systém odpovídá způsobu, jakým potenciální uživatelé pracují [3]. V případě, že bude nový program výrazně měnit způsob práce uživatelů, nebudou ho používat. Obchodní přínos Jak bylo řečeno výše, použitelná a efektivní aplikace má větší šanci na oblibu mezi uživateli. To může v konečném důsledku přinést větší obchodní i celkový úspěch a zvýšit ziskovost aplikace [5]. Bezpečnost Ta se týká především kritických systémů, jako například systém řízení jaderné elektrárny, navigační systémy letadel. Návrh orientovaný na uživatele může často zabránit neštěstí, které je způsobeno chybou uživatele v důsledku nepoužitelného systému. V případě malých aplikací pro koncové uživatele, může bezpečnost představovat ochranu uživatelových důležitých dat před náhodným smazáním nebo poškozením. Orientace na uživatele neznamená ignorování obchodních cílů a technologických limitací. Je třeba mezi nimi najít rovnováhu. 2.2 Goal-Directed Design Goal-Directed Design (česky návrh zaměřený na cíle ) je návrh interaktivních systémů zaměřený na cíle uživatelů [6], s účelem dosažení jejich spokojenosti a efektivity Potřeby uživatele Návrh zaměřený na cíle se zaměřuje na uživatelovi potřeby, motivace a kontext, ve kterém bude výsledný produkt používán. Snaží se také zjistit, kdo bude opravdu uživatelem aplikace. Odkrývá obchodní a technické možnosti, požadavky a omezení. Záměrem je vytvoření produktu, který je obecně použitelný, přínosný, chtěný, technicky zvládnutelný a obchodně výnosný [5]. 4

13 2.3. ROLE DESIGNÉRA UŽIVATELSKÉHO ROZHRANÍ Identifikace cílů Cíl je něco, čeho chce člověk dosáhnout. Nemusí být na první pohled viditelný a motivuje lidské potřeby a chování. Chování je reprezentováno aktivitami, které se dále dělí na jednotlivé úkoly (činnosti). Aby nedošlo k mylným představám o cílech uživatelů, je důležité provést důkladný uživatelský výzkum Proces návrhu Ve zkratce je možné rozdělit Goal-Directed Design proces na šest fází [5], které nemusí nutně následovat pouze za sebou. Tento proces je iterativní a jednotlivé fáze se mohou prolínat. Výzkum uživatelů a domény Modelování uživatelů a kontextu Požadavky definice uživatelských, obchodních a technických potřeb Návrhový rámec definice designu struktury a toku informací Návrhové zjemění chování, formy a obsahu Podpora potřeb vývoje Obrázek 2.1: Proces tvorby GUI podle Goal-Directed Design Goal-Directed Design vs. Activity-Centered Design Protipólem Goal-Directed Design je Activity-Centered Design (česky "návrh zaměřený na úlohy"). Je také orientovaný na uživatele, ale zajímá se o jejich chování (prováděné úlohy aktivity). Cíle je mnohdy obtížné identifikovat, aktivity jsou průkaznější a jasnější. Návrh zaměřený na úlohy říká, že uživatel se může přizpůsobit technologii [14] a že návrh zaměřený na cíle může ztroskotat na nejasnosti cílů. Oba přístupy se navzájem prolínají v použitých metodách výzkumu, analýzy i návrhu interakcí. Dále v této práci vycházím primárně z návrhu zaměřeného na cíle, upraveného pro potřeby malého týmu. 2.3 Role designéra uživatelského rozhraní V malém týmu zahrnuje role designéra uživatelského rozhraní návrh všech aspektů interakce uživatele s aplikací, spojuje tedy několik rolí dohromady [20]. Zahrnuje návrh informační architektury, interakčního a visuálního designu a zajišt uje koherenci a konzistenci napříč těmito aspekty. Role, které na sebe designér rozhraní bere, závisí i od konkrétního projektu. U aplikace zaměřené na obsah by například převládala role informačního architekta. 5

14 2.3. ROLE DESIGNÉRA UŽIVATELSKÉHO ROZHRANÍ Informační architekt Informační architekt je zodpovědný za model informační struktury, navigace a obsahové kategorizace. Tato role je důležitá především pro návrh webových aplikací, jelikož ty jsou často obsahového charakteru Interakční designér Interakční designér je zodpovědný za definování chování a interakce uživatele s aplikací, od přechodů mezi jednotlivými obrazovkami, po interakce v rámci jedné obrazovky. Má na starosti tvorbu procesních diagramů (nebo diagramů aktivit), tvorbu drátěných modelů a prototypů dokumentujících různé druhy chování programu Výzkumník uživatelů Výzkumník uživatelů (z anglického User Researcher ) zprostředkovává informace o uživatelích a jejich potřebách. Tyto informace získává prostřednictvím uživatelského výzkumu a testování. Jeho role je potřebná v různých fázích projektu, at již pro získání prvotních informací o uživatelích, nebo ověření a validace rozhraní v pozdějších stádiích projektu Visuální designér Tato role je často podceňována s tím, že visuální designér vytváří pouze hezký kabát programu. Proto je jeho důležitost zpochybňována. Ve skutečnosti má visuální designér na starost jedinou vrstvu aplikace, s kterou přichází uživatel do přímého kontaktu. Visuální návrh přímo ovlivňuje přívětivost a efektivitu prostředí, ve kterém uživatel pracuje. Návrh rozhraní je iterativní proces, ve kterém se jednotlivé fáze prolínají. Například při návrhu interakcí je nutné mít přehled o poznatcích z uživatelského výzkumu. I když dojde k důkladné dokumentaci, některé znalosti (především získané empatií) se při rozdělení rolí ztratí. Pokud je ale zapojen designér rozhraní do všech fází, nese si sebou získané informace a proto je spojení výše popsaných rolí do jedné výhodné. 6

15 Kapitola 3 Uživatel a uživatelské rozhraní Lidé jsou komplexní organizmy s mnoha atributy, které mají důležitý dopad na návrh rozhraní [7]. Před fází analýzy je důležité shrnout několik základních poznatků o uživatelích a jejich interakci s počítačem. Designér uživatelských rozhraní by měl znát lidské charakteristiky významné pro design a vlastnosti, ve kterých se mohou uživatelé lišit. Na tyto rozdíly se poté může zaměřit při uživatelském výzkumu. 3.1 Lidské charakteristiky důležité pro design Lidé se často velmi liší fyzicky, mentálně, úrovní vzdělání a počítačové gramotnosti. Některé charakteristiky máme však společné a pro návrh rozhraní jsou velmi důležité. Převážná většina pravidel (dobrých praktik) pro uživatelská rozhraní vychází právě z těchto mechanizmů. Patří mezi ně pamět, vnímání (zorný úhel a periferní vidění), pozornost, učení. Dále mají lidé obecně podobný způsob provádění aktivit a další společná vlastnost je chybování. Těmito lidskými charakteristikami se zabývá kognitivní psychologie Pamět Lidská pamět bývá rozdělována na dvě spolupracující části. Krátkodobá (pracovní) pamět udržuje informace po dobu maximálně třicet sekund a udrží pouze 3-4 kusy informace [3]. Pro udržení informací v pracovní paměti je potřeba je opakovat. Pokud neobnovíme obsah paměti, po půl minutě se postupně ztratí. Dlouhodobá pamět má neomezenou kapacitu, informace v ní mohou zůstat několik minut nebo i celý život. Lidská pamět obsahuje mnoho procesů, které je důležité pochopit, aby bylo možné navrhnout dobré uživatelské rozhraní. Mezi důležité mechanizmy patří vzpomínání a rozpoznání. Vzpomínání je proces aktivního prohledávání vzpomínek za účelem nalezení konkrétní informace. Pokud pouze rozhodujeme, jestli vnímaná informace odpovídá tomu, co máme v paměti, pak se jedná o rozpoznání. Rozpoznání je obecně jednodušší než vzpomínání. Dobrým příkladem tohoto principu je nabídka písem v textovém editoru. Většina dnešních textových editorů poskytuje možnost vybrat písmo z nabídky, takže není nutné si pamatovat přesný název písma je využit princip rozpoznání. Dalším důležitým mechanizmem je seskupování. Tento proces lidé používají, často nevědomě, ke sdružování částí do smysluplnějších celků. Častým příkladem je rozdělení telefonního čísla na tři trojčíslí. To se pamatuje jednodušeji než 9 samostatných číslic. Proto je 7

16 3.1. LIDSKÉ CHARAKTERISTIKY DŮLEŽITÉ PRO DESIGN dobré vytvářet v rozhraní logické celky a tím zjednodušit orientaci uživatele. Proces kódování informací z krátkodobé paměti do dlouhodobé paměti se nazývá učení. Proces učení vyžaduje ze strany uživatele často značné úsilí. Proto je důležité při vytváření rozhraní minimalizovat nutnost učení. Nezvýší se tím jen produktivita. Lidé se snaží vyhnout zbytečnému úsilí při učení, proto je nutnost naučení se velkého množství informací můžu i odradit od používání systému. Proces učení může být eliminován nebo usnadněn pokud: [7] Uživatel může použít dovednosti nabité v předešlých situacích (při použití jiných aplikací) Uživateli je poskytnuta dostatečná odezva Proces učení je rozložen do více fází, aby nedošlo k zahlcení uživatele informacemi Dodržení konzistence napříč rozhraním a s běžně používanými systémovými prvky výrazně pomůže uživateli zorientovat se v rozhraní a zkrátí jeho seznamovací dobu Visuální vnímání Vnímání zajišt uje přijímání informací z okolního světa za účelem získání jejich smyslu [7]. Je z části ovlivněno zkušenostmi, jelikož lidé mají tendenci identifikovat vnímané objekty na základě věcí, které již znají. Typy vnímání přímo souvisí s druhy lidských smyslů a především pochopení visuálního vnímání je velmi důležité pro návrh grafických rozhraní. Existuje mnoho teorií popisujících tento proces, pro návrh rozhraní jsou důležité zejména Gestalt zákony (teorie tvarů). Gestalt zákony visuálního vnímání jsou obecně společné pro všechny lidi. Netvoří sice ucelenou teorii, jsou však všeobecně považovány za velice důležité [3]. Je možné je velice dobře použít v návrhu moderních uživatelských rozhraní. Mezi Gestalt zákony patří: Blízkost. Poukazuje na fakt, že objekty objevující se blízko sebe v prostoru nebo čase vnímá člověk jako objekty k sobě patřící. Pro grafické rozhraní platí, že je výhodné seskupovat pouze objekty, které k sobě patří, a tím vytvářet logické celky. Uzavřenost. Uzavřené objekty jsou vnímány jednodušeji než neúplné nebo otevřené objekty. Lidská mysl dokonce doplní chybějící informace, aby vznikl celek. Podobnost. Podobné objekty se jeví jako sdružené do skupiny. Mohou být podobné tvarem i barvou. Symetrie. Symetrické objekty vytvářejí skupinu nebo celek, i v případě velké vzdálenosti mezi sebou. Šipky u scrollbaru tvoří celek, i když jsou vzdáleny daleko od sebe. Cíl dobrého návrhu je využít možnosti vnímání člověka tak, aby obrazovka rozhraní byla rozvržena ve smysluplné a zřejmé podobě. 8

17 3.1. LIDSKÉ CHARAKTERISTIKY DŮLEŽITÉ PRO DESIGN Obrázek 3.1: Ukázka gestalt zákonů. Zleva: Uzavřenost, blízkost, podobnost, symetrie Pozornost Pozornost je zaměření mentálních schopností na některé smyslové vstupy. Lidská pozornost je velice selektivní, kdyby tomu tak nebylo, člověk by byl zahlcen informacemi [16]. K nasměrování pozornosti může dojít bud instinktivně okolními událostmi, nebo vědomou koncentrací na danou věc. Příklad instinktivního nasměrování je například automatické přesměrování pozornosti na dialogové okno při jeho objevení. V případě vědomého nasměrování pozornosti je důležité eliminovat co nejvíce všechny rušivé události, jelikož koncentrace vyžaduje úsilí. Míra úsilí závisí na rušivých faktorech a také na fyzických rozdílech mezi vnímanými objekty. S větším úsilím roste zátěž na uživatele a výsledkem je dřívější únava při použití systému. Například skrytím málo využívaných ovládacích prvků je možné prodloužit dobu, po kterou je uživatel schopný se soustředit na čtený text. Aktivity, které člověk provádí poprvé, vyžadují často velkou pozornost. Naopak aktivity již naučené, jako např. řízení auta, jsou již skoro automatické a tolik pozornosti nevyžadují Cyklus lidské aktivity Sedmi krokový kognitivní model 1 zformulovaný Donaldem Normanem popisuje, jak lidé interagují s počítačovými systémy. Vychází z předpokladu, že akce a činnosti prováděné lidmi jsou motivovány jejich cíli. Lidské akce probíhají podle této teorie v sedmi krocích, rozdělených mezi fáze provedení a vyhodnocení [13]. Nejdříve se zformuje cíl, nebo-li stav, které ho se má dosáhnout. Cíl je transformován na záměr provést nějakou akci. Záměr je přeložen na sekvenci kroků (akcí), které je nutné provést, aby bylo dosaženo cíle. Tyto kroky jsou poté provedeny ve vztahu k vnějšímu světu. Výsledky akcí jsou vnímány a pochopeny. Cílem dobrého návrhu rozhraní je pomoci uživatelům projít cyklem aktivity co nejrychleji a nejpřesněji [7]. Ve fázi provedení je možné uživateli pomoci tak, že je z rozhraní jasné, jakou sekvenci kroků je důležité provést, aby se dostal k požadovanému cíli. Ve fázi vyhodnocení je zase důležité, aby byl uživatel schopný rozeznat jednoduše stav systému. Pokud je něco špatně, uživatel musí být schopný to poznat. Například elektrická šňůra s koncovkou 1. Z anglického Human Activity Cycle. 9

18 3.1. LIDSKÉ CHARAKTERISTIKY DŮLEŽITÉ PRO DESIGN Cíle Provedení Zformování záměru Vyhodnocení Vyhodnocení interpretace Vytvoření sekvence kroků Interpretace vnímaného světa Provedení akce Vnímání stavu okolního světu Svět Obrázek 3.2: Cyklus lidské aktivity podle Normana[?]. se zemnícím kolíkem nedovolí zapojení do zásuvky nesprávně. Většině lidí je hned jasné, že je něco špatně, pokud zapojují koncovku obráceně. Normanův model není jediný model aktivity, je ale v rámci HCI 2 komunity široce přijímán Lidská chyba Lidská činnost se neobejde bez občasné chyby. Je to obecně uznávaná společná charakteristika všech lidí. Úkolem systému je lidským chybám zabraňovat, předcházet a vypořádat se s nimi. Donald Norman dělí chyby do dvou hlavních kategorií, uklouznutí (z anglického slip ) a omyl (z anglického mistake ) [13]. K uklouznutí dochází díky nevědomému chování, kdy člověk provede automaticky činnost, která v daném kontextu není vhodná. Omyl vzniká na základě vědomého zvážení a vybrání špatné možnosti. Uklouznutí je většinou systémem jednoduše detekovatelné, jelikož jde o malé chyby jako stlačení špatného tlačítka. Pokud je uživateli poskytnuta dostatečná odezva. Naopak omyl může být větší chyba, kdy došlo ke špatnému zformulování cíle aktivity uživatelem. Stává se tak na základě špatného rozhodnutí a vyhodnocení situace, přílišného zobecnění a podobně. Tyto chyby jsou špatně rozpoznatelné, jelikož provedené akce odpovídají cíli uživatele a proto jim lze také těžko předcházet. 2. Human-Computer Interaction (česky Interakce člověka s počítačem ) 10

19 3.2. MENTÁLNÍ MODEL 3.2 Mentální model Mentální model je interní reprezentace toho, jak člověk chápe nějakou věc nebo systém [12].Většinou neodpovídá tomu, jak daná věc doopravdy funguje. Uživatelé nemusí vědět o komplexnosti systému, který používají. Tato znalost jim většinou vůbec nepomáhá při jeho používání. Místo toho si vytvoří vlastní model toho, jak systém funguje, který není založený faktech. Člověk není většinou schopný tento model popsat. Naproti tomu implementační [5] nebo také systémový [13] model detailně popisuje, jak program opravdu pracuje. V případě počítačových programů odpovídá implementační model programovému kódu. Při návrhu rozhraní vzniká ještě tzv. reprezentační model, vytvořený designérem. Dovoluje schovat pro uživatele nedůležité a často nepříjemné detaily a co nejvíce se přiblížit jeho mentálnímu modelu. Mentální model pomáhá člověku pochopit, jaké kroky musí podstoupit k provedení činnosti, kterou dělá poprvé nebo ji zapomněl [7]. Pokud bude uživatel pracovat poprvé s novou aplikací, bude očekávat její chování a vzhled na základě svého mentálního modelu. Pokud se program chová v souladu s uživatelovým mentálním modelem, je možné říct o programu, že je intuitivní. Bude jednodušeji naučitelný a použitelný. Tohoto je možné dosáhnout použitím návrhových vzorů, standardů a dodržováním konzistence rozhraní. Pokud se uživatelův stávající mentální model pro danou situaci nehodí, je nejlepší prezentovat model nový, který lépe vystihuje uživatelské cíle. 3.3 Zkušenost uživatelů V kontextu zkušenosti s danou aplikací existují tři obecně známé typy uživatelů: začátečníci, pokročilí a experti. Častým problémem interakčního designu je, jak navrhnout aplikaci pro začátečníky a experty zároveň. Častým neúspěšným řešením je použití zdlouhavých průvodců pro začátečníky a skrytých hlubokých menu pro experty. Důležité je pochopit potřeby všech tří skupin uživatelů. Začátečníci Začátečníkům je nutné zprostředkovat smysl a poslání produktu a pomoci jim při přechodu do fáze střední pokročilosti. To je možné provést pomocí separátního průvodce, ten by se však měl koncentrovat pouze na začátečníky a měl by být co nejstručnější. Středně pokročilý Tito uživatelé potřebují bezproblémový přístup k nástrojům. Ideální formou nápovědy pro tyto uživatele jsou tzv. tooltipy. Chtějí se při práci s programem aktivně zdokonalit, často k tomu ale nemají čas. Tvoří největší skupinu uživatelů. Experti 11

20 3.3. ZKUŠENOST UŽIVATELŮ Expertní uživatelé se konstantně snaží naučit více, pracovat rychleji a efektivněji. Požadují funkce jako možnost ovládání z klávesnice, jelikož jejich frekvence používání programu to vyžaduje. V programu ocení zejména funkce zjednodušující rutinní úkony. Většina uživatelů jsou středně pokročilý [5]. Skupiny začátečníků a expertů jsou malé a nestabilní. Každý uživatel projde s novým programem fází začátečníka, ale nezůstane v ní dlouho. Začátečníci se po určité době stanou středně pokročilými nebo přestanou program používat a přejdou k produktu, který se budou schopni naučit. A opět pouze několik uživatelů se dostane do expertní fáze, jelikož málo jich používá programy tak pravidelně a často, aby si konstantně pamatovali expertní funkce. Proto je důležité navrhovat pro trvale středně pokročilé uživatele, kteří tvoří většinu z uživatelů aplikace. Cílem je tedy navrhnout rozhraní tak, aby pomohlo začátečníkům stát se rychle a snadně středně pokročilými, nestálo v cestě středně pokročilým, kteří se chtějí stát experty a především udrželo trvale pokročilé uživatele spokojenými [5]. Existují případy, kdy je vhodné optimalizovat pro expertní uživatele. Do této kategorie spadají například vývojové, vědecké nebo zdravotnické nástroje. Od uživatelů takových aplikací se očekává vysoká znalost oboru a ochota investovat značné úsilí a čas do zvládnutí aplikace. Stejně tak existují kategorie produktů, které je nutné navrhovat pro začátečníky. Jsou to například zařízení pro seniory nebo uživatele s určitým postižením. 12

21 Kapitola 4 Proces tvorby GUI v malém týmu Proces tvorby grafického uživatelského rozhraní desktopového programu v malém týmu, který jsem zformuloval a použil, vychází z přístupu Goal-Directed Design. Při výběru použitých metod jsem zohlednil především poměr jejich časové náročnosti a přínosu. Upřednostňoval jsem přehledné a rychlé předání informace, před rozsáhlou textovou dokumentací. Například ve fázi návrhu interakcí používám procesní diagramy místo scénářů. I když se zaměřuji na popis návrhu GUI desktopové aplikace, podobný proces je možné použít pro aplikaci mobilní i webovou. Jednotlivé fáze procesu se mohou opakovat a mezi sebou prolínat v závislosti na zvolené metodologii vývoje. Při agilním vývoji se některé fáze mohou rozložit na několik částí, pokud nedojde k celému návrhu rozhraní na začátku projektu. Výzkum (uživatelský výzkum a úvodní specifikace) Analýza a specifikace (analýza výzkumu a specifikace požadavků) Návrh interakcí (případy užití, drátěné modely, prototypy) Visuální návrh (grafický návrh obrazovek, ikony, visuální styl) Vyhodnocení (uživatelské testování, heuristická analýza ) Obrázek 4.1: Navržený proces tvorby GUI v malém týmu. 4.1 Výzkum V oboru vizuální komunikace je výzkum považován za základní stavební kámen dobrého designu [8]. V oblasti interakčního designu je tomu stejně tak. Výzkum tvoří základy, o které je možné se opřít při návrhu interakcí a hledání zaměření produktu. Může být proveden i v pozdějších fázích, s účelem podpořit designéra při rozhodování o správném řešení. 13

22 4.1. VÝZKUM Výzkum Úvodní specifikace Konkurenční analýza Uživatelský výzkum Kvalitativní (rozhovory) Kvantitativní (průzkum, dotazník ) Obrázek 4.2: Části výzkumu Úvodní specifikace Na začátku projektu by měly být určeny cíle projektu, řešený problém, zainteresované strany, mohou být také určeny obecné požadavky na produkt. Tyto činnosti jsou většinou v kompetenci projektového manažera. I přesto může být zapojení designéra výhodné [20], obzvlášt pro malý tým. K určení potřebných informací jsou nejvhodnější osobní setkání s klientem a se všemi zainteresovanými stranami. Projektový manažer (designér) na nich může získat různé pohledy na potřeby, znalosti a problémy týkající se připravovaného projektu. Výsledky úvodní specifikace je vhodné shrnout v uceleném dokumentu. To platí pro klientskou práci i projekty uvnitř společnosti. Průvodní dokument by měl tedy shrnovat strategická rozhodnutí a může obsahovat také technickou specifikaci, časový rozpis a očekávané výsledky. Často je takový dokument nazýván design brief nebo pouze brief [17] Konkurenční analýza Konkurenční analýza má dva základní cíle a í: Zprostředkovat přehled o konkurenci, o tom co funguje a o tom co ne, pomoci v nalezení dobrých praktik [4] Identifikovat možnosti uplatnění na trhu, vlastnosti, které chybí již existujícím produktům (kterými se bude vyvíjený produkt odlišovat od konkurence) Dále může konkurenční analýza pomoci při určení cílové skupiny, nejen pro uživatelský výzkum. To ji činí cennou především pro projekty určené koncovým uživatelům, pro které je dobrá volba uživatelského sektoru významná. Někdy bývá konkurenční analýza mylně používána ke zjištění důvodů úspěchu konkurence. 14

23 4.1. VÝZKUM Konkurenční analýza je používána typicky na začátku a často také v průběhu projektu. Existuje několik různých způsobů jak ji provést. Je možné použít klasické tabulkové seznamy porovnávající funkce dvou a více produktů. Použití série malých obrázků zvaných multiples [20] zprostředkovává přehledný způsob porovnání rozložení prvků na obrazovce. Na začátku konkurenční analýzy je potřeba určit její cíl (co chceme porovnat a za jakým účelem) a kritéria (podle čeho porovnáváme). Cíl může být například: Vytváříme program pro úpravu fotek amatérskými fotografy a chceme vědět, ze kterých produktů mohou v současné době uživatelé vybírat a jakými funkcemi konkurenční software disponuje Uživatelský výzkum Na začátku uživatelského výzkumu je důležité určit cílovou skupinu uživatelů a získat k ní přístup. Je možné začít s provizorním určením skupiny, která se postupně zpřesňuje. U cílové skupiny se rozlišují obchodní charakteristiky jako věk, pohlaví, geografická poloha [17] a pro návrh GUI důležitější uživatelské vlastnosti jako odbornost, postoj k produktu, frekvence použití, motivace a zájem o produkt nebo aktivitu, kterou produkt provádí. V praxi se některé firmy snaží dohnat nedostatek výzkumu budoucích uživatelů pomocí uživatelského testování na konci projektu. U konce je ale velmi těžké napravit chyby způsobené zanedbaným výzkumem. Na druhou stranu množství dat (informací) z uživatelského výzkumu musí být zpracovatelné. Není potřeba shromáždit více dat, než bude možné zpracovat při analýze. V nákladech na uživatelský výzkum a analýzu musí být rovnováha. Běžně rozlišované typy uživatelského výzkumu jsou kvalitativní a kvantitativní. Nejlepší výsledky je možné dosáhnout vyváženou kombinací obou způsobů Kvalitativní Kvalitativní výzkum se snaží odpovědět na otázky typu "Jak?" a "Proč?". Z ekonomických důvodů k tomu používá malý vzorek lidí. Kvalitativní metody dovolují lepší pohled na motivace, očekávání a chování než metody kvantitativní. Mezi praktiky kvalitativního výzkumu patří pozorování a rozhovory. Jen málo uživatelů je schopno artikulovat své potřeby správně [5], ty je nutné odvodit z uživatelových výroků a postojů. Proto může být pozorování uživatele při práci přínosnější než rozhovory. Je ale podstatně nákladnější (finančně i časově). Jako ideální se jeví rozhovor, při kterém je možné vidět uživatele při práci, v jeho přirozeném prostředí. Rozhovor Rozhovor je strukturovaná konverzace [20] s potencionálními nebo stávajícími uživateli. Může být vedený osobně, nebo telefonicky. Videokonferenční hovor (například s využitím služby Skype) poskytuje podobné výhody, jako osobní setkání, ale s nižšími náklady. Přesto je nejlepší vést rozhovor v prostředí, ve kterém uživatel bude software (produkt) používat. Rozhovor by měl být zaměřený na získání následujících informací: Relevantní zkušenosti s podobným softwarem 15

24 4.2. ANALÝZA A SPECIFIKACE Jak uživatel pracuje Obecné cíle, které uživatele motivují k používání vyvíjeného software Ověření informací o základních uživatelských skupinách Kvalita rozhovorů je přímo úměrná kvalitě pokládaných otázek a výběru účastníků. Je dobré se vyhnout navádějícím otázkám. Úspěšnost rozhovorů hodně závisí také na upřímnosti účastníka rozhovoru (vědomé i nevědomé). V malém týmu je důležité mluvit s uživateli průběžně a ověřovat svá rozhodnutí, zároveň se nenechat svést na scestí osobními preferencemi malého procenta uživatelů Kvantitativní Kvantitativní metody uživatelského výzkumu jsou zaměřeny na objektivní informace získané od velkého vzorku lidí. Jsou vhodné pro získání odpovědí na otázky typu "Kolik?", jako například Kolik procent uživatelů disponuje internetovým připojením?, a na ověřování dříve získaných informací. Mezi metody kvantitativního výzkumu patří průzkumy (například ve formě dotazníku). Průzkum Průzkumy sestávají ze skupiny dobře vytvořených a cílených otázek, které jsou distribuovány mezi velký vzorek lidí [20]. Je možné použít průzkumy i pro získání kvalitativních informací (postoje a návyky uživatelů). V tomto případě je vhodná časově nenáročná forma a použití nenavádějících otázek. 4.2 Analýza a specifikace Analýza Afinitní diagramy (a jiné metody analýzy) Persony Specifikace požadavků Úvodní specifikace Obrázek 4.3: Části analytické fáze. 16

25 4.2. ANALÝZA A SPECIFIKACE Po provedení uživatelského výzkumu se musí získané informace setřídit a analyzovat. V této fázi se upřesňují uživatelské profily a požadavky na aplikaci. Častou chybou v procesu vývoje je zanedbání důkladné analýzy uživatelských dat. Neuspořádanou masu informací vzniklou po výzkumu je potřeba zpracovat a převést do podoby, kterou lze prezentovat členům týmu a klientovi. S výsledky kvalitativního výzkumu se nejlépe pracuje, pokud se nejdříve převedou do fyzické podoby (například nalepovací papírky) [17]. Při manipulaci s daty se tak zapojí i prostorové myšlení. Vhodnou součástí analýzy je také počáteční roztřídění dat. To pomáhá v manipulaci s daty a při identifikaci opakujících se vzorů. Běžné možnosti třídění dat jsou abecedně, chronologicky, podle počtu výskytů. Postupy pro analýzu dat se liší, podle způsobu práce s daty. Například abstrakcí získaných informací se vytváří konceptuální modely. Naopak dekompozicí prováděných úloh lze provést tzv. úkolovou analýzu (z anglického Task analysis ). Flexibilní metodou analýzy uživatelských dat jsou afinní diagramy, jejichž principem je seskupování informací do logických celků. V týmovém prostředí je možné použít brainstorming, skupinovou aktivitu kreativního řešení problémů. Zapojení všech členů týmu je vhodné také pro zvýšení obecné důvěry ve výsledky výzkumu a v práci designéra Afinní diagramy Afinní diagram (také diagram příbuznosti) je vhodným nástrojem pro uspořádání velkého množství informací získaných při uživatelském výzkumu 1. Pomáhá tyto informace uspořádat do přirozených a logických skupin, a tak objasnit strukturu a vzory v chování a postojích uživatelů. Neuspořádané informace Afinní diagram Skupina 1 Skupina 2 Skupina 3 Obrázek 4.4: Princip afinního diagramu

26 4.2. ANALÝZA A SPECIFIKACE Oblíbeným způsobem realizace afinních diagramů je použití nalepovacích (Post-It) papírků. Nejdříve se relevantní výroky uživatelů napíší na papírky. Mohou to být výroky popisující úlohy nebo reprezentující postoj uživatele vzhledem k vyvíjené aplikaci nebo tématu. Papírky se přilepí na stěnu tak, aby byli přístupné celému týmu po několik dní. Poté může začít fáze uspořádání podobných výroků do skupin, s cílem identifikovat trendy a vzory. Skupiny se pak pojmenují a dále strukturují. Je výhodné začlenit do tohoto procesu celý tým. Při sestavování afinního diagram mohou členové týmu nenásilnou cestou získat přehled o budoucích uživatelích, potenciálních funkcích a dalším směru vývoje aplikace vůbec. Afinní diagramy jsou vhodné i ve fázi uživatelského testování, k vyhodnocení získaných informací Persony Persony jsou dokumenty popisující typické uživatele. Představují zástupce takových skupin uživatelů, které jsou pro vyvíjený program relevantní a významné. Pokud jsou postaveny na dostatečném výzkumu, mohou zprostředkovat jasný obraz o budoucích uživatelích. Persony byly původně marketingový nástroj určený k modelování motivací k nákupu [5]. Pro návrh uživatelských rozhraní jsou zaměřeny na cíle a chování uživatelů. Důvodů k využití person je několik: Pomáhají se zaměřit na relevantní uživatele Mohou pomoci týmu a klientovi udržet pozornost na motivacích a potřebách uživatele v průběhu projektu Pomáhají vytvořit empatii celého týmu s budoucími uživateli a zvýšit tak motivaci k vytvoření systému, který splňuje cíle uživatelů Díky jejich jednoduché formě mohou být prezentovány všem členům týmu, klientovi, zainteresovaným osobám Mohou pomoci vyřešit konflikty, které vznikají během návrhových a vývojových rozhodnutí Představují velmi dobrý a často atraktivní způsob vtažení celého týmu do výsledků uživatelského výzkumu Persony mohou snížit časové nároky na designéra. Za předpokladu, že jsou persony správně vytvořeny a přijaty, mohou vývojáři některé problémy a detaily řešit sami, designér tedy nemusí navrhovat nutně všechny interakce. To je výhodné zejména pro malý tým. Části, které by měly persony obsahovat, závisí na konkrétním projektu a na obecenstvu, kterému budou persony prezentovány. Za minimum se považuje jméno, motivace, potřeby a scénáře [4]. Jméno může být reálné, nebo může popisovat obecnou roli persony. Motivace a potřeby persony reprezentují cíle jedné skupiny uživatelů. Scénáře jsou realistické příklady 18

27 4.3. NÁVRH INTERAKCÍ interakce persony a systému. Další součásti person ji mohou pomoci dotvořit tak, aby byla vhodná pro určené obecenstvo. Jsou to například popis chování, citace, požadované systémové funkce a demografické informace spolu s osobním profilem. Každá persona by měla mít přidělenou prioritu. Primární persony reprezentují nejdůležitější uživatelskou skupinu. Persony jsou velmi užitečný nástroj. Jejich kvalita je však přímo úměrná prostředkům vynaloženým na uživatelský výzkum. Nejlepších výsledků je dosáhnuto při spojení uživatelských dat z pozorování a rozhovorů [20], a online průzkumu ze sociálních sítí. Tzv. adhoc persony je možné vytvořit i bez uživatelského výzkumu, mohou sloužit jako odrazový můstek v případě nedostatku prostředků, nebo času Specifikace požadavků Specifikace požadavků není pouhý seznam funkcí, které má systém obsahovat. Slouží k definici produktu před fází návrhu. Měla by popisovat řešený problém, koncept a vizi toho, jakým způsobem se bude problém řešit [5]. Specifikace požadavků provedená po fázi výzkumu je již dostatečně informovaná uživatelskými daty. Je tedy možné doplnit a zpřesnit obchodní požadavky definované na začátku projektu. Požadavkům je třeba přidělit priority. Z uživatelského výzkumu by měly mít největší prioritu požadavky primární persony. Tyto se vyvažují s požadavky získanými během konkurenční analýzy a klientů. Scénáře jsou vhodným, i když často příliš obsáhlým, prostředkem k zachycení požadavků na systém. Pro potřeby vývojářů je nutné je dále transformovat do jednodušší (více procedurální) formy. Persony, dělené podle důležitosti, mohou také sloužit ke specifikaci požadavků. Neobsahují ale požadavky získané z konkurenční analýzy a ze strany klienta. Další formou reprezentace požadavků je seznam rozdělený podle priorit, doplněný o definici problému a vize. 4.3 Návrh interakcí Návrh interakcí 2 je postaven na syntéze principů interakčního designu 3 [5], návrhových vzorů a informací získaných během analytické fáze. Při výběru metod návrhu interakcí jsem se soustředil na metody používající vizuální reprezentaci. Pro sjednocení dokumentace návrhové fáze je výhodné používat jeden softwarový nástroj. Klasické programy používané pro softwarové modelování (například Case Studio) nejsou při návrhu GUI v malém týmu vhodné. Jsou zbytečně robustní a nákladné. Nástroje jako Microsoft Visio nebo Axure mohou být lepší volbou. 2. Interakce v tomto smyslu znamená komunikaci mezi člověkem a programem. 3. Principy interakčního designu jsou soubor znalostí, postojů a hodnot, kterými by měl interakční designér disponovat. 19

28 4.3. NÁVRH INTERAKCÍ Persony Specifikace požadavků Návrh interakcí Případy užití a procesní diagramy Skicování Drátěné modely Prototyp (prototypování) Obrázek 4.5: Části fáze návrhu interakcí Diagram případů užití Diagram případu užití (z anglického Use Case ) je formální modelovací technika UML (Unified Modeling language), která není omezená na konkrétní metodiku vývoje software a je hojně používaná [15]. Z pohledu softwarového inženýrství slouží k zobrazení hranice systému a jeho hlavních funkcí. Pro potřeby interakčního designu je diagram případů užití zajímavý, díky své schopnosti přehledně modelovat interakce mezi aktéry (uživateli) a systémem. Pro designéry je diagram případu užití dobře znám [17]. Diagram se skládá se z případů užití a aktérů. Aktér je externí role interagující se systémem. Případ užití je aktivita, kterou aktér může provést. Není to pouze primitivní funkce, ale komplexní interakce s předem daným cílem. Díky grafickému znázornění je diagram případů užití jednoduše čitelný i pro laiky. Proto je vhodný pro prezentaci klientům a jako efektivní dokumentace pro členy malého týmu. Při určování aktérů je možné vycházet z person, pokud byly v analytické fázi vytvořeny. Aktéry mohou být často jen uživatel a systém. Pro specifikaci jednotlivých případů užití se používají toky událostí, diagramy aktivit, pseudokód nebo procesní diagramy. Díky jejich flexibilitě a visuální reprezentaci se procesní 20

29 4.3. NÁVRH INTERAKCÍ diagramy jeví jako nejlepší volba pro malý tým Procesní diagramy Procesní diagram (také vývojový diagram) slouží k názornému grafickému zobrazení posloupnosti a vzájemné návaznosti všech kroků určitého procesu (úlohy). Jeho použití je vhodné, pokud je potřeba rychle a efektivně naznačit interakce uživatele se systémem. Procesní diagram se skládá ze sekvence kroků, které jsou propojeny cestami. Má směr, začátek a konec. Kroky, ve kterých dochází k větvení, se nazývají Rozhodovací body. Procesní diagramy jsou používány interakčními designéry zejména při návrhu webových aplikací [4], hodí se ale také pro návrh interakcí menších desktopových aplikací. Diagramy mohou být přepracovány do podoby jiných, více formálních diagramů, nebo doplněny scénáři, pokud je potřeba přidat více detailů Skicování Skicování je jeden z nejlepších přirozených nástrojů designéra. Visuální reprezentace problému představuje nejefektivnější způsob zaznamenání myšlenek a komunikace [16]. Žádný digitální nástroj se zatím nebyl schopen vyrovnat flexibilitě, rychlosti a jednoduchosti skicování na kusu papíru. Vizualizace myšlenek přináší potřebný celkový přehled při řešení problému. Obrázek 4.6: Příklad prvotní skicy webového rozhraní. Autor: Pavel Maček Skicování při návrhu interakcí umožňuje rychlé zkoumání prvotního konceptu. Příprava skic je rychlá a levná. Využití skic při brainstormingu je ideální pro malý tým. Digitální ná- 21

30 4.3. NÁVRH INTERAKCÍ stroje již mají dopředu určenou vizuální reprezentaci. Naopak skicování dává designérovi úplnou volnost a skici působí přirozeně jako nedokončená práce, takže nikdo nemá zapotřebí diskutovat o nedůležitých detailech a pozornost se ubírá hlavně na koncept. Skici ve formě malých obrázků jsou obrazové scénáře (z anglického storyboard ), což je koncept známý z kinematografie. Je to scénář filmového záběru, v případě uživatelských rozhraní to je scénář interakce Drátěné modely Drátěný model, neboli wireframe, je statický způsob zobrazení struktury a funkčního chování navrhovaného programu [20]. Vizuálně popisuje jednotlivé obrazovky programu a ukazuje umístění navigačních prvků, ovládacích prvků a obsahové členění. Drátěné modely pomáhají při zobrazení a odhalení vzájemných vztahů jednotlivých prvků obrazovky a pomocí jejich anotace lze naznačit i chování programu. Drátěné modely jsou využívány zejména pro návrh obrazovek webových a mobilních aplikací. Jako předstupeň prototypů jsou vhodné i pro desktopový software. Namísto reálného obsahu jsou drátěné modely vyplněny zástupným obsahem. Ten by měl být reálný, ne nesmyslný nebo generovaný [1]. Jen tak je možné navrhnout správné rozložení obsahu na obrazovce a vhodně zvolit strukturu. V pozdějších fázích jsou změny struktury většinou drahé. Drátěné modely mohou být hrubé, zobrazující pouze strukturu obrazovky, nebo detailní, věnující se i typografii a blížící se grafickému návrhu. Obrázek 4.7: Příklad drátěného modelu s anotací. Autor: Pavel Maček 22

31 4.3. NÁVRH INTERAKCÍ Je možné je prezentovat vývojářům, celému týmu, klientům a také budoucím uživatelům [20] a je možné nad nimi provádět uživatelské testování a nenákladně ověřovat dříve vytvořené koncepty. Klienti si mohou na základě drátěných modelů představit směr návrhu obrazovek a nemusí čekat až na grafický návrh. Změny v drátěných modelech jsou typicky méně nákladné než změny na úrovni grafických návrhů. Vzhled drátěných modelů není nijak unifikovaný. Měly by používat sjednocené výrazové prostředky v rámci jednoho projektu. V rámci malého týmu je výhodné používat stejný styl pro všechny projekty. Jelikož jsou drátěné modely zaměřeny na strukturu a chování, je vhodné používat černobílé schéma (odstíny šedi) a nezdržovat se výběrem barev nebo písma. Drátěné modely jsou většinou doplněny anotací, která popisuje strukturu, prvky na obrazovce, a jejich funkcionalitu. Neexistuje pro ni žádný formálně specifikovaný zápis, ale na internetu je k dispozici nespočet vzorů pro různé platformy a typy projektů 4. Anotace popisuje jednotlivé prvky drátěného modelu, pravidla a interakce. Měla by být napsána jasně a stručně, bez možnosti dvojího výkladu. Drátěné modely spolu s dostatečnou anotací mohou v některých případech nahradit formální obchodní specifikace požadavků Prototypy Prototyp je dynamický model vyvíjeného programu, nebo také vyjádření vize interakčního designéra [17]. Při prototypování dochází k vytvoření funkčního modelu z konceptů, které byli zatím jen na papíře. Prototyp je nástroj pro ověření a komunikaci konceptů zamýšlených pro vyvíjený produkt. Imituje funkce a chování výsledného programu, zároveň je jeho výroba několikrát levnější než implementace celé aplikace. Proto může být prototypování iterativní proces. Po vytvoření prototypu proběhne evaluace, na jejím základě se provedou potřebné změny a proces se opakuje, dokud se nedosáhne požadovaných výsledků. Druh použitého prototypu záleží na dostupných zdrojích a na typu produktu, který je vyvíjený. Podle použité úrovně detailu a podobnosti s výsledným produktem se dělí na [3]: Nízko-úrovňový prototyp Sestavený rychle s omezenou funkčností a základním rozhraním Nemá opravdovou interaktivitu, musí být někým rozpohybován (moderátor uživatelského testování) Dají se jednoduše upravit a iterovat Papírový prototyp je možné ho vyrobit z drátěných modelů, je to asi nejrychlejší způsob jak demonstrovat pracující produkt, výhodný pro malý tým, není příliš

32 4.3. NÁVRH INTERAKCÍ Obrázek 4.8: Papírový prototyp vyrobený formou šablony. Autor: Ondřej Válka valka.info/ vhodný pro uživatelské testování Fóliový prototyp obrazovky nakreslené na průsvitných fóliích a promítané zpětným projektorem, designér upravuje obrazovky podle interakcí s aplikací Vysoko-úrovňový prototyp Vyžaduje větší investici zdrojů a času Je plně interaktivní Obsahuje mnoho vlastností výsledného produktu (interakce, visuální design, funkční kód) Vhodný pro uživatelské testování Hrozí nebezpečí, že bude tento prototyp uživateli a klienty považován za finální Prototypovat celou aplikaci může být příliš nákladné a často to není potřeba. Proto je dobré omezit funkcionalitu. Podle způsobu omezení jsou rozlišovány: 24

33 4.3. NÁVRH INTERAKCÍ Vertikální prototyp Obsahuje funkcionalitu pro zvolenou část programu Dovoluje podrobné testování Horizontální prototyp Simuluje věrně rozhraní Nedisponuje žádnou reálnou funkcionalitou V dnešní době je možné použít pro prototypování desktopové aplikace nástroje vývoje webových aplikací. Například knihovna Javascript, jquery UI 5 dovoluje stejné typy interakcí jako desktopový software. S její pomocí je možné vytvořit prototyp, který se dá zkompilovat jako dekstopový program (platforma Adobe Air 6 ). Díky tomu lze dosáhnout komplexních interakcí s velmi malými náklady. Navíc je možné takové prototypy jednoduše distribuovat po internetu a využít vzdáleného testování. Prototypy vyšší úrovně dobře jsou vhodné k dokumentaci interakcí. S jejich použitím není potřeba vytvářet podrobnou dokumentaci a zároveň nezůstane návrh drobných interakcí na vývojáři. Ten by sám zvolil nejefektivnějšího řešení z hlediska kódu, což je často nejhorší řešení z pohledu designu Návrhové vzory Návrhové vzory zachycují běžná a ověřená řešení návrhových problémy. Jejich princip pochází původně z architektury 7. Mohou podstatně zrychlit a zjednodušit proces návrhu i vývoje (použitím hotových komponent). Například v případě, že chce designér ukázat uživateli, v jakém stavu je prováděná dlouhotrvající operace (kopírování souborů), použije standardní indikátor pokroku (z anglického progress indicator ). Je zbytečné navrhovat nové řešení již vyřešeného problému. Přesto nejsou návrhové vzory krabicová řešení. Jejich implementace se vždy trochu liší v závislosti na kontextu použití [19] a existují případy, kdy je vhodné navrhnout řešení nové. Zejména, pokud toto řešení přináší výrazné zlepšení. Rozlišují se vzory struktury (například vzor rozvržení do dvou panelů), chování (drag and drop) a vnějšího vystupování (aplikace zaměřená na obsah). Speciálním případem návrhových vzorů jsou směrnice (z anglického Design Guidelines ), které určují chování a vzhled aplikací vyvíjených pro určitou platformu. Pro vývojáře programů na platformě Mac OS X jsou zpracovány velmi podrobné směrnice popisující běžné vzory chování a interakcí Jako první popsal teorii vzorů v architektuře Christopher Alexander ve své knize A Pattern Language. 25

34 4.4. VIZUÁLNÍ NÁVRH 4.4 Vizuální návrh V případě GUI desktopové aplikace probíhá komunikace mezi uživatelem a aplikací vizuálně, například přímou manipulací s rozhraním [7]. Visuální návrh tedy hraje důležitou roli, protože stojí mezi uživatelem a systémem a podílí se velkou mírou na konečném dojmu uživatele. Visuální návrh GUI je komplexní disciplína, ve které platí základní pravidla z typografie a grafického designu. Základními stavebními prvky visuálního návrhu GUI jsou tvar, velikost, jas, odstín, orientace, textura, pozice. Pomocí těchto proměnných je možné definovat konkrétní návrh grafického uživatelského rozhraní. Dobrý visuální návrh by měl: Využívat visuálních proměnných k seskupení objektů na obrazovce a vytvářet hierarchie Zprostředkovat uživateli visuální strukturu a tok informací Účelně a důkladně spojit styl a funkci rozhraní [5] Vyvarovat se visuálnímu šumu Vizuální styl Visuální styl sestává z použitých barev, písma, grafických prvků, ikonografie a animací. Může být částečně určen firemní identitou. To by ale nemělo být na úkor principů visuálního návrh GUI. Barvy firemní identity nemohou určovat barvy uživatelského rozhraní. Visuální styl by měl být konzistentní v rámci aplikace ale také v rámci operačního systému. Konzistence neznamená jen stejný vzhled, ale i chování. Některé operační systémy (Mac OS X) mají visuální styl určený detailně a přísně, jiné (Microsoft Windows) mají směrnice volnější. Pro dosažení konzistentního vzhledu v rámci operačního systému je důležité použití stejných metafor, návrhových vzorů typických pro daný OS, stejných textur, animací. Změna barevného schématu konzistenci tolik neporuší, i když je zdánlivě nejviditelnější. K určení visuálního stylu rozhraní mohou pomoci tzv. inspirační tabule (z anglického Mood boards ). Je to způsob zkoumání emoční stránky produktu [17]. Jedná se o koláž vytvořenou pomocí obrázků, barev, typografie, která by měla působit stejně jako finální systém. Dříve používali designéři pro tvorbu inspiračních tabulí časopisy a noviny, ze kterých vytvářeli koláže. Dnes je možné vytvořit inspirační tabule digitálně a mohou obsahovat i multimédia Barevná paleta Použitá barevná paleta je výrazným identifikátorem visuálního stylu. Při výběru barevného schématu je dobré se vyhnout agresivním a komplementárním barvám. Vybrané barvy po- 26

35 4.4. VIZUÁLNÍ NÁVRH Obrázek 4.9: Směrnice popisující strukturu a vzhled dialogového okna Mac OS X. předí a pozadí by měly být dostatečně kontrastní Písmo Písmo na obrazovce by mělo být dostatečně ostré s dobrou čitelností a vysokým kontrastem. Pro běžné ovládací prvky se normálně používá písmo systémové Grafické prvky Grafické prvky jsou z velké části ovlivněny trendy a visuálním stylem operačního systému, pro který je aplikace vyvíjena. At už jsou to lehké přechody, nebo textura šumu, podobné grafické prvky pomáhají vytvořit zamýšlený dojem z aplikace Animace Animace je často používána k vytvoření bezprostřední odezvy programu. Moderní operační systémy disponují sadou standardních animací, které by měly být používány konzistentně v podobných situacích. Animace by měla být používána obezřetně a pouze v krátkých úsecích. Je to totiž výrazný prvek, který může představovat nežádoucí vyrušení uživatele, pokud je použit nevhodně Ikonografie Ikona je grafický symbol, který reprezentuje určitý objekt nebo funkci. Má mnoho různých použití, v rámci grafického uživatelského rozhraní může být symbolem pro objekty, vlastnosti objektů, akce a systémový status. Principy dobře utvořené ikony jsou podobné jako principy dobře vytvořeného grafického rozhraní. Správně vytvořené ikony by měly být: Povědomé měly by využívat známé metafory [7] 27

36 4.5. VYHODNOCENÍ Obrázek 4.10: Příklad vysoce stylizovaných ikon. Autor: Pavel Maček Zřejmé s jasným významem Jednoduché neměly by obsahovat zbytečné detaily Jednotné měly by být sestaveny ze stejných grafických prvků Rozlišitelné různé ikony by měly mít dostatečně odlišnou reprezentaci Postup tvorby ikon by měl začínat u zvolení vhodné metafory. Před kreslením v digitálním nástroji je dobré vytvořit několik různých skic. Tak je možné najít nejlepší reprezentaci dané metafory. Vizuální styl ikon a jejich stylizace by měli odpovídat stylu celého GUI Grafické návrhy obrazovek Grafické návrhy obrazovek vycházejí strukturou z drátěných modelů a graficky z visuálního stylu. Je výhodné si po určení visuálního stylu připravit dokument shrnující barevnou paletu a základní grafické prvky. To může pomoci při kreslení jednotlivých obrazovek a zrychlit práci. K návrhům obrazovek je možné použít grafické editory jako Adobe Photoshop nebo v poslední době stále populárnější Adobe Fireworks, který je pro návrh pro GUI lépe uzpůsoben. Grafické návrhy nemusí odpovídat přesně drátěným modelům nebo prototypu. Mohou v nich být zaneseny změny rozhraní na základě uživatelského testování a heuristické analýzy. Změny není třeba dokumentovat zpětně v drátěných modelech. Grafické obrazovky není potřeba navrhovat všechny. Je možné navrhnout obrazovky s unikátními prvky nebo strukturou a pro zbytek použít drátěné modely nebo skici, podle kterých obrazovky připraví vývojáři přímo při implementaci. V případě úzké spolupráce designéra a vývojáře se tímto způsobem ušetří dost času. 4.5 Vyhodnocení Vyhodnocení je iterativní proces kontroly návrhových rozhodnutí. Má své místo na začátku, v průběhu, i na konci projektu. Průběžná kontrola designérových rozhodnutí je během pro- 28

37 4.5. VYHODNOCENÍ Vyhodnocení (nemá hranice) Uživatelské testování (rozhovory, průzkumy) Heuristická analýza Obrázek 4.11: Metody vyhodnocovací fáze. cesu návrhu GUI velmi důležitá. Mezi široce používané metody hodnocení aplikace z pohledu grafického rozhraní a uživatele patří heuristická analýza a uživatelské testování. Obě metody jsou vhodné pro zjištění jiné skupiny problémů a mohou se tedy navzájem doplňovat a vyvažovat Heuristická analýza Heuristická analýza je systematické vyhodnocení GUI pomocí seznamu principů, heuristik 8 dobrého designu [3]. Je to detailní zhodnocení vyvíjeného programu odborníkem na interakční design, za účelem identifikovat potencionální problémy. Jelikož jde o hodnocení na základě profesní zkušenosti, kvalita získaných informací závisí především na hodnotiteli. Heuristická analýza je v porovnání s uživatelským testováním jednoduchá na provedení a relativně levná. Identifikovány jsou zejména menší chyby [7]. Naopak problémy struktury aplikace zůstávají většinou neodhaleny. Heuristická analýza není vhodná pro podložení návrhových rozhodnutí, tam je nutné zapojit uživatele [21]. Při provádění heuristické analýzy je dobré použít víc než jednoho hodnotitele (víc než 3 nemá většinou smysl). Hodnotitelům je nutné podat shrnutí projektu a seznam heuristik, na které se mají zaměřit. Čím budou mít lepší přehled o programu a uživatelích, tím bude výsledek analýzy hodnotnější. Analýza by měla proběhnout nejlépe víckrát za sebou. Nalezené problémy musí být zdokumentovány a přiděleny k patřičným heuristikám. Po evaluaci je třeba sestavit kompletní seznam problémů a přidělit jim prioritu podle závažnosti. V malém týmu je možné si pro heuristickou analýzu najmout kontraktora, nebo ji realizovat svépomocí, při nedostatku zdrojů. I v takovém případě má význam a může odhalit běžné problémy nebo zapomenuté interakce a procesy. Heuristiky je dobré si sestavit podle svých potřeb. I přesto existují ucelené seznamy 9, které je možné použít. 8. Heuristika princip vytvořený na základě zkušenosti

38 4.5. VYHODNOCENÍ Uživatelské testování Uživatelské testování pomáhá ověřit, zda se povedlo navrhnout systém, který řeší problémy uživatele a naplňuje jeho cíle. Uživatelské testování není není univerzální lék pro program se zanedbaným výzkumem. Uživatelské testování používá stejné metody jako uživatelský výzkum, kvalitativní (rozhovory, pozorování) a kvantitativní (průzkumy). Rozhovory a pozorování se používají ke zjištění problémů v interakci uživatele s programem, jeho postojů, popřípadě frustrací. Průzkum je možné použít k otestování emoční odezvy. S uživatelským testováním je dobré začít již během prvních fází projektu. Testování nad papírovým prototypem je do značné míry omezující, přesto může odhalit problémy v navigaci, kategorizaci obsahu a podobně. Testování nad horizontálním prototypem je vhodné pro prověření interaktivity. Vertikální prototypy poskytují možnost otestovat použitelnost pro vybrané funkce. Naplánováním uživatelského testování pro celý proces vývoje se zmenší šance, že nezbude čas [10]. Průběžné krátké testování s malým počtem uživatelů je pro malý tým asi nejvýhodnější. Doplněním o heuristickou analýzu lze získat i druhý pohled. Pokud je to možné, je dobré do testování zapojit celý tým. Odpadne tak potřeba drahé dokumentace (nahrávání). Pro testovací rozhovory je vhodné připravit si testovací plán. To je sada otázek, která provede uživatele systémem. Je dobré použít neutrální a nenavádějící otázky (stejně jako u uživatelského výzkumu). Testovací plán by měl být sestavený podle scénářů, pro které byl prototyp vytvořen. Při hledání účastníků pro uživatelské testování mohou posloužit persony jako vzor vhodných vlastností. 30

39 Kapitola 5 Tvorba GUI programu pro organizaci úkolů V této kapitole názorně popisuji tvorbu GUI programu Done aplikace pro organizaci úkolů podle metody GTD (z anglického Get Things Done ). Postupoval jsem podle procesu popsaného v předešlé části této práce. 5.1 Výzkum Úvodní specifikace Na začátku jsem do úvodního dokumentu shromáždil projektovou vizi, cíle projektu a zběžný obchodní model (ten jsem zahrnul, jelikož částečně ovlivňuje specifikaci požadavků). Nezaměřoval jsem se na detaily, jelikož jsem věděl, že se budou v prvních fázích projektu často měnit. Cíle projektu Vytvořit desktopovou aplikaci, která: Bude zaměřená na organizaci času (práce) podle metody GTD Bude dostatečně flexibilní pro použití individuálních modifikací GTD Bude pomáhat začátečníkům se základy GTD, zároveň nebude brzdit pokročilé uživatele Bude důvěryhodná, tak, aby ji uživatelé používali i k organizaci svého osobního života Bude určena pro Mac OS X i Microsoft Windows Po důkladném prostudování metody GTD jsem sestavil seznam základních požadavků. Tento seznam nebyl zatím podpořený uživatelským výzkumem ani konkurenční analýzou. Jako základní požadavky jsem určil: Sběr úkolů úkoly bude možné zaznamenat do schránky (inbox) Zpracování záležitostí úkoly bude možné třídit, přiřazovat datum splnění, přiřazovat kontext 31

40 Organizace Úkoly bude možné organizovat do projektů (podprojektů) 5.1. VÝZKUM Revize (Kontrola) Pro úkoly bude možné nastavit týdenní (měsíční) kontroly Podpora rozhodováni Informace o kontextu, projektu, a času budou přehledně zobrazeny tak, aby podpořili rozhodování Konkurenční analýza Následně jsem provedl analýzu konkurence s těmito cíli: Zjistit, jak konkurenční aplikace organizují úkoly Zjistit, do jaké míry je možné konkurenční produkty přizpůsobovat Porovnat layout (rozložení) konkurenčních aplikací Identifikovat základní skupiny uživatelů K dosáhnutí těchto cílu jsem použil dva přístupy. Pro získání přehledu o tom, jaký layout používá konkurence, jsem vytvořil sérii zmenšenin. Obrázek 5.1: Srovnání struktury konkurenčních programů. Růžové obdélníky naznačují oblast pro přidání nového úkolu, černé znázorňují oblast navigačních prvků. Funkční vlastnosti jsem porovnal pomocí tabulky kritérií. Použil jsem tato kritéria: Členění do sekcí běžné je členění na schránku (inbox), projekty a kontexty. 32

41 5.1. VÝZKUM Způsob a umístění vyhledávání úkolů Vyhledávání je implementováno vždy, většinou se nachází vpravo nahoře, a obsahuje našeptávač (nebo se rovnou filtrují vypsané úkoly) Způsob delegace úkolů Možnost poslání úkolu em je časté řešení Parametry úkolu Název, Splnit do a Kontext Použití kontextů Často bývá omezen počet kontextů pro jeden úkol Způsob synchronizace a ukládání dat Možnost synchronizace více počítačů (zařízení) je velmi častá S pomocí konkurenční analýzy (a rozhovorů s potenciálními uživateli) jsem identifikoval cílovou skupinu aplikace: Lidé pracující v zaměstnáních náročných na organizaci času (IT, management, obchod, webdesign). A tři provizorní uživatelské typy: Uživatel používající GTD v papírové podobě není ho potřeba přesvědčit o výhodách GTD, je důležité pro něj přinést přidanou hodnotu oproti papírovému řešení. Uživatel používající GTD v elektronické i papírové podobě (pravověrný uživatel) počítačově gramotný, zavedený uživatel, který potřebuje pokročilejší funkce. Uživatel, který nepoužívá GTD metodiku, ale rád by začal není rozhodnutý pro GTD, je důležité ho navést v prvních krocích, neztratit ho přílišnou složitost Uživatelský výzkum Cílové skupiny a provizorní uživatelské typy mi pomohli zjistit, na jaké uživatele se mám při uživatelském výzkumu zaměřit. Použil jsem kombinaci kvantitativních a kvalitativních metod. Vytvořil jsem průzkum ve formě dotazníku, zaměřený převážné na kvalitativní informace Průzkum Dotazník jsem vytvořil pomocí služby Google Spreadsheet 1. Díky navázání na tabulkový dokument jsem mohl využít přehledného způsobu uložení sbíraných dat. K rozšíření dotazníku mezi potenciální uživatele jsem využil sociální sít Twitter. Díky tomu jsem byl schopný namířit dotazník na cílovou skupinu vyvíjené aplikace. Dotazník obsahoval krátké adresné otázky, tak aby ho bylo možné vyplnit během pěti minut. Použil jsem dvě jazykové verze českou a anglickou s účelem zvětšit počet získaných odpovědí. Během prvního týdne jsem posbíral více než padesát odpovědí pro každý z jazyků. To je pro kvalitativně zaměřený průzkum dostatečný počet

42 5.2. ANALÝZA A SPECIFIKACE Rozhovory Po počátečním průzkumu jsem pokračoval v rozhovorech s budoucími uživateli. I když se jednalo o rozhovory neformální, měl jsem připravené otázky, abych se mohl zaměřit na informace, které pro mě byly důležité. Všechny poznatky o uživatelích jsem pečlivě dokumentoval. Data z uživatelského výzkumu je možné najít v příloze této práce. 5.2 Analýza a specifikace Po shromáždění dostatečného množství informací jsem započal jejich zpracování. Vzhledem k velkému počtu získaných dat jsem musel najít vhodný způsob jejich třídění Afinitní diagramy Uživatele z průzkumu jsem seskupoval přímo v tabulkovém dokumentu postupným obarvováním na základě jejich podobných charakteristik. Nejdříve do provizorních skupin, následně do rozpoznaných uživatelských typů. Výroky ke každé hrubě identifikované skupině jsem roztřídil na funkce a chování (společně s postoji, potřebami a motivacemi). Podobné výroky jsem seskupil a určil jsem nejčastější chování a požadované (potřebné) funkce. Obrázek 5.2: Zpracovávání uživatelského výzkumu pomocí afinních diagramů. 34

43 5.2. ANALÝZA A SPECIFIKACE Persony Získané informace jsem modeloval ve formě person. Určil jsem tři persony, které odpovídají uživatelským skupinám. U person jsem neuváděl demografické informace, vytvořil jsem pouze jejich kostru [4]. Každá persona obsahuje popis cílů, motivací a potřeb, funkcí (které by využila) a klíčové scénáře. Kompletní dokumentace person je v obrazové příloze této práce. Renata (primární) Používá GTD, ale ještě nenašla ten správný program. GTD si vedu na papíře nebo s pomocí různých programů, zatím jsem nenašla ten pravý program. Její motivace a potřeby: Hledá program, který ji usnadní zaznamenávání a vedení úkolů (oproti papírovému zápisníku). Chce dosáhnout jednoduchého vedení projektů a kontextů pro jednotlivé úkoly. Nechce myslet na opakující se projekty. Eva (sekundární) Používá věrně metodu GTD a konkurenční programy. Líbí se mi filozofie GTD a vyhovujeme mi dělení úkolů podle kontextů. Její motivace a potřeby: Chce mít po ruce spolehlivý nástroj pro zaznamenávání úkolů, který bude bezpečně uchovávat úkoly. Chce, aby manipulace se seznamy úkolů byla co nejjednodušší. S programem stráví nejspíš dost času, takže chce použitelný a vizuálně příjemný nástroj. Marek (doplňující) Používá GTD metodiku jen v omezené míře. Z GTD jsem si vybral části, které mi vyhovují, celé mi přijde příliš organizačně náročné. 35

44 Jeho motivace a potřeby: 5.3. NÁVRH INTERAKCÍ Nechce být striktně omezený na GTD. Chce mít možnost si program přizpůsobit podle svých potřeb. Nechce ztrácet čas přílišnou organizací. Chce zadávat úkoly tak rychle, jak jen to je možné Specifikace požadavků Po zpracování uživatelského výzkumu, jsem měl dostatek informací, abych mohl vytvořit plnohodnotnou specifikaci požadavků. Priority person jsem použil pro rozdělení požadavků podle důležitosti. Specifikační dokument je přiložený v příloze. Obrázek 5.3: Zjednodušená specifikace požadavků ve formě myšlenkové mapy. Žlutě jsou vyznačeny základní požadavky. 5.3 Návrh interakcí Při návrhu interakcí jsem se zaměřil na požadavky s vysokou a střední prioritou Diagram případů užití Diagram případů užití jsem modeloval na základě typických uživatelských scénářů. Zaměřil jsem se pouze na případy užití zahrnující uživatele. Jednotlivé případy užití jsem specifikoval pomocí procesních diagramů. Ty jsem použil místo pseudokódu, nebo diagramu aktivit. Procesní diagramy jsem zvolil z důvodu jejich přehlednosti a flexibility. 36

45 5.3. NÁVRH INTERAKCÍ Aplikace pro správu úkolů PU1 Sběr úkolů PU2 Zpracování úkolů «uses» PU3 Vytvoření kontextu PU4 Organizace úkolů «uses» PU5 Vytvoření projektu PU6 Prohlížení úkolů Uživatel PU8 Vyhledání úkolů Synchronizační server PU7 Synchronizace Mobilní zařízení Obrázek 5.4: Diagram případů užití. Při návrhu procesních diagramů jsem nedokumentoval chybové stavy a detailní chování rozhraní. Důležité detaily v chování aplikace jsem zachytil později v prototypu. Při definování interakcí jsem se soustředil především na jejich přímočarost Skicování Po zpracování všech důležitých scénářů do podoby procesních diagramů jsem začal s návrhem obrazovek. Zaměřil jsem se nejdříve na celkový layout. Využil jsem informace získané během analýzy konkurence a vyzkoušel jsem několik možných rozvržení obrazovky. Dva závislé panely Pro základní strukturu jsem použil návrhový vzor dvou závislých panelů (z anglického two-panel selector ) [19]. První panel slouží k výběru položky a v druhém panelu se obsah vybrané položky zobrazí. Nejznámějším příkladem tohoto vzoru 37

46 5.3. NÁVRH INTERAKCÍ Obrázek 5.5: Prvotní skica rozhraní. je Průzkumník 2. Použití dvou závislých panelů je vhodné, pokud je uživateli prezentován seznam objektů (kategorie, akce), který má vlastní obsah. Uživatel tak může přehledně vidět strukturu zobrazovaných dat. Podmínkou použití tohoto vzoru je dostatečný prostor na obrazovce, což mnou vyvíjený program splňoval. Skici jsem dále zpřesňoval. Pro umístění panelů jsem zvolil běžné řešení, zejména kvůli konzistenci. Levý panel tedy obsahuje navigaci a v pravém panelu se zobrazuje obsah. Vytvořil jsem skici základních obrazovek a nakreslil jsem i některé důležité chování programu. Všechny skici jsem anotoval, abych zdokumentoval interakce a významné detaily Drátěné modely Během této fáze jsem shledal, že má snaha, navrhovat rozhraní pro dvě platformy současně, (Microsoft Windows a Mac OS X) negativně ovlivňuje důležitá návrhová rozhodnutí. Proto jsem myšlenku společného rozhraní pro obě platformy opustil a zaměřil jsem se na charakteristiky operačního systému Mac OS X. Drátěné modely jsem navrhoval za účelem: Čitelnější a formálnější dokumentace prvotních skic Jako iterace a zpřesnění konceptů vytvořených při skicování Jako základ interaktivního prototypu 2. Systémový program operačního systému Microsoft Windows. 38

47 5.3. NÁVRH INTERAKCÍ Obrázek 5.6: Skica schránky úkolů. Samotné drátěné modely jsem navrhl v programu Adobe Fireworks, jelikož disponuje paletou připravených systémových prvků GUI a umožňuje export do aplikace Adobe Catalyst program pro tvorbu interaktivních prototypů. Anotaci jsem přidal v programu Microsoft Visio, který jsem použil k dokumentaci velké části návrhové fáze. Během přípravy drátěných modelů jsem řešil problém, jak vyznačit a zaznamenat interakce jako kliknutí, hover, nebo tažení objektu. Jako nejvíce vhodný způsob jsem určil použití ikon a zvýrazněného popisu v anotaci Prototyp Pro otestování základních interakcí jsem vytvořil horizontální prototyp, který je plně interaktivní, ale provedené změny nejsou ukládány a jsou viditelné pouze v rámci jedné obrazovky. Vzhled prototypu není založený na grafickém návrhu, ale na drátěných modelech. Kromě jednoduchých interakcí jsem v prototypu navrhl a vyzkoušel: Přeskládání úkolů tažením Jeden ze základních principů GUI [11] I když vypadá tažení objektů jednoduše, je to komplexní interakce složená z více než desítky stavů Je vhodný pro určování priority úkolů, uživatel úkoly může sám pohodlně přeskládat podle důležitosti Pro účely vyvíjené aplikace jsem použil tažení objektů omezené na prostor seznamu 39

48 5.3. NÁVRH INTERAKCÍ Obrázek 5.7: Drátěný model pro obrazovku Schránka Našeptávač Během vyplňování textového pole zobrazuje systém uživateli možné odpovědi Tento princip funguje dobře, pokud je možné udělat rozumný odhad toho, co uživatel bude vyplňovat Našeptávač jsem použil při vyplňování kontextu u úkolů a ve vyhledávání Při tvorbě prototypu jsem se dopustil v některých případech vědomé nekonzistence, abych mohl mezi sebou porovnat různé interakce. Pro určení kontextu úkolu jsem použil textové pole s našeptávačem. Díky tomu se automaticky vytvoří nový kontext, pokud našeptávač kontext nenajde. Pro určení projektu, do kterého úkol patří, jsem naopak použil výběr z možností (z anglického select box ). Výhoda tohoto přístupu je v jeho názornosti. Uživatel okamžitě ví, jaké projekty má k dispozici Nástroje pro tvorbu prototypu Pro tvorbu prototypu jsem zvažoval tyto možnosti: 40

49 5.3. NÁVRH INTERAKCÍ Obrázek 5.8: Interaktivní prototyp. GUI Design Studio Dovoluje vytvářet jednoduché scénáře a neumožňuje příliš velkou interaktivitu. Změna stylů a vzhledu je těžkopádná, na druhou stranu knihovna prvků je dostačující. Způsob prohlížení prototypu je nešikovný, je třeba instalovat speciální prohlížeč. Není možná recyklace prototypu. Microsoft Visio Je možné v něm vytvořit i drátěné modely a procesní diagramy. Interakce se v podstatě omezuje jen na procházení mezi jednotlivými obrazovkami. Adobe Catalyst Dovoluje import drátěných modelů z Adobe Fireworks a dokáže simulovat poměrně velkou interaktivitu. Je vhodný zejména pro prototypy omezené na jeden scénář, který je možné celý inscenovat. Prototyp je možné použít jako základ aplikace vytvořené na platformě Adobe Air. HTML + jquery UI (JavaScript knihovna) Designérům dobře známé nástroje. Při využití CSS frameworků je kódování prototypu velmi rychlé. Knihovna jquery UI simuluje skoro všechny typy desktopových interakcí. Použitá technologie Zvolil jsem poslední možnost. Základ prototypu jsem vytvořil pomocí HTML a JavaSriptu (knihovny jquery UI). Prototyp jsem pak exportoval z aplikace Adobe Dreamweaver jako multi-platformní aplikaci Adobe Air. Dosáhl jsem tedy desktopového vzhledu a chování, při jednoduché implementaci. 41

50 5.4. VIZUÁLNÍ NÁVRH 5.4 Vizuální návrh Před započetím tvorby grafických návrhů jsem určil základní charakteristiky visuálního stylu, které souvisí s typem programu. GUI by tedy mělo: Působit důvěryhodně, až konzervativně Neunavovat uživatele při delším užívání programu (zejména oči) [5] Využít co největší plochu na obrazovce Musí používat známé a lehce rozlišitelné metafory Působit přehledně a vyrovnaně Omezit použití výrazné a rušivé animace Jako východisko visuálního stylu jsem využil směrnice Apple HCI Guidelines, zejména v případě struktury aplikace a použitých interakčních prvků Grafické návrhy obrazovek Ve fázi grafického návrhu jsem se zaměřil na definování visuálního stylu aplikace. Proto jsem navrhl jen základní obrazovku. Specifické grafické prvky je možné vytvořit až během implementace. Pro určení struktury a hierarchie jsou dostačující drátěné modely. Grafický návrh jsem vytvářel ve dvou hlavních iteracích. Po první návrhu jsem se rozhodl zvolit více systémový vzhled, využít podobností s programem Finder (Průzkumník pro Mac OS) a zvýšit tím důvěryhodnost programu. Obrázek 5.9: První grafický návrh. V druhém návrhu jsem tedy zvolil barvy ze systémové palety. Použil jsem grafické prvky a ikony typické pro Mac OS. Snažil jsem se maximalizovat prostor pro úkoly a všechny prvky rozhraní rozdělovat do logických částí (navigační prvky, nastavení, základní akce, doplňující akce). 42

51 5.4. VIZUÁLNÍ NÁVRH Obrázek 5.10: Druhý grafický návrh Ikonografie Ikony jsem připravoval ve dvou stylových a velikostních verzích: Ikony pro nástrojovou lištu a kategorie Tyto ikony používají poměrně velkou míru detailu, stínování a odvážnější barevné schéma. Připravil jsem je ve dvou velikostech, 32x32 pixelů a 16x16 pixelů. Obě velikosti jsem musel kreslit zvlášt, abych uzpůsobil míru detailu dané velikosti. Ikony pro ostatní interakce Tyto ikony používají jiný způsob stylizace, přesto používají stejné tvary jako ikony pro nástrojovou lištu, aby byla dodržena konzistence. Jsou jednobarevné a jsou použité výhradně pro akce. Nejdříve jsem ikony načrtl a v několika iteracích jsem pro ně hledal vhodné metafory. Pro ikony jsem zvolil, stejně jako pro rozhraní, styl a barevnost běžné pro Mac OS X. 43

52 5.5. VYHODNOCENÍ Obrázek 5.11: Sada vytvořených ikon. 5.5 Vyhodnocení Heuristickou analýzu jsem provedl nad drátěnými modely a prototypy. Uskutečnil jsem heuristickou analýzu svépomocí a použil jsem kombinaci heuristik specifikovaných Nielsenem 3 a Benyonem [3]. Zaměřil jsem se na problémy, které se nevážou na vizuální styl, takže zejména problémy navigace, ovládacích prvků a celkové struktury aplikace Uživatelské testování Testování jsem prováděl v neformální podobě, abych minimalizoval jeho náklady. Drátěné modely a prototyp jsem opakovaně diskutoval s budoucími uživateli. Jejich odezvu jsem přímo zanášel do rozhraní Testování ve fázi skic První rozhovory s uživateli jsem vedl již během fáze skicování. Informace při nich získané mi pomohli zvolit základní strukturu aplikace a rozložení ovládacích prvků. Ověřil jsem správnost svého rozhodnutí použít dvou závislých panelů a horní nástrojové lišty Testování prototypu Neformálně jsem aplikaci testoval i na prototypu. Mohl jsem se tak soustředit na získání většího počtu názorů a postojů. Nevýhodou takového postupu je špatná dokumentace takových informací. I přes neformální přístup jsem přichystal testovací scénáře, díky kterým se uživatel mohl soustředit na prototypem podporované interakce. Výhodou mnou sestaveného prototypu byla jednoduchá demonstrace. Prototyp jsem zpřístupnil na internetu a je

53 5.5. VYHODNOCENÍ možné ho nainstalovat na libovolné platformě podporující Adobe Air (Microsoft Windows, Mac OS, některé Linux distribuce). Při testování se prokázala jasná struktura aplikace, naopak pojmenování některých prvků bylo problematické. Například slovo záležitost jsem v nástrojové liště zaměnil za úkol na základě reakcí uživatelů. Z hlediska GTD je termín úkol nepřesný, termín záležitost byl ale pro uživatele nejasný. Testoval jsem tyto scénáře: Vytvoření nového úkolu (jak přes nástrojovou lištu, tak rychlím vytvořením) Vytvoření nového kontextu Vytvoření nového projektu Přeskládání úkolů podle priority Zvolení kontextu Vytvoření úkolu z projektu Zrušení a editace úkolu Splnění úkolu 45

54 Kapitola 6 Závěr V této diplomové práci jsem popsal vhodný postup pro návrh GUI desktopové aplikace v rámci malého týmu s omezenými zdroji. V takovém prostředí je velmi složité udržet orientaci na uživatele a zároveň nepřekročit náklady na projekt. Postup, který jsem navrhl, se snaží vytěžit maximum z dostupných metodik a zdrojů. Praktickým výsledkem mé práce jsou podklady pro vývoj aplikace pro správu úkolů. Prototyp aplikace byl testován a ověřen uživateli. Při práci na vyvíjené aplikaci, jsem si prakticky vyzkoušel metody uživatelského výzkumu, analýzy a návrhu. V další fázi projektu bude nutné formálně otestovat prototyp a započít přípravy k implementaci. 46

55 Literatura [1] 37signals,.: Getting Real, [2] Allen, D.: Get Things Done: The Art of Stress-Free Productivity, Viking, [3] Benyon, D. a Turner, P. a Turner, S.: Designing Interactive Systems: People, Activities, Contexts, Technologies, Addison-Wesley, , 3.1.1, 3.1.2, 4.3.5, 4.5.1, 5.5 [4] Brown, D.: Communicating Design: Developing Web Site Documentation for Design and Planning, New Riders, , 4.2.2, 4.3.2, [5] Cooper, A. a Reimann, R. a Cronin, D.: About Face3: The Essentials of Interface Design, Wiley, , 2.1, 2.2.1, 2.2.3, 3.2, 3.3, , 4.2.2, 4.2.3, 4.3, 4.4, 5.4 [6] Cooper, A.: The Inmates Are Running the Asylum, Sams, [7] Galitz, W.: The Essential Guide to User Interface Design, Wiley, , 3.1.1, 3.1.2, 3.1.4, 3.2, 4.4, 4.4.2, [8] Visocky O Grady, J. a Visocky O Grady, K.: A Designer s Research Manual: Succeed in Design by Knowing Your Client and What They Really Need, Rockport Publishers, [9] Jaroslav, K.: Technologie informačních systémů (přednáška), [10] Krug, S.: Rocket Surgery Made Easy: The Do-It Yourself Guide to Finding And Fixing Usability Problems, New Riders, [11] Scott, B. a Neil, T.: Designing Web Interfaces, O Reilly, [12] Nielsen, J.: Mental Models, html, [13] Norman, D.: The Design Of Everyday Things, Basic Books, , 3.1.5, 3.2 [14] Norman, D.: Human-Centered Design Considered Harmful, CACM, jnd.org/dn.mss/human-centered.html, [15] Radek, O.: Objektové metody návrhu IS (přednáška), [16] Passer, M. a Holt, N. a Bremer, A. a Sutherland, E. a Vliek, M.: Psychology: The Science of Mind and Behaviour, McGraw-Hill Education, , [17] Saffer, D.: Designing For Interaction: Creating Innovative Applications and Devices, New Riders, , 4.1.1, 4.1.3, 4.2, 4.3.1, 4.3.5, [18] Tidwell, J.: Designing Interfaces: Patterns for Effective Interaction Design, O Reilly, ,

56 [19] Tidwell, J.: Designing Interfaces: Patterns for Effective Interaction Design,, , [20] Unger, R. a Chandler, C.: A Project Guide to UX Design: For User Experience Designers in The Field or in The Making, New Riders, , 4.1.1, 4.1.2, , , 4.2.2, 4.3.4, [21] Chisnell, D.: What You Really Get From a Heuristic Evaluation, org/dn.mss/human-centered.html,

57 Příloha A Obsah CD Přiložený kompaktní disk obsahuje: tuto práci ve formátu PDF dokumentaci a data uživatelského výzkumu, úvodní specifikaci, specifikaci požadavků v několika iteracích a persony, diagram případů užití a procesní diagramy původní skicy, drátěné modely s anotacemi, interaktivní testovací prototyp, grafický návrh základní obrazovky v několika iteracích, sadu detailních ikon 49

58 Příloha B Pokyny ke spuštění prototypu Pro správné spuštění prototypu je třeba nainstalovat nejdřívě platformu Adobe Air. Instalační soubory pro Adobe Air i prototyp jsou ve složce nazvané Navrh interakci. Po nainstalování se prototyp chová jako běžný program. 50

59 Příloha C Obrazová příloha Diagram případů užití, vybrané procesní diagramy, vybrané drátěné modely, persony. 51

60 C. OBRAZOVÁ PŘÍLOHA Diagram případů užití Aplikace pro správu úkolů PU1 Sběr úkolů PU2 Zpracování úkolů «uses» PU3 Vytvoření kontextu PU4 Organizace úkolů «uses» PU5 Vytvoření projektu PU6 Prohlížení úkolů Uživatel PU8 Vyhledání úkolů Synchronizační server PU7 Synchronizace Mobilní zařízení 52 Obrázek C.1: Diagram případů užití.

61 C. OBRAZOVÁ PŘÍLOHA PU2: Zpracování úkolů Inbox Existuje nezpracovaný úkol? Ano Přidat kontext Ne Časově omezený úkol? Ano Ne Přidat datum vypršení Prázdný inbox 53 Obrázek C.2: Procesní diagram pro případ Zpracování úkolů.

62 C. OBRAZOVÁ PŘÍLOHA PU5: Vytvoření projektu Základní obrazovka Vytvořit nový projekt Přidat kontext Časově omezený projekt? Ano Přidat datum vypršení Ne Potvrzení změn 54 Obrázek C.3: Procesní diagram pro případ Vytvoření projektu.

63 C. OBRAZOVÁ PŘÍLOHA PU6: Prohlížení úkolů Základní obrazovka Vybrat projekt Projektu Prohližet podle: Kontextu Vybrat kontext Zvolit zobrazení (Rozbalit všechny, sbalit všechny, první úkol) Zobrazený úkol 55 Obrázek C.4: Procesní diagram pro případ Prohlížení úkolů.

64 C. OBRAZOVÁ PŘÍLOHA PU7: Synchronizace Základní obrazovka Je uživatel registrovaný Ne Zaregistrovat Ano Přihlásit Synchronizovat Provedená synchronizace 56 Obrázek C.5: Procesní diagram pro případ Synchronizace.

65 C. OBRAZOVÁ PŘÍLOHA 9. Nový úkol - lightbox Dialogové okno společné pro všechny tři akce z nástrojové lišty 2 Kontext se nabízí funkcí automatického doplnění, pokud nexistuje, vytvoří se (uživatel by se o tom měl dozvědět) 3 Projekt se buď bude vybírat, nebo by se mohl vyplňovat stejně jako kontext 4 CHOVÁNÍ NA KLIK Po kliknutí na Opakovat se zobrazí 57 Obrázek C.6: Drátěný model pro obrazovku Vytvoření nového úkolu.

66 C. OBRAZOVÁ PŘÍLOHA 2. Kontexty - vybraný Kontext do kterého úkol patří Datum do kdy je potřeba úkol splnit ( Splnit do ) Projekt do kterého úkol patří CHOVÁNÍ PRO KLIK Úkol po rozkliknutí Možnost editace detailů, uživatel nemusí ukládat ručně, to probíhá automaticky Vybraný kontext je vyznačený Datum je možné vložit v různých formátech, také se při kliknutí do input pole objeví kalendář 58 Obrázek C.7: Drátěný model pro obrazovku Vybraný kontext.