Perfectionner vos cas d’utilisation

Suite à précédent article (What’s the Problem?), le magazine A List Apart vient de publier un autre article traitant des cas d’utilisation : Use-Cases Part II: Taming Scope.

Exemple de cas d'utilisation

Au programme de ce nouvel article : les cas d’extension (extend en anglais) et les cas d’inclusion (include toujours en anglais). Espérons que s’il doit y avoir un troisième article sur le sujet l’auteur ne nous entraîne pas trop loin dans la complexité du langage UML (dont ce principe de modélisation est issue).

A la découverte des cas d’utilisation

Le site A List Apart nous propose cette semaine un article de vulgarisation sur les cas d’utilisation : What’s the Problem?. Surprenant pour un site à la ligne éditoriale plutôt tournée vers les aspects techniques. En tout cas, les explications sont simples et les diagrammes très sympa :

Les cas d'utilisation selon A List Appart

Puisqu’on est dans le sujet, laissez moi vous donner mon point de vue :

  • Les cas d’utilisations (ou scénarios d’utilisations) servent à modéliser les interactions possibles entre un utilisateur et une application ;
  • Ils sont particulièrement utiles pour mettre à plat un processus et anticiper toutes les configurations possibles ;
  • Les cas d’utilisations sont regroupés au sein de packages qui couvrent l’ensemble des fonctionnalités d’un site ou d’une application en ligne ;
  • Les acteurs doivent être clairement définis (rôle, responsabilités…) en amont de la rédaction de cas d’utilisation ;
  • La notion de cas d’utilisation a été introduite dans le cadre d’UML et de la méthodologie RUP. Il servent à documenter les spécifications fonctionnelles d’un projet.

Dans mon travail, j’utilise mon propre système de représentation graphique des cas d’utilisation qui va un peu plus loin que celui de l’article d’A List Appart :

Les cas d'utilisation selon Canardo

Ce système de représentation a été baptisé Canardo (en hommage à son concepteur) et vous pouvez le trouver sur le fichier suivant : Gabarit de cas d’utilisation (format PPT). Pour info, vous pourrez trouver d’autres ressources de ce type dans la page ‘Publications‘ de ce site.

MAJ (25/01/05) : C’est au tour de Macromedia de nous pondre un article sur la modélisation des processus : Modeling User Workflows for RIAs. L’article est très didactique et les exemples de très bonne qualité :

Modélisation de processus selon Macromedia

Ils en profitent pour faire un peu de promotion pour leurs outils mais bon, il faut bien vivre, non ?

Quels boutons pour un formulaire / assistant : La réponse

Après un précédent billet posté pour m’aider à me décider sur la meilleure façon de mettre en forme les boutons d’un formulaire contenant plusieurs étapes, je vous livre les résultats de ce mini-sondage : une large majorité ont voté pour la solution B (avec deux flèche « < Précédent » et « Suivant >« ). Effectivement, c’est celle qui présente la solution la plus claire et qui laisse le plus de contrôle aux utilisateurs.

Et pourtant, ce n’est pas la solution que je vais retenir. Mon choix va plus s’orienter sur une nouvelle version de la solution A :

Bouton-formulaire

 

Plusieurs explications à cela :

  • Nous sommes dans le cas d’un formulaire guidé et non d’un assistant (pour plus d’explications entre ces 2 notions, voir le très bon article à ce sujet de Bob Baxley : Wizards and Guides, Principles of Task Flow for Web Applications) ;
  • L’objectif premier est de faire progresser les utilisateurs dans les étapes tout en minimisant le nombre d’aller / retour avec le serveur ;
  • Les étapes seront clairement affichées en haut du formulaire ;
  • A chacune des étapes, un contrôle de surface est effectué et les données sont enregistrées ;
  • Une dernière étape de récapitulation demandera aux utilisateurs de vérifier et valider leurs données, sinon de revenir en arrière et de corriger certaines étapes ;
  • Le bouton « Annuler » a été remplacé par 2 liens exprimés sous forme de questions qui permettent d’abandonner le formulaire ou de sauvegarder les données ;

Pour toutes ces raisons, je pense que cette nouvelle solution A est la plus appropriée car elle sera moins source d’erreurs et de fausses manipulations. Attention, cela ne veut absolument pas dire que la solution B n’est pas pertinente, au contraire ! C’est juste qu’elle n’est pas la plus adaptée à ce contexte précis.

Merci encore à tout ceux qui ont pris le temps de donner leur avis, cela m’a permis de pouvoir trancher et d’opter pour une solution qui présente le meilleur compromis incitation / utilisabilité (au passage, je m’étais plus orienté vers la solution D). Au vue de la qualité des commentaires, je pense que je vais vous solliciter plus souvent !

MAJ (18/01/05) : Visiblement je ne suis pas le seul à me poser des questions : Web Application Form Layout.

Quels boutons pour un formulaire / assistant ?

Je travaille en ce moment sur un projet de guide ergonomique dans lequel des recommandations doivent êtres faites quand à la présentation et mise en page des formulaires en ligne. Etant dans l’incapacité de me décider pour une solution ou une autre, je me permet de vous solliciter sur un problème bien précis :

Nous sommes dans le cas de figure où les utilisateurs doivent remplir un formulaire en ligne découpé en plusieurs étapes, une sorte d’assistant (wizard comme disent les anglo-saxons). A votre avis, laquelle de ces 4 propositions vous semble la plus claire, intuitive et posant le moins de problèmes d’interprétations :

Solution A :

Assistant-A

Solution B :

Assistant-B

Solution C :

Assistant-C

Solution D :

Assistant-D

Alors ? Votre avis ?

Les 5 lois de la conception d’interface

Ce soir, grâce à Gou, je vous propose de faire connaissance avec les 5 lois de la conception d’interface :

  1. L’utilisateur n’utilise pas votre application: il accomplit une tâche ;
  2. Plus un objet est grand et près du curseur, plus il est facile à cliquer ;
  3. Eviter de détourner l’attention de l’utilisateur de sa tâche primaire ;
  4. Utiliser la puissance de l’ordinateur pour éviter des efforts mentaux à l’utilisateur quand l’ordinateur peut (ou devrait) faire une part de travail ;
  5. Faire les choses faciles à distinguer et à mémoriser.

Comme le fait très justement remarquer l’auteur, on est pas loin des trois lois de la robotique d’Asimov. Tiens d’ailleurs, j’ai bien envie de faire un test de Turing pour vérifier qu’il n’y a pas que des automates type Googlebot ou Gigablast qui lisent ce blog : êtes-vous humains ?