Two weeks ago Sam Stevenson, 37signals hacker and creator of the widely used Prototype JS library, gave a scoop on some of the under-the-hood changes to the latest release of Backpack.

After getting a chance to play with the new user interface I must say I’m totally unimpressed. It seems a lot of the initial subtle design decisions by Ryan Singer and Jason Fried have been lost, forgotten or simply compromised in favour of a super-simple back-end implementation.

Creating a new list

Take for example the task of creating a new list and adding a few items:

Three subtle and simple problems which make this interface less than ideal:

1. Having to wait for a server roundtrip when creating a new list
2. Having to wait for a server roundtrip when adding a new list item (slowing down keyboard-efficient input)
3. Not focusing the text field when adding a new list item (eliminating simple keyboard-only input)

I’ll ignore point 3 as a simple bug, though a pretty glaring one considering it eliminates keyboard-only input and would be an oft-used and highly repetitive action.

Nonjax: AKA Synchronous Ajax

Why force the user to wait for a server roundtrip to create a new list? Why force the user to wait when adding a new list item? And no, I won’t accept the answer: “but we saved 500 lines of code by making everything powered by RJS”—that is a simple engineering problem.

Adding a list item requires absolutely minimal validation and a simple result from the action: adding the new list or item to the page. Why not just go ahead and do it, assuming that everything is AOK?

Pete from Unspace hit this nail on the head in Facebook Just Gets It Right (emphasis mine):

If we can be confident that a transaction will succeed, then why not immediately update the user interface to reflect that they have performed an action, and not interrupt the flow?

...the status quo is that you click on a link or button, and the site is programmed to pop up a spinning status notification while it fetches new content from the server. When the transaction has completed, your interface is restored and the user can continue navigation.

Just because Ajax itself is asynchronous – you send a request and wait for it to succeed or fail – that’s not how good user interfaces work, ever. Facebook assumes your action will be successful, because 98% of the time it will be, and the price of failure is quite low.. perhaps a status error box.

You’ve got the same sorts of issues when deleting list items:

Each time you have to confirm the popup and then waiting for a HTTP response—clunky! Not to mention good ‘ol fittsy: on a 24” monitor with a browser that centres popups it makes for a lot of mouse cruising between the item’s trash can icon and the “OK” button in the dialog box.

Facebook Get It

The Facebook designers seem to be creating much more efficient UI in the async/Ajax department. Take for example marking messages read or unread:

Notice the marking and unmarking of messages happens instantaneously where possible, with other parts of the UI waiting for the roundtrip.

User interface items you directly interact with should react as quickly as possible. If you kick a ball towards a goal post you expect it to immediately roll along the ground as a result of your action. When you mark a message as read you’re expecting the message to immediately change status.

The same level of thought seems to have gone into the interface for deleting messages:

When deleting a message they remove it instantaneously and then updated the other bits of the UI with a roundtrip to the server. You’ll also notice there’s bug in the count at the bottom of the message list. You’ll also notice the confirmation dialog is position near where the mouse hit the “Delete” link.

37signals going the way of the UI dodo

With only two UI brains and a bunch of Rails and Javascript engineers that are obviously making design decisions I don’t like the odds of 37signals being able to produce the same polish that made their apps a hallmark of web user interface design.

Speedy Rails development: a blessing or curse?

I always loved the fact that Rails was the perfect “magic behind the attractive and well designed curtains” (think Ryan Singer and Jason Fried handing DHH a well-designed prototype to bring to life) but it seems the majority of Rails applications launched in the past few years were driven by back-end design rather than front-end design, resulting in ugly interfaces and inefficient interactions.

It’s easy to get caught up in RJS, REST and all the juicy back-end technologies whilst forgetting what makes a truly elegant user interface: well thought out design with attention to detail; the same attributes that go into making an elegant Rails back-end.