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 FewPanes 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 
ModelViewController once had with mutually-dependent windows.
SemiconductorTestSystemsGroup 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" (http://c2.com/ppr/ui.html#3) in the SmalltalkBestPracticePatterns.

----
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 WindowPerTask. I know this can work out fine in very small systems; I don't know about bigger ones. --FalkBruegmann
----
I'm not entirely comfortable with WindowPerTask.  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?  --RonJeffries

I reviewed a large utility program once that had 1200 windows. It may have followed WPT, but I doubt it. At LifeTech, 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 ObjectExplorer 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 RefactoringBrowser also helps alleviate window pollution. --KentBeck

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.  --MarcThibault
----

'''Inductive User Interface'''

As far as I can tell, the "Inductive User Interface"
(
http://www.howtodothings.com/showarticle.asp?article=790
http://msdn.microsoft.com/library/en-us/dnwui/html/iuiguidelines.asp
)
seems to be the same as Window Per Task.

----
CategoryUserInterface