[Doxxic]

It first occurred to me when the menu bar got transparant.
Then I thought I found support in Apple's shift towards toolbars and one-window apps, + the fact that screens are getting bigger and bigger and the connection between the menu bar and specific open apps isn't very strong anymore.
I could imagine that the menu bar was becoming less central in app interfaces, and becoming more of a place where you can find all available commands if you happen to feel lost.

But still, many people are relying heavily on the menu bar, and we've never seen examples of the menu bar actually hiding.

Except in iPhoto's full screen mode.

But now I've seen Logic Pro 8 and it has a "local menu bar", inside the app window, underneath the tool bar.


I'm starting to imagine a Leopard where programmers have the option to add settings for hiding the menubar, *per application*.

[BuonRotto]

regarding Logic 8's local menubar: eeeeeeeeeeeeeeeeeeeeeeew

I do think ,however, that the subjugation of the menubar is coming. Not saying it's going away, just saying that those neato iPhoto full screen editing thingies and Docks with their revealing/hiding behavior off the edges of the screen might be coming to the menubar at some point down the road.

Don't kill the messenger, this is just my prediction.

[Kickaha]

OTOH, a menu-in-window app would be ready for porting to Windows.

[chucker]

Originally Posted by Kickaha OTOH, a menu-in-window app would be ready for porting to Windows.

Your post is made of win.

[rasmits]

Moving to a menu-in-window policy would be the stupidest Apple interface decision ever. The menu bar is and always has been an infinitely better solution for handling application menus.

[zippy]

Originally Posted by rasmits Moving to a menu-in-window policy would be the stupidest Apple interface decision ever. The menu bar is and always has been an infinitely better solution for handling application menus.

ding-ding
give that man an interwebz!

I would really hate to see them abandon this model. Of course developers can add additional menu/icon bars to their own apps - ala MS Office - but thankfully, most have stuck with the standard menu bar.

[Kickaha]

Agreed. Non-edge menu bars are just a pain in the ass.

[Doxxic]

Originally Posted by rasmits Moving to a menu-in-window policy would be the stupidest Apple interface decision ever. The menu bar is and always has been an infinitely better solution for handling application menus.

Except for really large screens in combination with really small app windows, like Adress book.

And (maybe) complex programs, where a lot of commands need to be close at hand. Like Logic Pro.
Menu-in-window-solutions could be seen as advanced toolbar buttons.

The menu bar as we know it is not really made for the commands you need often - that's what the tool bars are for. And contextual menus, in my opinion. And keystrokes.
Although I know many will argue that current menu bars at least guarantee that the commands are physically there where you expect them.

What you get otherwise, in the case of complex programs, is what Office 2008 seems to offer at first sight: an incredibly complex and cluttered toolbar (reactions to the ribbon on the windows version seem positive, though). Maybe there menu-in-window solutions would have been better, too.

[Kickaha]

And yet - menu in window is what they *had*.

[shatteringglass]

Originally Posted by Doxxic But now I've seen Logic Pro 8 and it has a "local menu bar", inside the app window, underneath the tool bar.

This scares/angers me. Are there any screenshots of it online?

[Eugene]

Originally Posted by zippy ding-ding give that man an interwebz! I would really hate to see them abandon this model. Of course developers can add additional menu/icon bars to their own apps - ala MS Office - but thankfully, most have stuck with the standard menu bar.

They already abandoned so many models, it's somewhat pointless to try to reason with Apple.

"Close Window" widget... WHY DOES IT QUIT single-window apps (and not even all of them?)

Document tabs... SDI was great... Tabs are just a less functional version of the Windows-standard MDI...something even Microsoft has moved away from.

--

The Leopard menubar has issues... Instead of defaulting to transparency, that should be an option. Instead of being transparent to show what's underneath, there should be a toggle to hide the menubar altogether.

To me, it's practical to place all the menubar options in a contextual menu. For one, many of us are using multiple-monitor set-ups and it doesn't really make sense to have one menubar for each monitor. Nor does it make sense to have to move the pointer to the primary monitor to access a menu while you work on a second monitor...

[aranhamo]

Originally Posted by Doxxic (reactions to the ribbon on the windows version seem positive, though)

Please no. We have Office 2007 for Windows here, and everything is hard to find. The more common the command and the more often it needs to be executed, the more difficult it is to find. You have to dig through 300 menus to find commands that used to be right there. If I could go back to an older version of Office, I'd do it in a second.

[Kickaha]

Originally Posted by Eugene To me, it's practical to place all the menubar options in a contextual menu. For one, many of us are using multiple-monitor set-ups and it doesn't really make sense to have one menubar for each monitor. Nor does it make sense to have to move the pointer to the primary monitor to access a menu while you work on a second monitor...

I think the NeXT nailed this one quite well.

[Kraetos]

Menu bars belong pinned to the top of the screen. As power users, we don't care as to whether or not they are pinned or they move with apps, because we use hotkeys for the most common menu commands.

But we are the minority, by definition.

When you are using a mouse, you absolutely want menu bars pinned to the top of the screen. This is called Fitt's Law, and it's one of those things they teach in UI 101. The gist of it is, the the time required to mouse to an object is a factor of its distance from the cursor and its size on the screen. You can't do anything about the position of the cursor, because its almost 100% unpredictable. You can do something about the size of the object on the screen.

Now, here's the other thing regarding the size on the screen: an item on the edge of the screen, for all practical purposes, is considered to be stretching infinitely in that direction. When something is on the edge of the screen, you don't need to think about placing the cursor - you just flick in that direction and there you go. The corners are even better; effectively, the target space of the 4 corner pixels is infinite. Hence, spotlight and the apple menu occupy these special little pixels.

So, by putting the menu bar across the top of the screen, Apple gives the mouse-heavy user a colossal target to hit with their cursor, saving them lots of time on the long run. On the other hand, menus pinned to windows give users a relatively small target to hit, therefore slowing them down.

[Kraetos]

Originally Posted by aranhamo Please no. We have Office 2007 for Windows here, and everything is hard to find. The more common the command and the more often it needs to be executed, the more difficult it is to find. You have to dig through 300 menus to find commands that used to be right there. If I could go back to an older version of Office, I'd do it in a second.

Agreed. The ribbon sucks. Microsoft seems incapable of producing a UI that conforms to any of the usual common sense UI guidelines. It boggles the mind. A simple Google search could teach them so much.

- Those goofy menus that hide items when they think you don't them (Which have made their way into photoshop, and make me want to stab someone in the liver)
- Window-attached menu bars
- Lack of distinction between an application and its windows (this confuses the hell out of switchers)
- Paragraphs upon paragraphs of dialog box text in Vista (don't make the user read! This is UI 101!)

Bah.

[BuonRotto]

Originally Posted by Kickaha I think the NeXT nailed this one quite well.

In Ars terms +++!

...and don't forget early experiments in Rhapsody and Mac OS X Server (betas?) that simply brought this over to the platform, albeit in obscure places.

[dmegatool]

Just one thing that I found anoying with the top-menu bar: When you have 2 apps let say side by side.. or even just that you see the app below, you can't acces the menu bar directly. You have to switch the application and then click on it...

But most of the time I use shortcut... But it shoul be better... but... Ah anyway

[autodata]

Originally Posted by Doxxic But now I've seen Logic Pro 8 and it has a "local menu bar", inside the app window, underneath the tool bar.

Originally Posted by BuonRotto regarding Logic 8's local menubar: eeeeeeeeeeeeeeeeeeeeeeew

Without having my hands on Logic 8 yet, the local menu bar appears to be a) a per-view menu bar, eg, if you have a arrange view and mixer view open in the same window they both have their traditional view-specific menu bars and b) the same menu bar situation that has always existed in Logic throughout its life as a multi-window app. I think it's a major, major mistake to look at Logic's UI elements that have existed since long before apple bought emagic and extrapolate overall apple UI trends from them. The only thing Logic 8's local menu bars seem to indicate is a tug-of-war between apple and years-old emagic UI design philosophies.

[Eugene]

Originally Posted by Kraetos So, by putting the menu bar across the top of the screen, Apple gives the mouse-heavy user a colossal target to hit with their cursor, saving them lots of time on the long run. On the other hand, menus pinned to windows give users a relatively small target to hit, therefore slowing them down.

If you have to travel an immense distance to reach the menubar, then the convenience of infinite height is completely nullified. Thankfully Fitt's Law also states one of the best places to put an interface element is directly under the pointer...the contextual menu.

The contextual menu does not care how big your screen is. I can also access it on any screen I like without it being obtrusive. The only thing it doesn't do is display the primary menu options at all times.

Obviously some people want to go one step further and implement pie/circular menus. I'm not sure I'd go that far.

[chucker]

Originally Posted by autodata I think it's a major, major mistake to look at Logic's UI elements that have existed since long before apple bought emagic and extrapolate overall apple UI trends from them. The only thing Logic 8's local menu bars seem to indicate is a tug-of-war between apple and years-old emagic UI design philosophies.

Bingo. Logic 8 is in fact moving away from local menu bars, compared to previous versions.

[shatteringglass]

Originally Posted by Eugene If you have to travel an immense distance to reach the menubar, then the convenience of infinite height is completely nullified. Thankfully Fitt's Law also states one of the best places to put an interface element is directly under the pointer...the contextual menu. The contextual menu does not care how big your screen is. I can also access it on any screen I like without it being obtrusive. The only thing it doesn't do is display the primary menu options at all times. Obviously some people want to go one step further and implement pie/circular menus. I'm not sure I'd go that far.

Cursor acceleration (especially the implementation built into Mac OS X) partially mitigates this issue. "Throwing" your mouse in a certain direction will let the user avoid having to traverse a huge distance, although having to navigate back to the prior point on the screen may prove more challenging (assuming the point isn't on an edge or corner, making that target much smaller). The problem with contextual menus is that they are not available until you preform a mouse action. A global menu bar shows options at all times, and in a consistent spot that the user can just glance at.

I think circular menus are a stupid idea, one that always seemed like a good idea, but would break apart in implementation.

[Eugene]

Originally Posted by shatteringglass The problem with contextual menus is that they are not available until you preform a mouse action. A global menu bar shows options at all times, and in a consistent spot that the user can just glance at.

They aren't mutually exclusive. The menubar will still be anchored where you'd expect it to be.

[nassau]

The local in-window menus have been in logic since the dawn of time.

[shatteringglass]

Originally Posted by Eugene They aren't mutually exclusive. The menubar will still be anchored where you'd expect it to be.

I didn't say they were. I just don't see contextual menus as being superior enough to warrant them being added either as a complementary UI element or as an outright replacement of the global menu bar (which I thought you had originally implied, but I was wrong). I hardly use them, but I guess I'm alone in this regard.

Ideally, I think contextual menus should only offer options that can be found elsewhere in the interface, but oftentimes it gives programmers an excuse to be lazy where they start burying commands that can only be found with a secondary click. (iTunes team, I'm looking in your direction.)

[Doxxic]

Originally Posted by autodata Without having my hands on Logic 8 yet, the local menu bar appears to be a) a per-view menu bar, eg, if you have a arrange view and mixer view open in the same window they both have their traditional view-specific menu bars and b) the same menu bar situation that has always existed in Logic throughout its life as a multi-window app. I think it's a major, major mistake to look at Logic's UI elements that have existed since long before apple bought emagic and extrapolate overall apple UI trends from them. The only thing Logic 8's local menu bars seem to indicate is a tug-of-war between apple and years-old emagic UI design philosophies.

Thanks, this is crucial!
Kills Logic as evidence for whatever could be happening to the menubars.

Originally Posted by Kraetos Menu bars belong pinned to the top of the screen every time. As power users, we don't care as to whether or not they are pinned or they move with apps, because we use hotkeys for the most common menu commands. But we are the minority, by definition. When you are using a mouse, you absolutely want menu bars pinned to the top of the screen. This is called Fitt's Law, and it's one of those things they teach in UI 101. The gist of it is, the the time required to mouse to an object is a factor of its distance from the cursor and its size on the screen. You can't do anything about the position of the cursor, because its almost 100% unpredictable. You can do something about the size of the object on the screen. Now, here's the other thing regarding the size on the screen: an item on the edge of the screen, for all practical purposes, is considered to be stretching infinitely in that direction. When something is on the edge of the screen, you don't need to think about placing the cursor - you just flick in that direction and there you go. The corners are even better; effectively, the target space of the 4 corner pixels is infinite. Hence, spotlight and the apple menu occupy these special little pixels. So, by putting the menu bar across the top of the screen, Apple gives the mouse-heavy user a colossal target to hit with their cursor, saving them lots of time on the long run. On the other hand, menus pinned to windows give users a relatively small target to hit, therefore slowing them down.

I don't think anyone thinks that the menu-bar is ever going to go away.

I think it *might* be going to be hideable, and see it's original role as 'commands picking center' being taken over by toolbars and contextual menus more and more. It's role could shift more towards 'commands *finding* center'. For many people but not all.

I don't think people who are accustomed to the menu bar as it is, or just liking it, and who don't want to change that, are going to have to be disappointed. Nothing has to change for them.
I'd solve it with allowing for a per applications preference setting and put in the interface guidelines that the menubar should not hide by default.

Originally Posted by dmegatool Just one thing that I found anoying with the top-menu bar: When you have 2 apps let say side by side.. or even just that you see the app below, you can't acces the menu bar directly. You have to switch the application and then click on it... But most of the time I use shortcut... But it shoul be better... but... Ah anyway

That's another reason, besides the increasing screen sizes, why I personally welcome a shift towards less dependency on the menu bar.

Originally Posted by shatteringglass I just don't see contextual menus as being superior enough to warrant them being added either as a complementary UI element or as an outright replacement of the global menu bar (which I thought you had originally implied, but I was wrong). I hardly use them, but I guess I'm alone in this regard. Ideally, I think contextual menus should only offer options that can be found elsewhere in the interface, but oftentimes it gives programmers an excuse to be lazy where they start burying commands that can only be found with a secondary click. (iTunes team, I'm looking in your direction.)

Cubase is an even better example. The contextual menu pretty much fill your screen and is full of submenus. It's way, way to big!
BUT I still find myself using it more often than the global menu bar... But only to get to some specific functions I use often.

[Eugene]

Originally Posted by shatteringglass Ideally, I think contextual menus should only offer options that can be found elsewhere in the interface, but oftentimes it gives programmers an excuse to be lazy where they start burying commands that can only be found with a secondary click. (iTunes team, I'm looking in your direction.)

First of all, how is a contextual menu a secondary click? You click it just as many times as you would on a menubar. Either you click and hold, or you click twice

Second, the the opposite of what you're implying is more likely to occur. Because every function of the menubar would be accessible under the pointer, extremely lazy programmers might forgo implementing contextual menu items altogether.

And that's another thing... I want contextual menus to be a lot more intelligent. In a word processor, a contextual menu should be able to tell if you've got a word, sentence or paragraph highlighted. In an app like photo if I drag a marquee over a pair of eyes, there should be a contextual menu option to remove red-eye.

Predictive interfaces are the next step, not trying to reinvent the wheel with 3D desktops and wacky gestures.

[chucker]

Originally Posted by Eugene First of all, how is a contextual menu a secondary click? You click it just as many times as you would on a menubar.

"Secondary" refers to it being on what's traditionally considered the second mouth button. (Even on three-button mice, the order of left-middle-right is typically 1-3-2, not 1-2-3 as one might think.)

[rasmits]

People wanting the menu bar to go away - why? Do you really need the 22 pixels on the top of your screen? What would you do with those 22 extra vertical pixels?

I think ridding ourselves of the menu bar would be a disaster for usability, especially for new and non-advanced users...

[zippy]

Originally Posted by Eugene First of all, how is a contextual menu a secondary click? You click it just as many times as you would on a menubar. Either you click and hold, or you click twice Second, the the opposite of what you're implying is more likely to occur. Because every function of the menubar would be accessible under the pointer, extremely lazy programmers might forgo implementing contextual menu items altogether. And that's another thing... I want contextual menus to be a lot more intelligent. In a word processor, a contextual menu should be able to tell if you've got a word, sentence or paragraph highlighted. In an app like photo if I drag a marquee over a pair of eyes, there should be a contextual menu option to remove red-eye. Predictive interfaces are the next step, not trying to reinvent the wheel with 3D desktops and wacky gestures.

You've had a few posts in here that I agree with, but I'll just quote this one for simplicity. I didn't even think about contextual menus when I read the original post, but I agree that they are much more efficient. Of course most of my computing has been done on Windows, which seems to rely pretty heavily on them, but I don't think that's a bad thing.

They are especially helpful for people who are not totally comfortable with the applications.

The only thing I can say about predictive contextual menus is that they could get very annoying - assuming they pop up automatically when you perform some action - e.g. the marquee over the eyes thing you mentioned. People tend to hate it when a computer jumps to conclusions and presupposes what they are trying to do. Also, the menus tend to be in the way when they pop up. Of course they could pop up somewhere off to the side, but that can negate the benefits of Fitts law unless you put it all the way over to the edge of the screen.

[Mac+]

I don't think Eugene was talking about predictive contextual menus that pop up. Moreso that the activity should dictate what options pop up when the contextual menu is invoked by a "right" or "control" +mouse click.