L'icona ad hamburger su desktop è dannosa, e ora è ufficiale | Usabile.it

Usabile.it

usabilità, accessibilità e interaction-design per il web

Home » Articoli » L'icona ad hamburger su desktop è dannosa, e ora è ufficiale

29/06/2016

L'icona ad hamburger su desktop è dannosa, e ora è ufficiale

[di Maurizio Boscarol]

Hamburger menu Le icone hamburger per far apparire i menu hanno bisogno della parola magica. Sì: "menu"

Ci stiamo arrivando un po’ tutti, più o meno contemporaneamente: semplicemente l’icona ad hamburger per i siti web desktop è una disgrazia e non andrebbe usata.

Che fosse controversa l’avevo già segnalato. Poi sono capitate un po’ di cose.

  1. Mi è capitato di fare dei test di usabilità su siti e applicazioni che usavano l’icona ad hamburger. Senza farla lunga: per chiunque non lavori nel settore informatico, quelle tre righette sono incomprensibili. Ovviamente diventano subito comprensibili se ci scrivete sotto, o a fianco, la parola “menu”. Questo quindi è il minimo sindacale.
  2. Ma un’altra cosa che non è chiara a tutti è che usare un’icona per far apparire un menu che normalmente nei siti desktop dovrebbe essere visibile senza fare niente, occulta contenuti e riduce il profumo dell’informazione. In pratica state nascondendo loro quello che offrite e dove possono andare.

Ribadisco che le due questioni sono distinte:

  1. la prima riguarda la comprensibilità di quella specifica icona, ed è risolvibile;
  2. la seconda riguarda la pessima idea di occultare le voci di menu principale anche dove lo spazio c’è, come sul desktop, dietro un qualunque tasto che richiede un’azione dell’utente.

Il NNGroup riporta anche diversi dati quantitativi, raccolti con test di usabilità remoti, che potrebbero convincervi di più, se i miei test, condotti con un numero inferiore di utenti, ma ripetuti in diverse tornate, e se i diversi articoli sul web non vi sembrano sufficienti.

La fascia in alto nasconde cose, ed è pure scomoda

A questo si aggiunge un terzo problema dei design mobile-first che stanno diventando tanto diffusi: spesso questi design prevedono che la fascia orizzontale che contiene logo, icona ad hamburger e qualche altra icona/funzionalità, come i social o la ricerca, rimangano visibili, magari minimizzandosi con un’elegante animazione, nella parte alta della pagina, facendo scorrere sotto il contenuto. Ebbene, pessima idea anche questa per tre ragioni:

  1. In schermi orizzontali, si riduce lo spazio verticale di lettura; su display non enormi come i tablet, questo può essere anche fastidioso. Tanto più se accoppiato magari con il banner dei cookie che improvvidi regolamenti hanno reso obbligatorio in tutta europa, e su cui torneremo.
  2. Si interrompe il corretto funzionamento dello scrolling che utenti un po’ esperti adottano premendo la barra spaziatrice per scorrere più rapidamente (ma anche cliccando sulla parte vuota della scroll-bar laterale). Così capita che scorrendo a pagine, rapidamente, alcune righe di testo vengano coperte da questa simpatica quanto inutile barra orizzontale bloccata in cima alla pagina.
  3. Infine, in alcune particolari situazioni (che curiosamente sono capitate proprio nei test di usabilità di cui sopra), questa barra può coprire i messaggi di errore o di conferma che in alcuni pattern di design vengono mostrati in cima alla pagina; questo può avvenire del tutto o in parte, ma se l’utente non se ne avvede, magari perché poco avvezzo al pattern (e, indovinate un po’: capita) e magari inizia a scorrere la pagina, anche solo di poco, questo messaggio non verrà mai notato e letto. Può capitare anche senza questa fascia in alto, ma con la fascia la probabilità che capiti aumenta, perché basta uno scorrimento minimo.
