LimitationsOfMailingLists

This document explores the idea of CommunityTiedToOneTechnology; here- mailing lists.

Mailing lists, like any communication technology, or medium, has affordances and limitations. See: TheMedium Thus, communities tied to a mailing list technology soley are limited by their tool.

Mailing Lists

Limitations

If subscribers do not use a mail client, they are sorely missing out on any functional advantages of mailing lists. But this also highlights the problem for people who are not subscribers, especially on active mailing lists…

LionKimbro observed that we can get stuck in one medium, because they are complicated: "Because to use a mailing list, you have to subscribe. You have to send back the little "are you who you say you are?" mail as well. Then you have to set up mail folder forwarding. And there are alllll these other little things you have to do as well, that make it a non-trivial option to just "post to the mailing list." …Because there are all these little barriers, these things that don't have technologies to help them work together, we find ourselves "stuck" in one medium, that has high integration within itself."

– some of the above quoted by HeatherJames from her own post on Online Facilitation at yahoogroups after wards there were some compelling defenses of the advantages of mailing lists.

Advantages

Discussion

Unorganized mess of complaints:

  • You can't make a hyperlink. I mean, you caaan, but then everyone'll shout, "HTML! Eeeevil!"
  • You can't just subscribe. You usually have to do some complicated, "I'm subscribing. Yes I'm really subscribing, now sent from the subscription address…"
  • You have to store all this mail. You have to set up a space in your incoming mail hierarchy to store the mail. You have to tell it "all from this email address" or "all with such-and-such in the subject line" or whatever. It lacks MetaData.
  • Unsubscribing is a (bleep!) as well. You can't just unsubscribe, you have to send back an email saying that you authorize the unsubscribe as well.
  • You can't just "ask a simple question. You can't ask a group a simple question, and track responses. Rather, you have to subscribe, (do all those things that it entails, such as setting up a space for the mailing list so that it doesn't bomb your normal mail,) then ask your question, then scan all of the messages, wait for the replies you are interested in, and then unsubscribe (going through all that process, and deleting the space and rules in your client.)

The "subscription" problem is not just a problem for e-mail, my intuition is telling me.

The answer to subscription, I feel, is integration; We need for your web browser (or it's future equivalent) to be able to tell your email client (or it's future equivalent) that a subscription request has just been made, and to authorize the check mail. (This is a theme we should probably go into more detail on in some other page… SubscriptionSecurityAutoLinking? or something like that.)

But longer term- I think- we need some sort of "use cases for e-mail." If we're going to replace mailing lists, we need to think out, "What are they good for right now? What are they bad for? What do we want them to be good for?"

I suspect we won't end up with one technology, but a bunch of interconnected technologies.

(So long, and not really the same as LimitationsOfMailingLists, that I've posted to a new page: MailingListsReplacement.)

I somehow feel that Gmane [1] is somehow answering some of your concerns, mainly by transforming a mailing list into a newsgroup. I didn't use this service a lot, but it provides archiving, a unified process for subscribing…go and see by yourself.

The "You can't make a hyperlink" argument is not so strong as a lot of mail clients are able to recognize url and make them clickable even in a plain-text e-mail.

I agree, and would also like to add that Gmane has a couple of things going for it except for the providing mailinglists as newsgroups. First, it has some spam filtering schemes, that makes Gmane even nicer to use than e.g. Usenet. Also, it has a pretty neat web interface that both lets you browse and post to the groups, even when you're away from your mailer.

Following a link on EmacsWiki, I've just discover that gmane now also proposes, besides a thread view, a blog interface to mailing lists and newsgroups. Including rss feed. See, for instance media wiki annoucement.

I realize that my position is unpopular, but I can't hold a position that I don't understand.

To my mind, being able to write out a URL in text, and click on it, is significantly different than being able to hyperlink text. Similarly with putting underscores around text, and actual italic.

The funny thing is, e-mail has the ability to handle hyperlink text. Just nobody wants to do it, because HTML is taboo in e-mail. For some reason, people believe that if you allow HTML in e-mail, then the natural result is blinking text, dancing hampsters, background images, and obease signature banners.

hmm, I admit I've never really thought about this except that it takes longer for a mail in HTML to appear in my client.

Rendering HTML is quite a huge task, if you include XHTML+CSS2 the only way to render an e-mail correctly is for the mail client to include the engine of one of the major browser or to open every mail in a browser. On a mobile phone or on a console a e-mail might be difficult. Yet a more complex task could be to have an editor that is able to create html on say a mobile phone or on a tv set top box.

So I don't think that html is a good standard for e-mail, and as a result I don't think that to send "non-standard" e-mails, using html, to a lot of unknown people (a mailling list) is a good thing, though nothing prevent you to communicate with your friend or co-workers using html or word documents when you know that they will be able to read your message. (if you think "why people don't use word to write e-mail?" is perhaps a way to understand what I try to say)

On the other hand, I admit that plaintext messages though very simple and universal are very poor. A solution to this might be a wiki like syntax, that is still easily readable in source form, easy to write even with a plain text editor but can be render easily, does provides hypertext, does not introduce a big overhead etc.. Moreover I think that having this kind of standard as a RFC, w3c standard (or PICA ;-)) would be a great thing for internet users because, today, there are 30 different syntaxs for wikis, 30 used in forums, plus one for each person writing plain text emails that uses one trick or another trying to send a good looking e-mail.

To resume, in my opinion, e-mails need to be in a standard format, html is perhaps not the best choice, wiki-like syntax could be a good choice and having such a standard would benefit to forum users, mailing list archives, wikis forums……

There have already been attempts at "standards" for plaintext e-mail markup. Cf. SeText. Such standards are usually not widely adopted outside of particular groups, or users of specific tools - e.g. e-mail newsletters or news distribution services.

Another attempted specification that was at least documented in an RFC is the `text/enriched` content type. This was specifically intended for use in email, in the same way that HTML email is used today. I know at least one mailer implemented it, but I'm not sure how many more did. The problem is that a constrained language is desired to make the content accessible easily. Spinning data off to a browser can cause all sorts of problems; while avoidable, it requires that specifications be implemented carefully, and HTML has always been plagued with problems in that arena. --FredDrake

Define external redirect: SocialNorm SubscriptionSecurityAutoLinking

EditNearLinks: EmacsWiki SeText

Languages: