012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Návrh uživatelského rozhraní aplikace pro správu úkolu˚ D IPLOMOVÁ PRÁCE

Bc. Pavel Maˇcek

Brno, podzim 2010

Prohlášení Prohlašuji, že tato diplomová práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Vedoucí práce: doc. Ing. Jiˇrí Sochor, CSc. ii

Podˇekování Na tomto místˇe bych chtˇel podˇekovat doc. Jiˇrímu Sochorovi za jeho cenné rady a nadhled bˇehem konzultací. Dále chci podˇekovat Lucii Tokárové, Ondˇreji Válkovi, své rodinˇe a Darkovi Koˇcárovi za jejich obrovskou podporu.

iii

Shrnutí Cílem práce je prostudovat postupy používané pˇri návrhu grafického uživatelského rozhraní desktopových aplikací a pˇredvést vybrané postupy pˇri návrhu konkrétního programu. Student prozkoumá ruzné ˚ 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 úkolu˚ založeného na metodice GTD (z anglického „Get Things Done“). Výstupem práce budou testovací prototypy vysoké úrovnˇe a grafický návrh aplikace.

iv

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

v

Obsah 1

2

3

4

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Desktopové aplikace . . . . . . . . . . . . . . . . . . . . . . 1.2 GTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tvorba uživatelského rozhraní v malém týmu . . . . . . . . . . 2.1 Orientace na uživatele vs. Orientace na funkcionalitu . . . 2.2 Goal-Directed Design . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Potˇreby uživatele . . . . . . . . . . . . . . . . . . . . 2.2.2 Identifikace cílu˚ . . . . . . . . . . . . . . . . . . . . . 2.2.3 Proces návrhu . . . . . . . . . . . . . . . . . . . . . . 2.2.4 Goal-Directed Design vs. Activity-Centered Design 2.3 Role designéra uživatelského rozhraní . . . . . . . . . . . . 2.3.1 Informaˇcní architekt . . . . . . . . . . . . . . . . . . 2.3.2 Interakˇcní designér . . . . . . . . . . . . . . . . . . . 2.3.3 Výzkumník uživatelu˚ . . . . . . . . . . . . . . . . . 2.3.4 Visuální designér . . . . . . . . . . . . . . . . . . . . Uživatel a uživatelské rozhraní . . . . . . . . . . . . . . . . . . . 3.1 Lidské charakteristiky duležité ˚ pro design . . . . . . . . . . 3.1.1 Pamˇet’ . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Visuální vnímání . . . . . . . . . . . . . . . . . . . . 3.1.3 Pozornost . . . . . . . . . . . . . . . . . . . . . . . . 3.1.4 Cyklus lidské aktivity . . . . . . . . . . . . . . . . . 3.1.5 Lidská chyba . . . . . . . . . . . . . . . . . . . . . . 3.2 Mentální model . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Zkušenost uživatelu˚ . . . . . . . . . . . . . . . . . . . . . . Proces tvorby GUI v malém týmu . . . . . . . . . . . . . . . . . 4.1 Výzkum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Úvodní specifikace . . . . . . . . . . . . . . . . . . . 4.1.2 Konkurenˇcní analýza . . . . . . . . . . . . . . . . . . 4.1.3 Uživatelský výzkum . . . . . . . . . . . . . . . . . . 4.1.3.1 Kvalitativní . . . . . . . . . . . . . . . . . . 4.1.3.2 Kvantitativní . . . . . . . . . . . . . . . . . 4.2 Analýza a specifikace . . . . . . . . . . . . . . . . . . . . . . 4.2.1 Afinní diagramy . . . . . . . . . . . . . . . . . . . . 4.2.2 Persony . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Specifikace požadavku˚ . . . . . . . . . . . . . . . . . 4.3 Návrh interakcí . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Diagram pˇrípadu˚ užití . . . . . . . . . . . . . . . . . 4.3.2 Procesní diagramy . . . . . . . . . . . . . . . . . . . 4.3.3 Skicování . . . . . . . . . . . . . . . . . . . . . . . . 4.3.4 Drátˇené modely . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 1 3 4 4 4 5 5 5 5 6 6 6 6 7 7 7 8 9 9 10 11 11 13 13 14 14 15 15 16 16 17 18 19 19 20 21 21 22 vi

4.3.5 Prototypy . . . . . . . . . . . . . . . . . 4.3.6 Návrhové vzory . . . . . . . . . . . . . 4.4 Vizuální návrh . . . . . . . . . . . . . . . . . . . 4.4.1 Vizuální styl . . . . . . . . . . . . . . . . 4.4.1.1 Barevná paleta . . . . . . . . . 4.4.1.2 Písmo . . . . . . . . . . . . . . 4.4.1.3 Grafické prvky . . . . . . . . . 4.4.1.4 Animace . . . . . . . . . . . . 4.4.2 Ikonografie . . . . . . . . . . . . . . . . 4.4.3 Grafické návrhy obrazovek . . . . . . . 4.5 Vyhodnocení . . . . . . . . . . . . . . . . . . . . 4.5.1 Heuristická analýza . . . . . . . . . . . 4.5.2 Uživatelské testování . . . . . . . . . . . 5 Tvorba GUI programu pro organizaci úkolu˚ . . . . 5.1 Výzkum . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Úvodní specifikace . . . . . . . . . . . . 5.1.2 Konkurenˇcní analýza . . . . . . . . . . . 5.1.3 Uživatelský výzkum . . . . . . . . . . . 5.1.3.1 Pruzkum ˚ . . . . . . . . . . . . 5.1.3.2 Rozhovory . . . . . . . . . . . 5.2 Analýza a specifikace . . . . . . . . . . . . . . . 5.2.1 Afinitní diagramy . . . . . . . . . . . . . 5.2.2 Persony . . . . . . . . . . . . . . . . . . 5.2.3 Specifikace požadavku˚ . . . . . . . . . . 5.3 Návrh interakcí . . . . . . . . . . . . . . . . . . 5.3.1 Diagram pˇrípadu˚ užití . . . . . . . . . . 5.3.2 Skicování . . . . . . . . . . . . . . . . . 5.3.3 Drátˇené modely . . . . . . . . . . . . . . 5.3.4 Prototyp . . . . . . . . . . . . . . . . . . 5.3.4.1 Pˇreskládání úkolu˚ tažením . . 5.3.4.2 Našeptávaˇc . . . . . . . . . . . 5.3.4.3 Nástroje pro tvorbu prototypu 5.4 Vizuální návrh . . . . . . . . . . . . . . . . . . . 5.4.1 Grafické návrhy obrazovek . . . . . . . 5.4.2 Ikonografie . . . . . . . . . . . . . . . . 5.5 Vyhodnocení . . . . . . . . . . . . . . . . . . . . 5.5.1 Uživatelské testování . . . . . . . . . . . 5.5.1.1 Testování ve fázi skic . . . . . 5.5.1.2 Testování prototypu . . . . . . 6 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . A Obsah CD . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23 25 26 26 26 27 27 27 27 28 28 29 30 31 31 31 32 33 33 34 34 34 35 36 36 36 37 38 39 39 40 40 42 42 43 44 44 44 44 46 48 49 vii

B Pokyny ke spuštˇení prototypu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C Obrazová pˇríloha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50 51

viii

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ˇcuji duležité ˚ cˇ ásti, které by nemˇeli pˇri vývoji orientovaném na uživatele chybˇet. Teoretické studium prakticky aplikuji pˇri tvorbˇe GUI1 programu Done – aplikace pro organizaci úkolu˚ podle metody GTD (z anglického „Get Things Done“). Jedná se o program urˇcený jednotlivcum, ˚ který pomáhá s organizací osobních i pracovních úkolu˚ a povinností. V práci se zabývám pouze tˇemi fázemi vývoje, které se pˇrí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ˇekteré dokumenty (pˇrípady užití) v tˇechto fázích použít. Vycházím pˇrevážnˇe z anglické literatury a primárních zdroju, ˚ sekundární zdroje využívám pouze jako doplnující. ˇ

1.1

Desktopové aplikace

Termín desktopová aplikace nebo desktopový software se používá u programu˚ urˇcených pro osobní poˇcítaˇce a notebooky. Kromˇe programu˚ urˇcených pro desktop jsou v dnešní dobˇe rozlišovány ještˇe webové a mobilní aplikace. Samostatnou skupinu tvoˇrí i tzv. integrované systémy (z anglického „Embedded Systems“), které jsou používané napˇríklad ve spotˇrební elektronice a prumyslových ˚ zaˇrízeních. Desktopové aplikace je dále možné dˇelit podle jejich úˇcelu, použitého vzhledu a množˇ ství cˇ asu, jaké uživatel s programem stráví [5]. Tyto charakteristiky významnˇe ovlivnují 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 cˇ asu vytvoˇrená Davidem Allen. Podle Allena není cˇ lovˇek uzpusoben ˚ tomu, aby si pamatoval všechny úkoly a závazky [2]. Proto navrhuje využití systému seznamu, ˚ ve kterém jsou tyto úkoly uloženy, a na který se muže ˚ cˇ lovˇek ˇ ˇ spolehnout. Cinnosti se cˇ ásteˇcnˇe automaticky pˇripomínají, pokud je tˇreba je vykonat. Clovˇ ek na nˇe tedy nemusí myslet. Následující diagram popisuje proces organizace úkolu˚ podle GTD: 1.

Grafické uživatelské rozhraní (z anglického „Graphical User Interface“).

1

1.2. GTD

Záležitosti

Schránka

Co je to?

Je to realizovatelné?

Ne

Koš

Někdy/možná

Ano

Projekty (plánování)

Více kroků

(termínový pořadač)

Jaký bude další krok?

Informace (k vyhledání kdykoliv bude potřeba)

Projektové plány

Jeden krok

(zhodnotit další kroky)

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

Kalendář

Další kroky

(… na práci někoho dalšího)

(udělat v určitý čas)

(udělat v nejbližší době)

2

Obrázek 1.1: Diagram procesu organizace úkolu˚ podle metody GTD.

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é cˇ ásti popsány pro projekty v podnikovém sektoru. Takové prostˇredí se svými prostˇredky a cíli výraznˇe liší od malého nezávislého týmu vyvíjejícího pro koncového uživatele. Pro malý tým je cˇ asté, že ˇ eji také dochází k zanedbávání principu˚ náse ruzné ˚ role v projektu spojují a prolínají. Castˇ vrhu orientovaného na uživatele, jelikož je k dispozici ménˇe zdroju. ˚ Je tedy duležité ˚ vybrat vhodné metodiky, aby náklady na vývoj byly co nejmenší a pˇrínos orientace na uživatele co nejvˇetší. Pro potˇreby této práce definuji malý tým jako pracovní skupinu s velikostí do pˇeti cˇ lenu. ˚ Jeho souˇcástí je kromˇe programátoru˚ a projektového manažera i designér uživatelského rozhraní. Mezi cˇ asté charakteristiky takového týmu patˇrí: [9] •

Dochází ke spojení a prolínání týmových rolí

•

Je velmi cˇ astá úzká spolupráce mezi jednotlivými cˇ leny

•

Je cˇ asté použití ad-hoc postupu˚ namísto formálních metodik

•

Není pravdˇepodobná vysoká hierarchizace Z tˇechto vlastností je možné usuzovat, že:[9]

•

Existují menší nároky na dokumentaci, kterou pˇripravuje designér pro vývojáˇre

•

Vzrustá ˚ duležitost ˚ dobrých mezilidských vztahu˚

•

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 projektu˚

•

Je cˇ astý vývoj pro koncového uživatele

Tyto charakteristiky ovlivnují ˇ výraznˇe proces návrhu rozhraní. Použité metody musí být iterativní, nesmí spoléhat zbyteˇcnˇe na dokumentaci a musí dovolovat velkou variabilitu. Metodiky se u malých projektu˚ vyskytují zˇrídka ve své cˇ isté podobˇe [17], proto je duležité ˚ použít postup dostateˇcnˇe flexibilní, který je možné pˇrizpusobit ˚ konkrétnímu projektu. Dokumentace musí být jednoduše srozumitelná pro všechny cˇ leny týmu. 3

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ˇres tˇricet let. I pˇresto poˇrád pˇrevažuje vývoj zamˇerˇ ený slepˇe na funkcionalitu programu místo na potˇreby uživatele [5]. V podnikovém sektoru muže ˚ být úspˇešná i aplikace, která neplní cíle uživatelu, ˚ ale plní obchodní cíle spoleˇcnosti. Pˇri vývoji pro koncového uživatele musí úspˇešná aplikace rˇ ešit problémy uživatelu, ˚ ne zadavatele, obchodního zástupce, nebo programátora. Jinak by si uživatelé program nekoupili a nepoužívali. Obecnˇe známým a z cˇ ásti pravdivým faktem je, že orientace na uživatele je drahá [3]. Aktivity uživatelského výzkumu, prototypování a podobnˇe, vyžadují mnoho cˇ asu a prostˇredku. ˚ Proto se nabízí otázka, zdali se toto úsilí navíc vyplatí. Existuje nˇekolik duvod ˚ u˚ proˇc je duležité ˚ intenzivnˇe se zajímat o potˇreby budoucích uživatelu: ˚ Použitelnost a efektivita Tyto vlastnosti jsou pro interaktivní systémy velmi duležité. ˚ Zejména pro aplikace urˇcené koncovému uživateli. Nezahrnují pouze produktivitu, tj. rychlost s jakou uživatel provádí dané úkony, ale také pˇrijatelnost. Pˇrijatelnost oznaˇcuje, do jaké míry systém odpovídá zpusobu, ˚ jakým potenciální uživatelé pracují [3]. V pˇrípadˇe, že bude nový program výraznˇe mˇenit zpusob ˚ práce uživatelu, ˚ nebudou ho používat. Obchodní pˇrínos Jak bylo rˇ eˇceno výše, použitelná a efektivní aplikace má vˇetší šanci na oblibu mezi uživateli. To muže ˚ v koneˇcném dusledku ˚ pˇrinést vˇetší obchodní i celkový úspˇech a zvýšit ziskovost aplikace [5]. Bezpeˇcnost Ta se týká pˇredevším kritických systému, ˚ jako napˇríklad systém rˇ ízení jaderné elektrárny, navigaˇcní systémy letadel. Návrh orientovaný na uživatele muže ˚ cˇ asto zabránit neštˇestí, které je zpusobeno ˚ chybou uživatele v dusledku ˚ nepoužitelného systému. V pˇrípadˇe malých aplikací pro koncové uživatele, muže ˚ bezpeˇcnost pˇredstavovat ochranu uživatelových duležitých ˚ dat pˇred náhodným smazáním nebo poškozením. Orientace na uživatele neznamená ignorování obchodních cílu˚ a technologických limitací. Je tˇreba mezi nimi najít rovnováhu.

