Semestrální práce z předmětu návrh uživatelského rozhraní (A4M39NUR): D4
České vysoké učení technické v Praze
F3
Fakulta elektrotechnická Katedra počítačové grafiky a interakce
Hierarchické číselníky Anastasia Kuznetsova, Lebedeva Antonina
Zimní semestr, 2015
/ Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1 2 Prototyp . . . . . . . . . . . . . . . . . . . . . . . . . . . .2 2.1 Popis prototypu a jeho funkcionality . . . . . . . . . . . . . . . . . . . . . . . . . .3 2.2 Implementační problémy . . . . . . . .5 2.2.1 Software a hardware . . . . . . .5 2.2.2 Problémy a nedostatky . . . .5 2.3 State transition network . . . . . . . . .6 3 Testování. . . . . . . . . . . . . . . . . . . . . . . . . . . .7 3.1 Zadání pro participanta . . . . . . . . .7 3.2 Post-test dotazník . . . . . . . . . . . . . . .8 3.3 Scénář testování . . . . . . . . . . . . . . . . . .8 3.4 Průběh testování . . . . . . . . . . . . . . . . .8 3.4.1 Participant 1 . . . . . . . . . . . . . . .8 3.4.2 Participant 2 . . . . . . . . . . . . . . .8 3.5 Nálezy a doporučení . . . . . . . . . . . . .9 4 Dokumentace pro vývojáře . . . . . . 10 4.1 Funkční požadavky . . . . . . . . . . . . 10 4.2 User experience design. . . . . . . . . 10 4.3 Vizuální design . . . . . . . . . . . . . . . . . 10 4.4 Interakční design . . . . . . . . . . . . . . . 11
iii
Kapitola Úvod
1
Tato část semestrálního projektu je zaměřena na vytvoření Hi-Fi prototypu a jeho testování s uživateli. Na zacatku druhe kapitoly budou popsane změny, kterým jsme musely podrobit Lo-Fi prototyp po testování s uživateli v části D3. Pak se zaměříme na popis Hi-Fi prototypu a na implementační problémy se kterými jsme se setkaly při jeho tvorbě. V kapitole Testování si popíšeme průběh testování s uživateli a na základě získaných poznatků zhodnotíme prototyp. Poslední kapitola bude obsahovat dokumentaci pro vývojáře.
1
Kapitola 2 Prototyp Na základě problémů nalezených v části D3 jsme provedly řadu úprav nad Lo-Fi prototypem: 1. Tlačítko „Uložit“ má špatné rozmístení. Tlačítko „Uložit“ bylo přejmenováno na „Odeslat“ a přemístěno do bloku „Vaše specifikace produktu“. 2. Problém s chápáním bloku „Aktuální specifikace“. Blok byl přejmenován na „Vaše specifikace produktu“.
3. Problém s chápáním možností bloku „Parametry“. Po analýze testování s uživateli v části D3 jsme stanovily, že většina uživatelů měla problémy s pochopením možností které nabízí vlastní parametry. Došlo k tomu zřejmě kvůli chybnému pojmenování bloku „Parametry“. Vzhledem k tomu jsme si rozhodly změnit název daného bloku na „Upřesnění kategorie“(dále v dokumentu ale budeme i nadále používat název Parametry, daná změna se týká pouze uzivatelského rozhraní).
4. Není zřejmé, že vlastní a standartní parametry lze kombinovat. Vlastní a standardní parametry se teďka nachází ve společném bloku „Upřesnění kategorie“, přidat vlastní parametr lze pomocí tlačítka se symbolem „Plus“. Po stisknutí tlačítka se zobrazí textové políčko pro zadání vlastního parametrů. 5. Není zřejmé jak oddělovat od sebe vlastní parametry. Jak již bylo definováno výše zavedly jsme jiný způsob definování vlastních parametrů, který mimo jiné řeší i daný problém.
2
................................ 2.1
2.1 Popis prototypu a jeho funkcionality
Popis prototypu a jeho funkcionality
Vytvořený Hi-Fi prototyp pokrývá následující scénáře: specifikace produktu s konkrétními vlastnostmi(2. scénář v D2 a D3), specifikace produktu bez znalosti jeho podkategorie(3. scénář v D2 a D3). Hi-Fi prototyp umožňuje uživateli:
.. .. .. .
Vyhledat kategorii, při vyhledávání funguje našeptávač. Použití navigace pro přechod mezi kategoriemi již mohou být zapotřebí pro splnění úkolů(úkoly jsou podrobně popsány v kapitole „Testování“). Přidávat neomezený počet standardních a vlastních parametrů. Smazat všechny parametry. Odstranit vlastní parametr. Změnit kategorii na stránce „Specifikace kategorie“. Odeslat specifikaci.
Po otevření aplikace se uživateli zobrazí úvodní stránka, která obsahuje vyhledávací políčko. Vyhledávání kategorie usnadňuje našeptávač.
Obrázek 2.1. Úvodní stránka
Nebude-li hledaná kategorie nalezena, zobrazí se uživateli chybová hláška a to rovnou při zadávání.
Po vyhledání kategorie může dojít ke dvěma stavům: kategorie je příliš obecna(má v hierarchickém stromě hloubku menší než tři), kategorie je dostatečně specifika. V prvním případě se uživateli po vyhledání zobrazí seznam všech podkategorií nalezené kategorie a také políčko pro zadávání vlastních parametrů. 3
2. Prototyp
...........................................
Ve druhém případě se uživateli zobrazí jak výpis standardních parametrů nalezené kategorie tak i políčko pro zadávání vlastních parametrů.
Obrázek 2.2. Zobrazení bloku „Upřesnění kategorie“
Jak ji vidět na obrázku výše blok „ Upřesnění kategorie“ je na začátku schovaný, což by mělo poukazovat na to že daná položka je nepovinná. Proces předávání vlastních parametrů je znázorněn na obrázku níže. Jak je vidět po přidání parameter se zobrazí jako predvyplneny check box. Dané řešení dovolí uživateli jak nezávislé definovat vlastní parametry tak i rychle zrušit výběr jednoho z nich. 4
.....................................
2.2 Implementační problémy
Obrázek 2.3. Přidávání vlastních parametrů
K odeslání specifikace slouží tlačítko „Odeslat“.
Obrázek 2.4. Stránka, která se zobrazí po odeslání specifikace
2.2 2.2.1
Implementační problémy Software a hardware
Pro tvorbu HI-FI prototypu jsme použily program Justinmind Prototyper. Má příjemný vzhled a poměrně bohatou funkcionalitu. Podporuje vrstvové zobrazení prvků(v programu má název „Outline“), kde je možné měnit pořadí prvků, zanořovat se do skupin. Také program dovoluje v průběhu vytvoření prototypu schovávat prvky, které překrývají spodnější prvky. Justinmind Prototyper podporuje export do HTML, což jsme využily pro testování. 5
2. Prototyp
...........................................
2.2.2
Problémy a nedostatky
Výše zmíněný program má také několik nedostatku.
. . . .
Malé množství standardních prvků, ve srovnání s programem pro tvorbu Wireframe (Balsamiq). Například jsme měly problémy s vytvořením prvku „Navigace“), který v daném systému neexistuje. Musely jsme ho sestavit z odkazů a grafických objektů(šipka a obdélník). Blok „Expression builder“ potřebuje nápovědu ke každé funkce zvlášť a přímo v editorů. (Aktuálně je odkaz na obrovskou offline dokumentaci). Pro řešení některých funkci našeho prototypu(například našeptávače) jsme musely použít tutoriály a dokonce i ukázky hotových řešení na oficiálních stránkách programu. Při kopírování prvků s nastavenými akcemi program není schopny znovu napojit všechny závislosti(i když mají úplně stejné názvy). Takže jsme musely nastavovat vsechno znovu. Není zřejmý způsob práce s databázi(Data Master) a absence možnosti propojování mezi tabulkami.
2.3
State transition network
Na diagramu níže jsou znázorněny veškeré průchody aplikací. Hi-Fi prototyp vytvořený v dané části projektu podporuje všechny tyto průchody.
Obrázek 2.5. State transition network
6
Kapitola 3 Testování Cílem testování bylo odhalit nejasnosti v návrhu uživatelského rozhraní. Po analýze HCI problémů z předchozích části projektu a také vzhledem k úpravám, které jsme provedly na základě informací získaných z uživatelského testování v části D3 jsme dospěly k závěru otestovat následující části naše aplikace:
.. . . . .
Rozmístění tlačítka „ Uložit“ Cíl testování: umístění daného tlačítka je intuitivní. Kombinace vlastních a standardních parametrů Cíl testování: uživatel při upřesnění kategorie dokáže kombinovat vlastní a standardní parametry. Blok „ Vaše specifikace produktu“ (neboli „Aktuální specifikace“ v části D3) Cíl testování: název bloku a jeho obsah je pochopitelný. Navigace Cíl testování: uživatel dokáže stanovit hloubku vybrané kategorii a v případě potřeby změnit ji na obdobnou(na kategorii ze stejné hierarchické hloubky). Chybové stavy Cíl testování: uživatel dokáže správně interpretovat chybové stavy a zareagovat na něj. Oddělení vlastních parametrů Cíl testování: uživatel porozumí způsobu oddělení vlastních parametrů.
3.1
Zadání pro participanta
Seznámení se situací: Jste ředitelem velké firmy a uvádíte na trh nový druh zboží. Abyste se ujistili, že se dané zboží na trhu prosadí, rozhodl jste se podrobit ho marketingovému průzkumu. Našel jste firmu, která se zabývá marketingovými průzkumy. Pro objednání průzkum musíte na stránkách dané firmy vyplnit online formulář, jedným z úkolů při vyplnění formuláře je specifikovat váš produkt. 1. zadání 1. Pouze specifikujte produkt „debetní gold platební karta mastercard s možností bezkontaktní platby“ 2. Odstraňte všechna upřesňění 3. Přidejte upřesňění „mastercard“ 4. Odešlete specifikaci 2. zadání 1. Pouze specifikujte produkt „tymián(předpokládejte že kategorie daného produktu je neznámá nebo nedefinovaná)“ 2. Odešlete specifikaci 3. zadání 1. Pouze specifikujte produkt „ čokoláda s oříšky“ 2. Změňte kategorii produktu na „ sladkosti“ 3. Odešlete specifikaci
7
3. Testování
3.2
........................................... Post-test dotazník
Všem participantum po testování byl předložen post-test dotazník: 1. Zdála se Vám posloupnost kroků které jste učinil pro dosažení cílu logickou? 2. Jaký krok při průchodu aplikaci Vám dělal největší potíže? 3. Jaké zlepšení byste pro danou aplikaci navrhnul? 4. Která část aplikace se Vám líbila(pokud taková je)?
3.3
Scénář testování
Ve všech případech testování proběhlo na počítači moderátora, testování se provádělo v klidném prostředí. Nejprve participant byl seznámen s průběhem testu, pak mu byla vysvětlena forma práce s prototypem, tzn. kroky které může dělat a jak může definovat vstupní parametry(jenom říkat nahlas neboť’ v prototypu vstupní parametry již byli definované). Pak participant dostal zadání ve kterém byl seznámen s problémy a se svými úkoly. Před začátkem testování moderátor požádal uživatelé komentovat své kroky a myšlenkové pochody. Po splnění všech úkolů uživatel byl požadán o vyplnění pos-test dotazníku.
3.4 3.4.1
Průběh testování Participant 1
Jednotlivé úkoly plnil velmi rychle a bez výrazných problémů. V průběhu testování se participant setkal s následujícími problémy:
. . .
nevšimnul si možnosti odstranit všechny parametry najednou, ale odstranil je postunym odklikávaným check boxů. problém s umístěním bloku „Podkategorie“, myslel si, že se jedná o blok „Upresnění kategorie“. nepochopil, že může parametrizovat pomocí vlastních parametrů kategorií, která má hierarchickou hloubku menší než 3(zobrazuje se u ní výpis podkategorií). Navíc si myslel, že musí u dané kategorie určit její podkategorii. Odpovědi na post-test dotazník:
1. Ano 2. Při výběru kategorie „ Koření“ nebylo zřejmé, že není nutné definovat její podkategorií. 3. Blok „ Podkategorie“ zobrazovat mimo blok „ Vaše specifikace“ 4. Přidání vlastních upřesnění kategorie
3.4.2
Participant 2
Na začátku dělal chyby, nechápal co má dělat, což, jak jsme zjistily pozdeji, bylo způsobeno tím že si špatně představil kontext aplikace. Jakmile pochopil zadání - splnil všechny úkoly bez velkých problémů. Během testování měl následující problémy:
.
Na začátku participantovi nedávalo smysl tlačítko „ Přidat vlastní“ kvůli čemuž ho při plnění prvního úkolu nepoužíval. Snažil se dojít ke správnému výsledku jinou 8
......................................
. .
3.5 Nálezy a doporučení
cestou, která bohužel nikam nevedla. Po opakování zadání k danému problému již nedochazelo. Umístění bloku „Podkategorie“ se mu zdálo nelogickým, očekával zobrazení jako v prvním scénáři. Pojmenování políčka pro přidávání vlastních upřesnění nepřišlo mu vystačujícím. Navrhoval ho rozšířit na například „ Přidat vlastní upřesnění“ místo aktuálního „ Vlastní“ Odpovědi na post-test dotazník:
1. Ano 2. Rozmístění bloku „ Podkategorie“ a tlačítka „ Přidat vlastní spec.“ uvnitř tohoto bloku. Navrhoval podkategorie umístit blíž aktuální kategorii a lépe pojmenovat tlačítko. 3. Participantovi by se líbilo, kdyby byla možnost přidávat vlastní podkategorii a pak jít rovnou do ní a tam ještě žádat vlastní upřesnění. Jako další návrh byl předělat odkaz „ Smazat upřesnění“ do tvaru tlačítka, ale šedé barvy.
3.5
Nálezy a doporučení
Po testování jsme zjistili, že hlavním problémem bylo špatně rozmístění bloku „ Podkategorie“. Jako řešení je možné přemístit podkategorie přímo pod blok „ Vaše specifikace produktů“ a tlačítko „ Přidat vastni spec.“ přidat do bloku „ Upřesnění kategorie“. Další doporučení je rozšířit popis políčka pro přidání vlastních upřesnění anebo přidat nápovědu ve tvaru pop-over bloku.
9
Kapitola 4 Dokumentace pro vývojáře 4.1
Funkční požadavky
Priority požadavků jsou uvedené v hranatých závorkách.
.. .. .. .. .
Vyhledat kategorii dle jejího názvu [Vysoká] Zobrazit našeptávač s odpovídajícími kategoriemi [Vysoká] Určit hloubku kategorie v hierarchickém stromě [Vysoká] Zobrazit všechny podkategorie vybrané kategorie [Vysoká] Zobrazit standardní parametry vybrané kategorie [Vysoká] Přidat vlastní parametr [Vysoká] Zobrazit polohu v hierarchickém stromě(navigace) [Vysoká] Odeslat specifikaci [Vysoká] Zobrazit vlastní a standardní parametry [Vysoká]
4.2
User experience design
Při návrhu prototypu jsme kladly důraz zejména na jeho jednoduchost a přehlednost. Vzhledem k zaměření aplikace jsme předpokládaly, že uživatelé ji budou používat jen čas od času. Z toho vyplývá požadavek, který jsme se snažily dodržet při návrhu význam ovládacích prvků prototypu musí být zřejmý díky předchozím zkušenostem s podobným ovládáním(Google, obecný e-shop).
4.3
Vizuální design
Obrázek 4.1. Zobrazení bloku „ Upřesnění kategorie“
10
........................................
4.4 Interakční design
Jak již bylo zmíněno výše při návrhu jsme dbály na jenoduchost a přehlednost. Přehlednost byla dosáhnuta správným uspořádáním ovládacích prvků. Například blok „Upřesnění kategorie“ se musí nacházet uvnitř bloku „Kategorie“ protože se jedna o upřesňující parametry daně kategorie. Blok „Upřesnění kategorie“ je implicitně schovaný neboť se jedna o volitelnou položku. Omezily jsme počet „hlavních barev“ na dvě: světle modrou a světle šedou. Dana barevná kombinace může být zaměněna, vždycky by se ale mělo jednat o kombinaci barev světlejších odstínů.
4.4
Interakční design
Prototyp se ovládá pomoci myší a klávesnici. Většina vstupních políček se ovládá pomoci základních horkých kláves. Tato možnost je pro zkušené uživatele velmi žádaná. Také při návrhu prototypu byl kladen důraz na okamžitou odezvu systému, například v případě chybových hlásek. Aplikace již bude vycházet z daného prototypu by měla také poskytovat danou funkcionalitu neboť’ ona výrazně zkracuje čas potřebný na splnění úkolů. Naš prototyp podporuje vyhledávání jen podle přesného názvu (t.j. s diakritikou), výsledná aplikace by měla podporovat i vyhledávání podle slov bez diakritiky, což výrazně usnadní práci s aplikaci.
11
