summaryrefslogtreecommitdiff
path: root/_posts/2015-01-16-your-website-is-not-special-dont-make-visitors-make-accounts.md
diff options
context:
space:
mode:
Diffstat (limited to '_posts/2015-01-16-your-website-is-not-special-dont-make-visitors-make-accounts.md')
-rw-r--r--_posts/2015-01-16-your-website-is-not-special-dont-make-visitors-make-accounts.md61
1 files changed, 61 insertions, 0 deletions
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.
+
+<!--more-->
+
+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/