Modal dialogs

[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