Misc. Notes from GNOME UX Hackfest, Tuesday

OSD & Panel Icons

Yesterday jimmac and hbons worked on Moblin icons, with the idea we could use the style for GNOME OSD (on-screen display, e.g., when you change your system volume, the big speaker icon pops up) and possibly the panel / applet icons.

Why use the moblin style? It’s much quicker to put together than the high-res icons (it can take 15 hours straight to do one of these); the Moblin style requires much simpler artwork. The style, because of its simplicity, could potentially be good high-contrast / accessible icons as well.

How do you get the Moblin icons?

git clone git://git.moblin.org/moblin-icon-theme

Challenges

We’d like complete coverage but won’t have it immediately. We should have a fallback – the Ubuntu folks suggested using a suffix for naming/calling icons from apps. E.g, if an application that wants to use this style they need to explicitly ask for it, if it doesn’t exist it falls back to the normal icon. (I’m not 100% sure how accurate my notes are here.)

One issue with the style is that it doesn’t work for every background color. There are a couple of potential solutions here:

Add an extra stroke of the shape in an inverse color around the outside of the icon, similar to how Tango icons have two outlines, one light one dark.

Pick the colors from the gtk theme.

One other challenge is they don’t work at smaller sizes right now; we potentially have to adapt them for smaller sizes. Since screens are getting more dense these days, we could consider doing 22×22 or 24×24 as the small size?

There is a single Inkscape SVG with all the icons, and a script renders the individual icons. It takes 20 minutes though; it’s inefficient.

To do

What work needs to be done to make this happen for GNOME?

Icon recoloring – make it possible to recolor the icons to work on any background. Can we implement them so they pick the color from the GTK theme settings?

We need additional icons for GNOME Shell that are not in the current Moblin set: battery, network, status are some examples.

We need to see if the Moblin icon theme license will be an issue for GNOME usage. Moblin is Creative Commons Share-Alike 3.0 => is it compatible with GPL? Will this cause any issues?

Consideration: in the indication of extremes – if volume is all the way up or all the way down – color it so it is visually different?

How to get involved

The mailing list gnome-themes-list might be the place to continue the conversation.

Nautilus discussion

John from Canonical showed us some mockups he had done to try to simplify Nautilus. We discussed them a bit. Here are some random notes from the discussion:

remove combo box to change nautilus view, just use menu?

frustration that nautilus is becoming like midnight commander, not beautiful to use, too complicated

snap to side-by-side like in windows 7 would be good and would remove need for split-pane.

search in nautilus sucks

confusion between magnifying glass icon for search vs zoom

Things to consider removing from ui:

zoom controls

tabs

Things to add to ui

undo

search folders

sharing / collaboration – share with

context-sensitive actions toolbar

Improving GNOME Designer Collaboration

Two main features that would make life easier:

Easier syncing of files

Version control

Garrett and jimmac use Dropbox for this today, but it is not open source and is capped at 2 GB.

Canonical Use Case Mapper

John showed us Canonical’s Use Case Mapper, which will hopefully be open-sourced at some point so GNOME designers can use it. It interfaces with Google docs at the moment.The template it uses in Google docs is public.

Special bonus tips that happen when us designers are in the same room

Both of these gems are from Garrett:

I kept trying to take pictures with my digital camera when my memory card was not in it. Garrett’s tip: leave your memory card door open when it’s out so when you pick up your camera you know right away the card’s not in it.

Rate this:

Share this:

Like this:

LikeLoading...

Related

About Máirín Duffy

Máirín is a principal interaction designer at Red Hat. She is passionate about software freedom and free & open source tools, particularly in the creative domain: her favorite application is Inkscape. You can read more from Máirín on her blog at blog.linuxgrrl.com.

Networking and Battery icons – we have those too – they’re currently in dalston and the devices panel rather than the icon theme though – I’m sure we can add them without too much trouble.

Icon coverage – if there’s a specific icon missing please file a bug in Moblin bugzilla and we’ll add it to the todo, obviously, patches welcome!

Icons licensing – we obviously need to check the specifics on this internally – but we are very happy to broadly contribute to GNOME and a number of the Moblin UI projects are maintained in GNOME already (like Bluetooth). Basically, drop me an email and we can certainly try and sort out whatever licensing GNOME needs.

True. However, the point was that tabs were implemented to solve a problem — using less screen space / window management effort to have multiple open directories — which they did. If they are removed *without a replacement*, whatever it will be, the problem would regress to an “unsolved” state, that’s all.

As the (lazy) maintainer of High Contrast icon theme, I agree on moblin icon theme appearance. Unfortunately the actual needs for a11y (wide strokes, simplified shapes…) will force us (me, when I’ll find some spare time) to redraw all them :(

But I’m very thankful to moblin icon theme, it will allow me to spend time drawing, not designing.

Being the one behind the small script that generates the icons from the big SVG file, I can try to improve things so to make the work flow as sane as possible.

For now, the “it takes 20mins to render everything” issue is “solved” by having the generated icons into the git repository and having an –id option to the script which takes the xml ID (ie the icon name) to re-render a specific icon.

Some stuff can be improved, small to big items:
* –id could take a glob pattern ie: –id ‘go-*’
* we have a small number of moblin-specific quirks
* actually generate the icons in their context directory using a small xml files describing where an icon should go based on its name
* use the CPU cores available on your system
* investigate a librsvg-based solution to render the icons instead of inkscape

We do not have that split view in Fedora. My jaw dropped when I saw it for the first time yesterday (not in a good way.) What do you use it for? It seems such a confusing model – which pane do the menu items apply to? It seems very confusing….

Honestly I have it on all the time, and I’m a big hater of midnight commander. The reasoning is simple: when I have to work with multiple directories (I often do) I can open them in the split view (other than using tabs); then I can drag and drop between the two. The way it works is that the view which has focus, also gets all events (menus etc), while the other is greyed out (but dnd still works of course).

For most people who see my computer the first time (eg. at work) it’s a bit of a shock (two folders, but wait, they’re the same thing!!!). Then I open a flash drive in one pane and my documents in another and drag and drop between them… and suddenly it’s like… ahhhh wow!!! o.o

Coming from windows users I’d say that’s a plus =)
As I said, it would be great to keep it, just let everything be optional. In fact, it’s already optional all now. Sometimes I turn off split view, and only rarely use tabs when I have many directories to browse (like when I messed up my nvidia driver).

I started my serious computing back in the DOS days with Norton Commander and then DOS Navigator (a *much better* Norton than Norton) and to this day I prefer Midnight Commander with split view for about anything file management related, it makes me work very fast.

# snap to side-by-side like in windows 7 would be good and would remove need for split-pane.

I agree with this point – it would let you have “split-pane” in all your applications (and split-pane is very useful for when you need to drag-and-drop stuff).
However, something which I think metacity should do is this: if I have two windows tiled on the left & right of the screen, and I resize one of them, the other should resize accordingly (just like a tiled wm) – this is something which I haven’t seen Windows 7 do.

Split pane is nicer to many than snap to windows because you get to reduce the amount of redundant UI and you simplify management of the views for users, so they don’t have to try arrange windows or have to conceptualise their relationship.

Think about the multiple views into buffers through Emacs. It’s awesome.

Wow, you used emacs as an example in usability? Really? I mean any expert program is usable for experts but I wouldn’t wish emacs on the casual computer user (for that matter Vi even though for many things I myself am more productive in Vi that is not true for the majority of computer users)

But please, please don’t take tabs out of nautilus. That has been one of the biggest reasons I’ve started integrating it back into my day-to-day workflow. (Being a Fedora user, I’ve not used split view. Bet I’d like it.)

As for use cases, without taking the time to fully flesh out these thoughts, I typically like to have specific windows dedicated to specific tasks. My tabs in a webbrowser are related, and a new topic/task triggers another window and set of tabs being opened. Likewise for the shell. This acts as an additional abstraction on top of the other task specific construct I use, virtual desktop per task. If I’m editing related files within a directory structure, I tend to share the desktop real-estate between nautilus and various other apps. A PDF, webbrowser, two shells, and a single nautilus window open pushes even my largest monitor to the edge.

In addition, managing multiple windows is cumbersome, as I rarely want to see the items separated. When I do want to break out or reintegrate tabd, dragging and dropping seems an ideal way to achieve this in a seamless manner. (I’d love to see additional file drag-and-drop refinements added for the tabbed use case, such as a variation on the infamous spring loaded folders ala OSX, too!)

