Tuesday, April 24, 2007 

GUI [Anti]Patterns and Safety-Critical Systems

A few weeks ago I was writing some code in C++/CLI, a simple DLL shared by a couple of C# programs. I was basically doing pair programming, although the main goal was to get my teammate more acquainted with C++/CLI, while writing some code we needed.

Testing and debugging the DLL involved running both clients, which under Visual Studio is not immediate: you can run one (the startup project) with the usual start button, but you have to manually select the other project in solution explorer, right-click, choose "debug" and then "start new instance". No big deal, except that I kept clicking on the wrong menu item ("Add" instead of "Debug"). I had to pay a lot of attention to avoid this mistake, but anyway, in a couple of hours I made something like 10 mistakes or so (to the general amusement :-).

As I said, no big deal, because Visual Studio is hardly a safety-critical application. However, in the past few days, I've been exchanging a few ideas on how to improve the GUI of a safety-critical application, and that episode came back to my mind. Why was I choosing the wrong item? Was there anything to be learned? There are at least two reasonable explanations:

1) I'm rather dumb, and I must be kept away from safety-critical applications.

2) Something in the design of that pop-up menu was misleading.

Now, (1) is a serious possibility :-). To quote Edsger Dijkstra in Programming Considered as a Human Activity, "I have only a very small head and must live with it". But (2) is also a possibility worth exploring.

So, here is the suspect menu, in its compact and expanded form:





Now, I'm not the first to think about GUI and safety-critical systems. There is quite some literature about it, including some (small) pattern language. An interesting paper is Patterns for Designing Safety-Critical Interactive Systems by Mahemoff and Hussey (I'm providing a link to citeseer cache, as the original link seems to be broken).
Within that paper, the pattern that seems most relevant for the situation at hand is "Intended Action":
Problem: How can we enhance assurance that a user's action matches their intention?
Just what we need! Unfortunately the solution part is not that helpful:
Solution: Arrange the user interface so that affordances are provided which reduce the likelihood that an error will occur when the user executes a task.
The examples provided are quite good (especially if you're familiar with Donald Norman's works), but they do not immediately apply to a simple pop-up menu.

However, given a pattern we can easily form an anti-pattern. In this case, the anti-pattern would be:
Arrange the user interface so that affordances are provided which increase the likelihood that an error will occur when the user executes a task.

