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!

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

 

“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!

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.

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

GNOME 2

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.

GNOME 3

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.

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.

gapingvoid.com

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]

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.

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:

• http://git.gnome.org/browse/notification-daemon/
• http://git.gnome.org/browse/libnotify

The notification specification source has a new home:

• http://git.gnome.org/browse/libnotify/tree/docs

The bug tracker does too:

• https://bugzilla.gnome.org/browse.cgi?product=notification-daemon
• https://bugzilla.gnome.org/browse.cgi?product=libnotify

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!

If you were reading this and this carefully you may have noticed links to a design document for the Shell.  I’ve just put out a long overdue update for that document.

Please read the GNOME Shell Design PDF and let us know what you think.  Higher resolution versions of some of the figures used in the document may be found here.  We’ll be adding these to the wiki soon.

Once you’ve read the document please grab the Inkscape SVG mockups and try to make them better.  I’m sure that you can.  My drawing skills are not exactly legendary.

Looking forward to hearing your thoughts and seeing your modifications.

As usual find us on IRC #gnome-shell on GimpNet or http://mail.gnome.org/mailman/listinfo/gnome-shell-list .

Make sure to try it out too.  It is really easy to use from jhbuild.  See http://live.gnome.org/GnomeShell#building

As most of you know, tooltips are the little window-like pop-ups that (hopefully) provide helpful information about a user interface element (widget, control, etc) as you hover over it.  It seems to me they were originally used to provide textual assistance for the case where the user is unsure what a tool will do when activated.  And were particularly useful when the tool had no intrinsic text.  However, since then their use has expanded and become more generalized.  They are used for quite a few different things today and can contain more than simple text.

Now granted, you have probably never been consciously annoyed by tooltips.  More likely you haven’t really thought a lot about them at all.  But that doesn’t imply there is no room for improvement.  I spent a few hours examining my own interactions with tooltips and I came up with a few things that bothered me.  These basically fall into the categories of: color, shape, and position.

The issues with color and shape are fairly obvious.  Yellow! boxes!  right out of the mid 90s.  The issues with positioning are a bit more subtle.

Before

Notice how the tooltip:

• Obscures what you are looking at
• Gets all up in your shit
• Does not appear in a stable position
• Appears to be more closely associated with the pointer position than the thing that is providing the tip

How about something like…

After

Niiice!

Thanks Matthias.