Experimental Theme Mockup

There are complaints about Ubuntu’s theming again and again. While I don’t think the default in Feisty is horrible, I don’t think it’s good, either. Colour perspective is an important reason for the prevalence of blue backgrounds. Orange jumps to the front, making Ubuntu look “full” and even “loud”.

So I played with warm but rather subtle tones, textures and various ideas in the details.

The shadows are not the same size for every window, but stepped according to z-order for a stronger sense of depth. This means the top window casts a larger shadow on the desktop.

Making no distinction between title and menu / tool bar means that any empty space there should act like the title bar does now. This is the reason why I clearly show the menu are on the browser window.

The size column of the browser has bars representing file size, where the full width is mapped to the largest file. With a very large file and several much smaller files, the only info this would provide is the distinction large / small, but even then it might be useful. It should work best in folders filled with similar files, like image or music collections.

Regarding some other details, please see:
HD Icons
List View Columns
Scrollbars with Popups
Options (check boxes and radio buttons)

Click on the thumbnails for full size images (1280 x 1024)

Experimental Theme Mockup

The Feisty screenshot this is based on:
Ubuntu Feisty
The only changes from the defaults that affect the visuals were turning on “Desktop Effects” and adding workspaces, I think.

EDIT: Since this still gets many hits, I would like to point to more recent work ;)
Experimental Theme Mockup 5

Ardour Latency Dialog

Paul Davis asked me for advice on the Latency dialog he is implementing. This is the state of things:

Latency current

The underlying logic above is to go from minus to plus and from large to small and back to large. With “Use natural latency” in the neutral center. The result looks rather chaotic :)

Latency A

“Use natural Latency” -> Automatic. Under the assumption this is the default, I put it on the left as the thing to start from. It should be a toggle button to inform the user if it is on or not (clicking the other buttons should disable it) . Adding the value it will result in as part of the label in parenthesis or as tooltip would be good, but I’ve been told that value is not readily available.

Using 2 rows allows to split step size and direction. Same size buttons avoid an overly busy layout.

Latency B

If custom widgets are an option.

Note that I treated this mainly on the layout level and did not put to question the elements, as I currently do not have much insight into the underlying needs. So I just trust Paul here ;)

Save Changes Integrated 3

Save Changes Integrated 1
Save Changes Integrated 2

Due to the various concerns that have been raised, here’s another approach, targeted at the WM alone.

I also played a bit with WM button styles and suddenly had the idea of using a colour change on the close button instead of a * in the document window title to indicate unsaved changes. But as that doesn’t show up in task bar items, perhaps both should be used.

The warning colour of the button could extent to the titlebar that serves for both document window and dialog. The window title changes to that of the dialog, as that makes more sense in the task bar, I think.

The dialog is meant to be a movable relative to the document window , just in case the user wants a free view on the canvas, but is placed so as to emphasize the connection. It’s taken right from GIMP; the wording, icon and button labels shall be of no concern, here.

Save Changes 3 Title Bars

Save Changes 3
(Click to enlarge)

Save Changes Integrated 2

After some discussion with Peter Sikking, I decided to modify the design from my previous post.

Before, I placed the dialog part at the bottom, to keep the buttons in the usual place (if you think of the whole window as dialog). This time I aim at a stronger visual separation, more like the dialog appearing right on top of the image window, but precisely aligned and glued to it. The canvas part could either slide down, or the message / button part could appear above it for not having to resize the window.

Note the disappearance of the close button. Close buttons were the user has to wonder if they equal cancel and close or do-whatever and close are a well known problem. For GNOME/GTK, it has been argued that the presence of a Close button on dialogs is an accessibility feature for the blind. Well, I don’t quite get that.

Save Changes 2
(Click to enlarge)

Save Changes Integrated

Applied to GIMP, as that’s where I stumble over the Save Changes dialog most frequently. That dialog appears centered over the image window, so you have to move it out of the way if you want to take a second look on the image you are about to either discard or to overwrite another version with. At least with GIMP 2.3.x and Metacity, the dialog can’t be focused separately, already making it a part of the image window in a way.

After the user issues a Close command, the canvas part of the image window should move up as the menu bar disappears. The window is expanded downwards as needed. The zoom combo box in the status bar of image windows would still be useful, but I decided to go for a clean layout. Zoom options could be given in a context menu on the canvas. Experienced users prefer shortcuts, anyway ;)

The List Changes button is optional. It came to my mind because the text mentioning changes from the last x minutes is nice, even helpful in cases, but vague (well, it points the user to his own memory and time perception, so to speak). Also, the GIMP already has a history panel and the changes dialog would be similar. I wondered if the button label should end with and ellipsis (…), but the HIG tells us that it should only be used if the brought up dialog requires user input.

I tried to shorten the message text a bit. The original reads: “Save the changes to image ‘Untitled’ before closing? If you don’t save the image, changes from the last 5 minutes will be lost.”

Save Changes

(Click to enlarge)

GTK Open Files – Search

A while ago I saw a proposal to add search to the GTK FileChooser dialogs by adding a Search item to Places and thought there has to be better way. Perhaps even better than adding a separate search entry. So here’s my attempt at combining path-bar, location entry, search and making type-ahead find with its problematic pop-up unnecessary. Based on Gedit’s dialog as example.

Click on the thumbnails for full size images.

GTK Open Files Search

The path elements are click-able for navigation, but appear as contents of the entry to give more sense to navigating upwards via backspace. They contain / to give a hint to its use for entering a folder (typing foo/ to enter foo). The entry also accepts ../ to go up, / as start of an absolute path and ~ for home.

Text entered is used for a recursive search on file/folder names in the current folder. Followed by a search inside files, a system-wide search and maybe a system-wide search inside files. Where system-wide could be limited to what a user is allowed to access. There would also be a search for tags wherever available.

The entry has a split for Name and Modified lined up with columns below. So the second part allows searches based on date of modification. There could of course be a third column and entry-segment fo size.

Finally something I had to at least try once. For all I know, current layout mechanisms don’t cover such things and I’m in doubt if it would be worth it:
GTK Open Files Search B