it-swarm-eu.dev

Proč je třeba použít „zadat název projektu k potvrzení“?

Pokud jste dlouhodobým uživatelem GitHubu, pravděpodobně jste něco takového viděli:

K tomu dochází pokaždé, když uděláte potenciálně destruktivní věc do úložiště, jako je přepnutí jeho veřejného/soukromého stavu nebo její archivace/odstranění.

Po kliknutí na tlačítko akce se výzva zobrazí modálně, takže se jedná o zvláštní opatření, které zabrání náhodným činnostem.

Ale pokud jde o mě, je to buď neúčinné v „nastavení další bariéry“, nebo příliš těžkopádné jako „zvláštní potvrzení“. Název úložiště lze jednoduše zkopírovat z adresy URL nebo přímo nad vstupní pole (tučný text výše), ale to je ještě složitější než pouhým kliknutím na tlačítko navíc.

Podle mého názoru, extra modální s jasně červenou button to nebude reagovat na akce klávesnice (jako klávesa Enter) by stačilo. Člověk by musel přesunout myš na jasně červené tlačítko, aby na ni klikl pro další vrstvu opatrnosti. To je méně těžkopádné a neschopnost jednoduše stisknout klávesu Enter je jednoduchá a efektivní.

Může někdo vysvětlit, jak je toto „zadání názvu projektu“ dobrým designem uživatelského rozhraní?

48
iBug

Nejedná se nutně o „dobrý design uživatelského rozhraní“, ale mnohem více o přijetí všech opatření k zabránění náhodnému smazání a zajištění toho, že uživatel je plně si vědom toho, co smazává.

Tato položka blogu to zachycuje docela dobře:

Namísto toho, aby uživatelům dali potvrzovací tlačítko, že by mohli omylem stisknout, zadejte jim textové pole a požádejte je, aby pro potvrzení zadali slovo „odstranit“. Když uživatel do textového pole zadá „smazat“, není pochyb o tom, že chce vymazat. Neexistuje žádné neúmyslné stisknutí tlačítka mazání. Když uživatel smaže, není politování, protože potvrzovací textové pole jim dává jistotu, co udělá, než to udělá.
Jak zajistit, aby uživatelé náhodně neodstraňovali - pohyb UX

Jistě, stisknutí tlačítka je snazší, ale to vždy ponechává šanci, že si jméno nepochopíte a vymažete nesprávnou položku.
Když musíte zadat jméno (nebo ho dokonce zkopírovat), můžete si být jisti, že to uživatel omylem neudělá. To by si uvědomili nejpozději při zvýraznění názvu pro copy-paste.

Kromě toho se obvykle používá pouze pro velmi kritické operace mazání. K tomu dochází velmi zřídka, takže argument o tom, že je to jednodušší nebo méně nepříjemný, se ve skutečnosti tam nedrží.


Zde jsou některé související otázky:

168
Big_Chair

Jen aby bylo jasné, že „dobrý“ design uživatelského rozhraní neznamená dát uživateli to, co chtějí. Často to znamená pomoci uživateli být lepší verzí sebe samých.

Kromě toho, co již bylo zmíněno, tento vzorec (a několik podobných) umožňuje UI snížit rychlost. Obecně muscle memory -> speed -> mistakes -> sad path.

Představte si, že pracujete ve zdravotnictví. Pokud by uživatelé vytvořili příliš mnoho „toku“ v běžných úkolech, mohli by potenciálně udělat jednoduchou chybu, která někoho zabije. Přestože je to intuitivní, je často dobré vytáhnout uživatele z jeho toku vyžadováním interakce (více než jednoduchý potvrzovací dialog, který se vždy objeví na stejném místě a může být přidán do svalové paměti).

Jedním z příkladů je psaní textu. Také jsem viděl:

  1. přidání časového limitu do tlačítek, než budou k dispozici.
  2. Náhodné umístění tlačítek pro pokračování procesu.
  3. Přidání zámku (např. Spuštění procesu jako správce s heslem)

Všechny tyto vzorce jsou určeny k tomu, aby obtěžovaly uživatele natolik, že přestaly mentálně posoudit proces, než začnou.

