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 > > _______________________________________________ fluid-work mailing list [email protected] http://fluidproject.org/mailman/listinfo/fluid-work
