Want users to use your cloud-based web site?  Follow these guidelines, so that users can sign up easily and use it.  Sadly, there are soooo many ways that web sites can do this wrong.  The result is a bewildering variety of inconsistent and sometimes incomprehensible mechanisms that unnecessarily annoy the very users you are trying to attract.  Heed these guidelines carefully!

As a technology analyst my job requires me to sign up for and access hundreds of different web based applications, most of them cloud based.  Those that perform right are a pleasure.  Most, however violate one or more of these guidelines.  As far as I can tell, this comes from a failure to think through all the consequences of the design.  After a particularly egregious example this morning I compiled this “Bill of Rights” that a user should enjoy in order to have easy and satisfying access to your cloud service.  This is exclusively about how a user registers and maintains their profile.

Guidelines

 1) A user should not have to learn a new user name. A user should be able to bring their own user ID in the form of either an email address, or an OpenID. — The site should not allocate a user name to the user, nor force the user to choose a user name unique for that server.

Sites that violate this guideline will prompt you for your “user id” which is often restricted to alpha-numeric characters, and might have a length restriction 8 to 12 characters.  I have an identifier I usually use, but more often than not, it will respond with “That user id is already taken”.  I try again and again until I find a short sequence that is not already taken, but how do I remember that ID for that site?  I write it down in my log book, but this means that every time I want to access that site, I have to find the place in the log book where I recorded it!  That is so 20th Century.

This is completely unnecessary.  Let me use my email address as a login ID.  I know that is unique to me.  It is familiar enough to me – no trouble to remember.  Better yet is to use an OpenID because then I don’t have to specify a password.  Both of these are ways to “bring my own ID” to the site.  Don’t push the job of remembering a unique internal key for the profile on the user, instead allow the user to log in with their own login ID, and then find the internal key from that.

2) Each user must have the ability to change their password as desired. — A user should not be forced to use a system defined password.

This morning I had to sign up for a service, after registering I received an email with my user name, and another with my password.  After logging in, I searched for the way to change my password.  There was none.  (This was the incident that prompted me to write this blog post.)   The site had been implemented on SharePoint.   After searching around, I found you have to purchase an after-market add-in to SharePoint that allows users to change their passwords.  Ridiculous!  I can hardly believe that I have to send an email to the administrator in order to reset my password … and apparently I have no way to specify what that password should be.  Into my log book goes the password, right next to everything else you need to access this site.  So much for security.

The inability for a user to change their password as part of the site pretty much rules out SharePoint for any serious cloud site.  My guess is that Microsoft wants all the user profile stuff to be managed through Active Directory, and this makes sense for a on-premises environment, but unnecessarily complicates a simple cloud based service.  Paying extra for this capability is annoying … it really should be built in to the core capability.

3) Each user should be able to use whatever password they desire. — Passwords should not have arbitrary and unusual requirements.

Forcing the arbitrary use of classes of characters does not make password more secure, and often serves only to frustrate the user. I know that users in the past have chosen poor passwords: single words.  Some education is necessary.  It is a good idea to include some punctuation, but not always.  Studies have shown that remembering a phrase, and taking the first letter from each word (such as “General Tsu’s Chicken At Peking Palace Is Spicy” or  gtcappis) produces a string of characters effectively impossible to guess that is still easy to remember.  There are no punctuation marks, but that does not mean the password is easy to break.  Attempts to encourage better passwords by requiring certain types of characters can backfire, as it did one time for me: the requirements were so onerous that I figured out the simplest way to comply, and found out several others were using the same password.

A better approach is a password quality measure which gives you feedback on how good your password it.  This way you give a positive reinforcement to those who choose good passwords, but don’t prohibit any password based on the kinds of characters that are in it.

I use the same password for all these site.  Some people arrogantly suggest that I should use 100 different passwords at 100 different sites.  That would require that I write down all the passwords in a place that could be read by others.  The best solution is OpenID (or Facebook Connect or others) which I could use at 100 sites, and changing the one password on that one ID would effectively change it at all 100 sites.  OpenID makes it easy to implement the best security policies.

4) The site should show the user what it is they are logging into, before prompting for the userid and password. — The site should not pop up an authenticating box without any display of the context that user is logging into.

This happens to me all the time: I click on a link, the page clears, and I get a login prompt.  What cloud user account should I use?   The link was for a document, but the link does not always make it clear what authentication domain the document is protected by.

What worries me most is that this could be a phishing site.  I enter my username and password into that box, and who knows where it goes to.  Of course, a real phishing site might display something pretty convincing to fool me, but a completely blank page with no indication of where you are is simply too easy to fake.

5) If the user does not have a profile, the site should show to an unauthenticated user how to register, and how to get approval to access the site. — It should not simply show a blank screen, or a failure to authenticate message.

Just last night I was referred to a site that needed authentication.  I could see from the URL that I had never been there before.  But failing to authenticate left me with a completely blank page.  I had no idea how to register for an account.  I tried all the normal tricks: shortening the URL, etc.  Finally, I had to send email to someone, who sent me back a link to the registration page.  Why didn’t the failure to authentication give me this automatically?  Why do we make people be the critical path in giving users information about how to use the system?

6) A user registering with a particular email address must be accommodated whether there is a prior profile or not. — The site must not refuse access because there is already an account with that email address.

I recently tried to use a popular PHP-based forum.  Apparently, a couple of years ago, I registered for the forum, and created a user ID for my email address.  I have no idea today what that user ID was, but it absolutely would not allow me to make a new account with that email address.  Furthermore, it would not tell me the user ID, which was required to reset the password.  The whole thing is needlessly annoying.

