PIA Blog / Productivity by Design

  Adobe Flash Catalyst est un nouvel outil destiné à la conception d’interfaces. Il se démarque clairement de ses concurrents par son orientation : faire le lien entre les logiciels de conception d’interfaces (comme Photoshop ou Illustrator) et les logiciels de développement de ces interfaces (Flash Builder).
Malgré une date de sortie lointaine, premier semestre 2010, Adobe propose une version bêta de son logiciel ; probablement pour ne pas se laisser déborber par Microsoft et la sortie de SketchFlow.

Jusqu’alors, le style, l’apparence et les éléments graphiques étaient mis à disposition de l’équipe de développement via une bibliothèque Flash (fichier SWF) et une feuille de style (fichier CSS).
Or, un prototype produit avec Flash Catalyst est directement convertible en projet de développement, ce qui a attiré notre plus vive attention.

Ce deuxième article fait suite à celui sur la conception d’interfaces et traite de la collaboration entre designer et développeur à travers Catalyst :

1. Développer à partir du prototype
2. Workflow designer/développeur
3. Bonnes pratiques
4. Bilan & Liens

1. Développer à partir du prototype

Flash Builder, anciennement Flex Builder, peut donc convertir un fichier Catalyst en un projet Flex.
Ce projet sera en tout point identique au prototype (puisque techniquement, Catalyst utilise lui-même Flex), et pourra implémenter les fonctionnalités requises.

Cependant, le projet généré n’est pas du tout orienté pour le développement :

• Certaines contraintes de Catalyst impose un agencement des composants qui n’est pas pertinent pour le développement.
• Certains composants devront être programmés avec Flash Builder (ex: un menu dynamique).
• De façon générale, les mécanismes de la programmation orientée objet (notamment l’héritage) sont complètement occultés.
• Catalyst ne produit pas un code directement intégrable dans une architecture telle que Cairngorm.
• Catalyst ne prend pas en compte les temps de réponse serveur.

Le projet issu du prototype doit donc être vu comme un canvas pour les futurs développements. La structure du projet évoluera de façon importante, car les objectifs d’un prototype ne sont pas les mêmes que ceux d’un projet de développement.


2. Workflow designer/développeur

Les travaux de conception et de développement ne sont jamais séparés : la conception peut évoluer et impacter le développement. Dans les projets de grande envergure, il est donc plus efficace de diviser une application en lots de fonctionnalités, qui sont un à un plus maitrisables.
Or, Catalyst ne permet pas de diviser le prototype en lots de fonctionnalités. Si le prototype intègre une nouvelle fonctionnalité après que les développements aient commencés, alors cette dernière devra être répercutée sur le projet manuellement.



Par contre, l’apparence peut être changée dans le prototype et répercutée sur le projet via Catalyst.
Une approche consiste à créer une librairie de composants à partir du prototype, et de créer un projet qui utilisera celle-ci : cela se révèle pratique pour que les designers puissent intervenir à posteriori sur le projet. Par exemple, la mise à jour de l’apparence d’un bouton. Je vous invite à consulter l’excellent article de Marc Hughes sur ce sujet.
Cependant, cette approche demande un travail d’adaptation, et oblige à suivre la logique de Catalyst, qui n’est pas orienté développement.

Or, grâce à la nouvelle architecture des composants Flex, l’apparence de ces derniers est complètement séparée du reste. Pourquoi ne pas isoler ces fichiers et ne permettre leur modification qu’à travers Catalyst, alors que le reste est entièrement remaniable via Flash Builder?

Pour ce faire, voici une application Adobe AIR qui s’en chargera  : télécharger Catalyst Plus

Parmi les composants Flex, seule l’apparence des boutons, listes, champs de texte et ascenseurs peut être changée avec Catalyst. Voici, par exemple, comment changer l’apparence d’un bouton et répercuter ce changement sur le projet de développement :

Cependant, il a été annoncé que l’apparence des autres composants sera modifiable dans la version finale de Catalyst. Pour l’instant, l’apparence de ces composants peut être changée de la manière suivante :

Par contre, l’agencement d’un écran ne pourra être modifié et l’ajout de nouveaux états ne sera pas pris en compte.


3. Bonnes pratiques

Voici quelques bonnes pratiques qui sont apparues lors de utilisation de Catalyst et de Flash Builder :

• Donner des noms explicites aux calques et aux composants (ex: ‘SkyBackground’ ou ‘CancelButton’).
• Lors de la création d’un composant, placer les élements qui le composent avant de créer le composant, sinon il faudra le refaire pour chaque état.
• Commencer par créer les composants de haut niveau (ex : un écran) vers ceux atomiques (ex : un bouton) pour éviter de perdre à chaque fois les interactions de ces derniers.
• Ne pas créer un composant à chaque fois, essayer de mutualiser au maximum (ex: un composant Button peut être réutilisé plusieurs fois).
• Ne pas créer d’interaction dans un skin (cela introduirait du code, ce qui est contraire à l’architecture de Flex).
• Privilégier le graphisme vectoriel de manière à pouvoir le modifier facilement par la suite.

4. Bilan & liens

Un prototype crée avec Catalyst peut être repris par l’équipe de développement. Cependant il devient difficile d’impacter des changements du prototype, une fois les développements amorcés. A première vue, son concurrent direct, SketchFlow de Microsoft, souffre du même problème.

Ainsi, dans le cas de projets complexes, qui conjuguent conception et développement, Catalyst montre (pour l’instant) ses limites. Il semble donc tout aussi important de faire évoluer les méthodes de travail et de communication, afin d’instaurer une collaboration plus efficace entre designers et développeurs.

Liens

• Catalyst
• le forum de Catalyst
• Flash Builder
• Tutoriaux en français
• Adobe TV « Flex improves designer/developer workflow »
• Marc’s Musings « Why I like my proposed Catalyst workflow »