
Examples of “Lazy Registration” - tortilla
http://webjackalope.com/lazy-registration/
======
jgilliam
It's not just about how long the signup form is, I believe it's simply the
language "account" or anything that connotes joining something. The form can
be three fields, and people still hate it.

The language "save my info for later", and versions of that, are much better.
It flips it around in the user's mind: "oh, now they're not asking me to give
something up, they're helping me out"

~~~
lucumo
_> The language "save my info for later", and versions of that, are much
better._

While I understand what you're saying, I believe that would trip me up. I'm
very much used to scanning for "Register", "Sign up", "Join" or "Create
account".

I'm also unsure how much people really hate giving up their information. If
anything, people are _looking_ for places to hand over their information:
Facebook, MySpace, LinkedIn, etc.

I think the problem is really that the more steps needed to convert your
users, the more likely it is a part will give up before the end.

~~~
c3o
At Soup.io (tumblelogging/lifestreaming) we initially had content creation
buttons right on the front page. We figured that the best first action for new
users would be to actually post something, not filling out a sign-up form.

But we had exactly the problem you're describing: People are so used to
scanning for "register"/"sign up" that some even assumed we were in invite-
only beta.

We eventually changed that to a "Try it now -- no sign up required" button,
which works better. The wording and UI is still tricky though: "Try it now",
"trial account" etc. carry the connotation that it'll cost something later.

We've been meaning to A/B test a straightforward sign-up form for a while and
measure effects on both conversion & retention, but unfortunately haven't
gotten around to it yet.

------
mattmaroon
Stack Overflow's registration is awful because it only supports OpenID, a
service that is spotty at best. I tried to ask a math question there and just
couldnt get it to log me in.

~~~
johns
That's your Open IDs provider's fault, not Stack Overflow's. Yeah, they may
suffer a little but not enough to be responsible for a shoddy provider. But
with how many providers are out there, it should be easy enough for you to use
another one.

~~~
dcurtis
No, it's Stack Overflow's fault for using such a terrible authentication
system. OpenID has pretty much proven itself to be a failure in user
experience.

Facebook Connect has accomplished most of the goals of OpenID, anyway. They
should use that instead.

~~~
sachmanb
This makes absolutely no sense to me. OpenID does not dictate anything about
the user experience. The site that is using OpenID places a log in textbox,
decorate as you wish, which takes you to your OpenId provider...which is the
experience you chose, given by the provider that you liked....

Facebook connect took off because of the site itself, how many people use it,
and people like those who constantly tell me that I should have Facebook
logins for my sites and apps (and no, I shouldn't).

so...

\- stop insulting openid unless you got a better idea that isn't proprietary

\- or if you cant think of a better solution than openid, help us get it out
there because it beats the old solutions, and we can at least start improving
until we can think of something better (i can't think of anything better...i
gave it a shot for an afternoon, its theory is sound, and its very flexible
and solves the problem just great)

~~~
dcurtis
OpenID is a horrible user experience because it forces the user to set up an
account externally to the site they want to visit. This is unintuitive,
potentially insecure, and annoying.

OpenID is worse in every way to an internal authentication system. The only
advantage is the mere dream of single sign-on, which has yet to come to
fruition.

------
Hexstream
"Really clever sites have even found a way to bypass the signup form
altogether. They slowly ask for data along the visitor’s path of discovery,
and pretty soon she’s a member of the site, without having to fill out a
form!"

Be careful with this, it can backfire. Sometimes you come across a cool site
that apparently doesn't require signup, then you spend some time creating
something, and then at the last minute you get a message: "Ok, now to actually
save your thing you just spent 10 minutes creating you JUST have to signup"...

It's so frustrating I usually just walk away in disgust. Don't pretend no
signup is needed to use a feature if it's not true.

------
sstrudeau
Luke Wroblewski's "Web Form Design"
<http://www.rosenfeldmedia.com/books/webforms/> makes this case well. He calls
it "gradual engagement." It's also one of the best books on a web design topic
I've ever read.

------
lucumo
I'd love to see some numbers on "Lazy Registration". How many users does it
save? How much effort goes into implementing it?

I've seen the idea before and I'm not really convinced. Sure, it sounds like a
great idea, but let me offer some thoughts.

1\. I have never been to 11 of the 12 sites mentioned in the article. Before I
read this article, I knew exactly one site where lazy registration is actually
practised: Stack Overflow. The idea has been floating around for some one or
two years now. It hasn't really catched on. To me this suggests that many
authors find it difficult to implement.

While difficulty in itself is not a problem, the time and effort invested in
something needs to pay off, and it needs to pay off more than investing it
into another feature. Opportunity costs apply here too.

2\. How many potential users really care about registration? Does a
"registration reddit-style" really put off that many people? In my experience,
people will just pick their normal username and mash a laughably simple
password into the appropriate box. There isn't much cognitive overhead there.
This will, in my opinion, really only be a problem to people who have never
registered an account before, anywhere.

Sure, you need to convince them that your product is useful. They won't
explore further if they aren't convinced that it may provide some value to
them. But it's probably a lot easier to put a tour on your website than to
implement lazy registration.

3\. If it does indeed give more users, do the extra users remain users for the
same amount of time, or do they switch more easily to competitors? What
happens to the users that you would've gotten with registration as well? Do
they switch more easily? It seems to me that that's a very real possibility.

Currently, my intuition tells me to just use a registration form if you need
it. In places where you don't need your users to be logged in, don't require
them to be. Just let them do as much as possible without an account, but I
wouldn't go for "unregistered accounts". That's too much effort for something
of which you don't know how it will turn out.

~~~
geeko
Sometimes it's not the fact that you have to sign up but the way registration
is done.

"people will just pick their normal username and mash a laughably simple
password into the appropriate box"

It's not as easy as it sounds.

1) My username might be taken 2) Often, I have to go to my email and activate
the account. 3) Entering and remembering a password is not as simple as it
sounds. New York Times is a good example on how not to do it:
<http://twitter.com/vpdn/status/1620213111> 4) Most of the time I don't see
why I have to sign up.

