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

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     : ayatana@xxxxxxxxxxxxxxxxxxx
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