Pulsante disabilitato interfaccia: perché il comando grigio esiste e quando invece va nascosto

Una scheda didattica su fondo avorio, due colonne bianche con angoli molto arrotondati, un titolo pesante in blu notte: Hide or Disable?. A sinistra un occhio sbarrato dentro un cerchio verde e la parola Hide, sotto una finta lista di impostazioni con icone sottili e frecce a destra. A destra un orologio dentro un cerchio azzurro, la parola Disable, e un finto pannello con un report in generazione, un grafico appena accennato e un pulsante Export report spento, grigio su grigio, con sotto una riga di testo che spiega quando tornerà disponibile. In fondo, una barra azzurra con una lampadina e due regole secche. È una di quelle grafiche che girano nelle bacheche dei progettisti d’interfaccia e che, proprio perché sembrano banali, meritano di essere prese sul serio: dietro quel bottone grigio ci sono quarant’anni di storia del progetto e un errore che vedo ripetere ogni settimana.

Che cosa fa bene questa scheda e dove si tradisce da sola

Partiamo da ciò che funziona visivamente. La struttura a confronto è chiarissima: due colonne speculari, stesso ritmo verticale, stessa gerarchia (icona, titolo, etichetta colorata, esempio, spiegazione, etichetta di sintesi). Il colore non è decorativo ma codifica: verde per il permesso negato, azzurro per la condizione temporanea. E, dettaglio non scontato, il colore non lavora mai da solo: ogni pastiglia colorata ha dentro una parola e un’icona, quindi chi non distingue bene verde e blu capisce lo stesso. È una regola che applico sempre quando disegno stati: il colore è un rinforzo, mai l’unico portatore di informazione.

Dove invece la grafica si contraddice è nell’esempio di sinistra. Per illustrare il concetto di nascondere, mostra una lista completa di comandi: rinomina area di lavoro, esci, notifiche, accessi, aspetto. Ma se quei comandi vanno nascosti, l’immagine dovrebbe farci vedere la lista senza di loro, cioè la versione pulita che l’utente non amministratore incontrerebbe davvero. Vediamo la premessa, non il risultato. È lo stesso problema di certi manuali che spiegano come togliere una parete mostrando la stanza prima della demolizione. La colonna di destra, al contrario, è molto più onesta: il bottone spento c’è, si vede, e sotto c’è la frase che ne spiega la ragione. Quella riga di microcopy è la parte più preziosa dell’intera scheda.

Il grigio spento nasce negli uffici degli anni Ottanta

La convenzione del comando visibile ma inattivo non è una trovata del web. Nasce con le prime interfacce a finestre e menu a tendina, quando bisognava insegnare da zero a impiegati e segretarie che dentro una barra in alto si nascondeva la mappa completa del programma. Il ragionamento dei progettisti dello Xerox Star, e poi di chi lavorò su Lisa e Macintosh, era che l’utente doveva poter esplorare il sistema senza paura: aprire un menu, leggere tutto quello che il programma sapeva fare, e capire per differenza che alcune cose in quel momento non erano applicabili. Cancellare le voci avrebbe reso il menu più corto e molto più ostile, perché la mappa mentale sarebbe cambiata a ogni clic.

Questa scelta è rimasta scolpita nelle linee guida di interfaccia dei sistemi desktop: le voci non disponibili si mostrano attenuate, il menu resta apribile anche se al suo interno non è utilizzabile nulla, proprio perché la gente deve poter imparare dove abitano i comandi. Ho lavorato su software gestionali dove qualcuno aveva deciso di ripulire i menu togliendo dinamicamente le voci non attive: il risultato, misurato sulle chiamate all’assistenza, fu un aumento di richieste del tipo ieri c’era e oggi non lo trovo più. La stabilità spaziale è una funzione, non un vezzo.

Affordance, significanti e il bottone che mente

Donald Norman ha passato anni a correggere l’uso disinvolto della parola affordance, arrivando a preferire il termine significante: non conta soltanto ciò che un oggetto permette di fare, conta il segnale percepibile che comunica cosa fare e dove. Le sue famose porte che invitano a spingere quando vanno tirate falliscono perché la maniglia è un significante che dice una bugia. Il bottone disabilitato è esattamente la stessa situazione, trasportata sullo schermo: ha la forma di un bottone, quindi promette un clic, ma il clic non produce nulla. È una porta con la maniglia dietro cui c’è un muro.

Per questo un comando spento senza spiegazione è quasi sempre un difetto di progetto. Il grigio da solo dice non ora, non dice perché né cosa devi fare tu. Nella colonna destra della scheda quella riga di testo sotto il pulsante fa proprio questo lavoro: trasforma un vicolo cieco in un’attesa comprensibile. La regola che uso da anni nelle revisioni di interfaccia è brutale ma efficace: se non riesco a scrivere in una riga la condizione che riattiva quel bottone, allora quel bottone non doveva essere disabilitato, doveva essere cliccabile e restituire un messaggio chiaro.

