>>>>> "BR" == Brock Rozen <brozen@torah.org> writes:
>> Well, yeah, but my question was about whether or not they get "welcome
>> to $list" and "you've just registered" messages (which seems like quite
>> a bombardment, seeing as how they didn't ask to be registered to
>> anything).
BR> Yes, they should -- since they really have been registered.
But that's just a detail of how things are stored; why should they care
what the internal database structure looks like? All they did was join a
list.
BR> Sure, if we don't want people to be aware of registration and make a
BR> use of it.
What use can they make of it? All it buys them is single-password access.
The real benefits go to the code and the site owner.
BR> You realize that you're basically burying registration under the
BR> carpet.
Yes, precisely. People don't want to learn yet another command to
manipulate their 'registration', they just want to join lists. Why
complicate that?
Registration really makes very little sense from the point of an email
interface; the only useful thing is the use of the password to bypass
confirmation. It makes _much_ more sense from the standpoint of a web
interface where they sign up for access and once in the front door have
everything done without the use of email.
BR> While I was never of the opinion that somebody should be registered
BR> unless they're subscribed to a list, now you're even "hiding" that
BR> option.
How is the option being hidden? By not telling someone that they've
exercised it implicitly? I'm just trying to simplify things for the user
as much as possible. The fewer messages and less documentation they have
to deal with, the better. And most of the users are only ever going to
find the password useful for one thing: removing themselves from the list.
(Outside of the hypothetical web interface, that is.)
The only difference that a 'join one list' user is going to see is the
following lines:
If you ever want to remove yourself from this mailing list,
send the following command in email to
$REQUEST:
approve $PASSWORD unsubscribe $USER
which works no matter what their address is. Whee.
In any case, I have it mostly working. There are still some problems but
the kinks are being worked out. We can try it out a bit and if it ends up
that I'm wrong and the method I'm using sucks then we can work on another
way of doing it.
- J<
Follow-Ups:
References:
|
|
