it-swarm-eu.dev

Perché esiste una convenzione sul Web per i menu a discesa al passaggio del mouse anziché al clic?

Questo è qualcosa che mi sono sempre chiesto. Su tutti i principali sistemi operativi, i menu dell'applicazione (File/Modifica/Visualizza ecc.) Vengono visualizzati solo con un clic. Tuttavia, quasi tutti i siti Web che utilizzano un menu a discesa lo istanziano al passaggio del mouse, non al clic.

Come e perché è nata questa convenzione?

19
DisgruntledGoat

Non ho idea dell'effettiva risposta corretta a questa domanda, ma lasciatemi speculare: penso che sia perché il web ha collegamenti ipertestuali. Fare clic su qualcosa in un sito Web è associato alla visita di una pagina diversa e, in quanto tale, se si dovesse creare un menu a discesa che si attiva al clic, l'aspettativa di ciò che può fare quando attivato è incerta: mi indirizzerà verso un nuova pagina o aprirà un menu? Quindi se continui questa linea di logica, la creazione di menu al passaggio del mouse ha molto senso, perché prima che un utente faccia clic puoi presentarli con un feedback che indica che hanno attivato un menu.

Può anche essere considerato il famoso internet problema di deficit di attenzione, da cui provengono tutti i numeri che mostrano le persone che stanno in giro sulla tua pagina per pochi secondi. So che il concetto di "utenti non fanno clic" è un mito, ma molte persone non lo fanno e può portare all'implementazione di molti menu utilizzando lo stato hover perché i progettisti si aspettano che gli utenti non facciano clic perché pensano potrebbe condurli a una pagina diversa.

Inoltre, immagino che sia un ciclo ripetitivo: i designer vedono i menu a comparsa e progettano i menu a comparsa, che più designer vedono e più designer progettano. Non tutti pensano a ogni singolo controllo dell'interfaccia utente che stanno usando in termini di perché ne hanno bisogno e quale scopo ha; molti designer con cui ho lavorato scelgono i controlli "perché è quello che usi" (vedi: uso eccessivo incessante della casella combinata con completamento automatico; un rant per un'altra volta).

Contrasta quanto sopra con le app desktop di razza in cui non c'è (di solito) uno stato al passaggio del mouse, certamente non come modello di interfaccia utente per i menu e penso che siamo tornati al punto di partenza.

20
Rahul

Solo un'ipotesi, ma hover è probabilmente usato al contrario di onclick perché css ha una pseudo-classe: hover.

O forse è stato utilizzato il menu a discesa perché l'utente non si è reso conto di dover fare clic per aprire il menu. La metà delle volte, un menu a discesa assomiglia a qualsiasi altro menu fino al passaggio del mouse. E l'azione prevista quando fai clic su un pulsante di navigazione è che il sito ti porti a quella pagina. Quindi forse gli utenti semplicemente non stavano trovando le opzioni di menu aggiuntive.

4
LoganGoesPlaces

Rahul fa un punto interessante riguardo alla mancanza di un'azione coerente su un "clic"; tuttavia, penso che vada oltre questo in un senso più generale di rilevabilità sulla superficie della pagina.

Le persone potrebbero non fare clic a causa del desiderio di non lasciare una determinata pagina, ma molte persone "passeranno il mouse" sulla pagina alla ricerca di stati attivi. Poiché i menu reagiscono al passaggio del mouse e non al clic, l'utente può scoprire più facilmente la struttura del sistema di menu senza ricorrere ai clic.

Questo, ovviamente, porta a determinati problemi di accessibilità. Quando faccio clic su un menu in un'applicazione desktop, il comportamento predefinito è di lasciare il menu aperto fino a quando non faccio una scelta o di fare clic sul menu. Questo aiuta gli utenti che potrebbero avere difficoltà a manovrare il mouse con il comando corretto senza uscire dal menu (che lo comprime nel paradigma hover).

4
Steve Mitcham

Le app Web sono decisamente incoerenti in termini di UI, ma l'utente deve capirle rapidamente (altrimenti la sua attenzione si prosciuga e andrà altrove).

Il menu al passaggio del mouse ha una rilevabilità molto migliore: quando vedo un pulsante su un sito appena visitato, non ho idea se aprirà un menu con più opzioni (che voglio), o mi porterà via, distruggendo lo stato attuale di una pagina (incluso il commento scritto a metà) - che ovviamente non è quello che voglio. Ci vuole solo un po 'di siti con un'ultima pratica per farmi paura di fare clic su qualcosa che non conosco - e l'utente intimidito non è utente felice.

Con il mouse, esploriamo cose sullo schermo, il passaggio del mouse significa "Attualmente ti sto guardando", quindi è abbastanza naturale che l'elemento dell'interfaccia utente mostri ciò che fa (un menu) o un suggerimento (descrizione comando: questo eliminerà il post che stai scrivendo).

D'altra parte, non reagire al passaggio del mouse è scortese: l'utente chiede cosa fa l'elemento e tu non rispondi. La gente ama sentire di avere il controllo e sapere cosa sta succedendo; ogni feedback è importante e, non reagendo al passaggio del mouse, stai sprecando la possibilità di comunicare.

Nel nostro recente software desktop (componente aggiuntivo di Outlook TaskConnect ), siamo arrivati ​​al punto di mettere la descrizione della guida su ogni elemento attivo e impostare il timeout della descrizione su zero, facendolo apparire immediatamente. Puoi vedere un breve video di come appare in azione . Cosa ne pensi di questo?

PS: In ogni caso, anche il menu dovrebbe sempre apparire quando si fa clic, altrimenti gli utenti touchscreen o le persone tastiera (inclusi gli utenti disabili) non sarebbero in grado di usarlo.

4
Tomáš Kafka

In genere, la prima voce di un menu ti porterà alla pagina con quel titolo. Non vai da nessuna parte quando sei in un'applicazione. Il passaggio del mouse per le voci di menu è stato sviluppato come scorciatoia per visualizzare le sottosezioni all'interno di una particolare sezione del sito anziché dover andare alla pagina per visualizzare le sottosezioni. Con un'app non vai alla sezione "file", ad esempio. Abbandonare le convenzioni web per il touchscreen è un errore per me. Sono utili da tenere a mente e da guardare, ma spesso è meglio un'app progettata appositamente per il touchscreen. I siti Web non sono pensati per le dita.

3
srgtick

La "rilevabilità" è sicuramente un fattore qui.

La mia distinzione è lo stato d'animo dell'utente, soprattutto quando si confronta un'applicazione con un sito Web.

Quando fai clic, intendi fare qualcosa, eseguire una determinata azione: deve essere intenzionale.
Gli utenti di solito utilizzano applicazioni in questo stato d'animo.

Tuttavia, (alcuni) siti Web riguardano maggiormente il consumo di contenuti. Stai navigando, leggendo e forse eseguirai un'azione. È un dato di fatto, na delle maggiori sfide che induce i visitatori del sito a FARE attivamente qualcosa, non solo visitare. Quindi ha molto senso provare a spingerti a fare qualcosa mostrandoti le opzioni più facilmente.

C'è un'altra differenza tra i due stati mentali:
Di solito utilizzerai un'applicazione diverse volte, diventando quindi un po 'più familiare e competente con essa. Sul Web, è probabile che molti dei tuoi utenti siano nuovi, quindi potrebbero non sapere dove cercare le cose e potrebbero anche avere "paura" di impegnarsi a (fare clic) su qualcosa che non sanno.

2
Dan Barak