51
Bryce Howitson

Tím je zajištěno, že:

  1. Rozumíte nebezpečí toho, co děláte.
  2. A co je nejdůležitější, že skutečně odstraňujete správný repo.

Pokud má uživatel mnoho repozit s dlouhými jmény, může být snadné si je promíchat. Zadání jména je dobrý způsob, jak se ujistit, že nevyměňujete špatné, což by bylo opravdu špatné.

15
frodo2975

Nepoužitý klávesový klíč (přes AutoHotKey) přemapuji pro občasné použití jako kliknutí levým tlačítkem myši, abych snížil napětí z nadužívání mousing zápěstí a někdy (zřídka) zasáhl tuto klávesu na nesprávném místě při multitaskingu. Také jsem občas narazil do myši a neúmyslně klikl na tlačítko v dialogu.

Zatímco „donutit mě nepřemýšlet“ je velmi dobré pravidlo, má smysl pomáhat uživateli soustředit se přesně na to, co provedení občasného, ​​destruktivního příkazu skutečně povede. Dokonce bych uvažoval o tom, že uživatel napíše plnou větu formuláře: „Vymažte úložiště iBug/příklad-úložiště, včetně jeho wiki, problémů a komentářů“, abyste vyjasnili úmysl uživatele sami = v této situaci, protože uživatel to udělá pouze jednou v tomto úložišti.

Každý, kdo skutečně píše kód, musí velmi často psát plné, jasné a správně napsané řádky textu, takže jeden takový řádek, který potvrdí nejničivější akci, kterou můžete na projektu provést, není nepřiměřený.

9
user117529

Podle mého názoru by stačil další modus s jasně červeným tlačítkem, které nereaguje na akce klávesnice (jako je klávesa Enter). Jeden by musel move jejich myš na jasně červené tlačítko, aby na ni klikl pro další vrstvu opatrnosti. To je méně těžkopádné a neschopnost jednoduše stisknout klávesu Enter je jednoduchá a efektivní.

(důraz byl přidán)

Jste jisti, že by museli „pohnout myší“? Pokaždé? I když jsou na zařízení s odlišným rozlišením, kde se možná věci neshodují podle očekávání? Nebo pokud jsou přiblíženy? Co dotykový vstup? A co lidé, kteří nepoužívají myš (kvůli rozdílům ve schopnosti/atd.)? Nyní se musíte ujistit, že reaguje na klávesnici způsobem, který nepřeruší přístupnost, ale neumožňuje náhodné vymazání.

I když existují argumenty proti bez rozdíl následování osvědčených postupů jednoduše kvůli tomu, že jsou osvědčenými postupy (versus rozvíjení porozumění tomu, proč jsou na místě) nebo přinejmenším „co všichni ostatní jsou dělá ", zejména když nejsou vždy ve skutečnosti tak skvělé, rád bych zdůraznil, že obvykle se stali nejlepší praxí, protože existují nepředvídané problémy, které vyvstanou, a snaží se jít proti jednoduše proto, že nevidíte jejich smysl, je obvykle špatný nápad. Při pohledu na něco, co je široce rozšířenou/široce osvědčenou osvědčenou praxí, vycházejte z předpokladu, že je smysluplný a významný a pravděpodobně má silné důvody, které se vyvinuly v průběhu času (a pravděpodobně mezi více lidmi než jen jeden, a určitě byly přezkoumáno více než jen jednou osobou), než jste vy sami pravděpodobně věnovali stejné skupině problémů (a pouze vás vede vlastní perspektiva). Nemluvě o problémech globální konzistence.

@ BigChairova odpověď spolu s @ Bryce Howitsonova odpověď obojí Zjistěte, proč je to obecně nejlepší postup pro neopravitelné akce obecně. V designu uživatelského rozhraní je důležité vytvořit tření pro kritické akce, které budou neodstranitelné, a oba tyto téma pokrývají téma v tomto kontextu docela dobře.

Je-li to možné , ale v každém případě bych doporučil jinou cestu, kde by bylo proveditelné:

Vyhněte se především tomu, aby akce nebyly obnovitelné

