From cec95aa2559fc095e4351e5dc69f2268f6350651 Mon Sep 17 00:00:00 2001 From: Ben Burwell Date: Mon, 17 Sep 2018 22:12:24 -0400 Subject: General cleanup --- ...not-special-dont-make-visitors-make-accounts.md | 61 ++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 _posts/2015-01-16-your-website-is-not-special-dont-make-visitors-make-accounts.md (limited to '_posts/2015-01-16-your-website-is-not-special-dont-make-visitors-make-accounts.md') diff --git a/_posts/2015-01-16-your-website-is-not-special-dont-make-visitors-make-accounts.md b/_posts/2015-01-16-your-website-is-not-special-dont-make-visitors-make-accounts.md new file mode 100644 index 0000000..51d9ff1 --- /dev/null +++ b/_posts/2015-01-16-your-website-is-not-special-dont-make-visitors-make-accounts.md @@ -0,0 +1,61 @@ +--- +title: Your Website is not Special, Don't Make Visitors Make Accounts +description: > + Few things bother me more than when I am forced to make an account to have + some basic interaction with a website. +--- + +One of my pet peeves in website usability design is forcing people to create +unnecessary accounts. My recent purchase of some concert tickets from Ticketfly +required me to make an account to buy them. For people who buy a lot of concert +tickets, having an account may make a lot of sense. But for me, as someone who +buys concert tickets at most once every year or two, having an account on a site +that I will probably only use once is not only unnecessary, it's annoying. + + + +This is not to say that you shouldn't offer accounts; that would be ridiculous +(depending on the type of site you are running, of course). However, in general, +your users know far better than you do whether or not they actually want or will +use an account. Forcing them to create an account will only drive them away. +People don't like creating accounts they don't want to have. There's really no +reason you can't have a "check out as guest" option. + +And if you do offer accounts, here are a couple of rules to follow to ensure a +good user experience: + +1. Allow the option of using a 3rd-party identity provider (OpenID, Facebook, + Google, etc.). Often, visitors don't want to have yet another + username/password to remember. +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. +3. Username = Email. Don't make people remember a username for your site. You + may allow them to pick a username later on that can be used in lieu of their + email address, e.g. as the URL for a profile page, but don't force them to + use a username to log in. +4. Don't make complicated password rules. If you do have password requirements, + show them to the user _before_ they try to make a password. Only telling them + when their password doesn't fit your requirements causes consternation. +5. Never _ever_ limit how long a password can be (within reason, obviously you + don't want to be receiving a megabyte long password). My bank limits + passwords to 14 characters, which is rather absurd. Since you're hashing your + passwords anyway, it's not like you need to allocate extra memory in your + tables to store longer passwords. +6. 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. + +Of course, there are technical details that you need to be watching out for that +are outside the scope of this post. I'll leave it to you to make sure your +implementation is secure and robust, but I'll leave you with a few general tips: + +- Don't invent your own crypto. This applies to protocols, hashing, encryption, + everything. +- [Use bcrypt][bcrypt]. +- Using unsecured HTTP (no SSL/TLS) is inexcusable. +- Don't invent your own crypto. +- _Don't invent your own crypto._ +- **[Use bcrypt][bcrypt].** + +[bcrypt]: https://codahale.com/how-to-safely-store-a-password/ -- cgit v1.2.3