So I’ve been reading the usability design docs for GNOME Shell and trying to figure out what I think they’re saying.  Frankly, it’s a bit unclear.  The Applications menu is broadly replaced by the “Activities” pane, which subsumes the role of Activities, Recent Documents, and Filesystem Bookmarks (yeah, I know; it’s still labeled “Places” despite the fact that that name communicates no information and ambiguously suggests it’s about Location services, which is a genuine embarrassment since GNOME is adding support for that re WiFi and Zeitgeist).  But here’s the issue: in the screenshots and screencasts, the Activities pane  always appears to hold four or five (tops) application icons.  If you need access to more than four or five applications on a regular basis, you have to search for them, then find the app you seek in an alphabetically-sorted list.  I can tell you right now that that is not going to work for me.  I regularly use two dozen or more apps.  Some of these I keep open perpetually (mainly communication apps, terminals, and Emacs), but most of the others I close down when not in use, simply to conserve memory/swap, etc (Inkscape, The Gimp, Rawstudio, Scribus, Krita, some Prism sites, Rhythmbox, MythTV, VLC, the calculator, Deluge, office apps, Grip, PiTiVi, Grsync, and so on and so on).

Having to search every time I need to launch the fifth-or-sixth app out of that list will take me more time.  If there’s no way to configure this behavior, I’m not looking forward to it.

That isn’t to say that the current Applications menu is All That.  It relies on strict categories, but the categories are broad and fill up rapidly.  Here’s the current count of my GNOME app menu categories:

1. accessories: 32
2. archimedes: 2
3. education: 3
4. games: 19
5. graphics: 41, 2 in a submenu
6. internet: 35
7. office: 22
8. other: 3
9. programming: 9
10. sound n video: 44
11. system tools: 15
12. unviersal access: 1

Obviously, you can see some bias in what tasks I do just by counting those menus, but the point is that everyone who uses their desktop to work has usage patterns.  More than one, I think.  I can group what I use my environment for broadly into office “stuff”, work communication, social communication, creative, entertainment, and utility computing.  They overlap; office stuff includes taking screenshots and writing, plus emailing and installing software.  But utility computing includes updating software, too, and work and social communication both could involve IM, Thunderbird, and other apps.

Still, in my own introspection, when I’m in one mode I need to stay in it for a length of time, then switch.  When I’m working, I’ll have and app open to test and I’ll write about it, and I’ll email/IM/VoIP questions and answers back-and-forth to its creator.  When I’m doing creative work, I’ll need to switch back and forth between the creative apps, often many many times.  But I stay within one circle of apps until I change modes.

The way I’ve customized GNOME 2.x to work with me in this method is through the use of launchers that I place on a dedicated panel, grouped roughly by task list, and by having the “perpetual” apps launch at login.  So far, I’m not seeing in the GNOME Shell documentation how I’ll be able to do anything like that in GNOME 3.  The Activities pane seems to limit the raw number of launchers I have immediate access to, and it seems to enforce either “most used” or “most recently used” as the sorting criterion — unclear which.  That has two problems: first, the perpetual apps are almost always going to qualify as “most used,” and when switching modes, a boatload of apps I specifically don’t need are going to qualify as “most recently used.”  In short, if I’m not able to customize the application launching behavior, it’s going to slow me down.

LGM is half-workshop and half-conference; developers that work on all sorts of graphics programs gather together and collaborate on tools that make graphics better — we’re talking photography apps, drawing apps, pub design, 3D modeling, fonts, and this year even video editing.  But there are also a lot of “behind the scenes” projects and libraries that make an important contribution, too — from rendering SVGs to managing color to printing.  When the teams that build these libraries and applications get together in one place, it enables more innovation, better communication, and makes all of the apps rock that much faster.

But LGM has no corporate overlord to make it happen; it is completely volunteer-driven and self-supported.  There is no expo floor and there is no entrance fee; the conference depends on the kindness of the community to make the venue, accommodations, and travel possible.  And for the past three years, the community has come through admirably — helping bring the conference together and in turn reaping the rewards of better graphics on Linux, UNIX, Macs, and even Windows.

But wait, didn’t I say that LGM was only half workshop?  That’s true, because even if you’re not a developer, you’re welcome to attend,  and attend free of charge. You can learn how to help out, learn how to make better use of the graphics apps that you already love, learn about applications and features that are brand-new, plus enjoy demos and performances from the free graphics community.

So if you edit photos, sketch, paint, design, or build in 3D, for fun or for work, you’ve got something waiting for you at LGM 2009. And even if you can’t make it to Montreal on May 6-9, you can help make the conference bigger and better for everybody. All you have to do is visit the LGM Pledgie page and make a small donation.  Why not now?

Salient points, in order of increasing importance*:

(1) XFM’s browser detection is correct

