[HIG] Re: [Usability]Question on Multiple Document Interfaces

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Aug 23, 2002 at 03:06:02PM +0200, Michele Campeotto wrote:
> Daniel Borgmann wrote:
> >Isn't the tab grouping of fluxbox pretty close to that? I didn't use

Every window manager I've tried that had or could have tab groups I found
to be deficient in its implementation of them or in other ways. This may
be because I tried them in early development, because of bad defaults, or
because nobody has spent much time looking at how to make them usable.

Nonetheless, I believe the window manager should handle tab grouping for
the same reasons Matthew Thomas, Colin Robertson, and others have stated.


>   I think this is a problem at least with some kind of applications. 
> How would you handle this, for example
>     http://primates.ximian.com/~dave/screenshots/anjuta2-devhelp.png

I don't understand how people can work in such environments. This is not
a criticism of Anjuta or other IDEs, but a statement of my lack of
understanding. I find having so many things taking space from the main work
is annoying. It seems to me like trying to hand write an essay with a ruler,
dictionary, and thesaurus covering most of the paper. (Would it suprise
you to know that I use emacs with the menubar and toolbar off? ;-)


>   with the WM-tabs approach without going the NetBeans/Forte way of 
> having lots of windows scattered in your workspace? And even if that 
> could be seen as a solution (given a really smart WM and task switcher 
> and carefully coded apps), I also think it would be quite hard for both 
> the app and the wm to organize the windows in a sane way...

I think it is important to consider what is a document. I believe most
people would consider the HIG to be a document even though it is a few
files in xml source and a few other files when rendered html - and there
are image files too. A spreadsheet is also a document and that usually
has many pages bundled in a workbook.

I think it is reasonable for an C IDE to present the .c and .h files
in the same toplevel window because, in a sense, they are just parts of
a single document. But why tabs or whatnot? For a C source pair, there will
be an include directive in the .c file; why not just fold the header in?
(Ans. too much scrolling ;-) How about a split-pane view? The header file
could be placed in the top-pane, the .c file in the bottom, and the views
could be (to some extent) synchonized. Instead of switching tabs and searching
for that forgotten declaration or definition, you'd just look at it in the
other pane.

Removing MDI doesn't have to result in screen clutter. Designers and
developers will probably have to do more work, think more, and talk to users
more. Much of this will be about things which cannot directly be codified
such as what is a document, to what end is a program used, and what is the
user's real goal outside of the contraints of the program.


>   This is starting to look more and more like the Mac OS approach, 
> IMO... not that I don't like it, but I'm not sure if the whole of the DE 
> is ready for such a change... I'm not sure the mixing of fundamentally 
> different paradigms is a good idea... I'm quite happy with tabs, after 
> all, and I don't feel being alone

<rant>Damn Kuhn for his abuse of the word paradigm.</rant>

I wonder how someone presenting an overall scheme would be received.
My guess is that he wouldn't be . . . at all. Screenshots serve poorly
to show how an environment works because they are static. Code takes
more time and to convey the overall picture you'd better have it
pre-installed when you sell the hardware. Words about at least these
things are rarely read.

I was going to present a scheme for an IDE without MDI, window clutter,
or screen clutter, but it would add too much to this email.


Cheers,
Greg Merchan