ApplicationMenuBar for a More Cohesive, Consistent, and Pleasant Experience

This is going to be a bit controversial and disliked by BeOS die-hards but I’d like to have the application name in bold next to the icon following the Mac convention.

We have the concept of a “key” menu bar that this could hook into. See “The Key Menu Bar” section from the BeBook and SetKeyMenuBar()

On Classic Mac OS and BeOS there wasn’t a good place to put application-wide menu options so every app put them in a different place making users have to go hunting for the option. This makes it consistent.

I brought this idea up before frustrated that Tracker puts its Preferences in the Window menu and that makes it hard to find.

The About option is an application specific menu item so it makes sense to be in the app menu even if some people don’t understand why.

3 Likes

Yeah, that’s indeed a good point. Also jscipione’s point about the position of the Tracker preferences.

OTOH, a lot of applications will have very few items in that menu, so that this consistency comes with a price tag, too.

If the help menu is not context sensitive, it should end up there, too, then.

However, I’m not entirely sold on the idea of having the icon there, either yet. Sure, it’s space conserving, but also less intuitive, and might look like too much depending on the layout of the window. Other options would be

  1. the application’s name
  2. “Application”
  3. “App”

or a combination of the above with the icon as jscipione suggested. I wouldn’t like having that menu in bold letters. That makes perfect sense on macOS, as you otherwise cannot really tell which menu you are seeing right now, what is the active application. We don’t have that issue, though. We have potentially less space in the menu bar, and should use it better.

Also, an icon would clash with Tracker’s draggable icon in the upper right (which I personally use quite often).

I think there are many things that need discussing if we want to have a general application menu.

I am very much against having an Icon only menu. It took me over 2 years to figure out that Visions app menu was in that icon. The discoverability is awfull, and the legibility of hvif icons on arbitrary backgrounds is questionable.

Having an item that could be a icon+text or text only per user preference could make sense, but only if it is using the existing menu layout classes…

In the “Program” menu, according to our interface guidelines

Program: Items related to operating on the program itself

About … Shows the About window. This is not a commonly-accessed item, so do not provide a keyboard shortcut for it.

Settings…Show the window which is used to customize settings for your program. This can be a submenu if your program only has a couple of settings.

Quit (Command + Q) This should be the bottom item in the menu and a separator should go above it. Clicking on this item should close all windows and quit the program.

I don’t think I have ever seen an application having a “Program” menu. IIRC, the interface guidelines have been single-handidly written by DarkWyrm and did not get too much attention or discussion.

But consistency should definitely be an important part of the UI.

I guess you wouldn’t have needed two years to find the Vision app menu, if all applications would work that way. Intuitivity is important, but IMO it’s less important than usability for the experienced user.

IMHO as a simple user, you will recognize something in the menu bar as a menu if it looks as other menus. It’s a matter of consistency. I mean that all menus should have an icon or, text plus icon or, text only ; otherwise a single icon can be mistaken for decorative.
This also means that if you’re using icons, the symbol used should representative for all entries in that menu. If it isn’t your menu may end up like these ugly hamburger menus that are painful to navigate.
An example is tools icon to represent settings (or parameters) menu, it is easily recognizable and commonly used. So, I would let this one outside the app (or program) menu.