Let’s face it

Maintaining web pages is a drag. Every project lead knows it’s been on the task list for ages, with not quite enough priority to get time. It isn’t usually fun, straightforward, or easily delegated. In general, the farther a thing is from where we spend time the less likely it is to get our attention. And we spend our time in the code, on the designs, in bug lists, and in front of the thing itself. That’s the face we see.

But it is quite different from the face everyone else sees.

They see the product. And the impressions or expectations of this product are as important as the actuality of the project that produces it. Things work best when these perceptions are in sync — or at least aren’t out of whack.

So, before someone even has a chance to try your thing of beauty, what face do they see?

Chances are a search engine or link sent them to one of the following:


projects.gnome.org screenshotThe projects index is out of date and incomplete. Which is understandable since it isn’t dynamically generated and no one maintains it. In order to update it, you need special access to push changes to the large (700 MB) and complicated gnomeweb-wml git module. A bad combination of properties.

The site itself is using an old design template that hasn’t been used on other gnome.org sites for many years. There is a strange blank space on the right side where some sidebar probably was supposed to go. Until recently, it even had some broken links too.

The index is a confusing mix of applications that have a user face and components that do not.

The list is incomplete because most recent projects have home pages on the wiki. Some projects have similar home pages on both the projects site and the wiki. Some projects consider the wiki the canonical home page and some consider the projects page canonical. Clearly, having a consistent story would be better.

So that’s just for the index page. The situation for each project site is even worse since they are all expected to have their own site templates. Which means that unless the project maintainer is really on top of things or has a designer on staff, the design falls really out of sync. This is sort of fun as a way to walk through the visual history of GNOME but isn’t a very nice face to present to the world.


Old wiki design

Old wiki design

Like projects.gnome.org, the site template was out of date and really needed an update. Also like projects.gnome.org, so much of the information on the wiki was out of date or obsolete. And the lack of any kind of structure made that information hard to find.

However, the wiki is much easier to edit and get casual contributions and fixes. It is active and the place where most groups actively contribute and coordinate efforts. The wiki is information rich and deep with historical knowledge. It is here to stay.


git.gnome.org screenshotThe “All Projects” index on git.gnome.org isn’t really intended to be a user facing project listing. It could be better but it isn’t the face we are hoping to show this new user of yours. Fortunately, the site design template is already up to date and seems to be working pretty well.

Future work here may involve doing more with the data we have in each project’s DOAP file.

So which one do we want them to see?

To figure this out we asked the stakeholders. The sysadmin team strongly prefers consolidation on the wiki. We know we have to keep that going. And it doesn’t require editing an esoteric module in git and running site-update jobs in the background. The design and web teams prefer not having to keep two disparate site styles updated and in sync. The project maintainers almost unanimously (except two) preferred editing a wiki to editing a gnomeweb-wml in git. And loved the ability to more easily delegate trivial site maintenance and updates to anyone with a wiki account.

The plan

So the answer was pretty clear. We would:

And where are we with that?

New wiki designAfter a couple months of really tedious work I’m happy to say this is pretty much done! With only a few details remaining:

  • gnumeric hasn’t been migrated because we need to finish porting the docs over.
  • We still have another iteration to do on the design of the wiki.

I’d really like to thanks Andrea Veri for all his work on this. As well as everyone else who has been helping for many weeks now.

Can I help?

Yes, please. Here are some ideas:

  1. The best thing you can do is to become familiar with the guidelines for the wiki and make sure new pages are put in expected locations. It would be great if we could, as my mom used to say, “keep up, don’t catch up.”
  2. Help correct relative page links when linking to a sub-page. For example, if you have a page called “Apps/FooBar/Screenshots” a link to it from “Apps/FooBar” should look like “[[/Screenshots|Screenshots]]”.
  3. Help us find and fix any broken links. We tried our best to prevent it when possible and correct them whenever they were noticed but hey – it isn’t easy.
  4. Update your App or Project page to follow the application template and project template, respectively.
  5. Volunteer to do something interesting with DOAP files on git.gnome.org – maybe similar to http://projects.apache.org/references.html
  6. Help ensure Andrea Veri’s contract is renewed and stays on as the GNOME sysadmin!

And lastly, keep making GNOME great — inside and out.

Happy holidays!

Posted in Uncategorized | Tagged , , , | Comments Off on Let’s face it

Cross Cut

We, as a community, have been making significant improvements to the GNOME 3 experience over the past couple years. With the new shell and new core applications we’ve been working hard to provide you with immediately useful defaults, more powerful ways to find your stuff, simpler and more natural workflows using direct manipulation, universal access, and a more coherent, effective, and beautiful experience.

