jimeng at umich.edu
Mon Jun 23 11:36:59 UTC 2008
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
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.
More information about the fluid-work