(2) XFM understands that codecs are the stumbling block in streaming media, not browsers or operating systems

(3) XFM understands that a variety of apps are available and that I could have one that works

:.  XFM doesn’t tell me whether or not my computer can play the stream, it lets me decide and press the “play” button.

[* - Note: maybe (2) and (3) should be reversed....]

The trouble is that tagging the build N.0 leads users to think that the release is a tested, stable, and finished project, when evidently it isn’t. That raises a secondary question about whether (a) 4.0 was meant to be stable and finished, but was just released with some flaws, or (b) what we call 4.0 should have been named something else, like 3.99 or 4-Preview. Who knows?

The dilemma is unenviable. If the answer to the above question is (a), then it’s a potential disappointment — you have a buggy release. If it’s (b), then you have far less of a story — the non-developer public at large may not be interested in a preview release.

Unfortunately, this release was in a bind brought about by publicity. Once you’ve committed to a release date, you have to go with it. Announcements have been going out for months now inviting the press and the public to release parties around the globe, which would be difficult to push around on the calendar and potentially costly to cancel. And it was already named. Changing the name from 4.0 to 3.999 after the release event was scheduled would sound like a last-minute change of direction (or worse, loss of confidence).

Neither optimal, but at least the second option would have preserved sanity in release naming, and not require any eleventh-hour “that word doesn’t mean what you think it means” revision.
Isn’t it weird how many problems can eventually be boiled down to something as simple as numbers?

It’s been two and a half years since I first wrote about the consequences of poorly selecting your version numbers, yet so many people still haven’t learned to anticipate the inevitable problems. Which isn’t to suggest that I thought that they would go away, it’s just surprising to see that people are still surprised by the same old problems.

It’s gone now, of course. But it was fun while it lasted. Ironically, the worst part was parenthetically attached to the same paragraph, in which he matter-of-factly said that these days everyone agrees that F-Spot is the bee’s knees of image management. Well, that’s just not true.

F-Spot is barely more useful than the back of a sticky note when it comes to managing your images. Image management for grown-ups is about the image metadata, and the only metadata that F-Spot thinks about are tags. Yikes.

Tags are a Web2.0 fad (hopefully soon to die in obscurity!) that have the unique distinction of growing less and less useful the more you use them. They don’t scale, they have zero context, and they’re all nonhierarchically equivalent.

Could you manage your digital music collection solely by creation date and tags? Not hardly.

I’ve worked as a photographer in two different contexts: in-house and freelance. Pros manage their photos with metadata-aware, smart tools like Extensis Portfolio and ACDSee. If you think that home users don’t have the same needs as pros, look forward one year. A year from now you’ll have twice as many images to keep track of as you have today. Pros’ problems are the same as home users’ problems, just a few years (or even months) ahead.

The frustrating thing is that there aren’t any Linux apps that intelligently manage photos. For a while there was imgSeek, but development of it seems to have stopped. What I’d really like to know is how hard-core Blender users do their digital asset management — it’s much the same as photos; different metadata in part of course. What do the troopers behind Elephant’s Dream and Peach use to keep track of the countless 3-D blends?

For a more detailed explanation of why this is hilarious, read either an analysis of the situation or brush up on some recent background information.

[ed. note: this doesn't mean that De Icaza's observations are incorrect, only that they are funny]

Yet in the real article, the Digg discussion, and via this blog’s comment form, a number of people are independently saying that I should have included LinuxMCE among the contestants.  Several of them are assuming that LinuxMCE’s absence means that I’ve never heard of it, which is of course untrue and an altogether different set of misunderstandings.

But the truth is that I didn’t include LinuxMCE in the comparison because it’s not the same kind of product, and therefore it’s simply not relevant to the MythTV distro roundup. It includes a bunch of other packages for disparate activities like Asterisk phone service and “home automation.” Those tasks have nothing to do with running a DVR — which, as I stated in the intro paragraph, was the point.

Lumping it in with the MythTV distros would be comparing apples to oranges, which is both unfair to people with either preference and pretty much entirely pointless.

And I don’t mean “unfair” as in “LinuxMCE would obviously come out on top, because it does so much more.” Frankly I think LinuxMCE would have fared quite poorly at the task, since I don’t want to run Asterisk or home automation from my set-top box, and doing so would degrade system performance.  You can install any vanilla Linux distro these days and include MythTV, Asterisk, a bunch of X10 utilities, and metric boatloads of other server stuff, too.  That system would take LinuxMCE to school on the feature front.

But so what? If you want a dedicated MythTV system, there are people catering to that exact need: MythBuntu, KnoppMyth, and MythDora.  More power to you if you have different requirements and LinuxMCE suits your needs.  But it is distinctive enough that when it gets stable, it should be reviewed on its own merits, not as part of a roundup of like tools.