Unfortunately, our favorite file organizer and manager has been a bit left behind. So, lately, a few of us have been trying to give Nautilus some much needed love, to bring it up to speed.

There are number of fairly high level objectives in this effort. I’ll attempt to describe a few of them. We want to…

Be Immediately Useful

The initial view of the application should present me with things I can take immediate action on. Things that are likely relevant to what I am doing or what I have been doing recently. Something that serves a reminding function for things that I have yet to do. Something that helps me establish context. Something that doesn’t require me to do additional work or navigation every single time it starts.

One way to achieve this is by displaying a list of recently created, modified, or used files.

This is what we have, now, in git master and it feels pretty nice. Though we’ll continue to refine and improve.


Have a Functional Search

We don’t even need to get fancy. Even a barely functional search would be a huge improvement. If you haven’t noticed, search was completely broken. You either had Tracker search support or you didn’t. If you compiled Nautilus with Tracker support then we would only show you results from the small subset of your files that Tracker was configured to index. If you tried to search a removable USB drive you would see nada search results. If you happened to turn Tracker off we would happily display nothing at all. If you did not compile with Tracker support we would do something amazing like crawl your entire filesystem looking for a filename match every time you updated the search terms, and nothing would be displayed until it was done – something on the order of “a long time.” Remember when I mentioned Nautilus was left behind? Not kidding.

So, yeah, who needs to search in a file manager anyway, right? Um.

Turns out quite a few of you do. And a good number of you want to be able to find your files from the GNOME 3 Activities Overview as well. And this requires there be an application providing those results. Which app should do that?

That’s actually a good question. I think ideally we’d have a number of more specialized applications providing the search results (and viewing experience) for the types of files they handle natively. New applications like Documents, and Photos, and Music. However, something should be providing the fallback for when these applications do not exist or until they exist. I think this application should be the one where you find your files.

So when you think about adding working search to Nautilus you really want to use the emerging GNOME 3 design pattern for search. Something that has been discussed quite a lot recently. Including most recently at the UX Hackfest last week.

This implies a few things. That searching be: fast, performed as you type, have results ordered by relevance, quickly converge on what you want, and allow quick activation of the top hit. This should hopefully reduce or obviate the need for scrolling, intensive visual scanning, unnecessary navigation. Allowing you to quickly grasp what you want and maintain your focus on your ultimate goal rather than a series of intermediate and tedious tasks. A better time.


Have Simpler and More Natural Workflows

In GNOME 3 we’ve been trying to allow you to work with, manipulate, or act on content directly. Actions that make sense in the situation you happen to be in. Contextual and relevant to the environment. Rather than require you to proactively create the conditions needed for an action, we allow you to select or identify the things you are interested in and then say what you want them to do. For example, I have a set of files I would like to collect, organize to be together. How does that work? Previously, in Nautilus I could identify where I would like this prospective collection to live, perform the action create a New Folder, then go look for content to fill it. What is wrong with that? In some situations that works just fine, especially if you are a “frequent filer.” But it could go wrong. In the case where I had already identified the things I wanted to organize I am forced to leave them, take on an intermediate task in order to set up preconditions for the primary task. What if I am interrupted during this intermediate task? What if I change my mind? Shouldn’t all this stuff just be done for me?

One way we can do better is not rely on our ability to predict the future. We are pretty awful at it most of the time. Exhibit A: How good did we think Prometheus was going to be?

Can we do better? Fortunately, yes. And not just better but faster and more reliably. It is better to do defer decision making and action. Identify the stuff and then select what you want to do with it. So, back to our example where I have a set of files I want to collect or associate. I think it is better to add a new action for the selection that allows me to create a New Folder with Selection. Boom. Done.

New Folder From Selection

Hold on mister. I’m not done. I wanted to put that new folder somewhere else!

Righto. Got you covered. Let’s add a new action on that Folder called Move To and ask you to just pick where you want it to go. How would that be? I think I heard you said “straightforward, quick, and powerful.” Cool, because all that is in git master. Check it out.

Move To

A couple of you just said, “but I wanted to email it not move it!” Ok yeah good point. That is going to require some fixes to the Send To functionality and it is on the roadmap.

Be More Coherent

You may have noticed that the file selection dialog in the example above isn’t very consistent with the patterns used in Nautilus. Good catch. Turns out this has been confusing the heck out of our users for years. The problem seems really obvious once you see the two together. Fortunately we have plans to fix it and make it easier and better for everyone.

Nautilus was a bit of black sheep among the GNOME 3 core applications. It had a design that grew organically over many years and didn’t really seem to fit in any more. In bringing it back up to par we now have things like a much improved and space efficient maximized window state, a more consistent menu layout and behavior, more consistent use of icons, and a more GNOME 3 style pathbar and toolbar.

Be More Effective

We’ve heard the complaints loud and clear. They’ve been ringing out on the mailing lists and piling up in bugzilla. We’ve gotten a little bloated a little too lax in tending the way our application operates by default. The context menus were running out of control and finding the option I wanted was too hard. The list view of files was crowded and noisy and hard to focus on the most important part: the filename. The default icon view started with a small icon, had a very inefficient layout for large icons, and generally sucked at browsing for content. We worked around this in various ways but we should really do better by default. This is work in progress with much more to do but we’re on the way.

Be More Beautiful

Every detail matters. We want every corner of GNOME to be delightful and well cared for. The little things. Like how the calm stability of the sidebar reassures and anchors me. Or how the way automatically updating the name of my computer in the sidebar, when it changes, delights me. Or the way the application allows me to focus on my goal shows me respect. This is what we want.

So how do we get there?

Trading Spaces

Sometimes is just not possible to add new functionality without first making some room. This doesn’t always mean you need to remove something. Nor does it always mean you should remove something. But sometimes you will. This is never done lightly. For Nautilus we spent a long time trying to figure out what is the minimum we’d need to do in order to accomplish the objectives discussed above. It is a very difficult trade off.

But in the end we decided that the responsible thing to do, in order to maintain the high quality of the user experience and the high quality of the code, was to remove a few things.

Extra Pane

This was removed for a couple of reasons. The first reason was that it was undiscoverable. Not all undiscoverable interfaces are bad but this one also stood in the way of providing a better alternative. Even if you never used the Extra Pane you always had useless Move To and Copy To items in the menus. We wanted to create a better Move and Copy workflow and really these items had to go. Once you remove all user facing ways to use the feature you have to ask yourself (as a good maintainer) whether the trade is worth it. Should we keep the feature for which we have a new and better alternative in Nautilus, a very similar and easily enhanced feature available in the Shell side by side view, and a pile of bugs getting no attention in bugzilla? We decided it was better for the project to remove it. This hasn’t pleased everyone but remember we still have some ways to go to make the experience complete.

Compact View

This is a tricky one. A lot of reasons people have been using this view are due to the other two views sucking for various reasons. We want to fix the root problems. We intend to have more effective list views for identifying files by name, more effective grid or icon views for finding files by content, and more effective search for finding anything based on name, textual content, or metadata regardless of where it is. This is consistent with the other core GNOME 3 applications. Working around the default isn’t going to do it.

The role for compact view is unclear. Our research suggests that it is something like: the only view that works for browsing a lot of files at once. This is really hard to reconcile with providing good defaults that just work and having consistency with the file chooser.

The view itself was not without problems and we would rather focus on making icon and list rock. I won’t dwell on the reasons here since they have been discussed at length already.

It was in the way of a better solution.

Type Ahead Find

One of our primary objectives was to add powerful search that is available by just typing. This is a great feature that has been demonstrated to be highly effective and loved by users. Unfortunately, this is in direct conflict with so called Type Ahead Find. What to do? Which is better? Tough call. We think we can serve all the existing use cases of type ahead find and more with our new found search capability. Is it perfect? No. Type ahead find was not without serious problems either. Even after many many years of efforts to improve it.

Problems like how difficult it is to continually scan all the items in the view and yet follow the selected item as it suddenly jumps to new items, or the requirement that you know the exact case sensitive prefix of the file or folder you are looking for, tricky popup search entry placement that covers the floating status bar or data in the item view, unfortunately interactions with the GNOME message tray, strange iteraction with other windows, awkward interactions with scrolling views. etc.

So, What’s Next?

Obviously there is still much more work to do here. As you can see from the Nautilus 3.6 roadmap. We have a ton of new features that I didn’t have time to cover here. This is going to be awesome and, here’s the good news…

You Can Help!

So pitch in. Patches to any of the roadmap item bugs would be greatly appreciated. Don’t hesitate to ask for help on the nautilus mailing list, or on IRC in or -design. Meet you there!

Posted in Uncategorized | Tagged , , , , | 47 Comments

We Deliver

