MDI kind

[Richard Gaskin]

Meitnik at aol.com wrote:

> In a message dated 8/9/04 12:04:59 PM, 
> use-revolution-request at lists.runrev.com writes:
> 
>>When we talk about "true MDI", are we talking about containing all of
>>the applications documents in a single window, rather than having each
>>of them as an independent window?
>>-- Well, ask a Windows developer what kind of MDI support is wanted in RR. As 
> 
> for me, I want a clean and effective way to handle MDI so it works like a MDI 
> critter in Windows expected. Anyone have a code library for handling MDI on 
> Windows with proper support for the taskbar?

What are the concerns about the taskbar?  AFAIK it's not possible to do 
MDI at all in Rev today, though there is a proposal for its 
implementation (see 
<http://www.runrev.com/revolution/developers/bugdatabase/show_bug.cgi?id=1928>).


What is MDI?
------------
The Win HIG describes four windowing models for desktop apps, each 
appropriate for different workflows:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch10a.asp>

Single-Document Window Interface
Workbooks
Projects
Multiple-Document Interface

Of these, Rev can do the SDI and Project models easily, and can mock up 
an acceptable Workbook with only modest effort to make tabs at the 
bottom of a window (I never use the Workbook model myself).

But MDI is a whole other animal, in which a parent window encompasses 
all document and tool windows.  Ideally, tool windows are also dockable 
in a true MDI (though not a spec requirement).  The parent MDI window 
holds the menu bar, unlike the SDI model in which each document window 
has its own menu bar.

There's an argument that MDI most closely parallels the Mac experience, 
since the Mac also has a single menu bar.  But with the advent of OS X 
that's where the similarities end:  in Mac Classic windows for a given 
app were in their own layer, and moving one forward brought all of them 
forward, which is what you get when moving an MDI window forward.  But 
OS X now has interleaved windows, so that apart from having a single 
menu bar Mac apps generally have more in common with the SDI or Project 
models.

It's useful to note that MDI is for viewing multiple documents, and is 
not necessarily appropriate for all multi-window designs.  Interfaces 
that provide multiple windows as different views into a single document 
file are addressed by the Project windowing model, which the Rev IDE uses.


Case Study: HyperRESEARCH
-------------------------
I have had only one app which would have benefitted from MDI, and the 
workaround is not pretty:  make a detached toolbar/menu window and 
position it along the top, using the backdrop to hide other apps.  That 
app (HyperRESEARCH) is most accurately described as a hybrid between 
this quasi-MDI model and the Project model (for viewing different 
elements of a single document we have one window for displaying 
transcriptions, another for cataloging citations of those 
transcriptions, another for listing the conceptual labels used for 
marking those citations, and another for annotations associated with the 
citations).

While HyperRESEARCH's design is inherently a perfect match for the HIG's 
Project model, users slammed us for not providing the conveniences 
afforded by MDI (rightfully so, IMO, even though we were fully 
HIG-compliant with the Project model).  Our emulating some of those MDI 
appearances and behaviors was a response to those requests, chiefly that 
there be a way to hide other apps and to minimize everything at once.

The toolbar+backdrop kludge is a far cry from the useful behaviors of 
MDI, which include being able to have the MDI parent window not 
maximized so one can easily switch to other apps by clicking on them 
directly rather than relying on the taskbar alone.

Also, an MDI parent window will of course hide all of its sub-windows 
when minimized, but to emulate this behavior you'll need to trap the 
iconify message in the toolbar window and minimize all your subwindows 
in script, which results in each of them having their own tab in the 
task bar (MDI gives you just one tab for the parent window, keeping 
things simple and clean).


Moving Beyond MDI
-----------------
Since the advent of OS X I don't bother with emulating MDI, as it 
doesn't address interleaving for managing windows on non-M$ platforms. 
Instead, we're migrating HyperRESEARCH to a panelled design in which 
what were separate windows in older versions will become resizable 
panels in a single window (a la Outlook Express, Mozilla, iMovie, etc.).

In addition to simplifying the user's workspace, the extra benefit of 
migrating the former hybrid Project/quasi-MDI model to a panelled SDI is 
that we save a fair amount of screen real estate by not having all those 
window title bars (32px * the number of windows * the width of each). 
Also, having everything associated with a given file in one window 
allows us to have multiple windows open; in a Project model it would be 
difficult to keep track of which window is viewing which file.

One could argue that a panelled single window is the more modern 
alternative to designs that use multiple windows for different views 
associated with a single file.  Apple seems to think so, with iMovie, 
iDVD, iPhoto, iTunes and others using mostly one window for everything, 
with the occassional dialog for less common tasks (I tend to design in 
ways that avoid platform-specific elements like Drawers).

While panels give you a better alternative to the Project model, they 
don't address those apps in which it's beneficial to have all documents 
together in the same application space (though I can't think of any 
offhand).

However, until we get a reliable method for notifying an app when a 
document is double-clicked (AFAIK Micro$oft provides no API for this, 
creating a second instance of the app instead), the usefulness of MDI is 
hampered.  M$ suugests we use MDI where needed, but makes it 
unnecessarily difficult to do so.  Fortunately it's not needed often.


Summary: Alternatives to MDI often make a cleaner UI
----------------------------------------------------
While MDI is sometimes useful and for the sake of completeness I feel 
Rev should support it, I prefer to use SDI for single-view documents and 
extend that with panels for replacing the multi-view Project model. 
True, M$ Office relies on MDI extensively, but application suites are a 
special case with unusually high needs for interaction among separate 
documents, and no one complains about Internet Explorer's cleaner and 
simpler SDI.  And with OS X's interleaved windows Apple is leading the 
way with a trend toward panelled single-window interfaces on that OS.

SuperCard users like myself may find the transition from multi-window 
views to panelled views unintuitive at first, if only because SC does a 
fine job in supporting multiple windows (with some features Rev has yet 
to match, like having different tool modes for different toplevel 
windows) but provides no equivalent of Rev's group object needed for 
many panelled designs, such as those in which a given panel must be 
scrollable independently of other panels.

Andrew, does your app use multiple windows for separate documents, or 
for different views into the same document?

If the former you may find SDI sufficient, and if the latter you may 
find moving the contents of those auxilliary windows into groups within 
a single window will simply your user experience.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________
  Rev tools and more:  http://www.fourthworld.com/rev