Audit ergonomique « Back-office Dotclear »

Présentation au sujet: "Audit ergonomique « Back-office Dotclear »"— Transcription de la présentation:

1 Audit ergonomique « Back-office Dotclear »
Gautier Barrère

2 Utilisation du document
Cet audit est basé sur les critères ergonomiques de Scapin & Bastien. Chacun des problèmes ergonomiques identifiés est justifié au regard de ces critères Pour chaque critère, des commentaires, justifications et exemples de recommandation sont proposés au lecteur Il est important de notifier que tous les critères listés ci-après sont interdépendants et que la plupart du temps, un choix de conception renvoie à plusieurs critères d’ergonomie Il est tout aussi important de préciser que la prise en compte des grands principes d’ergonomie est une étape nécessaire mais non suffisante pour garantir la conception de produit ergonomique. Cette tâche de fond doit impérativement être couplée à une approche de conception centrée sur l’utilisateur

3 Plan de l’audit 1. Concepts globaux « Blog »
2. Mode logué – Informations de « haut niveau » 2.1 Niveau de contraste 2.2 Police 2.3 Système de navigation – Architecture – Labelling 2.4 Système d’onglet 2.5 Navigation complémentaire 2.6 Rubriques de support 2.7 Sauvegarde automatique des données ? 2.8 Fonctionnalités / Options génériques 2.9 Formulaire 2.10 Editeur HTML 2.11 Pages « Liste » 3. Mode logué – Scénarii clé 3.1 Page d’authentification – Login / Delogin 3.2 Tableau de bord » 3.3 Rubrique « Nouveau billet » 3.4 Rubrique « Billets » 3.5 Rubrique « Commentaires » 3.6 Rubrique « Catégories » 3.7 Rubrique « Gestionnaire de média » 3.8 Rubrique « Pages » 3.9 Rubrique « Tags » 3.10 Rubrique « Extension > Liens » 4. Synthèse des principaux résultats 5. Prochaines étapes

4 1. Concepts globaux « Blog »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Concernant les notions : « Page », « Billet », « Commentaire », « Catégories » : Est-ce parlant pour un utilisateur lembda ? Quelles est la différence entre une page, un billet, un commentaire ? Définir les notions de page, billet, commentaire Proposer des éléments qui permettent de comprendre les concepts (un commentaire est associé à un billet, les billets sont associés à des catégories, les pages sont indépendantes, etc…) Signifiance des codes et dénominations

5 2. Mode logué - Info « haut niveau »
Niveau de contraste Police Système de navigation – Architecture – Labelling Système d’onglets Rubriques de support Sauvegarde automatique des données Fonctionnalités / Options génériques Formulaires Editeur HTML Pages « Liste »

6 2.1 Niveau de contraste Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Les informations en bas à droite des pages « Merci d’utiliser » ne sont pas assez contrastées Définir un rapport « Background / Foreground » assez contrasté Lisibilité Certains messages d’erreur ne sont pas assez contrastés : « Veuillez prendre garde à ne publier que des médias que vous possédez ou qui ne sont pas protégés contre la copie ».

7 2.2 Police Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Sur tout le back-office, la taille des caractères semblent un peu petite Cela concerne également la taille des libellés de bouton d’action, la taille des labels de champs de formulaires, de recherche … Voir dans quelle mesure on pourrait augmenter la police Lisibilité

8 2.3 Système de navigation – Architecture – Labelling
Rubrique « Tableau de bord » Recherche Breadcrumb Informations en haut à droite Effet de roll-over Effet de rubrique active Aide globale Rubriques « Aide globale » vs « Aide contextuelle » « Liens de contenu » vs « Liens de navigation » Liens externes Menu de gauche Utilisation du « Back » du navigateur

9 Rubrique « Tableau de bord »
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) « Tableau de bord » pas assez mis en valeur « Tableau de bord » occupe une place particulière dans la navigation de gauche. Il joue le rôle de « Accueil » et devrait de ce fait être un peu plus démarqué et mis en valeur Démarquer : - par le format : en définissant un design graphique différent - par la localisation : mettre un espace entre le « Tableau de bord » et le premier élément du menu de gauche Groupement / Distinction entre items

10 Recherche Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Placement de la recherche pas optimal La recherche est cachée dans une navigation Il semble important de la proposer sur toutes les pages Généralement, la recherche n’est pas positionnée dans un menu de gauche Placer la recherche en haut à droite, visible sur toutes les pages, avec une option de recherche avancée. Groupement / Distinction entre items Compatibilité (aux standards existants) Prise en compte de l’expérience utilisateur (les experts auront tendance à plus utiliser le moteur de recherche)

11 Breadcrumb Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Ce qui ressemble à un breadcrumb n’en est pas un Il est utilisé pour deux choses distinctes : - l’identification de la page (le titre) la localisation de l’utilisateur dans le back-office Cela rend les choses confuses Concernant le gabarit standard d’une page, il semble important de : - mettre un breadcrumb pour préciser l’emplacement de l’utilisateur dans le back-office mettre un titre distinct de niveau 1 Il semble préférable de conserver le breadcrumb uniquement pour indiquer à l’utilisateur son emplacement dans le système Guidage Comptabilité (aux habitudes des internautes)

12 Informations en haut à droite
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Les données regroupées en haut à droite semblent ne pas être toutes de même nature. Il est préférable d’organiser le système de navigation en regroupant ensemble les informations de même nature et en les séparant des informations d’autre nature. « Blog : mon premier blog » correspond au titre du blog. Il semble préférable de le placer de manière indépendante dans le banner (plus à gauche de sa position actuelle) Les informations « Utilisateur : rédacteur » et « Déconnexion » semblent liées. Il faudrait donc le communiquer au niveau du design graphique. « Voir le site » : Améliorer son placement et définir un design graphique qui ressemble plus à un « bouton d’action » Groupement / Distinction entre les items Guidage

13 Effet de roll-over Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Il n’y a pas d’effet de roll-over pour chaque « type » de zone cliquable Afin d’optimiser la navigation de l’utilisateur dans le système il est préférable de clairement mettre en avant les zones cliquables. L’effet de roll-over participe en partie à cela Proposer pour chaque « type » de zone cliquable un effet de roll-over adapté. A première vue, on distingue 3 types de zone cliquable : - les liens de type « Rubrique de navigation » dans le menu de gauche - les liens de type « Rubrique de support » (p.ex. l’aide) - les liens de type « Contenu dans le body »  Incitation

