From reading through the various responses on this post, I believe one very feasible and worthwhile solution to asynchronous UIs is to maintain what has been referred to as a transaction log somewhere in the UI for the user to be able to see containing all requests and their subsequent status/response message when the proper event fires. This would assume that any actionable items would trigger immediate changes to your UI in favor of the "success" case. It would be up to you as to whether you'd like to revert that scenario in the scenario that a failure occurs in an event response.
This would remove the dreaded "blocked UI" scenario because everything appears to happen instantaneously, however there would be failsafes in place when something goes wrong (the infrequent scenario).
To me it seems more a matter of order reversal in how we handle AJAX calls (assuming you aren't using an async/evented system).
I can, however, think of downsides. Take, for instance, a scenario where you may have a nested tree of actionable items that may have prerequisites on the other's completion. You could chain the events, but you might end up with a queue unbeknownst to the end user. Worse, a failure might occur at the parent level which leads to failures for all subsequent calls. I myself am not sure what the good alternative to this might be in terms of non-blocking UIs.
This would remove the dreaded "blocked UI" scenario because everything appears to happen instantaneously, however there would be failsafes in place when something goes wrong (the infrequent scenario).
To me it seems more a matter of order reversal in how we handle AJAX calls (assuming you aren't using an async/evented system).
I can, however, think of downsides. Take, for instance, a scenario where you may have a nested tree of actionable items that may have prerequisites on the other's completion. You could chain the events, but you might end up with a queue unbeknownst to the end user. Worse, a failure might occur at the parent level which leads to failures for all subsequent calls. I myself am not sure what the good alternative to this might be in terms of non-blocking UIs.