Un des gros avantages de travailler à
l'IETF est qu'il existe un ensemble
d'outils de travail en groupe très perfectionnés, permettant de
gérer un grand nombre de documents qui changent tout le
temps. Dans la plupart des SDO, ou
organisations similaires, on a juste des piles de documents
Word (ou, dans les dernières années,
Google Docs) inexploitables. Comme le gros
du travail IETF est fait sur des listes de diffusion, un des outils les plus
cruciaux est le moteur de recherche dans
ces listes de diffusion. Mais aucun outil n'est parfait et
ce nouveau RFC est une liste de points à
améliorer dans l'outil actuel, liste fondée sur l'expérience récente.
Ce https://mailarchive.ietf.org/
L'outil actuel avait eu comme cahier des
charges le RFC 6778 et avait été
déployé en janvier 2014. Notre nouveau RFC
liste les améliorations souhaitées.
Par exemple, lorsqu'on choisit « Group by
Thread », la liste résultante est plate, sans
hiérarchie. Cela rend difficile de voir où un fil de discussion
commence et où il finit :
Notre RFC demande que, dans les améliorations de l'outil,
l'affichage montre la hiérarchie.
Autre problème, il n'y a pas actuellement de boutons de
navigation (message suivant/précédent par date, ou suivant le fil
de discussion), que cela soit dans la liste des messages affichés,
ou bien lorsqu'on regarde un seul message. Le RFC demande que ces boutons soient ajoutés.
C'est en lisant ce RFC que j'ai appris qu'on pouvait changer la
taille de la fenêtre où s'affiche la liste des messages. Je la
croyais fixe, et c'était apparemment le cas de bien des
utilisateurs. Le RFC demande donc qu'on rende cette possibilité
d'agrandissement plus évidente (personnellement, je n'ai pas trouvé). En prime, la façon dont est faite
la troncation aujourd'hui ne semble pas rationnelle. Ici, on voit
bien que les sujets sont coupés (et la fin remplacée par des
ellipses) sans vraiment de raison.
Le service actuel est difficile à utiliser sur un petit écran,
comme celui des phono sapiens puisque les
divers éléments de l'interface sont toujours présents. Pour une
interface riche, il vaudrait mieux être responsive, ce que demande le
RFC (par exemple, on pourrait supprimer le menu des filtres quand
l'écran est trop petit).
Par contre, sur des grands écrans, l'interface actuelle est au
contraire trop économe et sous-utilise l'écran.
Enfin, notre RFC regrette que l'interface actuelle ne marche
guère sans JavaScript. La prochaine version
doit évidemment être capable de fonctionner sans JavaScript,
quitte à accepter quelques fonctions en moins (comme les filtres
appliquées dynamiquement).
Reste à développer, maintenant... Je n'ai pas encore vu d'appel d'offres.
