OK, with that out of the way I just wanted to talk about menus a little. Recently we released Ubuntu 11.10 Beta 1 and there was the requisite review on OMG! Ubuntu! and the conversation in the reader comments rather unsurprisingly descended into a debate about the menus and window controls in Ubuntu 11.10.

Let me explain the source of the debate. Here is a screenshot of Firefox in Ubuntu 11.10:

As you can see there are no windows buttons up there in the top-left corner of the screen and the menus are not visible either. All you can see is the application title. If you hover over the application title the windows buttons and menus appear so you can use them.

Now, I can understand how this has caused some controversy; the screams of armchair usability pundits rattling off concerns of “this is a regression in discoverability of the menu and windows buttons” can be heard in the galleys of that OMG! Ubuntu article. Conceptually I see their point; if the menu is not visible, and it is not in the application window, how do people find it?

This is a misnomer though. Usability and interaction design is all about balancing the effectiveness and discoverability of an interface with the aesthetics of a beautiful, desirable product that we want to use. We don’t just want to build functional technology; we want to build desirable, pleasurable technology that fits into our lives.

If the argument is that we need to expose functionality for it to become discoverable we can do this but such exposed functionality is often not beautiful and desirable. As an example, this is Microsoft Word with all the toolbars switched on

Clearly having everything switched on does not create a beautiful and desirable interface, and I can understand the retort to this would be “sure, Jono, but menus and window controls are a basic and common function in an interface, so we should prioritize their discoverability and visibility“. I am not sure I would agree with this. While they are an important and useful function in Unity, the point I take issue with is that they need to be visible all the time for people to understand where they are and how they function.

My thesis as to why is pretty simple: people learn by exploration. Let’s do a quick exercise. Write down on a piece of paper the last three devices that you purchased. They might televisions, cell phones, kitchen appliances, games consoles, or whatever else. Every one of these devices comes with it’s own interface to operate it. Now, how many of those devices did you sit down and read the instructions for? I am willing to bet it was close to none.

You learned those devices by poking around, trying things out, clicking, pressing, pushing, and otherwise playing with and exploring it. Many of these devices will have had entirely new interfaces to you which you had not used before, yet you figured them out. Some elements of the interfaces will have been obvious (e.g. buttons protruded to indicate that they can be pressed) and some elements less-so.

This is why I think the menu and window controls decision makes sense. People like to explore, and it will take next to no time for Ubuntu users to discover that hovering over the text in the panel will display the menu and the window controls. The same can be said for discovering that if you hit the left side of the screen the Launcher appears. The point here is that when you have discovered that the menu is there, you don’t need it to be visible all the time.

Instead you can hide it and present a far less cluttered interface. Put it this way, let’s look at the two options:

Personally I think the latter looks far sleeker, less cluttered and pleasant to use. Having used Ubuntu 11.10 for a month or so, this small change has really been a nice touch and I am pleased that these small touches continue to refine the Ubuntu experience into a truly desirable and powerful product that is simple and effective for everyone.

A little while back John Lea, a member of the Canonical Design Team filed this bug. The essence of the bug was grounded in one of the check-boxes on one of the pages of the Ubuntu installer:

The third-party software check-box is a useful little feature in which some non-free components can be easily installed at the install time if the user so desires so. The check-box is designed to solve the problem where things don’t work because there is no Open Source solution available.

The bug was proposing that the check-box be ticked by default with the goal of ensuring that the user does not get a broken experience. When I first learned of the bug report this struck me that it had some legal and policy ramifications. In my mind this is not as simple as just changing a default – my take was that if the check-box was ticked by default it would be a definitive change in policy for the Ubuntu project – it would include non-free components by default (even if a user could un-check it to not have this components installed).

I felt my responsibility in this case was to ensure that due process and transparent published governance was used to respond to the bug. As such I asked the Ubuntu Technical Board to provide comment and input. They had their public meeting (meeting log) and voted unanimously of 5-0 against the proposal in the bug report.

So that is the end of that, right?

