“Innovation has nothing to do with how many R&D dollars you have. When Apple came up with the Mac, IBM was spending at least 100 times more on R&D. It's not about money. It's about the people you have, how you're led, and how much you get it.” - Steve Jobs

Time is relative – Time is a key aspect we design

Designing rich internet applications (RIAs) is 50% about designing time perception. To me this is such an unconscious thought, that when I get slapped in the face as I have just this morning trying to communicate with my team about this issue, it really reinforces why I believe so so strongly that we need to be so much better at defining and articulating what it is we do and the value it provides.

I’ll be teaching a workshop at the IA Summit that deals with this topic and others related to the design of rich applications (internet or otherwise).

it is important to understand your role as interaction design as one of story teller. Just like a book author or movie director, pacing (managing time) is a primary component of success criteria for the success of your product’s experience by the audience, or end-user. Brenda Laurel’s work comparing Computers to theater speaks directly to this.

I’m currently working on a desktop application project and it amazes me how similar desktop application problems are exactly the same as web-application projects, just in robe of different acronyms. So instead of HTML, JavaScript, AJAX, DHTML, etc., I’m looking at .NET3, C#, WPF, etc.

In both cases though it is really clear that developers and product managers don’t understand what an interaction designer does. They are so concerned with metrics of the UI that they don’t understand that context greatly determines the perception of those metrics.

In desktop applications maybe the # of clicks might be looked at, but what is looked at more (at least in this case) is “performance”. they’ll stop watch application and screen change load times as if that is somehow a valuable measure of experience. Like, when’s the last time a user held their watch up to a screen after clicking or double-clicking? And even if that value is bad, is that the only thing going on for the use at the moment when that event is taking place. I mean we are multi-tasking, multi-aware people who get distracted fairly easily because we are always either prey or hunting.

So instead of seeing opportunities to mitigate poor performance experience as a part of the interaction design, which would take advantage of cognitive pulls and pushes to sway perception of time, they are stuck on the stop watch.

First off, it is important to realize that this is my fault as a designer. My communication of the problem and the solution have not been good enough and this is where prototypes come in. Unless things are experienced then they are not easy to understand. It is also why I believe in interactive digital prototypes. They are so easy with tools like Flash and Blend that there is really no reason to do paper anymore. Just different levels of fidelity of interaction.

But let’s get back to time. What does it mean to mitigate the perception of time. Too many multi-syllable words in there, eh?

1. Animation – This is probably your best source for making time appear to proceed faster. Movement implies forward motion and motion occurs over time.

2. predictive content management – the better you understand the flow of your users the more you can put in a preload treatment to your design so that the user doesn’t have to wait for something that should be dynamically generated at the point of interaction. Call this predictive caching if you like.

3. smaller chunks – This is more akin to streaming, but if you can break up your interface to load in smaller units, with the overall framework to load first and then apply the details as necessary. if you are running a query to a large data set, you can find ways to steam in the table instead of waiting for the table to complete using methods such as passive scrolling.

Don’t treat all interaction moments as equal. Loading an application is different type of initiated action than a menu-drop down. The first type of action can be mitigated with “tricks”; the 2nd type of action really needs to flow well at the point of initiation and thus needs to be pre-loaded as much as possible. To tell the difference between the two is to get a sense of the user’s perception of change. The more change they are experiencing the higher their pain threshold is for that change. Obviously, the result has to add value to them so that they get the right Return on Investment, which in this case means an investment of pain.

In the end, performance is but one issue or constraint that a designer needs to deal with and there are many tools in our chest to help mitigate the issues associated with performance whether it bandwidth from networks or CPUs.

Be Sociable, Share!


The archives run deep. Feel free to search older content using topic keywords.