Amadiere.com

Fourteen and a half crazy frog burpers

20th November 2010

OpenID is NOT an ex-parrot!

Filed under: Human Factors,Usability,Websites — Tags: , — Alex Holt @ 2:01 pm

I’ve read a few Tweets recently that OpenID might be dead. Poppycock! OpenID is alive and kicking and as strong, if not stronger, than ever before.

An ex-parrot

What is OpenID? OpenID is a means of identifying that someone who’s visiting your site is the same person as someone who’s already been here. The was traditionally with Usernames and Passwords. If you successfully signed in, we assumed you were the same person. OpenID provides that level of authentication. It basically sends back a little message from the provider (e.g. Google) saying “Yo dude, not spoken in a while, but this customer you asked me about? Well it’s <INSERTGUIDHERE>. Just go ahead and log them straight in or create them a new account”. I now don’t need to store passwords as a website – this is great news!

Rob Conory (of Tekpub) recently wrote a very excellent article “Open ID Is A Nightmare” in which he proceeds to outline his case for why OpenID is turning into a nightmare for him. It’s an entertainingly written article in Rob’s quirky style that outlines his viewpoints as both a developer and as a business owner. The latter point, as he goes on to say, is the key criteria in why he’s reached the point he’s at at the moment.

A friend of mine was offering a ton of solutions to my Open ID woes over Skype the other day – insisting that it’s worth “investing in for the long run – the kinks will get worked out”. I sort of agree as a dev – as a business owner I couldn’t give a rat’s ass.

He is smart guy and has a number of very relevant points that anyone considering using OpenID should be thinking about. He had a number of OpenID unrelated issues (RPXNow downtime), but they all contributed to the main gripe he had about things: customers were unable to get into his site, a site they’ve paid to get access to. This is a key point. People are PAYING to watch the content over at Tekpub and through no fault of his own, they were unable to get in. The problem is easily wafted away, waving your hands in the air and saying “this is a user problem!”. The user created an account and then forgot which provider they logged in with in the first place! What fools! Let us all gather around a camp fire, eat sausages and laugh at their pathetic attempts at life. Except – lets not forget Tekpub’s audience. It’s techies. It’s developers. It’s people like us. If WE are capable of getting confused and lost as to what is going on – then the anecdotal ”mum” is going to struggle a hell of a lot more.

The bonus and one of the driving forces behind OpenID is the supposed “reduced friction” when creating an account with a site. As Rob points out, there is the issue because we can effectively get so little back from the OpenID Provider, that we’d be unable to dig out the account from the mass of other accounts with no additional data. The users account is effectively orphaned until they remember the provider they signed up with. Locked out and angry.

This debate took a whole other level of LOL when Scott Hanselman tweeted:

Is OpenID dead? Poor usability to blame?

For some bizarre reason, the Twittersphere decided that that was neither a question, but an official announcement from Microsoft that OpenID was about to fail. When in reality, it was in relation to Rob’s above post. Humourous to those unaffected, but I can imagine quite irritating and stressful to Scott.

What is wrong with OpenID?

OpenID is fantastic at doing what it’s does, but there is definitely room for improvement. Maybe not in OpenID itself, but in the way it is implemented. Some of the key things that I personally think developers need to consider when designing a login system that uses OpenID are:

  • Each Account should be able to have more than one Login method attached to it.
    This is something I think people have inherited from years gone by. Traditionally, an account has a Username and a password, and nowadays maybe an OpenID field too. In reality, the user should have the ability to add whatever authentication methods your site allows, to their account. A one-to-many relationship from Accounts to Logins. E.g. I might sign up with my Google account, then decide later that I want to create a Username and Password for whatever reason. Then a bit later, I spot you have Facebook Connect as an option – cool, I’ll attach my Facebook account to this site too. Now where am I? I have 3 ways of getting into my account. That’s great news – that’s a lot easier for me as as long as I guess one of them randomly when I’m prompted – I’m sorted.
  • Upgraded accounts require more information.
    The low barrier to entry should be set for standard users, but the minute you decide you want to upgrade them (make them a moderator or take payment for a service from them), you should require more information to make sure you can trace things when issues arise. Requiring this would have given Rob the facility to offer a “forgotten your password?” function on his login page that would solve the issue that paying customers couldn’t get in.
  • The ability to merge accounts.
    Unfortunately, people have lots of different accounts around the internet. They will probably, as Rob did when trying to access StackOverflow, get into your site using the wrong one and in the process, create a brand new account. In theory, what they wanted to do was log in as the correct one and then maybe add this new provider to their list of available logins. This is a tricky problem to solve, but it’s doable. You want to offer the option for a user to merge their two accounts, copying whatever appropriate data to their primary account. If you can achieve this, then you’re giving the users the ability to solve their own problems – great! And even if they don’t, you have a nice UI for doing it on their behalf.
  • “WTF does OpenID mean?”
    Seriously. I’m have no ready solution for this problem – but people don’t know what OpenID is and that’s because it’s techie. We probably need to drop the OpenID words from headings to merely part of the description for clarification, when displaying our Authentication Options. People should just be offered the choice of which site they want to authenticate via: Google, Yahoo!, Facebook or whatever. The issue still remains that people don’t exactly understand still what it means that they are being “authenticated by Facebook”. Half of them won’t care that they don’t know, but for the other half, you probably want to re-assure them of what it is that they are allowing you to do. I don’t want some random site I’ve just stumbled upon telling everyone on Facebook that I’ve done XYZ on website ABC. I think the OpenID selector is good – but is it perfect? Not really – it works for me and is very simple to use – but it doesn’t answer any questions you might have as a customer. As a developer, you need to do that. You need to ease their fears.

