Subscribe to RSS Subscribe to Comments

freesoftwhere.org

XFM not smarter than you

 From the XFM Web site:

xfm-player.jpg

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....]

Tomboy for the notify!

tomboy-fail.jpg

Java for the notify!

javaws-more-information

What point what?

So KDE 4.0 is out now, prompting a swarm of disagreements about its purpose. The confusion stems from project members’ simultaneous vaunting and celebration of the release and warning the public that it is a developer-only, development version that they shouldn’t expect to work smoothly — conflicting messages from the same source, and more importantly the source that should present the authoritative message on the release.

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.

Trip down Digital Asset Management Memory Lane

Earlier this week, Eye of GNOME dev Frederico Mena Quintero blogged about EOG and image management. I think EOG is great and all, but the best part of the post was that he reminded me of the now-defunct CompuPic, a pro-level (sort of) photo management app that for a brief period of time a few years ago was available for Linux.

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?

« Previous PageNext Page »

Based on FluidityTheme Redesigned by Kaushal Sheth