it-swarm.it

Perché usare "inserisci il nome del progetto per confermare"?

Se sei un utente GitHub da molto tempo, probabilmente hai visto qualcosa del genere:

Ciò accade ogni volta che si fa una cosa potenzialmente distruttiva in un repository, come cambiare il suo stato pubblico/privato o archiviarlo/eliminarlo.

Il Prompt viene visualizzato in modale dopo aver fatto clic sul pulsante di azione, quindi questa è una misura aggiuntiva per prevenire azioni accidentali.

Ma per quanto mi riguarda, questo è inefficace nel "creare un'altra barriera" o troppo ingombrante come "un'ulteriore conferma". Si può semplicemente copiare il nome del repository dall'URL o proprio sopra la casella di input (il grassetto sopra), ma questo è ancora più complesso del semplice clic su un pulsante aggiuntivo.

Secondo me, un extra modale con un rosso brillante button che non risponde alle azioni della tastiera (come il tasto Invio) sarebbe sufficiente. Uno dovrebbe spostare il mouse sul pulsante rosso brillante per fare clic su di esso per un ulteriore livello di cautela. Questo è meno ingombrante e l'incapacità di premere semplicemente il tasto Invio è sia semplice che efficace.

Qualcuno può spiegare come questo "inserire il nome del progetto" sia un buon design dell'interfaccia utente?

48
iBug

Non si tratta necessariamente di "buona progettazione dell'interfaccia utente", ma molto di più sull'adozione di tutte le misure per prevenire la cancellazione accidentale e garantire che l'utente sia pienamente consapevole di ciò che sta eliminando .

Questo post di blog qui lo cattura abbastanza bene:

Invece di dare agli utenti un pulsante di conferma che potrebbero premere per errore, dare loro un campo di testo e chiedere loro di digitare la parola "elimina" per confermare. Quando l'utente digita "elimina" nel campo di testo, non c'è dubbio che desidera eliminare. Non è possibile premere accidentalmente il pulsante Elimina. Non vi è alcun rimpianto quando l'utente elimina, perché il campo di testo di conferma li rende certi di ciò che stanno per fare prima di farlo.
Come assicurarsi che gli utenti non eliminino accidentalmente - Movimento UX

Certo, premendo un pulsante è più facile, ma ciò lascia sempre la possibilità di leggere male il nome ed eliminare l'elemento sbagliato.
Quando devi digitare il nome (o anche copiarlo incollalo), puoi essere sicuro al 99% che un utente non lo farà per errore. Se ne accorgerebbero al più tardi evidenziando il nome di copia-incolla.

Oltre a ciò, questo di solito viene utilizzato solo per operazioni di cancellazione molto critiche. Questi accadono molto raramente, quindi l'argomento su come renderlo più facile o meno fastidioso non vale davvero.


Ecco alcune domande correlate:

168
Big_Chair

Giusto per essere chiari, "una buona" progettazione dell'interfaccia utente non significa dare all'utente ciò che desidera. Spesso significa aiutare l'utente a essere una versione migliore di se stesso.

Oltre a ciò che è già stato menzionato, questo modello (e molti altri simili) consente all'interfaccia utente di ridurre la velocità. In generale muscle memory -> speed -> mistakes -> sad path.

Immagina di lavorare nel settore sanitario. Se gli utenti accumulano troppo "flusso" in attività comuni potrebbero potenzialmente commettere un semplice errore che uccide qualcuno. Mentre è intuitivo, è spesso utile estrarre l'utente dal loro flusso richiedendo un'interazione (più di una semplice finestra di dialogo di conferma che appare sempre nello stesso posto e può essere aggiunta alla memoria muscolare).

Digitare il testo è solo un esempio di questo. Ho visto anche:

  1. aggiungendo un timeout ai pulsanti prima che diventino disponibili.
  2. Posizionamento casuale dei pulsanti di continuazione del processo.
  3. Aggiunta di un blocco (ad es. Eseguire processo come amministratore con password)

Tutti questi schemi hanno lo scopo di infastidire l'utente abbastanza da fermarsi a valutare mentalmente il processo prima di andare avanti.

51
Bryce Howitson

Questo per garantire che:

  1. Capisci il pericolo di ciò che stai facendo.
  2. Ancora più importante, che stai effettivamente cancellando il giusto repository.

Se un utente ha molti repository con nomi lunghi, può essere facile confonderli. Digitare il nome è un buon modo per assicurarsi che non si verifichi quella sbagliata, il che sarebbe davvero brutto.

15
frodo2975

Rimappare un tasto della tastiera inutilizzato (tramite AutoHotKey) per un uso intermittente come clic con il tasto sinistro del mouse per ridurre la tensione derivante dall'uso eccessivo del polso del mouse, e talvolta (raramente) premere quel tasto nel punto sbagliato durante il multitasking. Occasionalmente ho anche urtato il mouse stesso e ho fatto involontariamente clic su un pulsante in una finestra di dialogo.

Mentre "non farmi pensare" è una regola molto buona, ha senso aiutare l'utente a concentrarsi esattamente su ciò che eseguirà un comando distruttivo e poco frequente. Vorrei anche prendere in considerazione la possibilità per l'utente di digitare una frase completa del modulo, "Elimina il repository iBug/esempio-repository, inclusi wiki, problemi e commenti" alla lettera per chiarire l'intenzione dell'utente di se stessi = in quella situazione, poiché l'utente lo farà solo una volta su quel repository.

Chiunque effettivamente scriva codice deve digitare molto frequentemente righe di testo complete, chiare e correttamente digitate, quindi una riga in più per confermare l'azione più distruttiva che è possibile eseguire su un progetto non è irragionevole.

9
user117529

Secondo me sarebbe sufficiente un extra modale con un pulsante rosso acceso che non risponde alle azioni della tastiera (come il tasto Invio). Si dovrebbe spostare il mouse sul pulsante rosso vivo per fare clic su di esso per un ulteriore livello di cautela. Questo è meno ingombrante e l'incapacità di premere semplicemente il tasto Invio è sia semplice che efficace.

(enfasi aggiunta)

Sei sicuro che dovrebbero "spostare il mouse"? Ogni volta? Anche se si trovano su un dispositivo con una risoluzione diversa, dove forse le cose non si allineano come previsto? O se sono ingranditi? Che dire dell'input tattile? Che dire delle persone che non usano il mouse (a causa della differenza di abilità/ecc.)? Ora devi assicurarti che risponda alla tastiera in modo da non compromettere l'accessibilità, ma non consentire una cancellazione accidentale.

Mentre ci sono argomenti contro indiscriminatamente seguendo le migliori pratiche semplicemente perché sono le migliori pratiche (rispetto allo sviluppo di una comprensione del perché sono in atto) o almeno " quello che fanno gli altri ", in particolare quando non sono sempre in realtà così fantastici, vorrei sottolineare che di solito sono diventati una buona pratica perché ci sono problemi imprevisti che sorgeranno e cercare di andare contro di loro semplicemente perché non ne vedi il punto è di solito una cattiva idea. Quando si guarda a qualcosa che è una best practice diffusa/ampiamente adottata, partire dal presupposto che sia significativo e significativo e che probabilmente abbia forti ragioni sottostanti che si sono sviluppate nel corso del tempo (e probabilmente tra più persone di una sola, e sicuramente sono state recensito da più di una sola persona) di quanto tu stesso abbia probabilmente dedicato alla stessa serie di problemi (e con solo la tua prospettiva che ti guida). Per non parlare dei problemi di coerenza globale.

@ risposta di BigChair a fianco @ risposta di Bryce Howitson entrambi Scavare sul perché questa è una buona pratica per azioni irrecuperabili in generale. Nella progettazione dell'interfaccia utente, è importante creare attrito per le azioni critiche che saranno irrecuperabili e che entrambi trattano l'argomento abbastanza bene per questo contesto.

Laddove possibile , tuttavia, consiglierei di prendere una strada diversa in ogni caso in cui sarebbe possibile implementare:

In primo luogo, evitare di rendere irrecuperabili le azioni

