As long as you find your way b^^d
Kind regards, and keep us updated.
Michel Belleville
2009/11/6 RayJames <cdlcollege.rayja...@gmail.com>
> 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
>
