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