Is there anything like that in the menu above? Well, sure there is. Note how many items have a distinct visual clue on the left, relating the item to a familiar (and distinct) icon in the menu bar. This is a good application of the pattern above.
Also, notice how both Add and Debug provide an identical visual clue on the right, to indicate that they can be expanded. My small head was obviously confused by the two identical clues, and I was clicking on the wrong item (probably because I was visually scanning for a picture, not for text; that's the "rather dumb" part, I suppose :-). This is an instance of the antipattern.

Interestingly, the icons on the left and on the right seem to have the same purpose: they indicate what it's going to happen if you click on the item. The icon on the left represents the action that will be started. The icon on the right indicates that a sub-menu will be opened.
Note, however, that at a conceptual level they serve a remarkably different purpose: the icon on the left is concerned with application-level functionality, the icon on the right is hinting at navigational-level functionality. That's why the icons on the left are different, while the icons on the right (if present) are identical (an arrow), and may lead to confusion (I want to stress the idea that it's no big deal for Visual Studio: I'm just using a real-world example to talk about issues that would be relevant in the design of a critical-safety GUI).

Now, can we fix that? Well, sure. A simple fix would be to keep the arrow on the right, but still add an icon to the left (e.g. the icon of the first item in the sub-menu, if any). This will give a clue on what's below, and I'd surely click on the entry that looks like the button I've just clicked on the toolbar.
An alternative idea would be to change the indication on the right (e.g. by placing the icon of the first sub-menu item right before or after the arrow), although this would conflict with the common Windows paradigm (which wasn't designed for safety-critical applications anyway).
Yet another could be changing the arrow to a somewhat less eye-catching shape. Probably, you can come up with a few more strategies. As usual, in real-world safety-critical systems some (well-designed) experiments would be needed to determine the magnitude of the problem and the efficacy of every candidate solution.

A final note: there are quite a few interesting point in that paper on safety-critical systems. You will recognize the centrality of contextual design, as safety-critical systems may have to compromise on other important aspects (e.g. user productivity). Bainbridge's ironies of automation are also extremely interesting, and you may want to spend a few minutes pondering on them :-).

Labels: , ,

Comments:
I'll throw in a few more lines:

I was obviously visual scanning for something, and guess what, that something was an arrow, as I had just clicked the start (arrow) button on the toolbar.So I guess the first arrow on the menu was really catching my eye.

That's another instance of the antipattern: using similar simbols (the "start" arrow and the "sub-menu" arrow) to indicate different behaviours.
 
Se non leggevo il tuo primo commento, scrivevo io a proposito dei due triangoli (arrow)!
Il problema più grosso, secondo me, è che il menu contestuale citato è fatto male in toto. Provo a enumerare i problemi che vedo:

1) Troppo lungo. Contiene così tante voci che obbliga l'utente a cercare ogni volta quella desiderata, quando dovrebbe essere una azione intuitiva.
2) Alcune voci "critiche" producono danni se scelte inavvertitamente: qualcuno ha mai cliccato su "Rebuild" o "Clean" per sbaglio? Io sì, e ho odiato Visual Studio dal profondo.
3) Come conseguenza di 1, le voci sono distribuite in modo opinabile. Perché "Set as Startup Project" è nel mezzo del menu, prima di altre voci di uso più frequente? Eccetera.
4) Sempre come conseguenza di 1, l'utente fa come Carlo e cerca di memorizzare qualche riferimento visivo per non dover cercare leggendo. Ma è troppo difficile... In teoria, in una GUI fatta bene gli utenti scelgono sempre gli stessi riferimenti visivi. Ovviamente qui non vale. :-)
5) Sottomenu "Debug". Un sottomenu per due sole voci? Era meglio inserirle nel menu principale! E magari spostare dentro "Add" anche "Add Reference" e "Add Web Reference", che non servono quasi a niente.
6) Icona "Debug" (triangolo verde). Cavoli, è semplicemente sbagliata. Troppo simile alla freccina del sottomenu, come dice Carlo. Se ci fate caso, in altri contesti la stessa icona è realizzata come un triangolo dentro a un cerchio, apposta per togliere l'ambiguità.
7) Le altre icone: scegliere una dominante di colore per tutte le icone è un suicidio. Se le fanno tutte tendenti al blu, chi riesce a distinguerle? Aumentano la confusione..

Insomma, ripetendo il concetto che ho espresso qualche post fa, si vede che i programmatori non ci sanno fare con le GUI! :-)

Vale anche per Apple e il suo IDE, Xcode. Fino a pochi mesi fa aveva dei menu contestuali del tutto simili a questo. Poi, spinti dalle proteste degli utenti (già schifati dall'idea del menu contestuale), i programmatori di Xcode hanno rivisto i menu e ora sono molto più corti e razionali.
 
Citrullo, non se e' grave :-)) ma... concordo praticamente su tutto!

Giusto per trovare almeno qualcosa da ridire :-), ma che non intacca la sostanza, "add reference" in C# e' usatissimo... invece, visto che "add reference" apre un tabbed dialog, tanto valeva avere un tab per i web reference ed eliminare la voce di menu. Ma qualcuno nel team di Visual Studio deve credere che "web is different", altrimenti non si spiegherebbe perche' distinguere nel menu File tra "new project" e "new web site" (peraltro pessimo nome visto che ci finiscono sotto anche i web service) anziche' usare solo "new project" e anche qui sfruttare le diverse categorie gia' utilizzate nel dialog box successivo...
 
Ci stanno bene pure questi:

8) Lo spazio riservato alle icone delle voci di menu e' evidenziato verticalmente con quel gradiente grigio. Che avra' un aspetto molto "avanti", ma fa da separatore tra icona e testo, rendendo difficile l'associazione visiva tra i due elementi, e di conseguenza la ricerca di un riferimento.
9) Oltre al punto 7, le icone trasmettono poco significato. Quella di "Build" e' assolutamente anonima, "View Class Diagram" con quella lente sembra un "Search", "Properties" e' uno schedario... che c'entra?

Carlo, quando avrai voglia di postare altre stranezze della UI di qualche programma... fai pure, e' un piacere! :-)
 
Citrullo a motore raccolgo io il tuo invito e posto un'antipatia nella copia di files in Windows Vista.

Immaginate di voler copiare (magari per backup) una cartella che contiene files ed alcune sottocartelle in una nuova destinazione dov'era già stata copiata in precedenza.

Le immagini che vi possono comparire in sequenza sono:







Troppe immagini di conferma.

La seconda poi è molto caotica e troppo ricca di testo senza contare che magari non viene intuitivo di cliccare sul testo per eseguire l'operazione.

La terza poi mi sembra francamente ridondante in ragione della prima.
 
Citrullo a motore raccolgo io il tuo invito e posto un'antipatia nella copia di files in Windows Vista.

Immaginate di voler copiare (magari per backup) una cartella che contiene files ed alcune sottocartelle in una nuova destinazione dov'era già stata copiata in precedenza.

Le immagini che vi possono comparire in sequenza sono:


(cliccare sul link per vedere)


(cliccare sul link per vedere)


(cliccare sul link per vedere)

Troppe immagini di conferma.

La seconda poi è molto caotica e troppo ricca di testo senza contare che magari non viene intuitivo di cliccare sul testo per eseguire l'operazione.

La terza poi mi sembra francamente ridondante in ragione della prima.
 
Evidentemente ci sono problemi nella gestione del tag <a>.

Nell'anteprima mi visualizza tutto correttamente, ma poi in fase di pubblicazione esce quella schifezza che potete vedere.

Nel secondo avete almeno un link a tutte e tre le immagini...
 
Chiedo perdono.

m'era scappato uno slash di troppo.

<a href="..."/>link</a>

invece di

<a href="...">tag</a>

temo però che la cosa non sia recuperabile.

Se almeno avesse sbagliato anche l'anteprima...



Citrullo a motore raccolgo io il tuo invito e posto un'antipatia nella copia di files in Windows Vista.

Immaginate di voler copiare (magari per backup) una cartella che contiene files ed alcune sottocartelle in una nuova destinazione dov'era già stata copiata in precedenza.

Le immagini che vi possono comparire in sequenza sono:

Immagine 1
(cliccare sul link per vedere)

Immagine 2
(cliccare sul link per vedere)

Immagine 3
(cliccare sul link per vedere)

Troppe immagini di conferma.

La seconda poi è molto caotica e troppo ricca di testo senza contare che magari non viene intuitivo di cliccare sul testo per eseguire l'operazione.

La terza poi mi sembra francamente ridondante in ragione della prima.
 
WOW, la cosa si è sistemata!

(e termino)
 
Nell'esempio di Romano i progettisti si sono davvero superati!

