Modal dialogs

[Jim Eng]

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











----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org/portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Noah Botimer]

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
>
>
>
>
>
>
>
>
>
>
>
>
>

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org/portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Jim Eng]

On Jun 23, 2008, at 12:56 AM, Glenn R. Golden wrote:

> why modal?
>

Good question.  Two questions, really. Why do we want to use a  
"dialog" (by which we mean a separate "window" that pops up over the  
current document)?  And why would we want such a dialog to be modal?

The UI for the authoring environment shows the current state of a  
document being created/revised by the user, and it adds some editing  
controls.  This UI is intended to enable edit-in-place, as much as  
possible, to support users in creating/revising complex documents,  
maintaining the context of revisions within the user's view.  For text  
and headings, the user clicks in the text block and edits in place  
within the document, allowing the user to see the text above and below  
the current edit.  Clicking away to something else completes  the edit  
and preserves it within the document.  (In the current version of this  
tool, users can embed limited markup to format the text;  eventually  
that will be more wysiwyg -- using formatting controls rather than  
visible markup to format text.)

As in the wysiwyg editor (whether FCKeditor or TinyMCE), edit-in-place  
is not appropriate for some "types" of things.  A simple example of  
this is a "link" item, which contains a target (or "href")  and a  
label.  Call it "structured" content.  The "content" is specified by  
some set of attributes or metadata. When the user wants to insert a  
link, we prompt the user to supply the target and label.  We can't  
form a link unless we have both.  The form to create a link is not  
part of the finished document.  It's a helper to add structured  
content to the document.

For such structured items, it needs to be clear to the user (and to  
the tool) when an "edit" is complete -- what attributes are required  
and what user action(s) will successfully create/revise the element  
the user is attempting to create/revise.

All that's needed to add a text item is a character or two of text.  
The user can add any text and return to finish it later.  For  
structured types, there may be one or more required attributes before  
the item can be added.  Those dialogs need to be modal so it's clear  
to the user when we have a "complete" item that can be added to the  
document.

We could handle this by replacing the entire document in the tool  
frame with a form to create a link, but that would be disruptive,  
taking the user out of their current context to create a simple bit of  
content. It's likely to make the user forget the very information  
needed to complete the immediate task.  We want to maintain the  
context as much as possible to help the user maintain focus on the  
immediate task and its requirements.

Jim

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org/portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Jim Eng]

In spite of this lengthy response to what seemed like a simple little  
question, I missed something fairly important.  Another big reason for  
organizing tasks like this into little "pop-up" dialogs is that users  
are familiar with this way of structuring activity within a GUI.  It  
makes sense when a task is presented to us in this way.  It strips  
away complexity and helps us focus on the task and its requirements.

And when talking about modality, I don't mean that it should be hard  
for the user to dismiss such a dialog.  It needs to be clear when  
dismissing the dialog will result in losing work and when it will  
result in success at creating/revising the item.  In some cases, it  
could be as simple as clicking away from the dialog, as long as it's  
clear what effect that will have.

BTW, when I referred to the link's "target", I really meant the URL.

Jim


On Jun 23, 2008, at 7:36 AM, Jim Eng wrote:

> On Jun 23, 2008, at 12:56 AM, Glenn R. Golden wrote:
>
>> why modal?
>>
>
> Good question.  Two questions, really. Why do we want to use a  
> "dialog" (by which we mean a separate "window" that pops up over the  
> current document)?  And why would we want such a dialog to be modal?
>
> The UI for the authoring environment shows the current state of a  
> document being created/revised by the user, and it adds some editing  
> controls.  This UI is intended to enable edit-in-place, as much as  
> possible, to support users in creating/revising complex documents,  
> maintaining the context of revisions within the user's view.  For  
> text and headings, the user clicks in the text block and edits in  
> place within the document, allowing the user to see the text above  
> and below the current edit.  Clicking away to something else  
> completes  the edit and preserves it within the document.  (In the  
> current version of this tool, users can embed limited markup to  
> format the text;  eventually that will be more wysiwyg -- using  
> formatting controls rather than visible markup to format text.)
>
> As in the wysiwyg editor (whether FCKeditor or TinyMCE), edit-in-
> place is not appropriate for some "types" of things.  A simple  
> example of this is a "link" item, which contains a target (or  
> "href")  and a label.  Call it "structured" content.  The "content"  
> is specified by some set of attributes or metadata. When the user  
> wants to insert a link, we prompt the user to supply the target and  
> label.  We can't form a link unless we have both.  The form to  
> create a link is not part of the finished document.  It's a helper  
> to add structured content to the document.
>
> For such structured items, it needs to be clear to the user (and to  
> the tool) when an "edit" is complete -- what attributes are required  
> and what user action(s) will successfully create/revise the element  
> the user is attempting to create/revise.
>
> All that's needed to add a text item is a character or two of text.  
> The user can add any text and return to finish it later.  For  
> structured types, there may be one or more required attributes  
> before the item can be added.  Those dialogs need to be modal so  
> it's clear to the user when we have a "complete" item that can be  
> added to the document.
>
> We could handle this by replacing the entire document in the tool  
> frame with a form to create a link, but that would be disruptive,  
> taking the user out of their current context to create a simple bit  
> of content. It's likely to make the user forget the very information  
> needed to complete the immediate task.  We want to maintain the  
> context as much as possible to help the user maintain focus on the  
> immediate task and its requirements.
>
> Jim
>
>

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org/portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[colinbdclark]

