← Back to team overview

unity-design team mailing list archive

Re: 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.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

_______________________________________________

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 		 	   		  

Follow ups

References