Il titolo della prima finestra e' "Conferma sostituzione cartella", che io interpreto come: rimpiazzo la cartella esistente con questa?
Invece no, la domanda e' relativa all'unione del contenuto delle due cartelle. Quindi una confusione non da poco.
(Per inciso: ma perche' non rimpiazza la cartella?)

Sulla seconda finestra sono d'accordo con Romano: quando mai si clicca su un testo che non ha nulla di "clicchevole"? Poi non capisco perche' il nome del file e' scritto due volte (una in nero e una in blu) e in due opzioni diverse, per un totale di quattro volte. E nemmeno capisco perche' hanno usato due font diversi per il nero e il blu (e' anche fastidioso da leggere).
Buffa l'opzione in basso: "Applica ai prossimi 2 conflitti". Forse intendevano "Applica ai prossimi conflitti, che sono 2". :-)

Non capisco il motivo della terza finestra. Le icone rappresentano cartelle vuote, sono forse vuoti i folder? Non credo, perche' se fosse cosi', non avrebbe senso la richiesta di "unione".

Approfitto liberamente di questo bello spunto di Romano per sfottere ancora la UI stile Windows... :-)
Due cose secondo me non hanno senso. La prima sono le lettere sottolineate, ad indicare quale tasto sulla tastiera va premuto per invocare l'azione di quell'elemento di UI. Non le usa nessuno! Quanto tempo dovremo ancora vederle?
La seconda e' quel bordino rettangolare a puntini che appare ad indicare il focus della tastiera sui controlli non di testo (credo). Brutto, noioso e quasi inutile.
Queste due "feature" della UI di Windows risalgono ai tempi di Windows 3.11, quando poteva anche non funzionare il mouse, e si dava la possibilita' di comandare tutto da tastiera. Se proprio si vogliono mantenere queste caratteristiche, almeno che vengano legate ad una opzione e aggiornate secondo lo stile grafico del resto della UI!
 
Windows Vista - WOW?

Altra antipatia rilevata.

Create sul desktop (oppure nella barra di avvio veloce, che è la stessa cosa) un collegamento ad un programma per MS-DOS (Ne esistono ancora di molto utili :-). L'icona del collegamento (PIF) che vi verrà mostrata sarà sempre quella di un anonimo foglio bianco, anche se agendo nelle proprietà del programma ne scegliete un'altra di vostro maggior gradimento.

Sicuramente nessuno dei beta tester ha mai creato un collegamento ad un vecchio programma per MS-DOS perché la cosa si sarebbe notata subito...
 
Windows Vista - l'antipatia continua

Sto utilizzando il nuovo pupillo di Microsoft da circa un mese e l'impressione peggiora ogni giorno che passa.

Il motivo? E' presto detto. Nel compiere il lavoro di sempre rilevo sorprendenti cali di produttività rispetto a quando lavoravo con Windows XP.

E poi ogni tanto incappo in errori di funzionamento che la dicono lunga sulla qualità di questo prodotto. N.B. Usando componenti di Windows Vista e non programmi potenzialmente incompatibili.

Che sia solo una mia impressione?

Vi racconto l'ultima.

Fate in explorer un taglia incolla di una cartella da una posizione in un'altra dove in realtà quella cartella esiste già. Orbene tutto il contenuto della cartella viene tagliato e spostato, ma la cartella contenitore sorgente viene lasciata e poi vi tocca eliminarla a mano. Riproducibile sempre e con facilità.

Sarei tentato di fare come mio figlio che ha piallato Windows Vista ed è tornato ad XP...
 
Continua l'antipatia con Vista

L'implementazione dell'API EnterCriticalSection è cambiata e ci sono cascato in pieno.

Per fortuna con un minimo di debug ho capito che il problema stava lì e vi ho rimediato facilmente.

Poi ho voluto fare un po' di dietrologia ed ho cercato sul web le motivazioni.

Eccole:

forums.microsoft.com
msdn2.microsoft.com
 
CriticalSection Code Changes

CriticalSection code was changed to increase security and robustness. Applications using critical section locks:

Should always initialize critical sections.

Should not read into undocumented objects. Applications that read into the undocumented structures to assess the status of a critical section will most likely break if they are looking for uninitialized and freed critical sections.

Should prevent starvation. Applications that call Sleep while holding the critical section lock now can cause starvation for other threads that need the lock. Sleep calls should be placed after the LeaveCriticalSection call.
 
In realta' non vedo lo scandalo :-) nel modificare dettagli implementativi del thread scheduler, su cui peraltro non e' mai stata data particolare garanzia...

Uscendo anche un minimo dal caso specifico, ovvero approfittando di quanto dici per qualche considerazione generale:

In generale una Sleep nel codice e' sempre segno che qualcosa non sta funzionando nel verso giusto (ovvero: non stiamo usando bene le primitive del sistema, o il sistema stesso ha dei problemi).

Sempre uscendo dallo specifico, ho visto molte persone convinte che (ad es.) segnalare un evento causasse l'immediato scheduling di un thread in attesa su di esso. Queste assunzioni sono ovviamente del tutto infondate (sotto Windows).

Ancora piu' in generale, la programmazione concorrente (a parte problemi ormai semplici e consolidati, tipo producer/consumer, guardie di mutua esclusione su brevi porzioni di codice, ecc) e' uno di quei casi dove il "funziona sulla mia macchina" e' particolarmente pericoloso, e le poche cure sono una progettazione accurata (esistono ormai tanti approcci per modellare software concorrente) e nei casi piu' complessi anche una code inspection vera e propria.

Se avessi voglia di riaprire una vecchia diatriba con gli XPisti, magari proporrei come argomento un programmino concorrente, anziche' uno che disegna un cerchio :-)), giusto per vedere come sperano di progettarlo in modo convincente via TDD....
 
Post a Comment

<< Home