14 Effet de rubrique active
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Pour les liens de type « Rubrique de navigation », il n’y a pas d’effet de rubrique active. L’effet de rubrique active permet de clairement mettre en évidence dans quelle rubrique l’utilisateur se trouve. Proposer pour chaque lien de type « Rubrique de navigation » du menu de gauche un effet de rubrique active. Pour cet effet de rubrique active, il est préférable d’utiliser le même design graphique que celui employé pour l’effet de roll-over Guidage Feedback

15 Aide globale Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Aide globale manquante Même si l’aide n’en est pas une …  Une aide globale semble être un élément central indispensable. Proposer une aide globale dans le système de navigation sur toutes les pages Gestion des erreurs

16 Rubriques « Aide générale » vs « Aide contextuelle »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Actuellement, le back-office propose une aide contextuelle. Il semble préférable de proposer une aide générale et une aide contextuelle, et de les distinguer visuellement parlant. Gestion des erreurs Groupement / Distinction entre items

17 « Liens de contenu » vs « Liens de navigation »
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Le design graphique des liens de type « Contenu dans le body » et liens de type « Rubrique de navigation » est identique. A des fins de navigation, il est préférable de distinguer clairement ces deux types de liens P.ex. conserver le bleu pour les liens dans le body, et choisir une approche plus « Bouton de navigation » pour les liens de type « Rubrique de navigation ». Guidage

18 Liens externes Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Ouverture du lien « Dotclear » en bas à droite dans une fenêtre courante. Ce comportement pose divers problèmes : - l’utilisateur n’est pas averti qu’il est renvoyé vers un autre site, - quand il clique, il perd le contexte. Dans ce cas de figure il semble préférable : - d’indiquer qu’il s’agit d’un lien vers un site externe (p.ex. via un icône adapté) de faire ouvrir ce lien dans une nouvelle fenêtre D’autant plus qu’il s’agit d’un back-office : l’utilisateur est « dans une procédure » Incitation

19 Menu de gauche – Homogénéité
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Homogénéité du menu de gauche Dans ce menu de gauche, on mélange différentes types d’informations : - des pages purement informationnelles, (rubrique « Pages) - des fonctionnalités (« Recherche »), - des actions (« Nouveau billet »). Essayer de définir un menu de gauche cohérent Enlever la recherche de ce menu et la positionner en haut à droite, sur toutes les pages Regrouper visuellement « Billets », « Commentaires », « Catégories », « Pages », qui semblent être des informations qui se rejoignent. Regrouper « Gestionnaire de média » et « Liens » Groupement / Distinction entre items Compatibilité (aux standards)

20 Menu de gauche – Granularité
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Niveau de granularité du menu de gauche Pourquoi mettre ici « Nouveau billet » et pas « Nouveau commentaire » ? Pourquoi mettre « Commentaires » et pas « Rétroliens » ? La navigation principale (ici le menu de gauche) n’est pas là pour proposer des shortcuts vers les fonctionnalités importantes mais pour refléter la structure (arborescence) du back-office Essayer de définir un menu de gauche ayant un même niveau de granularité, pour lui donner une cohérence Positionner « Nouveau billet » à un autre endroit, p.ex. dans une toolbox visible sur toutes les pages. Cette toolbox pourrait reprendre un ensemble de choses (comme « Voir le site ») Groupement / Distinction entre items Comptabilité (aux standards)

21 Menu de gauche – Surface cliquable
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Les zones cliquables dans le menu de gauche sont très petites Plus les zones cliquables sont petites, moins elles sont accessibles Agrandir les zones cliquables de chaque élément de navigation pour améliorer leur cliquabilité Incitation

22 Menu de gauche – Icônes Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Icônes associés aux rubriques du menu de gauche posent différents problèmes Apportent peu de plus value dans ce cas particulier (cela laisse même présupposer que les labels auxquels ils sont associés ne sont pas assez parlants … en général on emploi cela pour mettre en valeur un type de document, p.ex. dans des pages de type « Liste ») Peu signifiants et trop petits Surchargent inutilement la page Il est préférable de conserver les icônes quand ils sont indispensables à la compréhension d’un élément Envisager d’enlever les icônes Comptabilité (aux besoins, aux objectifs, à la tâche des utilisateurs) Signifiances des codes et dénominations Charge de travail (densité informationnelle)

23 Menu de gauche – Affordance
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Elément de type « Blog » : mauvaise affordance, mauvaise cliquabilité Améliorer la cliquabilité de ces éléments Incitation

24 Utilisation du « Back » du navigateur
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Dans certains cas de figure, le « Back » du navigateur ne permet pas de revenir à la page précédente P.ex. dans la rubrique « Commentaires » quand on met une adresse invalide, un message d’erreur s’affiche mais on perd la page. Le « Back » du navigateur ne permet pas de retrouver la page précédente. Autre exemple : je crée un billet (je suis donc sur la vue « Onglets »), je fais « Voir le billet », je fais back, je ne retrouve plus la page précédente Toujours permettre à l’utilisateur de revenir en arrière en utilisant le bouton « Back » Contrôle utilisateur

25 2.4 Système d’onglets Les recommandations qui suivent concernent toutes les pages disposant du système d’onglets

26 Système d’onglets - Granularité
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) On met au même niveau des informations qui ne sont pas de même niveau (p.ex. « Ajouter un commentaire » semble être une page « Chidren » de « Commentaire ») Les onglets « Commentaires », « Rétroliens », « Ajouter des commentaires » semblent très liés. En effet, l’onglet « Commentaires » regroupent les rétroliens et les commentaires. Il semble préférable de réaménager ce système. Guidage

27 Onglet « Faire des rétroliens »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Apparence de l’onglet. Pourquoi cet onglet a un background blanc par défaut ? Il semble préférable d’utiliser le même aspect graphique que pour les autres onglets, sauf si cela est justifié Homogénéité Quand on clique sur cet onglet on perd les autres onglets Il est préférable de laisser le système de navigation sur toutes les pages concernées

28 Onglet « Faire des rétroliens »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Quand on clique « Faire des rétroliens » sans rien indiquer, rien ne se passe Mettre en place un message d’erreur Gestion des erreurs « Découverte automatique des URLs à rétrolier » : labelling + apparence (il semble s’agir d’un bouton d’action et non d’un lien) Améliorer le labelling et associer un design graphique de type « Bouton d’action » à cet élément Signifiance des codes et dénominations Titre de page, titre de fieldset, titre du bouton d’action identique Il semble préférable de ne pas utiliser le même intitulé pour des informations de nature différentes Guidage

29 Onglet « Faire des rétroliens »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Dans la zone de saisie, la police est différente des endroits endroits du back-office Utiliser une police homogène sur tout le back-office Homogénéité L’espace « Billet » n’est pas communiqué en tant que tel : on dirait plutôt « un élément à remplir  Améliorer la présentation de la page, en mettant en avant qu’il s’agit d’un billet déjà rédigé, pas d’un élément à remplir Guidage

30 Onglet « Commentaires »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) On utilise deux fois le même label « Commentaires » pour deux choses différentes (une fois dans l’onglet une fois dans le menu de gauche) Adapter le labelling au niveau de l’onglet : mettre p.ex. « Commentaires du billet » Signifiance des codes et dénominations

31 Onglet « Commentaires »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Quelle est la logique souhaitée : un listing par auteur ou un listing par commentaires et rétroliens ? Attente réponse à question Guidage

32 Onglet « Modifier le N » Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Quand l’utilisateur clique sur un élément de liste (un billet, une page, un commentaire, un tag), il arrive à une page « Modifier le N » : peut-être ne veut-il pas le modifier, mais simplement le lire. Quand on clique sur « Nouveau billet », on arrive également sur cet onglet « Modifier le billet » : modifier quel billet ? Au regard des différentes limites identifiées pour ces onglets, il semble préférable de revoir le système d’onglet Guidage

33 2.5 Navigation complémentaire
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) On ajoute une navigation complémentaire qui semble évitable Qu’est-ce qu’il serait vraiment utile à l’internaute ? avoir une overview avec un accès en un coup à tous les « N », ou uniquement faire du « next » - « last »). Ce système de navigation complémentaire ne semble pas nécessaire. Est-ce qu’il ne serait plus intéressant de fournir une overview (p.ex. via liste déroulante) Comptabilité (à la tâche de l’utilisateur)

34 2.6 Rubriques de support Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Pour l’instant, seule l’aide peut être considérée comme une rubrique de support. N’y a-t-il pas d’autres rubriques de support utiles pour le back-office ? : « sitemap » du back-office, rubrique de support permettant de remplir un questionnaire de feedback, un questionnaire de contact ? Envisager l’éventualité d’ajouter des rubriques de support Comptabilité (aux besoins des utilisateurs)

35 Aide contextuelle Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Cliquabilité de l’aide contextuelle. Le design pourrait plus inciter à cliquer Améliorer la cliquabilité Incitation Icône d’aide contextuelle peu signifiante Il semble préférable de proposer un label « Aide », accompagné (si cela est vraiment souhaité) d’un icône Signifiance des codes et dénominations De nombreuses personnes risquent de ne pas réussir à sortir de l’aide contextuelle Proposer un élément de design qui communiquerait mieux comment fermer l’aide

36 2.7 Sauvegarde automatique des données ?
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Message « Voulez-vous vraiment quitter cette page, vous n’avez pas enregistré vos modification » A terme, ce message risque d’agacer fortement les utilisateurs Envisager de faire une sauvegarde implicite Actions minimales Pourquoi lorsque l’on souhaite sélectionner un média, on doit préalablement sauvegarder les données ? Dans ce cas de figure, l’utilisateur n’aura pas l’impression de quitter quelque chose, il souhaite seulement ajouter un média au billet. Dans ce cas de figure, il semble préférable de ne pas demander à l’utilisateur de sauvegarder Comptabilité (à la logique et la tâche de l’utilisateur)

37 2.8 Fonctionnalités / Options génériques
Recherche « Voir le site » / « Voir le billet »

38 Recherche Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Il n’y a pas de recherche simple accessible depuis toutes les pages. Cela semble pourtant indispensable Proposer une recherche simple sur toutes les pages Compatibilité (aux standards) Prise en compte de l’expérience des utilisateurs « Recherche avancée » : une recherche avancée à côté de la recherche simple semble également intéressante Reprendre la page de recherche actuelle et l’aménager en « Recherche avancée » Bouton de validation pour lancer la recherche optimisable Définir un design graphique qui incite plus à cliquer Incitation

39 Recherche Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Peu ou pas d’information sont données concernant le fonctionnement de la recherche Proposer une aide pour mieux comprendre le fonctionnement de la recherche Guidage Gestion des erreurs Pas de gestion d’erreur proposée pour la recherche Proposer des messages d’erreur Page « Listing des résulttats » optimisable Améliorer la lisibilité du listing de résultats (trop long à décrire, je propose de faire des maquettes fonctionnelles, c’est plus simple) Lisibilté

40 « Voir le site » / « Voir le billet »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Ces deux fonctions semblent très similaires, pourquoi pas utiliser un design graphique et un emplacement similaire (ou ayant un air de famille) L’emplacement « Voir le billet » semble optimisable Pour la rubrique « Pages », pourquoi ne pas mettre un « Voir la page » ? Améliorer leur design graphique Employer un même design graphique et un même emplacement pour ces deux fonctionnalités Envisager un placement plus adéquat pour ces fonctionnalités Homogénéité Groupement / Distinction entre les items

41 « Voir le site » / « Voir le billet »
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Quand on utilise ces options, il est difficile de revenir à la page en arrière Les pages vers lesquelles on est renvoyées ne sont pas homogènes Pas de retour en arrière (autre que le « Back » du navigateur) possible quand on clique sur ces options. Proposer un moyen explicite (en plus du « Back » du navigateur) pour revenir en arrière Contrôle de l’utilisateur

42 2.9 Formulaire Les guidelines qui suivent renvoient à tous les formulaires présents dans l’interface dotclear Champs et labels Boutons d’action Gestion des erreurs Messages de confirmation …

43 Champs et labels Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Labels des champs de formulaire très petits Cela rejoint le problème général de la police trop petite Agrandir la police des labels Lisiblité Formatage des labels non homogène Homogénéiser le formatage des labels Homogénéité

