jonobacon@home

Archive for November 25th, 2008


Posted on November 25, 2008 - by jono

Ubuntu Free Culture Showcase II: This Time Its Personal

DIGG!!

I am epically excited to announce our second Ubuntu Free Culture Showcase this time for the Ubuntu 9.04 Jaunty Jackalope release!

The Ubuntu Free Culture Showcase is an opportunity to bring the best of two great worlds together by showing off high quality Free Culture content in Ubuntu. At the heart of Ubuntu’s ethos is a belief in showcasing Free Software and Free Culture, and with each development cycle we present the opportunity for any Free Culture artist to put their work in front of millions of Ubuntu users around the world. Although the space restrictions are tight, and we are limited to how much content we can include, the Ubuntu Free Culture Showcase is an excellent opportunity for artists everywhere.

The winning submissions will be made available on the shipped CDs and download images of the Ubuntu 9.04 release. Every user will be able to find the content in the Examples/ folder in a home directory.

With this competition we are now not only accepting submissions for audio and video, but also graphic/photo submissions. This opens up the competition to all of you budding photographers and artists. We have a winner to find for each category, and the competition closes on 6th February 2009.

Entering the showcase is simple:

  • Your submission must be one of the following:
    • Audio Entries – no larger than 1MB in size – made available in Ogg Vorbis format.
    • Video Entries – no larger than 2.5MB in size – made available in Ogg Theora format.
    • Photo/Graphic Entries – no larger than 0.5MB in size – made available in PNG or JPG formats.
  • All entries must be licensed and distributable under the Creative Commons Attribution ShareAlike license.
  • Upload your submission somewhere online (there are lots of free hosting solutions available such as archive.org). Do not email any of the organisers or judges with your submissions.
  • Add your entry to one of the submission tables at http://wiki.ubuntu.com/UbuntuFreeCultureShowcase.
  • When the deadline for submissions closes, our panel of judges will pick a shortlist, and the Community Council will then pick the final winners from the shortlist.

The deadline is 6th February 2009 and you can read more about it at http://wiki.ubuntu.com/UbuntuFreeCultureShowcase


Posted on November 25, 2008 - by jono

Desktop Shells, Usability and Trackers. Oh My.

A while back, I read with great interest Vincent’s blog entry. 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 I may have actually drooled. Instead of grabbing a tissue, I instead grabbed jhbuild and built said shell. Instructions for the brave are here. 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. 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.