Dans le derrière la simplicité se cache…
La simplicité a le vent en poupe présentement sur l’Internet avec à sa proue des compagnies telles Google et 37Signals. (J’utilise des mots de bateau pour dire que la simplicité est à la mode sur Internet à cause de compagnies comme Google et 37Signals. Je sais pas pourquoi j’ai fait ça mais je recommencerai plus.) Par contre, la simplicité a un coût beaucoup plus élevé qu’on le pense.
La pratique actuelle
Les applications les plus difficiles à utiliser sont créées de la façon suivante. D’abord, la base de données est créée avec ce qu’on pense avoir besoin. Ensuite, les classes sont faites pour accéder à la base de données. Après, l’interface est faite pour utiliser les classes qui accèdent à la base de données. Cette méthode est très répandue et serait considérée comme une bonne pratique. FOUTAISE!
Si on remarque bien, le produit final de ce genre de méthode n’est qu’un interface qui permet à un usager d’interagir avec la base de données. Ce n’est pas un interface optimisé pour l’utilisateur afin qu’il puisse faire ce qu’il veut faire. En plus, si il faut changer quoi que ce soit au modèle de la base de données… bonne chance. Comme elle est la base de l’application, il faudra changer les trois couches. Ouch! Je pense que la meilleure méthode est tout simplement de créer l’interface en premier mais c’est un autre débat qui sera le sujet d’un autre article.
Donc, faire de la simplicité complexe demande beaucoup de talent, une bonne vision globale de l’application et des connaissances en ergonomie. C’est beaucoup pour une seule personne.
La simplicité complexe
Lorsque je fais une application complexe, j’essaie de comprendre qu’est-ce que l’utilisateur veut. C’est la première étape. Comment va-t’il l’utiliser? Que veut-il savoir? Comment est-ce que sa vie en sera facilitée? Ce genre de questions.
L’exemple d’application humaine la plus connue est sans doute gmail. Quand les courriels ont été inventés, le mot courriel n’existait pas. Les emails étaient des messages envoyés d’une personne à une autre personne. Pendant 10 ans (entre 1994 et 2004), les applications pour les lire et les envoyer n’étaient qu’une couche de présentation sur la logique de programmation. On recevait un courriel, il s’affichait dans notre liste de courriels reçus en ordre de date. On envoyait un courriel, il allait dans notre boîte de courriels envoyés. Si on voulait suivre un échange de plusieurs courriels entre plusieurs personnes, presqu’impossible.
GMail a révolutionné le monde du courriel en créant le concept de conversation. Ça simplifie énormément l’utilisation de l’application mais le développement a dû être un vrai casse-tête. Mais la résolution du casse-tête en a valu le coût parce que maintenant, on s’attend tous à avoir le concept de conversation dans les nouvelles applications pour les courriels.
Comment faire la simplicité complexe
Je ne suis qu’un débutant dans la simplification des applications mais voici comment je m’y prends.
- L’important est l’interface : une application devrait offrir le moins d’options, de pages, boutons cliquables et d’éléments visuels possible. Par contre, il ne doit pas être trop limitatif.
- Connaître le client : La plupart des développeurs ne connaissent pas le client (et ne veulent pas le connaître). Par contre, il faut savoir ce qu’un client veut faire si on veut pouvoir faire un interface.
- Ne pas répondre à une demande mais résoudre un problème : Le client veut un bouton rouge pour faire telle action? Ne pas faire ce bouton rouge sans savoir pourquoi il veut ce bouton rouge et surtout à quoi il va lui servir. Le client pense que ce bouton rouge est la solution à son problème, mais peut-être savez vous exactement comment le régler.
- Avoir une vision globale : Ça implique de parler à des gens qui nous redoutent : des vendeurs, des directeurs, des téléphonistes. Ces gens sont souvent en contact avec les clients et ils ont leur propre vision d’une application.
- Penser avant de faire : Celui-là est le plus plate. Si on ajoute telle option, est-ce que ça règle vraiment le problème ou ça en créé un autre? Est-ce que la façon de faire actuelle est la meilleure solution qu’on a pour l’instant? L’important est de prendre environ 5 minutes de plus pour penser et on peut gagner des semaines de travail.
Tout ça pour dire que dans le derrière de la simplicité se cache la complexité.
C’est dur de ne pas succomber au point #3. Des fois le client tient vraiment à avoir son bouton rouge.
La plupart du temps j’essaye de “conseiller” ou “recommander” autre chose… mais quand je vois qu’ii a l’air déçu je lui dit “Ben moi je peux le faire le bouton rouge, pas de problème, c’est juste que je ne suis pas sûr que ce soit souhaitable”. Cette phrase porte souvent fruit alors je l’utilise souvent.
C’est clair qu’il faut user de subtilité dans quand le client insiste. Ça fait longtemps que je ne crois plus vraiment à l’approche classique d’analyse qu’on nous a enseignée.. en fait j’y croyais plus après environ 10 minutes après l’avoir entendue. Je pense que ça vaut le peine de faire l’analyse de la base de données et tout mais plus pour refactoriser une application.
Quand je suis forcé de faire une analyse classique, je l’a fait mais je fais aussi une esquisse de l’interface sur papier. Je met sa dans la face de l’utilisateur final et je lui demande comment il pense que ça fonctionne. S’il comprend pas.. c’est à retravailler.