Scorrendo, un eventuale messaggio in cima alla pagina finisce per scomparire sotto la fascia bloccata in alto.

Non si sta dicendo che su mobile un design di questo tipo non abbia senso:

  • infatti, su mobile lo spazio è poco, e aprire un menu mediante un tasto è sensato;
  • inoltre, lo sviluppo è principalmente verticale, quindi non si ha l’effetto di accorciamento percettivo dell’area di testo;
  • infine, non esistono le barre spaziatrici e quindi non si verifica neanche l’ultima categoria di problemi.

Su mobile, basta accertarsi di usare la parola “menu” vicino all’icona, o mostrare alcune voci e poi far comparire le altre con un tasto, come suggerisce il NNGroup.

Mobile-first non vuol dire mobile-only: e lo dice gente importante

Ma, ecco, il problema è proprio nell’interpretazione del significato di “mobile-first”: come sottolineano proprio Kara Pernice e Raluca Budiu che hanno redatto l’articolo per il NNgroup, non significa “mobile-only”. Se un design funziona su dispositivi mobili touch di piccole dimensioni, non basta ingrandirlo a tutto schermo affinché funzioni anche su desktop. Esistono i breakpoint dei CSS per consentirvi di rimodulare il design, eliminando del tutto icona del menu e mostrando da subito le voci principali di default sul desktop, evitando di lasciare inutili fasce coprenti in cima.

Naturalmente, potreste anche fidarvi delle mode, anziché dei molteplici risultati empirici che dimostrano che si tratta di cattive pratiche, e pensare che siamo noi specialisti di usabilità ad essere un po’ fissati. Ma il problema delle mode di design è che solitamente devono prima prender piede, affinché ci si accorga che sono sbagliate. Succede da sempre, non solo nel web-design. Interi quartieri in città importanti hanno afflitto generazioni di inquilini, perché andava di moda (e per convinzioni civilmente degnissime) il cemento armato: per fortuna nel web-design le conseguenze sono meno gravi…

I design di siti commerciali e istituzionali devono essere verificati con la ricerca e con i test di usabilità e adattati caso per caso. Specialmente poi se pensate di farli durare a lungo, o, il cielo non voglia, se avete in mente di renderli obbligatori – o anche solo consigliati – per un’intera famiglia di siti. O addirittura per un’intera categoria di siti.

Ma siamo certi che nessuno lo stia pensando.

Ne siamo certi, vero?

Tag: ,

Iscriviti alla newsletter di usabile.it:

Circa una mail al mese con gli aggiornamenti più significativi.