Jim,

Apologies for responding to this thread so late. It got lost in the  
whirlwind of conference travel and preparation.

Fluid is using the Dialog widget from jQuery UI 1.5 for our Uploader  
component.  It seems to work pretty well for us, and it has some nice  
features. You can try out a working demo here:

http://ui.jquery.com/functional_demos/#ui.dialog

At the moment, we're working on adding keyboard navigation and ARIA  
support to Uploader for the Infusion 0.4 release. As part of this  
work, we're going to make the jQuery UI Dialog accessible, too. If all  
goes well, I hope these improvements will be included in an upcoming  
release of jQuery.

As for your specific issues, I don't know how it would work within an  
iFrame, but I suspect this is a common problem.

Noah had mentioned problems with some dialog where they weren't truly  
modal, allowing users to navigate via keyboard outside the document.  
The jQuery UI Dialog does seem to correctly swallow both mouse and  
keyboard events outside of the dialog, so it functions in a truly  
modal way.

Hope this helps,

Colin

On 22-Jun-08, 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
>
>
>
>
>
>
>
>
>
>
>
> ----------------------
> This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org/portal 
> ) from the DG: Development (a.k.a. sakai-dev) site.
> You can modify how you receive notifications at My Workspace >  
> Preferences.
>

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Jim Eng]

Thanks, Colin.  That helps a lot.

The jquery dialog looks good.  It doesn't entirely solve the problem,  
but it looks like it might be better than the simplemodal we are using  
now.

