Interfacce grafiche e abitudini

Settimana scorsa, tra le altre, ho aggiornato a Jammy Jellyfish anche una macchina desktop che uso con interfaccia grafica. Questo sistema esce con GNOME 42 e, come prima cosa, ho dovuto aggiornare a mano l’unica estensione di cui davvero non riesco a fare a meno: Dash to Panel.

Per chi non la conoscesse, questa estensione combina le funzionalità della barra in alto della interfaccia di GNOME con la barra detta application launcher, in modo da formare una unica entità, normalmente in basso allo schermo, simile alla taskbar familiare a chi usa Windows.
Se qualche lettore sta già storcendo il naso, pensando che questo sia un sacrilegio, aggiungo che io detesto la barra in alto nelle interfacce grafiche dei sistemi operativi, ma la ragione di questa insofferenza non è estetica. Per spiegare le mie ragioni, è necessaria una piccola digressione

Il primo concetto da introdurre è la cosiddetta Legge di Fitts: si tratta di un modello matematico che lega il tempo medio necessario per acquisire un generico bersaglio da parte di un operatore umano. Originariamente sviluppata nel mondo meccanico, per migliorare la sicurezza aerea studiando le interazioni dei piloti con i comandi dei velivoli, è stata in seguito adattata con successo anche al mondo delle interfacce grafiche in ambito informatico.

Non c’è lo spazio qui – e soprattutto io non ho le competenze – per spiegare la legge e le ricerche che la riguardano nel dettaglio, ma su internet il lettore interessato troverà approfondimenti a volontà.
Il principio fondamentale della legge, riassumendo, dice che il tempo per centrare un elemento grafico con il puntatore del mouse è direttamente proporzionale alla sua distanza e inversamente proporzionale alla dimensione del bersaglio nella direzione del moto.
I due principi fondamentali del design, seguendo questa indicazione sulla velocità di esecuzione, sono che gli elementi di comando devono essere vicini al puntatore del mouse e che devono essere i più grandi possibili.

Il primo principio, che viene anche colloquialmente chiamato “regola di prossimità” è messo in atto in maniera estesa da quello che io considero una delle migliori invenzioni della interfaccia grafica: i menu contestuali.
Se progettati e realizzati correttamente, i menu contestuali permettono di avere sotto mano, letteralmente sotto mano, i comandi specifici dell’oggetto che si sta manipolando. Nel caso di un editor di testi, per esempio, evidenzando una parola o una frase e usando il click destro del mouse è possibile avere i comandi specifici per il testo (l’oggetto su cui si vuole lavorare), per di più in una posizione vicina a dove il puntatore del mouse già si trova.

Il secondo principio spiega che, quando mi sto muovendo, l’oggetto che devo raggiungere deve essere abbastanza grande da permettermi di riconoscerlo, capire quando il puntatore del mouse lo ha raggiunto, innescare il riflesso nervoso che ferma il mio movimento e farmi trovare ancora all’interno dell’area attiva dell’oggetto. Tradotto in soldoni, significa che i pulsanti, i link, le barre di scorrimento non devono essere troppo piccole rispetto alla dimensione totale dell’area di lavoro.
C’è un caso particolare di questo principio che è molto importante: dato che l’area di lavoro ha dei confini ristretti, le aree sul bordo del monitor hanno la caratteristica di avere una profondità infinita.
Si tratta naturalmente di un modo di dire, ma in pratica significa che un oggetto posizionato sul margine destro del monitor, per esempio, spesso anche solo 1 pixel è semplicissimo da centrare: basta buttare il mouse a destra e il puntatore si fermerà sull’oggetto perché sarà arrivato a fine corsa.
Con queste informazioni di base, possiamo ora tornare al concetto da cui è partito il discorso.

