10 ms·

Don't Make Visitors Make Accounts

143 points by benburwell 12y ago

minimaxir 12y ago
This advice is too generic. There are many, many applications where a persistent identity is required. What would happen if Hacker News had completely anonymous users? :P A ticketing startup is a good example of a startup which could be used without a dedicated user account. But that's the minority.
- throwawaymsft 12y ago
  The first point in the article was to have a login with FB, Google, etc. Most websites aren't special enough to warrant yet another account. Of course they need to keep track of people.
  - Drakim 12y ago
    But I don't want to hand off my FB, Google, etc to various websites. If a site only offers that, I simply close it and find another part of the web to browse instead.
    - tshtf 12y ago
      2. Don't force visitors to use a 3rd-party provider. Always have a local option. As a counter point to (1), many visitors won't want to use their Facebook/Google accounts for authenticating to other sites.
      - tracker1 12y ago
        I tend to prefer the oauth options myself... I don't want to have to enter a bunch of information, or add yet another site to lastpass if I can avoid it... Though, if they ask for too much, I tend to just deny and move on... For example, it's interesting that a site within the past couple of minutes to sign into could use a local account, facebook or google... I clicked fb first, they wanted contact info and my full friends list... google, just my email... so I let it in with my google account. I think it really depends... I wouldn't offer social logins without also having a local option, but it really depends on your audience.
    - Karunamon 12y ago
      Your account is never "handed off" - all of those schemes are based on openid or similar. All the site gets is a token.
      - jacquesm 12y ago
        But it requires you to have an account with some other party, such as Facebook or Google. What if you don't want that? Suddenly this service that you do want to use becomes unusable. And it also tells Facebook / Google etc what other sites you use, which is none of their business (not that they won't grab that info because of like buttons, analytics, embedded fonts or hosted JS but that's another matter).
        Karunamon 12y ago
        Can't have your cake and eat it too. If you complain that you don't want to have to log into sites, it makes less sense to complain when there are ways to have unified logins so that's not necessary anymore.
    - throwawaymsft 12y ago
      And that is literally the second point made in the article, to have a local fallback.
- krapp 12y ago
  >What would happen if Hacker News had completely anonymous users? :P It would turn into /g/ without the pictures?
- stegosaurus 12y ago
  I would say that in my experience, account creation at online retailers (even Amazon) is very rarely something I've found useful for myself. It may well benefit the company. I don't want my card details to be saved, and typing in my address and card number take less than a minute anyway. Newsletters almost universally go to spam because I'm not a landowner who has the disposable income to just buy arbitrary things that are advertised to me. I think generally developers are aware of this, but they're chasing the few that do respond to such tactics.
  - mattmanser 12y ago
    Most people aren't you actually, contrary to your very misplaced belief. Just think of the huge number of people have kindles with 1 click buy. The 'few' indeed.
    - Gracana 12y ago
      The advice isn't "don't have accounts," its "don't make visitors make accounts." Having an option is good... if you don't plan on coming back or you're worried about your security, you don't have to store anything on their servers. If you're a frequent customer and you want the convenience, you can make an account.
- jordanpg 12y ago
  He's not talking about requiring accounts for all users, only visitors. You can browse HN without limit without an account. Also, it is trivially easy to make HN accounts. My guess is that the OP approves of HN. These are just usability guidelines, almost all of which are dealbreakers for me when I visit sites. For example, when I use my password manager to generate a 64 char password for a new account somewhere, and get an error message saying "Please limit your password to 3 to 20 chars using only letters and numbers," I just have to laugh to myself. I mean, think about what this tells you about the creators of that site.
Frozenlock 12y ago
> Always allow your users to close their account. This should remove all information about them from your service to the extent possible without disrupting the integrity of other information. I think this would be much better if it answered the question "Why?"
- vonklaus 12y ago
  This is pretty obvious from the user perspective and from the site runners perspective, something you do not want. Obviously a user who closes their account want to make aure their information is safegaurded and no longer used. This is especially salient now that Facebook own user data like pictures and can profit not only from information, buy sellig photos and other user-contributed things as assets to be used for commercial purposes. From the site owners perspective, they want the data. Maybe they sell it, or maybe they want to provide a nice user experience. Welcome back user, here is all of your information, we kept it for you so it is not lost. Thanks for rejoining. In the end, it really depends on what kind of site and what kind of users you have. Sites will prob not choose to delete all the information they have, much to some of their users dismay.