I put the URL for the sample page you sent  
(http://ui.jquery.com/functional_demos/#ui.dialog) into the  
web-content tool in sakai and set the frame height to 2400 pixels.  
That simulates the case we have for the SRG authoring context.

The modal actually shows up off the screen in that case, centered in  
the 2400-pixel tall space, but the tool frame scrolls so the top bar  
of the dialog is visible at the bottom of the frame.    I had to  
scroll the frame manually to see the content of the dialog, but at  
least I could see the top bar of the dialog box.  Also, it seemed to  
be modal for everything inside the iframe but I could use buttons in  
the top-level of sakai (the iframe's parent).  And when I used the  
modal dialog with overlay, the overlay covered the iframe only -- not  
the entire browser window.

These results are not surprising.  To get it tow work otherwise, we'd  
need the contents of the page in the iframe to invoke javascript and  
manipulate the DOM in the top-level browser window.

It seems to me that we will need this capability unless we dump the  
iframes entirely (a good goal even without this additional  
motivation).  Maybe we'll want to figure out a way to make the modal  
dialog appear in the top-level sakai window even though it's launched  
by a script inside an iframe.

Jim



Quoting Colin Clark <colin.clark@...>:

> Jim,
>
> Apologies for responding to this thread so late. It got lost in the  
> whirlwind of conference travel and preparation.
>
> Fluid is using the Dialog widget from jQuery UI 1.5 for our Uploader  
> component.  It seems to work pretty well for us, and it has some  
> nice features. You can try out a working demo here:
>
> http://ui.jquery.com/functional_demos/#ui.dialog
>
> At the moment, we're working on adding keyboard navigation and ARIA  
> support to Uploader for the Infusion 0.4 release. As part of this  
> work, we're going to make the jQuery UI Dialog accessible, too. If  
> all goes well, I hope these improvements will be included in an  
> upcoming release of jQuery.
>
> As for your specific issues, I don't know how it would work within  
> an iFrame, but I suspect this is a common problem.
>
> Noah had mentioned problems with some dialog where they weren't  
> truly modal, allowing users to navigate via keyboard outside the  
> document. The jQuery UI Dialog does seem to correctly swallow both  
> mouse and keyboard events outside of the dialog, so it functions in  
> a truly modal way.
>
> Hope this helps,
>
> Colin
>
> On 22-Jun-08, 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
>>
>>

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Noah Botimer]

Jim,

I haven't done it for the jQuery plugin, but I did this "breakout"  
work with SimpleModal in Sakai.  I'm pretty sure I detailed the  
specifics earlier in this thread, so I won't go over them all again.  
But there is definitely some maneuvering required.

Probably the most painful thing is that the CSS for the dialog is  
generally not available in the portal frame where it has to launch.  
I worked around it by doing inline styles via jQuery's .css() stuff.

There may be a mechanism for a tool to inform the portal of a  
required CSS resource, but I think that's edging some brittle work.  
The portal frame may persist while the needs for tool resources  
change -- not a pretty or workable situation since you can't load or  
unload CSS dynamically with any level of reliability.

Thanks,
-Noah

On Jul 24, 2008, at 2:43 PM, Jim Eng wrote:

> Thanks, Colin.  That helps a lot.
>
> The jquery dialog looks good.  It doesn't entirely solve the  
> problem, but it looks like it might be better than the simplemodal  
> we are using now.
>
> I put the URL for the sample page you sent (http://ui.jquery.com/ 
> functional_demos/#ui.dialog) into the web-content tool in sakai and  
> set the frame height to 2400 pixels.  That simulates the case we  
> have for the SRG authoring context.
>
> The modal actually shows up off the screen in that case, centered  
> in the 2400-pixel tall space, but the tool frame scrolls so the top  
> bar of the dialog is visible at the bottom of the frame.    I had  
> to scroll the frame manually to see the content of the dialog, but  
> at least I could see the top bar of the dialog box.  Also, it  
> seemed to be modal for everything inside the iframe but I could use  
> buttons in the top-level of sakai (the iframe's parent).  And when  
> I used the modal dialog with overlay, the overlay covered the  
> iframe only -- not the entire browser window.
>
> These results are not surprising.  To get it tow work otherwise,  
> we'd need the contents of the page in the iframe to invoke  
> javascript and manipulate the DOM in the top-level browser window.
>
> It seems to me that we will need this capability unless we dump the  
> iframes entirely (a good goal even without this additional  
> motivation).  Maybe we'll want to figure out a way to make the  
> modal dialog appear in the top-level sakai window even though it's  
> launched by a script inside an iframe.
>
> Jim
>
>
>
> Quoting Colin Clark <colin.clark@...>:
>
>> Jim,
>>
>> Apologies for responding to this thread so late. It got lost in  
>> the whirlwind of conference travel and preparation.
>>
>> Fluid is using the Dialog widget from jQuery UI 1.5 for our  
>> Uploader component.  It seems to work pretty well for us, and it  
>> has some nice features. You can try out a working demo here:
>>
>> http://ui.jquery.com/functional_demos/#ui.dialog
>>
>> At the moment, we're working on adding keyboard navigation and  
>> ARIA support to Uploader for the Infusion 0.4 release. As part of  
>> this work, we're going to make the jQuery UI Dialog accessible,  
>> too. If all goes well, I hope these improvements will be included  
>> in an upcoming release of jQuery.
>>
>> As for your specific issues, I don't know how it would work within  
>> an iFrame, but I suspect this is a common problem.
>>
>> Noah had mentioned problems with some dialog where they weren't  
>> truly modal, allowing users to navigate via keyboard outside the  
>> document. The jQuery UI Dialog does seem to correctly swallow both  
>> mouse and keyboard events outside of the dialog, so it functions  
>> in a truly modal way.
>>
>> Hope this helps,
>>
>> Colin
>>
>> On 22-Jun-08, 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
>>>
>>>
>
>

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Jim Eng]

Thanks, Noah.  We had a number of issues with simplemodal.  I think  
the jquery dialog may be better as a general purpose solution in sakai.

If tools will still be in iframes for a while and if more than one or  
two tools need to use modal dialogs, it seems like we might want the  
portal to have the scripts and css that are needed to let tools  
overlay the entire window and have a modal dialog appear above the  
overlay.  But to do that, we'd need to agree on what we will be using  
throughout sakai and what specific files would need to be in the  
top-level document.  If the fluid widgets are included in the portal,  
we may get everything to support the jquery modal dialog there for free.

A couple questions: is there overhead to having jquery (or support for  
some other modal dialog) in the top-level document, and (if so) is it  
worthwhile to do this?

Jim



Quoting Noah Botimer <botimer@...>:

> Jim,
>
> I haven't done it for the jQuery plugin, but I did this "breakout"  
> work with SimpleModal in Sakai.  I'm pretty sure I detailed the  
> specifics earlier in this thread, so I won't go over them all again.  
>  But there is definitely some maneuvering required.
>
> Probably the most painful thing is that the CSS for the dialog is  
> generally not available in the portal frame where it has to launch.  
> I worked around it by doing inline styles via jQuery's .css() stuff.
>
> There may be a mechanism for a tool to inform the portal of a  
> required CSS resource, but I think that's edging some brittle work.  
> The portal frame may persist while the needs for tool resources  
> change -- not a pretty or workable situation since you can't load or  
> unload CSS dynamically with any level of reliability.
>
> Thanks,
> -Noah
>
> On Jul 24, 2008, at 2:43 PM, Jim Eng wrote:
>
>> Thanks, Colin.  That helps a lot.
>>
>> The jquery dialog looks good.  It doesn't entirely solve the  
>> problem, but it looks like it might be better than the simplemodal  
>> we are using now.
>>
>> I put the URL for the sample page you sent  
>> (http://ui.jquery.com/functional_demos/#ui.dialog) into the  
>> web-content tool in sakai and set the frame height to 2400 pixels.  
>> That simulates the case we have for the SRG authoring context.
>>
>> The modal actually shows up off the screen in that case, centered  
>> in the 2400-pixel tall space, but the tool frame scrolls so the top  
>> bar of the dialog is visible at the bottom of the frame.    I had  
>> to scroll the frame manually to see the content of the dialog, but  
>> at least I could see the top bar of the dialog box.  Also, it  
>> seemed to be modal for everything inside the iframe but I could use  
>> buttons in the top-level of sakai (the iframe's parent).  And when  
>> I used the modal dialog with overlay, the overlay covered the  
>> iframe only -- not the entire browser window.
>>
>> These results are not surprising.  To get it tow work otherwise,  
>> we'd need the contents of the page in the iframe to invoke  
>> javascript and manipulate the DOM in the top-level browser window.
>>
>> It seems to me that we will need this capability unless we dump the  
>> iframes entirely (a good goal even without this additional  
>> motivation).  Maybe we'll want to figure out a way to make the  
>> modal dialog appear in the top-level sakai window even though it's  
>> launched by a script inside an iframe.
>>
>> Jim
>>
>>
>>
>> Quoting Colin Clark <colin.clark@...>:
>>
>>> Jim,
>>>
>>> Apologies for responding to this thread so late. It got lost in  
>>> the whirlwind of conference travel and preparation.
>>>
>>> Fluid is using the Dialog widget from jQuery UI 1.5 for our  
>>> Uploader component.  It seems to work pretty well for us, and it  
>>> has some nice features. You can try out a working demo here:
>>>
>>> http://ui.jquery.com/functional_demos/#ui.dialog
>>>
>>> At the moment, we're working on adding keyboard navigation and  
>>> ARIA support to Uploader for the Infusion 0.4 release. As part of  
>>> this work, we're going to make the jQuery UI Dialog accessible,  
>>> too. If all goes well, I hope these improvements will be included  
>>> in an upcoming release of jQuery.
>>>
>>> As for your specific issues, I don't know how it would work within  
>>> an iFrame, but I suspect this is a common problem.
>>>
>>> Noah had mentioned problems with some dialog where they weren't  
>>> truly modal, allowing users to navigate via keyboard outside the  
>>> document. The jQuery UI Dialog does seem to correctly swallow both  
>>> mouse and keyboard events outside of the dialog, so it functions  
>>> in a truly modal way.
>>>
>>> Hope this helps,
>>>
>>> Colin
>>>
>>> On 22-Jun-08, 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
>>>>
>>>>
>>
>>
>
>
>
>

Jim Eng
jimeng@...
734-647-6976
----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.

[Jim Eng]

I misspoke.  The jquery UI widgets are not part of the standard jquery  
package (a version of which is already included in the portal).  
They'd need to be added in, which means there would be some small  
additional overhead loading the portal.  Worthwhile?

Jim



Quoting Jim Eng <jimeng@...>:

>
> Thanks, Noah.  We had a number of issues with simplemodal.  I think
> the jquery dialog may be better as a general purpose solution in sakai.
>
> If tools will still be in iframes for a while and if more than one or
> two tools need to use modal dialogs, it seems like we might want the
> portal to have the scripts and css that are needed to let tools
> overlay the entire window and have a modal dialog appear above the
> overlay.  But to do that, we'd need to agree on what we will be using
> throughout sakai and what specific files would need to be in the
> top-level document.  If the fluid widgets are included in the portal,
> we may get everything to support the jquery modal dialog there for free.
>
> A couple questions: is there overhead to having jquery (or support for
> some other modal dialog) in the top-level document, and (if so) is it
> worthwhile to do this?
>
> Jim
>
>

----------------------
This automatic notification message was sent by Sakai Collab (https://collab.sakaiproject.org//portal) from the DG: Development (a.k.a. sakai-dev) site.
You can modify how you receive notifications at My Workspace > Preferences.