Close Menu Navigation
Open Categories Menu [How To] Conception de maquettes interactive MVVM – 1 – La structure
- 21 July, 2012 -
- Actus, PixelSense, Silverlight, Tutos Docs, Windows 8, windows phone 7, WPF -
- Tags :
- 5 Comments
Comme la plupart d'entre vous, plus nous avons de clients, plus nous réalisons le même type de prestation, et plus nous expérimentons de meilleures méthodologies de production. Ces méthodologies sont communes à l'ensemble des technologies de l'environnement .Net.
Chez Peps-Interactive et par le passé, tous les projets que nous avons livré suivent les mêmes étapes lorsque l'on conçoit l'UX d'une application :
- Croquis / Prototype SketchFlow
- Maquette graphique au format Expression Design / Illustrator (surtout pas de Photoshop pour l'intégration .Net)
- Maquette Interactive intégrée au format XAML / MVVM
Chaque étape évolue à sa manière mais c'est la dernière dont je vais parler dans ce post car c'est celle qui pour nous a le plus évoluer.
Tout d'abord, la maquette a pour but de faciliter la mise à jour de l'intégration graphique entre chaque équipe (Dev / Design) et de surveiller la qualité de rendu finale. Elle agit comme un cahier de recette et doit être au moins partiellement navigable même avec des mécanismes très simples.
Si vous êtes habitués à SketchFlow, passez à l'étape supérieure pour la maquette interactive en réalisant les transitions vous-même. De cette manière votre application ne sera pas contenue dans le lecteur, elle sera plus légère que dans SketchFlow et vous ne vous taperez pas les styles Buxton qui ne sont plus nécessaires à cette étape.
Tout d'abord voici la structure MVVM dont j'ai toujours besoin quelque soit le projet :
cliquez dessus pour zoomer l'image.
Les avantages de la conception MVVM pour la maquette interactive
A ce stade j'ai plusieurs remarques concernant les avantages de la conception MVVM.
- Cela vous permettra d'obtenir des données typées au Design Time dans Blend. Ces données seront plus proches du résultat final qu'en passant par des samples datas qui sont plus adaptées à SketchFlow.
- MVVM vous permettra de dé-corréler simplement la fonctionnalité de la vue grâce à la liaison de donnée (Databinding) et aux commandes. Du coup les équipes de développeurs à qui vous passerez le bébé intègreront vos assets XAML plus simplement.
- Les vues que vous allez créer seront bien dans le répertoire Views et vous aurez des sous répertoires pour les sous-rubriques.
- Vous serez obligés de vous posez des questions concernant le contrat fonctionnel de chaque vue ce qui vous oblige à avoir eu en amont une réflexion ergonomique poussée.
- Vous obtiendrez des modèles de données cohérents proches de ce que les développeurs obtiendront de leur couche de service.
La structure globale
Voici à quoi servent les autres répertoires et fichiers :
Fichier racines
- Samples.xaml
C'est un UserControl contenant les contrôles intégrés / skinnés et représentés de manière unitaires. On différencie 5 catégories : Button, Input, RangeBase (slider, progressbar, scrollbar,etc...), Selector / List, Layout (HeaderedContentControl, etc...), CustomControl(vos contrôles à vous).
- Shell.xaml
Cette page ou fenêtre constitue la racine de votre maquette, c'est elle qui permettra de réaliser simplement des transitions entre chaque page.
Répertoires
- CustomControls & Themes
Ces répertoires contiendront les fichiers faisant référence à des CustomControls que vous aurez identifiés comme nécessaires aux vues de vos projets et donc que vous aurez réalisés vous-mêmes. N'allez pas trop loin n'ont plus dans le développement de contrôles complexes car ce n'est pas toujours envisageable pour des raisons de contrôle de code ou même d'architecture. Avant de vous lancez dans la conception d'un contrôle, vérifiez bien que vous ne pouvez faire autrement.
- Fonts
Ce répertoire contient toutes les fonts non embarqués par défaut dont vous pourriez avoir besoin.
- Images
Ce répertoire contient toutes les illustrations graphiques, utilisées lors de la conception comme base, ou faisant partie de l'application finale.
- PseudoModels & ViewModels
Ces répertoires contiennent respectivement les classes servant de modèle de données et centralisant les fonctionnalités. Globalement vous devriez obtenir un ViewModel par View.
- Resources
C'est sans doute le répertoire le plus intteressant et important en termes d'intégration graphique. Il ne faut pas le confondre avec le répertoire servant à la localisation. Dans ce répertoire, nous regroupons les ressources XAML par type.
- PrimaryRD.xaml : Contient les marges, des références pointant vers les fonts de base, la taille des fonts par structure (Header, SubHeader).
- ColorsRD.xaml : Les couleurs primaires réutilisées par les brushes sont ici.
- BrushesRD.xaml : Contient tous les Brush de type Solid, Gradient
- ImageBrushRD.xaml : Contient tous les Brush pointant vers une image
- PictosRD.xaml : Contient tous les DrawingBrush (pinceaux vectoriels) attention dans certains cas d'injection on peut obtenir des leaks...
- StylesAndTemplates.xaml : possède tous les styles anonymes. Toutefois, tous les styles nommés auto-générés par Blend peuvent également y être. C'est le cas pour les DataGrid par exemple.
- SpecificStylesAndTemplatesRD.xaml : Ce dictionnaire est important puisqu'il regroupe tous les styles et modèles que vous êtes dans l'obligation de nommer parce que différents de ceux appliqués par défaut.
- DataTemplateRD.xaml : de manière générale, c'est une bonne pratique de ne pas laisser les DataTemplate de listes ou de Combo directement au sein d'un UserControl. Ceux-ci seront souvent partagés entre deux pages. Il ne faut donc pas hésiter à créer ce dictionnaire.
- ConvertersRD.xaml : centralise tous les converter (IValueConverter) permettant facilement d'interpréter un objet logique sous forme de visuel.
- ViewModelsRD.xaml : afin de limiter la casse et de simplifier au maximum la conception d'une maquette n'hésitez pas à instancier vos ViewModel sous forme de ressources.
- UserControls versus Views : Attention ces deux répertoires ne contiennent pas le même type de UserControl. Le premier contient des UC réutilisables et / ou modulaires comme un footer ou une zone d'information,... Le second contient des pages entières de l'application constituées de modules et de contrôles unitaires.
- Utils : ce dossier regroupe toutes les classes dont vous avez besoin mais qui ne sont pas forcément utilisables pour les développeurs: la définition des commandes, la classe de base d'un vue-modèle, etc... La plupart des équipes de développement réalisent elle-même leur Framework de navigation sous des formes avancées utilisant MEF ou Unity. Inutile donc d'aller trop loin de ce point de vue car ce n'est pas vraiment le sujet qui vous préoccupe en tant que Designer.
Pour finir, n'oubliez pas de stocker toutes les dlls que vous utiliser dans un répertoire dlls situés à la racine de la solution, de cette manière vous serez sûr que la maquette sera consommable.
Ce premier article sur la conception de maquette graphique est terminée, le prochain que je ferai concernera la gestion de la navigation. Je fournirai une solution Visual Studio à cette occasion.
C’est intéresssant de voir comment tu organises le projet d’une maquette.
C’est une segmentation logique qui permet de réutiliser les “morceaux” plus tard dans le projet final.
La création de multiples dictionnaires est aussi quelque chose que je pratique, mais n’es tu pas gêné, in fine, par les dépendances qui se créent entre tous ces dicos ?
A la fin on a souvent pleins de dicos mais qui dépendent tellement les uns des autres qu’il aurait mieux fallu tout mettre au même endroit je trouve. J’essaye donc toujours de trouver un juste milieu (par ex, couleurs et brosses sont dans un même dico).
L’exemple classique c’est les couleurs et les brosses. Si on sépare c’est plus clair (comme tu le fais) mais le dico des brosses accède et dépend forcément de celui des couleurs. Dans ce cas là les dépendances sont évidentes et l’ordre de déclaration des dicos dans App.xaml est facile à gérer. Mais pour tous les autres dicos, quand ils se multiplient c’est moins évident.
Concernant MVVM, tu ne parles pas de la librairie que tu utilises, tu n’utilises rien pour la maquette ? Je vois que tu parles d’instancier les VM comme des ressources pour simplifier, pourquoi alors ne pas maquetter en utilisant MVVM Light par ex, qui s’occupe de tout ça (ou un autre framework) ? Choix délibéré pour la maquette ? Comment se passe alors ton intégréation “réelle” si le projet utilise un framework MVVM ?
Merci pour toutes ces questions Olivier.
De mon expérience moins on utilise de Framework pour maquetter et moins on a à les expliquer par la suite aux équipes de dev. Ces derniers ont les leurs (internes ou récupérés). Comment dire, ils en utilisent tous un mais cela change très souvent pour chaque client.
Du coup, la sagesse et surtout l’expérience me dictent d’utiliser l’implémentation la plus simple possible. Car il ne s’agit en aucun cas de développer l’application mais de fournir des vues et des contrôles unitaires qui seront raccords avec la fonctionnalité (les Vues-Modèles) quelques soient les mécanismes d’implémentations qui seront utilisés.
General Electrics utilise son propre Framework MVVM, Elior aussi, Accor aussi, Société Général aussi, Microsoft Services ou DPE, j’en parle même pas car cela change avec chaque consultant etc…
Comme ce n’est pas mon rôle, j’essaie d’éviter de former les équipes de dev à un nouveau Framework même si c’est Laurent B. qui l’a fait.
Sur un autre aspect, sur les gros projets ne pas organiser les dictionnaires est juste suicidaire, et limite passible de la peine capitale (payer une bière et faire ses excuses en donnant ta poupée vaudou) en terme de maintenance. Demain, si on me demande de changer l’AccentColor de n’importe quel projet, je sais faire en 10 secondes et ça impactera tout.
Il est également obligatoire de séparer les dico exportés depuis Design (notamment pour les pictos).
Honnêtement lorsque c’est correctement fait, tu ne devrais pas obtenir de référence cyclique avec des Merged Dictionnaries…
Enfin par exemple, il est de bonne guerre de se dire que les couleurs des charts, le skin des charts, les styles de Datagrid, etc… doivent être séparés. Car certains objets peuvent prendre une bonne vingtaine de ressources à eux seuls… et je te parle pas des librairies component one et / ou surtout Telerik de notre ami Justin.
En gros ce que je dis dans le post c’est pas un truc que j’ai imaginé sur le papier ou fantasmé en m’astiquant devant l’arborescence. Au contraire c’est un réel retour d’expérience d’intégration et de design interactif .Net acquis sur le terrain et accumulé depuis 2007 sur WPF, WPF/e, Silverlight, Windows Phone et W8.
ah oui j’oubliai ce n’est qu’une maquette donc pas besoin de développer autre chose que de la vue des données simples et des commandes bidons. Dans ce post je ne m’adresse pas forcément à de purs dev qui chercheraient une justesse architecturale. Mais à des designer / dev / intégrateurs qui souhaitent optimiser le flux de prod en mode agile.
Si tu veux en discuter devant une bière à l’occaz… sinon j’ai envie d’écrire un post sur “Pourquoi les Datagrid c’est pourri ? Pourquoi est-il en voie de disparition ?” ça te parle ?