Funzionalità rivelatrici (schede) man mano che l'utente immette più dati
Supponiamo che abbiamo un'applicazione in cui l'utente può aggiungere i suoi eventi. L'applicazione ha 4 funzioni principali (rappresentate come schede orizzontali quando l'utente accede):
- vista del calendario
- visualizzazione elenco
- vista grafico
- importare eventi
La scheda n. 2 (visualizzazione elenco) non presenta nulla di utile se non è stato inserito almeno 1 evento.
La scheda n. 3 (vista grafico) non fa nulla di utile se non sono stati inseriti almeno 4 eventi.
Le mie 2 opzioni:
- Tutte e 4 le schede sono visibili anche quando l'utente è nuovo e non ha eventi inseriti nel sistema. Un utile messaggio sulla scheda # 2 e # 3 informerà l'utente che non ci sono abbastanza eventi (dati) per questi pannelli/funzionalità per visualizzare qualcosa di utile.
- Rivela dinamicamente la scheda # 2 quando l'utente inserisce il suo primo evento e rivela la scheda # 3 quando l'utente inserisce il suo quarto evento. La rivelazione delle schede (funzionalità in realtà) verrà effettuata con un messaggio appropriato del modulo "Visualizzazione elenco attivata!".
Quale dovrei scegliere?
Non sono sicuro di quale percorso scegliere perché temo che:
- il percorso 1 confonderà i nuovissimi utenti (che si sono appena registrati) che non sapranno da dove iniziare (anche se la scheda predefinita è # 1 e nelle schede # 2 e # 3 c'è un messaggio che spiega la situtazione)
- il percorso 2 renderà l'applicazione molto vuota per gli utenti che si sono appena registrati. Potrebbe essere che li confonderebbe anche a causa delle nuove schede che compaiono iniettate tra le schede n. 1 e n. 4?
Sono d'accordo con te. Entrambi gli approcci hanno pro e contro.
Consiglierei di deriderli o di sviluppare un prototipo rapido e testarlo con un paio di persone, vedere cosa ne pensano! (test, test, test dovrebbero essere il tuo mantra, quando sviluppi UI: P)
Ma, nella mia esperienza, ti consiglierei di mantenere i menu statici, per evitare possibili confusioni sugli utenti: "perché il menu è cambiato quando ho inserito il mio X evento?", "Perché è andato via quando ho eliminato un evento ?". I meccanismi interni che hai descritto sembrano piuttosto semplici/diretti, ma non vedo alcun vantaggio nel nascondere 2 di 4 opzioni per evitare confusione, quando ciò introduce già un po 'di confusione :)
Preferirei che l'opzione 1 sia meno confusa, probabilmente. Ma la tua migliore opinione specialistica viene dagli utenti che testerai.
Vuoi link per i libri di Krug? o hai letto il sito web di Nielsen? Dovresti!
L'opzione 1, schede statiche con messaggi utili, dovrebbe andare bene. Ricorda, i tuoi utenti non sono stupidi. Quando ricevono istruzioni sulla situazione (dovrebbero avere più eventi per rendere utile una determinata scheda), la comprendono molto meglio della confusione creata dalle schede che appaiono e scompaiono mentre non hanno una ragione chiara per cui ciò accada .
E sono assolutamente d'accordo sul commento di José sui test con i modelli! È possibile ottenere il feedback più accurato dagli utenti finali effettivi del software. Basta non fare affidamento solo sulle loro opinioni o commenti, vedere di persona come usano il sistema (o mockup nei primi sviluppi).
Non è necessario disporre di un massiccio arsenale di utenti per i test costanti: se hai colleghi che puoi utilizzare ogni tanto, test di usabilità in corridoio può essere tuo amico e risparmiatore.
È chiaramente il numero 1. Un semplice
Nessun evento inserito. Crea nuovo evento
dovrebbe aiutare con tutti gli utenti alle prime armi.
La divulgazione progressiva non è male, batte interfacce "solo per principianti" (come i maghi) che non forniscono una transizione graduale alla "modalità esperto". Tuttavia, è necessario bilanciarlo con una struttura di navigazione di livello superiore stabile.
Non spostare oggetti. Aggiungere schede alla fine è meglio che inserirle nel mezzo. Questo aiuta anche a supportare ( "seleziona la seconda scheda" ).
Rendi ovvie le dipendenze: i controlli che si influenzano a vicenda dovrebbero essere sulla stessa pagina. Quando la casella di controllo [C] abilita l'elenco [L], la casella di controllo deve essere disponibile quando l'utente cerca l'elenco, e l'elenco deve mostrare/nascondere quando l'utente attiva/disattiva la casella di controllo.
Mantenere un flusso logico: nelle culture LTR, un controllo dovrebbe influenzare solo ciò che è direttamente giusto o al di sotto di esso.
Le considerazioni sui dati UE dovrebbero sempre fornire un percorso chiaro dal caso "vuoto" al caso "un elemento dati" e quindi al caso "più di un" elemento dati.
Inoltre, non aver paura di includere la documentazione nella GUI! Per esempio. nel caso vuoto, esegui un'azione per creare un elemento, ma mostra anche un'illustrazione di come potrebbe apparire, con un'immagine o un video che illustra il punto.