The Past

My first ever libre software gettogether was GIMPCon in 2000. The location at the CCC gave it the proper underground vibe. That gathering later became what is now Libre Graphics Meeting when the GIMP and Scribus folks thought there’s some possible synergy to benefit from.

The future

It may sound like a little blasphemy for a GNOME person to say LGM is my favorite conference. I dig GUADEC for its mix of developer and user oriented talks and workshops, but at LGM this synergy seems to be working even better. There’s probably a trend towards attracting more designers than engineers, and I don’t know of a tech conference where there’s pretty much 50:50 gender mix (perhaps in Madrid there were more women than men even).

I want more conferences or gettogethers like this. Feedback from an animator struggling to finish a task is million times more valuable than online polls asking for a feature that exists in other tools. Small community projects struggle greatly with focus and motivation. These user<>developer sessions should not mean folding every single suggestion into Inkscape feature and SVG spec, but seeing tools used is the best we have for user testing.

There were some humorous mailing list like moments too (I hope video archives will be posted, the sessions were recorded). We had a nice example of miscommunication between Boudewijn and Mitch during the GIMP Q&A, but there is room to turn that “but printing spot colors is way more expensive than CMYK, stop ignoring your users” to “it’s the actual workflow, retaining control over individual channels during the process, that makes CMYK a subset of stop color process, the output/print process remains the same.” when talking off a mailing list. People sometimes need to talk face to face to turn those faster horses into cars. I have lost all faith in non-technical or controversial topics ever resolved on a mailing list.

Workshops

I also really enjoyed the “get your hands dirty” sessions such as David Revoy‘s Krita speedpaint workshop that are the carrot-at-the-end-of-the-stick for potential new designers giving libre graphic toolchain a go. Seeing amazing art created with our tools is an amazing motivator that allows to overcome some bumps on the way and actually find strength to find unfamiliar solutions or actually bite the lip and start the dialog with the developers (it’s harder than you think). I don’t think my painting skills will improve any time soon, but the workshop did expose a significant omission from the Wacom settings for non-screen tablet users. It felt the Krita developers are on a good course working closely with David to shape the tool and getting amazing promotion and an actual product in return, in a similar way the open movie projects dramatically improved the quality of Blender.

Type

A significant number of talks related to type. Ben Martin and Dave Crossland presented the collaboration features of the new Font Forge. This sounded really intriguing for me, because a lot of the design process is tedious and horrible and things like metrics are a torture that I found much more bearable when we did it with Patrys the other day.

Ana and Ricardo made me feel guilty about never finishing or publishing some of my fonts, because I felt they are too raw but then never gotten to finish them. They mentioned their new foundry and some utilities like the autospacer, giving you a template workflow rather than starting from the dangerous and feared blank slate.

If you ever needed some hand holding for designing your own type, Dave pointed out an extremely nice guide to me.

Getting Started

I gave a short talk on the work we did on Getting Started, but in an expected way was dragged away before I could show some guts of the project. As there’s been interest to see behind the scenes more, I’ll try to blow the dust off the design team youtube channel and do a screencast.

LGM Rocks

I really had a blast seeing everyone again, and came back with a list of things to do and also the energy to do so. Big thanks to the organizers and in particular the GIMP folks for their continuous support of the event.

Recently I saw a few people commenting along of ‘GNOME 3 icons being crap’ so I investigated what the actual core of the issue might be. When dissing the years of work that went into creating the system theme and pushing app icons upstream, most of the commenters seem to actually have a problem with the folder icon.

The GNOME folder is a result of using the actual beige color that is both the real world folder material, and the legacy of Tuomas’ GNOME 1 folder. Easy things are hard so it’s a result of endless iteration with my soul mate, Lapo Calamandrei, to get the icon look great at the small sizes, but also to have the icon snap to the render grid well for the common high res sizes (64, 96, 128, 256). It repeats well in a grid. I feel the voices disliking the beige folder are the same voices disliking the grey folder in the original Tango set. We ended up listening to those folks and changed it to blue, but I ended up regretting the decision.

The blue folder grabbed way too much attention for something that’s used when browsing for the actual content. While a lot of effort went into making the folder, we don’t actually expose it all too much. Exposing the directory structure is the pre-GNOME 3 world. What we focus on now are the applications.

Which is actually the other issue people seem to attribute to “GNOME sucking”. It is true that the current reality of opening up the overview is quite different to the ideal mockup.

Many apps ship with very sub par application icons. One of the solution to this problem is to “take over” the theming of Application icons. We have been there in the past and just like taking over app distribution by distro packaging, there is a lot to lose when you centralize something that should really be left to the application authors. The app icon is the app’s identity. Sure it’s more difficult to convince the upstream to take your work despite it not being created by an algorithm, but taking away a project’s identity in the name of policing the aesthetics of the overview is not the right approach. We toyed with the idea of forming a blacklist and buttonizing some icons in prior to the 3.0 release, but came to the conclusion we should help app authors with guidelines and design help instead. For the life of me, can’t find this on the wiki anymore.
We’ve been successful in pushing app icons upstream for projects such as Inkscape, GIMP, Blender, Transmission and helped other projects such as Font Forge to create a multi-resolution icon adhering to the Tango guidelines. Another aspect of taking over all app icons by overriding them with an all-encompassing theme seems to be “consistency”. The word is used in a sense that the icons share a common shape and perspective. Now while that makes them form a really nice grid, it goes against the most useful attribute of a good icon — being distinguishable form the rest. I love the challenge of being restricted to a button shape and I’ve certainly drooled over some of the smart icons fitting into a rectangle pill, but a unique silhouette is really helping in identifying the app in the grid.

We do have a wider choice for the perspective in the Tango guidelines. Experience has showed us some objects simply can’t be made immediately distinguishable facing straight, so the on the table perspective is used sometimes. But that doesn’t suddenly make the set inconsistent.

To make myself clear, the icons aren’t perfect. We have a lot of issues to fix, but I felt I needed to express my stance on the repeating comments.

• Greyness of GNOME icons.
• Tile fit.

As part of the developer experience hackfest we are working on making the documentation more relevant and up to date.

A long while ago, I wanted to work on presentation of the upcoming HIG and using staticmatic to leverage haml, scss and a few helpers created a static reponsive site in the current GNOME.org styling.

But it’s time to murder my darling. To keep the content up-to-date and translatable we decided to use Mallard instead. So yesterday, during the DX hackfest I patched up the current library-web stylesheets to be responsive. Checking out the upcoming tutorials, API reference and design documents will be enjoyable on mobile devices too. You can track our progress on the hackfest wiki pages.

Hello in 2013! It has been ages since I’ve blogged anything, mainly because I enjoy Google’s social site, google+ way too much, despite, or perhaps due to it being filled mostly with my geek friends.

I decided to post this on wordpress, but it made me think about the possibilities to break the walled garden of g+ and somehow syndicate certain posts on this site. But that is perhaps material for another post.

What I wanted to share are two stumbling blocks, trivial for most of you, but very frustrating until you know the solution. A total must for your typical batch processing is the xargs utility. Used typically with find, it allows you to perform commands on a list of arguments. By default it lists all arguments on one line:

find . | grep svg$ | xargs echo

Now find itself has a million switches to perform filtering, but I prefer not diving into the manpage if given the option The default behavior of `xargs` leaves a lot to be desired, because usually there is a big list you are working on, and bash and other shells have a limit on the number of arguments. Additionally, it is very likely you will need another argument to follow the one you got passed. The magical parameter you’re looking for is -i that splits the inline list and calls the provided command separately for each passed argument. You can place that argument anywhere on the commandline using {} brackets:

find . | grep mp4$ | xargs -i ffmpeg -i {} -sameq {}.webm

So while the manpage surely includes this info, I bet someone will find this through a google query and will appreciate it

The other big stumbling block that I also hit with ruby is about Xpath queries in python. Big thanks to Patryk Zawadzki for the solution. When parsing inkscape svg xml documents, they actually include numerous namespaced tags, so simple queries like //rect will fail. You need to prepend all elements with the svg namespace (such as //{http://www.w3.org/2000/svg}rect). Full example here:

#!/usr/bin/env python3

import glob
import os
import csv
from xml.etree import ElementTree

members = csv.reader(open('members.csv'))
TEMPLATE = 'template.svg'

for data in members:
  print(data[0])
  svg = ElementTree.parse(TEMPLATE)
  svg.find(".//{http://www.w3.org/2000/svg}text[@id='memno']/{http://www.w3.org/2000/svg}tspan").text = data[0]
  svg.find(".//{http://www.w3.org/2000/svg}text[@id='name']/{http://www.w3.org/2000/svg}tspan").text = data[1]
  svg.find(".//{http://www.w3.org/2000/svg}text[@id='validto']/{http://www.w3.org/2000/svg}tspan").text = data[2]
  svg.write('./out/%s.svg' % (data[0]))
  os.system("inkscape -A ./out/%s.pdf ./out/%s.svg" % (data[0],data[0]))
  os.unlink('./out/%s.svg' % (data[0]))