2.2

Goal-Directed Design

Goal-Directed Design (ˇcesky „návrh zamˇerˇ ený na cíle“) je návrh interaktivních systému˚ zamˇerˇ ený na cíle uživatelu˚ [6], s úˇcelem dosažení jejich spokojenosti a efektivity.

2.2.1

Potˇreby uživatele

Návrh zamˇerˇ ený na cíle se zamˇerˇ uje na uživatelovi potˇreby, 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ˇerem je vytvoˇrení produktu, který je obecnˇe použitelný, pˇrínosný, chtˇený, technicky zvládnutelný a obchodnˇe výnosný [5]. 4

2.3. ROLE DESIGNÉRA UŽIVATELSKÉHO ROZHRANÍ 2.2.2

Identifikace cílu˚

Cíl je nˇeco, cˇ eho chce cˇ lovˇek dosáhnout. Nemusí být na první pohled viditelný a motivuje lidské potˇreby a chování. Chování je reprezentováno aktivitami, které se dále dˇelí na jednotlivé úkoly (ˇcinnosti). Aby nedošlo k mylným pˇredstavám o cílech uživatelu, ˚ je duležité ˚ provést dukladný ˚ uživatelský výzkum. 2.2.3

Proces návrhu

Ve zkratce je možné rozdˇelit Goal-Directed Design proces na šest fází [5], které nemusí nutnˇe 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.

2.2.4

Goal-Directed Design vs. Activity-Centered Design

Protipólem Goal-Directed Design je Activity-Centered Design (ˇcesky "návrh zamˇerˇ ený na úlohy"). Je také orientovaný na uživatele, ale zajímá se o jejich chování (provádˇené úlohy– aktivity). Cíle je mnohdy obtížné identifikovat, aktivity jsou prukaznˇ ˚ ejší a jasnˇejší. Návrh zamˇerˇ ený na úlohy rˇ íká, že uživatel se muže ˚ pˇrizpusobit ˚ technologii [14] a že návrh zamˇerˇ ený na cíle muže ˚ ztroskotat na nejasnosti cílu. ˚ Oba pˇrí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ˇe z návrhu zamˇerˇ eného na cíle, upraveného pro potˇreby 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 aspektu˚ interakce uživatele s aplikací, spojuje tedy nˇekolik rolí dohromady [20]. Zahrnuje návrh informaˇcní architektury, interakˇcního a visuálního designu a zajišt’uje koherenci a konzistenci napˇríˇc tˇemito aspekty. Role, které na sebe designér rozhraní bere, závisí i od konkrétního projektu. U aplikace zamˇerˇ ené na obsah by napˇríklad pˇrevládala role informaˇcního architekta. 5

2.3. ROLE DESIGNÉRA UŽIVATELSKÉHO ROZHRANÍ 2.3.1

Informaˇcní architekt

Informaˇcní architekt je zodpovˇedný za model informaˇcní struktury, navigace a obsahové kategorizace. Tato role je duležitá ˚ pˇredevším pro návrh webových aplikací, jelikož ty jsou cˇ asto obsahového charakteru. 2.3.2

Interakˇcní designér

Interakˇcní designér je zodpovˇedný za definování chování a interakce uživatele s aplikací, od pˇrechodu˚ mezi jednotlivými obrazovkami, po interakce v rámci jedné obrazovky. Má na starosti tvorbu procesních diagramu˚ (nebo diagramu˚ aktivit), tvorbu drátˇených modelu˚ a prototypu˚ dokumentujících ruzné ˚ druhy chování programu. 2.3.3

Výzkumník uživatelu˚

Výzkumník uživatelu˚ (z anglického „User Researcher“) zprostˇredkovává informace o uživatelích a jejich potˇrebách. Tyto informace získává prostˇrednictvím uživatelského výzkumu a testování. Jeho role je potˇrebná v ruzných ˚ fázích projektu, at’ již pro získání prvotních informací o uživatelích, nebo ovˇerˇ ení a validace rozhraní v pozdˇejších stádiích projektu. 2.3.4

Visuální designér

Tato role je cˇ asto podcenována ˇ s tím, že visuální designér vytváˇrí pouze hezký kabát programu. Proto je jeho duležitost ˚ zpochybnována. ˇ Ve skuteˇcnosti má visuální designér na starost jedinou vrstvu aplikace, s kterou pˇrichází uživatel do pˇrímého kontaktu. Visuální návrh pˇrímo ovlivnuje ˇ pˇrívˇetivost a efektivitu prostˇredí, ve kterém uživatel pracuje. Návrh rozhraní je iterativní proces, ve kterém se jednotlivé fáze prolínají. Napˇríklad pˇri návrhu interakcí je nutné mít pˇrehled o poznatcích z uživatelského výzkumu. I když dojde k dukladné ˚ dokumentaci, nˇekteré znalosti (pˇredevším získané empatií) se pˇri rozdˇelení 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

Kapitola 3

Uživatel a uživatelské rozhraní Lidé jsou komplexní organizmy s mnoha atributy, které mají duležitý ˚ dopad na návrh roz˚ shrnout nˇekolik základních poznatku˚ o uživatelích a hraní [7]. Pˇred fází analýzy je duležité jejich interakci s poˇcítaˇcem. Designér uživatelských rozhraní by mˇel 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é muže ˚ zamˇerˇ it pˇri uživatelském výzkumu.

3.1

Lidské charakteristiky duležité ˚ pro design

Lidé se cˇ asto velmi liší fyzicky, mentálnˇe, úrovní vzdˇelání a poˇcítaˇcové gramotnosti. Nˇekteré charakteristiky máme však spoleˇcné a pro návrh rozhraní jsou velmi duležité. ˚ Pˇrevážná vˇetšina pravidel (dobrých praktik) pro uživatelská rozhraní vychází právˇe z tˇechto mechanizmu. ˚ Patˇrí mezi nˇe pamˇet’, vnímání (zorný úhel a periferní vidˇení), pozornost, uˇcení. Dále mají lidé obecnˇe podobný zpusob ˚ provádˇení aktivit a další spoleˇcná vlastnost je chybování. Tˇemito lidskými charakteristikami se zabývá kognitivní psychologie. 3.1.1

Pamˇet’

Lidská pamˇet’ bývá rozdˇelována na dvˇe spolupracující cˇ ásti. Krátkodobá (pracovní) pamˇet’ udržuje informace po dobu maximálnˇe tˇricet sekund a udrží pouze 3-4 kusy informace [3]. Pro udržení informací v pracovní pamˇeti je potˇreba je opakovat. Pokud neobnovíme obsah pamˇeti, po pul ˚ minutˇe se postupnˇe ztratí. Dlouhodobá pamˇet’ má neomezenou kapacitu, informace v ní mohou zustat ˚ nˇekolik minut nebo i celý život. Lidská pamˇet’ obsahuje mnoho procesu, ˚ které je duležité ˚ pochopit, aby bylo možné navrhnout dobré uživatelské rozhraní. Mezi duležité ˚ mechanizmy patˇrí „vzpomínání“ a „rozpoznání“. Vzpomínání je proces aktivního prohledávání vzpomínek za úˇcelem nalezení konkrétní informace. Pokud pouze rozhodujeme, jestli vnímaná informace odpovídá tomu, co máme v pamˇeti, pak se jedná o rozpoznání. Rozpoznání je obecnˇe jednodušší než vzpomínání. Dobrým pˇríkladem tohoto principu je nabídka písem v textovém editoru. Vˇetšina dnešních textových editoru˚ poskytuje možnost vybrat písmo z nabídky, takže není nutné si pamatovat pˇresný název písma – je využit princip rozpoznání. Dalším duležitým ˚ mechanizmem je seskupování. Tento proces lidé používají, cˇ asto neˇ vˇedomˇe, ke sdružování cˇ ástí do smysluplnˇejších celku. ˚ Castým pˇríkladem je rozdˇelení telefonního cˇ ísla na tˇri trojˇcíslí. To se pamatuje jednodušeji než 9 samostatných cˇ íslic. Proto je 7

˚ 3.1. LIDSKÉ CHARAKTERISTIKY D ULEŽITÉ PRO DESIGN dobré vytváˇret v rozhraní logické celky a tím zjednodušit orientaci uživatele. Proces kódování informací z krátkodobé pamˇeti do dlouhodobé pamˇeti se nazývá uˇcení. Proces uˇcení vyžaduje ze strany uživatele cˇ asto znaˇcné úsilí. Proto je duležité ˚ pˇri vytváˇrení rozhraní minimalizovat nutnost uˇcení. Nezvýší se tím jen produktivita. Lidé se snaží vyhnout zbyteˇcnému úsilí pˇri uˇcení, proto je nutnost nauˇcení se velkého množství informací mužu ˚ i odradit od používání systému. Proces uˇcení muže ˚ být eliminován nebo usnadnˇen pokud: [7] •

Uživatel muže ˚ použít dovednosti nabité v pˇredešlých situacích (pˇri použití jiných aplikací)

•

Uživateli je poskytnuta dostateˇcná odezva

•

Proces uˇcení je rozložen do více fází, aby nedošlo k zahlcení uživatele informacemi

Dodržení konzistence napˇríˇc rozhraním a s bˇežnˇe používanými systémovými prvky výraznˇe pomuže ˚ uživateli zorientovat se v rozhraní a zkrátí jeho seznamovací dobu. 3.1.2

Visuální vnímání

Vnímání zajišt’uje pˇrijímání informací z okolního svˇeta za úˇcelem získání jejich smyslu [7]. Je z cˇ ásti ovlivnˇeno zkušenostmi, jelikož lidé mají tendenci identifikovat vnímané objekty na základˇe vˇecí, které již znají. Typy vnímání pˇrímo souvisí s druhy lidských smyslu˚ a pˇredevším pochopení visuálního vnímání je velmi duležité ˚ pro návrh grafických rozhraní. Existuje mnoho teorií popisujících tento proces, pro návrh rozhraní jsou duležité ˚ zejména Gestalt zákony (teorie tvaru). ˚ Gestalt zákony visuálního vnímání jsou obecnˇe spoleˇcné pro všechny lidi. Netvoˇrí sice ucelenou teorii, jsou však všeobecnˇe považovány za velice duležité ˚ [3]. Je možné je velice dobˇre použít v návrhu moderních uživatelských rozhraní. Mezi Gestalt zákony patˇrí: •

Blízkost. Poukazuje na fakt, že objekty objevující se blízko sebe v prostoru nebo cˇ ase vnímá cˇ lovˇek jako objekty k sobˇe patˇrící. Pro grafické rozhraní platí, že je výhodné seskupovat pouze objekty, které k sobˇe patˇrí, a tím vytváˇret logické celky.

•

Uzavˇrenost. Uzavˇrené objekty jsou vnímány jednodušeji než neúplné nebo otevˇrené objekty. Lidská mysl dokonce doplní chybˇejí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áˇrejí skupinu nebo celek, i v pˇrípadˇe velké vzdálenosti mezi sebou. Šipky u scrollbaru tvoˇrí celek, i když jsou vzdáleny daleko od sebe.

Cíl dobrého návrhu je využít možnosti vnímání cˇ lovˇeka tak, aby obrazovka rozhraní byla rozvržena ve smysluplné a zˇrejmé podobˇe. 8

˚ 3.1. LIDSKÉ CHARAKTERISTIKY D ULEŽITÉ PRO DESIGN

Obrázek 3.1: Ukázka gestalt zákonu. ˚ Zleva: Uzavˇrenost, blízkost, podobnost, symetrie. 3.1.3

Pozornost

Pozornost je zamˇerˇ ení mentálních schopností na nˇekteré smyslové vstupy. Lidská pozornost je velice selektivní, kdyby tomu tak nebylo, cˇ lovˇek by byl zahlcen informacemi [16]. K nasmˇerování pozornosti muže ˚ dojít bud’ instinktivnˇe okolními událostmi, nebo vˇedomou koncentrací na danou vˇec. Pˇríklad instinktivního nasmˇerování je napˇríklad automatické pˇresmˇerování pozornosti na dialogové okno pˇri jeho objevení. V pˇrípadˇe vˇedomého nasmˇerování pozornosti je dulež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ˇetším úsilím roste zátˇež na uživatele a výsledkem je dˇrívˇejší únava pˇri použití systému. Napˇríklad skrytím málo využívaných ovládacích prvku˚ je možné prodloužit dobu, po kterou je uživatel schopný se soustˇredit na cˇ tený text. Aktivity, které cˇ lovˇek provádí poprvé, vyžadují cˇ asto velkou pozornost. Naopak aktivity již nauˇcené, jako napˇr. rˇ ízení auta, jsou již skoro automatické a tolik pozornosti nevyžadují. 3.1.4

Cyklus lidské aktivity

