Du Wireframe au prototype : les possibilités offertes par Axure

0

 

axure

Wireframe VS Prototype

Un Wireframe (que l’on peut traduire par fil de fer) est une maquette fonctionnelle constituée de formes simples représentant l’interface d’un site Web, d’un outil métier, d’une application mobile ou d’un logiciel.

Dans un prototype, s’agit d’aller plus loin que dans un Wireframe : en y ajoutant les interactions possibles et éventuellement des objets graphiques.
Il est particulièrement utile pour vérifier l’ergonomie de l’interface, pour anticiper d’éventuels problèmes liés à la navigation ou à la compréhension de l’interface et des interactions par l’utilisateur.

 

Qu’est-ce qu’Axure ?

Axure est à l’origine un logiciel à destination des ergonomes et a fortiori des chefs de projet et des graphistes, permettant de construire des arborescences, des schémas, des Wireframes et des prototypes, pour pouvoir notamment les soumettre au regard du client.

A partir d’objets (widgets), il est possible de créer des interfaces, interactives ou non. Ses objets sont plus ou moins configurables. Axure offre une large palette de stylisation et d’interaction pour ces différents objets.

Axure permet d’exporter en différents formats, HTML ou documents (spécifications) et aussi de travailler de manière collaborative sur un même projet grâce à sa fonctionnalité de partage intégrée.

 

Interface et espace de travail 

interface Axure

 

L’interface modulable est constituée par défaut de :

1. une barre de menu : barre de menu classique permettant d’accéder à diverses fonctionnalités (enregistrement, export, organisation de la fenêtre, etc.).

2. une barre d’outils : accès aux fonctionnalités principales et aux outils courants (copier/coller, outils de sélection, organisation des éléments présents dans l’espace de travail).

3. un volet Pages : qui permet de matérialiser l’arborescence des écrans du prototype en cours de construction, il est possible d’ajouter, de dupliquer, de supprimer des pages, et de créer des dossiers pour les regrouper. On peut ainsi créer rapidement un organigramme des écrans.

4. un volet Libraries : accès à ce qui est appelé dans Axure des widgets, ce sont des objets types qu’il est possible d’utiliser dans ses écrans (textbox, tableaux, menus, etc.).

5. un volet Masters : permet de créer ce que l’on pourrait appeler des modèles qui peuvent ensuite être utilisés et réutilisés dans un ou plusieurs écrans (header, footer, etc.).

6. un espace de travail : il s’agit de la page/l’écran sur lequel on travaille et dans lequel on va ajouter les différents éléments issus des librairies/masters par glisser/déposer.

7. un volet Inspector : accès aux différentes propriétés des widgets placés dans l’écran en cours de construction. Il dispose de 3 onglets :
– 7a. Properties : dans lequel on va essentiellement définir les interactions des widgets (onClick, onLoad, etc.) ; ces événements peuvent être conditionnés (ex : « si mon champ possède la valeur ‘2’ »)
– 7b. Notes : qui permet d’enrichir le prototype de certaines remarques, particulièrement utile pour la génération automatique de documents
– 7c. Style : qui permet de définir les attributs liés aux widgets (couleur, dimension, position, etc.)

8. un volet Outline : dans lequel sont listés tous les éléments (objets et groupes d’objets) présents dans l’écran ou le master en cours de consultation. Il est essentiel de penser à renommer chaque objet créé, de manière à faciliter la gestion des objets de l’écran.

 

Zoom sur quelques fonctionnalités

Librairies de widgets

C’est dans ce panneau que sont regroupés les objets utilisables dans l’espace de travail. Pour les y ajouter il faut glisser déposer l’objet du panneau vers l’espace de travail, il est ensuite possible de le déplacer où l’on souhaite.

Parmi les widgets les plus classiques, mis à disposition, on retrouve (par défaut) :

  • des boutons ;
  • des éléments de formulaire (champ texte, zone de texte, liste déroulante, cases à cocher, boutons radio, etc.) ;
  • Image : pour délimiter une zone d’image ou pour ajouter une image de son poste de travail ; à noter qu’il est également possible d’importer un média externe (image, vidéo, etc.) par simple copier-coller ;
  • Place holder : pour délimiter des zones ;
  • des formes prédéfinies (rectangle, flèche, filets séparateurs, etc.) ;
  • des éléments complexes (tableau, menus, iframes, etc.) ;
  • dynamic panel : puissant composant permettant de définir des sous-éléments de page à diriger avec les interactions.

 