Whatever account has my email address is clearly mine.  A user should be able to enter their email address, get the user ID, and reset the password, without needing an administrator.  Proving I own the email address is easy: send this information to that email address.  It’s as if the designers believe their system so special every user will remember a special ID just for it.  The email address seems to be an after thought.  More and more we are seeing the email address used for the login ID, eliminating this problem.

7) Every web site should offer a mechanism for password recovery, where the user enters an email address, and is sent a link that can be used to reset the password to a new value. — You should never need an administrator to reset the password.

Most cloud sites today offer password recovery, but still I see software inside the firewall lacking this feature – for example SharePoint.  The reliance on administrators makes this kind of software too expensive for the cloud.

Note that the service should never send the password in the email message itself.  Instead, it should send a link that allows you to reset the password.  This link should work only once, and should time out.  Passwords should never be sent by email.  Instead, a link, that offers one chance to change the password should be sent.  All traffic to and from the web site carrying the password should be HTTPS so that there is no possibility that the password will be seen by anyone without you knowing it.

8) The user should be able to specify an arbitrary display name that is used to indicate that user in the UI. — The email address should not be used for this purpose. The display name should be able to be changed at any time.

Once again, most cloud sites allow you to specify your display name.  Using your actual email address for display is rare, but some sites force you to specify a unique user ID and that is sometimes used for your display name.  The big problem is that the user ID can not be changed, because it is the key to access your information.  The solution is simple: allow the user to specify a display name, and allow them to change it any time they want to.  The best cloud software does this today.

9) The site should gracefully handle the situation when a user changes email address. — They should not be forced to create a whole new profile just because they are using a different email address.

Email addresses make good global IDs, but they are not permanent.  There are many reasons that a user may change email address.  The system has to be designed to support this.  Thus the email address can not be the key that identifies the user inside the system.  If done correctly, the user should be able to have any number of email addresses simultaneously.  The user simply adds the new address, and starts using that, ignoring the old email address, or deleting it if they wish.  Same should be true with OpenID or other ID systems like Facebook and Twitter.

Randy Farmer has a great write up on how this should be accomplished with a three part ID:   one part is the internal key, second part (multiple values) is the login globally unique ID like an email address, and the third part (multiple values) is the presentation or display name(s) that you may wish to use.  That design that allows all these guidelines to be met.

10) Web site should make a clear display of the information feeds that the user has subscribed to for email notifications. — User should never be prevented from unsubscribing from any notification streams.

Many, possibly most, cloud services include an unsubscribe link in any email message that is sent out.  This is just plain old web manners.  The list of subscriptions is less common, but something that a good cloud service should provide to the user.

11) A user should be able to deactivate their own account at any time, unsubscribing from all notification streams, and destroying all private data. — User should not be stuck with a zombie account.

The cloud service allows the user to register.  It stands to reason that it should allow them to un-register.  Safeguards should make sure that such a dangerous action is not taken accidentally, and there probably should be a period of time (a month?) within which this can be undone, but those are details.   Once deleted, it should indicate to others that the account is no longer active.

There is a lot of concern in the public that once you start a cloud account, there is no way to get rid of it. Note that deleting a profile does not necessarily means that all the posts you made are removed.  This will depend upon the type of service.  If you participated in a public discussion on a forum, then your forum questions and replies are part of the collaborative product of the site.  Notice that I said that “private” data is deleted.  Each site will have to determine what is private, and what is not, but if there is private information it should be deleted so that there is no way in the future to violate the privacy agreement.

12) There is no twelfth guideline

I have been reading way too much history recently, and it was the ancient Sumerians who introduced to the world the idea that things should add up to 12.  Eleven guidelines was simply not enough; one more was needed to fulfill the list.  However, this is a freebie:  if you satisfy the first 11 guidelines, you get the twelfth one automatically and for free.  Consider it a present from me to you, and a reward for getting the other guidelines correct!

Cloud User’s Bill of Rights – Summary

1. No New Name: A user should not have to learn a new user name.  A user should be able to bring their own user ID in the form of either an email address, or an OpenID.  — The site should not allocate a user name to the user, nor force the user to choose a user name that does not already exist on the server.
2. User Specified Password: Each user must have the ability to change their password as desired. — A user should not be forced to use a system defined password.
3. Unlimited Password: Each user should be able to use whatever password they desire.  — Passwords should not have arbitrary and unusual requirements. 
4. Context before Login: The site should show the user what it is they are logging into, before prompting for the userid and password. — The site should not pop up an authenticate box without showing any context that user is logging into.
5. Guidance for Registration: If the user does not have a profile, the site should show to an unauthenticated user how to register, and how to get approval to access the site.  — It should not simply show a blank screen, or a failure to authenticate message.
6. No Deadlocks: A user registering with a particular email address must be accommodated whether there is a prior profile or not.  — The site must not refuse access because there is already an account with that email address. 
7. Password Reset: Every web site should offer a mechanism for password recovery, where the user enters an email address, and is sent a link that can be used to reset the password to a new value.  — It should force you to get an administrator to reset the password.
8. Display Name: The user should be able to specify an arbitrary display name that is used to indicate that user in the UI.  — The email address should not be used for this purpose.  The display name should be able to be changed at any time.
9. Address Change: The web site should gracefully handle the situation when a user changed their email address.  — They should not be forced to create a whole new profile just because they are using a different email address.
10. Subscription List: Web site should make a clear display of the kinds of information feeds that the user has subscribed to received email notifications on.  — User should never be unable to unsubscribe from any or all notification streams.
11. Deactivation: A user should be able to deactivate their own account at any time, unsubscribing from all notification streams.  — User should not be stuck with a zombie account.
12. There is no twelfth guideline