1 Audit ergonomique « Back-office Dotclear » Gautier Barrère 13.12.2008.
-
Upload
abelard-tavernier -
Category
Documents
-
view
106 -
download
0
Transcript of 1 Audit ergonomique « Back-office Dotclear » Gautier Barrère 13.12.2008.
1
Audit ergonomique « Back-office Dotclear »
Gautier Barrère
13.12.2008
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
1. Concepts globaux « Blog » 2. Mode logué – Informations de « haut niveau »
2.1 Niveau de contraste2.2 Police2.3 Système de navigation – Architecture – Labelling2.4 Système d’onglet2.5 Navigation complémentaire 2.6 Rubriques de support 2.7 Sauvegarde automatique des données ?2.8 Fonctionnalités / Options génériques2.9 Formulaire2.10 Editeur HTML2.11 Pages « Liste »
3. Mode logué – Scénarii clé3.1 Page d’authentification – Login / Delogin3.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
Plan de l’audit
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 ».
Définir un rapport « Background / Foreground » assez contrasté
Lisibilité
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 email 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
Homogénéité
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
Incitation
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 »
Prise en compte de l’expérience des utilisateurs
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 Gestion des erreurs
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
Guidage
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
Gestion des erreurs (qualité des messages d’erreur – correction des erreurs)
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 Gestion des erreursHomogé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
Gestion des erreurs
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
Guidage
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 nouveauDonner un moyen à l’utilisateur de fermer le filtre
Proposer un label « orienté action » parlant
Proposer un message d’erreur
Signifiance des codes et dénominationsGuidage
Homogénéité
Contrôle utilisateur
Guidage
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 itemComptabilité (à 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 itemComptabilité (à 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’utilisateurExpliquer la procédure pour accepter les cookies
Gestion des erreurs 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
Densité informationnelle
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
GuidageComptabilité (à 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
Guidage
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 optimisableFermer 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 expliciteGuidage
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)
GuidageHomogé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
Gestion des erreurs
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
Compatibilité (à la tâche de l’utilisateur)
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
Groupement / Distinction entre les items
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 itemsComptabiilté (à 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énominationsContrô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
Signifiance des codes et dénominationsGuidageContrô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
Signifiance des codes et dénominations
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
Guidage
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 itemsGuidage
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 Homogénéité
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é ?