Re: [Ayatana] Persistent menu mockup

[Luke Benstead <kazade@xxxxxxxxx>]

On 21 April 2011 06:36, S. Christian Collins <s.chriscollins@xxxxxxxxx> wrote:
> On 04/20/2011 11:41 PM, Conscious User wrote:
>>
>> Without explaining what is your idea for maximized windows, the
>> usefulness of the mockup is very limited.
>>
>> Most people would agree that making the menubar moving left and
>> right is not an acceptable solution, so explaining what would
>> you do in the maximized case is essential.
>
> Why couldn't the same solution work for maximized windows as well?  The only
> difference being the presence of the close, minimize and maximize buttons to
> the left of the global menu when a window is maximized.  Sure, this would
> cause the menu to shift over to make room for the window buttons, but would
> this really be so much of a distraction to people?
>
> -~Chris
>

This doesn't really solve any of the problems with the current
implementation, only the menu hiding problem.

The problem is, if a window is maximized and it's controls move to the
panel, and then a smaller window is focused how do you close the
maximized window without focusing it? How do you avoid the ambiguity
caused by both the maximized and smaller window both needing space in
the panel. And more importantly, if we keep merging the maximized
window the panel it looks like the window controls/menu/title of the
focused window are those of the maximized window.

The real issue is there is just not enough room in that panel for all
the stuff we want to put in it. Any suggestions we make are just us
trying to tweak a broken design. Let's start again, what was the goal
for moving this stuff in the panel?

a. Increasing available vertical space
b. Making things easy to find and hit (e.g. the continually
over-emphasized Fitt's Law)
c. Remain consistent

The current design succeeds at #a and fails #b and #c. The menu isn't
easy to find, it's not easy to hit, and the panel is not consistent.

So, let's rethink from the beginning, what elements do we have access to?

1. The application name
2. The window title
3. The window controls
4. The menu bar
5. The application icon

#2 is required, #1 and #5 can be either/both/neither, #3 is required,
#4 is required. In 10.10, all of those items are accessible whether or
not the window is focused, this is consistent. So, any movement into a
panel will result in some context switching. We have the following
options:

1. Move controls, title and menu into the panel but DO NOT merge the
titlebar. Everything would be consistent (always displayed based on
window focus, no visual ambiguity), but what we've done is basically
pointless because now we have an empty titlebar on all windows
2. Move the menu bar to the panel, and DO NOT merge the titlebar. Now
we have what OSX settled on, probably a good balance.
3. Merge the window controls and title on maximize only, keep menu
bars INSIDE the window. No visual ambiguity, we save vertical space on
the title, and it looks pretty cool. Everything is consistent.
4. Remove the panel completely. If we are trying to increase vertical
space, that would be the first thing to consider dropping. We'd need a
new home for the indicators.

Personally, I think #3 is the best option.

But it doesn't matter anyway, none of it is gonna change, and any
discussions on this list will be largely ignored,

Luke.