Well, not really. I don’t want us to dismiss the rationale and ethos behind John’s original proposal in the bug report. John wants to solve the valuable and important problem of users installing Ubuntu and things not working, largely because a closed-source tool was not installed to bring that support in the absence of an Open Source solution. As we move to take Ubuntu to the masses we are going to face various cases in which we can’t offer an Open Source solution or the required quality in that Open Source solution for a given use case. Examples of this include Flash support, MP3 playback, some graphics drivers etc.

While a broken experience will not help us get over the chasm, I am also of the view that we should not sacrifice our values and philosophy; freedom is not a chore that restrains us from delivering a great user experience but a feature that we need to celebrate and encourage.

Thus we face the classic tale of Freedom vs. Functionality in the Open Source community. How do we deliver a great user experience, but one that maintains our commitment to freedom, particularly in those cases where no free solution exists?

I feel uncomfortable saying we need to significantly compromise on either side of the line. We should never compromise in delivering a wonderful user experience that just works, but we should also never compromise in delivering a Free Software Operating System. What’s more, I feel like we haven’t uncovered all of the options available in striking this balance in the installer.

It strikes me that our goal here is for the installer to understand what capabilities can be delivered on the user’s system with Free Software, but to inform the user of their options regarding non-free additions that may offer a better experience. Then the user gets to decide. If they are unwilling to use non-free software, they understand that some things may not work. If they are happy to use non-free elements, they can get that experience without jumping through hoops. All the while this would ensure that we are free by default but non-free functionality would only be a click away if the user chooses so. This way we empower the user.

It is with this that I wanted to present a challenge to our growing design community. I think this topic is a valuable one for us to discuss at our next Ubuntu Developer Summit but thought it could be useful to open the discussion in the community now in preparation for the event. How do you feel we could best solve this? Anyone want to propose some mock-ups or put together a spec?

Recently I kicked off a segment on everyone’s-favorite-un-PC-ramblefest, LUGRadio, in which I expressed concerns that the GNOME project is not deciding on a direction for a next-gen incarnation of the environment, and KDE4 is primed to swoop in and eat its lunch. I am pleased to see the segment kicked off some discussion, and the issue has been raised in the minds of some core GNOME contributors.

While at GUADEC 2006 I sat on the patio of our wooden shack with Mirco Muller at about 3am and we spent quite some time discussing concepts about what a next-gen GNOME could look like. For a while I had been mulling over different concepts and ideas about how GNOME should work, and trying to distill them into core interactions for a desktop. In my mind, before you even think about mocking up a a user interface design, you need to define the modes of interaction; they are like deciding which tools and ingredients you are going to need to bake a cake. If you don’t decide on the tools and ingredients, you cannot effectively move onto the design stage and then the implementation.

The problem with current desktops is that they are largely artificial. We have created modes of interaction that the user has to learn to understand the computer, instead of the computer trying to understand the user. We have to learn where things live, how to move things around, which things can be clicked on and which can’t, how sensitivity and insensitivity works and other false economies. Fundamentally we the users have to fit in with what the computer wants us to do.

The next-gen GNOME needs to change this. It really, really does. What I want to see is an organic environment; one that is designed around human interactions, tasks and concepts that we find natural, intuitive and repeatable. Do you ever have those experiences where you think “it would make sense if it worked this way, I wonder if it does” and to your surprise it does? We need to fill our desktop with these experiences. To do this, we need to understand what interactions and concepts are natural to us as humans, and work on these concepts in GNOME.

So, with time not my friend right now, here is a rough list of some organic concepts that I think we need to bear in mind in our thinking:

• Pile Theory – nope, nothing to do with a nasty dose of the bum grapes, but the idea that we all naturally collect and stack things together into piles. I think this is a fundamental concept in a desktop – collections of things. Think of archives, directories, photo sets, collections of songs, related videos – they are groups of things that we need to access both as a group and as the individual items in that group. You can see this theory in action, look at many people’s desktops and the groups of icons of related bits and pieces – we need to make it easy to great this piles. Imagine a 3D interface to this piles where a bunch of items pile on top of each other and you can explode the pile or fit it together and re-organise it in different ways.
• A Physical Environment – I want to pick up documents that I am editing, spin them round and scribble notes on them, I want them to look like they are shredded when I delete them, I want to stick related things together like lego – I want a physicality to the things that happen on my desktop. A great first step with this was when Compiz put virtual desktops on a cube – it made the concept of multiple desktops more tangible. We need to apply this kind of physicality to all aspects of the desktop.
• Contextual Tools – something I have banged on about with Jokosher. You should only ever see tool options appear when it makes sense and when you can actually use those tools – insensitive greyed out tool options are nothing more than a distraction and a waste of space. In Jokosher, when you make a selection, the tools that can be used on that selection appear, we need to apply this concept to the entire desktop. This makes the desktop feel more organic in itself as the tools will only ever appear applicable to your context. It also makes the desktop far less cluttered and gets away from the nightmare of modal tools. We particularly want to get away from the hundreds of toolbar options available that clutter our applications. For all people have heralded the Ribbon as a great idea in Microsoft Office, I am pretty convinced that it may over-egg the pudding and confuse people with so many functional options available. We fundamentally need our desktop to be contextual – more on this later.
• Two Handed Interaction – some of the work with multiple mouse pointers makes this possible. For some applications this makes perfect sense. Think of a 3D modeller such as Blender – the most natural modelling process is sculpting using your hands, and this requires two hands. Think about putting things in other things – it makes sense to hold the container open to put the things in it (like when you put items in a carrier bag). Naturally there is a hardware implication for this which will delay its adoption.
• Real Contextual Working – a while back I wrote up my thoughts for a project desktop. We need our applications to be aware of what the user wants to do and ensure they are organic enough to evolve into a form that is condusive to that task.

With the growth in 3D technology, we have the opportunity to make all of this happen. This is just a collection of rough notes, but at GUADEC I hope to flesh some of these ideas out with other people. We need to break down the barriers to interaction, but also be brave enough to stand up and set a direction, which was the point of the segment. If I had my own way, I would love to blow off a week and spend all week designing a bunch of mock-ups. I have a fairly clear idea in my head how this kind of stuff would work, inspired from various interfaces and concepts, but I just don’t have the time to mock it up.

Go and download it.

So, I got up and discussed my views on usability, good design and making better applications. There was some interesting banter with the other folks in the room, and I think the (completely unprepared, unexpected) session raised some interesting issues that would be of use for most application authors.

As with the rest of LCA, this was videoed for your online viewing kicks, so go and download the video – my bit kicks in at around 12 minutes.

Dialog design is essential here. God gave you eyes and Carl Worth gave you Cairo for a reason, so lets set them on fire and make our applications look the bomb. As Laszlo blogged about, I added some header images to the effects dialog boxes when I was hacking on the code; this was to make the dialogs look consistent (by using the orange Jokosher theme) and attractive. One of the problems was with kind of approach was translating the text I put in the images – the text was part of a bitmap. This is a big problem now Jokosher is feeling the i18n love. To fix this, Laszlo recently replaced the images with a Cairo equivalent. As such, now we have good looking dialog boxes that translate well.

Traditionally, form and function have divided people into two approximate camps, one accused of being orange-sunglasses-wearing-hippy-web-two-point-zero-idolising-feckless-morons and the other described as over-technical-geeky-binary-lovers-with-no-mates. Why do we even need to make a choice? Why can’t we feel the love of powerful software…with rounded edges and shiny dialog boxes?

As our desktop moves into a new era, one driven by windows that wobble, software that gets ever more advanced and users that demand attractiveness and ability, we have so much opportunity. Hey, its not as if we don’t have an incredible platform to do this. Using Cairo as one such example, we have such an awesome ability to use this important component in our desktop to re-shape how we look at software. When I was hacking on the effects dialogs, sure, I could have made my life easier if I just used a plain old push-button for each effect, but I really wanted the dialog to have some life and have some character. There are of course usability concerns here too – in a future version of Jokosher I would like to replace the effects listed in the dialog box with images that look like a physical effects unit such as a stomp box. Cairo gives us the ability to break away from the Gtk mold and explore better ways of representing concepts on the desktop, and better ways to deliver attractive interfaces. Feel the power!

Of course, with power also comes responsibility, and like many of you folks, I never want to see our desktop turn into the invent-your-own-interface-and-toolkit bonanza that is going on in the Windows world. Here we want consistency of toolkit and HIG, but scope to develop new constructs and ideas where it makes sense. When I look at the GNOME desktop, I always feel like there is an opportunity for someone to wave a paintbrush over it to spruce it up. Lets see some of that action going on.

My talk seemed to go pretty well, and caused some interesting questions and discussion afterwards. Shortly after the talk I did an interview for a podcast which was fun, and then there was an interesting talk by danimo about KDE 4. Danimo’s talk was informative, but the post talk Q+A was even more interesting, and there was some really good discussion.

Its nice to feel the sense of community here, and I have had some great feedback about Canonical, Kubuntu, community management, concerns, expectations and other issues. It has also been nice to hook up with Matthias Ettrich again and also to meet Knut, Torsten Rahn (coolest name evaaar), Klaus Knopper and Martin Konold.

So all in all, a pretty good event so far, and it has filled my already full head with yet more ideas and thoughts.

Oh, and I entered a raffle for a Trolltech Qtopia Greenphone – I really hope I win. I would love one of those beauties.

Although Chris’s post was interesting, one of the comments brought up what I consider the main issue:

The biggest problem with ALSA is that configuring it is beyond any mere mortal. If your stuff doesn’t work out-of-the-box with ALSA, you have zero chance of getting it working yourself. Just try to get the optical output on that nforce4 to work and you’ll see.

Exactly. But, this is not just a problem with ALSA, it is a problem with the presentation of audio in our desktop. My question is – how much of this can we fix at the desktop level? Is there a way we can develop some sane defaults for most users, and at least make a GUI interface to sound that is simple? If you take a card such as the Delta 44 or M-Audio 1010, the configuration gets devilishly difficult due to the number of available inputs/outputs, different types of mixing etc. Even users of these high-end cards should not need to care about this kind of stuff.

I think we have a really strong multimedia stack, and GStreamer is making leaps and bounds in features and stability, but we need to nail that all important middle-ground between application-level multimedia playback and the physical sound card, and this seems to be an area that needs fixing in GNOME. This is incredibly important for Jokosher – we have gone out of our way to make audio production in it as usability and ease-of-use focussed as possible, but the whole user experience falls down if sound card configuration requires a degree in rocket science to use.

So, I ask you all – how much of this is fixable in the desktop, and if not, how much needs to be fixable at the ALSA or kernel layer? Also, how can HAL and FDI files help solve this problem?

Feature development

Human beings are great at making comparisons, that’s what we do. Utterances of “my car is better than yours”, “so, why is this microwave £30 more expensive than that one”, and “well, she/he is nice, but not as nice as xyz” can be heard across the land. Of course, we are no different when evaluating software. As such, comparisons have been made from day one about Linux vs. Windows, the GIMP vs. Photoshop, Ardour vs. Cubase, Firefox vs. IE, Outlook vs. Evolution etc. In the short term, we can indeed draw such conclusions. If application A does something that application B does not, it is fair to judge application A as being the superior product, right? Well, it is not that simple.

First of all, the IT industry is ridden with ‘feature insanity’. I alluded to this, particularly in an educational context in my Unwrapping Learning Potential With Open Source post. This phenomenon manifests in the innate process of comparing two things on a blow by blow feature chart, as opposed to actually identifying if the tool can do what you need it to do. This is particularly prevalent with OpenOffice.org – many, many people can be productive and do what they need to do in OpenOffice.org, but they instead demand that it matches every feature in the latest version of Microsoft Office. So, the first rule is to actually identify which features you need, and in many cases Open Source software is fine and dandy.

The second issue is to analyse the problem with a longer term approach and look at the history of Open Source. Let me outline this with my mad Inkscape skillz:

The diagram looks at the development of the Windows and Linux desktop. Back in the early days, a usable desktop in the Windows world was something such as Windows 3.0 or 3.1. Below the Windows box you can the Linux box is further to the right. The equivalent functionality to Windows 3.0 or 3.1 didn’t come to the Linux desktop until some years later. As such, the Linux desktop was immediately playing catch-up due to its later start. Microsoft had already got in there and started building their product, with plenty of developers and money behind it. How could the desktop compete?

If you now look at the right side of the diagram, you can see that the Windows and Linux desktops are fairly level. If you compare Windows XP to Ubuntu Dapper, SuSE Linux Enterprise Desktop or Fedora Core 5, they are fairly comparable. Sure, there are certain chunks missing, particularly in vertical markets, but people are today making real-world comparisons and considering the desktop in their organisations and homes.

From this we can identify that the Linux desktop is developing a lot quicker than the competition. This proves that the Open Source development process is working, and is working at a higher rate. This does not necessarily mean we are better optimised (100,000 monkeys picking tea are quicker than 10 high-speed tea-picking humans), but it does mean we are developing quicker, and piling in the features and unique selling points.

Marketing

In this months PC Pro, Tim Danton stated that “open-source will never pose a threat to Microsoft”. His argument basically boils down to the fact that Open Source software websites are not as good as the competition – he says that many Open Source project sites consist of just plain text and links. This is clearly an issue about Marketing.

To be honest, sure, there are some pretty dog-awful websites that push Open Source projects out there, and many do indeed consist of boring black text on a white background and a few blue links. But, I would say this is rare for major Open Source projects, and is mainly the case for niche applications, and the same limitations in fascia can be applied to niche software on any platform.

Since my entry to the Open Source community, I have seen developers evolve. Back in the early days, developers were largely code heads who cared for nothing but code. Many of these developers wrote awesome code, but produced terrible websites, ugly interfaces and terse documentation. As Open Source developed and become a serious and credible platform, developers have evolved into code heads with an experience and respect for project management, release schedules, usability, documentation and marketing. Take a look at any of the major Open Source projects and you can see well organised development teams with contributors who help in many different areas such as documentation, art, websites, coding and marketing. This is evolution doing its thing, and the average Open Source developer maintains a remarkably diverse range of skills and appreciation of these different areas. Open Source development process and practice basically grew up as the platform grew.

We have a strong, diverse and fast developing platform, and the really exciting time is as we surpass the competition in the many different areas. This is not a one horse game – we may steam ahead in web browser technology, but we may lag in CAD software. But, as Open Source grows and the platform grows, each of these areas look more and more promising every day. We just need to look at our history to understand our future.

While at GUADEC I sat down for a while with MacSlow, and he gave me a demo of Lowfat. For quite some time I have had some vague ideas for the approximate direction of GNOME 3.0, and some of Mirco’s work triggered some of these latent concepts and mental scribblings. I am still not 100% sure where I would like to see GNOME 3.0 go, but some of the fundamental concepts are solidifying, and with my recent addition to the mighty Planet GNOME, I figured I should share some ideas and hopefully cause some useful discussion. I am going to wander through a few different concepts and discuss how we should make use of them in GNOME 3.0, culminating in some ideas and food for thought.

A more organic desktop

One of the problems with the current GNOME is that it largely ignores true spatial interaction. Sure, we have spatial nautilus (which is switched off in many distros), but spatial interaction goes much further. If you look at many desktop users across all platforms, the actual desktop itself serves as a ground for immediate thinking and ad-hoc planning in many different ways:

• Immediate Document Handling – the desktop acts as an initial ground for dealing with documents. Items are downloaded to the desktop and poked at before entering more important parts of the computer such as the all-important organised filesystem.
• Grouping – users use the desktop to group related things together. This is pure and simple pile theory. The idea is that people naturally group related things together into piles. Look at your desk right now – I bet you have things grouped together in related piles and collections. We don’t maximise this natural human construct on our desktop. More on this later.
• Deferred Choices – the desktop serves as a means to defer choices. This is when the user does not want to immediately tend to a task or needs to attend to the task later. An example of this is if you need to remember to take a DVD to work the next day – you typically leave it next to the front door or with your car keys. The analogy with the current desktop is that you would set an alarm in a special reminder tool. More people set ad-hoc reminders than alarms.
• Midstream Changes – it is common for users to begin doing a task, and then get distracted or start doing something else. An example of this is if you start making a website. You may make the initial design, and then need to create graphics and get distracted playing with different things in Inkscape. The desktop often acts as a midstream dumping ground for these things. Work in progress in documents are often placed on the desktop, and this acts as a reminder to pick it up later (see deferred choices earlier).

It is evident that the desktop is an area that provides a lot of utility, and this utility maps to organic human interaction – collecting things together, making piles, creating collections, setting informal reminders, grouping related things. These are all operations on things, and are the same kind of operations we do in our normal lives.

Part of the problem with our current desktop is that there is a dividing line between things on the desktop and things elsewhere. It is a mixed maze of meta-data, and inter-connected entities that should be part of the desktop itself. As an example, when I was writing my book, I created word processor documents, kept notes about the book in TomBoy, saved bookmarks in Firefox and kept communications in GMail and Gaim. The singular effort of writing a book involved each of these disparate unconnected resources storing different elements of my project. I would instead like to see these things much more integrated into (a) contextual projects, and (b) manageable at a desktop level. More on contextual projects later.

Blurring the line between files, functions and applications

The problem we have right now is that the desktop is just not as integrated as it could be. If you want to manage files, you do it in a file manager, if you want to do something with those files you do it in an application, if you want to collect together files into a unit, you use an archive manager. Much of this can be done on the desktop itself, but we need to identify use cases and approach the problem from a document-type level.

Let me give you an example. A common type of media are pictures, photographs and other images. The different things you may want to do with those images include:

• Open them
• Edit them
• Compare them
• Collect them together by some form of relevance (such as photos from a trip, or pictures of mum and dad)
• Search for them

These tasks involve a combination of file management, photo editing applications, photo viewing applications and desktop search. Imagine this use case instead:

I want to look through my photos. To do this I jump to the ‘photo collection’ part of my desktop (no directories) and my collection has different piles of photos. I can then double-click on a pile and open up in front of me. Each photo can be picked up and moved around in a physically similar way to a normal desk (this is inspired from MacSlow’s LowFat). I can also spin photos over and write notes and details on the back of them. Using my photos I can put two side by side and increase the size to compare them, or select a number of photos and make them into a pile. This pile can then be transported around as a unit, and maybe flicked through like a photo album. All of this functionality is occurring at the desktop level – I never double-click a photo to load it into a photo viewer, I just make the photo bigger to look at it. All of the manipulation and addition of meta-data (by writing on the back of the photo) is within the realm of real world object manipulation, and obeying pile theory and spatial orientation.

The point here is that the objects on the desktop (which are currently thought of as icons in today’s desktop) are actual real world objects that can be interacted with in a way that is relevant to their type. In the above use case you can make the items bigger to view them, compare them side by side, and scribble notes on them. These are unique to certain documents and not others. You would not zoom, compare and scribble notes on audio for example, but you would certainly use pile theory on audio to collect related audio together (such as albums).

Applications

So, if we are trying to keep interaction with objects at the desktop level, how exactly do we edit them and create new content? How do today’s applications fit into this picture? Well, let me explain…

The problem with many applications is that they provide an unorganised collections of modal tools that are not related to context in any way. I have been thinking about this a lot recently with regards to Jokosher, and this was discussed in my talk at GUADEC. Take for example, Steinberg’s Cubase:

In Cubase, if you want to perform an operation, you need to enable a tool, perform the operation, disable the tool and then do something else. There is a lot of tool switching going on, and toolbar icons are always displayed, often in situations when that tool can either not be used or just would not make sense to be used. The problem is that it obeys the philosophy of always show lots of tools onscreen as it makes the app look more professional. Sure, it may look professional, but it has a detrimental impact on usability.

I believe that tools should only ever be displayed when pertinent to the context. As an example, in Jokosher we have a bunch of waveforms:

