
People (understandably) hate to register - jbogp
http://nospronos.com/en/blog/people-hate-to-register
======
csbrooks
It's unfortunate that signing up via Facebook or twitter or some other OAuth
method gives people such a creepy feeling. It sure is a lot more convenient
for everyone involved: don't need a password, no email confirmation, sometimes
it's one click and you're in.

I feel like Facebook screwed this up for everyone when people's feeds were
covered with apps their friends were using. Now when a site asks you to
authorize it with facebook, users don't feel like they can trust what it's
going to do.

~~~
Piskvorrr
Creepy feeling. Well guess what: apparently something that you say on FB which
_any_ one finds offensive can lead to your FB account being disabled, without
warning or official way to appeal.

Now tell me again, how convenient is this global login that can at any time
disappear from under your feet?

~~~
tehwebguy
Is that common? It seems like it is in the same neighborhood of likelihood as
losing your Gmail account for cause.

~~~
Piskvorrr
GMail is mostly used for e-mail, which is something of a private conversation
between (usually two) people. Facebook posts are quite the contrary: public,
visible to the world at large, _plus_ the users are actively encouraged to
flag items they dislike. Now don't get me wrong: this is quite necessary for a
_social network_ \- but using the same social network as the Universal Login
For Everything is where this very feature becomes the SPOF.

Also, whereas GMail is not inclined to police the morality of its users, FB
is. Not the same as data-mining, not the same as "legality" \- for example,
you have repeatedly used a word that FB retroactively considers a bannable
offense, say goodbye to your account; or you have, a long time ago, posted
pictures that are considered indecent under the new rules; or enough other
users maliciously coordinate to flag an innocuous item of yours - and the
banhammer falls automatically.

Moreover, GMail != e-mail: you are completely free to register with _any_ of
the bazillion e-mail providers, there is no need to use GMail; as for
Facebook, there is only one.

------
mcv
I wholeheartedly agree! At the time of the Adobe password leak, I was
surprised to find that I had an account there. I'm not a heavy Adobe user, and
certainly not a paying customer. So why did I have an account? I suspect I had
to create one at some point simply to be able to download something for free.
Requiring registration for something that's free is totally unnecessary. Now
they had my password for something that didn't need one, and by leaking it,
they leaked the password I also used on other sites that shouldn't need a
password.

There's a popular Dutch site, datumprikker.nl (date picker) that works exactly
like the author describes. No need for accounts; just a link and you fill in
only the stuff that's actually necessary for the service to work. It's very
popular for a reason: no hassle, easy to use, nobody has to register or sign
up.

~~~
annnnd
Just use mailcatch.com - you enter whatever@mailcatch.com as your e-mail, then
check [http://whatever.mailcatch.com/](http://whatever.mailcatch.com/) to see
your "inbox". Great stuff. Of course, this is only applicable if you don't
care who uses the newly created account (because all such e-mail is public).

------
JulianMorrison
Website creators seem to not understand that when we register, we are giving
them something of serious value - we are giving up our privacy. And I do not
give that to strangers in exchange for nothing.

~~~
mtdewcmu
You don't necessarily lose privacy by making up a username and password for a
site. You do lose some privacy if you use social sign-on or the site requires
you to provide an email address that's verified.

My pet peeve is the arbitrary rules that sites now have for passwords. When I
am registering for something I don't care much about just because I have to,
my inclination is to use the same easy-to-remember password I always use. But
the rules thwart this, and no two sites can agree on the same rules, thus
forcing me to alter the password, and guaranteeing that I will not remember
it.

~~~
vdaniuk
Ah, yes, one easy-to-remember password for large number of sites is definitely
a great way to protect your security. /s

Complaining about loss of privacy, but eagerly weakening your security for
convenience. I don't understand this argument at all.

~~~
stcredzero
I am amazed that you're downvoted, and so many replies are from people who
don't think 2 steps ahead and who understand the consequences of their actions
in aggregate! The compsci comprehension level around here appears to have gone
down from competent programmer/tech savvy to...I don't want to say...

~~~
PeterisP
Let me explain to this viewpoint in more detail - I have a rather clear
picture for the scenario where "one easy-to-remember password for large number
of sites" is the proper action to take.

Thre are a lot of sites that want me to have "an account" so that I can do
action X. That includes nearly all my passwords in my password manager. For
every account that I want to be secure (say, my email) there are ten accounts
that I don't want to have. If I want to do X, I don't want to have an account.
"Having an account" is a cost - I have to remember the account's data (even
the bit 'do I have an account on fancysite.com?' is a cost). If I have to have
an account, I have no need for the account to be mine and mine only. If I have
to have an account for me specifically, I have no need for it to be protected
from others; but I do need to remember it easily - to avoid the inconvenience
of creating a new account.

The site owners often make very different policies, for reasons that benefit
them - but they are often opposite to the user needs. All the security
problems related to the accounts are the fault of those people who required
"an account" in the first place - the Adobe breach is a good example, none of
those accounts shouldn't have existed in the first place; none of those people
should have been asked their emails; none of those people should have been
asked to choose a password. The stricter password requirements Adobe would
have made - the worse that would harm the actually important accounts. The
sole fact of Adobe asking large number of people for their email address and
asking to 'choose a password' \- that's a hostile attack that harms mass
security on the internet (as the consequences of that breach); we should
actively subvert such policies. If a site asks you for an identity more than
actually needed (i.e., if they need to ship stuff then they need an address)
or asks you for more authentification stuff (choosing passwords, security
questions, etc) than __you __need, then that 's [security-wise] hostile to
you; if you like that site you can suffer through that but you should do the
absolute minimum that fits their policies.

Ignoring client-side tools that hide the complexity, let's list some
reasonable possibilities for user authentification for the actual accounts
(where I explicitly don't care about others getting access to __that __account
but I care about protecting other accounts) sorting them by ease of use (i.e.,
how _I_ would like to 'log in' to the site), more preferred options first.

1\. No identification or authentification at all. For many scenarios that's
the optimum that we'd like to have, but it's prohibited by the site operators,
so we're forced to go 'downwards'. #1 on ease of use; #1 on security (no risk
to be a proxy for attacks on important accounts), #1 on privacy.

2\. Arbitrary identification with no authentification - i.e., I pick a
name/tag, and that gets used as a semi-unique handle. This allows semi-
personalized communication (i.e., distinguish multiple commenters) or some
persistence of data. For some scenarios, e.g., most of online commenting this
is the optimal point. On some sites I'd want to 'build a reputation' by having
a handle that's unique to me; but on _most_ of them the hassle of remembering
an account name is larger than this benefit, so I'd prefer to post with an
unauthentificated pseudonym. This again is often prohibited, so we're forced
to go 'downwards' or to not use such sites - all the next options are just
drawbacks that users choose to take in order to gain access.

