> Why not just make non-modal Dialogs / Wizards 'Editors' (i.e. site them in the editor area with their own tabs...)
Strongly agree. Years ago I actually coded a toolkit to make it easy to implement such things, and I could probably reproduce something similar if we wanted to experiment with it.
> I don't think this would fit. One expects an editor to be a way to view and change a file. Dialogs have another purpose which is to "actively" interact with user
> without necessarily being related to a file or a modified artifact.
I disagree. I ran this experiment once by implementing this paradigm in an Eclipse-based product. The user feedback we got from it was overwhelmingly positive. In one case we ran the opposite experiment of replacing several of these editors (we referred
to them as "edilogs") with dialog boxes and there was immediate negative feedback. Users prefer the edilogs.
> IMO, dialogs and editors are better being kept separated, or it will become more complex for users to figure out where to find the interaction they want and what kind of
> effect they can expect from the items shown in the usual editor stack.
Users are already familiar with the paradigm of having an editor that isn't associated with a file, since this is what any modern web browser uses as its UI paradigm. We've all used a wizard embedded in an editor every time you've signed up for a forum
account, and most of us probably never noticed. If anything, users are more familiar with this than they are with dialog boxes.
In the case of my experiment, above, we ran a lab UX study and none of our participants were confused by it.
> Fair enough...try 2...how about having a single window hosting all currently active Wizards / Dialogs, each with their own tab
Sure, it's good to consider lots options when brainstorming, but your first suggestion was brilliant. Let's not give up on it so quickly.