The Joy of Flex

When building a UI in Flex, a common situation is to play some kind of effect as a result of a user action. Take the simple case of the user pressing a button which causes an item to move nearby. If you want to use an effect to animate the item as it moves, then you have to consider the possibility of more user input while the effect is playing.

Consider the following UI: you are building a toggle button that controls some component, and when the user presses it, the component switches between two different ways of displaying itself. What should happen when the user clicks repeatedly on the button, faster than the duration of your effect?

I can think of six different ways to deal with this situation.

Approach 1: Play all the effects at the same time. In some ways this is the easiest thing to do. Your button handler probably creates an effect and tells it to start playing. So just let the effects manager deal with multiple effects playing on the same target. It knows how to do that, and as best as I can tell, it allows all the effects to run simultaneously but only allows one effect at a time to actually modify the target’s properties. This may work, but if your handler does things like create child objects and add and remove them, you may get into a lot of trouble with extra objects stacking up on the display list, depending on how well your code handles the re-entrancy.

Approach 2: Ignore additional clicks while the effect is playing. This is easy enough to do too, but will be a lot less satisfying to the user. Particularly in situations where the user clicks a second time right at the end of the effect and you ignore that click, the user’s experience will be that the button just didn’t work. You can make it clearer what’s going on by disabling the button during the effect, but it will still feel unresponsive.

Approach 3: Queue up the user input and then execute each one after the previous one’s effect is done. This works fine for one or two extra clicks, but it turns into a bigger problem if the user clicks repeatedly, because the UI ends up wiggling back and forth long after the user has stopped clicking, with no way for the user to stop it.

Approach 4: Remember the last value of the toggle button clicked while the effect was playing, and just execute that one when the effect stops. This is effectively the “musical chairs” approach: when the clicking (“music”) stops, the UI then proceeds to the final state of the toggle button.

Approach 5: Reverse the effect. When the user clicks while the effect is playing, just run it backwards. This is the most responsive of all the approaches, because the user gets instant, smooth feedback to the additional click.

Approach 6: Use states and transitions. If you set up the effect declaratively with states and transitions, then you get what someone on the Flex team decided you should get in this case, which appears to be that on the overlapping click, it ends the current effect immediately and starts the next one.

I’ve coded up all six of these approaches to make it easier to visualize how they each behave. They are all different, though in some cases the differences are very subtle. Play around with them and see which ones you like best.

The code isn’t anything to write home about, and in fact the point of this whole post is not so much how to implement these approaches, but how to think about different ways to handle effects in response to user input. None of these approaches is inherently right or wrong, and for each one of them, I bet I could come up with a situation where it would be the best choice.

That said, I have included the source, so you can view it by right-clicking on the example and picking “View Source”.

View the examples.

Technorati Tags: ActionScript, Effects, Flash, Flex