As you know, in GNOME, we’re committed to bringing you the easiest, most beautiful, and most advanced operating system in the world today. A major part of this effort, now, is to build a suite of amazing core applications that provide the operating system key or essential features. Today, I’d like to talk about our goals for one of these apps. It is just the earliest stages but here’s a taste of where we’d like to go.

I’m pleased to introduce you to…

“Absolutely, Positively Anytime”

Boxes is designed to be the easiest way to use or connect to applications running on another Windows, Mac, or Linux system. Whether the system is virtual and local, a home computer you need to access from the road, or a centrally hosted corporate login — we’ll get you there.

We’re taking a different approach. We’re focusing on you. Your stuff. Your work. Your time. Leave it to us to worry about whether the system is local or remote and keep your mind on your task. The user experience is streamlined to keep you focused on your content. Anytime, anywhere.

What can Boxes do for you?

If you are reading this post you are very likely a GNOME contributor in some way. So, that’s where I’ll begin.

If you are involved in designing, developing, translating, documenting, testing or any of many other crucial activities responsible for producing the next kick-ass version of GNOME you need to be working with the supple green and tender new growth. And here’s the thing about the supple tip; it ain’t always good for standing. We want GNOME to have built-in support for bridging this gap. It needs to be dead easy for us to participate in the future of GNOME. Running the latest git master in a Boxes virtual machine is a great way to do this. We want to invite a new generation of readers to become leaders.

Perhaps you are an application designer or developer. We want to make it simple as pie for you to try out the competition on other systems. We know you can do it best.

Perhaps you are a web developer and need to ensure your site renders correctly on a variety of platforms. Or occasionally need to use that ugly proprietary program your client makes you use. Don’t spend money and effort on keeping separate systems running. Run them all in Boxes.

Are you a system administrator with that one last expensive, stodgy, and hard to update proprietary app blocking your migration to free software? Box it up.

Are you excited to finally try out GNOME and experience the best of open source but worried about leaving your old familiar system behind? Take it with you. And use it anytime, anywhere…

Without the fuss.

“When you absolutely, positively, got to kill every motherf***** in the room”

We don’t aim to do it better. We aim to do it best. With the power of Linux KVM based virtualization, the efficiency of the SPICE protocol, and the elegance and ease of use of GNOME — accept no substitutes.

So, let’s get started. Check out the design whiteboard. Zeeshan will fill you in on some details and give a brief demonstration. Be sure to ask how you can help!

Posted in Uncategorized | Tagged , , | 15 Comments

New Pony

For a long time I was of the opinion that the problem with file management was the management. And the problem with file systems was the system. If only we could design a better management system we’d be all set. I think that turns out to be wrong. We didn’t need a better horse. We needed a new vehicle.

Everything is a file (until it is better).

This poses quite a dilemma for the design of Finding and Reminding in GNOME 3. So it is worth spending a bit of time investigating.

First, let’s limit the scope to the type of stuff we use files for today. For most people this is basically: Documents, Music, Pictures, Videos, and Downloads.

Documents are a bit hard to define. I guess in the “Places” scheme it more or less meant anything that isn’t Music, Pictures, Videos, or Downloads. An accepted definition seems to be something like: page-based information or evidence usually created by an application. Which probably means that most web pages aren’t documents until saved as PDF or something. This seems pretty close to how we use it.

Clearly, documents have been files. Even Merriam-Webster includes the term file in the definition. But are they always files and will they continue to be? Since quite often Documents are just a shorthand for Office Documents let’s look at what is happening there. Will such documents continue to live solely as files on your computer hard drive and be shared as email attachments? Not with Google Cloud Connect for Microsoft Office. And not with Microsoft’s own cloud initiative. You don’t open a file – you connect to a document.

Even when you look directly at the Google Docs app interface it is really hard to identify the documents as files. It isn’t just a cloud drive with a bunch of files in it. There is no “native” file format. At least to the user, the things just are what they are – spreadsheets, drawings, etc. The unit of storage is an implementation detail that just doesn’t matter until you need to export to another format – which is rare.

And the big news this week is that Apple announced they too will be hosting documents in the cloud:

Every doc, every edit, everywhere.

Not because of hype, not just to make money – but because it is better.

Music is slightly different in that we’re accustomed to both possessing and streaming music. Our purchased music lives in files on our various devices and we have elaborate systems for moving it around and backing it up. However, this too is changing.

Google Music is a serious attempt to dramatically improve the user experience around music consumption. It is:

A better way to play your music. Upload your personal music collection to listen anywhere, keep everything in sync,
and forget the hassle of cables and files.

It isn’t a coincidence that files are mentioned here explicitly.

Yesterday, Apple announced that the key part of iCloud is iTunes in the Cloud. And the pitch for this was in part:

…music you purchase in iTunes appears automatically on all your devices.

Without concerning yourself with downloads or files. Really, iCloud is all about elimination of files from the user experience. That is part of what is meant by “post-PC”.

Amazon also has some interesting things going on here. It is really nice to be able to just click on an album in Amazon’s store and then be able to play it on all of your devices. Without downloading files.

But music not being tied to files isn’t that new. I have playlists on Last.fm, Pandora, and YouTube and at no point does the experience of creating them or using them expose me to files.

Well, you may ask, why do I have so much music on my computer then? Basically, because you put it there and you were working around the RIAA. Once you have a better place to put it you won’t. Music in the cloud is a better user experience.

Pictures are interesting for a few reasons. One thing is that even though you still probably have most of them on your computer you very likely don’t actually interact with the files. Cameras store them in weird ways and there are a boatload of crappy apps that help manage them. Another thing is that you all take a shitload of photos. Which is one reason I suspect that even Apple won’t be permanently storing all photos in iCloud by default. Also, some of you are shy and the rest of you are pervs. 😉

In any case, we don’t really think of the content on Facebook, Picasa Web Albums and Flickr as a bunch of files and more than not that is where we are looking at photos.

And again, it isn’t because it is fashionable but because it is better.

Videos can either be similar to photos or similar to music. There really isn’t much different from what I’ve said already in those areas. YouTube, Flickr, Picasa, etc are where we expect to find and share videos.

Downloads are different. In most cases I think this is more for temporary storage for something that doesn’t have a well designed and integrated workflow. In many cases we still need to download software before installing it, download PDFs before printing, or moving to a USB stick or some other type of file bouncing. I hope to investigate this more in future posts.


So, this doesn’t mean that files are going to go away. But we do need to start to think of files differently. Perhaps more like a cache. Perhaps the local system as only one of many possible data providers.

Avoiding files allows us to side step some of the most frustrating things about computer use. When Google says “we want to strip out what frustrates people about operating systems” a large part of what they mean is removing the concept of files. And all their related annoyances: syncing, backups, “I left that at home”, “I’m out of space”, “where did I leave that”, etc. Files are a mechanical world metaphor that retain many of the problems of “things” in the real world.

There really isn’t any disagreement in the industry about this. Where people seem to differ is in how to handle it. I think there are a few approaches here: deep application integration, web primary, and service aggregation. Apple/iOS is doing the first, Google/ChromeOS the second, and maybe HP/WebOS the third.

I think the third approach is the only possible one if you don’t have your own hardware, OS, and huge-ass datacenter.

This all leaves us in Free Software land in a bit of a pickle. Our relevance or even existence depends on how well we can navigate these clouds. But the sky is filled with flak: proprietary licenses, restricted trademarks, limited terms of use, brand “nationalism”, collusion and cooperative agreements.

It is a huge challenge that we must face. Even if you are personally happy to manually manage your local files – the rest of the world isn’t – and this isn’t about you. It is about our future and the future of free culture. This isn’t a problem for tomorrow. This is all happening right now. How do we enable these better experiences without compromising our freedom? What do we do about this new pony? Let’s figure it out together.

Well, you’re so bad and nasty
But I love you, yes I do

— Bob Dylan New Pony


Posted in Uncategorized | Tagged , , | 23 Comments

Hot City

Today is very special.  We have achieved a major milestone in the history of the project.  GNOME 3 represents a continuation of the spirit that has powered us for over a decade.  And a bold departure to realms we have yet to explore.  You’ve done something extraordinary.  Take a moment to savor it.

“I’m so happy I could scalp somebody.” ― Mark Twain

Yet, we know this is only a glimmer of what we can do if we continue to show up, work hard, and kick ass together.

Especially on this day, but forever, I am so very proud to proclaim:

Please add your voice and help promote GNOME 3.  See https://live.gnome.org/ThreePointZero/Promote for more information on how you can be a part of this historic occasion.  Thank you!

Posted in Uncategorized | Tagged | Comments Off on Hot City

Shell Yes!

Back home after a typically exceptional week at GUADEC.  It is always really inspiring to be surrounded by so many people who are passionate about GNOME.  This year was particularly special for me because we are really starting to see the next wave of heroes becoming more involved with the project – and making an impact.

