Ce document présente le retour d'expérience de l'équipe Steria et I-Breed sur la conception d'une application tactile multi touch dans le cadre du concours SNCF "Inventez la nouvelle façon d'acheter des billets en Agence SNCF"
14. Des Spécifications d’IHM (pas très classiques…) [1] Le calendrier commence à la date du jour du jour et glisse sur 12 semaines (glisser pour faire défiler les semaines) La date par défaut est la date du jour [2] L’heure par défaut est la première heure. Pas de sélection par défaut des plages horaires [3] Le bouton « Ajouter retour » fait apparaître la zone bas de l’écran et le bouton se renomme en « Supprimer le retour » 1 2 3
15.
16.
17.
18. L’univers visuel du projet Steria - I-Breed - TechDays 2010 Steria - I-Breed - TechDays 2010
19. L’univers visuel du projet Steria - I-Breed - TechDays 2010 Steria - I-Breed - TechDays 2010
A partir des spécifications d’écrans Sur les propositions de design En cohérence avec la faisabilite technique Evaluation et test informels pour valider nos propositions
Guidage du process (enchainement par défaut des pages) Instructions pour accompagner Feedback et indices de tactile
Accès à une BLS pour avoir un élément de référence des fonctionnalités, informations et étapes actuelles du processus de commande
les critères/ éléments qui permettent de composer le voyage une zone de « travail » qui permet de préciser la valeur de chaque critère du voyage, de visualiser le détail d’un train etc une barre de suivi de progression qui permet à l’utilisateur d’identifier les éléments qu’il doit encore renseigner pour composer son voyage un « panier » qui regroupe les différents trains que l’utilisateur a sélectionnés et qu’il va comparer avant de sélectionner le voyage définitif un conseiller virtuel pour la partie assistance / conseil des scénarios Définition des interactions tactiles à la fin
Univers de couleur : couleurs chaudes, confortables rassurantes en cohérence avec les codes couleur de la scnf look : deux pistes à explorer : l’utilisateur est ancré dans la réalite => les objets présentés sont le plus proches possibles du monde réel. Par exemple l’écran d’accueil représente la gare du futur dans laquelle l’utilisateur va choisir de l’orienter vers le conseiller, l’espace borne de résa, les départs immédiats etc. Le calendrier pour sélectionne les dates du voyage ressemble à un calendrier papier classique, les cartes de réduction à celles du monde réel etc on reste sur les mêmes idées, mais plus symbolique pour faciliter au maximum la reconnaissance Design : On reste sur les pistes de desing proposées : Un design proche de l’univers SNCF. Une expérience visuelle illustrée. Un graphisme « tactile » : Volume. Transparence. Éléments interactifs dimensionnés pour le tactile. Un design proche de l’univers SNCF. Une expérience visuelle illustrée. Un graphisme « tactile » : Volume. Transparence. Éléments interactifs dimensionnés pour le tactile.
Etre proche de la réalité, du quotidien de l’utilisateur, par exemple : Calendrier pour les dates Le chemin d’un critère à l’autre qui jalonne la construction du trajet Le billet de train Le dossier/ panier pour y mettre les billets Un design proche de l’univers SNCF. Une expérience visuelle illustrée. Un graphisme « tactile » : Volume. Transparence. Éléments interactifs dimensionnés pour le tactile.
Langages : C# : pour mémoire, C# est une langage de programmation orienté objet à typage fort, créé par Microsoft. WPF : initiales de Windows Presentation Foundation. Il s’agit de la nouvelle spécification graphique de .NET 3.0. Intègre le langage descriptif XAML. XAML : Langage descriptif basé sur le XML. Il y a une hiérarchie dans les éléments, c’est-à-dire qu’il y a un élément racine , et que chacun des autres composants est contenu dans un et un seul composant parent. Outils : Expression Design : comme présenté plus tôt par Tristan, il s’agit d’un outil de création et d’illustration professionnel. Expression Blend : outil de conception d’interfaces utilisateurs et d’intégration. Supporte la version 3.5 de .NET. Visual Studio 2010 : environnement de développement intégré de Microsoft. Encore en beta 2. .NET 4.0 et WPF 4 sont intégrés (WPF 4 est la version à partir de laquelle on peut faire du Multitouch). Visual Studio 2008 : Version antérieure de Visual Studio. Supporte .NET jusqu’à la version 3.5 : il n’y a pas de Multitouch.
Pendant les brainstorms, et en attendant les premiers écrans, l’équipe technique s’est occupée : Du chargement des données (les données étaient fournies au format Excel : il s’agissait de les mettre au format csv et d’en optimiser le chargement au lancement de l’application) Du diagramme de classes De se familiariser avec WPF : Affichage des données chargées avec les contrôles de base Essais avec le Multitouch Nous n’avions pas d’écran tactile à notre disposition au début du projet. Pour procéder aux premiers tests et appréhender la technologie Multitouch, nous avons utilisé un outil permettant de simuler le Multitouch par l’intermédiaire de plusieurs souris : chaque souris représente donc un point de contact, ce qui permet de simuler des manipulations comme la rotation et le zoom. Voici une vidéo montrant ce que nous sommes parvenus à faire : c’est très moche, d’accord, mais nous avons pu en conclure que le Multitouch est quelque chose d’assez aisé à mettre en place. Nous pouvions donc nous concentrer sur l’intégration des écrans et le code métier.
Vidéo sur les PoC
Comme au cours de tout projet, nous avons rencontré quelques problèmes et difficultés. Après vous les avoir présenté, je vais vous parler des solutions que nous avons appliqué.
Problèmes de compatibilité entre VS2010 (utilisé pour le Multitouch avec .NET 4.0) et Blend 3 (qui ne supportait que la version 3.5 de .NET). Introduction d’une variable de compilation permettant de compiler certains bouts de code en fonction de la version de .NET utilisée. Plusieurs solutions (.sln) en parallèle : La solution .NET 4.0 avec VS2010 La solution .NET 3.5 avec Blend 3 et VS2008.
Translation du contrôle de départ à faire tourner à l’extérieur de l’écran. Rotation de deux VisualBrush (qui n’est qu’une image du contrôle à un instant donné => optimisation), représentant le contrôle à faire tourner. Translation du contrôle d’arrivée à faire tourner à l’intérieur de l’écran.
En fonction du matériel, certains boutons ou certaines zones peuvent être moins réceptives (ne réagissent pas) aux interactions utilisateurs? Ceci peut être dû à des zones trop petites. Pour régler le problème, nous avons agrandi les zones tactiles. On voit sur l’impression d’écran que la zone réceptive au contact (ici, en bleu) a été agrandie par rapport au bouton affiché. Comme ça, même Sophie-Laure arrive à cliquer sur les boutons !
Pour rappel, le XAML est basé sur le XML. Il y a une hiérarchie dans les éléments, chaque contrôle ou composant se trouve dans un et un seul parent. Un élément ne peut changer de parent. Nous avions parfois besoin de déplacer des composants qui étaient contenus dans des listes et les déposer en dehors du contrôle parent. Par exemple : les trains avec leurs différentes classes. Lorsqu’un utilisateur voulait acheter un billet, il devait le déplacer dans le panier. Nous avons donc créé un duplicata invisible du contrôle à déplacer et l’avons positionné au niveau de la fenêtre principale. A chaque déplacement (ou glisser / déposer), ce duplicata était affiché et prenait l’apparence de celui qu’il devait impersonnifier. A la fin de chaque manipulation, ce duplicata était à nouveau rendu invisible.
Les données fournies par la SNCF contenaient beaucoup trop de prix identiques, il n’y avait aucune différence entre un train partant à 6h du matin un lundi, et un train partant à 6h du soir un vendredi. Nous avons donc introduit une variation dans les prix, basée sur une sinusoïdale en fonction de l’heure de départ du train. Nous avons par conséquent pu mettre en place la jauge permettant de filtrer les trains par rapport à leurs prix. Démo !