Sedmi krokový kognitivní model1 zformulovaný Donaldem Normanem popisuje, jak lidé interagují s poˇcítaˇcovými systémy. Vychází z pˇredpokladu, že akce a cˇ innosti provádˇené lidmi jsou motivovány jejich cíli. Lidské akce probíhají podle této teorie v sedmi krocích, rozdˇelených mezi fáze „provedení“ a „vyhodnocení“ [13]. Nejdˇríve se zformuje cíl, nebo-li stav, které ho se má dosáhnout. Cíl je transformován na zámˇer provést nˇejakou akci. Zámˇer je pˇreložen na sekvenci kroku˚ (akcí), které je nutné provést, aby bylo dosaženo cíle. Tyto kroky jsou poté provedeny ve vztahu k vnˇejšímu svˇetu. Výsledky akcí jsou vnímány a pochopeny. Cílem dobrého návrhu rozhraní je pomoci uživatelum ˚ projít cyklem aktivity co nejrychleji a nejpˇresnˇeji [7]. Ve fázi provedení je možné uživateli pomoci tak, že je z rozhraní jasné, jakou sekvenci kroku˚ je duležité ˚ provést, aby se dostal k požadovanému cíli. Ve fázi vyhodnocení je zase duležité, ˚ aby byl uživatel schopný rozeznat jednoduše stav systému. Pokud je nˇeco špatnˇe, uživatel musí být schopný to poznat. Napˇríklad elektrická šnˇ ura ˚ s koncovkou 1.

Z anglického „Human Activity Cycle“.

9

˚ 3.1. LIDSKÉ CHARAKTERISTIKY D ULEŽITÉ PRO DESIGN Cíle

Provedení

Vyhodnocení

Zformování záměru

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ˇe. Vˇetšinˇe lidí je hned jasné, že je nˇeco špatnˇe, pokud zapojují koncovku obrácenˇe. Normanuv ˚ model není jediný model aktivity, je ale v rámci HCI2 komunity široce pˇrijímán. 3.1.5

Lidská chyba

Lidská cˇ innost se neobejde bez obˇcasné chyby. Je to obecnˇe uznávaná spoleˇcná charakteristika všech lidí. Úkolem systému je lidským chybám zabranovat, ˇ pˇredcházet a vypoˇrádat se s nimi. Donald Norman dˇelí 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ˇedomému chování, kdy cˇ lovˇek provede automaticky cˇ innost, která v daném kontextu není vhodná. Omyl vzniká na základˇe vˇedomého zvážení a vybrání špatné možnosti. Uklouznutí je vˇetšinou systémem jednoduše detekovatelné, jelikož jde o malé chyby jako stlaˇcení špatného tlaˇcítka. Pokud je uživateli poskytnuta dostateˇcná odezva. Naopak omyl muže ˚ být vˇetší chyba, kdy došlo ke špatnému zformulování cíle aktivity uživatelem. Stává se tak na základˇe špatného rozhodnutí a vyhodnocení situace, pˇrílišného zobecnˇení a podobnˇe. Tyto chyby jsou špatnˇe rozpoznatelné, jelikož provedené akce odpovídají cíli uživatele a proto jim lze také tˇežko pˇredcházet. 2.

Human-Computer Interaction (ˇcesky „Interakce cˇ lovˇeka s poˇcítaˇcem“)

10

3.2. MENTÁLNÍ MODEL

3.2

Mentální model

Mentální model je interní reprezentace toho, jak cˇ lovˇek chápe nˇejakou vˇec nebo systém [12].Vˇetšinou neodpovídá tomu, jak daná vˇec doopravdy funguje. Uživatelé nemusí vˇedˇet o komplexnosti systému, který používají. Tato znalost jim vˇetšinou vubec ˚ nepomáhá pˇri jeho používání. Místo toho si vytvoˇrí vlastní model toho, jak systém funguje, který není založený ˇ faktech. Clovˇ ek není vˇetšinou schopný tento model popsat. Naproti tomu implementaˇcní [5] nebo také systémový [13] model detailnˇe popisuje, jak program opravdu pracuje. V pˇrípadˇe poˇcítaˇcových programu˚ odpovídá implementaˇcní model programovému kódu. Pˇri návrhu rozhraní vzniká ještˇe tzv. reprezentaˇcní model, vytvorˇ ený designérem. Dovoluje schovat pro uživatele neduležité ˚ a cˇ asto nepˇríjemné detaily a co nejvíce se pˇriblížit jeho mentálnímu modelu. Mentální model pomáhá cˇ lovˇeku pochopit, jaké kroky musí podstoupit k provedení cˇ innosti, kterou dˇelá poprvé nebo ji zapomnˇel [7]. Pokud bude uživatel pracovat poprvé s novou aplikací, bude oˇcekávat její chování a vzhled na základˇe svého mentálního modelu. Pokud se program chová v souladu s uživatelovým mentálním modelem, je možné rˇ íct o programu, že je „intuitivní“. Bude jednodušeji nauˇcitelný a použitelný. Tohoto je možné dosáhnout použitím návrhových vzoru, ˚ standardu˚ a dodržováním konzistence rozhraní. Pokud se uživateluv ˚ 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živatelu˚

V kontextu zkušenosti s danou aplikací existují tˇri obecnˇe známé typy uživatelu: ˚ zaˇcáteˇcˇ níci, pokroˇcilí a experti. Castým problémem interakˇcního designu je, jak navrhnout aplikaci ˇ pro zaˇcáteˇcníky a experty zároven. ˇ Castým neúspˇešným rˇ ešením je použití zdlouhavých pruvodc ˚ u˚ pro zaˇcáteˇcníky a skrytých hlubokých menu pro experty. Duležité ˚ je pochopit potˇreby všech tˇrí skupin uživatelu. ˚ Zaˇcáteˇcníci Zaˇcáteˇcníkum ˚ je nutné zprostˇredkovat smysl a poslání produktu a pomoci jim pˇri pˇrechodu do fáze stˇrední pokroˇcilosti. To je možné provést pomocí separátního pruvodce, ˚ ten by se však mˇel koncentrovat pouze na zaˇcáteˇcníky a mˇel by být co nejstruˇcnˇejší. Stˇrednˇe pokroˇcilý Tito uživatelé potˇrebují bezproblémový pˇrístup k nástrojum. ˚ Ideální formou nápovˇedy pro tyto uživatele jsou tzv. tooltipy. Chtˇejí se pˇri práci s programem aktivnˇe zdokonalit, cˇ asto k tomu ale nemají cˇ as. Tvoˇrí nejvˇetší skupinu uživatelu. ˚ Experti 11

˚ 3.3. ZKUŠENOST UŽIVATEL U Expertní uživatelé se konstantnˇe snaží nauˇcit více, pracovat rychleji a efektivnˇeji. 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ˇetšina uživatelu˚ jsou stˇrednˇe pokroˇcilý [5]. Skupiny zaˇcáteˇcníku˚ a expertu˚ jsou malé a nestabilní. Každý uživatel projde s novým programem fází zaˇcáteˇcníka, ale nezustane ˚ v ní dlouho. Zaˇcáteˇcníci se po urˇcité dobˇe stanou stˇrednˇe pokroˇcilými nebo pˇrestanou program používat a pˇrejdou k produktu, který se budou schopni nauˇcit. A opˇet pouze nˇekolik uživatelu˚ se dostane do expertní fáze, jelikož málo jich používá programy tak pravidelnˇe a cˇ asto, aby si konstantnˇe pamatovali expertní funkce. Proto je duležité ˚ navrhovat pro trvale stˇrednˇe pokroˇcilé uživatele, kteˇrí tvoˇrí vˇetšinu z uživatelu˚ aplikace. Cílem je tedy navrhnout rozhraní tak, aby pomohlo zaˇcáteˇcníkum ˚ stát se rychle a snadnˇe stˇrednˇe pokroˇcilými, nestálo v cestˇe stˇrednˇe pokroˇcilým, kteˇrí se chtˇejí stát experty a pˇredevším udrželo trvale pokroˇcilé uživatele spokojenými [5]. Existují pˇrípady, kdy je vhodné optimalizovat pro expertní uživatele. Do této kategorie spadají napˇríklad vývojové, vˇedecké nebo zdravotnické nástroje. Od uživatelu˚ takových aplikací se oˇcekává vysoká znalost oboru a ochota investovat znaˇcné úsilí a cˇ as do zvládnutí aplikace. Stejnˇe tak existují kategorie produktu, ˚ které je nutné navrhovat pro zaˇcáteˇcníky. Jsou to napˇríklad zaˇrízení pro seniory nebo uživatele s urˇcitým postižením.

12

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ˇrístupu Goal-Directed Design. Pˇri výbˇeru použitých metod jsem zohlednil pˇredevším pomˇer jejich cˇ asové nároˇcnosti a pˇrínosu. Upˇrednostnoval ˇ jsem pˇrehledné a rychlé pˇredání informace, pˇred rozsáhlou textovou dokumentací. Napˇríklad ve fázi návrhu interakcí používám procesní diagramy místo scénáˇru. ˚ I když se zamˇerˇ 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ˇri agilním vývoji se nˇekteré fáze mohou rozložit na nˇekolik cˇ ástí, pokud nedojde k celému návrhu rozhraní na zaˇcá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ˇcního designu je tomu stejnˇe tak. Výzkum tvoˇrí základy, o které je možné se opˇrít pˇri návrhu interakcí a hledání zamˇerˇ ení produktu. Muže ˚ být proveden i v pozdˇejších fázích, s úˇcelem podpoˇrit designéra pˇri rozhodování o správném rˇ ešení. 13

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: Cásti výzkumu. 4.1.1

Úvodní specifikace

Na zaˇcátku projektu by mˇely být urˇceny cíle projektu, rˇ ešený problém, zainteresované strany, mohou být také urˇceny obecné požadavky na produkt. Tyto cˇ innosti jsou vˇetšinou v kompetenci projektového manažera. I pˇresto muže ˚ být zapojení designéra výhodné [20], obzvlášt’ pro malý tým. K urˇcení potˇrebných informací jsou nejvhodnˇejší osobní setkání s klientem a se všemi zainteresovanými stranami. Projektový manažer (designér) na nich muže ˚ získat ruzné ˚ pohledy na potˇreby, znalosti a problémy týkající se pˇripravovaného projektu. Výsledky úvodní specifikace je vhodné shrnout v uceleném dokumentu. To platí pro klientskou práci i projekty uvnitˇr spoleˇcnosti. Pruvodní ˚ dokument by mˇel tedy shrnovat strategická rozhodnutí a muže ˚ obsahovat také technickou specifikaci, cˇ asový rozpis a oˇceˇ kávané výsledky. Casto je takový dokument nazýván design brief nebo pouze brief [17]. 4.1.2

Konkurenˇcní analýza

Konkurenˇcní analýza má dva základní cíle a í: •

Zprostˇredkovat pˇrehled o konkurenci, o tom co funguje a o tom co ne, pomoci v nalezení dobrých praktik [4]

•

Identifikovat možnosti uplatnˇení na trhu, vlastnosti, které chybí již existujícím produktum ˚ (kterými se bude vyvíjený produkt odlišovat od konkurence)

Dále muže ˚ konkurenˇcní analýza pomoci pˇri urˇcení cílové skupiny, nejen pro uživatelský výzkum. To ji cˇ iní cennou pˇredevším pro projekty urˇcené koncovým uživatelum, ˚ pro které je dobrá volba uživatelského sektoru významná. Nˇekdy bývá konkurenˇcní analýza mylnˇe používána ke zjištˇení duvod ˚ u˚ úspˇechu konkurence. 14

4.1. VÝZKUM Konkurenˇcní analýza je používána typicky na zaˇcátku a cˇ asto také v prubˇ ˚ ehu projektu. Existuje nˇekolik ruzných ˚ zpusob ˚ u˚ jak ji provést. Je možné použít klasické tabulkové seznamy porovnávající funkce dvou a více produktu. ˚ Použití série malých obrázku˚ zvaných ˚ porovnání rozložení prvku˚ na obrazovce. multiples [20] zprostˇredkovává pˇrehledný zpusob Na zaˇcátku konkurenˇcní analýzy je potˇreba urˇcit její cíl (co chceme porovnat a za jakým úˇcelem) a kritéria (podle cˇ eho porovnáváme). Cíl muže ˚ být napˇríklad: „Vytváˇríme program pro úpravu fotek amatérskými fotografy a chceme vˇedˇet, ze kterých produktu˚ mohou v soucˇ asné dobˇe uživatelé vybírat a jakými funkcemi konkurenˇcní software disponuje.“ 4.1.3

Uživatelský výzkum

Na zaˇcátku uživatelského výzkumu je duležité ˚ urˇcit cílovou skupinu uživatelu˚ a získat k ní pˇrístup. Je možné zaˇcít s provizorním urˇcením skupiny, která se postupnˇe zpˇresnuje. ˇ U cílové skupiny se rozlišují obchodní charakteristiky jako vˇek, pohlaví, geografická poloha [17] a pro návrh GUI duležitˇ ˚ ejší 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ˇekteré firmy snaží dohnat nedostatek výzkumu budoucích uživatelu˚ pomocí uživatelského testování na konci projektu. U konce je ale velmi tˇežké napravit chyby zpuso˚ bené zanedbaným výzkumem. Na druhou stranu množství dat (informací) z uživatelského výzkumu musí být zpracovatelné. Není potˇreba shromáždit více dat, než bude možné zpracovat pˇri analýze. V nákladech na uživatelský výzkum a analýzu musí být rovnováha. Bˇežnˇe rozlišované typy uživatelského výzkumu jsou kvalitativní a kvantitativní. Nejlepší výsledky je možné dosáhnout vyváženou kombinací obou zpusob ˚ u. ˚ 4.1.3.1 Kvalitativní Kvalitativní výzkum se snaží odpovˇedˇet na otázky typu "Jak?" a "Proˇc?". Z ekonomických duvod ˚ u˚ k tomu používá malý vzorek lidí. Kvalitativní metody dovolují lepší pohled na motivace, oˇcekávání a chování než metody kvantitativní. Mezi praktiky kvalitativního výzkumu patˇrí pozorování a rozhovory. Jen málo uživatelu˚ je schopno artikulovat své potˇreby správnˇe [5], ty je nutné odvodit z uživatelových výroku˚ a postoju. ˚ Proto muže ˚ být pozorování uživatele pˇri práci pˇrínosnˇejší než rozhovory. Je ale podstatnˇe nákladnˇejší (finanˇcnˇe i cˇ asovˇe). Jako ideální se jeví rozhovor, pˇri kterém je možné vidˇet uživatele pˇri práci, v jeho pˇrirozeném prostˇredí. Rozhovor Rozhovor je strukturovaná konverzace [20] s potencionálními nebo stávajícími uživateli. Muže ˚ být vedený osobnˇe, nebo telefonicky. Videokonferenˇcní hovor (napˇríklad s využitím služby Skype) poskytuje podobné výhody, jako osobní setkání, ale s nižšími náklady. Pˇresto je nejlepší vést rozhovor v prostˇredí, ve kterém uživatel bude software (produkt) používat. Rozhovor by mˇel být zamˇerˇ ený na získání následujících informací: •

