Re: Toolbars (Was: Re: Unimplemented AppKit classes)

[Jeff Teunissen]

Martin Häcker wrote:

> >Toolbars do not simplify anything -- they're an additional complication
> >that gets in the way of getting useful work done.
> 
> You certainly take a very extreme point of view here on wich I want
> to ask you a question on.

Well, some think it's extreme. :)

> I know the menu interface and like it _but_ what do you do when you
> have _lots_ and lots of commands to fit in there?

Depends on how many are necessary, and whether or not they can be laid out
intelligently.

> You obviously don't like Word and its menu layout, so I'l use another
> app as an example: "Maya". This app almost certainly has the _most_
> menu commands that I've seen (at least 10 times as much as Word has)
> and they are _all_ needed.
> 
> They took a nice step and created a pie menu (which I like very much
> - but thats another thing) but - can you imagine how this looked in
> the old "Next Menu System"?

Nitpick: It didn't look like anything, since Maya didn't exist on NeXT.
That said, If it had existed, it would likely be very different.

> What do you do with this Interface if it has to hold so many commands
> to "Fix" it?
> - Add Submenus? -> Crufty and hard to use with 3 levels of submenus.
> - Add Dialog Boxes? -> Inflexible and "far" away as in clickcounts.
> - Add something else?

What would *I* do? Split the program into multiple units that work
together. Modelling, texturing, animation/kinematics, rendering. Since in
a production pipeline you don't generally have one person doing all of
these things at the same time (at most, you have one person doing both the
modelling and the texturing, as far as I know), you're more able to
distribute the load on machines and users, while giving each user a more
focused environment in which to perform the job at hand.

That way, in addition to being able to split the work of development
amongst smaller teams, you can then sell the suite on an "á la carte"
basis if you want.

Otherwise, I would suggest exactly what they did -- pie menus. Done
properly, they're an efficient means of managing lots of options without
bogging down the user. I might make the pie menus pinnable, so you could
keep certain menus around all the time (like NeXT-like menus).

> Well... thats the point.
> 
> I do have nothing against the Next Way of doing these things, but I
> also believe that they (Next) solved problems that where at hand at
> that time and that we now today have to deal with a totally new
> problem of giving a massive feature load to the user without
> overloading individual parts of the interface.

I, likewise, have nothing against new ways of doing things (that is, after
all, the point of my contention that GNUstep should be "more NeXT-like
than NeXT". Toolbars, though, are demonstrably a failure to use good
design practices.

Often (but not always), massive feature sets are a symptom of a larger
problem -- that the program has become too unwieldy and should be
refocused/refactored into multiple units.

[snip]

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/