it-swarm-eu.dev

Esistono prove che suggeriscono che la progettazione di schede all'interno di schede crea un'esperienza utente negativa?

Sto progettando un'applicazione Web complessa e il mio collega ritiene che l'utilizzo di un pannello a schede sia una cattiva idea. Sono più ambivalente.

Qualcuno può indicare eventuali prove (aneddotiche o basate sulla ricerca) che potrebbero aiutare a chiarire se dovrei evitare questa pratica.

Ho fornito un esempio qui .

23
cmoller

Caspita, sarò l'unico a rispondere in questo modo: Va bene nel giusto contesto!

Il tuo esempio è il contesto sbagliato. I passaggi di una procedura guidata non sono schede. Tuttavia, va bene usare le schede all'interno delle schede se segui le regole ::

  1. Ogni livello di schede dovrebbe differenziarsi visivamente stessi, quindi è chiaro su quale livello di organizzazione stai lavorando.
  2. Numero limite di schede. L'infinito è cattivo. 5 è il massimo. (Mostrato sotto).
  3. "ON" gli stati devono essere estremamente chiari. Usa un colore caldo per assicurarti che sia ovvio. L'utente dovrebbe sapere dove sono in ogni momento senza pensarci.
  4. Non lesinare su architettura dell'informazione. Le schede sono una funzione dell'organizzazione. Sii creativo e assicurati che l'organizzazione sia intuitiva.
  5. Assicurati che le schede siano realmente schede e non passaggi. (Il tuo esempio)

Esempio complesso. Un'applicazione B2b con navigazione intensa e molto al suo interno.

enter image description here

Un altro esempio, da un'applicazione che ho progettato nel 1998:

enter image description here

16
Glen Lipka

Le schede nidificate violano le Linee guida per l'interazione con l'esperienza utente di Windows per Windows 7 e Windows Vista (vedi pag.1182). Ciò include la combinazione di schede orizzontali con schede verticali nella stessa finestra. È probabile che abbiano molte prove per vietarlo. Il problema è che gli utenti possono facilmente confondersi su quale pagina di quale scheda si trovano e confondersi su dove fare clic.

L'unico motivo per nidificare le schede è se disponi di informazioni organizzate gerarchicamente. Tuttavia, ci sono molte altre opzioni per la navigazione delle informazioni gerarchiche. Pangrattato e alberi vengono subito in mente.

Nel tuo esempio, non sono sicuro che tu abbia davvero informazioni gerarchiche. Gli utenti torneranno ai passi arbitrari dei passaggi secondari? E in tal caso, con quale frequenza sarà il Sottotitolo predefinito/visitato per ultimo di quel Passaggio? C'è qualche motivo per distinguere tra Passaggi e Passaggi secondari? Perché non fare solo tutti i passaggi? Se hai bisogno di fornire un quadro concettuale, forse è sufficiente farlo con un testo statico (ad esempio, "Progetta il tuo cyborg (passaggi 1-5), programma il tuo cyborg (passaggi 6-8), fai il caos con il tuo cyborg (passaggio 9 )”)

6
Michael Zuschlag

L'esperienza dell'utente riguarda il contesto, quindi è possibile che ci siano situazioni in cui le schede all'interno delle schede potrebbero avere un senso e se implementate correttamente potrebbero fornire una buona esperienza utente.

Tuttavia, come regola generale, penso che sia qualcosa che dovrebbe essere evitato a meno che tu non abbia prove per dimostrare che è la soluzione più appropriata per la situazione in questione.

Per quanto riguarda il contesto specifico in cui vuoi usare le schede nidificate (il tuo esempio), penso che siano completamente inappropriati e privi di senso! Le schede consentono l'accesso casuale (al contenuto delle schede), ma si sta tentando di implementare un processo (lineare) basato sui passaggi, quindi anche un singolo set di schede per i passaggi sarebbe lo strumento (di navigazione) sbagliato per il lavoro, lascia che schede di nidificazione da sole all'interno di schede!

Ti suggerisco di limitare la navigazione all'interno del processo dei passaggi a avanti e indietro (e un'uscita/interruzione) e se i tuoi passaggi richiedono davvero passaggi secondari/attività, elencali nelle sezioni della pagina per il loro passaggio padre.

4
MarcusTucker

Sì * con un asterisco. Ma la prima domanda che vorrei porre è questa:

In quale altro modo possiamo risolvere questo problema di progettazione?

Se le alternative non sono piacevoli e semplici, allora - nonostante il fatto che le schede nidificate siano contro Microsoft Guidelines - considererei una soluzione tabset-on-a-tab. Perché? Poiché i progettisti di GUI non hanno sempre il compito di risolvere problemi semplici, soprattutto al di fuori del dominio del Web, in cui i client possono portarti problemi molto più complessi di "Dillo all'utente X" o "Vendi l'utente X" e dove gli utenti potrebbero avere esigenze specifiche che ti impediscono di temporizzare un'attività complessa in passaggi simili a una procedura guidata o di semplificare l'interfaccia utente rivelando progressivamente i controlli occasionali o qualsiasi altro trucco che i progettisti possano utilizzare.

Penso che, con un'ampia interpretazione di tabs, la risposta a questa domanda sia Sì * con un asterisco. L'asterisco segue: Forse i set di schede dovrebbero differire nell'aspetto (il che può, a sua volta, farti nome loro qualcosa diverso dalle schede - come la navigazione bar, persiane, maghi e così via). Qualunque cosa tu faccia, quando il tuo design è complesso, controlla il tuo prototipo con gli utenti; trovano le tab-on-tab troppo complesse? In tal caso, rileggi il primo paragrafo sopra e preparati a ripetere.

Su una nota personale, un progetto complesso a cui sto lavorando avrà presto un prototipo funzionante che include la navigazione nidificata. Non vedo l'ora di fare qualche test con gli utenti, per vedere come vanno. Tra un mese, avrò testato il progetto con utenti reali e proverò ad adattarlo se i test degli utenti rivelano problemi importanti.

4
JeromeR

Ciò non dovrebbe richiedere alcuna ricerca. È sicuramente confuso avere schede sotto schede, almeno in modo grafico. È possibile utilizzare la logica delle schede ma senza l'aspetto delle schede. Ciò che mi preoccupa di più è che vedo la parola "Step" che mi fa domandare se la tua intenzione iniziale sta portando l'utente a fare alcuni passaggi di configurazione/impostazione attraverso le schede. Se lo fai, ti consiglio vivamente di usare un mago.

3
Harris

Dipende sempre da come sono resi. Dai un'occhiata testo alternativo http://www.ubuntu-pics.de/bild/54446/screenshot_017_69kTK2.png . Sono presenti ovunque, ma probabilmente non influenzeranno l'esistenza di schede sotto di essi.

Nel tuo esempio, le schede erano troppo vicine l'una all'altra da far sembrare che ogni scheda "madre" non contenesse altro che un altro gruppo di schede. Sembra imbarazzante.

Come quello che ha detto Charis, la logica delle schede può essere eseguita senza l'aspetto delle schede. Non credo che ci sia uno studio là fuori che direbbe che una logica di tabulazione non dovrebbe essere usata all'interno di una logica di tabulazione. La maggior parte dei siti lo fa, incluso UXExchage. Questo problema riguarda il modo in cui le cose vengono visualizzate visivamente.

In questo caso, puoi utilizzare le frecce che mostrano i passaggi anziché le schede.

3
Allan Caeg

Una volta ho usato le schede all'interno delle schede di una complessa applicazione Intranet, ma abbiamo usato le schede orizzontali per la navigazione principale e la navigazione secondaria usate schede verticali - un po 'come un file o una cartella - insieme a codici colore distinti e ha funzionato abbastanza bene.

Sfortunatamente non ho un'immagine da mostrarti, ma abbiamo seguito da vicino la metafora della "cartella" perché abbiamo pensato che gli utenti target (un dipartimento governativo) l'avrebbero facilmente riconosciuta e che i test degli utenti avessero portato a termine questa ipotesi.

Spero che aiuti.

2
Robert Grant

Sono con Charis: le schede nidificate dovrebbero essere assolutamente evitate e poiché il tuo mockup suggerisce che gli utenti stanno lavorando attraverso un processo lineare passo-passo, quindi una procedura guidata o una barra di avanzamento (ad esempio http://developer.yahoo.com /ypatterns/navigation/bar/progress.html ) potrebbe essere più appropriato?

1
Tom