it-swarm-eu.dev

Je lepší zabránit zakázané akci nebo zobrazit chybové hlášení / vysvětlení?

Existuje několik příkladů, takže si vyberu konkrétní, na který se zaměří otázka.

Řekněme, že uživatel může mít specifické vlastnosti (nebo oprávnění):
Správce, virtuální, externí, finanční atd.

Pro komplikace věcí mají uživatelé také různé licence - Premium, Regular, Limited atd.

Pravděpodobně uvidíte, kam to jde:
Řekněme, že uživatel s omezenou licencí nemůže být administrátorem ani mít finanční oprávnění.

Možnosti:

  • Správce jde do profilu, řekněme Zacka a vidí, že mu nemůže dovolit finanční povolení.
    Problém je v tom, že administrátorovi není jasné, proč tomu tak je (informace o licenci a oprávnění se nezobrazují na stejném místě, a i kdyby tomu tak bylo, musel by správce znát systémové pravidlo „žádná finanční oprávnění pro omezené uživatele“)
  • Správce vidí všechna povolená oprávnění (předpokládejme, že jsou implementována pomocí zaškrtávacích políček), a pouze po kliknutí se zobrazí chybová zpráva informující o tom, proč byla operace odmítnuta.
    Nyní je důvod jasný, ale administrátor musel kliknout, aby to zjistil.

Existuje způsob, jak zabránit této akci a také vysvětlit proč? Fungovalo by zakázané ovládání s popisem? Nějaké lepší nápady?

Stručně řečeno, další příklady - řekněme, že máte interaktivní graf a většinu bodů v grafu můžete přesunout, ale některé musí být nehybné. Mohli byste je nakreslit odlišně, což znamená, že je nelze přesunout (aniž by vysvětlili proč), nebo můžete nechat uživatele, aby se pokusil je přetáhnout a pak zobrazit chybovou zprávu.

27
Dan Barak

V závislosti na aplikaci často často nezobrazuji části stránky, ke kterým nemá uživatel přístup. Zdá se, že uživatelé mění práva ostatních uživatelů, takže tato metoda nemusí fungovat. Doporučuji zobrazení chybové zprávy při každém zobrazení zakázaného vstupního prvku. Uživatelé mohou být frustrovaní, když nejsou schopni provést akci, kterou očekávají. Pokud je to pouze zakázané, pravděpodobně nebude rozumět proč a jen to vezme na program. Stejně tak chcete zajistit, aby zpráva byla co nejjednodušší a věcná. Dlouhé chybové zprávy jsou často ignorovány.

12
LoganGoesPlaces

Před úplným skrytím části uživatelského rozhraní pro funkci, ke které uživatel nemá přístup, zvažte:

  1. Bude uživatel o této funkci vědět?
  2. Budou na to trávit spoustu času?
  3. Bylo by lepší, kdybyste to nechali v nějakém stavu „postižených“ spolu s popisem nebo jiným ukazatelem, aby se mohli dozvědět, proč to není k dispozici?

Zde je jednoduchý příklad. Předpokládejme, že vaše aplikace obsahuje možnost tisku. Pokud není k dispozici žádná tiskárna, měli byste úplně skrýt příkaz nabídky tisku? Způsobí to zmatek a ztrátu času, když uživatel prochází všemi nabídkami a nakonec kontaktuje tým technické podpory, který se snaží najít příkaz „print“? Bude váš tým technické podpory dokonce pochopit, že tento uživatel nevidí příkaz „print“? Vyskytnou se nezamýšlené vedlejší účinky, pokud je například tiskárna připojena, ale vypnuta, aby se šetřila energie?

Obecně se domnívám, že v mnoha případech, zejména v případech, kdy je možnost někdy dostupná, je uživatelům nejlépe poskytnuta zakázaná možnost nebo dokonce povolená možnost, která zobrazí chybovou zprávu vysvětlující, proč tato možnost není aktuálně k dispozici.

35
Joel Spolsky

Vidím dva různé přístupy.

Pokud jsou akce zakázány z důvodu security, pokusil bych se je ve skutečnosti vůbec odstranit. Snadné s položkami nabídky nebo většinou tlačítek na panelu nástrojů.