Díky tomu je nejlepším způsobem, jak postupovat vpřed, nemít na prvním místě uživatelské akce výsledek neopravitelné softwarové stavy . Pamatujte, že to, co UI vystavuje osobě používající software, nemusí odpovídat tomu, co software dělá jeho stavu interně, v 1: 1 související sémantice. Je v pořádku, jak je něco představováno osobě, která jej používá, aby neodpovídala technické implementaci toho, co se stane, když aktivují související akci.

Nepoužívejte delete věci ve vaší softwarové reprezentaci, které jsou založeny pouze na vstupu uživatele. Označit ​​byly odstraněny v jejich reprezentaci úložiště a poskytnout prostředky k jejich získání (koše/atd.). Nepovolte vytváření situací, kdy se osoba používající váš produkt může vrátit zpět do rohu, ze kterého se nemůže dostat zpět. Nejenže je lepší UX vyhnout se nutnosti těchto typů potvrzení všude, kde je to možné, ale také snižuje požadavky na podporu a související úrovně tření v souvisejících otázkách podpory (což jsou také aspekty UX). Když někdo něco „smaže“, dejte hojně jasné , že bude moci vrátit zpět akci, kterou provedl, zatímco se zapojí do akce a poté (takže pokud - mít ​​náhodně „smazáno“ něco bez přečtení obrazovek až do přijetí akce, nyní mohou vidět, kam se vrátit, aby ji zrušili).

9
taswyn

Už jsem udělal to, čemu říkám náhodné chyby:

  • moje ruka posunula druhé stisknutí tlačítka (chtěl "Zrušit", dostal "OK"). Alternativně: vyskočila reklama a posunula stránku.
  • instrukce byla tak matoucí, že jsem stiskl špatné tlačítko (samozřejmě ne méně destruktivní)
  • Byl jsem "oh ne ne" a v panice stiskl špatné tlačítko
  • Můžu nebo nemusí být Juan Pablo Davila

To je důvod, proč v takových případech opravdu dávám přednost procesu, který mě nutí jednat odlišně od toho, co naznačuje svalová paměť.

5
WoJ

To, co se Github snaží udělat, je vyhnout se uživatelským chybám, ale konkrétně „uklouznout“, jak na ně odkazuje Don Norman v návrhu každodenních věcí.

K uklouznutí dochází, když uživatelé zamýšlejí provést jednu akci, ale nakonec provedou jinou (často podobnou) akci. Například psaní „i“ místo „o“ se počítá jako skluz; nechtěné vložení tekutého mýdla do ruky na zubní kartáček namísto zubní pasty je také skluz. Listy se obvykle dělají, když jsou uživatelé na autopilotu, a , když plně nevěnují své zdroje pozornosti úkolu.

Poslední část nabídky zdůrazňuji jako zvláště důležitou.

Následující článek nngroup hovoří o tom, jak zabránit uklouznutí

chyby typu skluzu často dělají odborní uživatelé, kteří jsou velmi dobře obeznámeni s daným procesem; na rozdíl od nových uživatelů, kteří se stále učí, jak systém používat

https://www.nngroup.com/articles/slips/

Vzhledem k typům lidí, kteří by Github používali, byste je považovali za velmi vysoké na něčem, jako je stupnice digitálního inkluze GDS , což by znamenalo, že se jedná o zkušené uživatele, u nichž je větší pravděpodobnost, že vydělají.

Pak je dejte dohromady a vciťte se s odborným uživatelem Githubu, který do projektu vložil stovky hodin, ale je unavený, zapomněl, na kterém projektu byl, a když to nechtěli, stáhl smazat. Jak se cítí?

Mnoho uživatelů Githubu má velký počet repozitářů a na stránce smazání jim není moc co říct, pokud nevěnujete pozornost, možná jste chtěli odstranit repo projekt „milión liber - koncept“, ale byli jste v "milión liber projektu".

To dělají a já bych za to považoval za efektivní design uživatelského rozhraní. Dobrým postupem je zavádění užitečných omezení do operací, které nelze obnovit.

3
dougajmcdonald