botimer at umich.edu
Sun Jun 22 21:39:55 UTC 2008
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.
> 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?
More information about the fluid-work