Il est également possible d’ajouter des librairies gratuites ou payantes, pour compléter les librairies proposées, et même de créer sa propre librairie pour pouvoir réutiliser ses objets facilement d’un projet à un autre.

 

Gestion des interactions

interactionsLes widgets sont paramétrables sur un certain nombre de critères accessibles dans l’onglet Properties du volet Inspector :

  • Interactions : permet de définir les interactions et les liens sur les objets :
    – les événements associés au type d’objet sont proposés par défaut (clic, select, keyUp, etc.) ;
    – une fois l’événement choisi, il est possible d’y appliquer des conditions d’exécution (if/if/else) ainsi que la liste des actions à appliquer lors de l’exécution de l’événement (masquer, changer d’état, définir une valeur, etc.).
  • Text Link : permet d’appliquer un lien hypertexte ;
  • Shape : une boîte peut être utilisée pour afficher une forme prédéfinie (cercle, flèches, etc.) ;
  • Interactions styles : permet de définir des changements de style (gras, italique, etc.) lors du déclenchement d’évènements (mouserOver, selected, etc.) ;
  • Selection group : permet de définir des groupes de contrôles (pour y faire référence lors d’interactions) ;
  • Tooltip : permet d’afficher une infobulle au survol de l’élément.

 

 

 

Gestion des notes

notesPar défaut il n’y a qu’un seul champ ‘notes’, mais il est possible de créer de nouvelles propriétés qui seront alors répercutées sur l’ensemble des ‘pages’ du projet.

La valeur de chaque propriété sera cependant propre à chaque ‘page’

Il est préconisé de définir les propriétés au début du projet, et uniquement si vous souhaitez générer une documentation.

NOTA : Comme il sera possible de choisir quelle propriété exporter (et dans quel ordre) lors de la génération automatique d’une documentation, il est tout à fait envisageable d’utiliser le même projet Axure pour générer différentes documentations.

 

 

 

 

 

Gestion des styles des objets 

objetsOn peut accéder aux Styles liés aux widgets depuis le volet Inspector, (certains sont accessibles également directement dans la barre d’outils) ils offrent plusieurs possibilités en fonction du type d’objet sélectionné, on peut :

  • Indiquer précisément les dimensions et positions de l’objet ;
  • changer son orientation : sa rotation (y compris pour du texte), retourner un objet par symétrie, ajuster la taille d’une zone de texte au texte qu’il contient ;
  • régler la visibilité (case à cocher Hidden) ;
  • changer la couleur de fond pour une forme ;
  • ajouter un ombré ;
  • modifier les bordures : épaisseur, style, couleur ;
  • pour certaines formes, arrondir les coins ;
  • régler l’opacité ;
  • modifier les paramètres de texte : police, taille, alignement, couleur, graisse, italique ou non, souligné ou non, espacement des lignes ;
  • créer des listes à puces ;
  • ajuster les marges intérieures d’un bloc (Padding).

Il est possible de modifier les styles associés à un type de widget en particulier cela affectera alors tous les objets de ce type présent dans tous les écrans du projet ou créer de nouveaux styles d’objet. Pour cela il faut se rendre dans le Widget Style Manager accessible rapidement depuis le bouton présent dans la barre d’outils :

objets2

 

 

 

 

Création de modèle : Masters

Les Masters sont faciles à créer. Il y a 2 méthodes :

  1. créer au préalable les objets dans l’écran et les convertir en Master (clic droit > Convert to Master) ;
  2. dans le volet Masters, ajouter un nouveau master, l’ouvrir dans l’espace de travail et ajouter les éléments voulus .

Les masters correspondent à des éléments qui sont communs à plusieurs écrans par exemple un header, une barre de menu, etc.

Ces masters peuvent ensuite être appliqués à une ou plusieurs pages de l’arborescence (par glisser-déposer, comme un élément de libraire classique). Vous pouvez aussi depuis ce panneau, supprimer un master d’un ou plusieurs écrans, organiser vos masters, ou dupliquer un master. Lorsque vous modifiez un master, ces modifications sont ainsi répercutées sur l’ensemble des pages dans lesquelles il a été inséré.

