Re: thinking outside the box (or, stealing the _really_ good ideas)

[Frederick I Gleef <gleef capital net>]

On Tue, 30 Jun 1998, sun wrote:
> [snip...]
> 
> i was the one who suggested putting "preferences" (and yes, i do think
> "options" would be a better term now) in the edit menu, and the fact
> that gnomines only contains a "game" menu has brought to my attention
> that we may be getting a bit _too_ restrictive with our guidelines.
> therefore i'd like to propose the following:

I would agree, Options is a better term.  Gnomine contains "Game" and
"Help", and fits happily within the current guidelines.  The guidelines
say that if "File" doesn't make sense for the app, the same stuff can go
under a new name, but the menu must be there if you have a menubar.

I still think that Options (or whatever we call it) should be in the File
(or whatever the application calls it) menu.


> remember the gimp, the program that started it all? i love that
> interface. i've gotten completely hooked on it, and in fact for those
> rare occasions when i need to do some work in photoshop i really miss
> having all the commands at most an inch away from my mouse pointer just
> by right-clicking.

I like the right-click menu too.  However, I think the Gimp goes a bit too
far with it by the time I'm in the filters menus.  Electric Eyes has a
much cleaner right-click menu.


> i think all gnome applications should have an option
> to turn the menubar _off_ and make all the commands accessible from a
> right-clickable "root menu" instead. 

Even Gimp doesn't do that.  Gimp has a perfectly good menubar.  It just is
in the tool selection window, rather than the picture window.  Not all
apps need a menubar, but all apps that have a menu bar generally have a
good reason for it.  Making it so that a user can just relocate the menu
bar to the right mouse button will mean an app cannot use the right mouse
button for its own material.

A right-click menu also should be designed a bit differently from a
menubar, since it's easier to have more items on a vertical menu than a
menubar.  The two are different interfaces and should not be considered
interchangable.


> it's just a spin for the better on the "contextual menu" ideas so
> popular in win32 and mac os 8. see the gimp and electriceyes for an
> example of this.

I don't know about MacOS System 8, as I haven't seen it, but Win32
right-click menus are also not interchangable with the menu bar.


> further, i'd like to propose that all the menus we're so used to seeing
> be limited to their _original_ usage:

'Original' usage seems vague to me.  Also, limiting what can go onto
the standard menus would require more menus, which is not necesarily a
good thing.


> for instance, the "file" menu should only contain commands that deal
> directly with files on a drive, open, save, save as, etc.

Um... Since the beginning of time (or at least since MacOS System 1)
"Exit" has been on the File menu.  This has absolutely nothing to do with
'dealing directly with files on a drive'.  There are also many commands,
such as print, that are traditionally on a File menu, that don't
necessarily meet your criterion.

In addition, unless you propose a third mandatory menu, there are things,
such as Options, that if it's a choice between going in File and going in
Help, File makes much more sense.  This limitation would require these to
have their own menu.


> "edit" should only contain commands that deal directly with shaping
> _content_ of the main window: cut, copy, paste, spell-check, whatever.