3\. Authentification without identification - publicly available login data,
such as the BugMeNot system. This attempts to go to the goal (#1) by sharing
data, but again, those accounts often get prohibited by the operators, forcing
us to worse measures further down the list.

4\. Username/password - optimizing for ease of remembering. That would ideally
be a single username and a single password for everything - i.e., the best
password was no password (#3), the next best password is a single, simple,
short password such as "password". Again, that doesn't work because [some]
site owners have expressly prohibited it, so the next best option is a single,
simple, semi-short password with a number of special characters such as
"Tr0ub4dor&3" \- so that it could actually be _single_ and fit policies of a
majority of sites. This approach sucks security-wise, as you note - however,
the major security flaw for this is actually not the weakness of passwords,
but the weakness of usernames - since the authentification doesn't matter for
those sites, but this approach leaks and connects identities, which is bad on
principle. However, without moving to things such as password managers which
wouldn't work when you sit down on a random untrusted computer, I'm not aware
of any better options that don't have this flaw; if there are multiple
usernames/passwords, then _something_ needs to remember them; and that
something itself needs to be accessible with very easy-to-remember (and most
likely completely insecure) settings.

5\. "Classic" system of not-the-same IDs (to prevent linking them) and secure,
periodically changed passwords that are unique for every site - that's not an
option. For the large class of unimportant accounts, the total value of the
account is less than the cost of that effort. The only way around this is by
client-side systems such as password managers that can automate account
creation and maintenance - so that while the "hidden" account is secure, the
whole process from the user point of view behaves as one of the previous
options. That is also a threat, since then (due to natural habits) people use
those tools also for the important accounts, and that opens another source of
vulnerabilities for them; in an ideal world I'd choose to have no
authentification for the vast majority of places, and I'd be able to remember
proper passwords (+2FA) for the couple things that actually matter.

~~~
stcredzero
_I have a rather clear picture for the scenario where "one easy-to-remember
password for large number of sites" is the proper action to take..._

Basically the rest reduces to: "I know enough to know better, but using a
Password Manager is too much trouble."

~~~
PeterisP
"Too much trouble" is the whole point. The value of security for such accounts
is approximately zero - if some solution doubles (or creates?) security but
requires an extra click or two, then it's a bad tradeoff that simply shouldn't
be done.

Why should people spend any effort at all to secure things that shouldn't be
secured in the first place? Why should anyone remember a single bit of info or
download an app or spend an extra keypress to protect an account that's
already public in intent; but "private" because someone else wanted it to be
private?

There are security problems if you use your 'throwaway' password for your
primary email (as some of the people on Adobe list have done), but that's not
the fault of the throwaway password, but in throwing away the keys to
something valuable. That throwaway password should be something that's _not a
secret_ , as an equivalent to no password.

It should not even attempt to be protected - it's something that you tell your
friends/colleagues openly (so that they'd not have to create their own
accounts there, it's quicker to login with yours), post it publicly on the
internet (again, bugmenot.com as an example), don't bother to change it years
after some site has leaked it, etc. The password as such exists only because
someone forces you to some tradeoff of "more security/less usability" \- the
only reason that the password is not, say, a 0-length string is that you're
forced to do so, but there's no reason at all to go any further than the
minimum.

For the majority of accounts that I have, the most appropriate level of
authentification is not "a reasonable level", not "a minimum", but exactly
zero.

~~~
mtdewcmu
I think new models and progress will have to be based on looking at the
technologies available, such as cryptography and web protocols, and figuring
out what are the best and most convenient systems you can assemble for various
levels of security. For instance, a site can track your visits with a cookie,
without your creating an account, as long as you use the same browser and the
cookie doesn't expire. Cookies seem like almost enough for a lot of scenarios,
except that you can't (currently) transfer them to a different browser and
there's no standard way to distinguish the person that owns a cookie if
multiple people use the same browser.

------
sdrinf
This is definitely _a_ solution to the registration problem; and metrics will
probably back you up on conversion. However, a major drawback of this occurs
while moving across multiple devices:

Peter (fictional archetype) might click through on his work computer; then go
home, and might want to have another look at the site; however he won't have
any recollection of his "personal URL", nor any way to access it. Peter will,
at this point, perceive all his time investment going down the drain. He will
either re-register (to be wacked on the head when he's back at work again), or
refuse the site altogether.

Note this is different in Doodle's case, due to it's inherent sharing nature:
people will email the link as part of the main process, so they're able to get
back later.

One way to see how this affects user's lifecycle is measuring: 1, username
only; 2, username + email; 3, username, email, password variants against
eachother, across the entire user funnel: registration, main mechanics,
retention (or length of lifecycle).

~~~
jbogp
I think the combining the "no registration at all" with an optional "send me
the link via email" is really nice.

Actually of the 5000 people who have "registered", more than half have given
their email address... probably means people like optional stuff, I know I do.

~~~
mrweasel
Do you then store the email address after having sent the link to the user?
Because I don't think people view it as "giving their email address", but more
like "send me the link and forget that you ever saw my email address".

~~~
jbogp
Nah I don't actually. Just have a field in the db to know if they gave one or
not, for statistics purposes...

~~~
kubiiii
Storing emails would be a convenient way to send the link if the user did not
send it from the registration page or lost it in the meantime. As a user I
would love seeing this kind of identification and would probably set a email
account only used to recover links and avoid sharing my main email account.

Nice work by the way.

~~~
jbogp
Good point, but for something done in 3 days I didn't want to risk having left
some SQL injection somewhere somehow and leaking people's email.

But yes that's a good idea.

------
pauljohncleary
I solved this problem (at [http://tab.bz](http://tab.bz)) by creating a fake
account with a dummy username/password when a user first interacts with the
site. All of the user's work is saved to that account, so they're free to do
anything they like. When they "Register" we just change the email and password

~~~
TuringTest
That may very well be a good way to handle first-time users, but I can't make
any sense of how the site works, and there's no help page.

The testimonials make it look like something I'd like to use, if only I could
understand how to use it.

------
nwalfield
An unguessable ID that designates some resource is called a (crypto)
capability.

Capabilities are quite different from access control lists (ACLs). In an ACL
system, the list of authorized principals is attached to the resource. Thus,
sharing access to a resource requires updating the resource. For instance, if
Alice creates a document and wants to share it with Bob, then Bob needs an
account and Alice needs to add Bob to the document's ACL. In a capability
system, the capabilities designate the resource and sharing the resource is as
simple as copying the capability. In fact, Bob can also share the document
(without copying it first) with Carol. In an ACL system, Bob would not
typically have permission to update the ACL.

For more information about capabilities, start with, for instance, the
e-rights wiki at
[http://erights.org/elib/capability/index.html](http://erights.org/elib/capability/index.html)
.

------
wcchandler
I've been hacking away at a hobby project in my spare time that implements
this method. You can password protect the page, if you want, but by default
the unique ID is publicly accessible. The easiest way to password protect it?
Use your email address as the "password." It's also easy to create
forks/snapshots using this method. If somebody makes a change that they don't
like, or wish to test something themselves and not have their "default" page
get crowded then they can share/revert to their one "master" ID, and use their
other ID until it's ready. My use case is fairly specific (simple server
monitoring tool), but sometimes there are _better_ ways of doing things than
the default go-to solution.

~~~
xerophtye
>The easiest way to password protect it? Use your email address as the
"password."

yeah that would be cool. You open YOUR page and it asks for your email id. So
you need to know the username (assuming that's what u make url from) and the
email id. Simle two factor auth without annoying sign ups

~~~
Xurinos
This is not two-factor authentication. It is important to know what it means.
From [https://en.wikipedia.org/wiki/Multi-
factor_authentication](https://en.wikipedia.org/wiki/Multi-
factor_authentication) factors are:

* Something only the user knows (e.g., password, PIN, pattern);

* Something only the user has (e.g., ATM card, smart card, mobile phone); and

* Something only the user is (e.g., biometric characteristic, such as a fingerprint).

Your example was two things that someone knows -- one factor.

~~~
xerophtye
oh yeah, what was i thinking O_o sorry, my bad.

~~~
Xurinos
No problem. :)

------
bguthrie
No, what this article states is that _the author_ hates to register, and for
their _particular_ app, not registering _may_ have made a difference in its
adoption rate. That doesn't say much about the implications of registration
for your business.

I recently launched an app that requires Facebook registration. I expected it
to be a disaster, but a necessary evil for our first pass. I was _shocked_ to
find a conversion rate from opening the app to logging in of 95%; it's not
hurting us nearly as badly as I anticipated. Measure!

~~~
thejosh
Isn't his for a website? Is yours a mobile app? I'm guessing that since the
user has already committed to downloading the app, and probably has FB clients
on their phone it's easy for them to use FB oauth (since it's actually quite
nice how that is haandled), they probably just want to use the app and are
happy to sign in with FB.

~~~
bguthrie
Neither myself or the author presented a controlled study; they are both
individualized experiences that may or may not be relevant to one's own
project. I'm simply trying to say that the OP isn't gospel. That said, for the
forcefulness of the headline, I would've expected much more data.

------
brudgers
I don't really hate sites that require registration unnecessarily, because,
well, I usually don't register, and until reading the article I always thought
it was some combination of the bother of password management and a dislike for
being tracked, I mean you know, if I didn't care about being tracked I'd just
let my browser keep phoning home to the 1000's of tracking companies, and stay
logged into Facebook and Gplus and hell I'd stay on Windows and use consumer
grade AntiVirus software and the Ask toolbar that Adobe and Oracle like to
install as default by default. Not caring should mean not caring, dammit.

But as I read the article I realized that it's really something else.

Requiring a user name and email means a trip to Epcot. It ain't Europe. There
are hyperlinks and pages and it looks like the internet. But it isn't. The
links will all be part of a sitemap. Registering is symptomatic of crabtraps:
once in, the only way out is back the way I came in and usually what's in the
middle is pretty much a three day old fish head, which isn't too bad if one is
a crab, I imagine, but a fishhead in a cage is still pretty much a fishhead in
a cage compared to the entire fucking ocean...even to a crabby bastard like
me.

I'm the first to admit that there are a lot more smart people in the world
than I tend to imagine, but the odds that I want to spend time in someone's
crabtrap for a few bytes of the someone's idea of the best fishhead ever are
pretty low. I mean if I'm that bored, there's YouTube and HN and Facebook and
Twitter. And one of them doesn't even require me to register...at least not
yet.

Don't get me wrong, you probably don't want me as a customer anyway -
requiring registration makes sense by filtering out people who might be harder
to track. It's the strategy successfully used by Nigerian princes.

[http://research.microsoft.com/apps/pubs/default.aspx?id=1677...](http://research.microsoft.com/apps/pubs/default.aspx?id=167713)

------
bambax
I hate to register. If I'm willing to register it means I really need the
service; if I need it so much I'm probably okay with paying for it.

"Free Registration" doesn't mean anything: if you get me to register for
something, you should really ask for money too.

------
aragot
We need to keep in mind that we are the old generation: We all have more than
10 years Internet experience and we know how many times Facebook has betrayed
us.

Now we should ask the younger generation and people with non-IT jobs what they
think about logging in through a social network. Perhaps it's just another
noise like managing URLs and Adobe updates.

~~~
lazyjones
> _Now we should ask the younger generation_

Indeed, for them it's probably just a click, they already have no expectation
of privacy on the Web. I'd really like to see numbers for various registration
methods (where several are available), as well as age distribution for each.

------
mschuster91
It would be very cool if browsers had an "auto-register" feature, where you
give the browser your information (name, nickname, email) and it automatically
fills registration forms when it encounters e.g. an META tag in the page
header.

One part already exists - the new html5 input type="foo" classes which COULD
be used if sites would actually USE them. The other part is the password
manager - it would need some rework to generate truly random passwords. Oh,
and if the email confirmation messages could be standardized, too, then the
mailclient could automatically confirm the mail.

edit: dear website owners, please allow facebook, twitter or any OpenID based
flow, no matter how much you dislike these services. I hate nothing more than
the tedious crap of filling out differently laid out forms, captchas and email
confirmations.

~~~
mtdewcmu
I work on websites in drupal and so I've both given thought to this problem
and seen how the process works from the inside. The problem with random
passwords is that they are impossible to remember, so you have to have your
password file with you all the time if you want to be able to access those
sites from another computer.

The lack of a standardized registration form is not likely to change as long
as sites manage their own accounts. However, perhaps there is some way that
accounts and registration could be outsourced to a third party. It would have
to be a company, or perhaps some not-for-profit entity, that did account
management as their only business, so that they weren't just trying to use it
as a vehicle to advertise their other business or sell your data, like
Facebook. If it was simple, streamlined, and effective for both site owner and
user, it could become a de facto standard.

~~~
bachmeier
The easy solution is to use [https://lastpass.com/](https://lastpass.com/)
Even if for some reason you don't trust it for your most critical passwords,
you can use it to fill in details and generate a password for random sites.

~~~
sparkie
Don't trust that company with your data, trust this one instead!

This is never the solution. The solution is to abstain from services which
need your data, and which don't give you the source code of the software so
that you can verify whether or not it does what they say it does.

Try instead: KeePassX, or KeePass2

~~~
bachmeier
Do you know anything about LastPass? You don't trust them with your data
because they don't have access to it:

[https://lastpass.com/how-it-works/](https://lastpass.com/how-it-works/)

------
OliverM
Passwords are weird.

You give a site your user name and password via a form. Your browser converts
these into a http request to a link via parameters. The site sends you your
account page, or makes you try again if you fluffed it.

Isn't this the equivalent of giving somebody private URL, like in the article?
It's essentially the same, functionally, as a password you remember. Except
passwords are less secure, as people use the same ones repeatedly, or generate
them from a simple system repeatedly (less vulnerable to automated password
guessing attempts, but as vulnerable to a dedicated human attacker).

Are their web frameworks that let you determine if a user is genuine by their
behaviour as much as their passwords? E.g. if I usually log in from the US,
why am I suddenly logging in from Russia, less than a half-hour since I logged
in via the US?

~~~
thret
I was burned by something like that just yesterday. I've never used my mobile
to log onto my email before, but after taking a 4hr trip and expecting an
email, I tried and found myself locked out. This despite having the correct
password, but it ran me through 'secret questions' which I filled out with
gibberish about 20 years ago because I correctly believed they were a security
risk.

Thanks for that hotmail, very helpful.

------
joeblau
Here is a thought that I've been playing with over the previous weeks, but I'm
not sure if it's viable. What if instead of making a website, you created an
entirely mobile application? My theory is that you could eliminate the need
for creating accounts since most people only usually use one device. You can
still have all of the mechanics for inviting and creating teams, because that
would be native to the system. All you would need to do is store a UUID for
each user.

There are a few drawbacks to this approach such as a user losing their device.
Essentially all of their history would be lost with it unless you used
something like CloudKit to back the users info up. The problem with an API
like CloudKit is that it isn't cross platform (yet). A user with multiple
devices could join the same game, but I don't see how that would stop users
with multiple emails from accomplishing the same thing.

Just something I was thinking about, but I do agree with not creating more
accounts. There needs to be a more elegant solution.

~~~
uptown
_" My theory is that you could eliminate the need for creating accounts since
most people only usually use one device."_

I think that's a very risky assumption, and only bound to be less-true as time
goes on.

~~~
nvdk
agreed, tablet + phone is quite common for example

~~~
SalimoS
but tablet + phone have generally the same iCloud/google account and event if
the device is stoled you can recover the account !

------
takinola
I hate to register on sites but I often do. This is because if I expect the
trade off between the pain of registration against the value I expect to get
from continuing to use the full functionality to be positive then I sign up.

My pain from registration is largely due to the friction from having to think
up a unique username (I hate when my favorite username is already taken) and
making up a password.

I am really not bothered by receiving email from services as most respectable
sites will unsubscribe you with one click and if they don't I simply mark
their email as spam.

I never sign up with social services (GooFaceTwit) due to my irrational fear
that at some point my activity on the site will be made public without my
consent.

Your takeaway as a product owner I think is that if you are building a service
for technical folks (would your typical user hang out on HN? If so, read on.
If not, ymmv), you should really think about if your service truly needs user
registration (I have seen some creative workarounds that don't impose a burden
on the customer and still allow the product to achieve business objectives).
If you do need registration, you should remove as many impediments as you can
(meaningful engagement prior to registration, email as username, only ask for
information you absolutely need to have, stagger your profile updates within
the user lifecycle, etc).

Personally, I would like to see a structural solution to the registration
problem. This is such a common issue for a significant portion of the web that
it should be solved at the browser level. Why is there not a "Register for
this site" button on the browser chrome? The user signs into their browser and
from then on can simply create an account on any site by clicking the button.
A little drop down or tooltip can show what information they need to share to
successfully register so the user is making an informed choice.

I shouldn't need to enter a user name password combo on any website ever again
and the entire process should be as easy as hitting the back button.

------
rogerbinns
There is a fantastic article
[https://www.uie.com/articles/three_hund_million_button/](https://www.uie.com/articles/three_hund_million_button/)
and followup [http://www.uie.com/brainsparks/2011/10/17/the-back-story-
for...](http://www.uie.com/brainsparks/2011/10/17/the-back-story-for-
the-300-million-button/) about the $300 million button. They showed just how
much forcing people to register actually costs, and stats on how many accounts
people had, how often they remembered which one was used etc.

------
olssonm
I've seen this idea before, and I really do like it. However, I managed to
close my window (had incognito mode), and now I will never be able to retrieve
my predictions. No big deal perhaps – but still annoying.

------
SimpleXYZ
Name: afdssdf email: fsdass@dfafd.com password:fsdssd How many times have I
filled forms out like that? Probably over 10,000. I also use my fake facebook
account almost as much as my real one.

~~~
BillyParadise
As long as you always use afdssdf@. If you ever want to log in again (without
reregistering), be sure you don't use afdsddf@!

~~~
SimpleXYZ
No, those are just random. If I find I actually want an account, I'll log-out
and sign up with a real e-mail/password. (It's very rare.)

Most sites that require e-mail I will just leave an never come back. If it
looks SUPER useful or amazing I'll go to the trouble of getting a disposable
e-mail account.

------
jeena
The problem I have with this solution is that I have already lost the link to
the ligue I created an hour ago and have no way to get back there :(

BrowserId (Persona) would work a bit better for me.

~~~
eitland
Browser history?

~~~
jeena
Ok you're right, but on the other hand if I, a vivid user of the browser
didn't think about searching the browser history for that, other people will
neither.

------
lucb1e
The author is right in that I do not want to sign up with Facebook, Twitter,
Github, Google+ or any other SSO SPOF.

He is wrong in that "Nooooo people do not want to create an account either".
If there is a reason to register, I am perfectly happy creating an account
with a self-invented password and email validation, even if it's to do only so
much as post a few comments under the same name somewhere.

------
btbuildem
Spot on. I like the method he used - simple on the code end of things, simple
for the end-user. I think simplicity is a proxy for success.

I think the only reasonable time to require someone's email (or other contact
information) is when sending emails delivers real value to your users - when
there is no other way to accomplish what you need to, except by sending email.

------
MicroBerto
We run a Price comparison site for nutrition products. The main reason we have
a "registration" process is so that you can sign up for price drop alerts on
your favorite brands, products, categories, and our hot deals we find.

So, since these users _want_ to receive emails from us, the system proposed
simply won't work.

We've spent a fair amount of time refining our process, and still have ways to
go, but this is the current process:

1\. User is not logged in, wants to get a price alert on their favorite
protein. They click the button.

2\. A modal popup comes in, _only_ asking for their email.

3\. They're now logged in, and the alert is saved (but not _activated_ ).
They're told to check their email.

4\. We send an activation email via Mandrill.

5\. They activate, when entails entering a password and their (optional) full
name, and all price alerts are now _active_ for them.

6\. After they activate, we send them on over to a welcome page, showing them
where they can see their settings.

This process is as simple as we can make it. The only thing I want to change
is some of the verbage in #4. Right now it's a blanket Confirmation email, but
doesn't mention the product they want to follow.

Our userbase is all over the map in terms of gmail, facebook, and twitter. I
don't trust any of those. So this is our best thing. See my profile if you
want to test it out.

~~~
revelation
Why have a password and full name or the whole UI shebang around logins? Save
their email in a cookie, then only send a confirmation email for the first
alert. Prepopulate the alert sign up with the mail from their cookie.

~~~
MicroBerto
But what about when they come from another browser or on mobile?

Most people will check their email from their mobile devices. Could be a
different browser than where they started, so now they have no easy way of
removing the alert, (unless we generate new codes for that in every email?)

~~~
revelation
You should already be providing one-click unlist links in _every_ mail you
send out. That is pretty much the law in some european countries now.

------
cpeterso
I was shopping for high-speed internet yesterday. Comcast's website refused to
share any details about their internet options' prices or bandwidths until I
registered an account. I guess when you are a near monopoly like Comcast,
price comparison is not something your customers need to worry themselves
about..

------
PythonicAlpha
_eMail-only registration_

I found the discussion about registration so inspiring, that I wanted to throw
in a different approach that I outlined in an own blog post and posted as
different thread.

[https://news.ycombinator.com/item?id=7884415](https://news.ycombinator.com/item?id=7884415)

------
fenesiistvan
People don't like to register? I don't think so:

I am using a CRM as our main website. It has a small "Register" link in the
corner which I was unable to remove until now due to my poor html/css
knowledge. It doesn't have any functionality. Still we have around 3 new user
every day :)

------
sebastianconcpt
The site is super cute. You don't need that to predict the WorldCup outcome.
The cup is staying in Brazil. It's all here:
[https://www.youtube.com/watch?v=CKded0d0M7E](https://www.youtube.com/watch?v=CKded0d0M7E)

In the other hand, the signing up issue is valid

------
thomasfl
Mozilla persona seems to be better than ouath, but most users have
unfortunately not heard about it yet.

------
Malarkey73
Here in the UK I played a game on the CBeebies website with my daughter (age
7). It wanted her to sign up for an account with an email address and details
so that she could save her progress.

She just plays from the beginning restarting each time and picking a different
path through the game.

~~~
rlpb
This is what cookies were invented for. It could easily save her progress in a
persistent cookie with no need to sign up.

(Signing up might still be an optional way of persisting that state beyond the
cookie, for example to share progress between cookies, but that could easily
come later and only when the user wants it)

------
ph4
This is a good way to piss off your marketing department. Unfortunately
sometimes UX has to take a hit in the name of the bottom line. Email/direct
marketing works. It won't deliver value to every user on every contact, but
even 5% response rates can offer ROI.

~~~
warcode
Make software to solve problems and help people. The money will follow.

You don't need ALL the money, just enough money.

------
drivingmenuts
Sometimes I wonder if the only actual value of an site is in the list of
people who sign up?

------
wldcordeiro
The most obnoxious offenders are job sites for specific companies. You need to
create an account that you will use probably a handful of times. To make it
worse they all use something like Taleo but for some reason can't share
logins.

~~~
aestra
This is very truly annoying but I believe that it serves a purpose of reducing
spam job applications.

------
webhat
Completely agree! Our website does require you register. Only at the end -
just before payment - do we ask for an email address.

EDIT: the email address is so we can send you the product you just ordered.

~~~
taspeotis
Those are the worst kinds of websites.

~~~
webhat
I'm still trying to figure out what you mean.

~~~
taspeotis
Wait for the user to invest some time in your website and then bam! Register
now.

~~~
webhat
Ah, I see, we are an online school. You can browse the courses, and some
course materials for free, but if you want to take them and get credit you
need to pay.

------
Chromozon
I was one of the users who went to your website the first time it was posted,
saw that you had to register to see anything at all, and left. +1 for the
changes!

------
sida
Funnily enough, a lot of Bitcoin gambling sites like just-dice.com, also
operate on an URL-based account system. It is really minimal barrier to
gamble.

------
mtdewcmu
Somebody really needs to solve this problem. I've given some thought to it,
but I haven't come up with any idea that's a slam-dunk.

------
LukeB_UK
I quite like Twitter's approach:
[https://twitter.com/signup](https://twitter.com/signup)

4 Fields, all relevant.

------
conradfr
To the website owner about the french version : "pronostics", not
"pronostiques".

~~~
jbogp
good point. wasn't sure. merci

~~~
flaie
I sent a message via the contact form (not via email) pointing some spelling
mistakes in the French translations, but it was not taken into account for the
moment ;-)

~~~
jbogp
Yes I did change it, especially in the rules ! Except "Brazil" because I
needed to keep this international.

By the way the French version is not the translation, it's the original.

~~~
flaie
Ok except that "Brézil" is incorrect, it's "Brésil" or "Brazil" if you want to
keep it international. There are still typos on the league page "Voir ses
pronotics" is missing a "s" for example.

But as I said in the message the site is usable so I don't really care that
much, it's just some polishing that would make it greater.

------
leorocky
> I know I'm going to need to come up with some password.

I agree with the premise, but you shouldn't come up with passwords when you
register. You should use a password manager that generates a unique password
for every site you use.

------
sophiaedm
no password, no login = facefeed

------
throwaway420
Now, this obviously wouldn't work for most types of bank or email security,
but for casual forums and things, I really like the way that Bret Victor
presented the trip phrase concept.

[http://worrydream.com/#!/tripphrase](http://worrydream.com/#!/tripphrase)

------
iambase
Wait up ! Signing up via twitter or Fb is pretty clutch afaic

