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 ?
Michaël Villar
8 novembre 2008 | 00:55
Je suis totalement d'accord, les préférences doivent être très limitées, ne laisser ce qu'il y a d'utile!
Après, je ne sais pas quelle est son application, donc je ne sais pas non plus dans quel contexte Quicklook est intégré, mais je me sers tout le temps de Quicklook sur mon Mac, c'est une fonctionnalité énorme!
Par contre je suis d'accord avec toi pour Coverflow, useless ;)
Fabien Schwob
8 novembre 2008 | 01:19
En ce qui me concerne, je dois dire que j'utilise beaucoup Quicklook et très peu coverflow.
Sinon, un des exemples les plus frappants d'évolution des Préférences c'est VLC qui dispose maintenant d'un système de préférence plus proche de l'esprit "Mac"
Julien ezaekiel
8 novembre 2008 | 11:14
Je dois dire que je suis content de lire ce blog.
Les articles ne sont pas fréquents mais par contre d'une très bonne qualité.
Je prends d'autant plus plaisir à les lire à chaque fois qu'il y en a un.
Michaël Villar
8 novembre 2008 | 12:11
@Fabien Schwob
Oui, VLC s'améliore comme Firefox, mais il reste du chemin. Pourquoi diable il n'y a pas de coche fermer sur la fenêtre?... et pourquoi il y a un bouton Enregister!
Fabien Schwob
8 novembre 2008 | 13:02
@Michaël :
Je suis d'accord, mais je pense que l'évolution va dans le bon sens et qu'il n'est pas toujours simple de maintenir des versions multi-plateforme et que l'on se retrouve de temps en temps avec des comportements plus générique que spécifique à une plateforme.
Je pense que dans ce que fait Adium en utilisant libpurple de Pidgin (un librairie portable en C) pour le code métier et Cocoa/Objective-C pour l'interface graphique est une bonne solution.
Guillaume
9 novembre 2008 | 13:04
Pour les preferences, moi, j'aurais code la fonction, mais coche la case par defaut, cela laisse la possibilite de desactiver cette fonction pour les machines lentes
Renaud Pradenc
9 novembre 2008 | 17:59
@Guillaume
Tu devrais relire la deuxième partie de l'article, qui explique justement les défauts de cette démarche.
Patrick Geiller
10 novembre 2008 | 20:50
J'adore Quicklook ! C'est un gain de temps énorme pour browser les résultats d'une recherche Spotlight.
Si l'aperçu quicklook prend trop de temps, on peut sauver un thumbnail avec le fichier. Les fichiers Autocad font ça, c'est plus pratique qu'attendre le chargement. Ensuite, le dev peut rajouter sous le thumbnail 'live preview' pour charger le fichier lui-même. Ainsi l'utilisateur a toujours le choix, et cette fois ci c'est un choix visible, pas caché dans les préférences.
Umberto Pato
24 novembre 2008 | 00:14
Je suis assez d'accord avec cette analyse "sur le pouce"... mais n'oublie pas Renaud que quoi que l'on ait à "choisir", seule la fluidité d'esprit permet de trouver de véritable(s) réponse(s) à ce choix !... La flèche est en Toi... la cible est en Toi... l'énergie entre les deux : c'est Toi !
Et - donc - cette analyse aurait pu tout aussi bien "tourner autour de l'annulaire"... :-)
Renaud Pradenc
24 novembre 2008 | 08:20
@Umberto: Je m'en vais méditer sur cela, sachant qu'il y a peu de vérités absolues…