Il y a plusieurs modes de fonctionnement grâce au paramètre Drop Behavior (répartition du comportement) :

  • Lock to master location : les interactions sont gérées dans le master et lorsqu’il est appliqué à une page les éléments sont positionnés aux même coordonnées que dans le master et ne peuvent pas être déplacés ;
  • Place Anywhere : les interactions sont gérés dans le master mais dans ce cas l’objet peut être déplacé dans l’écran comme bon vous semble ;
  • Break Away : les éléments et les interactions peuvent être modifiés et sont indépendants d’un écran à l’autre.

 

Export du prototype

Le bouton Preview vous aidera au fur et à mesure de votre avancement à vérifier l’aspect de votre Wireframe ou prototype mais surtout vos interactions et le parcours utilisateur (touche F5).

Une fois votre interface finalisée, pour la présenter à un client vous pouvez l’exporter en différents formats :

  • Format HTML : Permet d’avoir un prototype entièrement fonctionnel (si vous avez ajouté des interactions) pour valider les parcours utilisateur. Cela permet aussi d’identifier des lacunes ergonomiques avant les développements.
  • Format Word : L’export peut être basé sur un modèle de document spécifique, et permet ainsi d’utiliser une mise en page particulière (sommaire, entête/pied de page, etc.). Les différents éléments du projet pourront ensuite être sélectionnés comme devant être exportées (quelle page, quelles notes, quelles propriétés etc.) ainsi que leur ordre d’export. Les styles à appliquer au titres pourra également être définis, le tout pouvant être sauvegardé dans un template permettant de générer différents types de documents ayant des mises en pages différentes sans devoir refaire son paramétrage.
  • Autres formats : d’autres formats d’exports peuvent être téléchargés et ajoutés à Axure (csv, odt, etc.)

 

Mon expérience, de la théorie à la pratique

Le maquettage / prototypage des interfaces est selon moi une phase très importante car il permet :

  • de donner au client une vision claire de son produit pour lui permettre de valider les grands principes de navigation, de mise et page, voire des orientations graphiques ;
  • d’anticiper les problèmes d’ergonomie et de navigation et d’identifier des problèmes de cohérences entre les écrans ;
  • de mettre rapidement des solutions à l’essai avant les développements pour éviter de faire, défaire et refaire.

 

Les impressions de ma première expérience avec Axure :

  • la prise en main des fonctionnalités de base est assez simple ;
  • l’interface est intuitive en particulier pour des personnes habituées à des logiciels de graphisme (un espace de travail, des outils, des objets, des panneaux pour configurer ces objets) ;
  • l’ajout des éléments depuis la librairie se fait uniquement par glisser/déposer ce qui peut être un peu surprenant car avec les outils de graphisme, on a plutôt l’habitude de sélectionner son outil puis de cliquer dans l’espace de travail là où l’on souhaite l’utiliser. Mais en fait c’est assez logique car ce ne sont pas des outils mais d’objets ;
  • la création des interactions est dans certains cas un peu laborieuse ;
  • le paramétrage des différentes propriétés d’un objet est simple pour quelqu’un habitué à l’HTML/CSS, un certain nombre d’éléments rappelant les CSS ;
  • réaliser un prototype complet prend beaucoup de temps.

 

Pour conclure, Axure est tout à fait adapté à la création de Wireframes et de prototypes pour faire des démonstrations clients et présenter des solutions concrètes. Pour la partie Documentations et spécifications, je n’ai pas eu l’occasion de vraiment exploiter ces outils et donc je manque de recul pour pouvoir la juger.

Il faut garder en tête que la création d’un prototype demande un certain investissement en termes de temps mais qu’il est possible d’avoir des versions simplifiées (arborescence, zoning d’écrans, Wireframe).

Pour un petit projet, il est préférable pour des questions de temps de se limiter à des présentations simples (en créant un simple zoning sous Axure ou autre) , en les expliquant au client directement cela sera tout aussi efficace qu’un prototype avancé qui je pense est destiné aux projets les plus ambitieux avec de forts enjeux ergonomiques pour l’acceptation par les utilisateurs. Il faut donc dimensionner l’usage du logiciel de prototypage au projet que l’on va réaliser.

 

 

Pour aller plus loin

https://www.youtube.com/watch?v=J2BDVM6Qw5s

https://www.youtube.com/watch?v=1O8xFHQ4lHk

 

Initiation à Gatling, un outil de tests de charges

0

Gatling-logo

Après avoir développé, testé fonctionnellement une application, une autre étape importante consiste à tester l’application dans des conditions plus proches de la production. Pour cela, une étape de tests de charge semble indispensable. En effet, une application est souvent testée unitairement par un développeur, profil après profil, fonctionnalité après fonctionnalité.

