Menus are hidden by default

Reported by Matthew Paul Thomas on 2011-03-10
756
This bug affects 169 people
Affects Status Importance Assigned to Milestone
Ayatana Design
Undecided
Unassigned
Unity
Medium
Unassigned
unity-2d (Ubuntu)
Medium
Unassigned
unity (Ubuntu)
Medium
Unassigned

Bug Description

Ubuntu 11.04, Ubuntu 11.10, Ubuntu 12.04

1. Log in to Unity, and try to connect to a server: "File" > "Connect to Server".
2. Launch Firefox, and try to select an item from the "Bookmarks" menu.

What happens:

1. The "File" menu, and the rest of Nautilus's menus, are hidden by default.
- Unless you mouse over it, the menu bar is blank.
- When you mouse over it, the menus appear.

2. The "Bookmarks" menu, and the rest of Firefox's menus, are hidden by default.
- Unless you mouse over it, the menu bar contains only the text "Firefox Web Browser", which isn't useful at all (especially, but not only, since the real name of the application -- "Mozilla Firefox" -- is already present in the window title bar).
- When you mouse over it, the menus appear, partly but not completely replacing the previous text: "Firefox W File Edit View…".

What should happen: Menus should be visible by default, so that you can know that they exist without scrubbing the screen, and so that you can see where a menu is each time you aim for it.

The current behavior has led some people (including, this week, one of my design colleagues) to conclude that Ubuntu applications don't have menus when they do. For example <http://www.techrepublic.com/blog/opensource/gnome-shell-vs-ubuntu-unity-which-desktop-wins/2291>: "One of the most handy menu entries in GNOME (for me at least) is the Connect to Server entry in the Places menu. This allows the user to connect to nearly any type of server quickly and easily. The user can even connect to a Windows Share from here. In Unity - you won’t find that. In fact, you will be hard pressed to find any means to connect to a server in Ubuntu Unity."

In bug 720424, Jono Bacon reported that "when we did some developer tools usability testing last week and on some other occasions when I have had someone use Unity, I have noticed that some folks don't realize there is a menu there as it is not visible."

This was confirmed by usability testing of Ubuntu 11.04, where 2 out of the 10 people who needed to use a menu item could not find the menus at all -- and of the 8 who did find them, 7 did so only when the window was maximized. https://lists.ubuntu.com/archives/ubuntu-desktop/2011-April/002970.html (Usability testing results of Ubuntu 11.10 or 12.04 have never been published, but this part of the design did not change.)

Do not confuse this bug with bug 682788, which is about adding an option for visibility. Adding any options would not fix this bug, which is about menus being hidden *by default*.

-------------------------------------
Desired change:

Implement the 'Enhanced Menu' project for 12.10. This project will address the issues described in this bug and also issues described in the duplicates of this bus. Note the 'official' bug that tracks the implementation of this project is bug #682788

The following options will be added to 'System Settings/Appearance':

-------
Menus
Location: Global/Local
Visibility: Hidden/Always displayed
-------

More details to follow during the 12.10 cycle... ;-)

tags: added: sniffles
description: updated
Alex Launi (alexlauni) on 2011-03-10
Changed in unity:
status: New → Incomplete
tags: added: needs-design
Didier Roche (didrocks) on 2011-03-11
Changed in unity (Ubuntu):
status: New → Incomplete
John Lea (johnlea) wrote :

Marked as invalid as this change request contradicts the design, see http://docs.google.com/View?id=dfkkjjcj_1776g5ztgbc3

To discuss this design, please use the Ayatana-design mailing list https://launchpad.net/~ayatana

Changed in ayatana-design:
status: New → Invalid
Changed in unity:
status: Incomplete → Invalid
Changed in unity (Ubuntu):
status: Incomplete → Invalid
John Lea (johnlea) on 2011-03-11
tags: removed: needs-design sniffles
Paul Sladen (sladen) wrote :

Making "Won't Fox". I think if we're not going to do anything about the lack of discoverability , we need to be honest about that.

Changed in ayatana-design:
status: Invalid → Won't Fix
Vish (vish) wrote :

Hiding the menubar and only showing the menu on hover basically makes the most important benefit "A menu bar at the top of the screen. .... It has several benefits, most importantly being quick to use because of the large virtual target area..." a moot point, from <http://design.canonical.com/2010/05/menu-bar/> !

Even if user realizes that the menubar is hidden in the top panel, there would be no possibility of "quick use" (Fitts law ).
User can not know which menu item to hit, It will slow down the user in getting to the target menu. And hiding the menu for large screens just to save space is a very odd! ;-)

description: updated
Changed in unity-2d:
status: New → Invalid
Alex Launi (alexlauni) wrote :

