Notifications

Le comité de gestion du catalogue envoie un courrier électronique au contributeur 1) à ré- ception de la suggestion, 2) dès qu’elle est portée à l’étude, 3) dès qu’elle est rejetée ou accep- tée, 4) quand elle est éventuellement publiée. La procédure est la même si l’analyste souhaite suggérer l’ajout d’un nouveau patron ou la modification d’un patron existant.

En cas d’ajout ou de modification effective d’un patron, la rubrique « Actualités » de la page d’accueil du catalogue est mise à jour (cf. Figure 38). Les modifications sont classées par ordre anti-chronologique ; les ajouts et les modifications majeures sont mis en exergue. Tous les mois, un email est envoyé à l’ensemble des utilisateurs connus du catalogue pour leur résumer les mises à jour effectuées.

Figure 38. Section actualités de la page d'accueil du catalogue de patrons (capture d'écran réalisée le 2 juin 2008)

4.4.

S

’

La méthode de conception pour l’e-Gouvernement que nous proposons est illustrée dans cette section, sur une étude de cas fictive. La mairie de Goville souhaite concevoir le site Web de la cantine de l’école communale. Pour ce faire, elle fait appel à une entreprise de technolo- gies de l’information qui utilise notre méthodologie. Les besoins exprimés sont succincts, et c’est sur leur base que l’analyste doit produire une première proposition d’interface :

• Accès sécurisé pour les parents qui souhaitent consulter les repas auxquels sont ins- crits leurs enfants, ajouter ou supprimer des repas ;

• L’identifiant et le mot de passe leur sont remis en mains propres, à l’école ;

• On peut ajouter ou supprimer un repas jusque trois jours avant la date du repas ; À partir de cette étude de cas, cette section montre comment notre méthode satisfait les trois critères évoqués à la fin de notre état de l’art des méthodes de conception d’interfaces cen- trées utilisateur :

• Soutenir la conception :

− Support à la conception de wireframes de pages, à partir du catalogue de pa- trons ;

− Support à la définition de la navigation par un modèle StateWebCharts, à partir du catalogue de patrons et de l’outil eGovIPM (cf. chapitre 6) ;

• Favoriser la communication : génération d’un squelette de l’application qui puisse être discuté avec le client, sur la base des wireframes de page et de l’enchaînement d’écrans, et grâce à l’outil eGovIPM ;

• Capitaliser la connaissance : lorsque l’analyse révèle des éléments n’apparaissant pas dans le catalogue, le concepteur suggère un ajout de patron.

89

4.4.1. Soutenir la conception

Sur la base des besoins exprimés par le demandeur, l’analyste réalise les artefacts de conception décrits dans cette section. Pour ce faire, il utilise eGovIPM (le détail de cette réalisa- tion sera fourni dans le chapitre 6 consacré à l’outil), les patrons figurant dans le catalogue de patrons et un outil éditeur de dessin annexe, de type Visio. L’étude de cas n’est que partielle- ment traitée et nous ne présentons ici que la page concernant la gestion des repas des enfants.

Définition d’un wireframe de page

Pour concevoir son wireframe de page, l’utilisateur navigue sur le catalogue de patrons. Aucun patron de page ne correspond à son cas précis : définir une page permettant la gestion des repas d’un ou plusieurs enfants. Mais cette page a un axe central très fort : la manière dont les repas doivent être présentés. L’analyste cherche d’abord un patron traitant de « dates » : il saisit ce mot-clef dans le moteur de recherche interne du catalogue. La Figure 39 montre le ré- sultat de cette recherche, qui retourne notamment le patron « Calendrier » qui contient le mot « date ».