Commenta

  1. Danilo Spinelli - 30 giugno 2016, 19:58.

    Ciao Maurizio, ho letto con interesse (avevo già avuto modo di visionare l’articolo sul sito del nng), concordo in parte con quanto scritto e porto a “casa” le considerazioni della chiosa, vista anche l’elevata considerazione della tua professionalità che (qui) abbiamo tutti ;) e al sincero interesse nell’argomento. Detto ciò, alcune considerazioni.

    Per quanto riguarda i siti pilota della PA il menu già visibile su desktop è presente in quasi tutte le pagine interne (sulla destra); nello specifico l’argomento dell’analisi dovrebbe quindi limitasi al caso particolare del menu nascosto in home. O meglio quasi nascosto: negli ultimi siti, che usciranno a breve, è prevista su desktop una fascia orizzontale contenente le voci principali di navigazione che puntano a “home di sezione” (più versatili di un menu nella presentazione di liste e contenuti).

    Inoltre vengono applicate le raccomandazioni prescritte su https://www.nngroup.com/articles/support-mobile-navigation/: se i contenuti sono presentati in maniera efficace e le sezioni a cui le voci del menu (nascosto) afferiscono sono accessibili direttamente all’interno della pagina (che diventa essa stessa il menu), l’hamburger si rivela un “qualcosa in più”. È una concezione che riavvicina al web degli “albori”, dove l’ipertesto costituiva esso stesso La navigazione. Daltronde è lo stesso pattern utilizzato dai siti gov.uk, testati, usabili e che a malapena hanno un menu globale (quando lo hanno).

    In merito alle considerazioni sulla fascia orizzontale ‘fissa’ è vero che “riduce lo spazio verticale di lettura su display non enormi come i tablet”; tuttavia è il medesimo comportamento che hanno il 99% delle app native che quindi, sembrerebbe esser tollerabile. Inoltre andrebbero messi sul piatto anche i vantaggi dell’header fisso: la possibilità di accedere alle funzionalità di ricerca e al menu indipendentemente dal punto di scroll.

    La 2. è un caso specifico della 1. (viewport verticale ridotta), la 3., come tu stesso riporti, si verifica anche senza header fisso e andrebbe eventualmente quantificato l’aumento della probabilità che capiti il caso peggiore.

  2. Ale - 1 luglio 2016, 22:06.

    Il punto di vista è corretto. Soprattutto per un e-commerce. Peccato che poche aziende in Italia, che vendono online, sfruttano veramente una strategia di usabilità ( e ne capiscano il costo e il valore) per aumentare le conversioni.

  3. Maurizio Boscarol - 7 luglio 2016, 15:53.

    Danilo, già ti ho espresso le mie considerazioni, ma lasciami ribadirle qui a beneficio di chi legge:

    * Il menu nascosto in Home non è un dettaglio: la home è una delle pagine più importanti, e il menu assieme al contenuto è ciò che consente di capire cosa fa il sito e dove può andare l’utente. Anche nelle altre pagine, il menu laterale che appare è quello di sezione, non quello principale (che almeno fino al secondo livello credo convenga tenere).
    * Più in generale, il tema è quello della visibilità (di cosa c’è e di cosa si può fare) o, in un altro senso, del profumo dell’informazione. Chi può stabilire quanti link servano per far capire la ricchezza di un sito? In un sito pubblico complesso, non ne bastano di certo 3, o 5. Un equilibrio ci vuole, ma perché non prevedere soluzioni multiple (come fare un menu orizzontale a 3 + altro, uno a 5 + altro, uno fino a 10 voci, ecc), che coprano esigenze diverse?

    Ecco, se linee guida devono essere, il rischio che vedo è quello della prescrittività, che peraltro è pratica vecchia (legge Stanca, menu trasparenza di brunettiana memoria…). I risultati sono un utilizzo scarso da parte dei cittadini di quelle soluzioni.

    A meno che non vogliamo continuare così, solo impaginate meglio, non vanno imposte soluzioni, vanno previste facilitazioni. Per ogni pattern, prevedere implementazioni corrette e scoraggiare quelle scorrette.

    E poi insistere sul processo: un buon sito web parte dall’analisi delle esigenze degli utenti, come sai, non dall’applicazione di un menu nascosto o a 3 voci. Limitare i pattern disfunzionali è importante, ma anche consentire di trovare soluzioni adatte al caso, e prevedere una libreria di implementazioni testate e corrette per una varietà di casi, è ancora più importante.

    Linee guida di supporto al processo centrato sull’utente. Questo io immagino debbano essere. Non elenchi di prescrizioni rigide di pattern magari non testati.

    E se un pattern peggiora, anche di poco, l’esperienza (come lo header fisso), non consigliarlo! Trovare soluzioni migliori: la funzione di ricerca può anche essere disponibile in colonna, o in altri modi che non impattino sullo scorrimento.

    Non è nemmeno obbligatorio normare tutto, devo anche dire. Anche perché non tutto è normabile. Ma tutto è valutabile: si può cioè capire se una cosa ha funzionato, sta funzionando, o meno. Insisterei su questo processo di verifica e miglioramento, piuttosto: pratica che si fa poco nei siti privati (come dice anche Ale), e ancora meno in quelli pubblici.

  4. Livio - 7 luglio 2016, 16:33.

    Boh, ora si stanno un po’ mischiando gli argomenti, credo. Nel senso una cosa è la discussione su un componente, un’altra introdurre la discussione in un progetto come quello delle linee guida di design per la PA. Concordo con quanto dice Maurizio a proposito dell’approccio prescrittivo, anche se nel caso della Stanca si trattava di prescrizione di legge e non di teorica linea guida (anche se secondo me quelle contenute in quel sito nella forma attuale non sono linee guida…).
    A me personalmente quel SI DEVE tutto in maiuscolo fa un po’ ridere, ma ok opinione personale.
    L’approccio Bootstrap/Mobile First secondo me con le PA proprio non ci azzecca, burger o meno.
    Forse esistono delle scelte effettuate dallo staff che hanno portato all’uso di questi tool, ma non c’è alcuna documentazione al proposito sul sito, e credo che questa sia proprio la maggiore mancanza.

    Una possibile lettura: http://www.forbes.com/sites/roberthof/2014/02/27/mobile-first-is-dead-says-google-display-ad-chief-neal-mohan/#594b92df4784

  5. Danilo Spinelli - 13 luglio 2016, 10:59.

    Premessa: per sua stessa natura, il progetto delle LG è in divenire; a maggior ragione in questa fase considerata di “discovery”. nell’ottica “user-centered”, esaltata dal progetto (a proposito di processo), vanno raccolti i feedback degli utenti ed effettuati test di usabilità che portino a modifiche costruttive (di cui alcune già visibili). sono inoltre in consultazione pubblica: chi vuole può portare il proprio contributo che verrà messo all’ordine del giorno.

    > Il menu nascosto in Home non è un dettaglio

    Vero; è tra i motivi che hanno portato a inserire un menu orizzontale nei nuovi siti pilota. Un numero massimo di voci da consigliare è utile per evitare l’affollamento di quelle non essenziali, inducendo a tener fuori contenuti non prioritari, collocando le voci di utilità (contatti etc.) in posizioni prevedibili e coerenti trasversalmente ai vari siti.

    Per quanto riguarda funzionepubblica.gov.it, è vero che non ha un menu orizzontale visibile in home, tuttavia le voci di primo livello sono contenute in posizione preminente all’interno della pagina stessa (i box “blu”). Questo approccio, oltre ad essere facile da implementare tecnicamente, ha il vantaggio di tenere le voci di menu in evidenza sia su desktop sia su mobile dove risulterebbero invece nascoste utilizzando un menu orizzontale. È l’approccio che sul nngroup chiamano “The Navigation Hub” (https://www.nngroup.com/articles/mobile-navigation-patterns/) e, nel caso specifico, viene integrato dal burger menu. Con le parole di L.Wroblewski: “content first, navigation second” (cfr. http://alistapart.com/article/organizing-mobile)

    > il rischio che vedo è quello della prescrittività, che peraltro è pratica vecchia
    > non vanno imposte soluzioni, vanno previste facilitazioni

    Vero anche questo. Tuttavia va considerato anche il rischio opposto. Il discorso sul livello di prescrittività è delicato. Lasciare aperte troppe alternative si tradurrebbe in una sostanziale immutabilità rispetto alla situazione odierna (tutt’altro che rosea); favorirebbe il persistere di un’attitudine sciovinista ed egotica da parte delle PA, dove chi prende le decisioni tecniche spesso non è un esperto della materia; non aiuterebbe il cittadino costretto a orientarsi in sistemi di informazione incoerenti e complessi.

    Uno degli obiettivi a breve termine è avere una raccolta di “best practice” da poter incorporare rapidamente in un capitolato che vincoli il fornitore e/o i livelli amministrativi all’interno della PA. In mancanza di LG adeguate, chi redige i capitolati oggi è costretto a reinventare tali best practice per assicurare la qualità dell’output. Questo avviene nella migliore delle ipotesi e con grande spreco di ore uomo. Lasciare il tutto sul puro piano di “consigli generali” pregiudica il perseguire tale obiettivo.

    Inoltre c’è il discorso sul riuso e la qualità del software. Riuscire a convergere su un ristretto numero di pattern condivisi è un fattore abilitante per instaurare una collaborazione su un toolkit riutilizzabile, che garantisca qualità (es. compliance alle norme sull’accessibilità) e coerenza (es. tramite elementi grafici condivisi).

    Tutto ciò è in linea con le best practice internazionali (canadian web experience toolkit, swiss confederation web guidelines, govuk frontend toolkit, web design standards americani, …), dove in alcuni casi ci si è spinti ben oltre il suggerimento delle best practice. Per dirne una: “The corporate design elements identify the website definitively as websites of the Confederation and for this reason their use is obligatory. Their presentation and design are set out in the Confederation CD, and they may not be modified in any way.”

    È chiaro che va mantenuto un equilibrio che possa garantire l’efficacia tenendo aperte le “varie” possibilità. È un percorso complesso e pertanto va condiviso; il compito è arduo e l’apporto esterno fondamentale.

    A questo proposito segnalo che non c’è un “pensiero unico” tra chi redige le LG; pertanto portare questo tipo di discussioni dove possono esser viste e commentate da tutti aiuta a orientare le decisioni in maniera più rapida e/o ad aprire tematiche che magari sono state colpevolmente trascurate. È un invito a tutti coloro che sono sinceramente interessati all’argomento: i canali di comunicazione ci sono, usiamoli.

    > consentire di trovare soluzioni adatte al caso, e prevedere una libreria di implementazioni testate e corrette per una varietà di casi, è ancora più importante

    Questo è il piano. Per testare, valutare e correggere le diverse soluzioni bisogna tuttavia prima metterle in atto.
    Anche riguardo la vexata quaestio del burger non esiste un pensiero universalmente condiviso:

    http://usabilitygeek.com/making-case-for-desktop-hamburger-menu/
    http://www.andybudd.com/archives/2016/01/in_defence_of_the_hamburger_menu/
    https://adactio.com/journal/10120
    http://www.uxmatters.com/mt/archives/2015/05/why-its-totally-okay-to-use-a-hamburger-icon.php

    articoli che sostanzialmente convergono sul fatto che “when used correctly, with clear calls-to-action and the right in-page content, you might just be surprised to see that it can offer your website a distinct advantage”.

    Per concludere, oltre alle giuste e costruttive critiche ci sono state anche parole di apprezzamento (meno sonore) da parte degli utenti. Per quanto riguarda le “prescrizioni” nelle LG, è l’utente che comanda; l’impegno è garantire che ciò che dovrà esser rivisto, lo sarà (e per tempo).

  6. laura - 15 luglio 2016, 17:50.

    Maurizio sono d’accordo con te. Leggo prescrittività nelle Linee guida ma ben poco “processo”.

  7. Fabrizio Caccavello - 23 agosto 2016, 23:55.

    Intervengo sulla discussione un po’ in ritardo ma l’argomento è stato ritirato fuori da un mio collega e così ho ripreso questo tuo pezzo.
    Alle valutazioni di Maurizio, che condivido, aggiungo una riflessione.
    Nei design si sta mettendo in atto da tempo un processo di semplificazione, io per esempio ne parlavo già nel 2008 http://www.webaccessibile.org/le-basi/la-struttura-dei-layout-togliere-il-superfluo-e-aggiungere-cio-che-e-significativo/
    Ma semplificare non significa “ridurre” o “nascondere”. Significa l’opposto, eliminare il superfluo e dare più enfasi alle cose significative.
    Ecco, l’hamburger, al contrario, nasconde il significativo.


 

torna su Torna su

Privacy Policy