Perhaps a quick peek when a shortcut is hit, similar to OSX. Ctrl + W/Q, Copy, Paste, etc. are all well known keyboard shortcuts that people use, probably over the menus. Doing a small peek of the menu, or some other momentary animation in the spot where the menu should be would help enormously, as well as give those keyboard shortcuts some tangible effect.

Daniel Fore (danrabbit) wrote :

If the goal is to save space by removing menubars from applications it should be done in the proper way: re-designing these applications such that menubars are not necessary.

The only advantage I can see of doing it like this is to irritate users and developers into using/creating applications that don't rely on a menubar (such as those provided by elementary, the new U1 control panel, Google Chrome, etc). But I don't think this is the proper way to achieve that result.

To continue this course of action, an alternative method for displaying certain common actions the menubar supplies should be proposed so that developers have a sane alternative. In elementary we call this the AppMenu (the little cog on the right side of the toolbar). It holds actions that don't necessarily belong in the other parts of the UI such as the "About" "Preferences" "Report a Problem" and other entries that we've found are necessary to carry over from the menubar.

I suggest that menus should only be hidden when the window is maximized (so you can read the window title). Otherwise the menu bar should always be visible to avoid confusing the users.

Michael Sharman (msharman) wrote :

I agree, this is a major usability regression IMHO from previous versions of Ubuntu, I spent ages trying to find the menu before I thought of mousing over the title at the top of the screen. Can we at least have an option to turn it off!! I'm a Mac OS X user so menus at the top of the screen are not unfamiliar to me, but hiding it by default is a design flaw, it detracts significantly from the usability compared to a traditional desktop machine, IMHO it would be better to obscure the window title than to hide the menu.

Michael Sharman (msharman) wrote :

Perhaps more constructive.... in most of the apps I use there is ample space for the menu to sit beside the window title, why not simply make the menu permanently visible but sit next to the window title. If either gets too large then add a "..." indicator and then a mouse over can reveal the complete menu. (or ">>" or whatever to indicate there are more options).

Bracken (abdawson) wrote :

This is one of my major gripes with unity, there's far too much move mouse, wait, see, move mouse again, click. I want move, click.

Dag Ågren (paracelsus) wrote :

This issue really is absurd on desktop machines. The menu is hidden for absolutely no reason - the space left behind after it is hidden is not actually used for anything! This does not save any space, it actually wastes it!

As for the design document,

> Menus are an essentially awkward way of presenting functionality and
> options to the user of an application. Many modern applications are being
> designed without substantial menus.

Be that as it may, most applications DO use menus, right now. This is not going to change in the short or medium term.

> The top edge of the screen has some advantages for fine mouse pointer
> targeting.

As somebody pointed out, IF you can see what you are targeting! Hiding the menus ruins this advantage of the edge of the screen, so this is really an argument AGAINST the current design.

> The top level of the menu rarely shows significant information (it is not
> an indicator) - it consists essentially of category headings, like "File"
> and "Edit" and "View". None of those add any relevant information to the
> task at hand, or wider awareness.

This is entirely incorrect. After a short time of usage, the user will learn in which menu a certain option is, and aim for it. This is certainly "wider awareness". Furthermore, applications tend to (and should) place similar items in similar menus, so this knowledge is useful across applications.

Menu headings ARE very significant information.

> The name of the focused application is less relevant when there is only
> one visible application (maximised) and more relevant when there are many
> applications on screen (windowed).

True, and not relevant to this issue. The menus should be placed to the right of the application name, as they are on OS X.

> Screen space is extremely valuable, and we prefer to use pixels for
> content that is unique to the focused task, or wider awareness, than for
> chrome.

With the current system, the pixels in question go UNUSED. This, too, is an argument against the current design.

chrone (charlesalva) wrote :

make the menu turn on all the time or at least put an option to make it turn on all the time would be a great addition.

if we're gonna copy mac osx, at least we have to do it right! :D

GonzO (gonzo) wrote :

This is my #1 complaint about Unity.

And I actually *like* the GlobalMenu idea.

