On Thu, Jun 18, 1998 at 09:25:16PM -0700, Chuq Von Rospach wrote:
> At 6:55 AM -0700 6/18/98, Rich Kulawiec wrote:
> > Hmmm. That's 9 addresses per mailing list, which is going to mean
> > a heck of a lot of aliases for sites that operate hundreds of mailing lists.
> So? Is the idea a system easy for the user? Or the administrator?
> my mail list setup uses an average of 23 aliases per list (including
> the -digest paired list). Some are admin or interface aliases.
I must be missing the obvious: to me, this sounds like as much or
more complexity than having a single address to which (to pick
a number) 23 different commands can be sent.
> > I'm not sure I see why this is a win over a single address for
> > list administration to which directives are sent.
> Two ways. First, it makes interfacing from a web site a LOT easier,
> since you can pretty easily write an interface that goes to
> list-subscribe/list-unsubscribe and save yourself a lot of custom
> hacking to make things work.
I can do that anyway:
echo "subscribe" | mail foobar-request @
or the equivalent will have the same result. Again, am I missing
> Second, you can simply embed the
> list-unsubscribe address into your messages to make it as painfully
> easy as you can for users to deal with your lists. Because with
> list-subscribe and list-unsubscribe, they dont' need ANY memorized mail
> list commands. and users, I've found, appreciate that.
They *still* have to know list-subscribe and list-unsubscribe!
My experience has been that lots and lots users can't cope with
anything you do. You can put the list information in boilerplate
at the bottom of every message; you can embed some of it in X-headers;
you can send out one-a-week reminds of list admin functions; you can
do all of them.
They will still send "unsubscribe" messages to the entire list.
I see them every day, far too many times a day.
IMHO, and this is entirely based on anecdotal evidence gathered
by running a number of mailing lists and being on a heck of a lot
of others, much confusion results because there are so many ways
for people to get on and off mailing lists. What they learn by
working with the first mailing list they join, which uses, say,
smartlist, doesn't help them as much as it might, if their next
list uses listproc. And so on.
I'm partially aware of why this has happened, but that doesn't
mean I like it -- any more than I'd like it if people implemented
FTP servers with a dozen different ways of specifying "get"
(as "fetch", "retrieve", "transfer", etc.)
Users are confused because there are too many choices, and additional
experience simply gives them more choices and more confusion.
We don't need a bazillion ways of getting on and off mailing lists:
we need one. One that works regardless of what's handling the list,
and one that's available via mail. (To me, requiring people to
use the web to subscribe/unsubscribe is like requiring them to
use the TV to order telephone service.)
I care much less about what the one method is than the principle
that there should be one. Getting on and off mailing lists should
not have to be a complex issue -- but unfortunately, right now,
it sure seems to be.