If I was creating a site now, would I use OpenID? ABSO-FRICKIN’-LUTELY! It’s great and makes it so easy to actually log into to a site. If I can transfer that ease-of-access to the customer, while not freaking them out – then I’m onto a winner! Is OpenID an ex-parrot? Not at all – it’s here for the foreseeable future in my opinion. And that is a great thing!

12th February 2010

The Biggest Bits Are The Little Bits

Filed under: Human Factors,Usability — Tags: , , — Alex Holt @ 9:56 pm

There is the excellently accurate sentence attributed to Tom Cargill that goes:

The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.

This (fairly humorous) statement is a dig at all those projects that are developed and that overrun, but with a more than significant amount of truth in it. There can be a number of reasons why the project may not appear on time. Often, it’s because someone is trying really hard to avoid accepting the fact that the Project Triangle exists for their solution. The triangle states that there are always three options: Do it Fast, Do it Cheap & Do it Good – but of the three options, you can only have two. You as project manager have to negotiate with your stakeholders, which of the three are the two most important ones – because there is flying-pig chance that you’ll be able to get all three of them. They aren’t mutually exclusive – but achieving all three is certainly something that is seldom heard of for a project.

I believe these two things are linked. I think that projects overrun because the project early on was “Do it fast & do it cheap”, but near the end and as people start to inspect the system, people (whether it be the Stakeholders, End users or development team) decide that they need to do it well at the sacrifice of doing it fast. This could be argued as bad project management – but in reality, it’s bad Stakeholders. I believe they were correct to concentrate on quality However, they were grossly wrong to have considered leaving it as the third priority in the first place – it should have always been first! Take your pick as to which of the other two is important to you, but unless your project is technically fantastic and the attention to detail is there – then you might not have bothered doing it at all!

Jeff Atwood has eluded to this in the past in response to comments that Stack Overflow would be an easy system to build. He implies that yes, while the functionality would be really simple to replicate, all the little details would be missing, all the little improvements for both technical speed boosts / efficiency savings and for ascetics and intuitiveness for the user. You can spend your time doing 90% of Stack Overflow in 1 week, but then you’ll spend the remaining 90% of time faffing with the little details that will make your site stand out.

These little things can totally ruin your project / website / company, if you do not spend the time bowing before them in homage. There are plenty of website’s out there which don’t do justice to their potential. Websites that for some reason, got to the 90% of the way into their project and implement 90% of the features and functions – but then were put off by the long hard slog of the home straight which is the last 90%. The details beat them into submission! I’m not saying you have to be a designer to produce a good looking site, (it helps and I’d recommend that people get someone on board who specialises in functional website UI design), but if you don’t set your sights too high, then patience and an understanding of CSS will normally do. If you spend this time sorting out all the little things (the font size, the position of your error messages, your link positioning etc), your project will find its bounce-rate significantly reduced (a good thing!) and the general happiness of frequent users will be improved as they don’t have to work as hard to get the same amount of work done as your system is more intuitive.

Strive for perfection, excellence will be tolerated. If you are passionate about your project and you feel that you want to produce the best “whatever” in the world – then make sure you spend your time on the details! It’s sometimes a long hard slog, but it is invariably worth it in the end.

Theme designed & built for Amadiere.com by Alex Holt. Powered by WordPress