Modal dialogs

[Noah Botimer]

Posting to fluid-work after bounce...

On Jun 22, 2008, at 5:27 PM, Noah Botimer wrote:

> A couple of additional details and thoughts...
>
> The mod I did with SimpleModal was to primarily to achieve a "full- 
> screen" mode for some authoring work.  This is for editing pages  
> within a portfolio (stored as metaobj Forms), where the final  
> viewed content gets a whole window.  This was not the case with the  
> standard editing mode for Forms (a bunch of additional metaobj  
> markup/buttons in an iframe), so many things that would work in a  
> skin for the portfolios would not work in the authoring mode.
>
> The idea here is a high fidelity, WYSIWYG authoring experience.   
> The skinned portfolios were going to get a whole window, so the  
> only way to replicate this properly is to give the authoring mode a  
> whole window.  So, the primary modal stuff I've worked on is  
> leveraging an iframe in a huge dialog and using script to  
> communicate back to the controlling frame behind.  The iframe  
> source is really just a static page with a structural HTML wrapper  
> matching the portfolio skeleton, a skin, an FCKeditor, and some  
> buttons to fire a done-editing event.
>
> The nature of this work may be pretty different from a general case  
> where a "dialog box" is really needed -- maybe a div with a couple  
> of widgets, but nothing too complex.  There are, however, some  
> common considerations, such as the portal frame not loading  
> specialized CSS to drive the styles of your dialogs.  It may be  
> simpler in many cases to adjust the positioning code to deal with  
> the visible part of the tool iframe than to jump all the way out  
> and take on different problems.
>
> I've also done some work with another jQuery plugin called  
> Impromptu.  It seems pretty good and handles some of the typical  
> dialog box stuff automatically (yes/no buttons, etc.)  In general,  
> SimpleModal felt a little more natural to me, but YMMV.
>
> One thing that none of the plugins/libraries do (well, at least)  
> that I'm aware of is blocking the background input gadgets.  Things  
> like access keys in the frames and tab targets still get picked up.
>
> A technique that I've used (in tandem) to great effect is to hook  
> the onbeforeunload event.  In cases where it's really unsafe to  
> click away or use the back button, etc., it can save a lot of lost  
> work.  I actually set a flag when either the save or cancel button  
> gets pressed and allow those through -- everything else gets the  
> browser's standard "do you want to navigate away?" box with a  
> custom message.  I think this is a necessary safeguard, no matter  
> what dialog technique is used.
>
> Thanks,
> -Noah
>
> On Jun 22, 2008, at 4:18 PM, Jim Eng wrote:
>
>> In the authoring environment for Sakaibrary's Subject Research  
>> Guide tool, there are a few places where we need a modal dialog.  
>> We have been using the jquery.simplemodal.js plug-in for that  
>> (http://www.ericmmartin.com/projects/simplemodal/).  It works  
>> pretty well but there are some open issues.  In another project,  
>> Noah Botimer is using the SimpleModal plug-in and has outlined  
>> some changes he made to fix some of the issues we're having.  I  
>> haven't had a chance to look at Noah's work yet.
>>
>> I am writing to inquire whether anyone else is working on similar  
>> issues in sakai or implementing modal dialogs in other ways.  My  
>> hope is that we can agree on a standard approach to modal dialogs  
>> across sakai that will not have the problems we've encountered.
>>
>> Here's a brief description of the issues we are having:  When  
>> launched, SimpleModal covers our current document with a grey  
>> overlay (in a div) and shows the modal dialog in the center of  
>> that overlay.  There are two problems with the way we have  
>> implemented that using the SimpleModal plug-in.  First, our  
>> document is in an iframe, so only that part of the UI is greyed- 
>> out.  Ideally the entire sakai UI would be covered to make the  
>> dialog more fully modal (i.e. the user would need to dismiss the  
>> modal dialog before initiating some action within sakai but  
>> outside the modal dialog).  Also, the modal dialog is centered in  
>> the overlay, which may extend well beyond the visible portion of  
>> the document in the browser window.  The user may need to scroll  
>> up or down to see the modal dialog. I think it's likely that this  
>> is a problem in our configuration of the plug-in, but I haven't  
>> yet seen a way to fix that (still need to look at Noah's work to  
>> see whether this is addressed there).  Our most immediate need is  
>> to fix the positioning of the modal dialog so the user doesn't  
>> need to scroll to find it.
>>
>> My major question is whether anybody else is working with  
>> SimpleModal or other methods of implementing modal dialogs in  
>> sakai.  Is there already a preferred way to do this in sakai?  If  
>> not, does anybody have suggestions about how we should decide on a  
>> preferred way to do this?
>>
>> Thanks.
>>
>> Jim
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>