Avec Felix Corke, un designer, Richard Griffin, un intégrateur, et Ian Griffiths, un développeur.
C'est une session qui me tenait particulièrement à coeur, car WPF et Silverlight permettent à un designer d'intervenir à n'importe quel moment d'un projet mais on se demande souvent comment. Une chose est que la technologie le permette, une autre est de le faire en pratique.
Le processus
Ca ne s'applique qu'aux projets qui ont prévu un budget pour que les applications soient belles. Il ne suffit pas d'utiliser WPF/Silverlight pour que le résultat soit beau. Du coup ça ne s'applique pas à toutes les applications.
Pour que ça marche, il faut mieux:
- réunir tout le monde dans une même pièce
- avoir un contrôle de code source
- que le développeur comprenne Blend
La coopération
Les rôles:
- le développeur écrit le code qui dit ce que l'application fait
- le designer résoud des problèmes mais en ajoute (il fournit un fichier photoshop)
- intégrateur: c'est un nouveau rôle introduit par XAML. C'est celui qui permet au designer de comprendre les contraintes du développeur et inversement.
Le développeur utilise Visual Studio. Le designer utilise Adobe Photoshop et Illustrator, et Expression Blend pour l'intégration. Mais l'un et l'autre peuvent utiliser les outils de l'autre partie de temps en temps ce qui peut rendre la séparation des rôles assez floue.
Les étapes:
- un concept: en général un Photoshop
- transformation en éléments de l'interface utilisateur
- chacun crée: code et assets
- intégration, et on recommence
Le développement
Les erreurs à éviter comme développeur:
- la Grid n'est pas un Canvas. Elle complique tout, d'autant plus qu'elle est le contrôle par défaut dans Visual Studio et Blend;
- tout ce qui est mis dans le code au lieu du XAML ne peut pas être vu et modifié par le designer;
- Blend ne prend pas en chargers quelques fonctionnalités - il faut y penser en tant que développeur.
La data binding permet au designer de travailler. C'est la responsabilité du développeur de fournir un modèle dont les propriété exposent ce qui intéressent le designer (par exemple une propriété qui indique que tel bouton est visible). C'est le View Model. Il peut être créé de manière tout à fait indépendante du XAML et testé séparément (notamment cela permet de créer des tests unitaires).
Le code behind d'un XAML devrait être aussi vide que possible. Tout doit être dans le XAML et dans le View Model.
Pour que les contrôles ne soient pas vides, et donc réduits à zéro, sous Blend, il faut injecter des données fausses lorsque l'on détecte que l'application tourne sous Blend.
Il est rare de devoir créer des custom controls, mais dans le cas où on les crée il faut penser au designer. Il faut fournir des templates. En WPF il faut avoir des événements et propriétés dépendantes, et dans Silverlight il faut utiliser l'attribut TemplateVisualState.
Conclusion
Pour que tout cela fonctionne, le développeur doit tenir compte du designer, et donc faire des choses que l'on ne ferait pas si l'on n'avait pas à s'intégrer avec Blend. Il faut placer le designer au centre, connaître Blend et aimer le XAML.
Comments