Relevantní zkušenosti s podobným softwarem 15

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ˇerˇ ení informací o základních uživatelských skupinách

Kvalita rozhovoru˚ je pˇrímo úmˇerná kvalitˇe pokládaných otázek a výbˇeru úˇcastníku. ˚ Je dobré se vyhnout navádˇejícím otázkám. Úspˇešnost rozhovoru˚ hodnˇe závisí také na upˇrímnosti úˇcastníka rozhovoru (vˇedomé i nevˇedomé). V malém týmu je duležité ˚ mluvit s uživateli prubˇ ˚ ežnˇe a ovˇerˇ ovat svá rozhodnutí, zárovenˇ se nenechat svést na scestí osobními preferencemi malého procenta uživatelu. ˚ 4.1.3.2 Kvantitativní Kvantitativní metody uživatelského výzkumu jsou zamˇerˇ eny na objektivní informace získané od velkého vzorku lidí. Jsou vhodné pro získání odpovˇedí na otázky typu "Kolik?", jako napˇríklad „Kolik procent uživatelu˚ disponuje internetovým pˇripojením?“, a na ovˇerˇ ování dˇríve získaných informací. Mezi metody kvantitativního výzkumu patˇrí pruzkumy ˚ (napˇríklad ve formˇe dotazníku). Pruzkum ˚ Pruzkumy ˚ sestávají ze skupiny dobˇre vytvoˇrených a cílených otázek, které ˚ i pro získání jsou distribuovány mezi velký vzorek lidí [20]. Je možné použít pruzkumy kvalitativních informací (postoje a návyky uživatelu). ˚ V tomto pˇrípadˇe je vhodná cˇ asovˇe nenároˇcná forma a použití nenavádˇejí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: Cásti analytické fáze. 16

4.2. ANALÝZA A SPECIFIKACE Po provedení uživatelského výzkumu se musí získané informace setˇrídit a analyzovat. ˇ V této fázi se upˇresnují ˇ uživatelské profily a požadavky na aplikaci. Castou chybou v procesu vývoje je zanedbání dukladné ˚ analýzy uživatelských dat. Neuspoˇrádanou masu informací vzniklou po výzkumu je potˇreba zpracovat a pˇrevést do podoby, kterou lze prezentovat cˇ lenum ˚ týmu a klientovi. S výsledky kvalitativního výzkumu se nejlépe pracuje, pokud se nejdˇríve pˇrevedou do fyzické podoby (napˇríklad nalepovací papírky) [17]. Pˇri manipulaci s daty se tak zapojí i prostorové myšlení. Vhodnou souˇcástí analýzy je také poˇcáteˇcní roztˇrídˇení dat. To pomáhá v manipulaci s daty a pˇri identifikaci opakujících se vzoru. ˚ Bˇežné možnosti tˇrídˇení dat jsou abecednˇe, chronologicky, podle poˇctu výskytu. ˚ Postupy pro analýzu dat se liší, podle zpusobu ˚ práce s daty. Napˇríklad abstrakcí získaných informací se vytváˇrí konceptuální modely. Naopak dekompozicí provádˇený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 celku. ˚ V týmovém prostˇredí je možné použít brainstorming, skupinovou aktivitu kreativního rˇ ešení problému. ˚ Zapojení všech cˇ lenu˚ týmu je vhodné také pro zvýšení obecné duvˇ ˚ ery ve výsledky výzkumu a v práci designéra. 4.2.1

Afinní diagramy

Afinní diagram (také diagram pˇríbuznosti) je vhodným nástrojem pro uspoˇrádání velkého množství informací získaných pˇri uživatelském výzkumu1 . Pomáhá tyto informace uspoˇrádat do pˇrirozených a logických skupin, a tak objasnit strukturu a vzory v chování a postojích uživatelu. ˚ Neuspořádané informace

Afinní diagram

Skupina 1

Skupina 2

Skupina 3

Obrázek 4.4: Princip afinního diagramu. 1.

http://www.usabilitynet.org/tools/affinity.htm

17

4.2. ANALÝZA A SPECIFIKACE Oblíbeným zpusobem ˚ realizace afinních diagramu˚ je použití nalepovacích (Post-It) papírku. ˚ Nejdˇríve se relevantní výroky uživatelu˚ 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ˇrilepí na stˇenu tak, aby byli pˇrístupné celému týmu po nˇekolik dní. Poté muže ˚ zaˇcít fáze uspoˇrádání podobných výroku˚ do skupin, s cílem identifikovat trendy a vzory. Skupiny se pak pojmenují a dále strukturují. Je výhodné zaˇclenit do tohoto procesu celý tým. Pˇri sestavování afinního diagram mohou cˇ lenové týmu nenásilnou cestou získat pˇrehled o budoucích uživatelích, potenciálních funkcích a dalším smˇeru vývoje aplikace vubec. ˚ Afinní diagramy jsou vhodné i ve fázi uživatelského testování, k vyhodnocení získaných informací. 4.2.2

Persony

Persony jsou dokumenty popisující typické uživatele. Pˇredstavují zástupce takových skupin uživatelu, ˚ které jsou pro vyvíjený program relevantní a významné. Pokud jsou postaveny na dostateˇcném výzkumu, mohou zprostˇredkovat jasný obraz o budoucích uživatelích. Persony byly puvodnˇ ˚ e marketingový nástroj urˇcený k modelování motivací k nákupu [5]. Pro návrh uživatelských rozhraní jsou zamˇerˇ eny na cíle a chování uživatelu. ˚ Duvod ˚ u˚ k využití person je nˇekolik: •

Pomáhají se zamˇerˇ it na relevantní uživatele

•

Mohou pomoci týmu a klientovi udržet pozornost na motivacích a potˇrebách uživatele v prubˇ ˚ ehu projektu

•

Pomáhají vytvoˇrit empatii celého týmu s budoucími uživateli a zvýšit tak motivaci k vytvoˇrení systému, který splnuje ˇ cíle uživatelu˚

•

Díky jejich jednoduché formˇe mohou být prezentovány všem cˇ lenum ˚ týmu, klientovi, zainteresovaným osobám

•

Mohou pomoci vyˇrešit konflikty, které vznikají bˇehem návrhových a vývojových rozhodnutí

•

Pˇredstavují velmi dobrý a cˇ asto atraktivní zpusob ˚ vtažení celého týmu do výsledku˚ uživatelského výzkumu

Persony mohou snížit cˇ asové nároky na designéra. Za pˇredpokladu, že jsou persony správnˇe vytvoˇreny a pˇrijaty, mohou vývojáˇri nˇekteré problémy a detaily rˇ ešit sami, designér tedy nemusí navrhovat nutnˇe všechny interakce. To je výhodné zejména pro malý tým. ˇ Cásti, které by mˇely 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ˇreby a scénáˇre [4]. Jméno muže ˚ být reálné, nebo muže ˚ popisovat obecnou roli persony. Motivace a potˇreby persony reprezentují cíle jedné skupiny uživatelu. ˚ Scénáˇre jsou realistické pˇríklady 18

4.3. NÁVRH INTERAKCÍ interakce persony a systému. Další souˇcásti person ji mohou pomoci dotvoˇrit tak, aby byla vhodná pro urˇcené obecenstvo. Jsou to napˇríklad popis chování, citace, požadované systémové funkce a demografické informace spolu s osobním profilem. Každá persona by mˇela mít pˇridˇelenou prioritu. Primární persony reprezentují nejduležitˇ ˚ ejší uživatelskou skupinu. Persony jsou velmi užiteˇcný nástroj. Jejich kvalita je však pˇrímo úmˇerná prostˇredkum ˚ vynaloženým na uživatelský výzkum. Nejlepších výsledku˚ je dosáhnuto pˇri spojení uživatelských dat z pozorování a rozhovoru˚ [20], a online pruzkumu ˚ ze sociálních sítí. Tzv. adhoc persony je možné vytvoˇrit i bez uživatelského výzkumu, mohou sloužit jako odrazový mustek ˚ v pˇrípadˇe nedostatku prostˇredku, ˚ nebo cˇ asu. 4.2.3

Specifikace požadavku˚

Specifikace požadavku˚ není pouhý seznam funkcí, které má systém obsahovat. Slouží k definici produktu pˇred fází návrhu. Mˇela by popisovat rˇ ešený problém, koncept a vizi toho, jakým zpusobem ˚ se bude problém rˇ ešit [5]. Specifikace požadavku˚ provedená po fázi výzkumu je již dostateˇcnˇe informovaná uživatelskými daty. Je tedy možné doplnit a zpˇresnit obchodní požadavky definované na zaˇcátku projektu. Požadavkum ˚ je tˇreba pˇridˇelit priority. Z uživatelského výzkumu by mˇely mít nejvˇetší prioritu požadavky primární persony. Tyto se vyvažují s požadavky získanými bˇehem konkurenˇcní analýzy a klientu. ˚ Scénáˇre jsou vhodným, i když cˇ asto pˇríliš obsáhlým, prostˇredkem k zachycení požadavku˚ na systém. Pro potˇreby vývojáˇru˚ je nutné je dále transformovat do jednodušší (více procedurální) formy. Persony, dˇelené podle duležitosti, ˚ mohou také sloužit ke specifikaci požadavku. ˚ Neobsahují ale požadavky získané z konkurenˇcní analýzy a ze strany klienta. Další formou reprezentace požadavku˚ je seznam rozdˇelený podle priorit, doplnˇený o definici problému a vize.

4.3

Návrh interakcí

Návrh interakcí2 je postaven na syntéze principu˚ interakˇcního designu3 [5], návrhových vzoru˚ a informací získaných bˇehem analytické fáze. Pˇri výbˇeru metod návrhu interakcí jsem se soustˇredil 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ˇríklad Case Studio) nejsou pˇri návrhu GUI v malém týmu vhodné. Jsou zbyteˇcnˇe robustní a nákladné. Nástroje jako Microsoft Visio nebo Axure mohou být lepší volbou. 2. Interakce v tomto smyslu znamená komunikaci mezi cˇ lovˇekem a programem. 3. Principy interakˇcního designu jsou soubor znalostí, postoju˚ a hodnot, kterými by mˇel interakˇcní designér disponovat.

19

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: Cásti fáze návrhu interakcí.

4.3.1

Diagram pˇrípadu˚ užití

Diagram pˇrí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ˇe používaná [15]. Z pohledu softwarového inženýrství slouží k zobrazení hranice systému a jeho hlavních funkcí. Pro potˇreby interakˇcního designu je diagram pˇrípadu˚ užití zajímavý, díky své schopnosti pˇrehlednˇe modelovat interakce mezi aktéry (uživateli) a systémem. Pro designéry je diagram pˇrípadu užití dobˇre znám [17]. Diagram se skládá se z pˇrípadu˚ užití a aktéru. ˚ Aktér je externí role interagující se systémem. Pˇrípad užití je aktivita, kterou aktér muže ˚ provést. Není to pouze primitivní funkce, ale komplexní interakce s pˇredem daným cílem. Díky grafickému znázornˇení je diagram pˇrípadu˚ užití jednoduše cˇ itelný i pro laiky. Proto je vhodný pro prezentaci klientum ˚ a jako efektivní dokumentace pro cˇ leny malého týmu. Pˇri urˇcování aktéru˚ je možné vycházet z person, pokud byly v analytické fázi vytvoˇreny. Aktéry mohou být cˇ asto jen „uživatel“ a „systém“. Pro specifikaci jednotlivých pˇrípadu˚ užití se používají toky událostí, diagramy aktivit, pseudokód nebo procesní diagramy. Díky jejich flexibilitˇe a visuální reprezentaci se procesní 20

4.3. NÁVRH INTERAKCÍ diagramy jeví jako nejlepší volba pro malý tým. 4.3.2

Procesní diagramy

Procesní diagram (také vývojový diagram) slouží k názornému grafickému zobrazení posloupnosti a vzájemné návaznosti všech kroku˚ urˇcitého procesu (úlohy). Jeho použití je vhodné, pokud je potˇreba rychle a efektivnˇe naznaˇcit interakce uživatele se systémem. Procesní diagram se skládá ze sekvence kroku, ˚ které jsou propojeny cestami. Má smˇer, zaˇcátek a konec. Kroky, ve kterých dochází k vˇetvení, se nazývají „Rozhodovací body“. Procesní diagramy jsou používány interakˇcními designéry zejména pˇri návrhu webových aplikací [4], hodí se ale také pro návrh interakcí menších desktopových aplikací. Diagramy mohou být pˇrepracovány do podoby jiných, více formálních diagramu, ˚ nebo doplnˇeny scénáˇri, pokud je potˇreba pˇridat více detailu. ˚ 4.3.3

