Journal Thread Arcs

Posté par  (site web personnel) .
Étiquettes : aucune
0
12
août
2004
On entends souvent que les LL n'innovent pas ... et bien voilà une nouveauté très intéressante qu'offrira la prochaine release de GNUMail, la représentation des "threads" de message avec des arcs... Et en plus c'est joli !

http://www.roard.com/screenshots/gnumail-threadarcs.png(...)

Le concept des threads arcs vient de chercheurs de chez IBM (voir http://www.research.ibm.com/remail/threadarcs.html(...)), mais à ma connaissance GNUMail est le premier lecteur de mail qui l'implèmente (au moins dans le libre... je serais d'ailleurs curieux si quelqu'un connait d'autres implémentations !)

Un clic sur un node du thread permet d'accéder au mail en question, les arcs ont une hauteur contrainte dans la visu intégrée au mail et non-contrainte dans l'inspecteur (que l'on peut redimensionner à loisir). Franchement, c'est une visualisation bien plus sympa et pratique que le traditionnel treeview ...

Bref, que du bon. Merci à andreas et à ludo pour leur travail !

  • # hum

    Posté par  (site web personnel) . Évalué à 1.

    en tous cas avec le contenu de ton journal et le screenshot, j'ai rien compris.

    • [^] # Re: hum

      Posté par  (site web personnel) . Évalué à 4.

      bon je me réponds à moi-même pour ceux qui souhaitent comprendre. voilà ce qu'il me semble avoir fini par comprendre :

      - chaque point représente un article
      - chaque arc représente un lien "message - réponse" entre deux articles
      - l'arc bleu à gauche du point bleu central montre la filiation de l'article concerné (à quel article cet article répond)
      - les arcs bleus à droit du point bleu central montrent les réponses à l'article concerné

      perso je trouve que :

      - c'est fouilli et peu clair (peut-être une histoire d'habitude)
      - le fait qu'il y ait des arcs au dessus et au dessous de l'axe des points représentant les articles est confusant (ça n'a pas de signification, si j'ai bien compris : un arc supérieur n'est pas différent par essence d'un arc inférieur)
      - le fait que les arcs soient plus ou moins longs est confusant (ça matérialise le temps entre les deux articles il me semble ; mais ce n'est pas important dans le thread, alors que visuellement ça donne de l'importance à ceux qui ont un temps important de réponse)
      - l'avantage par rapport aux arbres me semble peu évident

      d'ailleurs tu ne donnes aucun argument en faveur de ce truc ?

      et puisqu'on parle de qq chose inventé chez ibm, il doit bien y avoir des brevets là-dessus qui trainent :/

      • [^] # Re: hum

        Posté par  (site web personnel) . Évalué à 3.

        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.

        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 "

        • [^] # Re: hum

          Posté par  (site web personnel) . Évalué à 2.

          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.
          Tu vois des relations avec des points, faire le lien avec les messages ne me parait pas trivial.

          • [^] # Re: hum

            Posté par  (site web personnel) . Évalué à 1.

            bah, vu qu'il suffit de cliquer sur un point pour obtenir le message... je pense qu'on fait vite le lien :)

            • [^] # Re: hum

              Posté par  (site web personnel) . Évalué à 2.

              Bof, ca veut dire qu'il faut retourner cliquer sur plusieurs pour s'y retrouver quand on recoit un nouveau mail dans le thread 2 jours après. Avec une vue des sujets + auteurs en arboresence on retrouve tout de suite.

          • [^] # Re: hum

            Posté par  (site web personnel) . Évalué à 2.

            D'ailleurs, pour le ca monte mieux en charge http://sophos.ca/~ludovic/mailbox_inspector_7.png(...) me laisse penser que au contraire ca n'est plus utilisable des que ca se complique

            • [^] # Re: hum

              Posté par  (site web personnel) . Évalué à 4.

              C'est pour ça qu'il y a la possibilité d'avoir la hauteur des arcs contrainte... de toute façon, je doute qu'un treeview soit bien plus pratique avec ce thread là ! :-)

              Sinon pour le côté "on repère mieux avec le nom de l'auteur et le sujet", rien n'empêche d'avoir une bulle d'aide l'indiquant (mais bon, ça n'y est pas pour le moment sur gnumail).

              Enfin tout ce que je peux dire, c'est que l'utilisant, je trouve ça effectivement plus pratique que le treeview traditionnel. Libre à vous de tester.

      • [^] # Re: hum

        Posté par  . Évalué à 4.

        > - le fait que les arcs soient plus ou moins longs est confusant

        Je suis bien d'accord. En termes d'information, le seul apport de cette représentation est le respect de la chronologie de gauche à droite. Mais justement, il prend visuellement une place primordiale (influence sur la taille des arcs et l'entrelacement des branches), alors que dans une conversation correctement menée, ça n'est pas censé être un élément nécéssaire à la compréhension (tu as juste éventuellement besoin de la chronologie entre les fils d'un même n½ud, mais ça le treeview le donnait déjà).

        > - l'avantage par rapport aux arbres me semble peu évident

        Bah en l'occurence c'est toujours un arbre, sauf que ça se voit plus difficilement.

        L'avantage de la stabilité à mesure qu'on ajoute des n½uds ne me semble pas primordial : dans un treeview, il y a aussi une forme de stabilité, la seule évolution étant l'écart entre les branches qui grandit petit à petit. Mais surtout, là, des opérations aussi simple que la dissimulation d'une branche feraient complètement changer l'apparence de l'arbre, alors que ça n'est pas le cas dans un treeview (les autres branches ne sont pas affectées).

        Quand aux traitement et autres colorations, je ne vois pas en quoi ça les facilite : la structure de données est la même, et ils sont applicables aussi sur un treeview.

        Bref, je comprends pas bien non plus l'intérêt.

      • [^] # Re: hum

        Posté par  . Évalué à 1.

        confusant ? Je ne connaissais pas cet anglicisme ;-)
        Je trouve ça plutôt déroutant

    • [^] # Re: hum

      Posté par  (site web personnel) . Évalué à 3.

      Hm... Tu recoit des mails au fur et a mesure, classes par exemple par leur date d'arrivee (cas le plus probable). Parfait. Mais si tu "discute" par mail, tu vas avoir une serie de messages disperses (car par exemple d'autre mails sont arrives entre temps...).

      Une solution est de faire alors un classement par sujet... Par exemple avec mutt: http://www.jhweiss.de/img/mutt_index.png(...)
      Et tu represente les relations entre les mails (qui a repondu a qui) par un arbre.

      Le probleme c'est que si tu restes dans cette config, quand un nouveau mail arrive il n'est pas forcement visible de suite a l'ecran (car le classement est forcement different...). Donc la plupart des gens fonctionnent avec le classement par date; mais n'empech, avoir la visu arborescente est parfois bien pratique.

      Les threadarcs permettent d'avoir cette visualisation, de facon plus efficace que le traditionnel arbre vertical (a la mutt), et de plus on peut continuer a avoir le classement par date (ou n'importe lequel) en plus.
      Bref, on visualise bien mieux la conversation, et c'est plus efficace pour naviguer dedans.

      Bien evidemment c'est surtout utile pour de longues conversations, souvent le cas si tu est abonne a des mailing-lists.

  • # MacSoup

    Posté par  (site web personnel) . Évalué à 5.

    Perso, je préfère la vue à la MacSoup (newsreader pour mac):
    http://news.cis.dfn.de/images/screenshots/soup0250.gif(...)

    Le treeview remplit quand même bien son rôle je trouve.

  • # autres implémentations

    Posté par  . Évalué à 1.

    Le concept des threads arcs vient de chercheurs de chez IBM (voir http://www.research.ibm.com/remail/threadarcs.html(...(...))), mais à ma connaissance GNUMail est le premier lecteur de mail qui l'implèmente (au moins dans le libre... je serais d'ailleurs curieux si quelqu'un connait d'autres implémentations !)

    En googlant un peu je suis tombé là dessus:

    http://toby.sourceforge.net/(...)

    un mua qui stocke les mails dans une db mysql
    (les scrinechottes sont antérieurs à l'implémentation des thread arcs)

    et un module perl pour générer l'image des thread arcs:

    http://search.cpan.org/~rclamp/Mail-Thread-Arc-0.21/lib/Mail/Thread(...)
    exemples d'images produites: http://unixbeard.net/~richardc/mta/(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.