it-swarm-eu.dev

Expozice funkcí vs. nadýmání uživatelského rozhraní

Při vývoji webových aplikací mám obvykle tendenci mít ikonu/tlačítko na funkci/funkci a umístit ji tak, aby byla snadno přístupná, aniž by rušila uživatele během jeho obvyklé práce. Často mám však střety s částí správy, protože se domnívají, že určitá tlačítka by měla být na více místech a měla by být co nejvíce viditelná.

Jaký je váš názor na to? Pokud mají tlačítka/funkce ve stejném kontextu jedno místo, pokud by jej měl uživatel vždy hledat (můj přístup), nebo by měla být tlačítka duplikována na všechna místa, kde by je uživatel mohl potřebovat (přístup managementu).

Příklady:
- Umístěte další tlačítko edit hned vedle karet konfigurační obrazovky, abyste se dostali do režimu úprav aplikace, protože možnost edit je uvnitř nabídky panelu nástrojů a není ihned vidět
- Umístěte tlačítko save nad a pod textarea, protože uživatel mohl buď dokončovat psaní (dolní save je blízko) ) nebo dokončení čtení náhledu (horní save je blízko)

Naše odůvodnění debaty:

můj přístup:
+ úhledný design
+ nepoužité ikony zůstanou skryté
+ struktura
- uživatel bez předchozího vystavení softwaru možná bude muset vyhledat funkce/vyhledávání

přístup vedení
+ funkce jsou viditelné tam, kde jsou potřeba
- redundantní komponenty UI pro stejnou funkci
- neuspořádaný vzhled a dojem
- UI nadýmal

Domnívám se, že zdání se zdá být neobjektivní, ale proto se ptám. Jaký přístup vede k lepšímu uživatelskému rozhraní?

6
Mike

Podle mého názoru nejsou duplicitní akce vždy špatné. Zvláště ne, pokud nejsou z pohledu uživatelů úplně stejné.

Myslím, že nakonec neexistuje žádný způsob sledovat vše. Není to duplikát versus duplikát, co nejvíce. Podívejte se na tento případ a rozhodněte se, co si uživatel může myslet, jaký je jejich obvyklý vzor, ​​co by dělali, kdyby to nebyla aplikace, ale papírová věc, jak by si mysleli. A na základě toho se rozhodněte, kde chcete poskytnout, jaké akce.


První příklad:

Umístěte další tlačítko edit hned vedle karet obrazovky s konfigurací, abyste se dostali do režimu úprav aplikace, protože možnost edit je uvnitř nabídky panelu nástrojů a hned není vidět

Myslím, že to je to, co říkáte:

tabs with an edit-mode

Pokud ano, pak mají tyto dvě akce pro uživatele jiný význam. První „režim úprav“ je uvede do redakčního/redakčního režimu (také do jejich vlastních myslí) a vše upraví. Druhé „změnit tato nastavení“ to provede pouze s touto stránkou.


Váš druhý příklad:

Umístěte tlačítko save nad a pod textarea, protože uživatel mohl buď dokončovat psaní (dolní save je blízko) nebo dokončovat čtení náhledu (horní save je blízko)

V poslední době jsem měl podobnou situaci:

CMS edit form with two save buttons

V tomto případě první tlačítko uložit poskytuje rychlý způsob provedení změn; snadno lze provést [upravit - něco změnit - uložit] a uživatel nemusí posouvat celý formulář dolů. A když uživatel potřebuje nastavit pokročilé možnosti, může jednoduše následovat formulář a uložit na dno.

(Jeden může argumentovat, že umístí pokročilá nastavení pod odkaz nad první tlačítko uložit a nechat jej rozkliknout, když klikne na odkaz. To však není vždy hledáno.)

7
Lode

Kdo říká, že nadbytečnost je vždy špatná? Je běžné mít nabídky, panely nástrojů a klávesové zkratky, které všechny dělají totéž. Pokud duplikáty nepřidávají něco (tj. Jsou skutečně zcela nadbytečné), , pak je čas něco odstranit, ale nemusí to být bity nejdřív si myslíš.

V Gmailu je reply k dispozici nad a pod zprávou, protože se uživatel pravděpodobně posunul nahoru nebo dolů stránku, což ztěžuje nalezení tlačítka na druhém konci. Tento problém neexistuje u stolních aplikací, takže by neměly dobrý důvod k tomu, aby na obou místech byly tlačítko.

Trik je zůstat v rovnováze a vyhýbat se všemu všude. Princip seskupení souvisejících funkcí pomáhá v obou směrech - neskrývejte věci z cesty, pokud se to opravdu týká lokalizovaných funkcí, ale nevyhazujte je do středu hlavního uživatelského rozhraní pokud to není užitečné pro provedení úlohy, kterou má uživatel provést. Druhý případ se týká možností a nastavení, které uživatel nastaví jednou a zapomenout - nevkládejte do cesty tlačítko Options, pokud na něj jen jednou kliknou.

Zjistěte, jaké jsou nejčastější případy použití pro každou část aplikace, a optimalizujte uživatelské rozhraní pro tyto případy použití. Je to v pořádku, pokud to přidá malý malý redundance.

4
Steve S

Ribbon společnosti Microsoft poskytuje uživateli možnost přidávat různé příkazy na panel nástrojů „Rychlý přístup“. Tuto myšlenku byste mohli rozšířit a tyto příkazy přidat pouze zpočátku a zároveň umožnit uživateli odstranit ty, které nechtějí.

0
Pat

Viděl jsem mnoho webových stránek s plovoucí lištou nebo widgetem, které zůstávají v dohledu bez ohledu na rolování. Nelze použít takovou lištu k udržení přehledů „Upravit“, „Uložit“ nebo jiných příkazů? To by samozřejmě fungovalo, jen kdyby se stránka jako celek uložila, myslím.

0
Peter Frings

Co o tom říkají skuteční uživatelé? A jak reagují na obě implementace, když jsou podrobeny uživatelskému testu? Myslím, že to jsou rozhodující faktory. Myslím, že aplikace by měly být hlavně snadno použitelné, takže vyhnout se bělení uživatelského rozhraní není cílem samo o sobě, ale prostředkem k jeho udržení použitelnosti. Pokud tlačítko navíc pomáhá uživatelům (tím, že mnohem častěji používanou funkci snadněji zpřístupní), více než jim brání (tím, že jim předkládá matoucí rozhraní), myslím, že by se to mělo udělat.

(A všimněte si, že většina GUI v nich již má redundanci. Některé možnosti jsou uvedeny v položkách nabídky nahoře, na panelu nástrojů, v místní nabídce a mají klávesovou zkratku.)

Myslím si, že pokud se režim úprav používá hodně, zaslouží si přímé tlačítko.

0
Inca

Mnoho webových aplikací má tlačítka Uložit/Odeslat jak nad, tak pod obsahem (zejména nákupní vozíky).

Dokud tlačítka vypadají stejně a jsou vzájemně sladěna, není s tím nic špatného.

K jejich řádkům by měla být přiřazena kontextová tlačítka (například tlačítko pro úpravu řádku); pravděpodobně by bylo lepší umístit editační tlačítko do řádku (snad na vznášedlo) než na panel nástrojů (pokud nepodporujete vícenásobný výběr)

0
SLaks