it-swarm-eu.dev

È meglio prevenire un'azione vietata o visualizzare un messaggio di errore / spiegazione?

Ci sono più esempi, quindi ne sceglierò uno specifico per focalizzare la domanda.

Supponiamo che un utente possa avere caratteristiche (o autorizzazioni) specifiche:
Amministratore, virtuale, esterno, finanziario, ecc.

A complicare le cose, anche gli utenti hanno licenze diverse: Premium, Regular, Limited, ecc.

Probabilmente puoi vedere dove sta andando:
Supponiamo che un utente con una licenza limitata non possa essere un amministratore o avere autorizzazioni finanziarie.

Possibilità:

  • L'amministratore passa al profilo di, diciamo Zack e vede che non può permettergli di avere permessi finanziari.
    Il problema è che non è chiaro all'amministratore perché (le informazioni sulla licenza e le autorizzazioni non sono visualizzate nella stessa posizione e anche se lo fossero, l'amministratore dovrebbe essere a conoscenza della regola di sistema di "nessuna autorizzazione finanziaria per utenti limitati")
  • L'amministratore vede tutte le autorizzazioni (supponiamo implementate tramite caselle di controllo) abilitate e solo quando si fa clic viene visualizzato un messaggio di errore che informa del motivo per cui l'operazione è stata negata.
    Ora il motivo è chiaro, ma l'amministratore ha dovuto "sprecare" un clic per scoprirlo.

C'è un modo sia per prevenire l'azione sia per spiegare perché? Un controllo disabilitato con una descrizione comandi funzionerebbe? Qualche idea migliore?

Per citare brevemente altri esempi, supponiamo che tu abbia un grafico interattivo e puoi spostare la maggior parte dei punti sul grafico, ma alcuni devono essere fissi. Potresti disegnarli in modo diverso per indicare che non possono essere spostati (senza spiegare il perché), oppure puoi consentire all'utente di provare a trascinarli e quindi mostrare un messaggio di errore.

27
Dan Barak

A seconda dell'applicazione, spesso non visualizzo solo le parti della pagina a cui un utente non ha accesso. Sembra che tu abbia gli utenti che modificano i diritti di altri utenti, quindi questo metodo potrebbe non funzionare. Consiglio di visualizzare un messaggio di errore ogni volta che si visualizza un elemento di input disabilitato. Gli utenti possono sentirsi frustrati quando non sono in grado di eseguire un'azione che si aspettano di poter fare. Se è solo disabilitato, probabilmente non capiranno perché e lo elimineranno semplicemente dal programma. Allo stesso modo, vuoi assicurarti che il messaggio sia il più semplice possibile e preciso. I messaggi di errore lunghi vengono spesso ignorati.

12
LoganGoesPlaces

Prima di nascondere completamente una parte dell'interfaccia utente per una funzionalità a cui l'utente non ha accesso, considera:

  1. L'utente sarà a conoscenza di tale funzione?
  2. Trascorreranno molto tempo a cercarlo?
  3. Sarebbe meglio tenerlo in giro in una sorta di stato "disabilitato" insieme a una descrizione comando o altro indicatore in modo che possano imparare perché non è disponibile?

Ecco un semplice esempio. Supponiamo che l'applicazione includa l'opzione per la stampa. Quando non è disponibile alcuna stampante, dovresti nascondere completamente il comando del menu di stampa? Ciò causerà confusione e perdite di tempo quando l'utente cerca attraverso tutti i menu e infine contatta il team di supporto tecnico cercando di trovare il comando "stampa"? Il tuo team di supporto tecnico capirà anche che questo utente non vede il comando "stampa"? Ci saranno effetti collaterali indesiderati se, ad esempio, la stampante è collegata ma si è spenta per risparmiare energia?

Come regola generale, credo che in molti casi, in particolare nei casi in cui un'opzione sia talvolta disponibile, gli utenti siano meglio serviti da un'opzione disabilitata o anche un'opzione abilitata che porta in primo piano un messaggio di errore che spiega PERCHÉ l'opzione non è attualmente disponibile.

35
Joel Spolsky

Vedo due approcci diversi.

Se le azioni sono disabilitate a causa di sicurezza In realtà proverei a rimuoverle se possibile. Facile con le voci di menu o la maggior parte dei pulsanti della barra degli strumenti.

Se le azioni sono disabilitate perché hai una versione più economica del software, le terrei presenti ma disabilitate. Questo fa sapere all'utente "potresti avere questo se pagassi di più" mentre se fosse rimosso non saprebbero cosa mancavano. Vedo che il popup "non è possibile farlo a causa della licenza" è un'interfaccia utente errata poiché l'utente non può dire se è possibile eseguire un'azione senza effettivamente tentare di eseguire l'azione.

8
shemnon

Un altro approccio è quello di non mostrare affatto l'azione.

Stack Exchange ne è un buon esempio. Se non ho i diritti di "modifica" per i post di altre persone, non vedo un link "modifica" affatto. Ciò significa che non provo a fare clic su di esso e mi chiedo perché non funzioni.

Ciò potrebbe non funzionare in tutte le circostanze, ma nel tuo esempio le opzioni/i collegamenti "admin" e "finanziari" non apparirebbero solo per utenti limitati, anche nelle schermate di amministrazione per quegli utenti. Se l'utente fosse cambiato in utente "Normale" o "Premium", appariranno tali opzioni/collegamenti.

Potresti quindi considerare di mostrare il tipo di utente da qualche parte semi prominente in modo che all'amministratore possa essere ricordato perché alcune opzioni/collegamenti non sono visibili!

7
ChrisF

Come hanno affermato altre risposte, se l'utente non dispone dell'autorizzazione per eseguire un'azione all'interno del sistema (come in, nessun privilegio di modifica/amministrazione), l'azione non dovrebbe essere visualizzata affatto.

Nei casi in cui le azioni sono disabilitate a causa dello stato dell'applicazione (impossibile modificare un file di sola lettura, impossibile copiare/incollare se non è selezionato alcun testo, l'utente ha una versione di prova del software che manca di alcune funzionalità, ecc.) Personalmente pensa che l'azione dovrebbe essere visualizzata, con un'indicazione visiva che l'azione al momento non può essere eseguita. Nota che non dico "disabilitato", perché se l'utente prova quell'azione, dovrebbe essere in grado di scoprire perché non è possibile. In questo modo un utente può vedere che l'azione è disabilitata, ma può anche ricevere un messaggio che spiega perché.

Starei attento al caso in cui un utente abbia una versione di prova/con licenza di un'app che non ha funzionalità. Ad esempio, se disponevi di un'app di lettura/scrittura ISO che non strapperebbe i CD a meno che non lo pagassi, allora potresti mostrare l'opzione "rip CD" ma non permettere all'utente di eseguirla. Ma se la tua applicazione ha intere suite di funzionalità nelle versioni di fascia più alta (ad esempio Visual Studio), la visualizzazione di tutte queste cose ma non consentirle potrebbe essere frustrante per l'utente. Non voglio aprire le mie suite IDE e vedere database, reti, UML integrato, test, profiling, ecc. Quando so che tutto ciò che mi viene concesso di fare è scrivere e costruire progetti .

6
Carson Myers