Pokud jsou akce zakázány, protože máte levnější verzi softwaru, nechal bych je přítomen, ale zakázán. Uživatel tak bude vědět, že „byste to mohli mít, kdybyste zaplatili více“, zatímco kdyby to bylo odstraněno, nevěděl by, co chybí. Okno „nemůžete udělat kvůli licenci“ považuji za špatné uživatelské rozhraní, protože uživatel nemůže zjistit, zda může provést akci, aniž by se akci skutečně pokusil provést.

8
shemnon

Dalším přístupem je neukazovat akci vůbec.

Stack Exchange je toho dobrým příkladem. Pokud nemám práva upravovat příspěvky ostatních lidí, nevidím odkaz „upravit“ vůbec. To znamená, že se na to nesnažím kliknout a přemýšlím, proč to nefunguje.

To nemusí fungovat za všech okolností, ale ve vašem příkladu by se možnosti/odkazy „admin“ a „finanční“ nezobrazovaly pouze pro omezené uživatele - dokonce i na obrazovkách administrátorů pro tyto uživatele. Pokud byl uživatel změněn na běžného nebo prémiového uživatele, objeví se tyto možnosti/odkazy.

Pak byste mohli zvážit zobrazení typu uživatele někde na polovině prominentní, aby si administrátor mohl připomenout, proč některé možnosti/odkazy nejsou viditelné!

7
ChrisF

Jak uvedly jiné odpovědi, pokud uživatel nemá oprávnění k provedení akce v systému (jako v, žádná oprávnění pro úpravy/správu), akce by se neměla zobrazit vůbec.

V případech, kdy jsou akce zakázány z důvodu stavu aplikace (nelze upravovat soubor jen pro čtení, nelze kopírovat/vložit, pokud není vybrán žádný text, má uživatel zkušební verzi softwaru, která postrádá několik funkcí atd.) Osobně myslíte, že by akce měla být zobrazena, s vizuální indikací, že akci nelze aktuálně provést. Všimněte si, že neříkám „zakázáno“, protože pokud uživatel zkusí tuto akci, měl by být schopen zjistit, proč to není možné. Tímto způsobem může uživatel vidět, že akce je zakázána, ale může také dostat zprávu s vysvětlením proč.

Byl bych opatrný v případě, kdy má uživatel zkušební/nedostatečně licencovanou verzi aplikace, která postrádá funkce. Například, pokud jste měli aplikaci pro čtení a zápis ISO, která by neroztrhla CD, pokud jste za ni nezaplatili, mohli byste zobrazit možnost „roztrhnout CD“, ale nenechat uživatele provést ji. Pokud však vaše aplikace obsahuje celou sadu funkcí v jejich vyšších verzích (například v vizuálním studiu), pak by zobrazení všech těchto věcí, ale jejich nedovolení, mohlo být pro uživatele frustrující. Nechci otevřít svůj IDE a vidět databáze, síťování, integrovaný UML, testování, profilování atd.), Když vím, že vše, na co mám v této licenci licenci, je psaní a vytváření projektů. .

6
Carson Myers

Moje pravidlo je: Pokud akce není uživateli dostupná z důvodu oprávnění, není viditelná. Pokud akce není k dispozici z důvodu dočasného kontextu (toto tlačítko „Uložit“ nemá význam, dokud uživatel nezadá něco, co se má uložit), je deaktivována.

„Oprávnění“ se vztahuje na „administrátora vs běžného uživatele“ i „prémiovou licenci vs levnou licenci“. Nepoužitelné prvky uživatelského rozhraní jsou nepřehledné - není to způsob, jak propagovat vaše další funkce.

Zdá se, že mnoho odpovědí má toto právo, prostě to chtělo shrnout do jedné z Nielsenovy heuristiky, která na to přesně poukazuje. Uvádí:

Prevence chyb Ještě lepší než dobré chybové zprávy je pečlivý návrh, který na prvním místě zabraňuje výskytu problému. Odstraňte buď podmínky náchylné k chybám, nebo je zkontrolujte a poskytněte uživatelům možnost potvrzení, než se k akci připojí.

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

4
Nacho