By content of the main window, I assume you mean the data of the main
window, as all the items you listed address.  Note that Options does not
fit here.

 
> the right-clickable "root menu" should also contain choices that _are
> not_ menus themselves, especially those that have been "kicked out" of
> the file and edit menus: quit, options, and "show menu bar" (if you just
> can't live without them) for starters.

So you would mandate a right-click menu.  I am currently working on an
Outline Font Editor application, around a very complicated canvas.  I was
counting on being able to use my right mouse button for special editing
features, I do not want to be required to support a menu there with
mandatory items, not when I have a perfectly good menubar that will
happily hold these items.

I would strenuously argue against mandatory right-click menus.
Right-click menus should be an acceptable alternative to menubars and
toolbars, but it should not be mandatory.

 
> of course, there is still the question of what to do with the "bastard"
> root menu choices (like "quit," "options," and "hide menu bar" when the
> menu bar is shown normally. an idea i had was to create a new menu
> remeniscent of the apple menu in the mac os or the atari menu in tos
> which, instead of containing os-wide options like desk accessories,
> would contain those "bastard" or miscellaneous menu choices that deal
> with the program itself. 

This could be a tolerable compromise if enough people like tearing things
from the File menu, but requiring three menus is nowhere near as elegant
as requiring two menus.  You haven't given an argument that convinces me
that the current two menu requirement for menubar programs should be
abandoned.


> we could use the program's default icon rather than a text label, too,
> to differentiate it from the other menus which are more dedicated to
> getting the actual work of the program done. 

Speaking as someone who has had to support applications users over the
phone, it is considerably easier to tell a user to find some text on the
screen than a picture.  It is particularly hard if the picture is not
consistant, as you have proposed.  If we must require another menu, it
should have a text name.

 
> ermmm, let me try to rephrase that: for example, all the menus in, say,
> a text-editor should deal directly with the text: file containing
> choices about where to save, open, and delete text files, edit
> containing the standard editing tools, view containing choices about how
> to display the text on screen, and so forth. then we could use the
> "application" menu (labeled with the editor's icon rather than text) to
> house all the commands that _do not_ deal directly with text, but with
> the way the application itself works and looks: "menubar" (show or
> hide), "options", and "quit".  the options in this latter menu, when the
> menubar is hidden, would appear in the root popup menu itself rather
> than in a submenu. "file" "edit" and "view" would appear as submenus in
> this root menu as well.
> 
> did that make sense?

That was a clearer description.  However, my objections voiced above still
stand.  Also, you don't mention toolbar-based apps, which have no menubar.
How do they fit into this scheme, or are they forbidden, or would the be
handled independantly.

 
> too, the root menu would give us something useful to map those annoying
> win32 contextual-menu keys to. :)

There are plenty of other useful things to map those keys to, for anyone
who wishes to do so.


> and regarding keyboard shortcuts: i further propose that user-settable
> keyboard shortcuts in the style of the gimp (again) be standard, but
> that the defaults be as follows:
> 
> ctrl-z: undo
> ctrl-x: cut
> ctrl-c: copy
> ctrl-v: paste
> ctrl-r: redo
> ctrl-o: open file
> ctrl-w: close [window] (for programs with multiple windows or documents)
> ctrl-q: quit (we should call it "quit" not "exit" since new computer
> users may not understand what they're exiting... the current edit mode,
> window, application, x session?)

Your argument against exit works just as well against quit too.  I don't
care which we call it, as long as the applications are consistent.

I second the proposal that we come up with keyboard themes.  There should
be at minimum a Win32, a MacOS and an Emacs theme, and at least one for
each of the major keyboard layouts (Dvorak, Spanish, Russian and German come
to mind).  The default should probably be Win32.


> i propose these because they seem to be a de facto standard among
> windows and mac os apps alike, and it's from these two platforms that we
> seem to be intent on evangelizing new gnome users. :) so how do we
> finalize these?

Well, the best way is to come to a consensus first, there has been
considerable dissent on the ones you listed above, considerably your
choice of ctrl-z for undo.  Since most of this dissent seems to come
from German keyboard users, I think an implementation of keyboard themes,
with a good set of German defaults on the German theme would go a long way
towards consensus.

The other way is for Miguel, or one of the major developers to say "You've
been bickering about this for months, enough.  This is how we will do it."
I think we all would prefer a consensus.

However, in order to get a consensus, we can't just say "I think it should
be this way".  We have to say "I think it should be this way for these
reasons".  Without this there is just arguing, with it there is room for
debate and compromise.


> i've seen most of those defaults suggested earlier;

Yes, and I've seen reasons presented against them that you don't address.


> do we vote or something, or just hope somebody with technical writing
> skills notices them and hashes out a chapter for the style guide? :)

In my opinion, voting tends to flood mailing lists.  In addition, I don't
think that we've come up with enough agreement to make for a good style
guide entry.


> further: there's been some talk of setting environment defaults for all
> gnome applications; if you all would be so kind as to right-click a
> blank spot on your panel i think you will see a perfect place for
> putting these: "global properties" is the intuitive choice.

User interface defaults should go under the ui-properties command.
Making sure the command can get accessed from the menu you refer to
could make sense, but it should be under that command, and accessible
without panel.


> (the window that comes up when you select it is called "global _panel_
> properties; does anyone disagree that this should be changed?)

I think this is premature.  You just proposed a change to the nature of
this menu earlier this paragraph, nobody has discussed it yet.  If people
agree that this menu should have more global impact, they will agree to
the name change, if they don't, they wont.


> so whaddya think?
> --
> "Whoever saves one life saves the whole world in time." --Talmud

I think I like your .sig quote :-)


-Gleef