Modal dialogs

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