La mia regola empirica è: se un'azione non è disponibile per un utente a causa delle autorizzazioni, non è visibile. Se un'azione non è disponibile a causa del contesto temporaneo (questo pulsante 'Salva' non ha alcun significato fino a quando l'utente non ha inserito qualcosa da salvare), allora è disabilitato.

Le "autorizzazioni" riguardano sia "utente amministratore vs utente normale" sia "licenza premium vs licenza cheapo". Gli elementi di interfaccia utente inutilizzabili sono disordinati, non il modo di pubblicizzare le tue funzionalità aggiuntive.

Molte risposte sembrano aver capito bene, volevo solo riassumere tutto con una delle euristiche di Nielsen, che indica esattamente questo. Afferma:

Prevenzione degli errori Ancora meglio dei buoni messaggi di errore è una progettazione attenta che previene in primo luogo un problema. Eliminare le condizioni soggette a errori o verificarle e presentare agli utenti un'opzione di conferma prima di impegnarsi nell'azione.

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

4
Nacho

Mi piace molto shemnon's risposta. Estenderei il suo secondo caso e applicherei il comandamento di Nielsen referenziato da Ign; se l'utente ha una licenza più economica, disabiliterei l'opzione e sostituerei l'oggetto di selezione con un'icona che chiarisce ulteriormente lo stato disabilitato dell'opzione.

Qualcosa di simile a

  • O Opzione 1
  • O Opzione 2
  • alt text Opzione 3
  • O Opzione 4

Poiché questo prodotto supposizionale è ancora in fase di sviluppo, includerei almeno una dichiarazione del livello di licenza dell'utente nella stessa pagina. In questo modo, l'amministratore vede che il livello di licenza dell'utente nello stesso momento in cui l'amministratore sta esaminando le variabili di sistema direttamente interessate da quella licenza.

Una bellezza del software è che tutto ciò che devi fare è chiamare l'informazione.

Modifica: Inoltre, potrei utilizzare uno schema di autorizzazioni incentrato sui ruoli, in cui le autorizzazioni possono essere assegnate ai ruoli e non ai singoli utenti. Questo spesso mitiga un sacco di spese generali dalla necessità di gestire le autorizzazioni dei singoli utenti.

  1. L'amministratore apre la schermata di modifica del ruolo.
  2. L'amministratore può selezionare un pulsante di opzione per la licenza più bassa a cui verrà applicato il ruolo.
  3. Le autorizzazioni che non sono disponibili per il ruolo selezionato sono disabilitate e "x" ed.
  4. L'amministratore seleziona le autorizzazioni dalle restanti opzioni attive.
  5. Successivamente, nella schermata di gestione utenti o nel profilo utente, l'amministratore visualizza l'elenco dei ruoli che l'utente può avere in base alla licenza e l'amministratore ne seleziona uno o più.
1
Matt

In generale, la mia regola empirica va in questo modo (e ho bisogno di avere una buona ragione per infrangerlo): se il ragionamento alla base del componente disabilitato scorre dal contesto o che la comprensione dovrebbe essere facile per l'utente a causa di altri motivi, quindi il blocco è la soluzione preferita. Altrimenti, l'utente potrebbe essere frustrato nel cercare di capire perché è così, e peggio ancora, probabilmente non ricorderà il motivo (caso lo abbia capito) la prossima volta che lo incontrerà.

1
Assimiz

Per rispondere alla tua domanda specifica, desideri visualizzare informazioni sufficienti in modo che gli utenti possano comprendere le limitazioni prima di fare clic. Nel tuo esempio, dovresti elencare ogni utente con la sua licenza come un campo di sola lettura collegato visivamente (ad es. Per prossimità) con i controlli per impostare il loro permessi. Oppure puoi combinare il campo della licenza in modo dinamico con l'etichetta per le autorizzazioni (ad esempio, "Autorizzazioni (con licenza limitata):").

Le autorizzazioni non applicabili probabilmente dovrebbero essere disabilitate, non abilitate e non nascoste. Se vale la pena ingombrare, includere testo in linea, testo al passaggio del mouse/descrizioni comandi o un collegamento per spiegare perché le autorizzazioni non consentite dalla licenza (il testo in linea può sostituire i controlli disabilitati se elenca le autorizzazioni; ad esempio "Amministratore , Finanziario non consentito per utenti con limitazioni ").

La regola generale è disabilita l'uso se l'utente può fare qualcosa nell'interfaccia utente per abilitare il comando. Disabilitato significa "puoi eseguire questo comando, ma proprio ora non è così come stanno le cose". Il "modo in cui vanno le cose" include la selezione attuale. Ogni volta che si utilizza la disabilitazione, dovrebbe esserci un'indicazione chiara in modo che gli utenti comprendano perché i comandi associati sono disabilitati per alcuni oggetti.

Utilizzare le finestre di messaggio invece di disabilitare se non esiste alcun modo per chiarire in anticipo all'utente il motivo della disabilitazione presupponendo che abbiano una conoscenza media del dominio. Le descrizioni comandi per i controlli disabilitati sono un'ottima idea, ma potrebbero non essere sufficienti da sole in tutti i casi.

Usa nascondiglio se l'utente non ha mai accesso al comando, indipendentemente da ciò che fa nell'interfaccia utente data la sua posizione corrente nell'organizzazione. Ad esempio, le azioni non autorizzate dall'utente in base alle autorizzazioni non vengono visualizzate. In questo caso è ingombrante e frustrante utilizzare le caselle di disabilitazione o di messaggio. Per quanto riguarda gli utenti, le azioni per le quali non hanno i diritti non sono il loro lavoro (altrimenti avrebbero accesso), quindi i controlli associati non dovrebbero semplicemente esistere nella loro interfaccia utente. I manuali delle procedure di documentazione o organizzazione possono indicare agli utenti come tali azioni vengono eseguite (ad esempio, "Il supervisore crea nuovi account cliente per te" o "È necessario disporre delle autorizzazioni finanziarie per modificare gli account; consultare l'amministratore per la procedura per ottenere l'approvazione per aggiornare le autorizzazioni. “).

Ho dettagli gory a Controllo dei controlli .

1
Michael Zuschlag

Alcuni dei punti precedenti sono fantastici e non voglio ripetere l'iterazione, ma ...

In questo caso, avrei tutte le opzioni disponibili visibili. Le opzioni che non erano applicabili nelle tue regole, dovrebbero essere disabilitate (in grigio). È noto a un utente di qualsiasi interfaccia riconoscere che se qualcosa viene oscurato, in genere significa che non è applicabile per una sorta di set di regole in corso.

Un suggerimento coincide perfettamente con un pulsante disabilitato. In alcuni casi speciali, più avanzati come il tuo sopra con le licenze, se l'utente senza la licenza corretta stava visualizzando un'area che richiedeva una licenza superiore, cambiando completamente l'arte del pulsante in qualcosa come "Aggiorna ora!" invece di ingrigirlo sarebbe una migliore pubblicità per il prodotto, e ottenere il punto.

Se l'utente amministratore lo stesse visualizzando, vedrebbe ovviamente che l'opzione finanziaria è disattivata, con una descrizione che spiega perché.

Non conosco completamente il contesto del problema, potrebbe non esserci nemmeno un prodotto coinvolto. Ma sulla base di ciò che ho capito, questa è la mia reazione ad esso.

1
user708

Windows UXGuide ha molte risorse che possono aiutarti a decidere se mostrare errori o impedire input non validi. Nello specifico c'è na sezione che fa la seguente dichiarazione sull'interfaccia utente.

Non dare messaggi di errore quando è improbabile che gli utenti eseguano un'azione o cambino il loro comportamento come risultato del messaggio. Se non è possibile eseguire azioni da parte degli utenti o se il problema non è significativo, eliminare il messaggio di errore.

Anche questa discussione mi ricorda un po 'quello che Karl Shifflett nel suo post sul blog intitolato "Fort Knox Business Objects (sì/no)" dove valuta i pro e i contro se consentire agli oggetti business di entrare uno stato non valido o meno e in che modo questa decisione influisce sull'interazione dell'utente.

Personalmente, tendo a impedire a un utente di inserire voci non valide o di disabilitare i controlli che eseguono azioni come pulsanti per la maggior parte del tempo, ma per alcuni controlli che implicano l'inserimento di testo complesso tendo a mostrare avvisi incorporati che sono meno invadenti delle finestre di messaggio ma continuano a ottenere il punto attraverso.

0
jpierson

Fare entrambe le cose: Backend e UI

Questo in realtà non dovrebbe essere né uno né una situazione. Le altre risposte elencano i buoni motivi elencati per mostrare le opzioni non disponibili e i buoni motivi per non mostrarli. Ma il fatto è che, in entrambi i casi, è necessario gestirlo correttamente sul back-end. È ancora necessario controllare correttamente gli input e le autorizzazioni dell'utente, anche se si ritiene che l'unico input che possano fornire sia corretto.

Ciò è doppiamente vero con qualsiasi applicazione basata sul web, in cui l'utente potrebbe abilitare artificialmente un controllo/opzione/input disabilitato. Non lasciare che Firebug superi la capacità della tua app di controllare ciò che posso fare. E nei casi in cui provano a utilizzare un'opzione che non dovrebbe essere disponibile, assicurati di registrare l'evento.

0
Jeffrey Blake