Detto questo, il modo migliore per andare avanti è non avere le azioni dell'utente comportare stati software non recuperabili in primo luogo. Ricorda, ciò che un'interfaccia utente espone alla persona che utilizza il software non deve corrispondere a ciò che il software fa al suo stato internamente, in un 1: 1 di semantica correlata. Va bene come viene rappresentato qualcosa alla persona che lo utilizza per non corrispondere all'implementazione tecnica di ciò che accade quando attivano un'azione correlata.

Non eliminare elementi nella loro rappresentazione software in base al solo input dell'utente. Mark li hanno cancellati nella loro rappresentazione di archiviazione e forniscono un mezzo per recuperarli (un cestino/ecc.). Non consentire la creazione di situazioni in cui una persona che utilizza il tuo prodotto può rientrare in un angolo da cui non riesce più a uscire. Non solo è meglio UX evitare la necessità di questi tipi di conferme ovunque sia possibile farlo, ma riduce anche i requisiti di supporto e i relativi livelli di attrito nelle questioni relative al supporto (che sono anche aspetti UX). Quando qualcuno sta "cancellando" qualcosa, rendi abbondantemente chiaro che saranno anche in grado di ripristinare l'azione che hanno intrapreso sia mentre si impegnano nell'azione che successivamente (in modo che se hanno accidentalmente "cancellato" qualcosa senza leggere schermate fino a includere l'azione, ora possono vedere dove andare per annullarlo).

9
taswyn

Ho già fatto ciò che chiamo errori accidentali:

  • la mia mano si è spostata il secondo in cui ho premuto il pulsante (volevo "Annulla", ho ottenuto "OK"). In alternativa: un annuncio è apparso e ha spostato la pagina.
  • l'istruzione era così confusa che ho premuto il pulsante sbagliato (ovviamente non quello meno distruttivo)
  • Ero "oh no no no" e in preda al panico ho premuto il pulsante sbagliato
  • Potrei essere o meno Juan Pablo Davila

Questo è il motivo per cui in questi casi preferisco davvero avere un processo che mi fa agire diversamente da ciò che la memoria muscolare suggerisce.

5
WoJ

Ciò che Github sta cercando di fare qui è evitare l'errore dell'utente, ma in particolare "scivola" come Don Norman si riferisce a loro in Il design delle cose quotidiane.

I slipp si verificano quando gli utenti intendono eseguire un'azione, ma finiscono per fare un'altra (spesso simile) azione. Ad esempio, digitare una "i" invece di una "o" conta come una distinta; Anche mettere accidentalmente sapone liquido per le mani sullo spazzolino da denti anziché sul dentifricio è una scivolata. I slipp vengono generalmente fatti quando gli utenti sono sul pilota automatico e quando non dedicano completamente le loro risorse di attenzione all'attività da svolgere.

Sottolineo l'ultima parte della citazione come particolarmente rilevante.

Il seguente articolo di nngroup parla di come prevenire gli errori

errori di tipo slip spesso vengono commessi da utenti esperti che hanno molta familiarità con il processo in questione; a differenza dei nuovi utenti che stanno ancora imparando come utilizzare il sistema

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

Considerando i tipi di persone che utilizzerebbero Github, li considereresti molto simili a qualcosa come GDS Digital Inclusion Scale che implicherebbe che sono utenti esperti più propensi a fare scivolate.

Quindi unisci i due e immedesimati in un utente esperto di Github che ha impiegato centinaia di ore in un progetto, ma è stanco, ha dimenticato il progetto in cui si trovava e scivola per premere Canc quando non intendeva farlo. Come si sentono?

Molti utenti di Github hanno un numero elevato di repository e nella pagina di eliminazione non c'è molto da distinguere se non stai prestando attenzione, forse volevi eliminare il repository "progetto da un milione di sterline", ma eri in "progetto da un milione di sterline".

Questo è quello che stanno facendo e lo considero efficace per la progettazione dell'interfaccia utente. Mettere utili vincoli nel modo di operare che sono irrecuperabili è una buona pratica.

3
dougajmcdonald