Re: window-in-window MDI

["James M. Cape" <jcape jcinteractive com>]

Chris Jones wrote:
> 
> Hi
> 
> Tom Gilbert <gilbertt@btinternet.com> wrote:
> >
> > I still haven't heard *one* good reason *for* it, except
> 
> I haven't noticed a good, solid reason *not* to use it. Lots of people have
> been talking about how all UI experts dislike it - Why?
> 
> Specifically, what is actually so wrong with it?

It does not take advantage of the window management features that the WM
provides (saving window sizes/positions, etc), which means that the
author must code his/her own state-saving mechanism (or it must be in
gnome-libs). The chances of that behaving exactly like the WM the user
is using are slim to none. So, there are two different methods of
manipulating windows -- and the new user must learn *both* to be
productive. It also does not *look* like the user's WM. Theme
inheritance, window controls, etc. are all different. So not only must
the user learn how the new window type behaves, but even what the
controls to manipulate it do. Further, does not mesh with the user's
chosen iconization method (whether Iconbox, Icon, or Taskbar), so it
must implement one on it's own, which is garanteed not to mesh with
whatever method I have chosen. This is *the* major problem I have with
it. If a window is hidden behind another, Alt+Tab cannot bring it
forward, and there is no taskbar to do it. mIRC is the closest thing I
have seen to a sane WiW MDI design, and that is only because it contains
its own taskbar. IOW, the app must implement its own tasklist/taskbar,
wasting a minimum of 24px of my screen real estate to *duplicate* a core
feature of the environment (handling overlapping or hidden windows).
This is lunacy! I should not have to learn two methods of handling
windows or retain that knowledge (BTW, the only ways in Word <= 97 had
to handle window switching were to waste screen real estate by not
maximizing the child window, thus further shrinking the workable area,
use CTRL+Tab, a second shortcut to match what the windowing system did
already, or use the Window menu, which I only found two years ago -- and
all of these hide if there is a new window, a major interface No-No (I
know from personal experience that I've tried to open the same documents
multiple times because I couldn't see it's window), or waste an
additional 24px of space duplicating a core interface feature of the
desktop (BTW, you would have to duplicate all possible ones to achieve
window management synthesis with the WM), or simply do without decent
window management.

I believe that succinctly covers why it should not be implemented, ever.
This is one case where the potential damage done outweighs the fact that
some users want it (only to be a competator to Windows, I'm sure --
those same people would freak if IE or Netscape implemented MDI :-)).

Oh yes, nearly forgot, Microsoft no longer does MDI for the very reasons
I pointed out above. Office 2000 is SDI (IE/Netscape style).

    Jim Cape
    http://www.jcinteractive.com

    "Men occasionally stumble over the truth, but most of them
     pick themselves up and hurry off as if nothing had happened."
        -- Winston Churchill