Re: [Ayatana] The Future of Window Borders, Menu Bars, and More

On 07/29/2010 10:35 AM, Martin Owens wrote:

On Thu, 2010-07-29 at 18:28 +0800, Allan Caeg wrote:

Conventions in Windows and OS X are evolving (see the ribbon interface
and app buttons on Office, Paint, etc.) while the Linux desktop is
limited (probably) because we can't make new things work everywhere
(different window managers, desktop environments, etc.).

I think it's more important to have standards in data format and
communication, than to have standards in interfaces across competing
products. Internal design consistency is very important and that can
only really be achieved with standards.

Insisting on a left aligned set of window buttons is something you can
only do within a distro, it's hard to enforce that sort of thing on your
collaborators, let alone your competitors. So it's best not to
standardise the look and feel of the product when it's pretty much the
one feature that separates various products in the market.

Applications should tell the desktop what they mean, not what they want.

I think things like the windicators and the indicators are going in the
right direction, but communication is only very slowly getting better. I
remember the almost flaming row I had with DX-Gould at UDS-J about
removing the indicators. The impression I got was not what the results
have turned into and I would have been quite happy to accept the current
design had it been possible to explain at the time.

Martin,

_______________________________________________
Mailing list: https://launchpad.net/~ayatana
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ayatana
More help : https://help.launchpad.net/ListHelp

May I add my own view of this? *ahem*: (tl;dr version at the bottom)

GNOME 3 comes out next year. With it comes many new technologies
including the Application Menu, a message tray for non-system
applications, and GTK+ 3. The GNOME Shell design page has
an interesting page on the Application
Menu (aka AppMenu) , a feature coming in GNOME Shell. The menus
that Chrome and Firefox and Opera and every other application with
menus are often relevant to two different things at once: the window
and the application. The difference between the two is that there
are some options, such as Open File, Print, or the View menu that
only affect the current window, and some options such as
Preferences, options for Add-Ons, Bookmarks, (maybe) History, Help,
Check for Updates, and About, that affect the entire program,
meaning every open window.

The Firefox Button makes sense on something like Windows because
Windows doesn't have a menu like this. On Mac, the button doesn't
make sense because of the global menu bar. On Linux, it's unclear
because there are so many different conventions with which to do
things, some more efficient than others. Remember: All
that the Firefox Button does is re-package the menu bar in a more
compact space on the window border, that is it. It's
simply re-organizing the current menu structure into a drop-down
menu.

Each operating system and desktop environment does things
differently and this is expected. Windows users often complain about
how hard to use Mac is, Mac users complain how hard to use Windows
is, KDE users complain how hard to use GNOME is, GNOME users
complain how hard to use KDE is and so on because they are used
to different things. Each OS has their own way of being
efficient and organized with their own unique styles. People
switching from Windows to Mac or Linux do so partially because of
this; it's told as being easy to use once you are used to it.
The Application Menu is one of GNOME 3's unique quirks, which is, in
my opinion, for the better.

It works like this: The parts of the menu bar that are relevant to
the application as a whole go into the Application Menu, so that no
matter what window you have open, you can still access
"entire-application functions", while the things that modify the
window alone stay there. This
mockup shows how it could work for Firefox . The Application
Menu page I linked to at the beginning says this menu could be used
to hold the following types of options:

- Quit (all windows of the application that are open)

- Preferences/Settings

- About

- Check for updates

- (maybe) Clipboard

- (maybe) Show/hide Windows

- (maybe) New Application Window

This could work very well because instead of looking through the
various menu bar options for the right option, you'd know where they
are instantly by simply looking in the Application Menu. Firefox
isn't the best example for this personally, so lets take Pidgin for
example. you have a buddy list and a conversation window open. The
conversation window would keep its menu bar, because the options on
it only affect the current window's contents. However, the menu bar
on the buddy list, which affects the entire program, would move to
the Application Menu so you could still access it even if your buddy
list wasn't the active window, or if it was on another workspace.
This approach is far more organized than something like the Firefox
Button or similar ideas, and it shouldn't take too long for somebody
used to Windows or Mac to get used to because it's a sort of hybrid
of both ideas. Firefox should continue using the menu bar for
Firefox 4, but after/before GNOME 3 is released support for the
Application Menu is a necessity. If Firefox detects that you are not
running GNOME, the menu bar as a whole should return. The menu bar
options like the File/Edit/View menus could optionally be put in a
button like they are on Chrome as well (at the very least it can be
easily done with an add-on).

tl;dr The GNOME Shell Application Menu is what should be utilized
instead of mimicking Windows for the sake of being "shiny" or
"familiar". Remember, you can't innovate and try to be completely
familiar at the same time.

- Ryan Peters

_______________________________________________
usability mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/usability