At least with the Launcher, I could turn the hiding behavior off (I hate it when my shell hides things from me by default. I don't mind a switch to *allow* me to hide things, if I want, but I never generally want anything hidden, ever.)

Normunds (Alistek) (3pm) wrote :

This behavior is NOT acceptable in real daily work, slows down significantly. This is my #1 complaint about Unity as well.
Is there any patch for showing menus?

Samuel Dellicour (smd) wrote :

For me too, the hide and show of the menus slows down my work, and I would really prefer to have them visible at all times.

mach (j-mach-wust) wrote :

While I understand the design decision, I would also much appreciate options:

1. Default behaviour (Unity behaviour)
2. No global menu (Windows behaviour, clumsily settable by removing indicator-appmenu)
3. Always show global menu (OS X behaviour, not settable at the moment)

Yes, I thought that range was what was planned too. What's the status?

OneEyedMan (belligeratiref) wrote :

 One of the things that I find particularly annoying about this auto-hide behavior is that it makes it hard to aim for a particular sub-menu. Essentially, you grab the mouse, hit the top of the screen, then slide along it until you hit what you want. Without auto-hide (IIRC this is how it works on OS X) you can see it the whole time, so you can aim for the target you want without slowing down or correcting course. My understanding of the motive for Apple's choice with these menus is that they are much easier to hit then the windows-style menus because they have an infinite effective depth (infinitely above the monitor). But if you cannot see the menu and you have to hit the top and then slide over, you have to slow down anyway to avoid hitting a neighboring menu. So you've lost much of what makes global menus great.

One almost tolerable workaround I have for this is to hold down the alt-key with my left hand as I reach for the mouse. That means that the menus are showing by the time I move the mouse to hit the top of the screen. Please add my vote to those wanting this feature to be tweak-able. In terms of specification, I would be happy to have it fully displace the current top level menu that show the application name / what page you are on when the delay is tweaked. Another possibility is to have an option where the global menu shows up as soon as the mouse starts to move rather than when it hits the top.

Unhide on first mouse movement would have it flickering on and off the whole time, given it can't tell which mouse movements are going to end with it over the menu. Surely that's going to be way more distracting than just having it permanently visible, which I think is all that most of us actually want anyway, to try to put a brake on all the overcomplicated stuff being discussed.

OneEyedMan (belligeratiref) wrote :

A delay in hiding the menu for a few seconds after movement would prevent flickering. I prefer a permanently visible option too. I simply wanted to provide another option in case it was easier to implement.

Ken (kkinder) wrote :

Interesting how this is a massive usability problem, and it's marked as "invalid" and "won't fix". That's a microcosm of Canonical's attitude toward its users.

Aleve Sicofante (sicofante) wrote :

@Ken: I see it marked as "Undecided" not "Invalid". Maybe there's some hope for the final realease?

I'd be happy if it could be possible in Unity 2D only for now.

I vote for the suggestion by Mach, and since that is supposed to be the way (according to Mark), I'll keep my fingers crossed.

Mark Shuttleworth (sabdfl) wrote :

I heard today that this was not likely to land for 12.04, it might be an
SRU candidate, but the code isn't ready for the LTS given we're in beta
already.

Mark

John Lea (johnlea) on 2012-04-12
Changed in ayatana-design:
status: Won't Fix → Confirmed
Changed in unity-2d:
status: Invalid → Confirmed
Changed in unity (Ubuntu):
status: Invalid → Confirmed
Changed in unity:
status: Invalid → Confirmed
description: updated
tags: added: udp
Changed in ayatana-design:
assignee: nobody → John Lea (johnlea)
importance: Undecided → High
status: Confirmed → Fix Committed
Changed in unity:
status: Confirmed → In Progress
Changed in unity (Ubuntu):
status: Confirmed → In Progress
Changed in unity:
milestone: none → backlog
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in unity-2d (Ubuntu):
status: New → Confirmed
description: updated
John Lea (johnlea) on 2012-04-22
Changed in ayatana-design:
assignee: John Lea (johnlea) → nobody
importance: High → Undecided
status: Fix Committed → New
Changed in unity:
status: In Progress → New
Changed in unity (Ubuntu):
status: In Progress → New
Changed in unity-2d (Ubuntu):
status: Confirmed → New
Changed in unity-2d:
status: Confirmed → New
Changed in unity (Ubuntu):
status: New → Confirmed
Changed in unity-2d (Ubuntu):
status: New → Confirmed
description: updated
John Lea (johnlea) on 2012-05-22
description: updated
tags: added: lim
description: updated
Omer Akram (om26er) on 2012-05-29
Changed in unity-2d:
status: New → Confirmed
Changed in unity (Ubuntu):
importance: Undecided → Medium
Changed in unity-2d (Ubuntu):
importance: Undecided → Medium
Changed in unity:
importance: Undecided → Medium
Changed in unity-2d:
importance: Undecided → Medium
Changed in unity:
status: New → Confirmed
GM Kavi (kavi) wrote :

If anybody comes up with a workaround for this until the checkbox which should have shipped with the initial release is added, please post it here. If there's some config file I can tweak or a patched package I can download (especially if something is backported from 12.10) I'd like to know. I absolutely loathe the disappearing menus.

Isaac Joseph (ikarosdev) wrote :

@GM Kavi: Yes, I have a PPA with a patched version of Unity. One of the options I've added is the ability to disable global menu hide. You can see my PPA here: https://launchpad.net/~ikarosdev/+archive/unity-revamped/

For more information, visit this link and view the last answer. It will show you where I added the option in CCSM: http://askubuntu.com/questions/25785/can-auto-hide-for-the-application-menu-be-turned-off-in-unity

Tim Penhey (thumper) on 2012-09-14
Changed in unity:
milestone: backlog → none
Tim Penhey (thumper) on 2012-09-14
tags: added: exbacklog

This is a massive usability problem an it is assigned to NOBODY ????

This is the biggest usability problem on 12.04 and a massive deterrent for anyone upgrading from 10.04 and have a userbase which is used to Gnome2. Less computer savvy users simply don't find the menu this way.

If Unity want to become a viable desktop, it should support configuring this and ship with allways-visible settings.

Adam Strzelecki (nanoant) wrote :

Hey guys, common, how long we need to wait till this gets fixed? All we see are just some ticket status changes, nothing more, no reponse from Ubuntu team or whatsoever.

Right now I am working both on Mac OS X and Ubuntu, and I find default disappearing menu completely useless, just to show empty space.

Luckily there're some nice patched unity builds at: ppa:iaz/unity
Why just not taking this patch and putting it into mainstream. Having stashes option to zero fade-out time is much better than nothing.

drx (drx) wrote :

This thread shows how bug tracking tools are not appropriate for discussing glitches in the design of an application.

Justin Jovic (justinjovic) wrote :

I really hope something is happening with this in 13.04. Please... its not that hard. Just give users a choice.

Piedro Kulman (piedro) wrote :

I am on Raring Ringtail now - still no change?
What am I missing?

thx, piedro

Dr Alistair Lane (alistair-2) wrote :

The auto-hiding of the menu causes a lot of usability problems for us, to the extent that some have ditched Unity altogether. Making choice available is clearly very important but the default should definitely be to show the menus always for the reasons already given in the report. No-one in our office likes the useless blank space and the need to keep unhiding to see what is available.

Matthew Frost (padatika) wrote :

Any chance of this getting looked at? Been a couple years now and it's pretty annoying.

JoeR (wallydallas) wrote :

I converted Grandma to Ubuntu 12.04. I thank the whole linux communit for an amazing product. This bug of hidden menus is perhaps the worst bug I have ever seen. Grandma worked on IBM systems in the '70's and she's used DOS, and Eudora on Windows 3.1 and on up. Grandma says this is, quote "the most frustrating part of any computer I have ever used". It seems that someone with power has abused it, and made their personal agenda of hidden menus more important than basic UI testing. While this bug is about hidden menus that should be on by default, it is also about the diminishing importance of users in the direction of Ubuntu.

dbailey (duncanbailey) wrote :

I understand that an always-on menu will hide the window title. Here's an idea:

With the always-on menu enabled, maximized windows maximize the old-fashioned way: The title bar doesn't take over the menu bar.

Honestly, this seems to be a problem that Mac and Windows have sorted pretty well. I wish there were a simple toggle between the two behaviors: Ubuntu seems to be reinventing the wheel on this one in a way that's actually less usable.

I agree. Any time I installed Ubuntu onto someone's system, I really have to emphasize to them that they must hover at the top to see these menus. This is not very intuitive; it has to be figured out the hard way or shown to you.

New users need to SEE the options available to them, not FEEL AROUND for them.

Piedro Kulman (piedro) wrote :

There is a setting in gconf to delay autohide.

But it cannot be set to more than 10 seconds. It should be a very little and minor change to allow this to be set to "infinite" ... The fact that no one at the unity team implements this very simple solution is more than annoying.

piedro

Changed in unity-2d (Ubuntu):
status: Confirmed → Triaged
Changed in unity (Ubuntu):
status: Confirmed → Triaged
Changed in ayatana-design:
status: New → Confirmed
Adam Strzelecki (nanoant) wrote :

Would this change be also available as backport in 12.04 LTS? We are using here only LTS versions at university. Also note that this bug was submitted before even 12.04 LTS was released, so I think the fix should also cover 12.04 LTS since it is still supported.

no longer affects: unity-2d
Adam Strzelecki (nanoant) wrote :

Since 14.04 LTS was just frozen and this bug hangs "ONLY" for 3 years on the roll, does it mean we cannot expect this to be finally fixed for 14.04 as well? Then what, 16.04, 22.04?

This is such a minimal fix, plenty of patches for previous unity version, but you just refuse to implement it!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers