Quand Joel change d'avis sur les interfaces graphiques

Joel Spolsky, de JoelOnSoftware, vient de publier un tout petit billet qui dit en substance: il ne faut ni cacher, ni désactiver les entrées d'un menu lorsque l'action correspondante ne peut être effectuée.
Le fait de cacher des éléments d'une interface est généralement considéré comme une mauvaise pratique. Il m'arrive souvent de chercher, dans des logiciels complexes comme OpenOffice ou Live, où diable cette fonctionnalité qui avait l'air si prometteuse à bien pu se planquer. C'est déjà suffisamment frustrant de naviguer dans les menus alors que j'ai du travail à faire, sans qu'en plus on m'enlève toute chance de retrouver ladite fonctionnalité parce que la commande n'est même plus là!
Jusque là, je suis d'accord avec Spolsky. Mais voyons ce qu'il nous recommande à la place:

Instead, leave the menu item enabled. If there's some reason you can't complete the action, the menu item can display a message telling the user why.

Sous quelle forme? Info-bulle? Boîte de message? Barre d'information en bas de la fenêtre, à l'autre bout du monde par rapport à l'endroit où l'utilisateur regarde?
Tout de suite, je me suis souvenu d'un essai qui m'avait marqué, où Spolsky assénait avec assurance que les utilisateurs ne lisent pas:

This may sound a little harsh, but you'll see, when you do usability tests, that there are quite a few users who simply do not read words that you put on the screen. If you pop up an error box of any sort, they simply will not read it. This may be disconcerting to you as a programmer, because you imagine yourself as conducting a dialog with the user. Hey, user! You can't open that file, we don't support that file format! Still, experience shows that the more words you put on that dialog box, the fewer people will actually read it.

Mettons que la commande "coller" ne peut pas être exécutée à un moment donné. Comment expliquer à l'utilisateur qu'il ne peut pas coller dans Paint .NET les 26 colonnes de nombres qu'il vient de copier dans Excel de manière à ce que 1) il lisent l'explication, et 2) il la comprenne?
Moi, pour ma part, je ne lis pas les messages. Et comme je suis un utilisateur comme un autre, je ne m'attends pas à des miracles sur ce front-là.
Pire encore, faut-il apprendre à l'utilisateur que chaque élément actif à l'écran peut lui envoyer un message à la figure plutôt que de produire le résultat attendu? Pas très bon pour l'encourager à explorer les fonctionnalités du logiciel...
D'autant que tout le monde grise des éléments des menus lorsqu'ils ne sont pas applicables. Or à la même époque, Spolsky nous vantait les mérites de la constance dans les interfaces graphiques:

If Microsoft is doing it in a popular program like Word, Excel, Windows, or Internet Explorer, then millions of people are going to think that it's right, or at least, fairly standard, and they are going to assume that your program works the same way. Even if you think (as the Netscape 6.0 engineers clearly do) that Alt+Left is not a good shortcut key for "Back", there are literally millions of people out there who will try to use Alt+Left to go back, and if you refuse to do it on some general religious principle that Bill Gates is the evil smurf arch-nemesis Gargamel, then you are just gratuitously ruining your program so that you can feel smug and self-satisfied, and your users will not thank you for it.
And don't be so sure it's not right. Microsoft spends more money on usability testing than you do, they keep detailed statistics based on millions of tech support phone calls, and there's a darn good chance that they did it that way because more people can figure out how to use it that way.

Alors au vu de tout ça, que penser de ce brusque revirement? Je respecte beaucoup les conseils de Spolsky. A tel point que je suis prêt à lui accorder le bénéfice du doute: est-ce une simple provocation? Peut-être nous donnera-t-il lui-même sa raison d'ici peu.