Re: Application menu.

I really don't understand your point. I just wanted to let you know what
an humble daily gnome user / evangelist thinks about an enhancement
proposal from an ergonomic point of view.

On Thu, 2003-09-18 at 17:04, Gregory Merchan wrote:

> This message summed it up so well, that I wonder if Cedric gave his vote
> with tongue in cheek.

No, I took care of cutting it beforehand, as I knew it would give me an
excuse for this post ;) 

>   AppName 
>     Apps with more than single word names would have to use StudlyCaps or
>     look like multiple menu items. Apps would have to use single word names.
>     Because not every app can be named Editor or Browser or what have you,
>     the names would not be very descriptive. With descriptive names we'd
>     need translations.

You're right, that's the biggest problem which really needs to be
tackled. MacOS X solved it by boldening the application name to force
visual coherence (and the trick works pretty well).
IMHO, I think gnome would only need to call it "Application". On the mac
they need to change it per application because they only have one
visible menubar at a time.  

>   About
>     Mostly a vanity item. Perhaps if it made it easy for users to flame
>     developers for data loss or alert asphyxiation, it'd be useful.
>     But really, it sits quite nicely on the Help menu with the other items
>     that tell you about the application.

Well, in an ever changing open-source world, where releases are fast
paced, I find it useful to remember which version of an application is
installed... or even more, now that menu entries has been rationalized
(Web Brower for epiphany or galeon, Project Management for MrProject,
etc...), to know which application matches each launcher...

>   Help
>     Has its own menu, and it's hard enough to get as it is. Why hide it?

As I said, in my previous mail "help" can certainly be discussed.

>   Preferences
>     Usually a design flaw allowing access to things that should be on the
>     View menu, the Tools menu, part of stored state, or non-existent.

Did you ever look to evolution preferences, AbiWord preferences, or even
gnome-terminal profiles...

>   Quit
>     Cruft. It's also quite confusing when it causes some other document,
>     perhaps on another workspace, to disappear.

That's why the file menu should only contain actions related to files.
Quit does not belong to the File menu, Close do. 

> Overall:
>    FOUR ITEMS! Except for the screenshot that started this thread, nobody
>    has suggested anything other than these four items. I dread to imagine
>    what people will start to fill it with.

Four items is not enough ? What's the definition of a good menu for you
? I don't want bloated menus, I want simple ones in understandable and
easy to use applications... 

But BTW, we could add a hide entry (ala MacOS) which could hide all the
application windows...

> Come on,

Overall, I find this mail a bit unfair regarding the current situation :

Let's take a deeper look into it. We are not speaking about a "one kind
of well defined application interface" here. There are several UI
paradigms used out there...

1- Tools (gnome-dictionary, gcalctool...)

2- Application oriented interfaces : One main application window,
several document windows (gimp, gaim...)

3- Single window, multiple documents interfaces : one application window
where document are accessible through tabs (gedit)

4- Multiple document windows interfaces : only document windows are
visible (Abiword, gnumeric...)

5- Some may mix both 3 and 4 (gnome-terminal, epiphany...)

For each of them, the requirements differ :

- (1) already have an application menu 

- (2) could benefit from it, by removing application related items from
the document windows (that should not have an application menu in the
menubar), leaving them in the main window application menu.

- (3) Should work like (1)

- (4) is MacOS style without the global application menubar. Keeping
Quit outside of the file menu would be the main benefit, but having
strong guidelines in the HIG would force applications to respect the
"Application Menu" and might help normalizing interfaces (gnumeric
having Preferences in the File menu) 

Back to lurking mode,

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]