Re: gui (and other stuff) proposal

["Dan \"Effugas\" Kaminsky" <effugas best com>]

-----Original Message-----
From: Stephane Crochon <stephane.crochon@hol.fr>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Sunday, September 20, 1998 3:19 AM
Subject: gui (and other stuff) proposal


>-- Hello everybody !
>
>I am new on internet and on gnome gui list.
>I have had some e-mail talk with Kenneth Pedersen (kI p@unix1.hials.no)
>about his gui proposal. He said me my comments were interesting and put
>them on his home page.
>I suggest everybody to have a look there
>(http://unix1.hials.no/~kp/gnome/DCI.html), and send me your comments.
>My english is buggy, but i have really few time to spend on info-things
>(it is NOT my job at all)


Hurm.

I really wish I could like the idea of a documented oriented interface--it
sure SOUNDS cool.

The problem is, DOI doesn't take into account consistency, or more
accurately, inconsistency.

Different documents have different operations that can be performed upon
them, and these operation differ by application.  A simple MP3 app may just
play a song, a complex one might do sine transforms of the subband
frequencies as well as playing.  Just staying in the realm of MP3 for the
moment, this means a DOI would need to do one of the following:

a)  Pre-define allowed functions to be performed on a MP3, and then place
that in the monolithic document interface in some kind of logical place.  No
application may add extra features, but the interface is allowed to have
perfect look-and-feel consistency since the holistic frame design is done in
advance.

b)  Allow function "plugins" into the frame interface.  This wouldn't be so
awful except for the fact that there's more to an interface than a drop down
menu with items to be selected; not to mention it still constrains available
features to force plugins.  For example, it is impossible to use a plugin in
Photoshop to real-time modify the values of the main graphic frame, like the
curves dialog does.  The most common problem is that not all features
overlap--just because you can do x, or y, that doesn't mean you can do x on
y.

Both of these are adequate solutions, but they aren't really anything new.
They're sometimes good solutions, but they often aren't.  They surely aren't
something to build an interface off of--my god, the clutter of 80 spare
menus...

The real problem with the documented oriented interface, of course, is that
it's oriented on the noun when the user often thinks of the verb.  How does
one compress a folder in a DOI?  In a Application Oriented Interface, one
opens up the compressor application(verb) and tells it to compress the
folder(noun).  How would this be done in a DOI?  I guess "compress" could be
an item in an added menu, and I guess clicking compress could bring up the
compression application, but then you're positing huuuuuuuge menus for each
file system frame content listing all the possible things one can do--go
check out what happens on windows with "create new document"--very very
ugly.  Gotta complement Send To... though--*THAT* happens to work well.