Skicování

Skicování je jeden z nejlepších pˇrirozených nástroju˚ designéra. Visuální reprezentace problému pˇredstavuje nejefektivnˇejší zpusob ˚ zaznamenání myšlenek a komunikace [16]. Žádný digitální nástroj se zatím nebyl schopen vyrovnat flexibilitˇe, rychlosti a jednoduchosti skicování na kusu papíru. Vizualizace myšlenek pˇrináší potˇrebný celkový pˇrehled pˇri rˇ ešení problému.

Obrázek 4.6: Pˇríklad prvotní skicy webového rozhraní. Autor: Pavel Maˇcek Skicování pˇri návrhu interakcí umožnuje ˇ rychlé zkoumání prvotního konceptu. Pˇríprava skic je rychlá a levná. Využití skic pˇri brainstormingu je ideální pro malý tým. Digitální ná21

4.3. NÁVRH INTERAKCÍ stroje již mají dopˇredu urˇcenou vizuální reprezentaci. Naopak skicování dává designérovi úplnou volnost a skici pusobí ˚ pˇrirozenˇe jako nedokonˇcená práce, takže nikdo nemá zapotˇrebí diskutovat o neduležitých ˚ detailech a pozornost se ubírá hlavnˇe na koncept. Skici ve formˇe malých obrázku˚ jsou obrazové scénáˇre (z anglického „storyboard“), což je koncept známý z kinematografie. Je to scénáˇr filmového zábˇeru, v pˇrípadˇe uživatelských rozhraní to je scénáˇr interakce. 4.3.4

Drátˇené modely

Drátˇený model, neboli wireframe, je statický zpusob ˚ zobrazení struktury a funkˇcního chování navrhovaného programu [20]. Vizuálnˇe popisuje jednotlivé obrazovky programu a ukazuje umístˇení navigaˇcních prvku, ˚ ovládacích prvku˚ a obsahové cˇ lenˇení. Drátˇené modely pomáhají pˇri zobrazení a odhalení vzájemných vztahu˚ jednotlivých prvku˚ obrazovky a pomocí jejich anotace lze naznaˇcit i chování programu. Drátˇené modely jsou využívány zejména pro návrh obrazovek webových a mobilních aplikací. Jako pˇredstupenˇ prototypu˚ jsou vhodné i pro desktopový software. Namísto reálného obsahu jsou drátˇené modely vyplnˇeny zástupným obsahem. Ten by mˇel být reálný, ne nesmyslný nebo generovaný [1]. Jen tak je možné navrhnout správné rozložení obsahu na obrazovce a vhodnˇe zvolit strukturu. V pozdˇejších fázích jsou zmˇeny struktury vˇetšinou drahé. Drátˇené modely mohou být hrubé, zobrazující pouze strukturu obrazovky, nebo detailní, vˇenující se i typografii a blížící se grafickému návrhu.

Obrázek 4.7: Pˇríklad drátˇeného modelu s anotací. Autor: Pavel Maˇcek 22

4.3. NÁVRH INTERAKCÍ Je možné je prezentovat vývojáˇrum, ˚ celému týmu, klientum ˚ a také budoucím uživatelum ˚ [20] a je možné nad nimi provádˇet uživatelské testování a nenákladnˇe ovˇerˇ ovat dˇríve vytvoˇrené koncepty. Klienti si mohou na základˇe drátˇených modelu˚ pˇredstavit smˇer návrhu obrazovek a nemusí cˇ ekat až na grafický návrh. Zmˇeny v drátˇených modelech jsou typicky ménˇe nákladné než zmˇeny na úrovni grafických návrhu. ˚ Vzhled drátˇených modelu˚ není nijak unifikovaný. Mˇely by používat sjednocené výrazové prostˇredky 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ˇené modely zamˇerˇ eny na strukturu a chování, je vhodné používat cˇ ernobílé schéma (odstíny šedi) a nezdržovat se výbˇerem barev nebo písma. Drátˇené modely jsou vˇetšinou doplnˇeny anotací, která popisuje strukturu, prvky na obrazovce, a jejich funkcionalitu. Neexistuje pro ni žádný formálnˇe specifikovaný zápis, ale na internetu je k dispozici nespoˇcet vzoru˚ pro ruzné ˚ platformy a typy projektu˚ 4 . Anotace popisuje jednotlivé prvky drátˇeného modelu, pravidla a interakce. Mˇela by být napsána jasnˇe a struˇcnˇe, bez možnosti dvojího výkladu. Drátˇené modely spolu s dostateˇcnou anotací mohou v nˇekterých pˇrípadech nahradit formální obchodní specifikace požadavku. ˚ 4.3.5

Prototypy

Prototyp je dynamický model vyvíjeného programu, nebo také vyjádˇrení vize interakˇcního ˚ které designéra [17]. Pˇri prototypování dochází k vytvoˇrení funkˇcního modelu z konceptu, byli zatím jen na papíˇre. Prototyp je nástroj pro ovˇerˇ ení a komunikaci konceptu˚ zamýšlených pro vyvíjený produkt. Imituje funkce a chování výsledného programu, zárovenˇ je jeho výroba nˇekolikrát levnˇejší než implementace celé aplikace. Proto muže ˚ být prototypování iterativní proces. Po vytvoˇrení prototypu probˇehne evaluace, na jejím základˇe se provedou potˇrebné zmˇeny a proces se opakuje, dokud se nedosáhne požadovaných výsledku. ˚ Druh použitého prototypu záleží na dostupných zdrojích a na typu produktu, který je vyvíjený. Podle použité úrovnˇe detailu a podobnosti s výsledným produktem se dˇelí na [3]: Nízko-úrovnový ˇ prototyp

4.

•

Sestavený rychle s omezenou funkˇcností a základním rozhraním

•

Nemá opravdovou interaktivitu, musí být nˇeký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ˇených modelu, ˚ je to asi nejrychlejší zpusob ˚ jak demonstrovat pracující produkt, výhodný pro malý tým, není pˇríliš http://wireframes.tumblr.com/

23


Obrázek 4.8: Papírový prototyp vyrobený formou šablony. Autor: Ondˇrej Válka http:// valka.info/ vhodný pro uživatelské testování •

Fóliový prototyp – obrazovky nakreslené na prusvitných ˚ fóliích a promítané zpˇetným projektorem, designér upravuje obrazovky podle interakcí s aplikací

Vysoko-úrovnový ˇ prototyp •

Vyžaduje vˇetší investici zdroju˚ a cˇ asu

•

Je plnˇe interaktivní

•

Obsahuje mnoho vlastností výsledného produktu (interakce, visuální design, funkˇcní kód)

•

Vhodný pro uživatelské testování

•

Hrozí nebezpeˇcí, že bude tento prototyp uživateli a klienty považován za finální

Prototypovat celou aplikaci muže ˚ být pˇríliš nákladné a cˇ asto to není potˇreba. Proto je dobré omezit funkcionalitu. Podle zpusobu ˚ omezení jsou rozlišovány: 24

4.3. NÁVRH INTERAKCÍ Vertikální prototyp •

Obsahuje funkcionalitu pro zvolenou cˇ ást programu

•

Dovoluje podrobné testování

Horizontální prototyp •

Simuluje vˇernˇe rozhraní

•

Nedisponuje žádnou reálnou funkcionalitou

V dnešní dobˇe je možné použít pro prototypování desktopové aplikace nástroje vývoje webových aplikací. Napˇríklad knihovna Javascript, jQuery UI5 dovoluje stejné typy interakcí jako desktopový software. S její pomocí je možné vytvoˇrit prototyp, který se dá zkompilovat jako dekstopový program (platforma Adobe Air6 ). 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ˇe dobˇre jsou vhodné k dokumentaci interakcí. S jejich použitím není potˇreba vytváˇret podrobnou dokumentaci a zárovenˇ nezustane ˚ návrh drobných interakcí na vývojáˇri. Ten by sám zvolil nejefektivnˇejšího rˇ ešení z hlediska kódu, což je cˇ asto nejhorší rˇ ešení z pohledu designu. 4.3.6

Návrhové vzory

Návrhové vzory zachycují bˇežná a ovˇerˇ ená rˇ ešení návrhových problémy. Jejich princip pochází puvodnˇ ˚ e z architektury7 . Mohou podstatnˇe zrychlit a zjednodušit proces návrhu i vývoje (použitím hotových komponent). Napˇríklad v pˇrípadˇe, že chce designér ukázat uživateli, v jakém stavu je provádˇená dlouhotrvající operace (kopírování souboru), ˚ použije standardní indikátor pokroku (z anglického „progress indicator“). Je zbyteˇcné navrhovat nové rˇ ešení již vyˇrešeného problému. Pˇresto nejsou návrhové vzory krabicová rˇ ešení. Jejich implementace se vždy trochu liší v závislosti na kontextu použití [19] a existují pˇrípady, kdy je vhodné navrhnout rˇ ešení nové. Zejména, pokud toto rˇ ešení pˇrináší výrazné zlepšení. Rozlišují se vzory struktury (napˇríklad vzor rozvržení do dvou panelu), ˚ chování (drag and drop) a vnˇejšího vystupování (aplikace zamˇerˇ ená na obsah). Speciálním pˇrípadem návrhových vzoru˚ jsou smˇernice (z anglického „Design Guidelines“), které urˇcují chování a vzhled aplikací vyvíjených pro urˇcitou platformu. Pro vývojáˇre programu˚ na platformˇe Mac OS X jsou zpracovány velmi podrobné smˇernice popisující bˇežné vzory chování a interakcí. 5. 6. 7.

http://jquery.com/ http://www.adobe.com/products/air/ Jako první popsal teorii vzoru˚ v architektuˇre Christopher Alexander ve své knize „A Pattern Language“.

25

4.4. VIZUÁLNÍ NÁVRH

4.4

Vizuální návrh

V pˇrípadˇe GUI desktopové aplikace probíhá komunikace mezi uživatelem a aplikací vizu˚ roli, álnˇe, napˇríklad pˇrímou manipulací s rozhraním [7]. Visuální návrh tedy hraje duležitou protože stojí mezi uživatelem a systémem a podílí se velkou mírou na koneˇcné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ˇechto promˇenných je možné definovat konkrétní návrh grafického uživatelského rozhraní. Dobrý visuální návrh by mˇel: •

Využívat visuálních promˇenných k seskupení objektu˚ na obrazovce a vytváˇret hierarchie

•

Zprostˇredkovat uživateli visuální strukturu a tok informací

•

Úˇcelnˇe a dukladnˇ ˚ e spojit styl a funkci rozhraní [5]

•

Vyvarovat se visuálnímu šumu

4.4.1

Vizuální styl

Visuální styl sestává z použitých barev, písma, grafických prvku, ˚ ikonografie a animací. Muže ˚ být cˇ ásteˇcnˇe urˇcen firemní identitou. To by ale nemˇelo být na úkor principu˚ visuálního návrh GUI. Barvy firemní identity nemohou urˇcovat barvy uživatelského rozhraní. Visuální styl by mˇel být konzistentní v rámci aplikace ale také v rámci operaˇcního systému. Konzistence neznamená jen stejný vzhled, ale i chování. Nˇekteré operaˇcní systémy (Mac OS X) mají visuální styl urˇcený detailnˇe a pˇrísnˇe, jiné (Microsoft Windows) mají smˇernice volnˇejší. Pro dosažení konzistentního vzhledu v rámci operaˇcního systému je duležité ˚ použití stejných metafor, návrhových vzoru˚ typických pro daný OS, stejných textur, animací. Zmˇena barevného schématu konzistenci tolik neporuší, i když je zdánlivˇe nejviditelnˇejší. K urˇcení visuálního stylu rozhraní mohou pomoci tzv. inspiraˇcní tabule (z anglického „Mood boards“). Je to zpusob ˚ zkoumání emoˇcní stránky produktu [17]. Jedná se o koláž vytvoˇrenou pomocí obrázku, ˚ barev, typografie, která by mˇela pusobit ˚ stejnˇe jako finální systém. Dˇríve používali designéˇri pro tvorbu inspiraˇcních tabulí cˇ asopisy a noviny, ze kterých vytváˇreli koláže. Dnes je možné vytvoˇrit inspiraˇcní tabule digitálnˇe a mohou obsahovat i multimédia. 4.4.1.1 Barevná paleta Použitá barevná paleta je výrazným identifikátorem visuálního stylu. Pˇri výbˇeru barevného schématu je dobré se vyhnout agresivním a komplementárním barvám. Vybrané barvy po26


Obrázek 4.9: Smˇernice popisující strukturu a vzhled dialogového okna Mac OS X. pˇredí a pozadí by mˇely být dostateˇcnˇe kontrastní. 4.4.1.2 Písmo Písmo na obrazovce by mˇelo být dostateˇcnˇe ostré s dobrou cˇ itelností a vysokým kontrastem. Pro bˇežné ovládací prvky se normálnˇe používá písmo systémové. 4.4.1.3 Grafické prvky Grafické prvky jsou z velké cˇ ásti ovlivnˇeny trendy a visuálním stylem operaˇcního systému, pro který je aplikace vyvíjena. At’ už jsou to lehké pˇrechody, nebo textura šumu, podobné grafické prvky pomáhají vytvoˇrit zamýšlený dojem z aplikace. 4.4.1.4 Animace Animace je cˇ asto používána k vytvoˇrení bezprostˇrední odezvy programu. Moderní operaˇcní systémy disponují sadou standardních animací, které by mˇely být používány konzistentnˇe v podobných situacích. Animace by mˇela být používána obezˇretnˇe a pouze v krátkých úsecích. Je to totiž výrazný prvek, který muže ˚ pˇredstavovat nežádoucí vyrušení uživatele, pokud je použit nevhodnˇe. 4.4.2

Ikonografie

