On Windowing, Palette Menus and MDI
I am archiving older pieces I have written on other sites, making this the definitive home for all my work. This is one of several I am porting over from my GameDev.Net user journal. Enjoy!
MDI sucks.
I think I've caught your attention, so now I can substantiate my allegation. The problem with MDI is collation of document windows associated with an application, usually with a blank background window that obscures all other application windows within the frame window region. This effects a monopolization of user attention and input by the application - in essence, saying "Look at me! Look at me! ...and look only at me."
My workflow often requires an interaction between data contained in multiple applications, and I know this to be even more so for many other computer users. Mac OS X actually has a different general GUI philosophy, built around the Apple Menu, floating palette menus and a hybridization of sorts of SDI and MDI which I actually think is a very good approach. Application document windows are not bundled: you can have a Word document window beneath an Excel window, beneath a Safari window, beneath another Word window. The key here is that you have two document windows belonging to the same application - without separate Finder instances (analogous to not having separate Task Bar buttons in Windows, making it a single instance of the application) - interleaved with other application document windows.
The advantage of this is that it facilitates rich drag and drop interactions, which is a far more natural, more tactile method than cut and paste. I'm a power user, so I believe in keyboard shortcuts, but I believe they should back up haptic approaches - just like I believe that command line interfaces should back up graphical ones.
The interesting thing is that Windows SDI encapsulates the application menu and document window in a single frame. Take a look at Word Pad to see what I mean. In fact, Microsoft Word does exactly the same thing. Mac OS X avoids or eliminates the need for this by placing the Apple Menu at the top of the screen and ceding control to the current application, reserving a tiny portion on the right for the clock, Finder (an icon) and a few optional notifications (display options are represented by an icon of the Apple Cinema Display, for example).
In addition, floating palette menus are encouraged, in contrast with Windows where the GUI guidelines explicitly discourage them. It makes sense for Windows' general GUI philosophy, of course, but I think that Windows could use a review of its philosophy. The advantage that floating palette menus present, particularly with hybridized MDI/SDI as described above, is that the reuse a single piece of screen real estate rather than multiplying what is effectively the same thing. This frees up more screen for other windows, etc, which, again, facilitates rich drag and drop interactions, among others.
Also, by stretching your floating palette menu either along the top or right side of the screen, you obviate to a certain extend the need to maximize applications because your menus are in a consistent place with respect to the desktop. (Of course, you need a large enough monitor and a high enough resolution, but wide screen displays are becoming more and more common place and 17 inches can be considered a baseline for desktop displays.)
Now, it must be said that your application should have only one floating palette menu. The GIMP, I'm looking right at you. PhotoShop CS on the Mac is very similar to the GIMP in terms of menus, but it has additional menus snap to and extend, or overlap using tabs, the existing menu. Hint, hint. A proliferation of menus leads to user bewilderment, something I think I shall talk about in detail in the near future.