Wiki page detailing ATutor/Lightbox integration

[Michael S Elledge]

Hi Greg--

I think we're on the same page here. My point was that having the Submit 
button isn't necessarily a bad thing. It may not be as clean as having 
an auto-execute mechanism, but it has the benefit of letting people know 
that they have to do something to make it work. Where we've run into 
problems in Sakai is when an item (like a link in a dropdown menu) will 
activate by someone pressing a down arrow, when they're trying to scroll 
down instead.

Mike

Greg Gay wrote:
> Hi Mike
> Explicit in what sense?
>
> Forms normally function with a button, so apart from including words
> like "press the button..." to make it clear that a button needs to be
> pressed when images are moved, I'd expect most screen reader users would
> expect to look for a button.
>
> What might be more difficult to implement is dynamic output of the state
> of the moved images, including perhaps announcing the new position, and
> that the order has been saved.  Currently there is no such indication,
> though I know this is in the works for .02.
>
> greg
>
>
> Michael S Elledge wrote:
>
>   
>> 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/8e06e43e/attachment.vcf>