Update: Turns out the “ evaluation in the xargs example was flawed. Thanks for spotting. Additionally, find itself seems to have an iterator of its own:

find . -name '*.avi' -exec echo ffmpeg -i '{}' -sameq '{}'.webm  ';'

As Barbara has been rocking the symbolic world, she was interested in the fullcolor Tango icons as well. We did a live Hangout session together with Garrett which we didn’t advertize anywhere, and yet some 20 people joined in. Now it’s up on the GNOME 3 Design youtube channel for your viewing pleasure.

Pssst! Looking for icons to design?

UX Hackfest

Some of us came to A Coruña a few days early to work out some pending issues, like the File Picker or the Initial Setup. We later learned that it was also quite useful for the students to see the early stages of the design process.

GUADEC

As always, GUADEC was packed with interesting talks, but it’s fair to stress out how well it was all organized. Props to the galicians!

Yet again GUADEC managed to inspire me to create, rejuvinated my motivation contrasting with hearing “it can’t be done” all the time. I found Adam Dingle and Jim Nelson’s talk on sustanability and ways to crowdsource Free software projects quite inspiring and something we need to focus on when designing Software. It relates to the ecosystem diversity and the historical focus on shoving everything into the core moduleset and the resulting friction we mentioned in our talk (Hopefully the videos will be available soon).

The stuff I’m excited for? OSTree will hopefully decrease the iteration time and make me frown at jhbuild a little less. Smooth animation within applications that Owen Taylor presented is also something that I hope will be easy for developers to make use of. So back to work…

Had a blast at GNOME Asia Summit in Hong Kong this year. I actually started my Free Software oddyssey in Asia, when I joined Tuomas at Global Linux 2000 in Seoul. Sgi was a big sponsor, to give you an idea how long ago that was

Initially we intended to do a design workshop, but based on the preferences of the audience, we made more of a talk and demo. Allan and Jon explained the process we undertake to design GNOME. Due to popular demand I’ve given some insights on icon design.

Hong Kong City University, the venue for the GNOME Asia Summit.

I have to thank the organizers for setting up a great event, allowing us to spark up the interest in GNOME and address people to take part in the GNOME project in areas other than code. I hope to be able to participate in future events.

After the conference we took the opportunity of being at the same place to sit down and work out the kinks of some designs. We discussed details of the message tray, banner queing, initial setup and a fair bit more*. I have a much better feeling about the app-provided search in shell now too. Another quite fruitful conversation was about the role of the dash in the future. Quite related to the work I’m doing with Joost on the app picker right now. I hope to have more updates soon.

I’m currently populating the photo collection here, but nowhere near getting through the hundreds of photos I took.

* I’m sure Allan will be doing a post on this too and he usually does a much better job writting a summary.

GNOME 3 introduced a new style of icons we call symbolic. Last year, Meg Ford joined the effort we kicked off with Lapo and did a great job extending the theme coverage, without us having any style guidelines in place yet. This year, we’ll have another Woman Outreach program participant joining the effort, so I’ve edited a little video introduction on how we design these icons along with a little overview of all the icon styles currently in place.

Allan has done a great job giving an overview of what we’ve been focusing on recently among the design team. This still leaves some room for me to give a peek on some of the details of what’s coming.

One of the decisions we made for GNOME 3 in terms of identity, was embracing Dave Crossland’s Cantarell and its open source pedigree and making the typeface our own. So far I have only been humbly shaping minor aspects of the typeface, but a long standing issue has been left long untouched, support for Cyrillic. Typeface design is certainly going outside my comfort zone. Luckily most of the glyphs can be dealt with by borrowing from their latin counterparts. The major part of the work involved (and will involve) some shape tweaks, metrics and hinting. Again, the bold weight poses bigger challenges at small sizes, which is our main focus.

Substituted cyrillic glyphs were all sorts of broken.

.

As you can see, there’s still some tweaking left to do on the shapes and hints before rolling out 0.0.9, but those not intimidated by jhbuild, please give it a go so you can help me identify issues that aren’t apprent to me. Another set Cantarell needs to support is Greek, as it’s stylistictically required to keep close to the Latin set.

If you’re looking into creating high fidelity mockups of your GNOME application, you might find this widget asset library handy.