Moins de boutons dans nos interfaces graphiques svp

Mark Shuttleworth veut moins de boutons dans les interfaces graphiques. Tristan Nitot n’est pas contre et parle un peu du comment faire passer le message. Et ils ont raison.

Problématique simple : notre mère nous demande quel programme utiliser pour ses photos de famille. Réponse classique : photoshop ou gimp. Dans les deux cas c’est un mauvais choix, ses besoins se limitent à tout ce qui est triage, correction des niveaux, de l’éclairage et deux trois petits filtres, et ce, sans aucune sélection sur l’image. Gimp ou photoshop sont des logiciels pour professionnels ou passionnés. On retrouve les mêmes problématiques dans tous les autres programmes dont un très connu : le traitement de texte.

Les programmes possédant une interface riche (en graisse saturant… la ram) sont utiles dans des applications professionnelles où les fonctions obscures ont un intérêt. Et si elles sont mal placées dans les menus, il existe des projets comme métisse qui permettent de redessiner une interface graphique en live avec un simple copier-coller.

Oui, mais le partage du savoir informatique dans tout ça. C’est un problème, on permet au gens qui ne veulent pas apprendre de ne pas apprendre, on leur laisse la liberté d’être dépendant. Ceux qui veulent vraiment être libre, le pourront toujours. On a toujours besoin de programmes professionnels avec beaucoup de fonctions, on a toujours les documentations pour apprendre un langage de programmation, comment et surtout quoi coder. En soit, on ne lit pas du Proust au CP, pourquoi devrait-on utiliser gimp ou photoshop ?

Reste les problèmes liés à cette évolution. Le premier est les développeurs. Enfin pas forcément, si le développeur veut un programme simple avec peu de boutons, il se le codera. Autrement il faudra rendre intéressant le codage de ce logiciel en, par exemple, le payant, enfin, plus intéressant… plus rentable. Les développeurs du libres codent souvent sur leur temps libre, c’est un hobby. Ils codent l’intéressant et l’utile, c’est tout. Il ne sont pas taillables et corvéables à merci.

Le deuxième problème est de trouver le bon équilibre, il ne faut pas tomber dans le simplisme ou enlever des fonctions que l’on rajoute par la suite avec des plug-ins à cause d’une mauvaise définition des besoins de l’utilisateur. Même si l’on peut aussi être face à un mauvais choix de l’utilisateur.
Firefox est un bon exemple, c’est un très bon navigateur qui dérive de Mozilla. Mozilla, c’est un navigateur plus un lecteur mail, plus un outil de création de page web, plus… Firefox n’est censé être qu’un navigateur. Voyons l’utilisation d’un firefox aujourd’hui. Que fait-on avec ? On va regarder ses courriels sur un webmail au lieu d’appuyer sur le bouton lecteur de courriel de l’application. Pourquoi ? Et bien, on enlève le besoin de configurer le truc puisqu’apparemment donner un lien vers un fichier chiffré contenant toutes les informations indispensables pour configurer la boite mail n’est pas possible. Il est vrai que les webmails pourris avec de la pub rapportent plus. Si on veut faire un peu de web-design, on installe les extensions pour. Firefox redevient mozilla, ironique non ? Néanmoins, on peut se contenter d’un adblock comme extension, si on ne fait que lire des documents au format (x)html.

La route à destination d’une informatique à la fois simple et puissante est longue et ardue. La philosophie UNIX du « on chaine plein de petits programmes qui font bien leur boulot pour faire un truc puissant » va sûrement aider. Il va falloir trouver un moyen de rendre le chainage simple quand on utilise beaucoup de petits programmes. Qui a dit apprendre le scripting aux gens ?