Joel Spolsky, noto programmatore in ambiente Windows, ha scritto di recente nel suo blog un articolo (piuttosto corto e per nulla approfondito, aggiungerei) dal titolo Don’t hide or disable menu items, ossia “Non nascondere o disabilitare le voci di menu”. La mia traduzione del pezzo:

Tempo fa si usava spesso, ed era persino consigliato, disabilitare voci di menu quando non potevano venire utilizzate.

Non fatelo. Gli utenti vedranno la voce di menu disabilitata sulla quale vogliono fare clic, e non avranno alcuna idea di ciò che dovrebbero fare per attivarla.

Invece, lasciate la voce di menu abilitata. Se esiste qualche motivo per cui non è possibile completare l’azione, la voce di menu può visualizzare un messaggio che spieghi all’utente perché 

Puntuale, come al solito, il commento di John Gruber:

Questo è un chiaro esempio del perché Spolsky sia uno sviluppatore Windows e non Mac. Disabilitare le voci di menu quando non è possibile utilizzarle è una buona pratica — significa che lo stato visivo di un menu riflette lo stato effettivo del comando che rappresenta. Uno può sostenere che questo possa confondere gli utenti che non capiscono perché una certa voce di menu sia al momento disattivata [appare ingrigita richiamando il menu], ma è uno dei più classici compromessi. La pratica suggerita da Spolsky, ovvero di lasciare sempre e comunque attive tutte le voci di menu, e mostrare un avviso quando vengono richiamate anche se non possono venire usate, sarebbe molto irritante ogni volta che l’utente si imbattesse in una tale situazione. (Mi ricorda anche certe applicazioni Mac assolutamente prive di aiuto in linea, ma che visualizzano comunque il menu Help / Aiuto, con una voce di menu tipo “NomeApplicazione Help” o “Aiuto NomeApplicazione” che non svolge nessun compito se non quello di visualizzare un messaggio che dice “L’aiuto non è disponibile per NomeApplicazione”).

Il suggerimento di Spolsky si basa inoltre sulla presupposizione che l’utente sia stupido. Meglio dare per assodato che l’utente sia intelligente e curioso di investigare da solo il perché un certo comando sia al momento disattivato. 

A me ricorda anche una scelta di design analoga, e ugualmente irritante, dell’ambiente Windows (almeno fino a XP): i ‘clic perduti’, ossia il fatto che un pulsante (di un pannello o di una finestra di dialogo) riconosca comunque il clic del puntatore del mouse anche quando in realtà l’applicazione è bloccata, congelata o non responsiva per qualsiasi motivo. Si fa clic su “Annulla” o “OK”, si crede che il clic abbia avuto effetto, e invece nulla: il pannello rimane lì, la finestra di dialogo pure, e non si è sicuri se l’applicazione abbia davvero registrato il nostro input. Sul Mac OS classico ricordo che, in una situazione analoga, un indizio del fatto che qualcosa non stesse funzionando era che il pulsante si ‘accendeva’ ma non ritornava sulla posizione di ‘spento’ e l’utente capiva la piega che stava prendendo la situazione. Su Mac OS X, di solito, non c’è feedback, ovvero si fa clic sulla finestra di dialogo ma tutto rimane rigidamente come prima.

È interessante vedere, anche da sottigliezze come queste (mi riferisco ai consigli di Spolsky), la differente prospettiva e mentalità dello sviluppare per una piattaforma o per l’altra. E vedere come l’usabilità di certe parti di un’interfaccia venga più o meno compromessa anche da piccole scelte come queste.