2009/11/5 RayJames <cdlcollege.rayja...@gmail.com>
> Hi Michel, I think I might have confused you a bit. The user is not
> necessarily my concern.
Well... Then I guess it's not necessarily a good thing you design UI because
it's all about the user. Ultimately, you're designing machines to work for
humans, and when you're designing user interfaces you're at the "ultimate"
step before the human uses the tools. If the user is not your concern here
you've picked the wrong part of the job. Really.
> The code running in the background that sends
> calls to my api while the user is viewing the course is.
Of course it is.
> These calls
> consist of functions that Initialize the learner session, terminate
> the learner session, set and get values from the LMS as well as a few
> error handling calls.
Of course they do.
> Every time the course code calls the api the
> api is supposed to execute the call and return either data, true/
> false, or both.
Of course it is.
> The problem is that on the Initialize and Terminate
> calls, nothing should happen until the api returns a true or false.
Well, if by nothing you mean nothing both server-side AND client-side I
agree with you, you need synchronous calls. That will also prevent your user
from doing anything between the beginning of the call and the end. Even
scrolling the page, or opening an outside link in a new tab, anything AT ALL
until the call finishes. I don't know you but I find that drastic.
> Once that happens, then the other calls WILL just be called in the
> background async style while the user is engaged with the course. I
> think this is the best way, because putting a "waiting" class could
> result in longer waiting times for the execution of the functions and
> could still possibly timeout before the code finishes. What do you
> think?
I respectfully disagree, it is my informed opinion that adding a waiting
class will not result in significant performances losses unless you botch
the job (and I mean really botch the job, like adding the waiting class to
any element of the page instead of the topmost element that needs it) or the
calls are very close (and again I mean really very close, the kind of close
that would make your interface unusable because synchronous calls would
freeze it every odd second).
The only constraint here is that you round up elements that must not be
triggered between the beginning and the end of your pseudo-synchronous calls
and give them this little trigger :
$('.the_waiting_class .any_element_you_want_to_block').live('click',
function() { return false; });
The event will only be triggered when the targets match (so when
the_waiting_class is given to their common parent), it will work on elements
added to the dom during ajax or whatever script, and no user will notice any
performance problem as .live uses bubbling to catch the events.
I apologize for not making myself clear enough. This is
> actually a fairly complex system and will be awesome when finished.
>
I'm sure it will, but remember UI is one of the most important things that
make the difference between "awesome" and "I'm tired of this site that just
freezes on me, let's google away".
> Keep an eye on Drupal and wait for it to come out as a module. I will
> be opening all my code up as open source once it is finished. Thanks.
>
Hope you do well.
Michel Belleville