Ikona je grafický symbol, který reprezentuje urˇcitý objekt nebo funkci. Má mnoho ruzných ˚ použití, v rámci grafického uživatelského rozhraní muže ˚ být symbolem pro objekty, vlastnosti objektu, ˚ akce a systémový status. Principy dobˇre utvoˇrené ikony jsou podobné jako principy dobˇre vytvoˇreného grafického rozhraní. Správnˇe vytvoˇrené ikony by mˇely být: •

Povˇedomé – mˇely by využívat známé metafory [7] 27

4.5. VYHODNOCENÍ

Obrázek 4.10: Pˇríklad vysoce stylizovaných ikon. Autor: Pavel Maˇcek •

Zˇrejmé – s jasným významem

•

Jednoduché – nemˇely by obsahovat zbyteˇcné detaily

•

Jednotné – mˇely by být sestaveny ze stejných grafických prvku˚

•

Rozlišitelné – ruzné ˚ ikony by mˇely mít dostateˇcnˇe odlišnou reprezentaci

Postup tvorby ikon by mˇel zaˇcínat u zvolení vhodné metafory. Pˇred kreslením v digitálním nástroji je dobré vytvoˇrit nˇekolik ruzných ˚ skic. Tak je možné najít nejlepší reprezentaci dané metafory. Vizuální styl ikon a jejich stylizace by mˇeli odpovídat stylu celého GUI. 4.4.3

Grafické návrhy obrazovek

Grafické návrhy obrazovek vycházejí strukturou z drátˇených modelu˚ a graficky z visuálního stylu. Je výhodné si po urˇcení visuálního stylu pˇripravit dokument shrnující barevnou paletu a základní grafické prvky. To muže ˚ pomoci pˇri kreslení jednotlivých obrazovek a zrychlit práci. K návrhum ˚ obrazovek je možné použít grafické editory jako Adobe Photoshop nebo v poslední dobˇe stále populárnˇejší Adobe Fireworks, který je pro návrh pro GUI lépe uzpu˚ soben. Grafické návrhy nemusí odpovídat pˇresnˇe drátˇeným modelum ˚ nebo prototypu. Mohou v nich být zaneseny zmˇeny rozhraní na základˇe uživatelského testování a heuristické analýzy. Zmˇeny není tˇreba dokumentovat zpˇetnˇe v drátˇených modelech. Grafické obrazovky není potˇreba navrhovat všechny. Je možné navrhnout obrazovky s unikátními prvky nebo strukturou a pro zbytek použít drátˇené modely nebo skici, podle kterých obrazovky pˇripraví vývojáˇri pˇrímo pˇri implementaci. V pˇrípadˇe úzké spolupráce designéra a vývojáˇre se tímto zpusobem ˚ ušetˇrí dost cˇ asu.

4.5

Vyhodnocení

Vyhodnocení je iterativní proces kontroly návrhových rozhodnutí. Má své místo na zaˇcátku, v prubˇ ˚ ehu, i na konci projektu. Prubˇ ˚ ežná kontrola designérových rozhodnutí je bˇehem pro28

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 duležitá. ˚ Mezi široce používané metody hodnocení aplikace – z pohledu grafického rozhraní a uživatele – patˇrí heuristická analýza a uživatelské testování. Obˇe metody jsou vhodné pro zjištˇení jiné skupiny problému˚ a mohou se tedy navzájem doplnovat ˇ a vyvažovat.

4.5.1

Heuristická analýza

Heuristická analýza je systematické vyhodnocení GUI pomocí seznamu principu, ˚ „heuris8 tik“ dobrého designu [3]. Je to detailní zhodnocení vyvíjeného programu odborníkem na interakˇcní design, za úˇcelem identifikovat potencionální problémy. Jelikož jde o hodnocení na základˇe profesní zkušenosti, kvalita získaných informací závisí pˇredevším na hodnotiteli. Heuristická analýza je v porovnání s uživatelským testováním jednoduchá na provedení a relativnˇe levná. Identifikovány jsou zejména menší chyby [7]. Naopak problémy struktury aplikace zustávají ˚ vˇetšinou neodhaleny. Heuristická analýza není vhodná pro podložení návrhových rozhodnutí, tam je nutné zapojit uživatele [21]. Pˇri provádˇení heuristické analýzy je dobré použít víc než jednoho hodnotitele (víc než 3 nemá vˇetšinou smysl). Hodnotitelum ˚ je nutné podat shrnutí projektu a seznam heuristik, ˇ na které se mají zamˇerˇ it. Cím budou mít lepší pˇrehled o programu a uživatelích, tím bude výsledek analýzy hodnotnˇejší. Analýza by mˇela probˇehnout nejlépe víckrát za sebou. Nalezené problémy musí být zdokumentovány a pˇridˇeleny k patˇriˇcným heuristikám. Po evaluaci je tˇreba sestavit kompletní seznam problému˚ a pˇridˇelit 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ˇri nedostatku zdroju. ˚ I v takovém pˇrípadˇe má význam a muže ˚ odhalit bˇežné problémy nebo zapomenuté interakce a procesy. Heuristiky je dobré si sestavit podle svých potˇreb. I pˇresto existují ucelené seznamy9 , které je možné použít.

8. 9.

Heuristika – princip vytvoˇrený na základˇe zkušenosti. http://www.useit.com/papers/heuristic/heuristic_list.html

29

4.5. VYHODNOCENÍ 4.5.2

Uživatelské testování

Uživatelské testování pomáhá ovˇerˇ it, zda se povedlo navrhnout systém, který rˇ eší problémy uživatele a naplnuje ˇ 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í (pruzkumy). ˚ Rozhovory a pozorování se používají ke zjištˇení problému˚ v interakci uživatele s programem, jeho postoju, ˚ popˇrípadˇe frustrací. Pru˚ zkum je možné použít k otestování emoˇcní odezvy. S uživatelským testováním je dobré zaˇcít již bˇehem prvních fází projektu. Testování nad papírovým prototypem je do znaˇcné míry omezující, pˇresto muže ˚ odhalit problémy v navigaci, kategorizaci obsahu a podobnˇe. Testování nad horizontálním prototypem je vhodné pro provˇerˇ 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 cˇ as“ [10]. Prubˇ ˚ ežné krátké testování s malým poˇctem uživatelu˚ je pro malý tým asi nejvýhodnˇejší. Doplnˇení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ˇreba drahé dokumentace (nahrávání). Pro testovací rozhovory je vhodné pˇripravit si testovací plán. To je sada otázek, která provede uživatele systémem. Je dobré použít neutrální a nenavádˇející otázky (stejnˇe jako u uživatelského výzkumu). Testovací plán by mˇel být sestavený podle scénáˇru, ˚ pro které byl prototyp vytvoˇren. Pˇri hledání úˇcastníku˚ pro uživatelské testování mohou posloužit persony jako vzor vhodných vlastností.

30

Kapitola 5

Tvorba GUI programu pro organizaci úkolu˚ V této kapitole názornˇe popisuji tvorbu GUI programu Done – aplikace pro organizaci úkolu˚ podle metody GTD (z anglického „Get Things Done“). Postupoval jsem podle procesu popsaného v pˇredešlé cˇ ásti této práce.

5.1

Výzkum

5.1.1

Úvodní specifikace

Na zaˇcátku jsem do úvodního dokumentu shromáždil projektovou vizi, cíle projektu a zbˇežný obchodní model (ten jsem zahrnul, jelikož cˇ ásteˇcnˇe ovlivnuje ˇ specifikaci požadavku). ˚ Nezamˇerˇ oval jsem se na detaily, jelikož jsem vˇedˇel, že se budou v prvních fázích projektu cˇ asto mˇenit. Cíle projektu Vytvoˇrit desktopovou aplikaci, která: •

Bude zamˇerˇ ená na organizaci cˇ asu (práce) podle metody GTD

•

Bude dostateˇcnˇe flexibilní pro použití individuálních modifikací GTD

•

Bude pomáhat zaˇcáteˇcníkum ˚ se základy GTD, zárovenˇ nebude brzdit pokroˇcilé uživatele

•

Bude duvˇ ˚ eryhodná, tak, aby ji uživatelé používali i k organizaci svého osobního života

•

Bude urˇcena pro Mac OS X i Microsoft Windows

Po dukladném ˚ prostudování metody GTD jsem sestavil seznam základních požadavku. ˚ Tento seznam nebyl zatím podpoˇrený uživatelským výzkumem ani konkurenˇcní analýzou. Jako základní požadavky jsem urˇcil: •

Sbˇer úkolu˚ – úkoly bude možné zaznamenat do schránky (inbox)

•

Zpracování záležitostí – úkoly bude možné tˇrídit, pˇriˇrazovat datum splnˇení, pˇriˇrazovat kontext 31

5.1. VÝZKUM •

Organizace – Úkoly bude možné organizovat do projektu˚ (podprojektu) ˚

•

Revize (Kontrola) – Pro úkoly bude možné nastavit týdenní (mˇesíˇcní) kontroly

•

Podpora rozhodováni– Informace o kontextu, projektu, a cˇ asu budou pˇrehlednˇe zobrazeny tak, aby podpoˇrili rozhodování

5.1.2

Konkurenˇcní analýza

Následnˇe jsem provedl analýzu konkurence s tˇemito cíli: •

Zjistit, jak konkurenˇcní aplikace organizují úkoly

•

Zjistit, do jaké míry je možné konkurenˇcní produkty pˇrizpusobovat ˚

•

Porovnat layout (rozložení) konkurenˇcních aplikací

•

Identifikovat základní skupiny uživatelu˚

K dosáhnutí tˇechto cílu jsem použil dva pˇrístupy. Pro získání pˇrehledu o tom, jaký layout používá konkurence, jsem vytvoˇril sérii zmenšenin.

Obrázek 5.1: Srovnání struktury konkurenˇcních programu. ˚ „Ružové“ ˚ obdélníky naznaˇcují oblast pro pˇridání nového úkolu, „ˇcerné“ znázornují ˇ oblast navigaˇcních prvku. ˚ Funkˇcní vlastnosti jsem porovnal pomocí tabulky kritérií. Použil jsem tato kritéria: •

ˇ Clenˇ ení do sekcí – bˇežné je cˇ lenˇení na schránku (inbox), projekty a kontexty. 32

5.1. VÝZKUM •

Zpusob ˚ a umístˇení vyhledávání úkolu˚ – Vyhledávání je implementováno vždy, vˇetšinou se nachází vpravo nahoˇre, a obsahuje našeptávaˇc (nebo se rovnou filtrují vypsané úkoly)

•

Zpusob ˚ delegace úkolu˚ – Možnost poslání úkolu emailem je cˇ asté rˇ ešení

•

Parametry úkolu – „Název“, „Splnit“ do a „Kontext“

•

ˇ Použití kontextu˚ – Casto bývá omezen poˇcet kontextu˚ pro jeden úkol

•

Zpusob ˚ synchronizace a ukládání dat – Možnost synchronizace více poˇcítaˇcu˚ (zaˇrízení) je velmi cˇ astá

S pomocí konkurenˇcní analýzy (a rozhovoru˚ s potenciálními uživateli) jsem identifikoval cílovou skupinu aplikace: Lidé pracující v zamˇestnáních nároˇcných na organizaci cˇ asu (IT, management, obchod, webdesign). A tˇri provizorní uživatelské typy: •

Uživatel používající GTD v papírové podobˇe – není ho potˇreba pˇresvˇedˇcit o výhodách GTD, je duležité ˚ pro nˇej pˇrinést pˇridanou hodnotu oproti papírovému rˇ ešení.

•

Uživatel používající GTD v elektronické i papírové podobˇe (pravovˇerný uživatel) – poˇcítaˇcovˇe gramotný, zavedený uživatel, který potˇrebuje pokroˇcilejší funkce.

•

Uživatel, který nepoužívá GTD metodiku, ale rád by zaˇcal – není rozhodnutý pro GTD, je duležité ˚ ho navést v prvních krocích, neztratit ho pˇrílišnou složitost.

5.1.3

Uživatelský výzkum

Cílové skupiny a provizorní uživatelské typy mi pomohli zjistit, na jaké uživatele se mám pˇri uživatelském výzkumu zamˇerˇ it. Použil jsem kombinaci kvantitativních a kvalitativních metod. Vytvoˇril jsem pruzkum ˚ ve formˇe dotazníku, zamˇerˇ ený pˇrevážné na kvalitativní informace. 5.1.3.1 Pruzkum ˚ Dotazník jsem vytvoˇril pomocí služby Google Spreadsheet1 . Díky navázání na tabulkový dokument jsem mohl využít pˇrehledného zpusobu ˚ uložení sbíraných dat. K rozšíˇrení dotazníku mezi potenciální uživatele jsem využil sociální sít Twitter. Díky tomu jsem byl schopný namíˇrit 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ˇehem pˇeti minut. Použil jsem dvˇe jazykové verze – cˇ eskou a anglickou – s úˇcelem zvˇetšit poˇcet získaných odpovˇedí. Bˇehem prvního týdne jsem posbíral více než padesát odpovˇedí pro každý z jazyku. ˚ To je pro kvalitativnˇe zamˇerˇ ený pruzkum ˚ dostateˇcný poˇcet. 1.

https://docs.google.com

33

5.2. ANALÝZA A SPECIFIKACE 5.1.3.2 Rozhovory Po poˇcáteˇcním pruzkumu ˚ jsem pokraˇcoval v rozhovorech s budoucími uživateli. I když se jednalo o rozhovory neformální, mˇel jsem pˇripravené otázky, abych se mohl zamˇerˇ it na informace, které pro mˇe byly duležité. ˚ Všechny poznatky o uživatelích jsem peˇclivˇe dokumentoval. Data z uživatelského výzkumu je možné najít v pˇríloze této práce.

5.2

Analýza a specifikace

Po shromáždˇení dostateˇcného množství informací jsem zapoˇcal jejich zpracování. Vzhledem k velkému poˇctu získaných dat jsem musel najít vhodný zpusob ˚ jejich tˇrídˇení. 5.2.1

Afinitní diagramy

Uživatele z pruzkumu ˚ jsem seskupoval pˇrímo v tabulkovém dokumentu postupným obarvováním na základˇe jejich podobných charakteristik. Nejdˇríve do provizorních skupin, následnˇe do rozpoznaných uživatelských typu. ˚ Výroky ke každé hrubˇe identifikované skupinˇe jsem roztˇrídil na funkce a chování (spoleˇcnˇe s postoji, potˇrebami a motivacemi). Podobné výroky jsem seskupil a urˇcil jsem nejˇcastˇejší chování a požadované (potˇrebné) funkce.

Obrázek 5.2: Zpracovávání uživatelského výzkumu pomocí afinních diagramu. ˚

34

5.2. ANALÝZA A SPECIFIKACE 5.2.2

Persony

Získané informace jsem modeloval ve formˇe person. Urˇcil jsem tˇri persony, které odpovídají uživatelským skupinám. U person jsem neuvádˇel demografické informace, vytvoˇril jsem pouze jejich kostru [4]. Každá persona obsahuje popis cílu, ˚ motivací a potˇreb, funkcí (které by využila) a klíˇcové scénáˇre. Kompletní dokumentace person je v obrazové pˇríloze této práce. Renata (primární) •

Používá GTD, ale ještˇe nenašla ten správný program.

•

„GTD si vedu na papíˇre nebo s pomocí ruzných ˚ programu, ˚ zatím jsem nenašla ten pravý program.“

•

Její motivace a potˇreby: Hledá program, který ji usnadní zaznamenávání a vedení úkolu˚ (oproti papírovému zápisníku). Chce dosáhnout jednoduchého vedení projektu˚ a kontextu˚ pro jednotlivé úkoly. Nechce myslet na opakující se projekty.

Eva (sekundární) •

Používá vˇernˇe metodu GTD a konkurenˇcní programy.

•

„Líbí se mi filozofie GTD a vyhovujeme mi dˇelení úkolu˚ podle kontextu.“ ˚

•

Její motivace a potˇreby: Chce mít po ruce spolehlivý nástroj pro zaznamenávání úkolu, ˚ který bude bezpeˇcnˇe uchovávat úkoly. Chce, aby manipulace se seznamy úkolu˚ byla co nejjednodušší. S programem stráví nejspíš dost cˇ asu, takže chce použitelný a vizuálnˇe pˇríjemný nástroj.

Marek (doplnující) ˇ •

Používá GTD metodiku jen v omezené míˇre.

•

„Z GTD jsem si vybral cˇ ásti, které mi vyhovují, celé mi pˇrijde pˇríliš organizaˇcnˇe nároˇcné.“ 35

5.3. NÁVRH INTERAKCÍ •

Jeho motivace a potˇreby: Nechce být striktnˇe omezený na GTD. Chce mít možnost si program pˇrizpusobit ˚ podle svých potˇreb. Nechce ztrácet cˇ as pˇrílišnou organizací. Chce zadávat úkoly tak rychle, jak jen to je možné.

5.2.3

Specifikace požadavku˚

Po zpracování uživatelského výzkumu, jsem mˇel dostatek informací, abych mohl vytvorˇ it plnohodnotnou specifikaci požadavku. ˚ Priority person jsem použil pro rozdˇelení požadavku˚ podle duležitosti. ˚ Specifikaˇcní dokument je pˇriložený v pˇríloze.

Obrázek 5.3: Zjednodušená specifikace požadavku˚ ve formˇe myšlenkové mapy. Žlutˇe jsou vyznaˇceny základní požadavky.

5.3

Návrh interakcí

Pˇri návrhu interakcí jsem se zamˇerˇ il na požadavky s vysokou a stˇrední prioritou. 5.3.1

Diagram pˇrípadu˚ užití

Diagram pˇrípadu˚ užití jsem modeloval na základˇe typických uživatelských scénáˇru. ˚ Zamˇerˇ il jsem se pouze na pˇrípady užití zahrnující uživatele. Jednotlivé pˇrípady užití jsem specifikoval pomocí procesních diagramu. ˚ Ty jsem použil místo pseudokódu, nebo diagramu aktivit. Procesní diagramy jsem zvolil z duvodu ˚ jejich pˇrehlednosti a flexibility. 36


Aplikace pro správu úkolů PU1 Sběr úkolů

«uses» PU2 Zpracování úkolů

PU4 Organizace úkolů

PU3 Vytvoření kontextu

«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ˇrípadu˚ užití.

Pˇri návrhu procesních diagramu˚ jsem nedokumentoval chybové stavy a detailní chování rozhraní. Duležité ˚ detaily v chování aplikace jsem zachytil pozdˇeji v prototypu. Pˇri definování interakcí jsem se soustˇredil pˇredevším na jejich pˇrímoˇcarost.

5.3.2

Skicování

Po zpracování všech duležitých ˚ scénáˇru˚ do podoby procesních diagramu˚ jsem zaˇcal s návrhem obrazovek. Zamˇerˇ il jsem se nejdˇríve na celkový layout. Využil jsem informace získané bˇehem analýzy konkurence a vyzkoušel jsem nˇekolik možných rozvržení obrazovky. Dva závislé panely Pro základní strukturu jsem použil návrhový vzor dvou závislých panelu˚ (z anglického „two-panel selector“) [19]. První panel slouží k výbˇeru položky a v druhém panelu se obsah vybrané položky zobrazí. Nejznámˇejším pˇríkladem tohoto vzoru 37


Obrázek 5.5: Prvotní skica rozhraní. 2 . Použití dvou závislých panelu je Pruzkumník ˚ ˚ je vhodné, pokud je uživateli prezentován seznam objektu˚ (kategorie, akce), který má vlastní obsah. Uživatel tak muže ˚ pˇrehlednˇe vidˇet strukturu zobrazovaných dat. Podmínkou použití tohoto vzoru je dostateˇcný prostor na obrazovce, což mnou vyvíjený program splnoval. ˇ Skici jsem dále zpˇresnoval. ˇ Pro umístˇení panelu˚ jsem zvolil bˇežné rˇ ešení, zejména kvuli ˚ konzistenci. Levý panel tedy obsahuje navigaci a v pravém panelu se zobrazuje obsah. Vytvoˇril jsem skici základních obrazovek a nakreslil jsem i nˇekteré duležité ˚ chování programu. Všechny skici jsem anotoval, abych zdokumentoval interakce a významné detaily.

5.3.3

Drátˇené modely

Bˇehem této fáze jsem shledal, že má snaha, navrhovat rozhraní pro dvˇe platformy souˇcasnˇe, (Microsoft Windows a Mac OS X) negativnˇe ovlivnuje ˇ duležitá ˚ návrhová rozhodnutí. Proto jsem myšlenku spoleˇcného rozhraní pro obˇe platformy opustil a zamˇerˇ il jsem se na charakteristiky operaˇcního systému Mac OS X. Drátˇené modely jsem navrhoval za úˇcelem: ˇ • Citelnˇ ejší a formálnˇejší dokumentace prvotních skic

2.

•

Jako iterace a zpˇresnˇení konceptu˚ vytvoˇrených pˇri skicování

•

Jako základ interaktivního prototypu Systémový program operaˇcního systému Microsoft Windows.

38


Obrázek 5.6: Skica schránky úkolu. ˚ Samotné drátˇené modely jsem navrhl v programu Adobe Fireworks, jelikož disponuje paletou pˇripravených systémových prvku˚ GUI a umožnuje ˇ export do aplikace Adobe Catalyst – program pro tvorbu interaktivních prototypu. ˚ Anotaci jsem pˇridal v programu Microsoft Visio, který jsem použil k dokumentaci velké cˇ ásti návrhové fáze. Bˇehem pˇrípravy drátˇených modelu˚ jsem rˇ ešil problém, jak vyznaˇcit a zaznamenat interakce jako kliknutí, hover, nebo tažení objektu. Jako nejvíce vhodný zpusob ˚ jsem urˇcil použití ikon a zvýraznˇeného popisu v anotaci. 5.3.4

Prototyp

Pro otestování základních interakcí jsem vytvoˇril horizontální prototyp, který je plnˇe interaktivní, ale provedené zmˇeny 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ˇených modelech. Kromˇe jednoduchých interakcí jsem v prototypu navrhl a vyzkoušel: 5.3.4.1 Pˇreskládání úkolu˚ tažením •

Jeden ze základních principu˚ GUI [11]

•

I když vypadá tažení objektu˚ jednoduše, je to komplexní interakce složená z více než desítky stavu˚

•

Je vhodný pro urˇcování priority úkolu, ˚ uživatel úkoly muže ˚ sám pohodlnˇe pˇreskládat podle duležitosti ˚

•

Pro úˇcely vyvíjené aplikace jsem použil tažení objektu˚ omezené na prostor seznamu 39


Obrázek 5.7: Drátˇený model pro obrazovku „Schránka“. 5.3.4.2 Našeptávaˇc •

Bˇehem vyplnování ˇ textového pole zobrazuje systém uživateli možné odpovˇedi

•

Tento princip funguje dobˇre, pokud je možné udˇelat rozumný odhad toho, co uživatel bude vyplnovat ˇ

•

Našeptávaˇc jsem použil pˇri vyplnování ˇ kontextu u úkolu˚ a ve vyhledávání

Pˇri tvorbˇe prototypu jsem se dopustil v nˇekterých pˇrípadech vˇedomé nekonzistence, abych mohl mezi sebou porovnat ruzné ˚ interakce. Pro urˇcení kontextu úkolu jsem použil textové pole s našeptávaˇcem. Díky tomu se automaticky vytvoˇrí nový kontext, pokud našeptávaˇc kontext nenajde. Pro urˇcení projektu, do kterého úkol patˇrí, jsem naopak použil výbˇer z možností (z anglického „select box“). Výhoda tohoto pˇrístupu je v jeho názornosti. Uživatel okamžitˇe ví, jaké projekty má k dispozici. 5.3.4.3 Nástroje pro tvorbu prototypu Pro tvorbu prototypu jsem zvažoval tyto možnosti: 40


Obrázek 5.8: Interaktivní prototyp. GUI Design Studio Dovoluje vytváˇret jednoduché scénáˇre a neumožnuje ˇ pˇríliš velkou interaktivitu. Zmˇena stylu˚ a vzhledu je tˇežkopádná, na druhou stranu knihovna prvku˚ je dostaˇcující. Zpusob ˚ prohlížení prototypu je nešikovný, je tˇreba instalovat speciální prohlížeˇc. Není možná recyklace prototypu. Microsoft Visio Je možné v nˇem vytvoˇrit i drátˇené modely a procesní diagramy. Interakce se v podstatˇe omezuje jen na procházení mezi jednotlivými obrazovkami. Adobe Catalyst Dovoluje import drátˇených modelu˚ z Adobe Fireworks a dokáže simulovat pomˇernˇe velkou interaktivitu. Je vhodný zejména pro prototypy omezené na jeden scénáˇr, který je možné celý inscenovat. Prototyp je možné použít jako základ aplikace vytvoˇrené na platformˇe Adobe Air. HTML + jQuery UI (JavaScript knihovna) Designérum ˚ dobˇre známé nástroje. Pˇri využití CSS frameworku˚ 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ˇril 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ˇri jednoduché implementaci. 41


5.4

Vizuální návrh

Pˇred zapoˇcetím tvorby grafických návrhu˚ jsem urˇcil základní charakteristiky visuálního stylu, které souvisí s typem programu. GUI by tedy mˇelo: •

Pusobit ˚ duvˇ ˚ eryhodnˇe, až konzervativnˇe

•

Neunavovat uživatele pˇri delším užívání programu (zejména oˇci) [5]

•

Využít co nejvˇetší plochu na obrazovce

•

Musí používat známé a lehce rozlišitelné metafory

•

Pusobit ˚ pˇrehlednˇe a vyrovnanˇe

•

Omezit použití výrazné a rušivé animace

Jako východisko visuálního stylu jsem využil smˇernice Apple HCI Guidelines, zejména v pˇrípadˇe struktury aplikace a použitých interakˇcních prvku. ˚ 5.4.1

Grafické návrhy obrazovek

Ve fázi grafického návrhu jsem se zamˇerˇ il na definování visuálního stylu aplikace. Proto jsem navrhl jen základní obrazovku. Specifické grafické prvky je možné vytvoˇrit až bˇehem implementace. Pro urˇcení struktury a hierarchie jsou dostaˇcující drátˇené modely. Grafický návrh jsem vytváˇrel 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 (Pruzkumník ˚ pro Mac OS) a zvýšit tím duvˇ ˚ eryhodnost 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ˇelovat do logických cˇ ástí (navigaˇcní prvky, nastavení, základní akce, doplnující ˇ akce). 42


Obrázek 5.10: Druhý grafický návrh.

5.4.2

Ikonografie

Ikony jsem pˇripravoval ve dvou stylových a velikostních verzích: Ikony pro nástrojovou lištu a kategorie Tyto ikony používají pomˇernˇe velkou míru detailu, stínování a odvážnˇejší barevné schéma. Pˇripravil jsem je ve dvou velikostech, 32x32 pixelu˚ a 16x16 pixelu. ˚ Obˇe velikosti jsem musel kreslit zvlášt’, abych uzpusobil ˚ míru detailu dané velikosti. Ikony pro ostatní interakce Tyto ikony používají jiný zpusob ˚ stylizace, pˇresto používají stejné tvary jako ikony pro nástrojovou lištu, aby byla dodržena konzistence. Jsou jednobarevné a jsou použité výhradnˇe pro akce. Nejdˇríve jsem ikony naˇcrtl a v nˇekolika iteracích jsem pro nˇe hledal vhodné metafory. Pro ikony jsem zvolil, stejnˇe jako pro rozhraní, styl a barevnost bˇežné pro Mac OS X. 43

