Re: Debian menus policy
On Thu, Dec 13, 2001 at 08:25:01PM -0800, Craig Dickson wrote:
> Brian Nelson wrote:
> > Furthermore, it's more logical to search through a menu that matches
> > your thoughts, like editing->text->...
>
> No, I don't agree. If I'm working with a sound file, doing various
> things to it, it's convenient for the programs that might use this file
> to be grouped together. It's a _sound_ file, I'm working with _sound_,
> so if there's a menu labeled "Sound" below which are editors and players
> (possibly in submenus, possibly not), that's the most practical
> arrangement. It groups together programs that might be used together,
> and which can operate on the same files. They are closely related on
> that basis. In contrast, a text editor and a sound editor may both edit
> files, but not the same files; they really have next to nothing to do
> with each other, so grouping them together in the menu is misleading.
Well, what Brian Nelson wrote touches the issue I believe. It is nice
(or even productive) to match the thought processes of a user, which
might be hard without some research. This is nicely shown by the
differences between how Thomas Hood would like a menu, and how for
example you like one. I myself usually know what I am going to do, so I
think along the lines medium->action->... (on the topic of media, Games
can be viewed to operate on users (the amount of relaxastion ?)).
But sometimes I do not, sometimes I only know I want to configure
something, but not sure what it is (granted, I try documentation first,
and not a menu, but you get the idea).
To sum it up, I think if you really want to have a go at being
"logical", one should do some more work on researching the domain first,
if it is not going to be a better solution for more people, I would
prefer the status quo.
> Instead, you either go for a majority sense of what people want, or you
> build enough flexibility into the system that each person can make it do
> more or less what he wants. Which wouldn't be that hard to do; the menu
Agree on that.
> files would just have to have both datatype-oriented and
> function-oriented information (essentially forming a two-dimensional
> grid of programs) and then you allow the user to configure the menu to
> favor one dimension or the other for his view of it. It's not really any
> harder than making a file manager able to sort file listings by name or
> by size.
Why stop at two dimensions ? Why the hierarchy as it is now ? One could
make use of menus like in high end modellers (Maya for example), where
the menus expand in all directions from the current entry, and the menus
grouped in such a way that the user operates at optimal performance. And
that is why those suites cost a hell of a lot more than Povray or
Blender or any other gratis/cheap suite.
> Craig
LarstiQ
Reply to: