Man, that felt like an ass chewing but I needed it. :) I am going to
do some more homework and see how to put the advice you gave me to
good use. Thanks for your time Michel. I really appreciate it.
Ray James.
On Nov 5, 2:42 pm, Michel Belleville <michel.bellevi...@gmail.com>
wrote:
> 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
