2/8 DÉBUT PRÉC. SUIV. FIN SOMMAIRE INDEX GLOSSAIRE

6 juin 2006

1. Expérience utilisateur

Résumé :
La plateforme web « Les Fûts » s'adresse à des membres d'associations, qui ne sont pas techniciens et qui n'ont pas forcément l'habitude du web.

Contexte

Pour un utilisateur, un site web associatif distribué par les Fûts s'apparente un site web tout simple, avec des fonctionnalités standard.

De ce point de vue, chaque association a son site web, avec son contenu et ses documents spécifiques, et son apparence à lui.

Cependant, si une personne fait partie de plusieurs associations membres des Fûts, elle peut accéder de façon unique et homogène à toutes les informations de ses associations. Par exemple, la personne pourra avoir sur une même page de type calendrier, les dates des différents événements de ses différentes associations.

Cas d'utilisation de bases

En tout premier lieu, les visiteurs du site doivent au moins être capables de :

laisser des commentaires à propos de tout élément du site
rechercher des informations sur l'ensemble du site
imprimer facilement un élément du site
faire un copier/coller d'une URL sur le site, et qu'elle soit encore valide un an après (sous réserve évidemment que l'association ait conservé son site)
s'abonner au site, soit par une newsletter, soit par l'intermédiaire des flux RSS, soit en demandant une notification par e-mail de réactions à un message, à un commentaire...

De même, les membres habilités de l'association qui possède le site, doivent au moins être capables de :

publier une note courte, suivant le modèle du blog ou du forum
ajouter, modifier, gérer, supprimer, des pages, suivant le modèle du wiki
attacher des tags aux éléments du site
gérer les habilitations des utilisateurs
uploader des documents, des images
avoir une page personnalisée, et gérer leurs préférences,

Les personnes qui sont membres de plusieurs associations dont le site est distribué par les Fûts doivent au moins être capables de :

disposer d'une page d'accès unique aux sites des différentes associations dont elles sont membres.

Briques de bases

Chaque site distribué par les Fûts doit avoir :

une charte graphique,
une politique de sécurité,
un annuaire des membres,
un calendrier,
un forum,
un blog,
un wiki,
un moyen public d'envoyer un feedback, ne serait-ce que par l'intermédiaire d'un forum.

Tags avancés : en-têtes

Pour la technique, un tag est une méta-donnée, un en-tête attaché à un élément.

En l'occurrence, on propose que ce soit un en-tête de nom « X-Semantic-Tag: ».

Un utilisateur, sous certaines conditions à définir, devrait également être capable d'attacher d'autres en-têtes arbitrairement.

Ainsi, lorsqu'un commentaire est laissé à propos d'un document, l'utilisateur devrait pouvoir décider que le commentaire apparaîtra également dans tel(s) newsgroup(s), en spécifiant un en-tête « Newsgroup: ». Idem pour les « Followup-To: ».

Par ailleurs, il serait bon que les messages (d'un point de vue technique, tout est message dans les Fûts) aient un en-tête qui spécifient leur domaine d'appartenance, leur namespace. On propose « X-Semantic-Namespace: ».

Ainsi, les tags identiques de domaines différents pourraient être définis comme apparentés... ou non. Par exemple, si deux associations utilisent le tag « réunions », on peut décider de les apparenter ou non. Ou si deux associations ont chacune un forum « tournois », on peut décider sur une page d'agrégation de les apparenter ou non.

Noter que les recherches sur mots-clefs doivent pouvoir se faire sur tous les d'en-têtes.

Commentaires

Les commentaires peuvent être laissés à propos de chaque élément du site : articles de blog, pages institutionnelles, images, documents, et évidemment discussions sur un forum.

Tous les caractères sont permis, en particulier les caractères accentués (utilisation d'Unicode). Voir plus bas.

Les commentaires suivent le modèle text only, en vigueur généralement sur Usenet.

Ainsi, la saisie d'un commentaire ne permet pas de grandes fioritures : du texte, un peu de mise en forme (gras, italiques), un peu d'éléments inclus (liens HTTP, FTP ou mailto:), des indentations pour citations, des listes.

Mais : pas d'images, de son, de vidéo.

On peut choisir que le commentaire soit publié en police à chasse fixe.

Annuaire

Les adhérents d'une association doivent être capables de voir la liste des autres adhérents.

Timezones

Les actions sont tracées avec leur date, mais également leur fuseau horaire quand c'est possible.

Dans les vues de dates et d'heures, on présente à l'utilisateur les différences entre fuseaux horaires. Cela permet de mettre en relation temporelle différentes actions tracées, en particulier ce qui concerne le postage d'articles.

On tracera également quand c'est possible la ou les langues utilisées dans les actions (rappelons que toute action est en fait un message), et le pays d'origine de l'action.

Multilinguisme

La plateforme du site des Fûts doit être prévu au moins en français et en anglais.

Les utilisateurs doivent pouvoir publier des articles, des commentaires et des documents, dans n'importe quelle langue, et la spécifier s'ils le désirent.

Pas d'identifiant numérique interne à l'écran

Les identifiants internes de l'application, qu'il s'agisse de personnes, de messages, de groupes, d'articles, de documents... ne doivent pas apparaître à l'écran de l'utilisateur. Surtout s'il s'agit d'identifiants numériques.

En effet, un identifiant numérique peut renseigner sur le nombre total d'éléments stockés, ou sur la séquence de leur création... L'utilisation d'identifiants numériques peut également permettre l'accès « pirate », du moins « aléatoire », à des éléments, puisqu'on peut forger soi-même des URLs.

On préfèrera afficher des identifiants numériques fonctionnels (numéros de chapitres, dates...) et des identifiants texte sans accents (US-ASCII).

Prenons un exemple : un groupe de discussion (ou forum, ou newsgroup, comme vous voulez) qui s'appellerait « Les Fûts, Général ». À l'écran, l'utilisateur voit évidemment le nom « Les Fûts, Général » avec ses accents. Mais dans les URLs, que verra-t-on passer ? Certainement pas des paramètres du genre « ?forum=123 » comme chez phpBB, mais plutôt du genre « ?group=lesfuts », voire carrément pas de paramètre : « /group/lesfuts/ », comme chez Google Groups.

Caractères accentués

Il ne doit y avoir aucun problème de caractères accentués dans l'interface utilisateur (utilisation d'Unicode) :

si mon navigateur et mon système d'exploitation me permettent de saisir des accents courants (par exemple, le « e » accent aigu) ou des caractères diacritiques moins courants sur le web (par exemple, le « oe » lié), voire des caractères qui n'ont rien à voir avec la choucroute (par exemple, du coréén), la plateforme doit être capable de stocker mon texte accentué, et de me le restituer exactement comme je l'ai saisi.
si mon navigateur et/ou mon système d'exploitation ne me permettent que de saisir certains accents, la plateforme doit être capable de stocker mon texte accentué, et de me le restituer exactement comme je l'ai saisi.
si un autre utilisateur a saisi des caractères accentués ou diacritiques trop complexes pour mon navigateur et/ou mon système d'exploitation, j'aurai une limitation à l'affichage, mais cette limitation doit porter sur ces caractères, et non sur l'ensemble de la page ou de l'application.
si par malheur (remboursez !) des accents causaient des problèmes majeurs d'affichage sur mon navigateur, je dois être capable par un changement de mes préférences, de passer explicitement dans un mode dégradé, reconnu par l'application.

Back & Reload

L'application doit être robuste au bouton Back, et au bouton. Reload.

Par exemple, si après avoir posté un message, je fais Back, puis de nouveau Publish, l'application doit me prévenir que mon message a déjà été publié et qu'il ne le sera pas une seconde fois.

À moins bien sûr que le contenu du deuxième message soit différent, ou que l'utilisateur souhaite explicitement republier le message quand même.

Les heuristiques sont à étudier.

Messages d'erreurs

Les messages d'erreurs doivent être clairs, et comporter les éléments suivants :

Description de l'erreur. Exemple : « votre article est vide et ne peut donc pas être envoyé ».
Solutions probables. Exemple : « merci de saisir le contenu de votre article ».
Informations de référence. Exemple : ...

Les messages d'erreurs applicatifs doivent être préférés à l'apparition à l'écran de messages d'erreurs techniques bloquantes. Par exemple, lorsqu'une demande applicative met du temps à recevoir sa réponse, on peut tomber en timeout applicatif, c'est-à-dire que l'utilisateur a un affichage clair : « votre demande a été prise en compte, mais elle n'a pas encore été traitée. Merci de revenir sur cette page d'ici une minute ». De cette façon le problème de traitement n'est pas bloquant.

Liste de messages publiés

En plus des vues classiques du genre blogs et forums web (phpBB), l'utilisateur a accès aux messages présentés par liste : tous les titres messages, filtrés ou non, présentés sous forme de liste à plat.

C'est une vue complètement évidente, qui permet de regrouper sur un même écran articles, commentaires, etc. et de les classer par auteurs, par dates...

Penser aux blogs, qui donnent une place prépondérante aux articles, et qui relèguent les commentaires à un voire deux clics. La liste à plat complètera le suivi des commentaires.

Penser aux forums web, qui regroupent de façon quasiment obligatoire les messages par discussions. La liste à plat complètera le suivi de l'activité du forum.

Les éléments affichés dans cette liste sont :

le type de l'élément : document, article de blog, page de wiki, article de forum, commentaire...
le nom de l'auteur, éventuellement tronqué à 40 caractères, dans ce cas on rajoute des points de suspension « ... »
la taille du message en lignes, ou en caractères, ou en octets après un encodage en UTF-8
la date d'envoi du message, avec une indication de timezone relative lorsqu'il s'agit d'une autre timezone que celle de l'utilisateur qui voit la liste
le sujet du message, éventuellement tronqué à 200 caractères, dans ce cas on rajoute des points de suspension « ... »

La pagination de ce type de liste est par défaut de 50 éléments, mais ce nombre peut être modifié par l'utilisateur.

L'affichage peut être filtré en :

n'affichant que les messages lus, non lus, cochés, nouveaux,
n'affichant que les messages qui sont moins vieux que 7 jours, 14 jours, un mois, 2 mois, 3 mois, 6 mois, un an

La liste peut être triée par :

auteur (ignorer les majuscules et minuscules, convertir les signes accentués en ASCII, ne se baser que sur ce qui est affiché/tronqué),
date (ramener à GMT),
sujet (ignorer les préfixes standard comme « Re: », ignorer les majuscules et minuscules, convertir les signes accentués en ASCII, ne se baser que sur ce qui est affiché/tronqué),
enfilade (regroupement préalable des messages en discussions, puis tri par sujet).

Représentations arborescentes des discussions

Lorsque les commentaires sont nombreux, chacun répondant soit à l'élément initiateur (un document, un article...) soit à un autre commentaire, ils forment de véritables discussions.

Ces discussions doivent être représentées sous forme arborescente, pour permettre la visualisation rapide, le tagging et/ou le dépôt dans un kill-file par sous-discussion.

Écrans de consultation

Les écrans de consultation à prévoir pour la v1.0 des Fûts sont :

Page d'accueil. Page d'accueil de blog classique : articles récents, et liens vers les commentaires.
Pages classiques. Les pages classiques sont : le plan du site, la page « à propos », les mentions légales, et un formulaire pour contacter l'équipe.
Archives du blog par mois.
Archives du blog par année.
Articles du blog.
Liste des tags.
Calendrier.
Annuaire.
Liste à plat des messages.
Liste des forums.
Articles des forums.

C'est le même site qui « est » à la fois un blog et un forum. En effet, la vue des messages par liste concerne aussi bien les éléments du blog que du forum. Dans cette perspective, au lieu de prévoir des liens « Vers le blog » et « Vers le forum », prévoir des boutons « Afficher le site en mode blog », « Afficher le site en mode forum ».

Un article de blog (et ses commentaires, qui nécessitent un lien en mode blog), peut être directement affiché sous forme de discussion (ses commentaires apparaissent à plat, avec d'autres commentaires sur d'autres articles).
Une discussion de forum peut être rattachée à une vue blog en « remontant » vers l'article d'origine. Cliquer sur « Afficher le site en mode blog » positionnerait l'utilisateur sur cet article.

Sur chaque page, on doit avoir les informations sur la session en cours, avec la date en cours, la timezone utilisée, la langue utilisée, le nom de l'utilisateur, les liens vers ses préférences, etc. Ou bien, si l'utilisateur n'est pas encore identifié, des zones de saisies pour qu'ils s'identifie quand il le souhaite. Un m

On doit également avoir une zone de recherche sur chaque page.

La navigation structurelle doit être implémentée de A à Z, avec visualisation de l'emplacement courant sous la forme « A/B/C », ou « A -> B -> C », et présence de liens « Up », « Top », « Prev », « Next », quand c'est pertinent.

2/8 DÉBUT PRÉC. SUIV. FIN SOMMAIRE INDEX GLOSSAIRE