Le défi : Commencer par l’interface!
Vous êtes développeur et êtes encore sceptique par rapport à la pertinence de concevoir l’interface de vos applications avant même d’écrire une seule ligne de code? Peut-être pensez-vous que cette technique est surestimée, mais lui avez-vous au moins donné une chance de vous convaincre que vous aviez tort? Je vous propose de débuter votre prochain projet de cette façon. J’ai la conviction que vous y découvrirez quelque chose de révolutionnaire. En ce qui me concerne, cette méthode de travail a dramatiquement augmenté le plaisir que je retire à développer des applications sur le Web.
#1 : Tout le monde est visuel
Avez-vous déjà remarqué que bien souvent, lorsqu’on explique quelque chose de relativement complexe à quelqu’un, cette personne finit par nous avouer qu’elle aimerait voir de ses yeux ce que nous sommes en train d’essayer de lui expliquer? Vient ensuite inmanquablement la phrase à 100$ suivante : “C’est parce que je suis quelqu’un de visuel”. A l’inverse, il m’est jamais arrivé qu’on me demande d’expliquer en des mots plus clairs ce que je tentais d’exprimer avec mon interface, tout ça parce que j’avais à faire à quelqu’un d’auditif. Nous sommes tous visuels. Pour cette seule et unique raison, concevoir l’interface d’une application avant de s’attaquer à l’aspect pur et dur de la programmation devient automatiquement une technique gagnante.
Note hors-sujet : J’ai eu l’impression d’être un humoriste lorsque j’ai utilisé l’expression “Avez-vous déjà remarqué”
#2 : La meilleure façon de saisir the big picture
Passer beaucoup de temps sur la conception des interfaces est une excellente façon d’avoir une idée globale du projet, et ça, c’est primordial. Débuter en concevant la base de données, les classes ou tout autre aspect correspondant davantage à la façon dont vous construirez le projet plutôt qu’à ce qui en fera partie vous nuit terriblement dans votre quête visant à obtenir le portrait global de votre application. Lorsque vous bâtissez une interface sans lien avec la programmation derrière, vous n’avez plus de contraintes. Vous vous concentrez sur le quoi plutôt que sur le comment.
#3 : La meilleure façon de rester motivé
Vos interfaces sont peut-être statiques et vos fonctionnalités sont peut-être simulées, mais au moins elles sont là! Vous les voyez, vous savez vers quoi vous vous dirigez. Vous venez à peine de commencer votre projet que déjà vous avez quelque chose à vous mettre sous la dent! Vous pouvez expérimenter autant que vous le voulez sans crainte de déployer des efforts dans le vide. Étant donné qu’il n’y a aucune programmation derrière, il n’y a rien de plus facile que de supprimer un morceau de votre interface si vous le jugez inutile après mûre réflexion. Aucun besoin d’avoir une base de données derrière pour vous mettre des bâtons dans les roues. Vous pouvez déjà naviguer entre les différentes pages et voir immédiatement ce qui cloche, ce qui manque et ce qui est de trop à l’intérieur de votre application.
#4 : Revoir ses priorités
Il n’y a pas de temps perdu avec la conception d’interfaces. On peut les manier et les remanier jusqu’à temps d’être complètement satisfait. On peut ajouter des fonctionnalités sans coder, sans trop penser à leur faisabilité. On oublie le code et on se concentre sur ce qu’on veut faire de notre projet. La structure interne de votre application, bien qu’importante en soi, n’est qu’un sous-composant de votre application. Votre projet n’est défini que par le besoin qu’il tente de combler.
#5 : Dès que le code entre en jeu, vous perdez un peu de liberté
C’est pourquoi il vaut mieux attendre avant de l’inviter à festoyer derrière vos interfaces. Le code est le gardien des contraintes et des limites. Embarquez-le trop tôt et il ne tardera pas à ruiner la fête pour tout le monde. Embarquez-le à la fin et il réalisera que tout a déjà été décidé et que c’est à lui de s’adapter à votre interface. Le code, ainsi que son fidèle complice base de données, ne pourront plus gâcher la vie de personne.
#6 : Il ne vous reste qu’à coder les interfaces une à une…
Vous avez construit toutes les interfaces et maintenant vous avez l’impression d’avoir perdu votre temps? Toutes ces fausses données éparpillées un peu partout… c’est un peu décourageant non? J’éprouvais cette sensation la première fois que j’ai utilisé cette technique mais je me suis vite rendu compte que je m’en faisais pour rien. Remplacer des données simulées par des données réelles est étonnament facile. C’est là que tout commence à prendre forme! C’est d’ailleurs à ce moment que j’ai pris conscience de quelque chose de fascinant : Pour la première fois, c’était mon code qui devait se plier aux contraintes imposées par mon interface et non l’inverse.
#7 : Amusez-vous…
Au-delà de tout ce qui a été dit, concevoir les interfaces au tout début d’un projet est tout simplement amusant. Comme je l’ai mentionné au début de cet article, je ne m’étais jamais autant amusé dans mon travail de développeur Web. Depuis que j’ai commencé à utiliser cette technique, tous mes projets me semblent plus accessibles, plus concrets, plus réalisables. De toute façon, construire une base de données, une classe ou une fonction sans pouvoir voir ce à quoi tout ça va ressembler, c’est compliqué et ennuyeux. Vous savez, c’est parce que je suis quelqu’un de visuel…
Ça tombe bien, moi aussi je suis visuel…
Sérieusement, c’est la meilleure explication que j’ai lu à propos de cette technique. C’est certain que le fait que tu utilises cette technique (et moi aussi) fait de toi une preuve vivante que ça marche.
Je sais qu’il y a environ 1% du monde qui lisent les commentaires mais je vous dis : ESSAYEZ-LE et vous voudrez plus jamais revenir comme avant.
Pour ma part, j’ai jamais vue ça autrement …
Je suis pas certain qu’on parle de la même chose dans ce cas-là. Je ne parle pas de faire une maquette en photoshop et de se “baser là-dessus”. Je parle de faire toute l’application en (X)HTML/CSS et en simulant les fonctionnalités. C’est pas du tout “la norme” ça.
Mais c’est officiel qu’en tant qu’intégrateur, tu as peut-être plus le réflexe de penser comme ça naturellement. C’est plutôt nous, les programmeurs, qui ont généralement tendance à avoir le réflexe inverse.