44 Boutons d’action Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Boutons d’action optimisables Les boutons d’actions ne sont pas assez identifiables en tant que tel. Mettre plus en valeur les boutons en les séparant un peu plus du dernier champ du formulaire Améliorer la cliquabilité et associer un design graphique qui ressemble plus à un bouton d’action. Agrandir la zone de cliquage De manière générale améliorer les intitulés : il est préférable de commencer par une lettre majuscule et de mettre des labels orientés action (p.ex. « se loguer » plutôt que « login »). Guidage Signifiance des codes et dénominations

45 Boutons d’action Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Pas de bouton « Annuler » Envisager si dans certains cas de figure, un bouton « Annuler » serait adapté Contrôle utilisateur

46 Gestion des erreurs Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Positionnement des erreurs optimisable En général, on essaie autant que possible de proposer l’erreur directement au niveau du champ concerné Proposer l’erreur en dessous du champ concerné Gestion des erreurs (qualité des messages d’erreur – correction des erreurs) Les messages d’erreur ne sont pas toujours complets Les messages d’erreur ne répertorient pas en intégralité tous les messages d’erreur d’une situation donnée Pour une meilleure compréhension de la situation d’erreur, toutes les erreurs d’un contexte donné doivent être mises en évidence Rédaction des messages d’erreur optimisable En général, une politique de rédaction de type : - Description de l’erreur / Solution au problème ….donne de très bons résultats Gestion des erreurs (qualités des messages d’erreur)

47 Gestion des erreurs Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Apparence des messages d’erreur optimisable Utiliser une couleur plus « aggressive » Améliorer l’icône associé au message d’erreur Gestion des erreurs Signifiance des codes et dénominations Quand on est sur l’onglet « Ajouter un commentaire » : quand l’utilisateur clique tout de suite sur « Ok », la page est remplacée par un message d’erreur et l’utilisateur perd le contexte initial Il semble s’agir d’un bug à corriger Homogénéité Il manque des messages d’erreur pour de nombreux cas de figure (champ de recherche de tags, recherche, filtre, etc.) Proposer des messages d’erreur pour tous les dialogues de type formulaire qui en nécessitent

48 Message de confirmation
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Mise en évidence du message de confirmation optimisable (p.ex. « Billet mis à jour avec succès ») La couleur actuelle est trop proche de la couleur du design global du back-office Améliorer l’icône Associer une couleur spécifique au message de confirmation (par exemple le vert). Signifiance des codes et dénominations Feedback Message intermédiaire de demande de confirmation : on utilise un autre mode de dialogue (de type Windows) En général, il est préférable d’intégrer au maximum les différents dialogues dans le design du système Si on conserve ce message de demande de sauvegarde, essayer de les intégrer en épousant au maximum le design du dotclear Guidage

49 Message de confirmation
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Possibilité de « undo » de confirmation manquante Cela semble être une approche intéressante. Envisager cette option Gestion des erreurs (protection contre les erreurs) Quand on crée un objet (page, billet, commentaire, etc.), lorsque l’on enregistre, on reste sur la même page Il semble préférable de rediriger l’utilisateur vers la liste initiale (page listant les pages, les billets, les commentaires) en mettant, en plus du message de confirmation en haut de la page, en évidence l’élément ajouté dans la liste Feedback Comptabilité (à la tâche de l’utilisateur)

50 Autres éléments Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Cliquabilité du « + » Améliorer la cliquabilité en jouant sur : - le design graphique - la grandeur de surface de clic Guidage

51 2.10 Editeur HTML Ces guidelines renvoient à toutes les pages proposant l’éditeur HTML

52 Editeur HTML – Densité informationnelle
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Beaucoup d’informations proposées dans l’éditeur. De nombreuses informations sont regroupées mais semblent de nature différente. Il semble préférable d’aménager ces informations de manière plus logique. Une idée : pourquoi ne pas séparer les fonctionnalités « standards » des autres un peu moins communes (comme p.ex. le retour à la ligne p.ex.) Compatibilité (en fonction du profil et de la tâche de l’utilisateur)

53 Editeur HTML – Icônes et labels
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Certains icônes et labels des fonctionnalités ne semblent pas très explicites « Image externe » : Image externe à mon site ? Pourquoi devoir fournir une URL pour insérer une image ? « Sélecteur de média » : les gens risquent de ne pas comprendre qu’ils peuvent insérer des pdf via cette option « Liens vers un billet » ou liens vers une autre URL : cette distinction est purement technique, les utilisateurs ne vont pas la comprendre Mettre tag avec code ? Suppression ou barré Forte emphase : pour les gens c’est italique Etc … Reconsidérer les icônes Signifiances des codes et dénominations

54 Editeur HTML – Sélecteur de média
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Gestionnaire de média » versus « Sélecteur de média » : quand on clique sur « Sélecteur de média », on arrive à une « page parallèle via pop up Il semble préférable d’éviter d’utiliser des pages « parallèles » pour un même concept Homogénéité Guidage « Choisissez un fichier à insérer dans le billet en cliquant sur « + » » : ou dois-je cliquer ? Proposer les aides proches des éléments concernés Gestion des erreurs

55 Editeur HTML – « Ajouter un lien »
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) La procédure « Ajouter un lien » semble optimisable Pourquoi l’URL du lien est en gras ? Pourquoi ne pas mettre une langue par défaut Sélection d’un pays : comment les gens cherchent ? Sur base du nom du pays ou de son abbréviation ? « Annuler » versus « Insérer » : ordre pas standard Homogénéiser le formatage de tous les labels de champs Mettre une langue par défaut Lister les pays dans un ordre parlant pour les utilisateurs Concernant l’ordre des boutons d’action, toujours proposer en premier le bouton « Positif » permettant de finaliser l’action et ensuite le bouton « Négatif » permettant d’annuler l’action. Proposer une couleur différente (mettant plus en valeur) pour le bouton « Positif » est également une approche intéressante Homogénéité Actions minimales Compatibilité (à la logique de l’utilisateur) Guidage

56 Editeur HTML Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Quand il n’y a pas de « Media », de « Billet », de « Tag » : si l’utilisateur clique sur ces options, il n’y a pas de message d’erreur Proposer des messages d’erreur adapté Gestion des erreurs La procédure « Remplacer un lien existant » n’est pas optimale Faciliter la procédure