Opravdu se mi líbí odpověď shemnonova . Rozšířil bych jeho druhý případ a použil ignorované Nielsenovo přikázání; pokud má uživatel levnější licenci, zakázal bych možnost a nahradil objekt výběru ikonou, která dále objasňuje stav zakázané možnosti.

Něco jako

  • O Možnost 1
  • O Možnost 2
  • alt text Možnost 3
  • O Možnost 4

Vzhledem k tomu, že se tento předpokládaný produkt stále vyvíjí, zahrnul bych na stejnou stránku také alespoň prohlášení o úrovni licence uživatele. Správce tak vidí, že úroveň licence uživatele ve stejné době, kdy administrátor sleduje systémové proměnné přímo ovlivněné touto licencí.

Krása softwaru je, že vše, co musíte udělat, je volat informace.

Úpravy: Kromě toho bych mohl použít schéma oprávnění zaměřené na role, kde mohou být oprávnění přiřazena rolím a nikoli jednotlivým uživatelům. To často zmírňuje tunu režijních nákladů z potřeby mikromanažovat individuální uživatelská oprávnění.

  1. Správce otevře obrazovku pro úpravu rolí.
  2. Správce možná vybere přepínač pro nejnižší licenci, na kterou bude role použita.
  3. Oprávnění, která nejsou k dispozici pro vybranou roli, jsou deaktivována a "x" upravena.
  4. Správce vybere oprávnění ze zbývajících aktivních možností.
  5. Později na obrazovce správy uživatelů nebo v uživatelském profilu uvidí správce seznam rolí, které může mít uživatel na základě licence, a správce vybere jednu nebo více.
1
Matt

Obecně platí, že moje pravidlo platí takto (a já musím mít dobrý důvod k jeho porušení): Pokud argumentace za deaktivovanou komponentou plyne z kontextu nebo že porozumění by mělo být pro uživatele snadné z jiného důvodu, pak je preferovaným řešením blokování. Jinak by mohl být uživatel frustrován, když se snaží přijít na to, proč je to tak, a co je horší, pravděpodobně si nebude pamatovat důvod, proč k tomu došlo (v případě, že by na to přišel), až se s ním setká.

1
Assimiz

Chcete-li odpovědět na konkrétní otázku, chcete zobrazit dostatečné informace, aby uživatelé mohli porozumět omezením dříve, než kliknou. Ve vašem příkladu byste měli uvést každého uživatele s jeho licencí jako pole jen pro čtení vizuálně spojené (např. Blízkostí) s ovládacími prvky pro nastavení jejich oprávnění. Nebo byste mohli dynamicky kombinovat licenční pole se štítkem pro oprávnění (např. „Oprávnění (s omezenou licencí):“).

Neaplikovatelná oprávnění by měla být pravděpodobně zakázána, neměla by být povolena ani neskrývána. Pokud to stojí za zmatek, zahrňte řádkový text, textový kurzor/popisky nebo odkaz pro vysvětlení, proč oprávnění nepovolená licencí (řádkový text může nahradit deaktivované ovládací prvky, pokud jsou v nich uvedena oprávnění, například „Správce“ , Finanční není povoleno pro omezené uživatele “).

Obecným pravidlem je zakázání použití, pokud uživatel může udělat něco v uživatelském rozhraní k povolení příkazu. Zakázáno znamená „můžete provést tento příkaz, ale právě teď ne, jak to vypadá.“ „Způsob, jakým jsou věci“, zahrnuje aktuální výběr. Kdykoli použijete zakázání, měla by existovat jasná indikace, aby uživatelé pochopili, proč jsou přidružené příkazy pro některé objekty zakázány.

Používejte políčka zpráv místo zakázání, pokud neexistuje žádný způsob , aby byl důvod deaktivace uživateli předem vyjasněn za předpokladu, že má průměrnou znalost domény. Popisy pro zakázané ovládací prvky jsou skvělý nápad, ale samy o sobě ve všech případech nemusí stačit.

