How We Got Here: Part I of a Design History of GNOME 3 the Shell
Daf Harries asks Jon McCann and Jakub Steiner: what was the seed that got GNOME 3 going? How does modularity cause problems? And how do new contributors learn a project’s design philosophy?
Editor’s note: Another brief history of GNOME 3’s design process, incorporating some quotes from this interview, is at http://live.gnome.org/ThreePointZero/DesignHistory.
Daf Harries: To start us off, tell us about your history with GNOME and your role in GNOME 3.
Jon McCann: I’ve been quite actively involved in GNOME for about 8 years or so. I was attracted by the design ideology of the project but ran into lots of issues with it in practice. I quickly learned that the most effective way to improve the design was to fix it yourself. I’ve been passionately working to improve the GNOME user experience ever since, by whatever means I can.
For the last few years, I’ve been coordinating the design of GNOME 3, leading the design for GNOME Shell and System Settings, and occasionally jumping in the trenches to help out with some projects. Oh, and trying to stay out of the way and let our talented visual designers and artists do their thing.
Jakub Steiner: I started working on GNOME as an icon designer after being involved with the GIMP project about 10 years ago. My focus has shifted to general visual design over the years, working on downstream projects, such as Ximian Desktop, building on top of GNOME, while contributing to upstream as well.
I had a bit of a hiatus from GNOME and felt like focusing on GNOME 3 visual aspect again. So while I am an old fart when it comes to GNOME, I got involved with GNOME 3 fairly late.
DH: Can you sum up the GNOME 3 design in a single sentence?
JM: Ineffable. Sorry, partly joking. We’ve taken a pretty different approach in the GNOME 3 design that focuses on the desired experience and lets the interface design follow from that. So, it is much harder to describe to someone than it is to let them experience it themselves. With any luck you will feel more focused, aware, effective, capable, respected, delighted, and at ease.
JS: GNOME 3 tries to get out of your way. We didn’t design GNOME 3 for you to discover. You should just be able to get your stuff done.
DH: When work started on GNOME 3, was there a conscious adoption of a design process, or have things been more ad-hoc? For the Shell, I’ve noticed that there was an explicit design document, which as far as I know is not something that happened much during GNOME 2 development.
JM: GNOME 3 was conceived at the GNOME UX Hackfest of October 2008 here in Boston. I think it is noteworthy that even before any kind of process emerged there was an intentional design-first ethic to the project. That was rather uncommon in open source at that time. I think we’ve gradually influenced a culture shift in the community so that it would be considered unacceptable to start a project in GNOME today without a design-first approach.
Perhaps the most notable part of the design process is that everything has been done in the open. We’ve had full transparency for every decision (good and bad) and every change we’ve made. We strongly believe in this model. It is not only right in principle; it is just the best way in the long run to build great software sustainably in a large community. We’re building a wave of change as much as we are building a series of great products. We’ve seen over and over how talented teams of designers have worked to build excellent products in silos but failed to sustain them or to effect meaningful change in the community. As I said, the GNOME 3 design started with a collaboration at the UX Hackfest that spanned the breadth of our community. We’ve always worked very hard to keep it that way. Unfortunately, we’ve hit roadblocks in some places. But we have never stopped reaching out to those folks and still welcome participation in the GNOME process. We understand that it is challenging to work in the open like we do. Many designers are not accustomed to it. You need to have a lot of humility to be able to show works in progress and have an extremely thick skin. People get to see the guts of the process and need to use some imagination to see where things are headed. You also need to prepare your ego for sharing credit or receiving none at all apart from personal satisfaction in the end product. Not all parties are prepared for that, as it turns out. You also have to accept that the entire world can monitor, critique, and learn from your progress while you have no access to or insight into their work done in secret. But those are just the rules of the game. If you want to take part you have to come out and play.
That design document started as my personal notes and things that I had been playing with for quite a while. It was helpful for me to try to organize those thoughts and try ensure they where self consistent and coherent. A design, especially an operating system, really needs to have this consistency. After a while, we realized that it would be useful to share this information online so everyone can see where I think we may be going. That turned out to be pretty powerful I think. One of the biggest challenges in open source design is trying to get folks thinking about and working towards a similar vision. You can’t really organize a community without such a guide. On the other hand, the vision needs to be blurry enough that you don’t get locked in too early and allow others to surprise you or help you refine things. Old-school, detailed specification manuals don’t really allow for that. But I think this pamphlet did OK. And we’ve been fortunate enough to have a lot of talented new contributors show up and keep surprising us. A good example of this is someone like Allan Day. He’s jumped in, engaged the project, built trust with developers and designers, and made a significant impact in a relatively short amount of time.
After a while we more or less stopped using the document because most of us had internalized it and it was time to move to higher order refinements or, in some cases where things just didn’t work as expected, complete revisions. We also transitioned to using wiki pages for most of our work since that allowed for more fluidity and easier collaboration.
That collaborative work was done primarily through online chat (IRC) with the love and help of the GNOME design community, who are not only very talented designers but folks that understand that designing such a complex system requires a very unique blend of holistic and specific thinking. It is pretty hard to do and really hard to do well. Like most good design it requires a commitment. It is birth, not death. Death is quick – like a drive-by shooting or firing off an email. But rearing requires nurture, understanding, empathy, and care. And we’re really lucky to have this kind of support in our community.
JS: I wasn’t there when GNOME 3 was conceived, I was in fact freaking out as a dad during that time. But I got hooked to work on GNOME again during the UX hackfest in London early last year. Of course it was a specific event where there probably was more designers than engineers, but the mood was very unlike my typical FOSS involvement where I’m only asked to use lipstick on a pig at the last moment. Before that I experienced something similar in the GIMP project. Peter Sikking has been asked and agreed to do some excellent design work there. It has been very welcome by the GIMP engineers and some really hot improvements came out of that cooperation for 2.6 and the upcoming 2.8. Both GIMP and GNOME 2 weren’t really designed before, it was very ad hoc.
DH: What was the seed that got GNOME 3 going? Did you come into the 2008 UX Hackfest with some existing design work? Were there a lot of competing ideas from the start, or did you quickly settle on one design?
JM: The desire to create GNOME 3 had been growing in the community for years before a few people finally decided it was time for some action and organized the 2008 UX Hackfest. We learned a lot in the process of creating GNOME 2. We watched the technology landscape change around us. I think, collectively, we were ready for a change. One notable seed was planted as far back as 2005 when Jeff Waugh was promoting Project ToPaZ as a way of exploring 3.0 design ideas. So, it was in the back of our minds for a while.
Consequently, I think most people at the hackfest brought design ideas with them. What was truly remarkable, however, was how much agreement we found. At least in the working group that I took part in, there was a camaraderie and genuine enthusiasm for finding a path forward. After spending a few days doing research, identifying goals and constraints, and generating ideas, we pretty quickly converged on a single rough outline. We spent the rest of the time iterating and refining it, mocking it up, and documenting it on the wiki. Personally, I came away from the experience incredibly energized and optimistic about the future of GNOME. Not only because I felt good about the quality of the results but that we demonstrated we could come together and work as a team. In this case, cooperation was much more fruitful than competition.
DH: You went to the trouble of distilling the design values you wanted for the Shell. How do you go about inculcating those ideas in new contributors? Does it happen via a sort of osmosis, or are things more explicit? Do you think it’s ever useful to keep the design document around, or is it something to write up before you start and leave behind once you’ve got going? And how does the HIG fit in with all of this?
JM: The beauty of it is that you don’t have to convince new contributors of anything. Most often they find you because they identify in some way with your vision or goals. In the best cases you find a kind of harmonic resonance. I am pretty convinced that the most practical way to build a community or a product is through such shared goals. To me, it is the critical difference between a discussion and a fight. You can have a discussion if you presume you are working together – in harmony. If you have fundamentally different ideas about who you are or what you are doing then you are discordant and bound to fight. And no one wins a fight.
I think, after a while, core values and core goals become part of the blood of a community and don’t really need to be held as doctrine. However, I’ve found that it can still be quite useful to consult them when trying to resolve design challenges. For example, our goal of “respecting the user’s focus” has informed a lot of the decisions we’ve made. And that helps keep our design focused.
The GNOME Human Interface Guidelines is primarily for application authors. So, it didn’t play that much of a role in how we designed the OS part of the user experience.
DH: To what degree is the GNOME 3 design the Shell design?
JM: The overall design has always been for the user experience of an operating system. We’ve never really considered GNOME 3 to be separate from the Shell. They are part of the same larger design and not separable components.
One of the things we we set out of fix in GNOME 3 was the over-modularization of GNOME 2. GNOME 2 had become a bit of a Frankenstein’s monster, assembled from bits and pieces that were not always designed to integrate perfectly. You could see the seams. And more importantly, you could feel them and they didn’t feel nice. So, perhaps the most important goal of GNOME 3 is this unification of the experience. When something does not draw attention to itself by revealing its construction it can comfortably recede into the background and become transparent to you. That’s what we’re after.
JS: I’ll only expand on that. Even if GNOME consists of multiple projects with small subcommunities, being involved and proud of their little darling, the focus is on the whole experience. A small component could actually be useful outside of GNOME, but that is not the focus. The UI can become much more streamlined if there is that one particular integration in mind.
DH: Can you give some examples of times when modularity caused problems? And of the kind of integration you’re aiming for?
JM: We began to realize there were very definite costs of modularity. There is a common misconception that modularity and choice within a system increases robustness and flexibility. In actuality, the at-arms-length standardization inherent in that practice dramatically reduces flexibilty in design and implementation, yields no benefit to people using the resulting system, and tragically reduces the overall quality of the product and brand. And as we saw in many cases in GNOME 2 it made certain problems intractable.
One example, is that in GNOME 3.0, for the first time in the history of GNOME (believe it or not), we have been able to integrate network management, user account management, printer management, and system time and date functionality. The only way we were able to effectively tackle these problems is by making very specific choices about what the user should see and building the technology as needed. It is theoretically possible to go through a standardization process to build modular components to implement those user experience goals, but in many cases the costs involved are prohibitive.
Another prime example is found in the implementation choices Owen Taylor made for GNOME Shell. In GNOME 2, the operating system shell was assembled from a variety of different components: a panel, panel applets, a window manager, file manager, various daemons that provided system control through so-called status icons, and so on. Each of these components existed independently and, while we did our best to make them work cooperatively, each behaved slightly differently and we never achieved the kind of coherence that we wanted. Owen made what I consider a very smart choice: to build the shell as a single entity. All of the parts designed to work together seamlessly as part of a single scene graph and with well-understood and deterministic interactions.
A final example, where a slightly different manifestation of modularity caused problems, is regarding the use of internal optional dependencies. Many of these options in isolation seem harmless on the surface, but in aggregate what results is a matrix of internal forks. The system may be built in any number of different ways. Each component must be designed to cope with all of those conditions. In many cases, the result was that the software could only rely on the intersection of those options – the lowest common denominator, if you will. In my opinion, that is the tail wagging the dog. Our first concern really should be what the user sees – the one thing we call GNOME 3.
By the way, I highly recommend checking out The Innovator’s Solution by Clayton Christensen for a very interesting analysis of the costs of modularization.
DH: How do you go about coordinating design over the whole project where maintainership is divided across modules? Have there been cases when it’s been difficult to convince a module maintainer of your global approach?
JM: It can be extremely challenging. I’m not sure we know the best way yet. What I’ve tried to do is continue to articulate the vision, build relationships and trust with maintainers, and communicate with as many people as I can. Of course, it always helps to have patches. And if none of that works – I beg and plead.
Sure, sometimes that isn’t enough. However, in the majority of cases maintainers were happy that we could actually more precisely define how the parts should fit together into a whole. In some cases this was because it made the code much easier to maintain. But more often it was because they really cared about the user experience.
(continued in Part II…)