Nous allons nous intéresser ici à un outil permettant de réaliser ces tests de charge, à savoir Gatling. Gatling est un outil basé sur le langage Scala, Netty et Akka. Grâce à Netty, les requêtes sont lancées de manière asynchrone, ce qui permet d’utiliser un grand nombre d’utilisateurs virtuels. Les scénarios générés sont écrits en langage Scala. Ce langage est proche de Java mais est plus simple à appréhender. Quant à Akka, c’est un Framework qui implémente le modèle d’acteurs.

Gatling s’installe facilement grâce à un fichier zip. Étant basé sur Akka, il a néanmoins besoin de la présence du JDK pour fonctionner. Il suffit ensuite de paramétrer manuellement son navigateur pour qu’il passe par le port 8000.

Création du scénario

Les scénarios peuvent être écrits entièrement à la main, ou nous pouvons utiliser le « recorder ». Celui-ci permet d’enregistrer un scénario simplement en navigant dans l’application, à la façon d’un internaute. Le scénario généré peut ensuite être modifié à l’envi à l’aide du langage Scala.

Nous allons ici tester Gatling dans sa version la plus simple. Prenons par exemple une application de réservation de billets de train :
– Ouvrir l’URL du site
– Rechercher un billet aller-retour Paris-Marseille pour une personne avec une carte jeune de réduction
– Accéder à l’ensemble des tickets disponibles
– Choisir le trajet aller et valider
– Choisir le trajet retour et valider
– Renseigner les données pour le mail récapitulatif
– Accéder à la page de paiement

L’entête du fichier est généré automatiquement, suivant les informations renseignées dans la fenêtre de Gatling. Par défaut, le nom de la classe est « RecordedSimulation ». Le nom du package doit commencer par une lettre est doit être en minuscule.

Le fichier résultant va être créé dans le répertoire paramétré dans « Output folder » et, dans notre exemple, va porter le nom « RecordedSimulation.scala ».

 

1

 

Dans l’entête du fichier généré se retrouve le nom du package et du nom de la classe. De plus, la variable baseURL indique l’adresse principale du site testé. Les fichiers générés peuvent être modifiés grâce à un éditeur de texte type Notepad++. Ils peuvent également être ouverts dans Eclipse, si celui-ci est présent sur le poste.

 

2

 

Lorsque l’on navigue sur une page web ou que l’on saisit des informations dans un formulaire, toutes les URLs sont enregistrées par Gatling. Un extrait des actions exécutées lors de la saisie des villes de départ et de destination est présenté, ici un Paris-Marseille aller-retour. Plusieurs fonctions similaires sont générées car la fonction d’autocomplétion est enregistrée.

 

3

 

Ce type d’enregistrement génère un grand nombre de requêtes. Nous pouvons modifier leur nom, afin de les rendre plus parlantes. Cela permettra de les retrouver plus facilement dans les graphiques de résultats. Nous allons détailler la saisie des informations après validation des billets aller et retour et avant la page de paiement. Le site demande la date de naissance du voyageur, ses nom et prénom ainsi que son adresse email.

Le nom de la requête a été ainsi modifié :

 

4

 

Ce morceau de scénario peut être écrit comme une fonction. Ceci permet de factoriser le code et de potentiellement le réutiliser par la suite.

 

5

 

La génération des scénarios est donc facilitée par l’utilisation des fonctions. Un scénario se compose d’une succession de fonctions. Une même fonction pouvant être appelée par plusieurs scénarios, il est donc possible de lancer plusieurs fois les mêmes actions, par exemple pour des profils différents.

 

6

 

Pour l’instant, le scénario est exécuté par une seule personne avec des informations de date de naissance, de nom, de prénom et d’adresse email fixes. Nous pouvons pousser le paramétrage de la fonction de saisie d’information avec un fichier. Dans notre exemple, nous pouvons mettre en facteur le jour, le mois et l’année de naissance, les nom et prénom ainsi que l’adresse email.
Le fichier nécessaire à ce paramétrage doit être un fichier au format CSV. Le nom des colonnes doit reprendre le nom des variables qui sera utilisé par la suite dans le scénario. Un exemple de fichier est présenté ci-dessous. Notre fichier se nomme param.csv.

 

7

 

