I once wrote a nice rant about the inadequacy of the desktop metaphor.

In the light of the upcoming GNOME 3, the more document-centric Shell and the browser-mode nautilus (instead of spatial mode), I wanted to remix my thoughts a bit.

Note: I am not a developer and I am not on the Shell or Nautilus teams. The idea of a desktopless environment was briefly raised on the Nautilus mailing list months ago and has hesitantly appeared at the end of the GNOME Shell Design Document, as quoted below:

Used for both ephemeral, and working set data finding and reminding. Given time, the constant stream of things to do, the constant remainder that does not get done, and the unwillingness to categorize and archive manually, and the fact that the solution doesn’t scale (due to being spatially bound) results in the system breaking down. On top of this – so to speak – is the problem that this data lives underneath all of the current activities on the computer and is therefore very difficult to reach. Which also tends to reduce its effectiveness for finding and reminding. It also doesn’t provide any form of prioritization.

In the Shell design, the “desktop” folder should no longer be presented as if it resides behind all open windows. We should have another way of representing ephemeral and working set objects.

The reminding function of the desktop is really only available immediately after login. Once any activities are started its effectiveness is dramatically diminished. Starting the Journal automatically at login will have a equivalent effect and have the advantage of being easier to access later.

However, I haven’t seen much more happening since then, and I believe this to be a fundamental question to settle. GNOME 3 would be, in my humble opinion, a perfect window of opportunity for an “intrusive” paradigm shift like killing the aging desktop metaphor.

I believe the concept of “icons on the desktop” to be counterproductive and perhaps counterintuitive. This blog post is a humble attempt at demonstrating why.

Windows obfuscating contents

Most of the time, the desktop is hidden by multiple windows. To access your desktop contents, you need to manually minimize your windows, hit Ctrl+Alt+D, or use the “Show desktop” panel applet (which probably won’t exist in the Shell anyway). Then, when you are done interacting with your desktop, you need to raise all your windows again. You keep moving things out of the way and putting them back in the way, all the time!

Alternatively, you could use nautilus to access the contents of the desktop folder, which defeats the purpose of having contents on the desktop. Or you could always keep an empty virtual workspace to switch to, but it quickly fills itself with windows and the cycle repeats itself.

Icons, visual clutter and cognitive strain

The Desktop is typically “designed” for transient files (though, as I’m arguing here, the vast majority of users don’t actually use it for its intended purpose). By transient files, I mean the following categories/scenarios:

• Files that I received or downloaded (through instant messaging, or files that the web browser auto-downloaded for me, for example)
• Temporary crap: blogging material, files to be attached to bug reports, files from bug reports, emails, etc. Usually files with a lifespan of five minutes.
• “Reminder” files, there just to annoy me into doing something about them.
• Files that I am currently working on (though, in theory, nothing prevents us from working on files that were already filed properly in folders)
• Files that are “waiting” for something (for example, files I would need for project X in 2 months)

The distinguishing lines between those scenarios is often blurry, to say the least.

The problem with desktops is that we, modern “information workers”, have heaps of data to process, and we have the following choices to make about a file (GTD/Inbox Zero fans will see that one coming):

• Process it immediately (and then delete or archive it)
• Defer it (“I need to wait 2 weeks for event X to happen before I can touch this”)
• Archive it (in that case, it should not be on the desktop)
• Get lazy and let it sit there

Oftentimes, this means items start accumulating on the desktop for weeks on end, waiting for the right moment/motivation/energy to be used. All this has a price. For some, it can be annoying to have all that stuff in your face all the time, or it can become a chore to “clean up”.

Ironically, the inverse tendency can also be true: the less there is, the more we are inclined towards piling up new stuff.

Keeping the balance takes determination and technique (not everyone is a GTD/Inbox Zero maniac). For less organized people, the desktop just becomes a dumping ground, full of “stuff” constantly in your face, “urging” you to be processed and reminding you that you should be doing something else but don’t have the energy or resources needed.

My point is a bit hard to prove here because, to some, it may look like I am advocating “hiding stuff under the rug”. For the sake of the argument though, I shall say that I have been running my computers without a desktop since 2007. This is what it typically looks like:

