Lors de la session de CocoaHeads de jeudi soir, nous avons eu droit à une présentation de Jonathan Perret, qui en bon adepte de la méthodologie XP, crée ses applications de façon itérative. C’est à dire, qu’il fait en sorte qu’elle reste fonctionnelle tout le temps, mais ajoute les nouvelles fonctionnalités, et améliore l’existant au fur et à mesure.
L’un des auditeurs, lui alors demandé s’il faisait de même pour l’IHM (Interface Homme-Machine), ce à quoi Jonathan a répondu par l’affirmative, ce qui ne manqua pas d’étonner l’auditeur qui fit remarquer, à raison, que de nombreuses sociétés ne travaillent pas ainsi. Beaucoup conçoivent les IHM à l’avance sur papier, ou sous Photoshop, et en discutent en comité, avant de demander aux programmeurs d’implémenter le produit de leurs réflexions.
Preuve en est l’existence de nombreux outils pour créer des maquettes graphiques, ou les différents articles d’équipes expliquant comment elles ont conçu leur IHM sur papier avec des gabarits d’écran. Ces maquettes sont bien jolies, mais ce ne sont que des maquettes; non-seulement, les réaliser prend du temps, mais souvent la mise en œuvre réelle révèle que les concepts qui paraissaient si séduisants dans l’imaginaire fonctionnent mal en réalité.
Leur démarche me semble être le produit de dérives visant à occuper les graphistes et créer des plans et autres réunion; bref, des occupations habituelles des grosses boites. Pour ma part, j’utilise donc une approche itérative qui, à mon sens, se justifie par le fait qu’il est relativement peu coûteux (en termes de temps et de ressources) de se tromper. Quel que soit le programme que l’on conçoit, on commet des erreurs de conceptions: ces erreurs font partie intégrante du travail de design. Souvent, il est nécessaire de se tromper pour comprendre quelle est la bonne solution.