Yes, very important to show immediate feedback so the user knows what's going on; shocking how often that isn't done. In many cases, just that alone is going to prevent the OP's scenario with the impatient user.
But unless it's unavoidable/inappropriate, I'm not a fan of that preventing other actions. The number of times I've clicked the wrong thing and been frustrated because I couldn't do what I wanted to do until the thing I didn't want to do finishes... So my take is: Offer immediate feedback, and if it's *appropriate* or necessary disable other actions but not if you can avoidit; offer a way of cancelling anything that will take any time (which is nearly anything), whether it's an explicit "cancel" widget or just initiating a different action. I can totally see some widget, perhaps something appropriate for scripteka, that could be general enough to handle this reusably. [Travis, with my pedantic hat on: Your "ParallelRequestManager" is actually a *serial* request manager (the requests are handled in series, not in parallel); your SerialRequestManager is more of a *single* request manager... ;-)] -- T.J. Crowder tj / crowder software / com On Jul 2, 5:52 am, "Ryan Gahl" <[EMAIL PROTECTED]> wrote: > Well, it does sound quite sensible, if not a bit heavy for your specific > problem (which, by the way is not rooted in the transport layer, but in the > UX layer... the user experience). The crux of your problem is that the user > is clicking something again. Why? Because he is unaware that anything is > going on from the first click (i.e. your request is taking longer than the > user expects and you give no indication that something is happening). The > most common pattern, which for all intents and purposes works and is far > less complicated to implement than the "request queue", is to implement a > "Loading..." shim that renders everything underneath it unclickable, and > goes away when the call returns. > > Now... if you're hellbent on implementing the "request queue"... let me know > and I'll offer up some suggestions (we have done something similar for other > issues). BUT, the answer I gave above is IMHO a more accurate solution if > you objectively look at the real issue. > > > > On Tue, Jul 1, 2008 at 7:18 PM, Travis Miller <[EMAIL PROTECTED]> wrote: > > > I'm looking for a good pattern that prevents AJAX requests from > > overlapping. > > > Consider this scenario, using an address book application as an example: > > > 1. On the left side of the page, there's a list of contacts. On the right > > side, there's a box that shows the currently selected contact. (Only one > > contact can be open at a time.) > > 2. The user clicks on a contact to open it. > > 3. The app initiates an AJAX request, but it takes a while. Maybe the > > server has to do some extra processing for some reason. > > 4. The user gets impatient, and clicks on another contact before the first > > one has loaded, which initiates a second, parallel AJAX request. > > 5. The second contact loads immediately, and the user starts working with > > it, but then... > > 6. ...the first AJAX request finally completes, and the first contact gets > > loaded over the second! > > > Obviously, the first AJAX request should be canceled if a second request of > > the same type is issued while it's still running. > > > Here's what I'm thinking: a generalized utility class - say, > > SerialRequestManager - designed to handle all situations of this type. Sort > > of a wrapper around Ajax.Request. A setRequest() method would accept an > > Ajax.Request object (and, if one is already set, destroys the existing one > > first); you'd probably want a cancelRequest() method, as well. The same > > class could hide and show an activity indicator. > > > To stray from the original problem a bit: a variant class - > > ParallelRequestManager - could add incoming requests to a queue, rather than > > destroying existing ones; it would show the activity indicator when the > > first request was added to the queue, and hide it when the last remaining > > request in the queue completes. > > > Does any of this sound sensible? :) > > -- > Ryan Gahl > Manager, Senior Software Engineer > Nth Penguin, LLChttp://www.nthpenguin.com > -- > WebWidgetry.com / MashupStudio.com > Future Home of the World's First Complete Web Platform > -- > Inquire: 1-920-574-2218 > Blog:http://www.someElement.com > LinkedIn Profile:http://www.linkedin.com/in/ryangahl --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
