la hauteur des arcs et le fait que ca passe au dessus ou au dessous n'est pas determinant -- c'est juste pour alleger la representation.
Fouilli et peu clair, ca depends -- le screenshot a ete pris expres lors d'une conversation assez chargee -- mais il faut surtout comparer au systeme plus classique de treeview. Et la, c'est effectivement plus clair/compact/efficace que si on avait utilise une treeview.
Par rapport a une representation arborescente, c'est plus compact, ca monte mieux en charge, la position des nodes ne bouge pas si on ajoute de nouveaux messages (stabilite) et on voit mieux les relations entre messages.
Le gros interet c'est qu'il est tres simple de faire des traitements par dessus ensuite -- on peut tout a fait imaginer d'utiliser des couleurs differentes pour visualiser par exemple les differents protagonistes, etc. L'inspecteur de GNUMail pourra justement servir a jouer sur ces parametres.
[^] # Re: hum
Posté par Nicolas Roard . En réponse au journal Thread Arcs. Évalué à 3.
Fouilli et peu clair, ca depends -- le screenshot a ete pris expres lors d'une conversation assez chargee -- mais il faut surtout comparer au systeme plus classique de treeview. Et la, c'est effectivement plus clair/compact/efficace que si on avait utilise une treeview.
Par rapport a une representation arborescente, c'est plus compact, ca monte mieux en charge, la position des nodes ne bouge pas si on ajoute de nouveaux messages (stabilite) et on voit mieux les relations entre messages.
Le gros interet c'est qu'il est tres simple de faire des traitements par dessus ensuite -- on peut tout a fait imaginer d'utiliser des couleurs differentes pour visualiser par exemple les differents protagonistes, etc. L'inspecteur de GNUMail pourra justement servir a jouer sur ces parametres.
Le papier d'IBM est tres interessant a lire pour explorer le pourquoi du comment et les possibilites : http://www.research.ibm.com/remail/publications.html(...) , " THREAD ARCS: An Email Thread Visualization "