A while back, I read with great interest [Vincent’s blog entry](https://www.vuntz.net/journal/2008/10/22/494-desktop-shell-from-the-user-experience-hackfest-general-overview). I also heard from my fellow Canonicalites about the progress made the GNOME hackfest. I am rather interested in the opportunities before us with the GNOME platform and a new approach to the shell, so when I read [Owen’s update](https://blog.fishsoup.net/2008/11/22/gnome-shell-status/) I may have actually drooled. Instead of grabbing a tissue, I instead grabbed `jhbuild` and built said shell. Instructions for the brave are [here](https://live.gnome.org/GnomeShell). Its actually pretty simple, so no real bravery required.
Things have changed a lot in computing in recent years. Back when GNOME 2.0 was released we were not faced with the plethora of use cases that we are confronted with today. Social networking, online services, the cloud, collaborative editing, (micro)blogging and other such buzzword compliant technologies are now a staple in not only the life of technical types like us, but regular people: even my dad has a blog. In recent years the industry has pointed its innovation-ray squarely at people and what people do. We are no longer expected to dance to the computer’s tune, but it dances to ours.
The GNOME community has been on something of roller-coaster reacting to this, and the subsequent potential changes in focus and interface concepts. Many have called for GNOME 3.0, or whatever it is codenamed this week, but for too long it might as well have been called *Project Vaporware*. GUADEC after GUADEC it was discussed, there were many ideas, but no design document, implementation plan or approach. I even talked to Stormy about personally taking some time off and getting some key people in the same room to discuss this. Shortly after those discussions, the hackfest happened (nothing to do with me), and I am tickled pink at the opportunities that have arisen from it.
On this topic, I would like to raise an important question, and one that I would be delighted for the GNOME community to think about, and the wider Free Software community to think about too. Your comments, as always, are welcome.
In recent years we have not only seen a change in focus in how computers are used in people’s daily lives, but we have seen an evolution in community. Years ago, if you wanted to be a part of our community, you really needed to be a hacker. You needed to be able to code in C and know what on earth a memlock or a refcount is. Beards were optional, but generally recommended. As time progressed, out community diversified – documentation writers, artists, advocates, testers and more came on board. One such role that joined our merry bandwagon has been *interaction designers*.
Matthew Paul Thomas, Seth Nickell, Celeste Lyn Paul, Calum Benson, to name a few. Across our community we are developing skills and expertise in how people work with interfaces. I myself have always had a keen interest in this area, but it has largely remained a hobby. Those who commit the majority of their time to this important science have read, refined, explored and questioned the nuances in how we connect human psychology to practical interfaces. This kind of input is *incredibly* valuable. We need to be encouraging these contributors to be involved in the design stages of our interfaces and applications, be contributing perspectives on high-level goals and significant and highly visible areas of the stack such as the gnome-shell, be involved in consistency across applications with style guides and toolkit design, and importantly, be regularly testing and evaluating existing experiences so that we can learn more about where we stand today in an effort to make tomorrow a more usable place. A good example of this is Matthew Paul Thomas’s [Empathy and Pidgin usability evaluation](https://mpt.net.nz/archive/2008/09/07/empathy-pidgin). Those kinds of assessments are superb.
Few would disagree that these contributions are important, but we have not yet figured out how to merge these contributions into the development process. Unfortunately, all to often, these valuable contributions get lost, seemingly ignored and never implemented. The reason for this is twofold.
Firstly, when an upstream developer receives a set of interface recommendations and changes from an interaction designer, for them to be implemented it requires that he or she either (a) agrees with those recommendations or (b) has faith in the designer and their recommendations. I would like to imagine that most upstream developers would be able to put their faith in the abilities of the designer, trust their judgement, and implement designs that they may not be 100% in agreement with. I suspect not though. I suspect that in all too many situations, upstream developers receive good solid designs that they may not really agree with, and despite resounding evidence to suggest the design is a better approach, they choose not to implement them.
This though leads us to the crux of the issue. What we need to fix is how interface design recommendations are communicated and recommended to upstream projects and distributions. In software, if something goes wrong, you can file a bug in a bug tracker. If you need to communicate with an upstream, there is a mailing list. If you need to obtain source code, there is a source repository. Where though is the natural home for communicating interface design ideas, fixes and discussing and debating common problems in existing interfaces? The popularity of bug trackers has been largely due to the structured nature in which the data is stored – they are highly searchable and work well with a developer’s workflow. This has made them more suitable than general communication channels like mailing lists. Bugs appear on mailing lists, but participants almost always recommend the poster to file a bug report.
We need tracker for interaction design fixes and proposals. We need to understand how to structure, communicate, discuss and implement interaction ideas more effectively. I would love some interaction designers to sit down and hammer on this question for a little while. How can we not only structure ideas but also tie them elegantly into actual development? How can we structure and come to a conclusion on an interaction concept and then hook in the implementation of that concept? An ideas forge is not enough – an organised list of never-implemented ideas is not much more useful than a disorganised list of never-implemented ideas. We need to understand how to smooth how the interaction rubber hits the development road.
I think this is an important problem for us to solve, and if we get it right, we could reap the benefits of so many brilliant minds out there whose brains are wired to understand interactions as elegantly as possible. Just imagine what could be possible.
