unity-design team mailing list archive

[Ian Santopietro <isantop@xxxxxxxxx>]

The problem here isn't the dark toolbar wasting space, it's just making the
space taken more apparent. The issue is the new Gnome 3 settings application
wasting space. The new toolbar is only a color; it does not take up any
additional space.

I'm in support of the dark toolbars. I think they draw a nice distinction
between the UI/interface, and the user content. As it stands, dark toolbars
help the user focus on the content in the window. A dark panel helps this,
but dark toolbars draw a cleaner separation between content, and the tools
that act on that content.

On Sun, Jul 24, 2011 at 05:40, Sony-qs <sony-qs@xxxxxxx> wrote:

> **
>  I'm new here, but that's a nice discussion! That's right, the dark Toolbar
> isn't space friendly. And I began to love the space I won with natty ;-)
> "nrundy" talked about a search box in the toolbar ... and yes they often
> need many space, so why don't put it in the right corner under the toolbar,
> if there's one! The box could be half transparent and hover onMouseOver!
> look@this <http://img715.imageshack.us/img715/7816/4uieph1png.jpg>
>
> Another question: I even miss fixing the Unity-Panel to accept
> keyCombinations for Alt+E (Edit) -> Alt-C (Configuration)! First step is
> working but then you can only choose with Up and Down! Work in progress?
> Greetings from Germany
>
> Am 22.07.2011 19:39, schrieb Carl Ansell:
>
>  I feel that the toolbars should only be used where it makes sense. In the
> earlier example, it did not make sense to have a thick toolbar for just a
> search box.
>
>
> Having them blend in with the top panel could be seen as a good thing when
> the window is active. Both the toolbar and the menu would be together, and
> it is worth remembering that the global-menu means that the panel is
> integrated with the running application.
>
>
>
> When the application becomes inactive, the toolbar could slide upwards and
> out of view, like the unity launcher slides to the left at present. After
> all, if the application is inactive, the toolbar is not going to be needed
> until it becomes active again, in which case the toolbar can re-appear.
>
>
>  ------------------------------
> From: nrundy@xxxxxxxxxxx
> To: ayatana@xxxxxxxxxxxxxxxxxxx
> Date: Fri, 22 Jul 2011 13:08:40 -0400
> Subject: Re: [Ayatana] Oneiric Dark Toolbars waste vertical space - what
> was the point of Unity?
>
>  The newly implemented Dark Toolbars to Oneiric have left me wondering if
> the Developers have forgotten one of the driving principles for Unity--to
> reclaim vertical space?
>
>  Look at the following comparison between Natty as it is today and Oneiric
> with Dark Toolbars. In Oneiric, not only has writing been placed underneath
> the icons (taking vertical space) but there is now a huge/thick
> vertical-space-wasting "Dark Toolbar" with only one item on it: the search
> box. COME ON! I thought the whole point of Unity was to allow more space for
> the items in the window. Does everything that uses Gnome 3.0 have to present
> enormous amounts of chrome with no purpose other than to waste vertical
> space? One of the things I love about Natty is how much vertical space has
> been reclaimed. Now it's looking like all that is going to be gone in
> Oneiric.
> http://imgur.com/a/w9pBQ
>
>  ------------------------------
> From: nrundy@xxxxxxxxxxx
> To: ayatana@xxxxxxxxxxxxxxxxxxx
> Date: Fri, 22 Jul 2011 11:06:08 -0400
> Subject: Re: [Ayatana] Oneiric Dark Toolbars are a BAD idea - here's why
>
>  Dark Toolbars are a BAD idea. The Top-Panel should remain a significantly
> darker color than application toolbars.
>
>  Gnome-shell has the right idea where they made the top-panel black,
> communicating that the top-panel is NOT part of a running application.
> Google has started putting a black top-panel across its webpages,
> communicating that the top-panel is NOT part of the search results or web
> page's content. These dark top-panels provide an always-present, constant
> frame of reference that grounds the user and differentiates it from the
> project's focus (i.e., a web search, a web page's content, or a running
> application). This grounded focus is lost when Dark Toolbars are merged to
> the top-panel.
>
>  The Top-Panel is NOT part of a running application. Yet this is exactly
> what is communicated to the user when application toolbars are essentially
> merged to the Top-Panel. Keeping the top-panel separate from application
> toolbars is even more important now because of Unity's new space-saving
> design. To move an entire window for example, a user can click on the
> Titlebar. Yet dark toolbars would be the same color as the titlebar. To
> restore a maximized window, the user can double-click free space on the
> top-panel. Yet dark toolbars would present loads of free space the same
> color as the Top-Panel. There are all kinds of problems with choosing Dark
> Toolbars.
>
>  Aesthetically it is also a failure. It shrouds regularly used
> tools/buttons in darkness. The buttons and tools should be clearly visible
> and accessible by the user. Not hidden in a darkened state.
>
>  A better approach would be a gradation of darkening as one moves toward
> the top-panel. For example, the top-panel would be a dark color (like
> Ambiance). The Toolbar would be a middle color (like the present cream or
> maybe a gray), in this way bridging the gap, adding a gradation, from the
> lighted/white background where the work is done to the darker panel. The
> work area is lighted because that's where the user's focus is. The toolbar
> area is darker than the work area because it is an area of "peripheral"
> focus for the user as he/she works. Tools/buttons are referenced and
> consulted during the work process. The OS's top-panel is dark because this
> is an Always-Present constant that doesn't change, and it is not actively
> engaged when a user is working on a project, hence it is black/dark in
> color. The Toolbars do NOT share this state. The Toolbars should not be
> identified with the Top-Panel.
>
>  An Operating System's Top-Panel is NOT the same as an Application's
> Toolbar controls. They should not be treated the same visually. Yes, an
> application's Global Menu and window controls appear in the top-panel when
> maximized. But these are items that are established and utilized primarily
> when beginning or ending a work project. A Toolbar on the other hand is
> actively engaged during work. For example, when writing a paper, a user will
> look up to identify the selected font name or font size, whether a specific
> formatting option is engaged, and so forth. Looking at the Global Menu does
> not provide visual feedback like this--hence it makes sense to put it in the
> Top-Panel and have it be darkened in color like the Top-Panel. It is
> readily accessible by mouse and keyboard shortcut to serve its purpose. But
> visually, it has no purpose; hence, one of the driving forces to move it the
> top panel and get it out of the way and prevent it from taking up space. It
> does not make sense from a usability standpoint to treat an application's
> toolbar (which shows the font name, font size, etc) in a darkened state.
> There is already a LOT of dark in ubuntu. Adding more by making the toolbars
> dark is a mark against efficient usability and more of an esoteric aesthetic
> preference that has nothing to do with usability and functional design.
>
>
>  ------------------------------
> From: jorge.ortega111@xxxxxxxxx
> Date: Thu, 21 Jul 2011 22:07:25 +0100
> To: ayatana@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ayatana] Oneiric Dark Toolbars/Menubar Issues
>
> I think it is an interesting solution. I suggested before something a bit
> more radical: that every application when open, would create its own virtual
> workspace. To do this only for maximised  applications is also, I think, a
> good idea.
>
> On 21 July 2011 19:36, Jonathan Meek <shrouded.cloud@xxxxxxxxx> wrote:
>
> I recently say the post on OMG!Ubuntu! about the possibility of dark
> toolbars being included for Oneiric and this sparked an interesting debate
> among someone I know who I asked to draft his thoughts on the issue for post
> to the Ayatana list for discussion. Here it is:
>
>
>  PROBLEM:
> The management of maximised windows in Unity is principally flawed and
> could potentially cause confusion.
> This problem arises due to the location of the toolbars of maximised
> windows, and the global menu in the Unity panel.
> Consider the screenshot at http://cdn.om. Both the toolbar and the menu
> would be together, and it is worth remembering that the global-menu means
> that the panel is integrated with the running
> application.gubuntu.co.uk/wp-content/uploads/2011/07/2011-07-19-150134_1366x768_scrot-1.png<http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/07/2011-07-19-150134_1366x768_scrot-1.png>.
> In the screenshot, you can see that because of the dark theming of the
> toolbar of the image preview window, it appears to be a part of the panel
> and the global menu.
> The screenshot demonstrates a situation in which this is undesirable. It
> may appear to the user that the toolbar for the image preview application is
> a part of the global menu for the settings application. A similar problem
> may arise in the event that a user has, for instance, two documents open in
> a word processor, and one maximised behind another unmaximised window. In
> this case, it may appear that the toolbar of the window behind operates on
> the window in front. This could cause confusion and annoyance.
> SOLUTIONS:
> There are a number of potential solutions, including theming inactive
> windows differently and displaying the title bar of full screen windows.
> In my opinion, the best solution I have observed is the solution in use on
> Mac OS X Lion. Lion creates a dynamic workspace for each maximised  window,
> in effect treating maximised (or full-screen) applications as additional
> workspaces. This means that it is impossible to end up with a situation
> where an unmaximised window is in front of a maximised window.
>
>   From Jonathan Rothwell <jonathan@xxxxxxxxxxxxxx>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________ Mailing list:
> https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.netUnsubscribe :
> https://launchpad.net/~ayatana More help :
> https://help.launchpad.net/ListHelp
>
> _______________________________________________ Mailing list:
> https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.netUnsubscribe :
> https://launchpad.net/~ayatana More help :
> https://help.launchpad.net/ListHelp
>
> _______________________________________________ Mailing list:
> https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.netUnsubscribe :
> https://launchpad.net/~ayatana More help :
> https://help.launchpad.net/ListHelp
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Ian Santopietro

*Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html*

"Eala Earendel enlga beorohtast
 Ofer middangeard monnum sended"

Pa gur yv y porthaur?

Public GPG key (RSA):
http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x412F52DB1BBF1234