5.5. VYHODNOCENÍ

Obrázek 5.11: Sada vytvoˇrených ikon.

5.5

Vyhodnocení

Heuristickou analýzu jsem provedl nad drátˇenými modely a prototypy. Uskuteˇcnil jsem heuristickou analýzu svépomocí a použil jsem kombinaci heuristik specifikovaných Nielsenem3 a Benyonem [3]. Zamˇerˇ il jsem se na problémy, které se nevážou na vizuální styl, takže zejména problémy navigace, ovládacích prvku˚ a celkové struktury aplikace. 5.5.1

Uživatelské testování

Testování jsem provádˇel v neformální podobˇe, abych minimalizoval jeho náklady. Drátˇené modely a prototyp jsem opakovanˇe diskutoval s budoucími uživateli. Jejich odezvu jsem pˇrímo zanášel do rozhraní. 5.5.1.1 Testování ve fázi skic První rozhovory s uživateli jsem vedl již bˇehem fáze skicování. Informace pˇri nich získané mi pomohli zvolit základní strukturu aplikace a rozložení ovládacích prvku. ˚ Ovˇerˇ il jsem správnost svého rozhodnutí použít dvou závislých panelu˚ a horní nástrojové lišty. 5.5.1.2 Testování prototypu Neformálnˇe jsem aplikaci testoval i na prototypu. Mohl jsem se tak soustˇredit na získání vˇetšího poˇctu názoru˚ a postoju. ˚ Nevýhodou takového postupu je špatná dokumentace takových informací. I pˇres neformální pˇrístup jsem pˇrichystal testovací scénáˇre, díky kterým se uživatel mohl soustˇredit na prototypem podporované interakce. Výhodou mnou sestaveného prototypu byla jednoduchá demonstrace. Prototyp jsem zpˇrístupnil na internetu a je 3.

http://www.useit.com/papers/heuristic/heuristic_list.html

44

5.5. VYHODNOCENÍ možné ho nainstalovat na libovolné platformˇe podporující Adobe Air (Microsoft Windows, Mac OS, nˇekteré Linux distribuce). Pˇri testování se prokázala jasná struktura aplikace, naopak pojmenování nˇekterých prvku˚ bylo problematické. Napˇríklad slovo „záležitost“ jsem v nástrojové lištˇe zamˇenil za „úkol“ na základˇe reakcí uživatelu. ˚ Z hlediska GTD je termín „úkol“ nepˇresný, termín „záležitost“ byl ale pro uživatele nejasný. Testoval jsem tyto scénáˇre: •

Vytvoˇrení nového úkolu (jak pˇres nástrojovou lištu, tak rychlím vytvoˇrením)

•

Vytvoˇrení nového kontextu

•

Vytvoˇrení nového projektu

•

Pˇreskládání úkolu˚ podle priority

•

Zvolení kontextu

•

Vytvoˇrení úkolu z projektu

•

Zrušení a editace úkolu

•

Splnˇení úkolu

45

Kapitola 6

Závˇer 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ˇredí je velmi složité udržet orientaci na uživatele a zárovenˇ nepˇrekroˇcit náklady na projekt. Postup, který jsem navrhl, se snaží vytˇežit maximum z dostupných metodik a zdroju. ˚ Praktickým výsledkem mé práce jsou podklady pro vývoj aplikace pro správu úkolu. ˚ Prototyp aplikace byl testován a ovˇerˇ en uživateli. Pˇri 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ˇe otestovat prototyp a zapoˇcít pˇrípravy k implementaci.

46

Literatura [1] 37signals, .: Getting Real, http://gettingreal.37signals.com/, 2010. 4.3.4 [2] Allen, D.: Get Things Done: The Art of Stress-Free Productivity, Viking, 2001. 1.2 [3] Benyon, D. a Turner, P. a Turner, S.: Designing Interactive Systems: People, Activities, Contexts, Technologies, Addison-Wesley, 2005. 2.1, 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, 2007. 4.1.2, 4.2.2, 4.3.2, 5.2.2 [5] Cooper, A. a Reimann, R. a Cronin, D.: About Face3: The Essentials of Interface Design, Wiley, 2007. 1.1, 2.1, 2.2.1, 2.2.3, 3.2, 3.3, 4.1.3.1, 4.2.2, 4.2.3, 4.3, 4.4, 5.4 [6] Cooper, A.: The Inmates Are Running the Asylum, Sams, 1999. 2.2 [7] Galitz, W.: The Essential Guide to User Interface Design, Wiley, 2007. 3, 3.1.1, 3.1.2, 3.1.4, 3.2, 4.4, 4.4.2, 4.5.1 [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, 2009. 4.1 [9] Jaroslav, K.: Technologie informaˇcních systému˚ (pˇrednáška), 2005. 2 [10] Krug, S.: Rocket Surgery Made Easy: The Do-It Yourself Guide to Finding And Fixing Usability Problems, New Riders, 2010. 4.5.2 [11] Scott, B. a Neil, T.: Designing Web Interfaces, O’Reilly, 2009. 5.3.4.1 [12] Nielsen, J.: Mental Models, http://www.jnd.org/dn.mss/human-centered. html, 2005. 3.2 [13] Norman, D.: The Design Of Everyday Things, Basic Books, 1988. 3.1.4, 3.1.5, 3.2 [14] Norman, D.: Human-Centered Design Considered Harmful, CACM, http://www. jnd.org/dn.mss/human-centered.html, 2006. 2.2.4 [15] Radek, O.: Objektové metody návrhu IS (pˇrednáška), 2008. 4.3.1 [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, 2009. 3.1.3, 4.3.3 [17] Saffer, D.: Designing For Interaction: Creating Innovative Applications and Devices, New Riders, 2010. 2, 4.1.1, 4.1.3, 4.2, 4.3.1, 4.3.5, 4.4.1 [18] Tidwell, J.: Designing Interfaces: Patterns for Effective Interaction Design, O’Reilly, 2006. 4.3.6, 5.3.2 47

[19] Tidwell, J.: Designing Interfaces: Patterns for Effective Interaction Design, , 2005. 4.3.6, 5.3.2 [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, 2009. 2.3, 4.1.1, 4.1.2, 4.1.3.1, 4.1.3.2, 4.2.2, 4.3.4, 4.3.4 [21] Chisnell, D.: What You Really Get From a Heuristic Evaluation, http://www.jnd. org/dn.mss/human-centered.html, 2010. 4.5.1

48

Pˇríloha A

Obsah CD Pˇriložený kompaktní disk obsahuje: •

tuto práci ve formátu PDF

•

dokumentaci a data uživatelského výzkumu,

•

úvodní specifikaci,

•

specifikaci požadavku˚ v nˇekolika iteracích a persony,

•

diagram pˇrípadu˚ užití a procesní diagramy

•

puvodní ˚ skicy,

•

drátˇené modely s anotacemi,

•

interaktivní testovací prototyp,

•

grafický návrh základní obrazovky v nˇekolika iteracích,

•

sadu detailních ikon

49

Pˇríloha B

Pokyny ke spuštˇení prototypu Pro správné spuštˇení prototypu je tˇreba nainstalovat nejdˇrívˇe platformu Adobe Air. Instalaˇcní soubory pro Adobe Air i prototyp jsou ve složce nazvané Navrh interakci. Po nainstalování se prototyp chová jako bˇežný program.

50

Pˇríloha C

Obrazová pˇríloha Diagram pˇrípadu˚ užití, vybrané procesní diagramy, vybrané drátˇené modely, persony.

51

ˇ C. O BRAZOVÁ P RÍLOHA

Diagram případů užití

Aplikace pro správu úkolů

PU1 Sběr úkolů

«uses» PU3 Vytvoření kontextu

PU2 Zpracování úkolů

«uses» PU4 Organizace úkolů

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ˇrípadu˚ užití.


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ˇrípad „Zpracování úkolu“. ˚


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ˇrípad „Vytvoˇrení projektu“.


PU6: Prohlížení úkolů


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ˇrípad „Prohlížení úkolu“. ˚


PU7: Synchronizace


Je uživatel registrovaný

Ne

Zaregistrovat

Ano Přihlásit

Synchronizovat

Provedená synchronizace

56

Obrázek C.5: Procesní diagram pro pˇrípad „Synchronizace“.

9. Nový úkol - lightbox

3

2 4

1

Projekt se buď bude vybírat, nebo by se mohl vyplňovat stejně jako kontext

CHOVÁNÍ NA KLIK Po kliknutí na „Opakovat“ se zobrazí 4

Kontext se nabízí funkcí automatického doplnění, pokud nexistuje, vytvoří se (uživatel by se o tom měl dozvědět)

Dialogové okno společné pro všechny tři akce z nástrojové lišty

3

2

1


57

Obrázek C.6: Drátˇený model pro obrazovku „Vytvoˇrení nového úkolu“.

5

2. Kontexty - vybraný

6

4

3

1

2

6

5

4

3

2

1

Datum je možné vložit v různých formátech, také se při kliknutí do input pole objeví kalendář

Vybraný kontext je vyznačený

CHOVÁNÍ PRO KLIK Úkol po rozkliknutí Možnost editace detailů, uživatel nemusí ukládat ručně, to probíhá automaticky

Projekt do kterého úkol patří

Datum do kdy je potřeba úkol splnit („Splnit do“)

Kontext do kterého úkol patří


58

Obrázek C.7: Drátˇený model pro obrazovku „Vybraný kontext“.

3

6. Kalendář - výpis

1

2 Ovládací prvky určené pro přepnutí zobrazení kalendáře (výpis/grid)

Je možné zobrazit úkoly na týden a měsíc, „Dnes“ zobrazí výpis od aktuálního dne

2

3

V řežimu „výpis“ jsou úkoly výpsány za sebou

1


59

Obrázek C.8: Drátˇený model pro obrazovku „Kalendáˇr (ve formˇe výpisu)“.


Renata (používá GTD bez konkrétní GTD aplikace) (primární) „GTD si vedu na papíře a s pomocí různých aplikací, zatím jsem nenašla ten pravý program.“

Cíle •

Mít přehled o svých, povinnostech a cílech.

•

Zbavit se nutnosti myslet na pravidelné události.

Motivace a potřeby Hledá program, který ji usnadní zaznamenávání a vedení úkolů oproti čistě papírovému řešení. Chce dosáhnout jednoduchého vedení projektů a kontextů pro jednotlivé úkoly. Nechce myslet na opakující se projekty.

Funkce •

Opakující se úlohy v kalendáři.

•

Vytvoření projektu z úkolu.

•

Archiv, kde se uchovávají již hotové úkoly.

•

Tisk seznamů.

•

Kalendář s možností zobrazení dnů, týdnů, měsíců.

•

Jednoduchý způsob vkládání nových úkolů.

•

Lokální uchovávání dat.

Scénáře Renata si poznamená úkol na lístek papíru nebo do zápisníku Moleskine. Po příchodu domů zapne počítač a úkoly z papíru a zápisníku si přepíše do programu. Zadává více úkolů najednou. Přidá k ním kontexty a papíry s úkoly zahodí. Renata si každý den na konci dne vyřadí úkoly, které splnila a přidá úkoly, které nepřidala během dne. Na konci týdne si projde seznamy úkolů, udělá kontrolu a předběžně rozhodne hlavní úkoly na další týden. Přeskládá si úkoly v kontextech.

60

Obrázek C.9: Persona Renata.


Marek (používá GTD metodiku jen v omezené míře) (doplňující) „Z GTD jsem si vybral části, které mi vyhovují, celé mi přijde příliš organizačně náročné.“

Cíle •

Vnést pořádek do svého života, ale strávit tím co nejméně času.

Motivace a potřeby 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é.

Funkce •

Rychle zadáváni úkolů, nejspíše do mobilu.

•

Podpora plánování u projektů.

•

Synchronizace s Google Kalendářem.

•

Synchronizace s mobilním zařízením.

•

Podpora plánování u projektů..

•

Poznámky u úkolů.

•

Odkazy na lokální soubory.

•

Nastavení důležitosti úkolů.

•

Použití klávesových zkratek a ovládání z klávesnice.

•

Rychlá dostupnost funkcí.

Scénáře Marek přidává úkoly během dne podle toho jak mu to vyhovuje a vyplňuje u úkolu jen to nejnutnější. Marek k úkolům přidává poznámky, které obsahují odkazy, podrobnější popis úkolu, prioritu. Marek přesouvá úkoly z inboxu do projektového stromu, vnořuje do sebe projekty a úkoly přerovnává přetahováním mezi seznamy.

61

Obrázek C.10: Persona Marek.


Eva (používá věrně metodiku GTD a konkurenční programy) (sekundární) „Líbí se mi filozofie GTD a vyhovujeme mi dělení úkolů podle kontextů.“

Cíle •

Mít přehled o svých, povinnostech a cílech.

Motivace 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šší, např. přesouváním přes drag and drop. S programem stráví nejspíš dost času, takže chce použitelný a vizuálně příjemný nástroj.

Funkce •

Funkce, která by pomohla s týdenním hodnocením.

•

Kontrolní seznam (výpis všech seznamů úkolů), přehled projektu, časové připomínky, přehled činností.

•

Poznámky u úkolů.

•

Lokální uchovávání dat.

•

Tisk úkolů podle kontextu.

•

Provázanost s mobilním zařízením.

•

Synchronizace s Google Calendar.

•

Odkazy v poznámce úkolu.

•

Zálohování.

•

Nahrávání souborů (obrázků atd.) k úkolům.

Scénáře Eva přidává úkol do schránky (inbox) a pečlivě vyplňuje u úkolů kontexty. Organizuje úkoly do projektů a z úkolů které mají víc kroků vytvoří projekty. Pravidelně prochází kontrolní seznamy.

62

Obrázek C.11: Persona Eva.

012345

Recommend Documents