Lack of relationship between the top bar menu and windows in the restored state

Bug #764829 reported by Charline Poirier on 2011-04-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ayatana Design

Bug Description

In testing, participants were able to use top menus only when the window was in the maximised state. In other states, participants did not associate the top menu with a selected window and were not able to print for example. When a window was in the restored state, participants believed that the top menu showed options relevant to the system and not individual applications.

tags: added: nattytesting
Matthew Paul Thomas (mpt) wrote :

People could use the menus only for maximized windows because they discovered the menus by accident while mousing over the close/minimize/unmaximize buttons in a maximized window. They then concluded that mousing over the close/minimize/maximize buttons was the way to access menus, but that didn't work for unmaximized windows.

Therefore, this bug could be fixed by making the menus visible even when you are not mousing over the close/minimize/maximize buttons (bug 732653). This would also have the benefit of making menus much faster to use.

Secondarily, the focused window and the menu bar should look more like each other than either of them look like a background window. Currently, other than the window frame, there is no distinction between the focused window and other windows (bug 534799).

Andrea Cimitan (cimi) wrote :

Well, it's really annoying having to move the mouse on the top panel just to see if there's a menu with interesting options or not, and sometimes, you can feel difficulties in getting of which window the menu belongs.
Even if I'm using Unity from months and I know that the menu is on top

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

Other bug subscribers