~~~
lucumo
The NYT is a site where registration is unnecessary[1]. Registration was
harder to do for them than it is to not have registration at all.

I was talking about situations where you store data on a user and link more
data to a user. Sure, you can do that using some kind of token in a cookie,
but if you want to give your users a name at least some of the time,
registration is easier. At that point "unregistered users" add more work.

Your other examples are more a problem with the way registration is
implemented, than with registration _per se_.

[1] From a technical point of view. It probably makes business sense to them,
although I'm unsure how.

~~~
patio11
_makes business sense to them_

It lets them publish a rate card which includes something to the effect of
"46% of our pageviews come from US zip codes with median household incomes in
excess of $80,000"

------
dcurtis
The best example of this is Posterous. You just email something to
post@posterous.com and you instantly have an account and a blog.

You can then just keep using it or you can add a password and "claim" it later
to get access to other features.

------
lawrence
This is a helpful article, but I think there's a difference between easing
someone towards a registration and not requiring a registration at all. Some
of the companies listed seem to be the latter.

------
tlrobinson
With 280slides.com you can create an entire presentation and export it to
PowerPoint and a number of other formats without ever registering. Only if you
want to save a document will it prompt you to login or register.

------
rmc00
I really agree that this approach of gradually engaging the customer is the
best way to go. The last thing a startup needs is to lose customers just
because they can't use the product without going through a ridiculously long
signup form.

It just makes sense: don't take the information until you need it. I found
another article on A List Apart that may of interest to people who liked this
article. <http://www.alistapart.com/articles/signupforms>

------
callmeed
Very good approach and something that I'd like to work toward in my projects
...

From a technical standpoint, what's the best way to tackle this? Let's say
you're using Rails or Django, you let a visitor create [some-widget] and then
ask if they'd like to register ... do you store a reference to the new [some-
widget] in a cookie until they do?

~~~
cstejerean
I would treat users that have not yet registered as closely as possible to
normal users. So create a user object in the database for them and keep track
of the last access date. You can either mark the account as temporary, or just
store an empty password and rely on that to identify accounts that are not
fully registered. You can purge inactive accounts after a certain number of
days. If it's only keyed by session ID then there's no point to keep this data
around past the session expiration date.

Then in a few places in your app you can check if you have the necessary
information on file for the current user acocunt, and prompt the user to enter
it if not (things like email address, a picture, real name, whatever it is you
need). When they finally select a password they become a normal user of the
site.

