Always assume the call you’re making will work.

Some context for the above, I recently got sick of my iPhone and decided to give Android a spin, side-stepping the obvious discussion here, one of the things that has irked me about the Android experience is that it just doesn’t feel as responsive as the iPhone for certain applications, specifically email. So I started to compare the two and realised that the iPhone reacts to my interactions immediately whereas Android seems to wait for approval from the server. This eye-opening discovery led to me imposing a new standard here at Moov2:

Every user interaction must have an immediate and obvious reaction.

Proud and smug feelings of wearing my user experience hat were soon interupted when challenged to explain wtf I actually meant by this. So, for example, deleting an email from a list of viewed email messages. When I hit delete I expect that message to be removed from the list and if that happens as soon as I press the delete button, I’m a happy chap. Conversely, if I have to wait, even a couple of seconds, I may think I missed and try hitting it again… and again… etc. So developers, quite simply, as soon as that delete button is hit, remove the message from the list and THEN send your call informing the server to do it’s part. This approach can be applied to pretty much any application development that involves a rich user interface, Flash, Flex, Silverlight, AJAX, Android, iPhone, native desktop apps and whatever.

But what if something goes wrong?

Of course, just throwing the message away willy-nilly is reckless, there’s a whole host of things that could prevent that message from being deleted. The user might be offline, the email list might not be up to date or there may just be some other bug elsewhere making the delete email process just plain not possible at the moment. In this case, sheepishly, politely and unobtrusively, let your user know the fact and pop the email back where it came from. This will obviously be a nuissance to the user, but how often does this really happen in comparisson to how often it works? Very rarely, and it’s no less annoying for the user than having to sit there waiting with no response only to find out the action failed.

What if I NEED the response in order to update the UI?

So deleting is a fairly convenient example because we’re taking away from an already viewable interface, what about if we’re adding to our interface based on the response from our call? For example displaying the list of emails in the first place. Well, for this I suggest you present all of the interface elements that you know are going to be available and just provide some indication that something else is going on to reassure the user that their input has been acknowledged. So when the user chooses to view their inbox, immediately react and change the view, present them the ‘Inbox’ title, show them any user controls they might be able to interact with and display the space those messages are going to load into with some form of preloader/spinner and note indicating their messages are being retrieved.

So take a minute and review your result handlers to see how much UI stuff is being done there. Could it be moved to before the call was made? This sometimes means you need to think about how to best back-track when things go wrong but for the 95% of the time when you just get the result you’d expect you’ll deliver a MUCH more responsive feeling interface that your users will thank you for.

By the way, if you’d like to actually see some code demonstrating this concept tweet the following message to Pete who has prepared a very clean implementation of this for a Flex application we’re currently working on: “Hey @peterkeating, codez pls http://bit.ly/f8HOyp. I’m sure he’ll oblige with a sample soon enough.

I left a comment there but whilst it’s in moderation but it’s raised some more thoughts for me so thought it deserved it’s own post.

Tony writes about how an investment in user experience is driven by supply and demand of said experience. In slow moving uncompetitive markets, this added value of a slick user experience isn’t necessary and therefore is unlikely to receive heavy recognition and investment. You only need to look at many banking systems, trading platforms and data entry software to believe this is the case (N.B. these being slow movers rather than uncompetitive).

Tony also mentions the example of router interfaces as something that blatantly receives little UX attention because it’s more appropriate for router manufacturers to compete on price rather than improving user experience.

The general cycle of things seems to be as follows:

1 – New product enters market, has no competition, focuses on functionality over form, it works, it does the job, reaches x% of market.
2 – Competition appears, attention on products grows, market grows, slice of pie desired grows, product’s prices reduced.
3 – Prices reach lowest reasonable point, value needs to be added, user experience rears its head, flash/flex guy gets a new contract.

This sucks. And in my view is stupid. At point 3 we’re still trying to generate more sales/users/whatever so we try to build desire through improving the product experience. Yet we’re now making less per unit than ever before.

Had we invested in a suitable UX in the first instance the costs of doing so would have been less (I.e. not having wasted time and money on the first iteration crappy implentation), we’d have a much better, more desirable product, we’d have benefited from the additional interest whilst we’re charging a premium and we’d be raising barriers to entry for any future competition.

You could argue the new interface extends the product lifecycle which would otherwise have dropped off sooner but in my opinion the advantages of doing it right first time far outweigh that.

Niels Bruin responded with what I think is a very good wake-up call to the starry eyed approach to reviewing web apps with lots of transitions, reflections and other shiny bits. Niels highlights some real basic usability faux pas that Firebrand made such as mystery meat navigation, red punishing looking confirmation messages and inconsistent design touches.

To be honest, I read all the commotion and Niels put down before I looked at the site and to be fair to Firebrand I probably wouldn’t have picked up on those points myself. But then I’m not and would not claim to be a UX hotshot of any kind. The key point for me is that the points raised by Niels do not require a magical usability eye and could very easily be a printed checklist and implemented as part of a quality control assessment before final delivery of a product. To be fair I do also agree with the points Ryan makes in his followup and I’m also all too familiar with things such as expectation and deadlines which can all to easily prevent this much-needed attention to detail. However, if we keep reminding ourselves of it then hopefully it will become second nature and not needed as a time consuming afterthought.

If you’re responsible for the creation, delivery or quality of a customer facing project, take 20 minutes, open up your word-processor of choice (perhaps use it as an opportunity to try out Buzzword) and hack together a simple list of quality control checks.

Here’s a handful of checks plagerised from Niels post and an old post I remembered by Aral to get you started, copy the below and paste into a document, print out 10 copies, run through your current project and tick each one off and you’re well on your way to becoming a quality control engineer!

Niels’ Firebrand wrist-slap:

• Make sure any icons/metaphors are extremely obvious or explained with tooltips or other indicators
• Make confirmation messages look positive and warnings look like warnings (I.e. don’t positively confirm an action in red)
• Is everything laid out consistently? How much effort would it really be to tweak that button a few pixels to line up properly?
• Can familiar controls be used in a familiar manner? E.g. can I scroll a scrollbar using my mousewheel, drag it and click up/down arrows?
• Have you tested on all likely platforms/browsers? At least WinXP, Vista, Linux, OSX with IE6 & 7, Firefox, Safari, Opera

Aral’s old post on UI principles (interpretation by moi for checklisting purposes):

• I can use it but am I a ‘typical user’? Even better: can I get an intended user (or several) to use it?
• Does validation “prevent not scold”? Does the user get scolded “YOU IDIOT, WHY DIDN’T YOU SELECT A GENDER BEFORE CLICKING THAT BUTTON?!” or do we just make the button un-clickable until the gender has been selected with some unobtrusive instruction to do so?
• Does the user receive sufficient feedback? If the user makes an interaction, is it obvious that interaction has been acknowledged by the app and the expected result has happened? (see Niels point on adding to faves).

There’s a load of other things that can be added to this list, for generic testing and I’m sure for specific audiences/companies/application types etc. I’m going to do some digging on other principles people have come up with as I know there are a ton out there but whilst this is topical I thought I’d add my opinion and throw in a call to action to anyone reading.

It’s not really a new concept rather than a different outlook on the “widget” concept. It is also something that Apollo is an ideal platform for developing.

In Ryan’s post he demonstrated use cases of when to focus on a browser app vs when to focus on a desktop app. One of the points about when to target the desktop was:

You’re building a “widget” application. Widgets are becoming bigger and bigger (in terms of capability) and you just can’t run a widget platform inside the browser. Widgets need to be accessible from the desktop, where they can take up a small space and be easily moved around. The browser restricts that too much.

He then asked for other ideas to which I responded:

Something that I’ve been harping on about a bit lately is the opportunity of a “desktop web service” (service in the desktop sense, not a web service). So that’s not too clear and a better term is needed, I think an example is in order:

Say you were a trader and wanted to be notified when certain things happened to rates/markets. With a desktop app you can have a form of service (or invisible app) that runs in the background watching the trading web services, when something pertinent happens you can fire into action informing the user.

This is a use case for a desktop app as you don’t want the user to rely on having a browser window open on a specific website.

Clear as mud? Wicked, I think i need to go away and create this application to aid my ill-eloquent thoughts-to-text abilities.

Ryan alerted me to the fact that my suggestion IS a widget of sorts. However, for myself, the term widget conjurs up the image of a small funky looking app that runs on your desktop and is used for fun, interest or time-passing E.g. weather reports, RSS readers, traffic warnings etc. In light of this I hadn’t associated my example (a corporate or enterprise type application) with the term “widget”.

So an “enterprise widget” is essentially a widget with or without a UI which can run as a desktop service until some event or action happens that would require further interaction with it (or another desktop or web application).

Another idea that could be classed as an enterprise widget is
Grant Skinners gTimer – I don’t know the specifics of this (it looks very cool and a something I’ve been wanting for a long time) but it could potentially run as an invisible application on your desktop (or just an icon in the system tray) and only prompt for client/project details when you open/close files and applications. Therefore negating the need to conciously update your timesheets when you switch projects.

Basically any action you need to take that needs to be responsive to some event or information change you can setup an enterprise widget to monitor activity and prompt with the necessary action based on certain flags. E.g. you could have an RSS reader that spurs you into a blogging frenzy whenever anyone mentions a specific term or technology you’re interested in.

Apollo seems to be the ideal choice for developing such enterprise widgets because of it sits squarely on the line between desktop and web. Making use of web services, desktop presence and desktop chromelessness (a word I just invented) are all key elements of the enterprise widget.

I’m not sure “Enterprise Widget” is the best term because, as I mentioned earlier, I don’t associated “widget” with a business tool but maybe that’s just me or maybe there is an existing definition that might be a better fit. I initially referred to it as a “desktop web service” but that was just plain confusing. Ideas?

During Rob’s presentation on Optimising visual interfaces for the human brain something was brought up that I hadn’t considered previously; the difference between “Intuition” and “Conditioning”. This wasn’t a major part of the presentation but something that got me thinking nonetheless.

Intuition, for the sake of this discussion, is similar to instinct, they are a form of common sense that perhaps cannot be associated to any specific learning experience.
Conditioning, is a more manufactured type of action that we may perform, we’ve been told to do it this way, we’ve been doing it like this for some time, so when we want to do something, we’ll try to do it this way.

The above are two very crude explanations, I have no psychological knowledge and so have drawn these explanations from the presentation last month and some brief further reading. Please feel free to offer any comments below, agreeing or otherwise.

Anyway, what has this got to do with interface design? Actually quite a lot I have realised. Usability is obviously a very important factor of interface design, the user has got to instantly feel comfortable with their environment and almost know where to look and what to click in order to achieve a desired action. Even if they have never before performed this action. When designing an interface, we have to make a concious decision on whether we feel it is appropriate to target a user’s intuition, conditioning or both or even if there is a distinction between the two.

This is perhaps best explained by example, of which there were several in Rob’s presentation which I am unashamedly going to borrow.

Here are two “OK” / “Cancel” dialogue prompts, one is for Mac one is for Windows. Despite aesthetics, the fundemental difference between the two is that for Mac the Cancel option is to the left, for Windows this is to the right. Aparently, the rationale for Mac putting their cancel button on the left and the OK button on the right is because it is synonomous with the Escape and Return keys on a keyboard. I would assume the Windows approach is based on the typical left to right reading and expected order of events, confirm or reject.

Another example is one I thought of whilst getting my mind in knots trying to get my head around this. If I were to launch a completely new program, with a save option, it would be perfectly reasonable for me to offer access to the save feature by way of a floppy disk icon. Why is this? Is a floppy disk icon the most intuitive approach? No it’s probably not, I’m sure many new and younger computer users wouldn’t even know what a floppy disk was (maybe most would at present but give it another few years), when was the last time you saved to a floppy disk? This is what I would consider conditioning, we’re used to doing it this way so we’ll continue to do so even if it might not be the most appropriate approach for new and future users.

I’m not sure there is a distinct line between intuition and conditioning. It almost seems as if they are both results of a way we get used to doing things only intuition is more towards being hard-wired as part of who we are as opposed to conditioning being something we are more recently used to doing. Thats not to say i think intuition is not affected by our development within our individual surroundings. For example, would someone who reads arabic, or other right to left language, expect to see the first option on the right, second on the left? Do operating systems even take this into consideration in translated versions? It’s all food for thought but definitely worth bearing in mind when thinking about your application audience. If you get a chance do check out the online video of Rob’s presentation as there is a lot more interesting and useful information about much more than just intuition.