And this is what happens if I reactivate the “icons on the desktop”:

As a real world analogy, my current summer job involves office work. Pure, old-fashioned office work with actual folders, tons of paper, a hole puncher, stapler, and pencils. I process a couple of dozen cases per day, which means that my desk is a constant mess, with me pushing and pulling folders around, using aforementioned tools, throwing them back in the pile while I go fetch printouts, letting objects fall on the floor, leaving bits of memos everywhere, etc.

It doesn’t look exactly like this, but close enough:

(picture by Rob)

It is Hell.

Why would I ever want to reproduce this kind of chaos onto my computer screen? Isn’t it the computer’s job to give me unlimited storage and triaging capability for me not to shuffle things around constantly?

Text legibility

Partly due to Bug 317764, GNOME’s text readability on the desktop is very poor, to put it nicely.

As I don’t want to nitpick on a bug report that I filed years ago, I won’t comment further on the matter. Suffice to say, reading text without a solid, contrasting background is an accessibility disaster. Those who want to dig the matter can take a look at the bug report linked above.

Wallpaper enjoyment

Not only complex wallpapers impair text legibility (as mentioned above), but the reverse is also true: text and icons take away from your enjoyment of a good wallpaper because they add visual clutter. When I wrote my original article a couple of years ago, I had calculated that out of my 2500+ wallpapers, about 5-10% of them could actually be used with the traditional desktop metaphor.

Here’s the thing: our icons are mostly bright, and their text labels are bright too. Even with sufficient text borders (if bug 317764 was fixed), having items on the desktop interferes with the artistic complexity of most wallpapers in terms of clutter, brightness, contrast, etc. For that reason, only a minority of minimalistic wallpapers are truly suitable for use with icons on a desktop.

Incoherence with the “file manager”

By exposing the desktop folder as a special use case, we lose a great amount of functionality and break the consistency with “normal” folders; the desktop does not have the same features as the “full-featured” file browser Nautilus. No side pane, menubar, toolbars, no listview/treeview/compact view/infrared view, etc.

It made “some” sense when spatial mode was the default behavior, but it doesn’t make much sense now that browser mode is the default.

TL;DR/summary: the desktop metaphor sucks. We are stuck with a limited surface, limited file management tools, and a background that actively impairs legibility of the files sitting on it (unless you’re using a solid black background).

Not so intuitive?

The desktop metaphor is often presumed to be more intuitive to use, because:

• The user would interact solely with that desktop, thus see the entirety of his/her’s important files. This falls short for anything but the simplest use cases.
• Users come from Windows/Mac OS/Altimit OS and are used to the desktop metaphor. This is one of the eternal debates of usability, “Do we make drastic changes or do we keep everything ‘familiar’?” It struck me, however, that one day my mom asked me directly if those desktop folders could vanish! A similar observation applies to a couple of other relatives: I suggested disabling the desktop because it was a mess and… they actually agreed!

In my opinion, for someone who was not trained for using the desktop (others can be retrained, or brainwashed), not having a desktop does not make a computer less intuitive. Actually, I believe having a desktop increases the difficulty, due to the reasons mentioned earlier and because it creates “another” way to access your files and folders.

You can easily explain to someone that “Whenever you need to access some of your documents, you just have to access the Activities screen and click your Documents folder, or your Home folder”. Explaining why some things appear on the desktop but at different places in the file chooser or Nautilus? Not so much.

As a matter of fact, unless the gconf key “desktop_is_homedir” is set to True, the standard XDG directories (Documents, Images, Music, etc.) are not even located on the desktop, so the user has to use the Activities menu to access them anyway. Many users don’t bother. And many users have no abstract conception of the distinction between the Home folder and the Desktop folder. I have observed this time and again.

In GNOME 2.x, switching non-geeks to launching their Home folder from the Places menu is a bit of a stretch, since it requires more abstract thinking (knowing what files and folders are).

Things change with the GNOME Shell: the incredible elegance of the Shell’s concept is that it combines applications, recent documents and places all into the Activities menu, which is accessible simply by a flick of the mouse. This means that accessing the home folder takes exactly one click, and is much, much less painful. The fact that the Home folder can now be accessed so easily is one more reasons why I believe the time is right to get rid of the desktop. The fact that removable devices can be accessed (and unmounted) directly from the Shell is icing on the cake.

