sublog :

Why OpenID sucks from a user experience perspective

Wed, 17 Feb 2010 19:48:00 -0600

Many people seem to be touting OpenID as the next big thing in authentication. Early adopters request it, web geeks love it, and sites having it claim to be easier to use and more modern. The idea of maintaining only one login to access everything else sounds like a great idea until you thoroughly examine it. I personally have been considering the concept, especially since many Cashboard customers are requesting OpenID login as a feature addition.

What problem are we solving exactly?

The first gripe most people have with regular login systems is memory. There’s no doubt about it, maintaining all of the login information across your accounts can become tedious.

I personally have about 40 web logins and passwords I have to maintain for various services. The idea of having only one login to remember is nice, but is this really a problem?

Today all browsers allow you to save your login/password information, and if you’re worried about security you can always use a program to manage your passwords which also encrypts everything for safe keeping. Most password managers also have mobile versions for your phone so you can take login information with you on the go.

Replacing non-problems with confusion

OpenID claims to solve this memory "problem" another way, by providing one password to rule them all. It sounds good in theory, but in reality quickly it falls apart from a usability perspective.

I stumbled across a great article that explains the usability downfalls of OpenID which I suggest you check out. I won’t rehash all of the discussion there. Rather, I’d like to take a look at a real world example I personally ran into on Stackoverflow.

One can imagine the following thoughts racing through the average web visitor’s head when this screen initially pops up.

Huh?
Where’s the username and password fields?
I like Google, but don’t like Yahoo. Should I click Google?
What do I type here?
What’s my OpenID URL?

Even those that know what OpenID is could be challenged when presented a screen like this. I personally have a Google account, 2 Yahoo accounts, a WordPress account, and an AIM/AOL login. Which one do I use to login here?

At least with the majority of my other accounts I use a standard email address which I’ve been conditioned to remember. OpenID invents a whole new bag of problems, this being just the first.

New problems being invented with OpenID

I’ve actually logged into Stackoverflow before and had linked it with my Yahoo account. Returning to the StackOverflow site to ask a question I attempted to login with my Yahoo OpenID once again. The problem is, now Stackoverflow didn’t recognize my Yahoo OpenID.

Instead of being logged in after completing the OpenID process I was greeted with this screen.

I thought I must have forgotten which OpenID I used to login. Perhaps it was my Google account? Nope, not that one…not any of them in fact.

Feeling frustrated I finally stumbled to this page which is supposed to email your forgotten login information. I played roulette with my different email addresses, finally hitting one that it found acceptable.

When I received the "account recovery" email it told me something quite bizarre; I had linked my account to my Yahoo/Flickr OpenID. The problem is I had just deleted my Flickr account a couple of days ago thinking I would never use it again. Even though I still had a Yahoo account, I did not have my Flickr account. It turns out that you can actually have MULTIPLE OpenIDs through the same provider.

This is supposed to be better than a regular username / password combination how?

Unfortunately there is simply no way to ever login again to the site, or reset my account to be linked with another OpenID.

What a horrible user experience.

Where do we go from here?

I’m sure the example I ran into is just one of many usability scenarios that nobody has bothered to think through. Multiple this by the number of sites implementing OpenID logins and you can quickly start to imagine the myriad of usabilty problems being invented daily.

OpenID does solve a number of interesting security problems, but at the moment I think it’s not mature enough from a usability standpoint to be useful.

I hope the interaction problems surrounding OpenID continue to be worked on, as Yahoo is doing. They’ve conducted a very thorough usability study on OpenID, which I encourage you to read if you’re interested in the topic. It appears they’re making progress, but at a slow pace.

Alternatives

There seems to be a few great implementations of Facebook connect and Twitter oauth starting to pop up around the web.

I really like what Disqus is doing with blog commenting and linking to the social web, and I’m sure we’ll continue to see more interesting alternatives appear.

I’m interested to see where things go from here. Have you seen any great implementations of OpenID yet? Share them with me.

Making Workling::Return::Store predictable

Sun, 25 Oct 2009 02:56:00 -0500

This took me about 4 hours to figure out today, so I figured I might as well blog about it.

I’m using the Workling / Starling combo to handle background processing tasks on Cashboard for various things.

One of those things is the Cashboard / Basecamp project sync, which provides a really nice progress bar while it does it’s thing.

I was encountering unpredictable results when I started refactoring some code from the worker into various models, and stumbled upon this oddity.

&gt;&gt; Workling.return.set('foo', 'bar')
=&gt; &quot;STORED\r\n&quot; 
&gt;&gt; Workling.return.get('foo')
=&gt; &quot;bar&quot; 
&gt;&gt; Workling.return.get('foo')
=&gt; nil

I expected Workling.return.get to be a non-destructive action, but I was dead wrong. It turns out that the default Memcache Workling::Return::Store client acts like a first-in-first-out (FIFO) stack on each key.

Adding these methods allow me to use any Workling::Return::Store as I initially expected. This will add the methods to the default MemoryReturnStore (for testing), and the StarlingReturnStore (for dev/production).

Now I can run the following code with no problem.

&gt;&gt; Workling.return['foo'] = 'bar'
=&gt; &quot;STORED\r\n&quot; 
&gt;&gt; Workling.return['foo']
=&gt; &quot;bar&quot; 
&gt;&gt; Workling.return['foo']
=&gt; &quot;bar&quot;

Hopefully this helps someone bashing their head against the wall, like I was. Don’t hurt yourself.

Cashboard sponsors Rails Rumble 09

Fri, 21 Aug 2009 16:25:00 -0500

Each year since its inception we’ve sponsored the Rails Rumble by offering comped Cashboard accounts for each member of the winning teams. This year is no different as we’re providing free DYNAMIC accounts for all winners.

The Rumble is getting ready to kick off this weekend, with over 200 teams competing for top prizes from many different companies.

If you’re not familiar with the Rails Rumble, here’s a primer

The Rails Rumble is a 48 hour web application development competition. As a contestant, your team gets one weekend to design, develop, and deploy the best web property that you can, using the awesome power of Ruby and Rails.

As a judge, you get to review some fun new micro applications and help determine which teams fare best in a number of categories. Along the way, you might discover a new service that’s really useful or fun.

Oh yeah, and there are prizes too. For both contestants and judges. Sounds great, eh?

There have been many excellent entries in the past, some going on to become full fledged commercial services. If I were starting a new app this would be a great way to get some press for it, especially with the attention the event is getting from the business world.

I’m excited to see what this year’s contestants come up with.

Using concerned_with and autotest for Rails models

Wed, 06 May 2009 19:10:00 -0500

Cashboard is growing to be a huge software project, over 11k lines of code, written in Rails.

Some of the models have gotten extremely fat using Jamis Buck’s advice about "skinny controllers, fat models". One obese file in particular was causing me a ton of stress due to it’s massive content, even though I comment liberally and tend to break up sections in the code with large ASCII dividers.

To compound the stress, my unit tests were also getting extremely bloated and hard to read. I couldn’t tell if I’d tested a particular behavior at a glance. Things were becoming extremely hard to manage on both fronts.

I ended up searching out ways to break chunks of logic into separate files and finally settled on using the concerned_with trick for ActiveRecord.

Autotest problems

I’m a firm believer in using autotest while developing. There’s no way I could manage a huge project like Cashboard myself without it. I’ve come to rely on it.

The concerned_with trick is great to break up logic into multiple files for one model, but I ran into some issues with the trick and autotest.

All of my tests for a model were still crammed into one huge file and the unit test didn’t even run when I saved one of my new "concern" files.

Solutions

Through some trial and error, I stumbled across a wonderful way to structure all of my files and hooked up autotest to recognize them all properly. Hopefully it helps someone else out there fighting with the same issues.

Right now I’ve got my project structured like so.


  app/models/
  * account.rb
  * account/
  ** billing.rb
  ** validation.rb
  ** ...
  test/units
  * account_test.rb
  * account/
  ** billing_test.rb
  ** validation_test.rb

Using this layout, I’d expect the billing_test.rb file to get run by autotest if I saved the billing.rb file. This is quite easily accomplished by adding a .autotest file to the root directory of your Rails project – as described in this article.

The contents of my .autotest file automatically map my concerned_with files to my custom unit tests for model behavior.

Post subversion changes to twitter

Wed, 04 Feb 2009 15:45:00 -0600

Here’s a quick post-commit script for subversion that posts changes directly to www.twitter.com.

I’m using it to power the Cashboard twitter feed. If you preface any SVN commit message with "tweet" the rest of the commit message will be pushed to twitter.

Just modify the twitter username and password, then the script in your subversion "hooks" directory, and mark it as an executable (chmod +x post-commit).

Solo nintendo game developer's 100 day protest

Sat, 03 Jan 2009 10:08:00 -0600

Anyone who has ever thought of developing a platform game knows it’s a hard biz to crack. First you have to have a great concept, then you have to develop that concept into a marketable product. More often than not it requires you have a team of talented and motivated people working with you to achieve your vision.

On top of that Nintendo, Playstation, and the rest require you purchase a very expensive (multi-thousand dollar) software development kit from them and gain their approval of your title before releasing it. All of that is enough to discourage even the most motivated of people.

Bob is a solo developer who has created a 20-hour long 2D role playing game for the Nintendo DS – by himself.

Step back for a minute and think what that requires…better yet, I’ll quote him in his own words.

"bob’s game" is a sort of masterpiece for me. I’ve invested well over
15,000 hours into its development over 5 years of dedication-
That is no exaggeration, and it shows!

All concepts, story, code, sprites, tiles, music, samples, fonts,
etc. were created entirely from scratch by me- and I had to
teach myself the skills as I went along, with no training!

The code is straight C, the music is tracked, and the art is all
completely hand-clicked tiles and sprites- done the right way,
pixel by pixel, like the classics we all know and love.
I intend this to become one of the last great old-school
2D retail console games- truly the design of a single mind.

It’s the game I wanted to play when I was younger,
a vision I’ve been following since then.

This dude is a mad genius. A mad, obsessive compulsive genius. Some people are giving Bob a hard time on youtube, but I have nothing but respect for his effort. Anyone that can see out their vision with only their time and hard work is ok in my book. Props to Bob.

Problem is, Nintendo won’t even sell the guy a SDK so he can release his game on the Nintendo DS. Because of this, Bob is staging a 100 day protest. He’s locked and barricaded himself in his room, with friends delivering food once weekly. Man, he’s not just really smart and motivated – he’s crazy too! This could be the worst adult temper tantrum ever, or one of the most clever viral marketing campaigns to date. I can’t tell and I don’t really care. Gotta love a guy like that.

Anyhow, Bob would like for everyone to write Nintendo and tell them you want to play his game. Simple as that. Please take a few minutes out of your day to help him out. Crazy Bob should have the chance to succeed or fail, just like everyone else. There are a number of titles out for the DS that are of questionable quality, but they seemed to get released just fine. His game actually looks like something I might play.

Trailer for "bob’s game"

Designing like an engineer is bad for business

Mon, 22 Dec 2008 15:02:00 -0600

Making great software is a huge challenge.

The challenge only gets harder for those that have to wear multiple hats because of constraints, self-imposed or otherwise.

As most readers of the blog know I act as the main designer and developer for Cashboard (shameless plug #10384). This situation arose from many factors, but the main one being I wanted to get the product up and running under my own power. I’ve seen too many projects fail and I didn’t want anyone to blame on this one but myself.

I tell most people I’m a designer first, but I program out of necessity. Anyone in the software engineering field knows this is usually a bad idea and results in a shit product, yet I believe I’m able to pull it off because I’m able to "switch modes" or "switch hats" most of the time.

I’m damn good at what I do, but I’m definitely not above the classic problem. I routinely have to catch myself "designing like an engineer" instead of designing as a user experience person. Case in point, Cashboard’s "Account Preferences" screen.

The old screen is shown below in all of it’s fucked up, cluttered, and confusing failure.

This particular screen was built over time. Sections were added as the product grew, and it shows.

The design made complete sense to the programmer side of my brain. Sections of the screen directly map to functions of the code. As it usually turns out in situations like this, it was the exact wrong way to approach the design of that screen.

Non-relevant information is shown which clutters the view and detracts from the goal at hand. Things aren’t logically grouped from a customer’s point of view, and worst yet the screen has an overall busy look that’s quite perplexing.

There are two forms on the page, with two buttons, and a link to update other relevant information on yet another screen. (yuck!)

Preferences Screen Remix

Finally fed up with the design I took it upon myself to give that screen a makeover. Putting on my designer hat I busted out the design documents necessary, re-assessed the goals of customers visiting that screen, and had a revelation.

Customers of the app visiting this screen just want to update their preferences. They don’t care that changing their currency is a different operation from setting their date formats or billing address on the back-end, and they shouldn’t have to.

As with most design breakthroughs, this one was sitting right in front of my face. The solution was plainly there, yet I was missing it up until now because I wasn’t paying attention.

The updated design eliminates unnecessary information presented from the first screen, brings the "billing address" fields into the mix, and consolidates the multiple forms into one.

The result is a much cleaner looking form that actually makes sense for the goals at hand and is pleasing to look at as well.

As someone once told me – it doesn’t cost a thing to pay attention, but not paying attention can cost you dearly. True words indeed.

Import production SQL to your development box with Capistrano

Tue, 09 Dec 2008 21:48:00 -0600

I got sick of using Navicat to import production data from our servers in order to test it locally on a development box.

Here’s a quick Capistrano task that imports production data from your server to your development box locally.

This is great way to debug problems that are happening on your production server. It gives you the ability to mess with things locally without the risk of fucking up someone’s important data ;)

Killing lazy dogs

Tue, 09 Dec 2008 11:36:00 -0600

Sometimes working on one thing gets pretty tedious.

Last night while taking a break from Cashboard I had some fun and wrote a simple web app that was inspired by a design board I frequent often.

Kill the lazy dog is a small Ruby app written with Sinatra.

The objective is to come up with a pangram – a phrase that uses every letter of the alphabet.

Send any audio to your stereo system via airport

Mon, 17 Nov 2008 03:31:00 -0600

One of the gadgets I love the most is my Airport Express from Apple.

It gets the most use streaming audio from iTunes onto my stereo system. One major gripe I’ve had with the Airport Express is that I have to use iTunes to send music to it.

Luckilly I stumbled across Airfoil for Mac and Windows, which streams any audio on your computer to the Airport Express.

I’ve got it running with Pandora Radio right now, and it’s working perfectly.

I love technology.

UPDATE

I also must say, they have a genius way to make you purchase the damn software. They get you hooked listening to your favorite music, then overlay white noise on top of the broadcast after a few minutes and prompt you with a dialog to purchase.

Now if I could only build in something like that to Cashboard.