|
Grex > Coop > #299: Discussion of newuser. | |
|
| Author |
Message |
cross
|
|
Discussion of newuser.
| 
Dec 1 23:00 UTC 2010 |
This item is for the discussion of newuser. What should it ask people for?
The following are pretty much required:
1) Login name.
2) "Real" name (they don't have to put in an actual name, but we need
something for the GECOS field in the password file)
3) Email address (so we can email them their password).
Right now, it asks for some other stuff and uses that to build the user's
.plan file: phone number, address, the type of computer you use, what you
do for a living, gender, birthdate, and what other interests you have.
None of this is necessary.
Actually, for legal reasons, we may *have* to ask for birthdate, but I'm
not a lawyer and not sure. But I remember that that was a thing a few
years back.
What else?
|
| 85 responses total. |
rcurl
|
|
response 1 of 85:
|
Dec 2 05:06 UTC 2010 |
Michigan nonprofit corporate law has no reqirement of members'
birthdates being recorded.
|
cross
|
|
response 2 of 85:
|
Dec 2 08:52 UTC 2010 |
At one point, there was a federal law requiring online services to ask for
users' birthdates, and if they were below 13 years old, verify that their
parents had given them permissions to get accounts. We just sort of punted
on that.
It has nothing to do with membership.
|
kentn
|
|
response 3 of 85:
|
Dec 2 13:55 UTC 2010 |
I'd like to see the web newuser be as simple as needed to set up a
working Unix account (username, password, "real" name, optional contact
information) that will allow web access, so that people can get an
account and get cracking without a lot of technical/confusing questions.
That web new user page should ideally fit on one normal screen. As long
as they only access Grex from the web, they should be okay and if we add
a few more web services they'll be even better off.
For the command line newuser, my assumption would be most people who
run that will expect it to be on the technical side. I'm sure it got
as complicated as it did due to all the issues new users had in days of
yore with terminal types, backspace key assignments, etc. That said,
I'm guessing there is an opportunity to simplify that program/process as
well(?)
Some people will want to register via the web and then use both command
line and web tools. In that case, we'll need to provide additional
assistance if things like their terminal and backspace aren't working.
Perhaps a script they could run (and a web page they could access) to
update their account settings would be a good idea to save staff time
(change shell, change "real" name, change backspace key assignment,
change password, etc.).
We do want people to learn about Unix, too, so technical questions would
be one of the hoops they need to jump through to get a useful command
line account. But we don't want it to be an onerous process nor do we
want it to be a dead end.
It would be good information for us to know how users got their
accounts, via the web or via the command line newuser program. That way
we could judge the popularity of each method and perhaps see a little of
how our user base is changing (if it is).
|
cross
|
|
response 4 of 85:
|
Dec 2 14:40 UTC 2010 |
I wouldn't expect anyone to be any more or less technical based on
how they create their account. Most services these days, even other
public access Unix services, only provide a web interface for account
creation. People are so used to it that it would be weird if they
didn't expect it; even most techno-dweebs would login to Grex's
newuser and sort of shrug and say, "oh wow; well, ok...."
I think one of the realities is that we don't need to bother with
backspace keys and terminal types and all the rest of that garbage.
For the most part, that's handled by whatever terminal emulator the
user uses, and whatever SSH clients are out there. Having us write
software to try and figure it out is probably just going to screw
people up. Gone are the days when someone only used one terminal,
and that terminal was a VT100 or Wyse 50 or Heathkit 19, and setting
these variables just complicates life for everyone; it's far better
to just run tset and have it do the right thing.
One thing I think is critical is that we should not make a big
distinction between "web" accounts and "command line" accounts.
When a user creates an account on Grex, regardless of whether they
use the command line newuser login or a web interface, they'll get
one account and it will be set up exactly the same. As I said in
the last paragraph, we don't need to ask about terminal types or
erase and kill characters and junk like that. For that matter, we
don't need to ask about shells or editors or any of the rest of
that sort of thing: give reasonable defaults and a way to change
and let users do what they want.
So yeah. Basically, minimalism in the account creation process
seems to be a universally agreed upon good thing.
So what "optional" information should we request?
|
kentn
|
|
response 5 of 85:
|
Dec 2 15:45 UTC 2010 |
The reason I was thinking information on how they got their account
was good is that we don't get enough information about how the system
is being used (including how people are finding Grex and getting their
accounts). We're often making decisions based on annecdotal evidence.
I'd like to avoid that, if possible.
It would be good, at least, to have the "registered" information like we
used to:
registered: Fri Jul 19 16:00:39 1991 on tty /dev/tty01 at speed 2400
Maybe we could add "www" or "command line" to that if it's not obvious
due to the tty. This information comes from the .plan file, though,
and not a gecos field, as far as I know.
If we can get this information without messing with newuser, then that's
fine, too.
|
nharmon
|
|
response 6 of 85:
|
Dec 2 16:20 UTC 2010 |
re 2: I think the law Dan was thinking about is the Children's Online
Privacy Protection Act.
http://www.ftc.gov/ogc/coppa1.htm
|
cross
|
|
response 7 of 85:
|
Dec 2 16:50 UTC 2010 |
resp:5 Newuser already tracks that sort of information and puts it
into the .plan file; it's just that all the recent users have decided
to keep their information hidden. So the registered information is
there, but private.
Similarly, that information is also logged into a file
(/var/log/newuser.log). General users can't read that file for
obvious reasons. New newuser logs the data in JSON format, which is
easy for tools to parse and manipulate. So we can write programs that
suck in the newuser log data and do all sorts of statistical analyses
on them; I agree that more of that and less anecdotal evidence is
generally a good thing.
Changing newuser is now easy, as the new newuser is much easier to
maintain than the old newuser. But I don't think it needs to be
changed for this as it already does what we're talking about.
resp:6 Yeah, that sounds like the one. Can anyone read this and see
if it applies to us? I kind of think that it doesn't, as we don't
collect information for "commercial" purposes, and it seems to
specifically exempt non-profit organizations, but I am now a lawyer
and all that.
|
kentn
|
|
response 8 of 85:
|
Dec 2 16:55 UTC 2010 |
There was a line in there about not applying to nonprofits as defined
in some FTC rule, so we'd need track back a little farther to see if
a 501C3 is considered exempt from being an "operator" under that law.
IANAL either.
|
cross
|
|
response 9 of 85:
|
Dec 2 17:07 UTC 2010 |
I think that point would drive whether we *have* to ask for birthdate
or not (and, presumably, newuser would have to do something if the
potential user was under 13 years old).
|
veek
|
|
response 10 of 85:
|
Dec 2 17:37 UTC 2010 |
We could slurp personal info when we need to populate .plan and the
users home-page, and leave it out of account creation.
Instead of asking for info directly, do it indirectly - show the user a
snazzy web-template with pics and links to facebook and a wall and nice
resume etc of some template user, and ask him if he'd like to create
something similar.. there are classes of users:
1. kids in school
2. kids in college
3. kids just out of college (in technical fields, arts. etc)
4. working ppl with hobbies
5. hacker types
??
(so we'll need a good web-template for each.. something like Facebook
or hyves.nl or bebo - but much more elegant, clean and personalized)
|
cross
|
|
response 11 of 85:
|
Dec 2 19:18 UTC 2010 |
Sounds really overly complex.
|
rcurl
|
|
response 12 of 85:
|
Dec 2 19:39 UTC 2010 |
How would all that information be used?
|
cross
|
|
response 13 of 85:
|
Dec 2 19:44 UTC 2010 |
resp:12 What information are you referring to, specifically? Right
now, the stuff we ask for get's put into the user's .plan file. Well,
the email address gets used to email the user their new password. The
only other real use is for resetting passwords if the user forgets:
traditionally, this was done via an emailed request; if the user's
plan is private, but has information that could be used to verify the
user's identity in it, then staff could look at that and ask the user
a question based on it to get at least some idea that they are who
they say they are. Of course, if the request comes from the email
address the user used to register, then that's not really necessary.
|
kentn
|
|
response 14 of 85:
|
Dec 2 23:35 UTC 2010 |
I'd rather we didn't complicate this newuser process. It's not about
how much information we can collect or about customizing the information
we collect. It's about collecting less information and making the
process of creating an account simpler and faster.
In my opinion, if we do ask for optional information, it's good if we
do it directly. Then people can ignore what they don't want to have
appearing on their accounts.
|
veek
|
|
response 15 of 85:
|
Dec 3 00:27 UTC 2010 |
resp:12 nope, darn - me unclear:
1. Strip newuser to the barest minimum.
2. If the user decides to do the mkhomepage/mkplan routine, then ask him
for stuff - meanwhile highlight the cool home-pages bit in motd and on
the site
|