Odhalení funkčnosti (karty), když uživatel zadává více dat
Předpokládejme, že máme aplikaci, ve které může uživatel přidávat své události. Aplikace má 4 hlavní funkce (reprezentované jako vodorovné karty, když se uživatel přihlásí):
- zobrazení kalendáře
- zobrazení seznamu
- zobrazení grafu
- importovat události
Karta # 2 (zobrazení seznamu) nepředstavuje nic užitečného, pokud nebyla zadána alespoň jedna událost.
Karta # 3 (zobrazení grafu) nedělá nic užitečného, pokud nebyly zadány alespoň 4 události.
Moje 2 možnosti:
- Všechny 4 karty jsou viditelné, i když je uživatel nový a do systému nebyly zadány žádné události. Užitečná zpráva na kartách # 2 a # 3 informuje uživatele, že není dostatek událostí (dat), aby tyto panely/funkce mohly zobrazit cokoli užitečného.
- Dynamicky odhalit kartu # 2, když uživatel vstoupí do své 1. události a odhalit kartu # 3, když uživatel vstoupí do své 4. události. Odhalení karet (ve skutečnosti funkce) bude provedeno s příslušnou zprávou ve tvaru "Zobrazit seznam povoleno!".
Který z nich bych si měl vybrat?
Nejsem si jistý, kterou cestu zvolit, protože se obávám, že:
- cesta 1 zamění velmi nové uživatele (kteří se právě zaregistrovali), kteří nebudou vědět, odkud začít (i když výchozí karta je # 1 a na kartách # 2 a # 3 je zpráva vysvětlující situaci)
- cesta 2 způsobí, že aplikace bude vypadat velmi prázdně pro uživatele, kteří se právě zaregistrovali. Mohlo by to být tak, že by je také zaměnilo, protože nové karty, které se objevují, se vloží mezi karty č. 1 a č. 4?
Souhlasím s tebou. Oba přístupy mají klady a zápory.
Radil bych jim vysmívat se, nebo vyvinout rychlý prototyp a otestovat ho s několika lidmi, zjistit, co si myslí! (testování, testování, testování by mělo být vaší mantrou při vývoji uživatelských rozhraní: P)
Ale podle mých zkušeností bych vám poradil, abyste menu zachovali staticky, abyste se vyhnuli možným nejasnostem pro uživatele: „Proč se menu změnilo, když jsem vložil svou Xth událost?“, „Proč to zmizelo, když jsem vymazal událost ? “. Vnitřní funkce, které jste popsali, se zdají docela jednoduché/přímočaré, ale nevidím žádnou výhodu v skrývání 2 ze 4 možností, jak se vyhnout záměně, když to již přináší nějaké záměny :)
Já bych šel s možností 1 je pravděpodobně méně matoucí. Váš nejlepší názor odborníků však přichází od uživatelů, které testujete.
Chcete odkazy na knihy pana Kruga? nebo jste si přečetli web pana Nielsena? Měl by jsi!
Možnost 1, statické karty s užitečnými zprávami, by měla fungovat dobře. Pamatujte, že vaši uživatelé nejsou hloupí. Když dostanou poučení o tom, jaká je situace (měli by mít více událostí, aby byla určitá karta užitečná), pochopí to mnohem lépe než zmatek vytvořený tím, že se karty objevují a mizí, zatímco nemají jasný důvod, proč k tomu dochází .
A naprosto druhý Joséův komentář k testování s maketami! Můžete získat nejpřesnější zpětnou vazbu od skutečných koncových uživatelů softwaru. Jen se nespoléhejte pouze na jejich názory nebo komentáře, přesvědčte se sami, jak systém používají (nebo maketa v ranném vývoji).
Nemusíte nutně mít masivní uživatelský arzenál pro neustálé testování - pokud máte spolupracovníky, můžete využít každou chvíli, testování použitelnosti v chodbě může být váš přítel a časovač.
Je to jasně číslo 1. Jednoduchý
Nebyly zadány žádné události. Vytvořit novou událost
by měl pomoci všem začínajícím uživatelům.
Postupné zveřejňování není špatné, bije „rozhraní pouze pro nováčky“ (jako průvodci), které neposkytují plynulý přechod na „expertní režim“. Musíte ji však vyrovnat stabilní stabilní navigační struktuře nejvyšší úrovně.
Nepohýbejte předměty. Přidání karet na konec je lepší než vložení do středu. Pomáhá také podpora ( "vyberte druhou kartu" ).
Zjištění závislostí: Ovládací prvky, které se vzájemně ovlivňují, by měly být na stejné stránce. Když zaškrtávací políčko [C] povolí seznam [L], musí být zaškrtávací políčko k dispozici, když uživatel hledá seznam, a seznam by se měl zobrazit/skrýt, když uživatel přepíná zaškrtávací políčko.
Udržujte logický tok: v kulturách LTR by kontrola měla ovlivňovat pouze to, co je přímo vpravo nebo pod ní.
Úvahy o údajích UE by měly vždy poskytnout jasnou cestu od případu „prázdný“ k případu „jedna datová položka“ a poté k případu „více než jedna“ datová položka.
Kromě toho se nebojte zahrnout dokumentaci do GUI! Např. v případě prázdného případu proveďte akci k vytvoření položky, ale také ukázejte, jak by to mohlo vypadat, s obrázkem nebo videem ilustrujícím bod.