This page started as a translation of LimitationsOfMailingLists
Ce document explore l’idée d’une CommunautéLiéeAUneTechnologie ; ici- les listes de diffusion par courrier électronique.
Les listes de diffusion par courriels, comme toute technologie de communication, ou tout médium, ont des affordances et des limites. Voir : LeMédium. De ce fait les communautés liées seulement à une liste de diffusion sont limitées par leur outil.
Si les abonnés n’utilisent pas un client de courrier électronique, ils oublieront complètement tous les avantages fonctionnels des listes de diffusion. Mais ceci fait aussi ressurgir le problème des personnes qui ne sont pas abonnées, tout spécialement sur les listes de diffusion active…
LionKimbro a observé que nous pouvons être embourbés dans un médium, tout spécialement parce qu’ils sont compliqués : “Parce que pour utiliser une liste de diffusion, vous devez vous abonner. Vous devez ainsi envoyer le petit mail “êtes vous bien ce que vous prétendez être ?”. Puis vous devez régler votre réexpédition de mail dans un dossier. Et il y a encore toooooouuuus ces petites choses que vous devez faire par ailleurs, qui en font une option non triviale pour simplement “poster vers la liste de diffusion”…. parce que toutes ces petites barrières, ces choses qui n’ont pas de technologies pour les aider à fonctionner ensemble, nous nous retrouvons coincés dans un médium, qui a une haute intégration à l’intérieur de lui-même.”
– quelques-uns des arguments ci-dessus cités par HeatherJames sont extraits de son propre billet sur Online Facilitation at yahoogroups après quoi il y a eu quelques discussions persuasives sur la défense des avantages des listes de diffusion.
LangueFrançaise PageTranslation LimitationsOfMailingLists
Fouillis inorganisé de plaintes :
Le problème de “l’abonnement” n’est pas simplement un problème pour l’e-mail, mon intuition me dit.
La réponse à l’abonnement, je pressens, est l’intégration ; nous avons besoin de votre navigateur web (ou de son futur équivalent) pour pouvoir dire à votre client email (ou son futur équivalent) qu’une requête d’abonnement a été simplement faite et pour autoriser la vérification du mail. (C’est un thème que nous devrions probablement étudier plus en détail sur une autre page… SubscriptionSecurityAutoLinking? ou quelque chose comme ça.)
Mais à plus long terme -Je pense- que nous aurons besoin d’une sorte de “use cases for e-mail.” Si nous allons vers le remplacement des listes de diffusion, nous avons besoin de réfléchir à “Quel sont les avantages ? Quels sont les inconvénients ? A quoi voulons nous qu’ils soient bons pour faire quoi ?”
Je soupçonne que nous n’en finirons pas avec une technologie mais avec un jeu de technologies interconnectées.
(Salut, et pas vraiment la même chose que les LimitesDesListesDeDiffusion, j’ai posté sur une nouvelle page : RemplacementListesDeDiffusion?1.)
Je pressens en quelque sorte que Gmane [1] est en train de répondre à quelques-uns de vos problèmes, principalement par le fait de tranformer une liste de diffusion en un newsgroup. Je n’ai pas beaucoup utilisé ce service, mais il fournit de l’archivage, un processus unifié pour s’abonner… allez-y et voyez vous-même.
L’argument “Vous ne pouvez pas produire un hyperlien” n’est pas si solide parce que beaucoup de clients mail sont capables de reconnaître les url et de les rendre cliquables même dans un e-mail plein-texte.
Je suis d’accord, et aimerait aussi ajouter que Gmane a deux choses pour cela mis à part pour la fourniture de listes de diffusion en tant que newsgroups. D’abord, il a quelques programmes de filtrage de spam, qui font que Gmane est même plus joli que d’utiliser par ex. Usenet. Il a aussi une vraiment belle interface qui vous laisse naviguer et poster vers les groupes, même si vous êtes éloignés de votre client mail.
En suivant un lien sur EmacsWiki, je viens simplement de découvrir que gmane propose maintenant aussi, à côté de la vue en mode fil, une interface de blog vers des listes de diffusion et les newsgroups. Comprenant un fil rss. Regardez par exemple, l'annonce media wiki.
J’ai bien conscience que mon opinion n’est pas populaire, mais je ne peux pas tenir une opinion que je ne comprends pas.
Selon moi, être capable d’écrire un URL dans un texte et cliquer dessus, est radicalement différent que d’être capable d’hyperlier du texte. De la même façon pour mettre des soulignés sous le texte et un véritable italique.
La chose amusante est que, l’e-mail a la capacité de gérer le lien hypertexte. Simplement personne ne veut le faire, parce que le HTML est tabou dans l’e-mail. Pour quelque raison, les personnes croient que si vous autorisez le HTML dans l’e-mail, alors le résultat naturel est du texte clignotant, des hamsters qui dansent, des images d’arrière-plan et des bannières de signature obèses.
hmm, je dois admettre que je n’ai jamais pensé à ça excepté que cela prend plus de temps pour un mail en HTML d’apparaître dans mon client.
Rendre le HTML est une tâche vraiment énorme, si vous inculez XHTML+CSS2 la seule façon de restituer correctement un e-mal pour le client mail est d’inclure le moteur d’un navigateur réputé ou d’ouvrir chaque mail dans un navigateur. Sur un téléphone mobile ou une console un e-mail pourrait être très difficile. Encore une tâche plus complexe pourrait être d’avoir un éditeur capable de créer du html sur disons un téléphone mobile ou sur un set top box de télévision.
Ainsi, je ne pense pas que le html soit un bon standards pour l’e-mail, et comme résultat je ne pense pas qu’envoyer des e-mails “non-standards” en utilisant le html, vers beaucoup de personnes inconnus (une liste de diffusion) soit une bonne chose, bien que rien ne vous empêche de communiquer avec vos amis ou collègues en utilisant des e-mails html ou des documents word quand vous savez qu’ils pourront lire votre message. (si vous pensez “pourquoi les personnes n’utilisent pas word pour écrire un e-mail ?” c’est peut-être un moyen de comprendre ce que j’essaye de dire)
D’un autre côté, j’admets que les messages plein-texte bien que très simples et universels sont très pauvres. Une solution à cela serait un wiki comme syntaxe ce qui est encore facilement lisible en format source, facile à écrire même avec un éditeur plein-texte mais peut être restitué facilement, fournit vraiment de l’hypertexte, n’introduit vraiment pas de surcharge, etc.. En outre je pense qu’avoir cette sorte de standards comme une RFC, un standard w3c (ou PICA
) serait une grande chose pour les utilisateurs internet parce qu’aujourd’hui, il y a 30 syntaxes différentes pour les wikis, 30 utilisées dans le forums, plus une pour chaque pour chaque personne écrivant des e-mails en plein-texte qui utilisent un truc ou un autre pour essayer d’envoyer un e-mail de bonne facture.
Pour résumer, à mon avis, les emails ont besoin d’un format standard, html n’est peut-être pas le meilleur choix, la syntaxe ala wiki pourrait être un bon choix et disposer d’un tel standard bénéficierait aux utilisateurs de forums, aux archives de listes de diffusions, aux forums wikis…..
Il y a déjà eu des tentatives de “standards” pour la syntaxe e-mail plein-texte. Cf. SeText. De tels standards sont généralement largement adoptés à l’extérieur de groupes spécifiques, ou d’utilisateurs d’outils spécifiques - par ex. les newsletters par e-mail ou les services de distribution de nouvelles.
Define external redirect: RemplacementListesDeDiffusion NormeSociale SubscriptionSecurityAutoLinking