Make a specific window for each task the user must perform. All of the information needed to complete a task should be available in the Few Panes of the window. Assume prerequisite tasks have been completed (if they haven't, the user will simply change windows.)
This pattern effectively side-steps gross problems Model View Controller once had with mutually-dependent windows. Semiconductor Test Systems Group engineers knew exactly what tasks their users performed. There were only five or six and they could be done independently.
This pattern's called "Task Window" (c2.com 
) in the Smalltalk Best Practice Patterns.
I even suggest using the task name (which may come from the steps in a use case description) as the title of the window. This tells the user explicitly where in the use case he is (not that he knows it's a use case :-) ), and helps you to adhere to the rule of Window Per Task. I know this can work out fine in very small systems; I don't know about bigger ones. --Falk Bruegmann
I'm not entirely comfortable with Window Per Task. Smalltalkers get pretty good at WPT, and even they can get confused unless they use really good window arrangement discipline (a thing I have not fully learned). I've seen relatively inexperienced users get really confused with multiple windows. I think single windows may be better for the inexperienced. Any experimental data known out there? --Ron Jeffries
I reviewed a large utility program once that had 1200 windows. It may have followed WPT, but I doubt it. At Life Tech, we had two windows, a Navigator which supported the task of finding information and a Task Editor which supported the task of changing information. The users knew exactly which of these to use when. Modes?! Oh! The Humanity!
Re: Smalltalk's design. I think the problem is that the windows don't support a whole task. Just as the Object Explorer puts a bunch of Inspectors in a single window, there is a UI waiting to happen which puts a bunch of senders/implementors browsers in a single window. The Refactoring Browser also helps alleviate window pollution. --Kent Beck
Re: Window Per Task: I think that it is not intuitively obvious that a "task" maps to a single window in each case. One example can be found in the "wizards" used commonly in Microsoft Windows and other software to accomplish more complex "tasks." Is a wizard a Window?
Maybe the "outer" window could be a task, and the inner window (which may have not visible borders) is specific to each step of the wizard. Thus, sub-windows become sub-tasks.
If you think of each window as a small tool that does one thing well, this is in the finest tradition of application design and KISS. Assuming the requirements negotiation went well, this also means you are mapping a window to each storyboard panel, which in turn maps to an ideal use case. There are some of us (well, maybe just me) who wouldn't think of doing it any other way. --Marc Thibault
Inductive User Interface
As far as I can tell, the "Inductive User Interface"
) seems to be the same as Window Per Task.
See original on c2.com