Is there a design pattern for dealing with overlapping UI actions and animations

Question

Is there a design pattern for dealing with overlapping UI actions and animations? A few examples:

Let's say I have an interactive table row that expands to reveal an extra control when the user clicks on it, and vice versa if they click on it again. If the user clicks on the row while the expand animation is in progress, I want it to stop animating and shrink back to its original size from the place where it stopped.
I have a set of rows from example 1 inside a group. When the last row is deleted, I want the group to shrink and then remove itself in a callback. However, while the group is shrinking, the user could still add another row to it. If that happens, I want the group to stop shrinking, expand to the correct size, and add the row.
What if I have a sorting function for the UI in example 2? If the user clicks on the sort button, the rows shuffle and animate into their new positions. However, I still want the user to be able to click on table rows, delete rows, and do everything else that my UI allows. The UI should behave sensibly, with the shuffle animation taking precedence.
You could automatically fast-forward all animations for a UI element when a new action is performed on it, and/or block user input in all animating UI elements. But that seems inelegant to me. As a user, I really admire UIs that don't stutter or block me from doing what I want

Explanation / Answer

You do want to attach animations to table rows while keeping their interaction capabilities untouched. A decorator fits in here: it'll manage the animation, while forwarding user interaction events to the decorated object. Note that the animation by itself isn't important here, and it'd suffice for it to be a (mere) parameter of the decorator object (thus letting us to reuse the same decorator class with arbitrary animations). Also, this way you can have an arbitrary number of animations simultaneously active over the same row, just by nesting decorators; the visual result is another story :)

If we take a step back and look for the big picture, though, even from the point of view of the user interface animations are only details -if well more or less tricky to deal with, and definitely of great relevance in order to provide a good user experience. But they aren't the focus. A generic scheme could be like this:

The user asks the system for an action to be performed, by means of whatever predefined input event.
The system schedules the user's command. Immediate execution should not be assumed here, unless explicit requirement.
The system executes the user's command, and this takes an arbitrary amount of time and tasks (between whom animations can be counted) to be performed. Here, the system can (begin to) execute commands sequentially or concurrently, depending an the scheduler and the dependencies between the requested actions.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.