Développement Mac et iPhone
La plupart des gens confondent stylisme et design. Autrefois en français, on distinguait le dessin du dessein; l'homophonie a fait préférer le terme design à dessein, mais l'idée reste: le design, c'est la conception fonctionnelle, comment "marche" l'objet. Le stylisme, lui, n'est lié qu'à l'apparence d'un objet (et non pas son esthétique, il n'y a pas de notion de beau ici, juste celle de différenciation).
Les Mac sont des machines fortement designées. Il m'a toujours été difficile d'expliquer pourquoi j'avais fait le choix du Mac à des personnes qui ne connaissent que le PC. Elles ne comprennent pas pourquoi elles devraient payer plus cher pour un ordinateur, "seulement parce qu'il est plus beau". Certainement, si vous me lisez, vous utilisez un Mac, et vous savez pourquoi: vous avez acheté plus que du matériel, vous avez acheté une expérience. Vous aimez le Mac parce qu'il a été "pensé".
En tant que programmeur sur Mac, je suis aussi un utilisateur, et je m'arrange pour reproduire ce qui me plaît et bannir ce qui m'agace au quotidien. L'essentiel du travail de design se faisant sur l'interface utilisateur, les Apple Human Interface Guidelines restent un livre de chevet. Mais ce sont tout autant les années d'utilisation du Mac qui m'ont formé à sa culture: minimalisme, prévisibilité, cohérence.
J'ai eu l'occasion de parler avec un programmeur qui a un poste important chez un grand éditeur de logiciels d'apprentissage des langues. Nous parlions d'Eclipse, et je lui exprimais mon dégoût pour son interface. Il me répondit: " l'interface utilisateur, c'est avant tout une question de goût". Je ne peux pas être plus profondément en désaccord ! Il y a certes des habitudes, personnelles ou liées à l'utilisation d'une plateforme particulière, certes tout le monde ne pense pas pareil, ni n'a les mêmes aptitudes mentales, mais je suis convaincu que les trois piliers que j'ai cité plus haut (je les cite à nouveau: minimalisme, prévisibilité, cohérence) sont des principes qui peuvent s'appliquer à tous les cerveaux.
Voici un exemple. Un développeur a proposé que nous faisions des remarques sur son nouveau logiciel. Beaucoup de mes remarques portaient sur les Préférences, mais particulièrement sur une case à cocher. Cette case servait à activer la génération de l'aperçu QuickLook. Si, si, vous savez, QuickLook, le truc introduit par Apple avec Mac OS 10.5 et qui permet d'afficher l'aperçu des documents.
"C'est utile alors. Pourquoi tu ne le laisses pas activé tout le temps ?" lui demandais-je.
Parce que la génération de l'aperçu prend du temps. Mais si la génération n'est pas faite, le Finder met plus de temps à afficher l'aperçu", me répondit-il. Et un peu agacé par mes propos, il a laissé sa case à cocher.
Voyez-vous le travers ici ? Ce développeur n'a pas voulu faire de choix. Il laisse l'utilisateur le faire à sa place. Mettons-nous dans la peau de l'utilisateur: je me retrouve avec une case "Générer l'aperçu QuickLook", je la coche ou pas ? À mon avis, 9 personnes sur 10 préférerons ne pas y toucher. Dans celles qui restent, certaines iront voir la doc et ne seront pas plus avancées. Elles laisseront la valeur par défaut. Il reste peut être alors une infime portion d'utilisateurs qui vont tester ce qui leur convient le mieux. Le pire, c'est que le développeur devra quand même décider si la case doit être cochée par défaut ! Les conséquences sont les suivantes:
Quelle était la bonne décision alors, puisque je sais tout ? Je dirais: Imposer la meilleure option à l'utilisateur. Si la génération de l'aperçu prend moins d'une seconde, alors c'est négligeable pour l'utilisateur. Mais mon vrai choix, en vrai, aurait été de ne tout simplement pas coder cette fonctionnalité. Je n'utilise jamais l'affichage Coverflow, et très rarement QuickLook. Et j'imagine qu'il en est de même pour tout le monde, sauf Steve Jobs, pour épater la galerie lors de ses conférences. D'ailleurs, je parie que Coverflow aura disparu dans Mac OS 10.8. Et même si j'ai tort, il y avait plein d'autres choses plus importantes à coder avant.
Pour finir, ne jetons pas la pierre à ce développeur — qui a pensé avant tout à ses utilisateurs — mais balayons déjà devant notre porte: Toi, lecteur, quels choix t'es-tu refusé à faire ?