Immaginiamo una situazione di lavoro comune: un utente ha sullo schermo del suo computer una applicazione su cui sta lavorando in maniera intensiva con la schermata massimizzata. Potrebbe essere un testo in un elaboratore, un foglio di lavoro, un disegno in un software di progettazione assistita al calcolatore, codice in un IDE o qualsiasi altra cosa vogliate. Con schermi di grandi dimensioni, non è escluso che si lavori su due programmi affiancati: magari una presentazione da una parte in cui si inseriscono dati numerici partendo da un foglio di lavoro nell’altra metà dello schermo.
Guarda caso, per massimizzare o affiancare le finestre, si usano i bordi dello schermo: trascinando una finestra sul bordo alto, questa si massimizza. Trascinando una finestra sul bordo sinistro e un’altra sul bordo destro, le due si affiancano automaticamente occupando metà schermo ognuna.
Il bello di queste ultime azioni è che possono essere eseguita quasi senza guardare: proprio perché i bordi hanno profondità “infinita” non bisogna nemmeno puntare realmente il mouse, basta spostarlo in maniera grossolana, usando solo la propria memoria muscolare senza quasi attenzione cosciente, evitando così distrazioni.

Dopo questo lungo giro panoramico, torniamo al punto principale: perché penso che la barra dei task superiore non sia una buona scelta progettuale?
Come spiegato appena sopra, immaginiamo di avere una o due finestre massimizzate su cui si sta facendo il grosso del lavoro.
Una situazione comune è passare a una finestra secondaria per qualche compito specifico: il prompt dei comandi, una calcolatrice a schermo o, perché no, un player musicale. Questi strumenti sono visualizzati in finestre, non massimizzati: una volta terminato di usare uno di questi, come si torna alla schermata di lavoro principale? Dato che è massimizzata sullo sfondo, se il titolo della applicazione è adiacente al bordo superiore dello schermo, non devo fare nessuno sforzo cosciente: finito di lavorare sulla finestra “piccola” mi basta, di nuovo, buttare lo schermo in alto, senza nemmeno fare attenzione e fare click per fare tornare il focus sulla applicazione principale.
Ecco che, se la parte alta dello schermo ospita una barra dei task, per passare a un programma massimizzato, devo spostare la mia attenzione per centrare la barra del titolo che si trova in alto, ma non troppo.

A prima vista, scritta così, questa cosa può sembrare una banalità, ma mantenere l’attenzione focalizzata sul lavoro e non sull’interfaccia è una cosa che mi sono abituato a fare da anni e non poter effettuare questo cambio di focus in maniera rapida è estremamente fastidioso.

Una obiezione a questo ragionamento è che la barra dei task in alto contiene i menu e quindi averli sul bordo dello schermo li rende, come già spiegato, infinitamente alti. Questa è la filosofia sempre seguita da macOS, per esempio.
Ci sono due obiezioni a questo argomento: la regola di prossimità, già discussa, e la larghezza dell’elemento.
La regola di prossimità è violata perché un elemento appartenente a una tale finestra, ovvero uno dei suoi menu, è visualizzato fuori da quella finestra e forse anche lontano da essa.
Secondo, nel caso di un menu sul bordo è vero che la altezza è infinita, ma la larghezza non lo è per nulla: i nomi dei menu sono corti, quindi normalmente si tratta di solo qualche decina di pixel.

Il risultato di tutto questo è che, anche se i menu di una applicazione sono “fissati” sul bordo, mi serve sempre molta attenzione per centrarli, per via della loro larghezza.
Al contrario, la barra del titolo è così estesa che posso centrarla semplicemente puntando genericamente il centro dello schermo (o 1/4 e 3/4 in caso delle due affiancate), semplicemente non puntando agli angoli, dovi troverei alcuni pulsanti di azione.

Chiudo qui la lunga spiegazione, sperando di aver fornito informazioni utile ai lettori.
Vi ho mostrato, soprattutto, che vette possono raggiungere le spiegazioni pseudo-tecniche che un geek si dà per giustificare le proprie piccole manie 😉