Skrýt, pokud uživatel nikdy nemá přístup k příkazu bez ohledu na to, co dělá v uživatelském rozhraní vzhledem k jeho aktuální poloze v organizaci. Například akce neautorizované uživatelem na základě jejich oprávnění se jednoduše nezobrazí. Je pro tento případ nepřehledné a frustrující používat deaktivující nebo schránky zpráv. Pokud jde o uživatele, akce, na které nemají práva, nejsou jejich prací (jinak by měli přístup), a související ovládací prvky by tedy ve svém uživatelském rozhraní neměly prostě existovat. Příručky k dokumentaci nebo postupům organizace mohou uživatelům sdělovat, jak jsou takové akce prováděny (např. „Váš nadřízený pro vás vytváří nové zákaznické účty“ nebo „Potřebujete k úpravě účtů finanční oprávnění; postup najdete u svého administrátora, který vám poskytne schválení k upgradu vašich oprávnění). “).

Podrobnější informace najdete na Controlling Your Controls .

1
Michael Zuschlag

Některé z výše uvedených bodů jsou skvělé a já nechci znovu opakovat, ale ...

V tomto případě bych viděl všechny dostupné možnosti. Možnosti, které nebyly ve vašich pravidlech použitelné, by měly být deaktivovány (zobrazeny šedě). Je běžné, že uživatel jakéhokoli rozhraní rozpozná, že pokud je něco šedé, obvykle to znamená, že to není použitelné pro nějaký druh sady pravidel, která se děje.

Špička nástroje se dokonale shoduje s deaktivovaným tlačítkem. V některých zvláštních, pokročilejších případech, jako je ta výše uvedená, s licencemi, pokud uživatel bez řádné licence prohlížel oblast, která vyžadovala vyšší licenci, zcela změnil umění tlačítka na něco jako „Upgradujte nyní!“ místo toho, aby se to zobrazovalo šedě, by to byla lepší reklama na tento produkt, a to by se ukázalo.

Pokud by jej uživatel admin prohlížel, zjevně by viděli, že finanční možnost je zobrazena šedě, s tipem nástroje vysvětlujícím proč.

Nevím plně souvislosti vašeho problému, nemusí se jednat ani o produkt. Ale na základě toho, co jsem pochopil, to je moje reakce na to.

1
user708

Windows UXGuide má dost prostředků, které vám mohou pomoci při rozhodování o tom, zda zobrazit chyby nebo zabránit neplatnému zadání. Konkrétně existuje sekce , které činí níže uvedené prohlášení o ui.

Pokud uživatelé pravděpodobně nevykonávají akci nebo nezmění své chování v důsledku zprávy, nedávají chybové zprávy. Pokud uživatel neprovádí žádnou akci nebo problém není významný, potlačte chybovou zprávu.

Také tato diskuse mi trochu připomíná, co Karl Shifflett ve svém blog s názvem „Fort Knox Business Objects (yes/no)“, kde zvažuje klady a zápory, zda povolit obchodním objektům vstup do neplatný stav nebo ne a jak toto rozhodnutí ovlivňuje interakci uživatele.

Osobně mám tendenci zabránit uživateli v tom, aby zadával neplatné položky nebo deaktivoval ovládací prvky, které většinou provádějí akce, jako jsou tlačítka, ale u některých ovládacích prvků, které vyžadují složité zadávání textu, mám tendenci zobrazovat inline varování, která jsou méně rušivá než zprávy, ale stále dostávají bod napříč.

0
jpierson

Udělejte obojí: Backend a UI

To by opravdu nemělo být ani situace, ani situace. Další odpovědi obsahují seznam dobrých důvodů pro zobrazení nedostupných možností a dobré důvody, proč je neukazovat. Ale věc je, v každém případě, musíte s ní správně zacházet na pozadí. Stále musíte správně zkontrolovat uživatelské vstupy a oprávnění, i když si myslíte, že jediný vstup, který mohou poskytnout, je správný.

To platí dvojnásob pro každou webovou aplikaci, kde by uživatel mohl uměle povolit zakázané ovládání/možnost/vstup. Nedovolte, aby používání Firebug trumflo schopnost vaší aplikace ovládat to, co mohu dělat. A v případech, kdy se snaží použít možnost, která by neměla být k dispozici, nezapomeňte událost zaznamenat.

0
Jeffrey Blake