Il problema serio: il grigio che sparisce sotto la soglia di leggibilità

C’è un cortocircuito poco conosciuto nelle regole di accessibilità del web: il requisito di contrasto minimo per il testo prevede un’eccezione per i componenti di interfaccia inattivi. Tradotto: un’etichetta grigio chiaro su fondo grigio chiarissimo, dentro un bottone disabilitato, tecnicamente non viola la soglia. Da qui nasce l’abitudine di far evaporare gli stati spenti fino a renderli illeggibili, con la coscienza a posto perché lo strumento di verifica non segnala nulla.

Nella pratica è un disastro. Chi ha una vista non perfetta, chi usa lo schermo in pieno sole o su un monitor mal calibrato non capisce se quel rettangolo sia un bottone, un titolo o un errore di caricamento. Nella grafica che stiamo guardando, il pulsante di esportazione è proprio al limite: leggibile su un display buono, incerto su un portatile economico con luminosità bassa. Il mio criterio operativo è semplice: l’eccezione normativa è un permesso, non un obiettivo. Uno stato disabilitato va disegnato per restare comprensibile — riduco la saturazione e il peso, tolgo l’ombra e l’effetto di rilievo, ma tengo il testo abbondantemente sopra la soglia che userei per un testo secondario. La differenza tra attivo e inattivo la devo affidare alla forma e al contesto, non solo alla trasparenza.

C’è poi la parte invisibile. Un controllo disabilitato con il meccanismo nativo del browser esce dall’ordine di navigazione da tastiera: chi si muove col tasto di tabulazione o con uno screen reader non lo incontra mai e non riceve nemmeno la spiegazione scritta accanto. Le pratiche di implementazione degli standard di accessibilità prevedono soluzioni intermedie che mantengono l’elemento raggiungibile e lo annunciano come non disponibile. Non è un dettaglio da sviluppatori: è la differenza tra un utente che aspetta e un utente che non sa nemmeno che esiste un pulsante da aspettare.

Nascondere o disabilitare: la regola vera è meno simmetrica

La scheda propone una dicotomia elegante: non permesso o irrilevante si nasconde, rilevante ma non ancora pronto si disabilita spiegando perché. È un buon punto di partenza, ma nella mia esperienza va corretta su tre fronti.

I permessi non sono solo un tema di ordine visivo. Mostrare a un utente normale un elenco di azioni riservate agli amministratori non è soltanto rumore: è un invito a chiedere qualcosa che non otterrà, e in certi contesti è anche un’informazione che rivela la struttura interna dell’organizzazione. Qui nascondere è la scelta giusta, e non per estetica.
La differenza tra i due casi non è il permesso, è la durata. Se lo stato cambierà da solo entro pochi secondi o minuti, si disabilita e si spiega. Se dipende da un’azione dell’utente, meglio lasciare il comando attivo e guidarlo. Se non cambierà mai per quella persona, si nasconde.
Non esiste una risposta valida per ogni prodotto. Un software professionale usato otto ore al giorno può permettersi menu ricchi e stati inattivi, perché l’utente costruisce una mappa e la tiene. Un’applicazione consumer usata due volte al mese deve mostrare pochissimo, perché nessuno costruirà mai quella mappa. Le stesse due regole applicate ai due casi danno risultati opposti.

Le norme ergonomiche sull’interazione uomo-sistema ruotano attorno a principi come l’autodescrizione, la controllabilità e la conformità alle aspettative. Un comando spento e muto le viola tutte e tre insieme: non si descrive, non è controllabile, e delude un’aspettativa che la sua stessa forma ha creato. Un comando spento con una riga di spiegazione, invece, le rispetta.

Lo stesso errore fuori dallo schermo

Questa storia mi interessa perché non è digitale. Il pulsante d’ascensore che si illumina ma non risponde perché il piano è chiuso, il termostato di casa con la rotellina che gira a vuoto quando la caldaia è in blocco, la targa di ottone tirata a lucido su una porta che va spinta: sono tutti oggetti che promettono un’azione e non la mantengono, senza dire perché. Ogni volta che sento dire ho sbagliato io davanti a uno di questi oggetti, penso che abbia sbagliato chi li ha progettati.

La lezione pratica che porto via da questa scheda, difetti compresi, è una sola e vale per uno schermo come per un citofono: un comando può essere disponibile o non disponibile, ma non deve mai essere ambiguo. Se non si può usare, deve dirlo. Se tornerà usabile, deve dire quando. Se non tornerà mai, non deve stare lì. È una forma di rispetto verso chi usa le cose, ed è anche il modo più economico per ridurre le richieste di assistenza: la maggior parte delle domande che riceviamo non nasce da funzioni mancanti, ma da funzioni presenti che non spiegano il proprio stato.

Fonti

Tag:Interfacce digitali