The first point here is that we don’t display the typical waveforms you see in other applications. Waveforms are usually used to indicate the level in a piece of audio, and as such, we figured that musicians just want to see essentially a line graph, instead of the spiky waveform in most applications. This immediately cuts down the amount of irrelevant information on screen. Now, if you select a portion of the wave in Jokosher, a tray drops down:

(well, at the moment, it drops down, but does not visually look like a tray, so run with me on this for a bit!)

Inside this tray are buttons for tools that are relevant to that specific selection. Here we are only ever displaying the tools that are pertinent to the context, and this has a few different benefits:

• We don’t bombard our users with endless toolbars
• Tools are always contextual, which makes the interface more discoverable and intuitive
• We restrict the potential of error by restricting the number of tools available for a given context
• There are fewer buttons to accidentally click on, and this lowers the hamfistability of our desktop

Now, take this theory of contextual tools, and apply it at the desktop level. Using our example from earlier with photos, I would like to see contextual tools appear when you view a photo at a particular size. So, as an example, if I have my collection of photos and I increase the size of a photo to look at it, I would like to see some context toolbars float up when I hover my mouse over the photo to allow me to make selections. When I have made a selection I should then see more tools appear. There are two important points here:

• Firstly, you don’t load the photo into an application. As you view the photo at the desktop level, the functionality associated with an editing application seamlessly appears as contextual tools. This banishes the concept of applications. Instead, you deal with things, and interact with those things immediately.
• Secondly, tools are always contextual, and relevant to the media type. For a photo and a document, selections make sense, for an audio file, you should be able to apply effects and adjust the volume, for a text editor you should be able to change font properties. Everything is relevant to the context.

The contextual desktop at a project level

To really make the project feel contextual, we need to be able to make it sensitive to projects and tasks. At the moment, tasks and sub-tasks are dealt with on a per-task basis as opposed to being part of a bigger, grander picture. Let me give you a use case with today’s desktop:

I am working on a project with a client to build a website for him. I decide I want to send some emails to him, so I fire up my email client and dig through my inbox to find the mail he sent me yesterday. I then reply to him. As I work, I realise that I need to speak to him urgently, so I log on to IM. Within my buddy list I see that he is there, so I have a chat with him. While chatting, my friend pops up to discuss the most recent Overkill album. As I am working, I don’t really want to talk about the album right now, so I either ignore him or make my excuses. After finishing the discussion with the client, I load up Firefox and hunt through my bookmarks to find a relevant page and start merging the content into the customers site. To do this I load up Bluefish and look through the filesystem to find my work files and begin the job.

The problem here is that the relevant work is buried deep in other irrelevant items. To make matters worse, some resources such as IM can just prove too distracting, and may never get used (remember midstream changes earlier). As such, the really valuable medium of IM is never used for fear of distraction. Now imagine the use case as this:

I am working on a project with a client to build a website for him. I find my collection of projects and enable it, and my entire desktop switches context to that specific project. Irrelevant applications such as games are hidden, and relevant resources are prioritised. When I communicate with the client, only emails and buddies relevant to that project are displayed. When I want to find resources (such as documents) to work on, only those documents that are part of the project are displayed. The entire desktop switches to become aligned to my current working project. This makes me less distracted, more focused and there is less clutter to trip over.

I actually had this idea a while back, and wrote an article describing it in more detail. Feel free to have a read of it.

Conclusion

The point of this blog post is not to sell you these concepts, but to identify some better ways of working which are more intuitive and more discoverable. Importantly, we need to make our desktop feel familiar. This was a point Jef Raskin made as part of his work, and I agree. Some people have been proposing some pretty wacky ideas for GNOME 3.0, but grandiose UI statements mean nothing unless they feel familiar and intuitive. What I am proposing is an implementation of real world context, relevance and physics into our desktop. This will make it more intuitive, less cluttered, less distracting and a better user experience.

I really want to encourage some genuine discussion around this, so feel free to add comments to this blog post, or reply via Planet GNOME. Have fun!