Users are patient right? I mean...it's ok if after they click on something to throw up an indeterminate spinning cursor isn't it?

Want to get a taste of what it feels like? Click on this guy (start sort)...

[ source: Native Sort (stalls UI) ]

Nobody likes an unresponsive application - even if it means taking a small performance hit. What I am talking about is perceived performance. Click on this next guy (start sort) and I'll fill you in on the details.

[ source: Non-blocking Native Sort ]

The second example takes a little longer to run... but it felt a little better seeing things blink a little didn't it? Nirvana comes to Flash developers who embrace the rendering cycle. Huh?

    private function foo():void {
        barObject.x = 10;
    }

The little sample above moved the object to x position 10 right? Well... not immediately. That function queued a position change for the object that will be executed in a rendering cycle; code execution and rendering typically don't co-exist. If you haven't read my last post about the elastic racetrack... it might help clear this up a bit.

What I'm doing isn't magix... it's just an AVM / rendering friendly implementation of a long running or complex process. There are developers out there that have gone to great pains to implement pseudo-threading or event based models to chunk big tasks. Whatever suits you best... but the important part to remember is the pit in your stomach when you clicked on the first example.

A good user experience doesn't always have to be sub-second... but it does need to be responsive. Presenting the user with significant feedback (not just a spinning cursor) about the process at hand is a deadly tool in the hands of a UX ninja. Obviously there is a trade-off to accomplish this; what I'm suggesting isn't a silver bullet by any means and should be implemented judiciously. What's the takeaway?

Performance can be quantitative or qualitative... but above all keep your UI responsive no matter what path you have to go down!