57 « Visuel » vs « Code » Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) « Visuel » versus « code » pas optimaux Cliquabilité optimisable Labelling : les intitulés choisis sont-ils parlants pour les gens ? Améliorer le design graphique et la surface de clic Envisager des termes plus explicites Guidage Signifiances des codes et dénominations Switch entre « Visuel » et « Code » : quand on fait un switch entre les deux modes, on n’est pas placé au même endroit Quand l’utilisateur switche entre « Visuel » et « Code », faire en sorte qu’il soit au même niveau dans la page Actions minimales

58 Editeur HTML – Validation HTML
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Validation XHTML : l’emplacement et le design graphique ne semblent pas optimaux Pourquoi ne pas proposer cela directement dans l’éditeur ? Pourquoi cet élément a un design graphique de type lien « Contenu dans le body » ? Il s’agit plutôt d’un bouton d’action, voir d’une fonctionnalité « toolbox » Envisager un meilleur emplacement : pourquoi ne pas proposer cela directement dans l’éditeur Adapter le design graphique de cet élément Groupement / Distinction entre items Guidage « Vérification XHTML » : quelquefois, il y a un message d’erreur de type « socket » Proposer un message d’erreur adapté Qualité des messages d’erreur

59 Editeur HTML – Agrandissement
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Option permettant d’ajuster la grandeur de la boîte de saisi semble peu utilisable Quand on sélectionne cette option, on ne peut plus s’en défaire. Faire en sorte que l’utilisateur garde toujours le contrôle Contrôle utilisateur

60 2.11 Pages « Listes » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Les listes sont généralement accès sur les billets Au même titre que la page « Billets » liste des « Billets » : La page « Commentaires » devrait lister des commentaires associés à des billets La page « Tags » devrait lister des tags Comptabilité (à la tâche de l’utilisateur) Lorsqu’on sélectionne un élément dans une liste, on devrait arriver vers une page qui porte le nom de l’élément choisi (au lieu de « Modifier le N ») P.ex. quand on clique sur un tag listé dans la rubrique « Tags », la page devrait s’appeler tag « untel ». D’une manière générale, et si d’autres cas de figures se présentent, il serait préférable de respecter ce critère de base Guidage

61 Filtres Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Elément de filtre en haut de page optimisable Icône pas explicite II semble s’agir d’une recherche pour l’utilisateur, pourquoi ne pas la nommer et l’afficher en tant que telle ? Encore un choix de conception et un design graphique différent pour une zone cliquable Quand on entre dans le filtre, on n’arrive plus à en sortir. Le label pour lancer la requête « Filtre » semble optimisable Quand on appuie sur « Filtre » sans indiquer de critère, il n’y a pas de message d’erreur Améliorer la signifiance de l’icône Proposer un module de recherche et le nommer « Recherche » Envisager s’il n’est pas possible d’utiliser un choix de conception existant plutôt que d’en proposer un nouveau Donner un moyen à l’utilisateur de fermer le filtre Proposer un label « orienté action » parlant Proposer un message d’erreur Signifiance des codes et dénominations Guidage Homogénéité Contrôle utilisateur Gestion des erreurs

62 Formatage des listes Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) « Page(s) 1 » : pourquoi afficher cet élément quand il n’y a qu’une page ? Voir s’il est possible de ne pas afficher cet élément quand il n’y a qu’une page Densité informationnelle Présentation de la liste sous forme de tableau optimisable Appliquer quelques guidelines de base pour améliorer la lisibilité (je propose de faire des maquettes c’est plus simple) Lisibilité Pourquoi afficher uniquement certaines métadonnées dans le tableau Voir dans quelle mesure on ne devrait et pourrait pas afficher toutes les métadonnées Comptabilité (à la tâche des utilisateurs) Pourquoi ne pas permettre de changer les métadonnées directement dans la liste ? P.ex. il semble utile ici de donner la possibilité de changer une catégorie Envisager la possibilité de changer les (ou certaines) métadonnées directement depuis la liste Contrôle utilisateur Actions minimales

63 Roll-over dans les listes
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Roll-over pose problème Pourquoi faire un roll-over uniquement pour ce cas de figure ? Pourquoi faire ce roll-over sur toute la ligne alors que seuls quelques éléments de la ligne sont cliquables Homogénéiser les choix de roll-over Proposer uniquement un effet de roll-over pour les zones cliquables Homogénéisation Guidage

64 Autres métadonnées dans la liste
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Formalisme de date pas uniforme Proposer un formalisme de date uniforme pour tout le back-office Homogénéité Les icônes à droite dans la liste posent différents problèmes Icônes peu explicites Surface de cliquabilité très petite Améliorer la signifiance des icônes. Voir dans quelle mesure il ne serait pas utile de proposer une légende Agrandir la surface de clic Signifiances des codes et dénominations Guidage

65 « Actions sur les billets sélectionnés »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Beaucoup d’informations hétérogènes dans le menu déroulant. Les options « Ajouter des tags », « Supprimer des tags » ne semblent pas être au bon endroit Il semble préférable de conserver ce menu pour les informations sur les statuts (publier, etc…). Envisager de placer les autres options uniquement au niveau des fiches descriptives Groupement / Distinction entre item Comptabilité (à la tâche de l’utilisateur) Option « supprimer » : on utilise encore une autre procédure Uniformiser les procédures de suppression Homogénéisation Pas assez de feedback pour mettre en avant ce qui est fait par le système quand l’utilisateur sélectionne une option Améliorer le feedback pour donner un retour sur les actions de l’utilisateur Feedback Il n’y a pas de confirmation de suppression Proposer un message d’erreur adapté Gestion des erreurs

66 Autres options de la liste
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Tout sélectionner » vs « Inverser la sélection » : - Ces informations semblent optimisables La présentation des ces informations semblent optimisables Groupement / Distinction entre item Comptabilité (à la tâche de l’utilisateur) Guidage Validation de l’option choisie via « OK » : pourquoi ne pas permettre aux gens qui ont javascript d’activé de ne pas utiliser « OK » Envisager la possibilité d’avoir une validation implicite quand l’utilisateur fait un choix dans le menu (sans faire apparaître le bouton « Ok ») Actions minimales

67 Liste « sans objet » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Quand on arrive à une page en mode « liste » ou il n’y a pas d’items , on propose un texte peu adapté Il semble préférable d’améliorer le message proposé à l’utilisateur Guidage

68 3. Mode logué – Scénarii clé
Page d’authentification – Login / Delogin Rubrique « Tableau de bord » Rubrique « Nouveau billet » Rubrique « Billets » Rubrique « Commentaires » Rubrique « Catégories » Rubrique « Gestionnaire de média » Rubrique « Pages » Rubrique « Tags » Rubrique « Extension > Liens »

69 3.1 Page d’authentification – Login
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Emplacement « J’ai oublié mon mot de passe » pas optimal Le message d’erreur n’est pas associé visuellement au champ concerné Préférable de proposer ce lien à côté du champ concerné. L’emplacement serait adapté (dans le fieldset) si le lien concernait tout le fieldset et si l’on mettait « J’ai oublié mon login et/ou mon mot de passe » Gestion des erreurs Regroupement - Distinction pour la localisation « Vous devez accepter les cookies pour utiliser l’interface privée » pas explicite Certains utilisateurs ne connaissent pas la notion de cookie. La plupart ne connaissent pas la procédure pour les accepter Expliquer la notion de cookie, expliquer ce que cela implique pour l’utilisateur Expliquer la procédure pour accepter les cookies Prise en compte de l’expérience des utilisateurs

70 3.1 Delogin Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Le design graphique associé à « Déconnexion » semble optimisable (trop proche de celui associé à « redacteur » Améliorer la cliquabilité de cet élément Guidage Il manque un message de confirmation pour la déconnexion Proposer un message de confirmation pour la déconnexion Feedback

71 3.2 Rubrique « Tableau de bord »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Les fonctions « Nouveau billet », « 5 billets », etc. prennent beaucoup de place sur la page tableau de bord. Essayer de voir comment l’on pourrait gagner de la place sur cette « page d’accueil » Densité informationnelle Le tableau de bord répète beaucoup d’informations déjà présentent dans les zones de navigation. Pourquoi ne pas utiliser ce tableau de bord comme une véritable page d’accueil Il semble préférable d’utiliser cet espace pour mettre en évidence des actions très spécifiques, et ne pas recopier en partie le menu de gauche

72 « Préférence utilisateur »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Préférence utilisateur » est un élément que l’on ne retrouve pas dans le menu de gauche ? Toutes les pages devraient être accessibles via le menu de navigation Guidage

73 Rubrique « Tableau de bord »
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Le tableau de bord propose trois types d’informations : - des actions (p.ex. « Nouveau billet »), - des liens vers des pages informationnelles (p.ex. « Préférence utilisateur »), - des informations d’overview sur le nombre d’éléments déjà rédigés par le rédacteur (p.ex. « 5 billets »). Il semble préférable d’avoir une ligne de conduite homogène et de positionner les informations en fonction de leur nature. Les informations d’overview (p.ex. « 5 billets ») semblent être intéressantes sur toutes les pages du back-office. Centraliser les informations d’overview dans le tableau de bord (nombre de billets, de pages, de commentaires, de liens, de tags) et proposer cet encart « Tableau de bord » sur toutes les pages du back-office. Au regard des problèmes de granularité du menu de gauche, pourquoi ne pas enlever « Nouveau billet » du menu de gauche et le proposer sur la page d’accueil. Une autre idée pourrait être de mettre une « toolbox » accessible sur toutes les pages pour les actions importantes, notamment « Nouveau billet » Groupement / Distinction entre items Guidage Comptabilité (à la tâche de l’utilisateur)

74 « Billet rapide » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) « Billet rapide » versus « Nouveau billet » : les gens risquent de ne pas trop comprendre la différence. D’autant plus qu’elle semble minime. Cela est d’autant plus dommage que l’on présente les informations de manières différentes (l’option « Catégorie » n’est pas positionnée au même endroit) Au regard des précédentes remarques, pourquoi ne pas proposer directement « Nouveau billet » sur cette page ? Comptabilité (aux besoins de l’utilisateur)

75 Rubrique « Tableau de bord » – Labelling
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Labelling du « Tableau de bord » : ce label semble renvoyer à des informations d’overview Il semble préférable de conserver le label « Tableau de bord » pour les informations d’overview et de nommer le lien dans le menu « Accueil » Guidage Signifiance des codes et dénominations

76 3.3 Rubrique « Nouveau billet »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Extrait » est un label, pourquoi n’est-il pas proposé en gras ? Définir une approche de formatage des labels de champ de formulaire homogène Homogénéité « Extrait », « Note », « Contenu » : on ne donne pas d’explication sur ces concepts à l’utilisateur. P.ex. le comportement de « Extrait » par rapport à « Contenu » n’est pas directement explicite, les gens risquent d’être obligé de comprendre par « essai-erreur » Fournir des éléments (p.ex. aide contextuelle textuelle ou imagée) qui permettent d’expliquer les concepts Guidage Gestion des erreurs « Catégorie » : s’il n’y pas de catégorie, on propose tout de même un menu déroulant Quand il n’y a pas de catégorie, il semble préférable de ne pas mettre de menu déroulant et de faire un renvoi ici vers l’option qui permet de créer une catégorie

77 « Etat du billet » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) « Publié » est l’option proposée par défaut, pourquoi ne pas la mettre en premier dans la liste ? Réordonnancer les options du menu déroulant de manière logique pour l’utilisateur Comptabilité (à la logique de l’utilisateur) Que veut dire « programmé » ? Définir des labels dans le menu déroulant parlants pour l’utilisateur Signifiance des codes et dénominations

78 Option « Publié le » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Le format attendu n’est pas spécifié Même s’il y a un calendrier, fournir le format attendu à la suite du champ Incitation Aucune date n’est proposée par défaut  Proposer par défaut la date du jour Action minimale

79 Calendrier Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Calendrier optimisable Il affiche directement des infos dont on n’a pas besoin Le système de navigation par mois et années est optimisable Fermer le calendrier est également compliqué (option mal placée, petite surface de clic, quand l’utilisateur clique en dehors du calendrier ce dernier devrait se fermer, etc…) Il semble préférable de regarder les solutions de calendrier existantes ou d’adapter globalement la solution actuellement utilisée

80 « Accepter les commentaires, les rétroliens »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Accepter les commentaires » et « Accepter les rétroliens » semblent être des informations de types différents par rapport aux autres informations proposées dans cette colonne de droite Il semble préférable de localiser ces deux informations à un endroit bien distinct des autres Regroupement / Distinction des items « Accepter les rétroliens » : - Qu’est-ce qu’un rétrolien ? - Que veut dire « Accepter un rétrolien » ? Proposer une aide contextuelle permettant d’expliquer cette notion à des lemdba users Guidage Gestion des erreurs Prise en compte de l’expérience de l’utilisateur

81 « XHTML » et « WIKI » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) « XHTML » et « WIKI » : le lembda user risque de ne pas comprendre Proposer des aides contextuelles pour orienter le choix de l’utilisateur Guidage Gestion des erreurs Prise en compte de l’expérience de l’utilisateur

82 « Billet sélectionné » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) « Billet sélectionné » : - qu’est-ce que cela veut dire ? - qu’est-ce que cela implique pour l’utilisateur de cocher cette case ? Expliquer ce qu’implique le fait de cocher la case Action explicite Guidage

83 Mode de navigation supplémentaire
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Langue du billet » et « Mot de passe » : on propose des modes de navigation différents à ce qui existe Eviter dans la mesure du possible de démultiplier les éléments de navigation pour des choses similaires (p.ex. langue du billet, pourquoi ne pas utiliser un menu déroulant ? D’autant plus que la place gagnée n’est pas énorme) Guidage Homogénéité

84 « URL spécifique » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Url spécifique : - à quoi cela renvoie t-il ? - pourquoi mettre un cadena ? - attention : si vous indiquez l'URL manuellement, celle-ci peut entrer en conflit avec une autre catégorie : comment faire autrement que manuellement ? Améliorer le labelling Pourquoi ne pas proposer directement le message d’erreur ? Rendre le message d’erreur plus explicite Signifiances des codes et dénominations Charge de travail (Actions minimales) Qualité des messages d’erreur

85 « Ajouter une pièce jointe »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Ajouter une pièce jointe » versus « Sélecteur de média » : ces options ont l’air quasi identiques Tenter de définir des labels plus distincts et exclusifs Signifiance des codes et dénominations

86 Zone « Tags » 1/2 Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Qu’est-ce qu’un tag ? Expliquer la notion de tag Signifiance des codes et dénomination S’il n’y a pas de tag, logiquement, il ne faudrait pas mettre « Sélectionner dans la liste de Tags » « Champ de recherche » versus « Choisir depuis la liste » : cela semble être deux choses différentes, mais cela n’est pas communiqué Améliorer la présentation des informations de manière à communiquer les deux modes d’action Guidage

87 Zone « Tags » 2/2 Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Quand on clique sur « Ok » sans proposer de Tag, il n’y a pas de message d’erreur Proposer un message d’erreur adapté Gestion des erreurs Il n’est pas assez mis en avant qu’il s’agit d’une logique de liste Communiquer clairement qu’il s’agit d’une logique de liste Guidage Tout dépend du nombre de tags qu’il peut y avoir sur un blog, néanmoins le mode de présentation ne semble pas optimal Améliorer la présentation des tags existants (une approche par « bulleted list » améliorerait la lisibilité) Lisibilité Supprimer le tag : l’icône n’est pas l’icône standard Utiliser un icône « Suppression » homogène pour tout le back office Globalement, il semble préférable d’utiliser un cadre bien distinct pour ces aspects « TAG »

88 3.4 Rubrique « Billets » Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Quand l’utilisateur clique sur la rubrique « Billet », pourquoi ne lui offre t-on pas la possiblité de rédiger un nouveau billet ? Il semble préférable dans cette page de lui proposer la possibilité de créer un nouveau billet Compabilité (à la logique et à la tâche de l’utilisateur) Quand on valide le billet, il n’y a pas de feedback explicite proposé à l’utilisateur Il semble préférable, une fois que l’utilisateur a crée un billet, de le renvoyer vers la page qui liste l’intégralité des billets existants en mettant bien en évidence le billet ajouté Feedback

89 3.5 Rubrique « Commentaires »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Quand l’utilisateur clique sur la rubrique « Commentaires », il devrait s’attendre à accéder à une page listant les commentaires associés aux différents billets Adopter ici une logique de liste de commentaires Compatibilité (à la tâche de l’utilisateur) Il semble qu’il devrait également être possible de rédiger directement un commentaire Permettre dans cette page de faire un commentaire

90 Icône « Modifier ce commentaire »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Ne semble pas à la bonne place Pour modifier un commentaire, le plus logique semble de rentre l’intitulé cliquable Groupement / Distinction entre les items Pas assez mis en valeur Mieux mettre cette fonctionnalité en valeur Zone de clique très petite Agrandir la zone de clic Guidage Icône très peu significative Il semble préférable d’enlever cet icône

91 « Commentaires indésirables »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Qu’est-ce qu’il se passe si on choisit cette option ? Donner des informations qui permettent à l’utilisateur de comprendre ce qu’il se passe s’il choisit cette option Guidage Signifiances des codes et dénominations Les commentaires indésirables ne sont pas notifiés dans les listes Il semble intéressant de mettre tous les commentaires indésirables dans la liste, et d’y associer une icône spécifique (comme « Publié », non « Publié », etc.) Homogénéité

92 3.6 Rubrique « Catégories »
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Approche différente pour lister les catégories Pourquoi ne pas adopter une approche identique aux autres parties du back-office pour lister les catégories ? Il semble préférable d’adopter une approche homogène aux autres listes Homogénéité

93 « Supprimer les catégories »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) La procédure utilisée n’est pas homogène Il semble préférable d’employer une procédure de suppression commune pour tout le back-office Homogénéité Gestion des erreurs La fonctionnalité ne semble pas bien placée Il semble préférable de placer l’option de suppression directement au niveau de la catégorie : dans la liste et dans la fiche descriptive de la catégorie Groupement / Distinction entre les items Comptabiilté (à la tâche de l’utilisateur)

94 Billet par catégorie Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) On a une approche différente de la page « Billet » Il semble préférable d’homogénéiser cela Homogénéité

95 « Créer une catégorie » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Procédure : pourquoi ne pas adopter une procédure similaire pour toutes les créations d’objet ? Définir une approche similaire pour la création des objets Homogénéité Terme « Parents » : peu explicite Proposer un label plus explicite Signifiance des codes et dénominations

96 Options supplémentaires
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Ceci va déplacer toutes les catégories au premier niveau » : semble peu explicite Rendre cela plus explicite Actions explicites « Réordonner directement » : - label pas explicite - comment cela réordonne ? - option semble mal placée Rendre ce label plus explicite Mettre en valeur ce que cette fonction permet de faire Il semble préférable de placer cette option directement au niveau de la liste Signifiance des codes et dénominations Contrôle explicite Groupement / Distinction entre items

97 Fiche descriptive d’une catégorie
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Catégorie parente » et « Voisine » : les concepts semblent difficiles à comprendre Rendre cela plus explicite (p.ex. via une approche graphique) Signifiances des codes et dénominations Dans la liste des catégories, il y a deux liens, mais cela ne se voit pas Distinguer les liens adjacents Guidage

98 3.7 Rubrique « Gestionnaire de média »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Privé : peu explicite Label du bouton : « Envoyer » ou « Ajouter » ? Rendre cela explicite Signifiance des codes et dénominations « Activer l’interface avancée » : - « Interface » : labelling peu explicite - Présentation globalement optimisable : est-ce un lien de navigation ou un bouton d’action - Je fais un « Back » via le navigateur et je suis perdu Trouver un label plus explicite Adapter le design graphique Le « Back » doit toujours permettre de revenir à la page précédente Guidage Contrôle explicite

99 3.7 Rubrique « Gestionnaire de média »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) Le mode de présentation est nettement plus lourd et plus compliqué que les autres pages qui listent des élements : pourquoi ne pas conserver l’approche de liste des autres pages ? Les formulaires sont peu délimités et identifiables Alléger la présentation de la page Voir dans quelle mesure on ne pourrait pas adopter l’approche de liste classique Densité informationnelle Homogénéité

100 3.7 Rubrique « Gestionnaire de média »
Choix de conception et limite(s) identifiée(s) Recommandation(s) Critère(s) et justification(s) « Répertoire » versus « Catégorie » : les deux titres semblent très proches Redéfinir les labels de façon à mieux les distinguer et les rendre exclusifs Signifiance des codes et dénominations « Ajouter des fichiers » versus « Nouveau répertoire » ? Définir des labels plus explicites et exclusifs

101 3.7 Rubrique « Gestionnaire de média »
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) On propose plusieurs zones cliquables très rapprochées pour les mêmes choses Le fait que les liens soient très proches laisse supposer qu’il s’agit de liens différents Eviter de démultiplier les liens identiques dans de faibles périmètres qui plus est avec des « libellés » différents Guidage Télécharger ce fichier zip : à quelles fins ? Rendre cela plus explicite afin de mieux orienter l’utilisateur Taille maximale : - 2MB = c’est quoi MB ? Expliciter Signifiances des codes et dénominations

102 3.8 Rubrique « Pages » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Nouvelle page : le placement de l’option (pour l’instant associé au « breadcrumb ») et le design graphique associé (qui ressemble peu à un bouton d’action) semblent optimisables Proposer un emplacement plus adéquat Proposer un design graphique plus adéquat Groupement / Distinction entre items Guidage

103 3.9 Rubrique « Tags » Choix de conception et limite(s) identifiée(s)
Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) Il semble que l’on oublie de proposer ici des informations qui pourraient répondre aux besoins utilisateurs dans ce contexte En plus de la liste des tags, les gens pourraient s’attendre à avoir ici la possibilité de créer un tag Il semble également intéressant de mettre en évidence quel billet est associé à quel tag Pourquoi ne pas proposer la possibilité d’associer le tag à d’autres billets directement dans cette page ? Pourquoi ne pas proposer ici de créer un tag Mettre en évidence les billets associés aux différents tags Un détail : si 1 billet, alors pas de (s) à billet. Mettre un s entre parenthèse, si cela est possible Proposer ici la possibilité d’associer un tag à d’autres billets Comptabilité (à la tâche de l’utilisateur)

104 3.9 Rubrique « Tags » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Supprimer ce tag : on utilise un moyen différent de ce qu’il existe. Il y a déjà « Supprimer des tags », à quoi renvoie « Supprimer » ? Adopter une approche globale commune pour les procédures de suppression Homogénéité Renommer le tag : procédure pas explicite Rendre cela plus transparent pour l’utilisateur Guidage

105 3.9 Rubrique « Tags » Choix de conception et limite(s) identifiée(s)
Recommandation(s) Critère(s) et justification(s) Agencement des tags Pourquoi ne pas adopter un mode liste ? Lisibilité

106 3.10 Rubrique « Extension > Liens »
Choix de conception et limite(s) identifiée(s) Explication complémentaire du problème Recommandation(s) Critère(s) et justification(s) La rubrique « Liens » amène vers une page qui porte un autre nom « Blogroll » Afin de faciliter la navigation et la compréhension de la page, il est préférable de conserver des labels identiques Mettre comme titre de page « Liens » ou alors intituler la rubrique « Blogroll » Incitation Homogénéité « Blogroll » ne semble pas très parlant pour le lembda user Proposer un label plus parlant Signifiance des codes et dénominations Présentation des informations On utilise des approches différentes (au niveau des onglets, des options de suppression etc.) Homogénéiser Ici se posent les mêmes réflexions que pour le système d’onglet

107 4. Synthèse des principaux résultats
Système de navigation, architecture, labelling Système d’onglets Aide versus aide contextuelle Sauvegarde automatique des données Recherche « Voir le billet » / « Voir le site » / « Voir la page » Certains formulaires Editeurs HTML Optimisation des pages de listes Tableau de bord Optimisation création d’un « Billet » / « Commentaire » Optimisaton « Catégories » Optimisation « Gestionnaire de média » Pour tout cela, il semble important de faire du maquettage

108 5. Prochaines étapes Repenser les profils utilisateurs ciblés et faire des personas : qui ciblez-vous ? C’est question est prioritaire pour la reconception Task analysis : quels sont les scénarii clé ? Est-ce que vous souhaitez en ajouter d’autres ? Reprendre chacun des points et faire du maquettage fonctionnel Tri de cartes Tests utilisateurs

109 D’autres propositions
Possibilité d’enquête d’usage Possibilité de recueil d’informations sur l’usage des gens via des outils ? Possibilité de recueil de feedback contextualisé ?