Back when I wrote the first version of this essay a few years ago, the ecosystem was different. We were in the middle of a stable GNOME 2.x series, with no revolutionary 3.x redesign at our doorstep, and the thought of advocating a desktopless GNOME 2.x as the default behavior didn’t even cross my mind. However, at the dawn of a groundbreaking release, I believe now is the time to voice one of my deep convictions: we ought to kill the desktop by default. This means:

• Set the key “/apps/nautilus/preferences/show_desktop” to False by default
• Set the key “/apps/nautilus/preferences/desktop_is_home_dir” to True (unless we have a new use for the desktop folder)
• Ensure that the interaction between the Shell’s and its places shortcuts is rock-solid: it needs to fully support dragging and dropping items onto places such as Images, Documents, Home, etc; it needs to be reliable in showing all the removable storage devices and reliable in mounting/unmounting them. Have 20 usb keys plugged in? They should all be easily accessible without even launching Nautilus.
• Eventually: complement this vision with tools like GNOME Activity Journal and the (experimental) idea of “project-centric” workspaces. Surely someone smarter than me will be able to come up with a brilliant solution to the eternal problem of “limbo/temporary files”; perhaps a zone where files have “expiration” dates and where users can “pin” files to prolong their life before they are either archived (put in another folder) or trashed.

What about “@Waitingfor” files?

As I mentioned previously, there are some kinds of files that you need to work on at a later time. Back in the day, I wrote a horrible, hacky python script to deal with this, called FrontBringer. Again, perhaps that the great minds behind the 3.x vision could come up with a better way to handle this use case, with files that you can “pin” or put in a “cryogenic storage”. Or something based on Lucas’ newly announced Board. Perhaps Guadec would be a great time to discuss these things (I will not be able to attend, sadly).

Gentlemen, start your flamethrowers.

Well hello there. I haven’t blogged much about PiTiVi lately, since I hadn’t kept up with the project’s happenings for a month or so. My PiTiVi bug mail folder was getting out of hand, so did some triaging today and discovered some gems. Namely, “Pier Carteri” has been hard at work, tackling two of the items on the PiTiVi Love list: a feature to revert to the saved version and a previewer in the file chooser, which looks roughly like this:

“Sup dawg, I heard you like videos, so we put a previewer in your file chooser so you can preview while you choose your files so you don’t have to preview them in the previewer after having chosen them.”

Now, be aware that those changes are not yet official: they are in Pier’s own git repository and have not been thoroughly reviewed and merged in the master branch. There are probably bugs and rough edges left. This is where you, gentle reader in quest of adventure, come in and test the hell out of it. Play with it. Break it. Unleash the fury of the bleeding edge tester.

Some other notable bugfixes in pitivi git lately:

• Rendering WebM/VP8 now works properly (bug #621576)
• Aspect ratio was not preserved when rendering, resulting in letterboxing (bug #615569)

I’ve been happily using various pieces of software over the last five years (especially nautilus-cd-burner and K3B) to burn ISO images, create data DVDs, etc. I’ve come to rely on that kind of stuff to work and keep working.

Not in Ubuntu 10.04. For some reason, I have been unable to burn a single data DVD tonight.

Let’s see:

• I tried dumping one or two files into a blank data project in Brasero, putting a blank DVD+R in and hitting the Burn button. It seemed to work, then failed a few seconds after starting the burn process and dumped a truncated error log (not very helpful, but available further down below).
• Cursing the good name of Brasero, I promptly uninstalled it and put nautilus-cd-burner back in place, expecting it to do the job where Brasero had left off (Brasero was at least able to create an ISO image). And there came the surprise. Nautilus didn’t work either. That’s news to me. Wait a second. I remember K3B not working either lately. Uh oh.
• I then tried from the command line, with the following command: growisofs -dvd-compat -Z /dev/sr0=GITS.iso
  • This worked with a (freshly blanked) DVD+RW.
  • …and then when I attempted the very same command with a DVD+R, it failed.

Is it growisofs’ fault? cdrecord? The kernel? Some other thing? There are so many pieces of software in the Linux CD/DVD burning ecosystem that it’s a maze for a non-connaisseur to figure out. And somehow, this is not very encouraging:

For the record, my computer is a Dell Inspiron 530n (ubuntu-certified desktop machine that has worked flawlessly so far) with an Optiarc DVD±RW AD-7200S. My Sony accucore DVD+R discs are the same ones I have kept purchasing over the years (the most reliable I have found).

Here is Brasero’s error log when trying to burn directly from a data DVD project, when trying to burn from a DVD ISO image, and here are my two attempts at using growisofs on the command line (DVD+RW = success, DVD+R = fail).

I’m stumped; I have wasted 3 blank discs and still haven’t been able to burn the data I wanted to give to a friend or even figure out why this is happening. Any ideas? Are there many users affected by this, or are we only a handful? Issues like these are hard to justify in an Ubuntu LTS release.

Update (2010 06 07): it seems the problem was Brasero creating incorrect ISO images. Trying to burn an existing ISO image works, so my drive, kernel, cdrkit/wodim/cdrecorder libraries are not to blame.

There’s an ugly bug in Outlook (a bug in Outlook?! ya don’t say…). If you use Evolution, and send out a nice mail with accents or special characters in the attachments’ filenames, like this:

Then Outlook will parse it like this:

If you have multiple files with the same extension, it will just name them “ATT*.dat” (where * is random gibberish) to differentiate them.

I discovered this “the hard way” when I was sending some serious business mail for school work/research and someone came up and asked “what are those .dat files for?”

Turns out there’s an option for this. In the preferences: Composer Preferences > General > Encode file names in an Outlook/GMail way. The gconf key that it controls (/apps/evolution/mail/composer/outlook_filenames), has the following description:

Encode file names in the mail headers same as Outlook or GMail do, to let them display correctly file names with UTF-8 letters sent by Evolution, because they do not follow the RFC 2231, but use the incorrect RFC 2047 standard.

So if you set that key to True, your mail shows up like this in Outlook:

My first reaction was, of course, FFFFUUUUUU- , followed by “argh, Outlook certainly has no bug tracker I could report this to“. I guess I’m too used to open source software.

And so we have to conform to crap like this to interoperate, or manually strip out accents from the mails we send to known Outlook users (I haven’t seen this problem in GMail). I wish I could just make Outlook vanish from existence, but, from my experience, few MS Outlook users are MS Outlook users by choice. Instead the software has been dictated by the work environment (in healthcare, the government, etc.).

Please tell me that MS got their act together and changed this in later versions (>XP)…

Hello Planet GNOME (thanks Lucas for adding me)! You may know me from the Specto or PiTiVi projects, or as your worst bugzilla nightmare:

What I’ll do

I’ll be mostly blogging about PiTiVi (because that’s what I’m the most involved in these days, and the devs are usually too busy unleashing their fury onto foul minions of Hell), and I may remix some of my old usability thoughts in the new light of GNOME 3.0.

On that note, I’m still waiting to see whether or not the “icons on the desktop” debate/idea has been settled (I haven’t quite caught up on Nautilus’ and the Shell’s happenings in the past few months). If it has not, I may attempt a thought experiment on it.

What I will (probably) not do

So, what’s new in PiTiVi lately?

Note: I suggested that the Title and Description fields go into a dedicated “Metadata” tab, we’ll see.

However, PiTiVi 0.13.4 will be the version bundled with Ubuntu 10.04. It is quite basic, but, like many new applications in Ubuntu, should benefit from the large testing user base, and hopefully gain some new contributors. The current work highlighted above gives me an optimistic outlook on PiTiVi’s future.

Want to help out with PiTiVi? We need all the help we can get! Take a look at our contributing page.

Sintel logo proposal

I shall conclude this blog post by highlighting how awesome Inkscape is. In a matter of days, I managed to create this logo entry for the Sintel open movie project entirely in vector art.

While it took me a long time, I mastered the (over)use of shape masks and learned how to use “Live Path Effects” along the way. Some folks on #inkscape have been very helpful in pointing me in the right direction (which part of the documentation to look at). Along the way, I encountered a nice rendering bug with Live Paths Effects. Basically, my nice dragon scales looked like this:

Looks like Inkscape shares some attributes with inkjet printers! ;) To work around this problem,  I had to fiddle with the DPI/rendering resolution until I stumbled upon something that renders correctly. Ew.

Also, it seems Inkscape gets real sluggish on a Core2 Quad when you have a LPE with 9785 nodes on top of a dozen layers with masks and blur effects. And yet, somehow, I was surprised. Can you believe how demanding I have become of computers? :)