As for menu items, I generally manipulate icons with right-click menus and keyboard shortcuts, not top-level menus. I’d rather loose the menus than the tabs. :)

Again, I love the strides GNOME has made on the UI front in the past, and love the just works mentality that has come with it, but we still need powerful features, even if they do not fit into ivory tower ideals of user-friendliness.

“But please, please don’t take tabs out of nautilus. That has been one of the biggest reasons I’ve started integrating it back into my day-to-day workflow. (Being a Fedora user, I’ve not used split view. Bet I’d like it.)”

If you’re using Fedora, I don’t think you’ve seen the tabs we are talking about. They aren’t available in Fedora.

There seems to be a misunderstanding of why split-view is useful. Let me rephrase the reasoning behind split view.

Split view is _NOT_ there to work around Window Manager limitations or bugs. A WM snap function, while handy, would not offer identical functionality to split view.

The key difference also isn’t the avoidance of visual clutter (repeated menus etc) on the second window.

Generally speaking, an important concept of file handling (and here especially copy & move operations) is the notation of a source and a destination.

The small, but important, difference between split view and two Nautilus windows side-by-side is that split view introduces the concept of a “default target”. A window manager cannot do this, and this is also the reason why it makes sense to have 2 panes, but not 3 or 4 of them. This is also the reason why split-view may make sense for applications for which a source/target notation is fundamental, and not for others.

This default target is also represented by the “{Copy | Move} to other pane” menu items. Users that need to do heavy-duty file handling can assign keyboard shortcuts to those menu items, and move around files with a single button press.

The “default target” notation offers even more for hardcore power users, which can access both the source and the target pane in their Nautilus Scripts (and write for example a “diff these two directories” script with very little effort). This surely isn’t possible with a WM snap either.

Users with simpler needs aren’t really affected much of all this. The only effect for them is that “extra pane” option in the view menu that they don’t wanna click. I have a hard time understanding why that would make people to “drop their jaws”.

I actually think that it is a very natural model to show source and target location when they are that fundamental to the typical action that the user wants to do with a given application. I find it much more natural than the clipboard copy/paste stuff that is generally accepted because people got used to this strange idea.

As for the people that fear split-view is confusing because they don’t know which pane the menu and toolbar applies (I guess mairin is not alone in this fear), I doubt they ever used it before commenting. Just go ahead, and give it a try. You’ll see that only one pane is active at any given time, the other one has a greyed-out appearance. Naturally, all toolbar and menu action apply to the active one, and not the the greyed-out one. Just like everywhere else (and this clear visual difference between the pane that has the focus and the one that doesn’t is actually another advantage to having two Nautilus windows side-by-side).

The reason for Alex to push split-view in at this time was the change in focus for Nautilus, transisting from a desktop shell and application launcher (a task that is now supposed to be taken over by the GNOME Shell) to a file manager. Of course, he explained it much better himself [1].

I think what Mo is getting at here is if you somehow got into the split view state without understanding it, it would be very confusing to the user. Lets not get so attached to current solutions that we don’t look for alternate clearer solutions. For example, is there a way (perhaps not available in current GTK+ yet) we could make the source/destination model clearer?

“if you somehow got into the split view state without understanding it”

I see. That is basically true for all modes in all applications, or all settings in general. If you, for example, accidentally switched between spatial and browser mode in Nautilus, it would be equally confusing. Actually, it would be even more confusing, because you don’t see the results right away, but only upon opening the next folder (or even opening a new window) – so it’s harder to make the mental connection to the option required to switch back.

But of course, “others have the same or worse problem” is never a good argument. How about putting a minimal sunk-in close-button (the style that tabs have) right to the location bar? But I guess, this is a matter of taste again: Cluttering the UI with more graphical elements vs. even more visible way to get out of split-view mode.

I have not played yet with Nautilus split view (it isn’t available in Fedora) but from my experience with split view in mc I can say this: figuring the source/destination is NOT the problem (I have to check every time if I am in the left or right panel), the important part is the speed. If I want to be fast, use both hands and a lot of shortcuts, then I use mc. If I feel like lazy and want to use just the mouse, then I use Nautilus with spatial view.