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

Re: [Ayatana] Design problem: Menus hidden by default in Unity



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Conscious User wrote on 17/03/11 16:14:
>...
> Frankly, this sounds like the kind of heat-of-the-moment workaround
> that brought Unity to its current state in the first place. The
> impression I have is the current design is a pile of workarounds:
>
> + Let's merge the titlebar and the panel when the window is maximized
>   and show the menubar. The title is not that important.
> - Oops, now the menubar position differs in maximized windows because
>   of the buttons.
> - Ok, then let's fix it on that position.
> - Oops, ugly gap for non-maximized windows.
> - Ok, let's put the title there.
> - Oops, titles can have different sizes.
> - Ok, let's truncate it.
> - Oops, this is ugly.
> - Ok, let's show the entire title by default and the menu on hover.
> - Oops, now it's inconsistent with maximized windows.
> - Ok, let's do the same for maximized windows. Hey, this brings the
>   title back for maximized windows. Win!
>
> With admittedly some poetic license, this is how I picture it: a
> series of local optimizations losing track of global optimization.
>...

That looks quite plausible.

> Instead of trying to fix the current situation, I prefer going
> back to when the menubar was fully visible and the titlebar
> didn't merge with the panel, and restarting to think from there.
>
> My personal suggestion would be dropping the title in the panel as
> mpt suggested, but keeping the idea of merging the titlebar and the
> panel. This means dropping the title entirely in the maximized
> case, yes. I don't think anyone would really care.
>...

I think that would be a big improvement, even temporarily.

However, when I asked here whether any application uses its menu titles
as an indicator, a couple of people mistakenly replied with cases where
an application uses its *window* titles as an indicator: an asterisk in
many applications to represent unsaved changes, and "(Private Browsing)"
in Firefox.

For those cases, applications would need to redesign to show that
status somewhere else (or to obviate it by, for example, not having such
a thing as "unsaved changes" in the first place).

But if they're going to redesign to remove the need for an
always-visible title in a title bar, why not put the same effort into a
greater win -- a standard full-screen mode that has no menu bar *or*
title bar?

> For fixing the gap, I'm going to suggest something controversial,
> but that I wanted to suggest for a long time anyway: dropping the
> minimize and maximize buttons, following Gnome3's direction and
> under their same arguments.
>...

I think the Gnome Shell designers are badly underestimating the use
cases for minimize. And anyone who thinks dragging is a replacement for
a maximize button probably hasn't done any user testing recently.

- -- 
mpt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2Dh0QACgkQ6PUxNfU6ecoBYQCcDdKecHGEGz/KeDCZyYG28c/u
GxEAoMRwsJnFc1lQYueAjWmJwYsN/5Bz
=Xjt0
-----END PGP SIGNATURE-----