fishnchips 12y ago
By having you create an account I get your email. By getting your email I can start retargeting you for advertising purposes and perhaps even you will tick the box allowing me to send you spam. This is called customer retention.
JonathonW 12y ago
> Use a slow, secure hash function like SHA-256. Don't use MD5! Don't use a single round of any hash function, including SHA-256. You shouldn't try to roll your own crypto, and you shouldn't try to roll your own password verification either. Use bcrypt and you'll get salting and you'll get a multi-round hashing process that has the ability to easily scale up in complexity as computing power continues to increase.
- chronid 12y ago
  This. Absolutely this. Also see [1]. [1] http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- benburwell 12y ago
  I actually just updated the article to reflect this. bcrypt is a much better solution than what I originally proposed. Thanks!
  - TheSwordsman 12y ago
    I gotta ask, how many systems/websites have you actually maintained in a production environment? I like people offering help to others, but I read your article before you updated this... and I immediately wrote you off because of that. It's great to offer advice, but can't seem to find any indication of what your experience is.
  - TheSwordsman 12y ago
    Nevermind, answered my own question.
- markdown 12y ago
  Except if you can't use bcrypt. Eg. on Google App Engine.
  - unepipe 12y ago
    When Google is doing your authentication for you? This node is about rolling your own auth.
getdavidhiggins 12y ago
Some of us have been online for decades, and have seen our fair share of walled gardened apps with a login screen hiding the app. We are sort of used to registering, but we are also sick to the teeth of having to register too. The problem can lie in the micro copy too; you often see "10 seconds to register" or, "one click login". It is rarely that - it usually entails a frightful tale of password management, making the password match the requirements of the app (alphanumeric and maximum 8 characters nonsense), alongside a11y issues, PIA (Personally identifiable information) issues, and a slew of other barriers to entry. Very much something that has gone un-noticed by developers for a long time, is that login systems are an obstacle and something to be avoided if we can. Login systems can not be solved with Single Sign On (SSO) / OpenID systems either. (Not all of us have FB/Google accounts, and never presume so) Every developer is scrambling to find a solution for the 'login problem', and completely overlook how login systems complicate things for their users. A lot of login systems suffer from Not Invented Here™ syndrome. Often online forms are a sort of 'mystery meat' where users don't know what to expect there. I once saw an account registration form asking to include an emoji character in my password, for example.
- yarou 12y ago
  Biometrics may alleviate some of these issues, but you have a lot of compliance/regulatory headaches to worry about. Not to mention privacy issues.
onan_barbarian 12y ago
Seriously. Our local burrito chain has a loyalty program where you get a little card, and so on, but you have a password. Right, because I really want to remember a Burrito Password.
- arthurcolle 12y ago
  I wonder how many people's passwords for that are 'burrito'
  - andyjdavis 12y ago
    I would guess most are either "burrito", "password", "1234" or similar with the remainder being forgotten by the person who set it the instant they entered it. I am curious what percentage have a reasonably strong password that they can actually remember for their burrito account.
- fishnchips 12y ago
  Password managers solve this problem pretty nicely.
  - UrMomReadsHN 12y ago
    I don't want to pull up my password manager to buy my lunch.
    - fishnchips 12y ago
      You probably have it on your mobile. I agree though this is borderline crazy.
      - UrMomReadsHN 12y ago
        I don't keep passwords on mobile. I am very segmented with how I use my phone.
sam_lowry_ 12y ago
My website is special.
timr 12y ago
Actually, most of this advice is too general to be good. Your website is special, and you should think through all of these questions rather than just taking a blog post's advice at face value. Maybe you don't display it as an "account", but I can't think of a single commercial website where you shouldn't at least be taking an email address as part of the transaction. Yeah, users love to complain about registration, but I can tell you from direct experience that they love to complain even more loudly when they have a problem, and you can't find a history of their transaction because they never gave you a way to identify them -- I can guarantee that they never printed out your transaction record. Account-less purchases will have their way with you. Don't do it. As for the rest of it, maybe it makes sense for you to provide OAuth options; maybe it doesn't. It really depends on the domain. Likewise, maybe it makes sense to offer "traditional" login, or maybe it doesn't (Tinder seems to be doing okay). The password advice is good. Developers are this unique audience of people who have -- well, let's say "highly evolved" -- expectations about how web businesses "should" work. Most normal people don't share their expectations, so don't make assumptions without direct validation from your target audience.
- larrys 12y ago
  "most of this advice is too general to be good" I guess what bothers me the most about "advice" like this is what makes the person stating the advice qualified to give the advice? This is not to say it's right or wrong but with all due respect to all those on HN that are still in college (such as Ben the OP) why do you feel that you are uniquely qualified to offer this? Noting that you posted it to HN and not a third party that somehow tripped on it ... OP do you care to give your thoughts?
  - benburwell 12y ago
    I could have provided a clearer intent in my post, but here goes. These are simply usability guidelines that I've built up over my time interacting with hundreds of websites. I find myself annoyed by certain things over and over, so I decided to put them together in the form of a list. I don't believe I am more qualified to write this than anyone else who has spent a decent amount of time on the Internet. Furthermore, there are always exceptions. I'm not implying (or I hope people are not inferring) that no site should ever provide a sign-in/account feature. You may have a compelling reason to provide this, and that's great. But don't allow or require people to do this when it offers them no value.
