[thesite] the new author box

[rudy]

>| when, oh, when will we be ready to work on the member pages?
>
>NOW!!!!  :)
>
>Seriously .. can we work on them while the redesign is being done?

sure we can

here, i'll start the ball rolling (and i'll gladly take ownership and track
the details on this one)

we should first establish
~ what's the difference between a user and a member
~ how would current user data map onto a member-user structure

as a bit of background (but only a bit, since we shouldn't have to dig into
the archives, we know this stuff, anybody on this list does), we are
dealing with the likelihood, nay, the reality, of multiple "userids" per
actual real person -- e.g. home and work email ids

a person with both home and work ids, who posts to thelist regularly from
either of them, has two identities in the list archives

if the archive data were ever integrated with other user data.... wait a
second! they already are, in the tip harvester! -- then it would be nice if
both email ids were associated with the same "person" in the database

viewed in the other direction, you would not want authors to have to fill
out more than one of those new author bios we just introduced (never mind
for the moment that it is site loginid and not list emailid that identifies
article authors)

jeff, i'm afraid i have to disagree with another comment of yours --

> it's as simple as logging in and changing your email address, eh?

would that it were that simple, but this assumes only one email id per
person

okay, so big deal (i can almost hear the rebuttal now), what if we had an
adjunct "alternate/additional email id" table to hold the spillover --
after all, most users have only one email id and so the number of extra
rows in the adjunct table would be very low, and of course you'd need outer
joins, but then you'd also need an admin script to manage the adjunct email
ids....

as you can see, the implications are interesting, and tempting to think
about now (especially for the predominantly left-brained among us), but the
particular implementation strategy is immaterial until after a couple of
basic agreements are reached --

~ what's the difference between a user and a member
~ how would current user data map onto a member-user structure

"member" in this context should now be taken to mean all that good data
that we maintain about the "real person" that i talked about

unfortunately, common parlance all too often associates the word "user"
with the word "person"

the word "member" was chosen to make a stronger cognitive association to
actual people, allowing "user" to remain associated with "userid" at the
same level as "emailid"

if this terminology confuses, we need to clear this up before anything else


rudy