All in all, hats off to the Inkscape project. A great app, easy to pick up, stable, and a joy to use. You provided me with lots of fun in the past few days.

Are you a student looking for a fantastic experience in improving a great open source video editor project? This year again, GStreamer has been accepted as a mentoring organization in the Google Summer of Code, and oversees project applications to make PiTiVi kick ass. Student applications are now open, and the application deadline is April 9th, so come discuss your ideas as soon as possible!

Stephen “lostcookie” Griffiths recently started coding on PiTiVi, learning the codebase as he works through the PiTiVi Love list. He has done awesome work on the source list to implement an “icon view” mode and has managed to somehow not become insane while I pointed out all his mistakes and bugs :)

The icon view is especially useful if you are working on a wide, high-resolution monitor (ex: 1920×1200) with a large number of clips that have nice thumbnails, because you can fit more of them without needing to scroll.

Before:

After:

This definitely looks cool. Great work Stephen!

I have requested additional super cow powers on GNOME bugzilla to be able to do some serious bug triaging in PiTiVi’s bug list. I have

• Touched approximately 70 bugs or more today (out of ~230 initially), spending approximately 5.5 hours doing bug triaging and hunting (according to hamster)
• Confirmed many unconfirmed bugs
• Updated target milestones (even for already fixed bugs!)
• Added keywords (and added “Special searches” to the website)
• Reassigned components (so that Brandon can easily search for bugs that are related to the user interface)
• Closed a ton of obsolete/fixed/duplicate bugs.

Damn, this feels good. I hope Edward won’t be mad at me for doing the cleanup and flooding his inbox while he was on vacation.

I was keeping an eye once in a while on the promising SFLPhone project, developped by the Savoir-faire Linux folks.

A slightly outdated screenshot I took (back in June, when I first wrote the draft for this blog post), since I’m too lazy to take new ones:

I’m using Callcentric as an SIP provider and Twinkle was the only Linux client (well, except x-lite) that seemed to work with it. However, Twinkle has the following problems:

• Not very open/friendly/vividly maintained. This is my subjective view. A project that has no public bugtracker, public version control repository, and an author that does not respond to emails (I sent a few of them over the last two years), is, to me, an unfriendly project.
• QT 3. Ewww. I can bear with that, but I much prefer GTK+ applications. SFLPhone has both a GTK+ and a QT interface.
• Does not work well with PulseAudio
• Complex (follows the KDE approach of maximum configurability), which is not necessarily bad for something like VoIP, however
• Weird bits of German appearing in the GUI, poor/incomplete French translation… which I can’t fix since the author never replied.
• A huge gaping User Interface the size of a hallway
• Terrible icons: what’s up with having smileys everywhere? They all look alike!

But generally, Twinkle works and is stable, which is sadly much more than every other VoIP client I tried out there on the Linux desktop. I was just looking for something better-integrated (especially with PulseAudio) and for which I could contribute without feeling like my efforts were going into /dev/null.

I found out that SFLPhone improved a lot in recent times and decided to give the daily builds a shot (because the 0.9.5 release does not work with callcentric). I was amazed at how well it worked. While there are some details to polish here and there (I filed around 44 bugs since june), making and receiving calls with callcentric works quite well.

And here’s where the awesome starts: it is designed with PulseAudio in mind. That means that it [supposedly] mutes the other applications when you are receiving a call (well, it used to, at least). I shot a video of me calling my computer (using a regular landline phone), and the computer automagically handled the call by muting Rhythmbox. This, my friends, is the kind of cracktastic shit I’ve been dreaming of.

There are still many issues left to fix, but it mostly works. I use it frequently to record important calls, for example.