deleted 12y ago
[deleted]
rendall 12y ago
Don't tell me what to do!
z3t4 12y ago
Most people will actually endure a sign-up process. We are so used to it. But you should stop asking for an e-mail address! Or make it optional.
- tracker1 12y ago
  Unfortunately account recovery requires a secondary means of contact... I'm much more likely to give a new site my email address than a credit card number, phone number or other piece of personally identifying information.
throwawaymsft 12y ago
My favorite model is letting people use the app from the first visit, stored in a cookie. "Want to save your work? Create an account." Creating an account can use FB/Google, or local login. First demonstrate value, and people will gladly save their work.
- lhh 12y ago
  Do you happen to have examples off hand of sites that do this well? Thinking about implementing something like this for my current project
  - throwawaymsft 12y ago
    Khan Academy used to let you watch videos, do questions, and collect points. Then you would sign in to claim them. Their new homepage looks to push you to sign up first though. There is still a link to "Unclaimed points > Sign up to claim your points" in the top nav.
bbx 12y ago
This reminds me of the $300 million button: http://www.uie.com/articles/three_hund_million_button http://www.uie.com/articles/three_hund_million_button They significantly increased their revenue by simply allowing customers to purchase without having to create account.
jinushaun 12y ago
1. I do not want to log in with Facebook or Google 2. I use a password manager so creating new accounts is cheap and easy.
- vonklaus 12y ago
  Agree or disagree with the post, you are a sample size of 1. If you said on your site, these were the patterns you see, then sure maybe it is in line with a macro-trend. If n=1 the data is usually not very helpful.
  - fishnchips 12y ago
    Samples of size one can invalidate scientific theories.
nosferatus 12y ago
"don't invent your own crypto" I laughed hard.
jacquesm 12y ago
I never use websites that require me to have an account somewhere else. Either have no account at all (especially if you don't need one, that's just friction) or set up a minimal password system as an option next to FB/G/TW or whatever else is in fashion as external authorization provider.
jobposter1234 12y ago
In addition to the other threads, the fact is businesses need contact information to make money. Upsells, deal emails, etc., are all a critical part of their revenue streams. So removing this would cost them a great deal of money.
- lazyjones 12y ago
  > fact is businesses need contact information to make money. Upsells, deal emails, etc., Fortunately, there are plenty of exceptions to this rule. For example, price comparison websites (I built, ran and sold one) need nothing of the sort, it's just a mediocre marketing tool (your users are much better at recommending your product than you are!).
kevinflo 12y ago
I felt oddly vindicated when he mentioned Ticketfly specifically... It irked me too that they don't allow guest checkout, so in making http://showboarder.com http://showboarder.com I put in the extra thought/effort to make it an option. That said, having implemented this I can see why many services don't. It's an entire other case to consider when thinking about security, user experience, etc. and for many it could definitely be more trouble than it's worth. It's just a question of values if you make it a priority or not.
- hawkeyedan 12y ago
  I'd suggest that the guest use case is the most important one and that account generation/creation/etc is for most sites the use case that should come second.
mbrock 12y ago
Why not let users complete their transaction with only an email and payment info — and then send an optional account confirmation link along with their receipt?
TheSwordsman 12y ago
Who is BenBurwell, and why do I trust his advice?
tempestn 12y ago
"My bank limits passwords to 14 characters..." I chuckled at that, since my bank limits passwords to exactly 6 alphanumeric characters.
- aikah 12y ago
  for me its 6 numeric characters.
xnull1guest 12y ago
I agree with the author that in the short game not providing your own accounts is attractive. However in the long game it doesn't look so good. Unfortunately there are problems with using federated auth everywhere. * It's a single place for a compromise to occur - the devastation of a serious identity provider hack completely upends the security of huge swaths of the internet in a single shot * Breaks in fedauth protocols and implementations, similarly, presents a large auth crisis for the entire Web * It's a single place for legal or extralegal pressure for governments to access services and data on behalf of everyone * It creates market friction. If federated login had been around in large numbers when Myspace was the big social platform we'd still be using Myspace for the sheer reason we need it to vouch for our identity. It makes the big fedauth players 'too important to fail' One should consider options carefully and determine whether a good user experience can be offered without further centralizing the Web.
riteshpatel 12y ago
As a platform that sells tickets to events (https://www.theticketfairy.com/ https://www.theticketfairy.com/), I feel that I should make a counterargument to not making users create an account. Our checkout process requires no existing account, so you click on the buy button, enter your name, email address and billing info, and you create a password at the end, after which you DO have an account. We feel that this is much better UX than most other ticketing sites that send you to registration forms before you can continue the checkout. We used to receive many, many support requests from people who'd lost the email containing their tickets. We then added order history and the ability to download their tickets by logging into their accounts and this resulted in a massive drop in support emails. Another key point is that most people realise they've lost the ticket email only a few hours before the event is about to start, so we get very panicky last-minute emails from people freaking out that they're not going to be able to get in. Just giving people the option to log into an account and retrieve their tickets not only dramatically reduces our workload but also provides them with peace of mind. We're adding 3rd-party login shortly (primarily Facebook) but will keep email/password as an option. However, even with 3rd-party login, we'll still need to confirm the email address as most people are used to email as their delivery method. Saying all this, most of the advice in the article is valid and we follow many of the points. Our username is the email address and we enforce HTTPS on all pages (with HSTS headers).
- jordanpg 12y ago
  > support requests from people who'd lost the email containing their tickets "Losing email" is a problem completely distinct from the UX question. Since "losing email" is more-or-less impossible in year 2015, it isn't a reason to force people to make accounts. There are other ways to deal with this problem.
  - andyjdavis 12y ago
    >Since "losing email" is more-or-less impossible in year 2015 Actually losing email is basically impossible but non-technical people still do it all the time. What they mean is that they can't find the email they are after. "I am not good at searching" is indistinguishable from "the email is gone".
fr0styMatt2 12y ago
The worst thing about having to register an account on damn near everything is the security implications. I lost track of the number of unique passwords that are stored in my LastPass a long time ago. Seriously, the number is absolutely ridiculous to the point that trying to manage those accounts manually and in a secure fashion is, I'd argue, too much of an unnecessary burden on people.
dsjoerg 12y ago
If you want your readers to follow your advice, tell them _why_ they should, and not simply _what_ to do. See what I did there? Are readers of this piece supposed to follow the advice, like sheep, simply because they are told to? Or because they will get more usage? Or because it will make the world a better place? Or some other reason? We can only guess.
rfrey 12y ago
This can go too far in the other direction too. My latest project was a sunglasses/eyewear design site, where people could design their own glasses (I had a tech stack on the backend to make the glasses in my studio - the company is an experiment in mass customization). I went to great lengths to allow people to use the software without creating an account. In the end, I probably spent two weeks trying to get it to work properly with all the edge cases - saving the anonymous design when they do finally create an account, locking out certain features that required identity, appropriate warning dialogs when work was going to be lost, etc. And I still had edge cases. I burned two or three weeks trying to accommodate account-averse people, then had to spend another two days yanking it. That effort was based on my personal distaste at having ten billion website accounts, a distaste probably widely shared here on HN and likely nowhere else. (This isn't an argument with Ben's points - his example use cases clearly don't need accounts.)
dzhiurgis 12y ago
> My bank limits passwords to 14 characters, which is rather absurd. Similar with Paypal. What's most frustrating, when you login it lets to enter as long password as you want. Which is when it leaves you wondering why your password does not work.
kazinator 12y ago
> One of my pet peeves in website usability design is forcing people to create unnecessary accounts. This has been a pet peeve of a vast number of web surfers for over 15 years now. In the early days, this pet peeve created a backlash in the form of a custom. The custom went like this: 1. When confronted with an annoying site asking you to log in or register, first try the account name "cypherpunk" with the password "cypherpunk". 2. If that works, great. 3. If there is no such account, then create one, for the benefit of future visitors who participate in the custom. There are variations on this: pluralizing to "cypherpunks" and possibly using the "cipher" spelling.
- kazinator 12y ago
  .. and speaking of which, who is the dickhead who created a cypherpunk account on HN, but with a nonstandard password? Or changed it to a nonstandard one? Please atone for your evil ways and fix it to "cypherpunk". Thx.
another-dave 12y ago
" If you do have password requirements, show them to the user before they try to make a password. " & again as help text when they're logging in. Constantly have to reset passwords on obscure sites because I don't remember that I've been forced to use, e.g. no symbols. No use just telling me that on sign-up & expecting me to remember 6 months later.

143 points by benburwell 12y ago

This advice is too generic. There are many, many applications where a persistent identity is required. What would happen if Hacker News had completely anonymous users? :P A ticketing startup is a good example of a startup which could be used without a dedicated user account. But that's the minority.

throwawaymsft 12y ago
The first point in the article was to have a login with FB, Google, etc. Most websites aren't special enough to warrant yet another account. Of course they need to keep track of people.
- Drakim 12y ago
  But I don't want to hand off my FB, Google, etc to various websites. If a site only offers that, I simply close it and find another part of the web to browse instead.
  - tshtf 12y ago
    2. Don't force visitors to use a 3rd-party provider. Always have a local option. As a counter point to (1), many visitors won't want to use their Facebook/Google accounts for authenticating to other sites.
    - tracker1 12y ago
      I tend to prefer the oauth options myself... I don't want to have to enter a bunch of information, or add yet another site to lastpass if I can avoid it... Though, if they ask for too much, I tend to just deny and move on... For example, it's interesting that a site within the past couple of minutes to sign into could use a local account, facebook or google... I clicked fb first, they wanted contact info and my full friends list... google, just my email... so I let it in with my google account. I think it really depends... I wouldn't offer social logins without also having a local option, but it really depends on your audience.
  - Karunamon 12y ago
    Your account is never "handed off" - all of those schemes are based on openid or similar. All the site gets is a token.
    - jacquesm 12y ago
      But it requires you to have an account with some other party, such as Facebook or Google. What if you don't want that? Suddenly this service that you do want to use becomes unusable. And it also tells Facebook / Google etc what other sites you use, which is none of their business (not that they won't grab that info because of like buttons, analytics, embedded fonts or hosted JS but that's another matter).
      - Karunamon 12y ago
        Can't have your cake and eat it too. If you complain that you don't want to have to log into sites, it makes less sense to complain when there are ways to have unified logins so that's not necessary anymore.
  - throwawaymsft 12y ago
    And that is literally the second point made in the article, to have a local fallback.
krapp 12y ago
>What would happen if Hacker News had completely anonymous users? :P It would turn into /g/ without the pictures?
stegosaurus 12y ago
I would say that in my experience, account creation at online retailers (even Amazon) is very rarely something I've found useful for myself. It may well benefit the company. I don't want my card details to be saved, and typing in my address and card number take less than a minute anyway. Newsletters almost universally go to spam because I'm not a landowner who has the disposable income to just buy arbitrary things that are advertised to me. I think generally developers are aware of this, but they're chasing the few that do respond to such tactics.
- mattmanser 12y ago
  Most people aren't you actually, contrary to your very misplaced belief. Just think of the huge number of people have kindles with 1 click buy. The 'few' indeed.
  - Gracana 12y ago
    The advice isn't "don't have accounts," its "don't make visitors make accounts." Having an option is good... if you don't plan on coming back or you're worried about your security, you don't have to store anything on their servers. If you're a frequent customer and you want the convenience, you can make an account.
jordanpg 12y ago
He's not talking about requiring accounts for all users, only visitors. You can browse HN without limit without an account. Also, it is trivially easy to make HN accounts. My guess is that the OP approves of HN. These are just usability guidelines, almost all of which are dealbreakers for me when I visit sites. For example, when I use my password manager to generate a 64 char password for a new account somewhere, and get an error message saying "Please limit your password to 3 to 20 chars using only letters and numbers," I just have to laugh to myself. I mean, think about what this tells you about the creators of that site.

Frozenlock 12y ago

> Always allow your users to close their account. This should remove all information about them from your service to the extent possible without disrupting the integrity of other information. I think this would be much better if it answered the question "Why?"

vonklaus 12y ago
This is pretty obvious from the user perspective and from the site runners perspective, something you do not want. Obviously a user who closes their account want to make aure their information is safegaurded and no longer used. This is especially salient now that Facebook own user data like pictures and can profit not only from information, buy sellig photos and other user-contributed things as assets to be used for commercial purposes. From the site owners perspective, they want the data. Maybe they sell it, or maybe they want to provide a nice user experience. Welcome back user, here is all of your information, we kept it for you so it is not lost. Thanks for rejoining. In the end, it really depends on what kind of site and what kind of users you have. Sites will prob not choose to delete all the information they have, much to some of their users dismay.

fishnchips 12y ago

By having you create an account I get your email. By getting your email I can start retargeting you for advertising purposes and perhaps even you will tick the box allowing me to send you spam. This is called customer retention.

JonathonW 12y ago

> Use a slow, secure hash function like SHA-256. Don't use MD5! Don't use a single round of any hash function, including SHA-256. You shouldn't try to roll your own crypto, and you shouldn't try to roll your own password verification either. Use bcrypt and you'll get salting and you'll get a multi-round hashing process that has the ability to easily scale up in complexity as computing power continues to increase.

chronid 12y ago
This. Absolutely this. Also see [1]. [1] http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
benburwell 12y ago
I actually just updated the article to reflect this. bcrypt is a much better solution than what I originally proposed. Thanks!
- TheSwordsman 12y ago
  I gotta ask, how many systems/websites have you actually maintained in a production environment? I like people offering help to others, but I read your article before you updated this... and I immediately wrote you off because of that. It's great to offer advice, but can't seem to find any indication of what your experience is.
- TheSwordsman 12y ago
  Nevermind, answered my own question.
markdown 12y ago
Except if you can't use bcrypt. Eg. on Google App Engine.
- unepipe 12y ago
  When Google is doing your authentication for you? This node is about rolling your own auth.

getdavidhiggins 12y ago

Some of us have been online for decades, and have seen our fair share of walled gardened apps with a login screen hiding the app. We are sort of used to registering, but we are also sick to the teeth of having to register too. The problem can lie in the micro copy too; you often see "10 seconds to register" or, "one click login". It is rarely that - it usually entails a frightful tale of password management, making the password match the requirements of the app (alphanumeric and maximum 8 characters nonsense), alongside a11y issues, PIA (Personally identifiable information) issues, and a slew of other barriers to entry. Very much something that has gone un-noticed by developers for a long time, is that login systems are an obstacle and something to be avoided if we can. Login systems can not be solved with Single Sign On (SSO) / OpenID systems either. (Not all of us have FB/Google accounts, and never presume so) Every developer is scrambling to find a solution for the 'login problem', and completely overlook how login systems complicate things for their users. A lot of login systems suffer from Not Invented Here™ syndrome. Often online forms are a sort of 'mystery meat' where users don't know what to expect there. I once saw an account registration form asking to include an emoji character in my password, for example.

yarou 12y ago
Biometrics may alleviate some of these issues, but you have a lot of compliance/regulatory headaches to worry about. Not to mention privacy issues.

onan_barbarian 12y ago

Seriously. Our local burrito chain has a loyalty program where you get a little card, and so on, but you have a password. Right, because I really want to remember a Burrito Password.

arthurcolle 12y ago
I wonder how many people's passwords for that are 'burrito'
- andyjdavis 12y ago
  I would guess most are either "burrito", "password", "1234" or similar with the remainder being forgotten by the person who set it the instant they entered it. I am curious what percentage have a reasonably strong password that they can actually remember for their burrito account.
fishnchips 12y ago
Password managers solve this problem pretty nicely.
- UrMomReadsHN 12y ago
  I don't want to pull up my password manager to buy my lunch.
  - fishnchips 12y ago
    You probably have it on your mobile. I agree though this is borderline crazy.
    - UrMomReadsHN 12y ago
      I don't keep passwords on mobile. I am very segmented with how I use my phone.

sam_lowry_ 12y ago

My website is special.

timr 12y ago

Actually, most of this advice is too general to be good. Your website is special, and you should think through all of these questions rather than just taking a blog post's advice at face value. Maybe you don't display it as an "account", but I can't think of a single commercial website where you shouldn't at least be taking an email address as part of the transaction. Yeah, users love to complain about registration, but I can tell you from direct experience that they love to complain even more loudly when they have a problem, and you can't find a history of their transaction because they never gave you a way to identify them -- I can guarantee that they never printed out your transaction record. Account-less purchases will have their way with you. Don't do it. As for the rest of it, maybe it makes sense for you to provide OAuth options; maybe it doesn't. It really depends on the domain. Likewise, maybe it makes sense to offer "traditional" login, or maybe it doesn't (Tinder seems to be doing okay). The password advice is good. Developers are this unique audience of people who have -- well, let's say "highly evolved" -- expectations about how web businesses "should" work. Most normal people don't share their expectations, so don't make assumptions without direct validation from your target audience.

larrys 12y ago
"most of this advice is too general to be good" I guess what bothers me the most about "advice" like this is what makes the person stating the advice qualified to give the advice? This is not to say it's right or wrong but with all due respect to all those on HN that are still in college (such as Ben the OP) why do you feel that you are uniquely qualified to offer this? Noting that you posted it to HN and not a third party that somehow tripped on it ... OP do you care to give your thoughts?
- benburwell 12y ago
  I could have provided a clearer intent in my post, but here goes. These are simply usability guidelines that I've built up over my time interacting with hundreds of websites. I find myself annoyed by certain things over and over, so I decided to put them together in the form of a list. I don't believe I am more qualified to write this than anyone else who has spent a decent amount of time on the Internet. Furthermore, there are always exceptions. I'm not implying (or I hope people are not inferring) that no site should ever provide a sign-in/account feature. You may have a compelling reason to provide this, and that's great. But don't allow or require people to do this when it offers them no value.

deleted 12y ago

[deleted]

rendall 12y ago

Don't tell me what to do!

z3t4 12y ago

Most people will actually endure a sign-up process. We are so used to it. But you should stop asking for an e-mail address! Or make it optional.

tracker1 12y ago
Unfortunately account recovery requires a secondary means of contact... I'm much more likely to give a new site my email address than a credit card number, phone number or other piece of personally identifying information.

throwawaymsft 12y ago

My favorite model is letting people use the app from the first visit, stored in a cookie. "Want to save your work? Create an account." Creating an account can use FB/Google, or local login. First demonstrate value, and people will gladly save their work.

lhh 12y ago
Do you happen to have examples off hand of sites that do this well? Thinking about implementing something like this for my current project
- throwawaymsft 12y ago
  Khan Academy used to let you watch videos, do questions, and collect points. Then you would sign in to claim them. Their new homepage looks to push you to sign up first though. There is still a link to "Unclaimed points > Sign up to claim your points" in the top nav.

bbx 12y ago

This reminds me of the $300 million button: http://www.uie.com/articles/three_hund_million_button http://www.uie.com/articles/three_hund_million_button They significantly increased their revenue by simply allowing customers to purchase without having to create account.

jinushaun 12y ago

1. I do not want to log in with Facebook or Google 2. I use a password manager so creating new accounts is cheap and easy.

vonklaus 12y ago
Agree or disagree with the post, you are a sample size of 1. If you said on your site, these were the patterns you see, then sure maybe it is in line with a macro-trend. If n=1 the data is usually not very helpful.
- fishnchips 12y ago
  Samples of size one can invalidate scientific theories.

nosferatus 12y ago

"don't invent your own crypto" I laughed hard.

jacquesm 12y ago

I never use websites that require me to have an account somewhere else. Either have no account at all (especially if you don't need one, that's just friction) or set up a minimal password system as an option next to FB/G/TW or whatever else is in fashion as external authorization provider.

jobposter1234 12y ago

In addition to the other threads, the fact is businesses need contact information to make money. Upsells, deal emails, etc., are all a critical part of their revenue streams. So removing this would cost them a great deal of money.

lazyjones 12y ago
> fact is businesses need contact information to make money. Upsells, deal emails, etc., Fortunately, there are plenty of exceptions to this rule. For example, price comparison websites (I built, ran and sold one) need nothing of the sort, it's just a mediocre marketing tool (your users are much better at recommending your product than you are!).

kevinflo 12y ago

I felt oddly vindicated when he mentioned Ticketfly specifically... It irked me too that they don't allow guest checkout, so in making http://showboarder.com http://showboarder.com I put in the extra thought/effort to make it an option. That said, having implemented this I can see why many services don't. It's an entire other case to consider when thinking about security, user experience, etc. and for many it could definitely be more trouble than it's worth. It's just a question of values if you make it a priority or not.

hawkeyedan 12y ago
I'd suggest that the guest use case is the most important one and that account generation/creation/etc is for most sites the use case that should come second.

mbrock 12y ago

Why not let users complete their transaction with only an email and payment info — and then send an optional account confirmation link along with their receipt?

TheSwordsman 12y ago

Who is BenBurwell, and why do I trust his advice?

tempestn 12y ago

"My bank limits passwords to 14 characters..." I chuckled at that, since my bank limits passwords to exactly 6 alphanumeric characters.

aikah 12y ago
for me its 6 numeric characters.

xnull1guest 12y ago

I agree with the author that in the short game not providing your own accounts is attractive. However in the long game it doesn't look so good. Unfortunately there are problems with using federated auth everywhere. * It's a single place for a compromise to occur - the devastation of a serious identity provider hack completely upends the security of huge swaths of the internet in a single shot * Breaks in fedauth protocols and implementations, similarly, presents a large auth crisis for the entire Web * It's a single place for legal or extralegal pressure for governments to access services and data on behalf of everyone * It creates market friction. If federated login had been around in large numbers when Myspace was the big social platform we'd still be using Myspace for the sheer reason we need it to vouch for our identity. It makes the big fedauth players 'too important to fail' One should consider options carefully and determine whether a good user experience can be offered without further centralizing the Web.

riteshpatel 12y ago

As a platform that sells tickets to events (https://www.theticketfairy.com/ https://www.theticketfairy.com/), I feel that I should make a counterargument to not making users create an account. Our checkout process requires no existing account, so you click on the buy button, enter your name, email address and billing info, and you create a password at the end, after which you DO have an account. We feel that this is much better UX than most other ticketing sites that send you to registration forms before you can continue the checkout. We used to receive many, many support requests from people who'd lost the email containing their tickets. We then added order history and the ability to download their tickets by logging into their accounts and this resulted in a massive drop in support emails. Another key point is that most people realise they've lost the ticket email only a few hours before the event is about to start, so we get very panicky last-minute emails from people freaking out that they're not going to be able to get in. Just giving people the option to log into an account and retrieve their tickets not only dramatically reduces our workload but also provides them with peace of mind. We're adding 3rd-party login shortly (primarily Facebook) but will keep email/password as an option. However, even with 3rd-party login, we'll still need to confirm the email address as most people are used to email as their delivery method. Saying all this, most of the advice in the article is valid and we follow many of the points. Our username is the email address and we enforce HTTPS on all pages (with HSTS headers).

jordanpg 12y ago
> support requests from people who'd lost the email containing their tickets "Losing email" is a problem completely distinct from the UX question. Since "losing email" is more-or-less impossible in year 2015, it isn't a reason to force people to make accounts. There are other ways to deal with this problem.
- andyjdavis 12y ago
  >Since "losing email" is more-or-less impossible in year 2015 Actually losing email is basically impossible but non-technical people still do it all the time. What they mean is that they can't find the email they are after. "I am not good at searching" is indistinguishable from "the email is gone".

fr0styMatt2 12y ago

The worst thing about having to register an account on damn near everything is the security implications. I lost track of the number of unique passwords that are stored in my LastPass a long time ago. Seriously, the number is absolutely ridiculous to the point that trying to manage those accounts manually and in a secure fashion is, I'd argue, too much of an unnecessary burden on people.

dsjoerg 12y ago

If you want your readers to follow your advice, tell them _why_ they should, and not simply _what_ to do. See what I did there? Are readers of this piece supposed to follow the advice, like sheep, simply because they are told to? Or because they will get more usage? Or because it will make the world a better place? Or some other reason? We can only guess.

rfrey 12y ago

This can go too far in the other direction too. My latest project was a sunglasses/eyewear design site, where people could design their own glasses (I had a tech stack on the backend to make the glasses in my studio - the company is an experiment in mass customization). I went to great lengths to allow people to use the software without creating an account. In the end, I probably spent two weeks trying to get it to work properly with all the edge cases - saving the anonymous design when they do finally create an account, locking out certain features that required identity, appropriate warning dialogs when work was going to be lost, etc. And I still had edge cases. I burned two or three weeks trying to accommodate account-averse people, then had to spend another two days yanking it. That effort was based on my personal distaste at having ten billion website accounts, a distaste probably widely shared here on HN and likely nowhere else. (This isn't an argument with Ben's points - his example use cases clearly don't need accounts.)

dzhiurgis 12y ago

> My bank limits passwords to 14 characters, which is rather absurd. Similar with Paypal. What's most frustrating, when you login it lets to enter as long password as you want. Which is when it leaves you wondering why your password does not work.

kazinator 12y ago

> One of my pet peeves in website usability design is forcing people to create unnecessary accounts. This has been a pet peeve of a vast number of web surfers for over 15 years now. In the early days, this pet peeve created a backlash in the form of a custom. The custom went like this: 1. When confronted with an annoying site asking you to log in or register, first try the account name "cypherpunk" with the password "cypherpunk". 2. If that works, great. 3. If there is no such account, then create one, for the benefit of future visitors who participate in the custom. There are variations on this: pluralizing to "cypherpunks" and possibly using the "cipher" spelling.

kazinator 12y ago
.. and speaking of which, who is the dickhead who created a cypherpunk account on HN, but with a nonstandard password? Or changed it to a nonstandard one? Please atone for your evil ways and fix it to "cypherpunk". Thx.

another-dave 12y ago

" If you do have password requirements, show them to the user before they try to make a password. " & again as help text when they're logging in. Constantly have to reset passwords on obscure sites because I don't remember that I've been forced to use, e.g. no symbols. No use just telling me that on sign-up & expecting me to remember 6 months later.