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