Le nom du fichier paramétré doit être inséré dans la fonction où il est appelé, avant l’appel des variables. Les variables ainsi définies sont appelées grâce à l’écriture ${nomvariable}, ce qui donne un fichier plus générique.

 

8

 

Paramétrage du test de charge

Pour l’instant, un seul utilisateur se connecte à l’application. Pour faire des tests de charge probants et simuler les vraies conditions de navigation, le nombre d’utilisateurs peut être augmenté. Par exemple, 6 utilisateurs peuvent se connecter à l’application toutes les 15 secondes grâce aux fonctions inject et rampUsers.

9

Si nous voulons plutôt tester des utilisateurs simultanés, il faut utiliser la fonction atOnceUsers avec le nombre d’utilisateurs en paramètre. Par défaut, le scénario est enregistré avec un seul utilisateur.

10

 

Affichage des résultats

Les résultats sont ensuite disponibles, après leur génération dans un répertoire /results. Un nouveau dossier est généré, portant le nom de package, suivi d’un tiret et de plusieurs chiffres. Les résultats sont fournis au format HTML et la page racine, index.html, permet d’accéder à l’ensemble de ces derniers.

Un premier graphique en bâtons fournit une vue du temps de réponse des requêtes. Les requêtes sont partagées en différentes catégories suivant leur temps de réponse. Dans notre cas avec un utilisateur, nous pouvons voir que plus de 400 requêtes répondent en moins de 800 ms, mais qu’un certain nombre sont en erreur, dans la colonne ‘failed’.

 

11

 

Dans ce deuxième graphe en bâtons, où 10 utilisateurs sont envoyés en simultané, il est possible de voir que le résultat est plus nuancé. On peut noter que l’écrasante majorité des requêtes répondent en moins de 800 ms à quelques exceptions près. On retrouve également des requêtes en erreur.

 

12

 

La page index.html contient également un tableau récapitulatif de toutes les requêtes. Pour chaque ligne, on peut voir le nombre de requêtes total, le nombre de requêtes OK, le nombre de requêtes KO ainsi que les temps de réponses.

 

13

 

En cliquant sur le nom d’une requête, une nouvelle page s’ouvre, pour afficher les résultats de la requête spécifiquement. Par exemple, si on ouvre la request_41, il est possible de voir que 7 requêtes ont abouti en moins de 800 ms et 3 n’ont pas abouti.

 

14

 

D’autres types de graphiques sont également disponibles. Par exemple, nous pouvons voir le nombre de requêtes par utilisateur ou le nombre de réponses par utilisateur.

Ces analyses permettent de voir quelles requêtes sont les plus problématiques, et de corriger le tir rapidement.

 

Synthèse

Gatling dispose de nombreux points forts :

  • Cet outil est gratuit et simple à installer. Il ne requiert aucun logiciel supplémentaire hormis un JDK à jour.
  • La facilité d’utilisation du recorder : avec un simple navigateur et un minimum de paramétrage, il est possible d’instancier de nombreux scénarios, des plus simples au plus complexes.
  • L’existence d’un plug-in pour Eclipse : pour les développeurs Java, il devient simple de lancer le recorder, ou par la suite de lancer les tests de charge.
  • La possibilité de créer des scénarios ou de les modifier grâce au langage Scala. Le langage Scala est suffisamment simple et « parlant » pour pouvoir être utilisé facilement.
  • La clarté du site : La documentation sur le site est assez complète pour faire des scénarios simples, puis pour les complexifier par la suite.
  • La détection des problèmes de compilation : lorsque nous essayons de lancer les tests de charges, l’outil pointe les erreurs de compilation dans la console.
  • La clarté des graphiques générés : nous pouvons faire aisément des analyses globales ou des analyses plus détaillées, requête par requête.

 

Gatling a aussi ses points faibles :

  • La génération différée des rapports : les rapports sont générés après l’exécution de la totalité des tests de charge.
  • L’interface qui permet de lancer les tests de charge, dans sa version native, n’est pas graphique.

 

En conclusion, Gatling gagne à être connu et utilisé dans le cycle de vie d’un projet. Avec un minimum de connaissance en langage informatique, des scénarios complexes peuvent être élaborés. Cela permet de pointer du doigt les portions d’application à modifier ou à optimiser. Je l’ai testé dans sa version la plus basique. Malgré un manque d’ergonomie dans l’outil de tests de charges en lui-même, les fichiers générés se retrouvent facilement et le paramétrage est aisé.