Figure 39. Résultat de la recherche du mot clé « date » sur le catalogue de patrons (capture d'écran réalisée le 22 mai 2008)

C’est le patron de composant de base « Calendrier1 » qui sert de base à la conception de cette page. Comme suggéré par le prototype de ce patron (cf. Figure 40), un enfant inscrit à un repas est représenté par une couleur. Les dates du calendrier ne sont pas cliquables, compte tenu de la complexité des données à gérer : sur une seule date, on peut en effet ajouter ou supprimer un repas pour chacun des enfants. Il est donc proposé à l’utilisateur de cliquer sur un des liens « Modifier » pour modifier les inscriptions aux repas d’un ou plusieurs de ses enfants. Cette pop up (non présentée ici) propose l’ajout ou la suppression de dates, les dates étant grisées, rendues inactives jusque trois jours ouvrables après la date du jour. En parallèle, l’analyste consulte les patrons d’enchaînements d’écrans : pour ce cas d’étude dont la procédure est simple, il s’agira

90

d’un « Tableau de bord » avec le calendrier général de la Figure 40 comme nœud central, de- puis lequel seront accessibles une tâche « Modifier » par enfant, plus une pour l’ensemble des enfants.

Une fois le cœur de la page élaboré, l’analyste l’enrobe avec un cadre générique pour la page, inspiré par le patron de composant de base « En tête et Pied de page1 », dont le prototype est reproduit sur la Figure 41.

Figure 40. Prototype du patron de composant de base « Calendrier »

Figure 41. Prototype du patron de composant de base « En-tête et pied de page »

91 Figure 42. Wireframe de la page « Repas des enfants »

Définition de la navigation

Nous reviendrons en détail sur les étapes de réalisation du modèle de navigation de la Figure 43 dans le chapitre 6 dédié à l’outil eGovIPM. Le patron de base est le canevas « Ta-

bleau de bord » d’eGovIPM, comme il avait été repéré lors de la conception des wireframes de

pages. Suite au login de l’utilisateur, le parent d’élève dispose d’un tableau de bord. Cette page (cf. Figure 42) comprend un calendrier des repas auxquels les enfants sont inscrits et des liens permettant de modifier les repas de chaque enfant, ou de tous les enfants en une seule fois. De- puis toute page de l’application, un lien est fourni vers le site de l’école de Goville.

Figure 43. Modèle de navigation SWC du site Web de la cantine de Goville  Précédent Suivant  M o i s d ’ av ri l 20 0 8 L M M J V S D 31 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 1 2 3 4 Légende 5 Pas de cantine 5 Aucun enfant inscrit

5 Jules est inscrit 5 Théo est inscrit

École de Goville Mon identifiant : PICART Me déconnecter

C a n t i n e d e l ’ é c o l e d e G o vi l l e G é r e r l e s r e p a s d e m e s e n f a n t s



 Modifier

92

4.4.2. Favoriser la communication

Pour sa rencontre avec le client, l’analyste a généré avec eGovIPM (cf. chapitre 6) les pa- ges XHTML de l’application à partir du modèle de navigation SWC de la Figure 43 et des ima- ges de ses wireframes de page personnalisés. Il parcourt le modèle de navigation par le biais d’un navigateur Web, profitant de chaque nouvelle page pour en expliquer les fonctionnalités.

La Figure 44 ci-après montre la page d’identification générée automatiquement depuis le modèle StateWebCharts. L’analyste n’a pas jugé bon, dans un premier temps, de personnaliser le wireframe de cette page : c’est donc le wireframe générique du catalogue de patrons1 qui apparaît. La Figure 45 a été générée automatiquement également, mais l’analyste a spécifié sur le modèle StateWebCharts de la navigation qu’un wireframe personnalisé était disponible : il apparaît alors.

Figure 44. Page XHTML du squelette de l’application généré par eGovIPM : Identification

Figure 45. Page XHTML du squelette de l’application généré par eGovIPM : Gestion des repas

93 Le client est satisfait des modes d’interaction choisis et des informations dispensées. Ce- pendant, à la vue de cette proposition, une idée émerge : celle d’ajouter une fonctionnalité per- mettant à un parent de payer la cantine pour le trimestre passé, par carte de crédit. Il demande à l’analyste si un tel ajout est possible en peu de temps, afin de ne pas prendre trop de retard dans le projet. L’analyste accepte et entame la deuxième définition de l’interface, pour y ajouter ce module de paiement par carte de crédit.

4.4.3. Capitaliser la connaissance

Le client du site Web de la cantine a demandé l’ajout d’un module de paiement par carte bleue sur le site. L’analyste a fourni un effort considérable pour produire un wireframe de page satisfaisant pour cette page, qui ne figurait pas dans le catalogue. Afin que cet effort soit forma- lisé par le comité de gestion du catalogue de patron, et éventuellement intégré à celui-ci, il ren- seigne les informations suivantes par le biais du questionnaire. Puis, par manque de temps, il ne rend pas générique le wireframe tel qu’il l’a conçu pour le projet de la cantine (cf. Figure 47), et l’envoie tel quel, par courrier électronique à l’adresse indiquée sur le catalogue.

Titre du patron

Paiement par carte de crédit.

Description

Un particulier souhaite régler un montant via l’application, au moyen de sa carte de crédit.

Exemples

Site d’e-Commerce Etamhttp://www.etam.fr (dernier accès : 25 sept. 08)

Figure 46. Bon exemple pour la suggestion de patron « Paiement par carte de crédit »

Cas d'utilisation

Il faut utiliser ce patron dès qu’un particulier souhaite payer par carte de crédit.

Il ne faut pas utiliser ce patron lorsqu’une entreprise doit payer ; préférer alors le rem- plissage de bons de commandes.

94

Mise en page

Utiliser les logos officiels des différentes cartes de crédit. Afficher clairement le logo de la banque de l’application. Rappeler en tête de page le montant à payer.

Autoriser l’annulation du paiement avant qu’il n’ait été validé.

Ressources

–

Prototype

Figure 47. Wireframe de la page « Paiement du trimestre passé »

4.5.

D

Nous avons proposé dans ce chapitre une méthode de conception basée sur des patrons d’interfaces pour l’e-Gouvernement. Le support permettant le recueil des patrons a été formalisé par le biais d’un catalogue hypertexte, et une procédure de mise à jour de ce support est suggé- rée. L’évolutivité d’un catalogue de patrons étant l’un des signes de sa vitalité et de son utilité, les utilisateurs doivent en effet être encouragés à soumettre des ajouts de patrons. Notre mé- thode entre dans le cadre d’un processus de conception basé sur des prototypes moyenne fidéli- té, incluant des prototypes moyenne fidélité sous forme de modèles de navigation et de wire-

frames. Des pistes d’amélioration de cette méthode restent à explorer, en particulier au niveau

de la navigation au sein du catalogue, vers une offre de recherche de solution optimale pour le concepteur.