The overall tone of the conference was amazingly positive and productive, welcoming and fun.  Which seems to be a bit of a contrast to the debates and discussions that have occurred online in reaction to some of the talks.  It is at once sad and funny.  Well, tragic really.  Deciding who is right isn’t interesting if the question isn’t the right one to ask in the first place.

We are dividing and conquering ourselves – lost before we begin.  Are we so hungry and desperate that we must devour each other in order to survive?  I hope not.  These tribal distribution boundaries are guarded jealously and they fight over the smallest (one) percentage of the market and mindshare.

I think it is time we reunite.

If we want to change the game, think big, and demonstrate that we can truly be relevant – we need to work together. If we want to change our approach from mere assembly to something that we design and construct with consideration in a unified and coherent way – then we need to start at the source. We need to start with GNOME.

What lies underneath is mostly just implementation detail. What matters is what we expose to the user and the developer. I propose that we take notes from Android, WebOS, Meego, and others and consider Linux an implementation detail and start to define the OS as we see fit.

The question is not can we, but will we?

Shell YES!

Please see the slides from my talk for a bit more on this topic.  Read the notes for each slide for some idea of what I was saying since I wasn’t reading off the slides.  Hopefully the video will be available soon because there were some fantastic questions asked in the discussion period that followed the slides.

Posted in Uncategorized | Tagged , , , | 14 Comments

The Grip, the Trip, and the Slip

If you’ve been following the GNOME Shell design documents you may have noticed that it had these FIXMEs and sets of random notes where there should be designs for what we’ve been calling the finding and reminding problem.  Now that some of the other parts of the design are falling into place – ’bout time we get to it.

What is “finding and reminding”?  Generally, having a simple and effective way to keep track of, recover, and be reminded about various types of content and information.  In the traditional desktop computing model this often meant “file management.”  But this is 2010 and we just don’t want to party with files or management anymore.  They used to be cool but now they’re old and out of shape and make us do a lot of boring work and status reports every week?!  Sorry.  Back on track.

Most traditional computing environments offer a variety of tools which attempt to address aspects of the problem. These often include:

  • “Desktop” (folder)
  • “Places” (folders or collections)
  • Search
  • Recently used lists
  • File Manager (eg. Explorer or Finder)
  • File open/save dialogs

You’re probably thinking “hey no biggie they all work together or at least consistently, right?”  Nya.

Functional Evaluation

Well, if you take a step back and you think really hard about the problem and analyze the interactions and you’re super clever, you can come up with a functional evaluation of the system.  Or you can just cheat and find them in journal articles like I did.  Actually, I smooshed a few together to come up with the following categories of information:

  • On hand (grip) – should remain easily and quickly accessible while relevant
  • Under foot (trip) – should be visible to facilitate opportunistic finding and reminding
  • Out of sight (slip) – when the shelf life of the first two types of information expires it should gradually slip out of view

Information that is frequently used or currently relevant should be kept around and readily available. Information that is incomplete or needs attention or action should be kept in a place where it may be tripped over to offer opportunistic finding. Other information that may no longer be immediately relevant should be available but out of the way so it won’t interfere, clutter, or confuse.  Out of the way information should have a distance that is roughly proportional to its relevance (likely time of last use).

To be most useful the information retrieval system should be:

  • Available – ubiquitous access
  • Persistent – can be relied upon as a record
  • Current – up to date and relevant
  • Contextual – includes information in context
  • Present – serves a useful reminding function
  • Shareable – easily shared between people
  • Transparent – don’t require effort to maintain

The system should be designed with the following types of users in mind:

  • No Filers
  • Spring Cleaners
  • Frequent Filers


OK then.  If we use that kind of analysis to evaluation GNOME 2 how do we fare?

It turns out – not that well.  It requires too much work, is too isolated, lacks coherence and context, and doesn’t keep the right information on hand or in sight.  I’ll spare you the details until the end.


So let’s try to do better next time.  Oh wait, that’s like now isn’t it?  OK.  Hmm.  Here’s an idea…

How might we design a solution that marries the Desktop, Search, Places, and the Recently used list? How might the roles complement one another?

  • What if the Desktop was a place to stage items that need to be addressed?
  • What if items could expire from the Desktop and fall safely into a time ordered list and eventually into an archive bucket?
  • What if Places were just a default set of tags that can be used as filters?
  • What if we had enough abstraction from the filesystem that we could transparently include non-local information in the same view?
  • What if we had enough abstraction from the filesystem that would could include information that isn’t that file-like?
  • What if this same desktop+timeline view allowed me to schedule items to address in the future?
  • What if similar or related items were automatically stacked together so they don’t clutter the Desktop?
  • What if I could access my Desktop from anywhere?
  • What if the Desktop wasn’t hidden behind all my other activities?
  • What if I could easily share my content with others?
  • What if everything in my archive was readily searchable and had rich contextual metadata?
  • What if it was easy to add almost any kind of item to the Desktop?
  • What if one had the ability to tag, star, and make notes about content directly from a document window?

Might be pretty sweet actually.  What could this look like?

Hold on.  What are we looking at here?  Sigh, I mean besides a lot of lazily duplicated document icons and some poorly pixel-grid aligned… (Hi jimmac – I’m trying but it is late)

Essentially it is a representation of the following schematic:

  • This coming week
  • Tomorrow
  • Desktop (Now)
  • Today
  • This week
  • Last week

If things aren’t pinned into the Desktop they will gradually fall down the view until they safely drop out the bottom into the Archive.

Items may be filtered by any number of labels. A useful set of labels would be provided by default but users may add their own as well. Items may be starred to denote relevance or whatever meaning the user wishes to assign to that designation.

I’ve written up a lot more boring details on the wiki so feel free to check it out and make comments in the appropriate section.

What do you think?  They tell me it is doable.  And no it’s not a pooper.

Drop by the GNOME Shell design office hours today (Wed) 2 – 4PM EDT (UTC-4) on irc.gnome.org:#gnome-shell and let us know what you think.

Posted in Uncategorized | Tagged , , | 18 Comments

Above the clouds

Finally settling back into the groove after an exciting week in London at the GNOME 3 Usability Hackfest.  Despite the title of the event, I’m glad that it turned into a wide-ranging, and multidisciplinary discussion of user experience design for GNOME 3.  These kind of free-form, high bandwidth, and deep tissue discussions are so much more effective in person.

We started the week by talking about high level goals and broad stroke experience design.  It was awesome that Seth Nickell was able to be present for this and, as always, brought a lot of fantastic ideas and energy to the conversation.  These discussions and the goals for GNOME 3 that we list in the GNOME Shell designs seemed to inspire some of the various blog posts he made during the week.  It was a lot of fun to “throw up waves of leaves and dance in them.”  However, of course, one of our next challenges will be to try and figure out how to rake them back into piles.  I’ll try to cover that in another post, soon.

For me, two things became clear after these discussions.  The first is that we have a really compelling and exciting story to tell about GNOME 3.  The second is that we need to do a lot better in telling that story.

This kind of big picture thinking and goal setting is really valuable and far too rare.  It allows us to establish markers to help navigate and iterate our way forward with more confidence and less risk than simple dead reckoning.  Without overly specifying or constraining the path.  This is an important thing to remember on any journey – be it a trip to London, a stroll through the woods, or a software design and engineering effort that may change the world.  Don’t believe a 5 year plan.  Allow for the unexpected.  Leave room for fun.

What are the goals for GNOME 3?  I can throw at few at you.  But feel free to come up with your own.


Yes, I’m super serial.  It’s in the GNOME Shell design document.

Inspire the world.  With our designs.  Our code.  Our culture.  Our ability to listen and adapt.  Our get shit done ethic.  Our spirit of adventure.

Prove we’re relevant to a broad spectrum of people.  Finally start to meet the promises and match all the big talk.  Show that everyone deserves great design, an open and accessible platform, and a participation model that facilitates and encourages personal growth from “reader to leader.”

Provide a framework for taking responsibility for the user experience.  No more excuses.  No more: NOTGNOME, not my module, not my problem.

Help us cope with modern life in a busy world.  Help us connect, stay on track, feel at ease and in control.  Manage being informed without being disrupted.  Allow us to get deep in the zone while our next activity only a gesture away – right where it always is.

Design a first class technical platform that can meet the challenges of and take advantage of the capabilities of modern computing hardware.  Bring desktop programming into the web age.  The Shell is Javascript and CSS – yes, that Javascript and CSS.  The same ones that a gazillion teenagers are playing with right now.  Provide a clear and consistent guidance to application developers.

Sound good?  Love to hear what you think.

[Will continue with more from the hackfest in the next few posts]

Posted in Uncategorized | Tagged , , , | 12 Comments

Action Pack

We have been inspired by GNOME.  Moved to act by the ideas, ideals, and opportunities.  Encouraged to stay as we grow ourselves and as a community.  We know that the true measure of strength is not how much you can take but how much you can afford to give.  And we have demonstrated that, by sharing, we can all succeed.

GNOME is a story that continues to inspire me.  And in my eight years and counting, if I have achieved little more than making one person feel hopeful for and empowered to change their future, I will feel very good about the work we are doing.

As we march towards GNOME 3, I feel very strongly that our truest measure of success won’t be the technology, design, or ideology – but simply this: Will we continue to inspire?  I am very hopeful.  The signs are looking very good.  Back in June I asked, “Will a new crop of heroes emerge?”  Well, let me tell a short story and let you decide.

In November and again in early January, we posted some new design proposals for GNOME Shell.  Many of them went into a release of the design document and SVG mockups.  Others came out of discussions on IRC.  Now, nearly all of these changes are complete.  That shouldn’t surprise you too much if you know some of the hackers on the original Shell core team.  Those dudes are among the best we have.  However, that’s not how it went down.  It has been much more interesting than that.

Mockup from 6 January 2010

There are actually a lot of changes introduced here but I’d like to point out a set of exemplary and highly visible changes:

  1. A new linear workspace presentation
  2. Added undo functionality into the core system
  3. New look for App running indicators
  4. Updated presentation of the left dash and App Menu item in the Top Bar
  5. Allow close windows directly from the window picker
  6. No icons on desktop backdrop
  7. Include eject buttons for removable media

All done.  Now let’s look at how, when, and by whom.

  1. On Jan 22, Maxim Ermilov pushed the fix for bug 593844. Jan 23, Florian Müllner pushed a few more refinements.
  2. Feb 5, Maxim Ermilov wrote the fix for bug 608933.
  3. Jan 7, Florian Müllner pushed a fix for bug 606257.
  4. Jan 7, Colin Walters pushed fixes for bug 605491.
  5. In Nov and Dec, Florian Müllner pushed a few patches for bugs 602532, 603691, etc.
  6. Feb 3, Maxim Ermilov pushed the fix for bug 591912
  7. Nov 27, Florian Müllner pushed a fix for bug 602976.

You all know Colin Walters (Debian, Rhythmbox, Fedora, Mugshot, D-Bus, hacker man-machine) but you may not yet know Maxim and Florian because from what they tell me they are pretty new contributors to our community – but hell they sure know how to make an entrance.  Stay tuned.

By no means has the rest of the Shell community been slacking.  A ton of work is going on a bit behind the scenes and on the rapidly evolving Message Tray.  In the next few days we’ll be discussing the the next iteration of UX mockups and designs as well as exciting plan for evaluation of some of the claims we’ve made in our design process so far.  Come be a part of the action.

Posted in Uncategorized | Tagged , | 14 Comments

Taking Notice

Over the last few weekends I’ve been working with Christian Hammond to try to get our notification specification, libnotify, and notification-daemon story in order.

Bugeye by bensonkua

Long story made short – things had become a bit fragmented over the last year or two.  A number of people tried valiantly to move the spec along but were unsuccessful in getting their changes published.  Everyone on the planet that was shipping libnotify and notification-daemon shipped them with a different set of patches.  This meant we had lots of different micro-forks of both the implementation and specification.  We even had a hard time agreeing on the version numbers for the specification.  Version 0.10 happened after version 1.0 was published.  Yikes, what a mess.

Some downstream distributions either decided to try to differentiate by writing their own notification-daemon implementation or writing custom bubble themes.  This kind of differentiation or fragmentation is dangerous (or at best anti-social) and should usually be viewed with some skepticism.  I should not be spared from this criticism either since I wrote a new theme that we used in Fedora 12.  (It is now included upstream)

So, out of respect for the original authors and innovators I put some time in to try to straighten this all out.

The canonical implementations have a new home:

The notification specification source has a new home:

The bug tracker does too:

We still need to find a place to host the new 1.1 version of the specification on the GNOME web site.  After discussing this with Fred Peters it seems like http://library.gnome.org/devel/references#standards is an appropriate place for it.  Hopefully we can decide in the next few days.

I have to give credit where it is due.  Most of what I’ve done is merging the changes from Andrew Walton and Aurélien Gâteau.  Thanks dudes for continuing to do the right thing and pushing changes upstream – even or especially when it was hard.  And thanks to Christian Hammond, Mike Hearn, and J5 for their vision and hard work in getting us to this point.

Now, hackers we need you.  Please grab these from git and test them out and file bugs.  I’d like to do a release in the next few days but it would be great if they got some testing before then.  Thank you!

Posted in Uncategorized | 15 Comments