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.<p>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.
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.<p>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.
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.
This is definitely <i>a</i> 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:<p>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.<p>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.<p>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).
I solved this problem (at <a href="http://tab.bz" rel="nofollow">http://tab.bz</a>) 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
An unguessable ID that designates some resource is called a (crypto) capability.<p>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.<p>For more information about capabilities, start with, for instance, the e-rights wiki at <a href="http://erights.org/elib/capability/index.html" rel="nofollow">http://erights.org/elib/capability/index.html</a> .
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 <i>better</i> ways of doing things than the default go-to solution.
No, what this article states is that <i>the author</i> hates to register, and for their <i>particular</i> app, not registering <i>may</i> have made a difference in its adoption rate. That doesn't say much about the implications of registration for your business.<p>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 <i>shocked</i> 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!
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.<p>But as I read the article I realized that it's really something else.<p>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.<p>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.<p>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.<p><a href="http://research.microsoft.com/apps/pubs/default.aspx?id=167713" rel="nofollow">http://research.microsoft.com/apps/pubs/default.aspx?id=1677...</a>
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.<p>"Free Registration" doesn't mean anything: if you get me to register for something, you should really ask for money too.
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.<p>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.
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.<p>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.<p>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.
Passwords are weird.<p>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.<p>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).<p>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?
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.<p>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.<p>Just something I was thinking about, but I do agree with not creating more accounts. There needs to be a more elegant solution.
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.<p>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.<p>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.<p>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.<p>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).<p>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.<p>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.
There is a fantastic article <a href="https://www.uie.com/articles/three_hund_million_button/" rel="nofollow">https://www.uie.com/articles/three_hund_million_button/</a> and followup <a href="http://www.uie.com/brainsparks/2011/10/17/the-back-story-for-the-300-million-button/" rel="nofollow">http://www.uie.com/brainsparks/2011/10/17/the-back-story-for...</a> 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.
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.
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.
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 :(<p>BrowserId (Persona) would work a bit better for me.
The author is right in that I do not want to sign up with Facebook, Twitter, Github, Google+ or any other SSO SPOF.<p>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.
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.<p>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.
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.<p>So, since these users <i>want</i> to receive emails from us, the system proposed simply won't work.<p>We've spent a fair amount of time refining our process, and still have ways to go, but this is the current process:<p>1. User is not logged in, wants to get a price alert on their favorite protein. They click the button.<p>2. A modal popup comes in, <i>only</i> asking for their email.<p>3. They're now logged in, and the alert is saved (but not <i>activated</i>). They're told to check their email.<p>4. We send an activation email via Mandrill.<p>5. They activate, when entails entering a password and their (optional) full name, and all price alerts are now <i>active</i> for them.<p>6. After they activate, we send them on over to a welcome page, showing them where they can see their settings.<p>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.<p>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.
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..
<i>eMail-only registration</i><p>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.<p><a href="https://news.ycombinator.com/item?id=7884415" rel="nofollow">https://news.ycombinator.com/item?id=7884415</a>
People don't like to register? I don't think so:<p>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 :)
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:
<a href="https://www.youtube.com/watch?v=CKded0d0M7E" rel="nofollow">https://www.youtube.com/watch?v=CKded0d0M7E</a><p>In the other hand, the signing up issue is valid
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.<p>She just plays from the beginning restarting each time and picking a different path through the game.
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.
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.
Completely agree! Our website does require you register. Only at the end - just before payment - do we ask for an email address.<p>EDIT: the email address is so we can send you the product you just ordered.
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!
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.
I quite like Twitter's approach: <a href="https://twitter.com/signup" rel="nofollow">https://twitter.com/signup</a><p>4 Fields, all relevant.
> I know I'm going to need to come up with some password.<p>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.
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.<p><a href="http://worrydream.com/#!/tripphrase" rel="nofollow">http://worrydream.com/#!/tripphrase</a>