Wiki page detailing ATutor/Lightbox integration

[Michael S Elledge]

My two cents: It's also important for persons with disabilities to have 
explicit event activation, although activation behind the scenes using 
the Enter button would be okay so long as they are adequately informed 
in advance.

Mike

Greg Gay wrote:
> Hi Joseph
> We only present 10 images per screen, so there would be 10 updates going
> on each time an image is moved. In most cases this won't be a problem,
> for smaller installations, but on larger ones, with many people moving
> images at the same time, potentially hundreds of calls to the database
> and the webserver are being made. And, if there are 20 images per screen
> etc., that number increases even more.
>
> My preference would certainly be to eliminate the submit button. You're
> right, some people may not even know they have to use the button,
> particularly if you can't see it. For systems like Sakai, which caters
> to bigger institutions, with higher end hardware and faster networks,
> auto submit on move probably won't be a problem. But, ATutor also caters
> to less "connected" clientele, who may be using lower end hardware, and
> slower Internet connections, so we're going to default to the manual
> save order method for now. They can always change that setting by
> uncommenting a single line in the gallery code to change the setting to
> save on move.  We'll probably end up making this a configurable option
> at some point, unless we can cut back some on the hardware load and
> network traffic.
>
> Let me know if you do come up with a way to minmize the load.
>
> greg
>
> Joseph Scheuhammer wrote:
>
>   
>> Hi Greg,
>>
>>     
>>> We also discovered by accident that the lightbox generates a submit
>>> event when an image is moved,
>>>       
>> Part of the reason for doing this is to maintain state if the user
>> leaves the page and later comes back.  A concrete case I can point to
>> is Sakai's image gallery tool, where the user might switch galleries
>> in the middle of rearranging thumbnails in one gallery.  When they
>> switch back, they expect the last thumbnail order they saw to be
>> maintained.  It's undesirable to force them to hit a submit button
>> before switching out -- users will likely forget to do that (if they
>> even know that they have to).
>>
>> The submit event is an ajax call and the result is ignored by the
>> Lightbox JavaScript code.  If network traffic is a concern, then
>> perhaps the information submitted could be minimized.  At the moment
>> it submits a form with an input for every thumbnail in the box.  I'd
>> have think about how that might be made smaller and still communicate
>> enough information to tell the server how the order has changed.
>>
>>     
> _______________________________________________
> fluid-talk mailing list
> fluid-talk at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-talk
>
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: elledge.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
URL: <http://fluidproject.org/pipermail/fluid-talk/attachments/20080214/d507b776/attachment.vcf>