Six months on, I owe the world a report on my attempts to implement GTD methodology in a standard calendaring application.  I chose Thunderbird with the Lightning extension,  because it’s cross-platform and because I already use it for so much else (in other words, AXIOM 1: Do Not Be Tied Down To One Device Or Platform, and AXIOM 2: Never Use A Single-Purpose Application When There Is A Flexible Solution).

What I did was this:

1. Created one “remote” calendar for each GTD context, using remote WebDAV storage, since that was available to me through a private domain I host junk on (e.g., webdav.freesoftwhere.org/cal/errands.ics)
2. Created a “Category” for each project
3. Managed my tasks through these lists, as individual VTODO items.

The rationale for (1) was two-fold: I want to be able to access my tasks from any platform that knows VTODO, and on small-form-factor or restricted platforms, I want to be able to see only a subset of the contexts.  For example, in the office, one might want to de-clutter one’s task manager by only viewing the “work” context.  That doesn’t apply to me, because I work from home, but you get the idea. You might also have a phone/mobile device whose task manager can only support a single iCalendar feed, and selectively choose just the “phonecalls” or “errands” context.

I accessed the feeds from Thunderbird/Lightning on Linux and OS X, and attempted — without success — to to so from Maemo and Symbian clients as well.  No editing on the latter platforms, and no actually working VTODO reading on Maemo at all.  There is no Web app support for VTODO in Google Calendar, or other free software web calendar services that I could find (if you know one, drop me a line).  For basic task management, I’ve stuck with it.

What I learned:

• Lightning: adding new categories is a royal pain in Lightning. It requires opening Thunderbird’s Preferences editor.
• Lightning: Lightning exposes noticeably less of the task detail in the main window than it does in the “new task” dialog box (e.g., status and category, but NOT location).  This makes it difficult to make use of these features.
• Lightning: The above also means you must right-click -> edit everything to update status/details, which is a pain if you’re trying to do GTD. GTD requires active task management, not just binary done/notdone lists.
• Lightning: multiple “color” inheritance in the user interface (i.e., from the calendar and from the category) is confusing at best; how to solve that not easy particularly (even in the mythical perfect calendar where you don’t need more than one calendar feed to manage everything)
• Lightning: In Lightning, you cannot simply click to show just one calendar (in this case, remember, that a calendar means a GTD context); instead every calendar you want to NOT see must be un-checked.
• Lightning: The task manager cannot filter what is shown by category, which would be helpful to view all tasks for a particular project.
• Lightning: I cannot figure out what the Tasks -> Calendar menu does while in Task mode; it lists the calendars, but selecting or unselecting them seems to have no effect.
• Lightning: Lightning is just more crash-prone in general for tasks than for calendars.  They’re hard to reproduce; it’s nobody’s fault, just due to fewer users filing fewer bugs.
• VTODO: sharing categories between tasks and events is not a good idea.  My usage of categories as GTD projects can sometimes cause overlaps, but projects are transient.  The GTD principle of only tracking actual appointments as calendar events almost always uses broad, permanent categories (”home”, “work”, “church”, “school”).  Mixing is confusing.
• VTODO: “due date” does not work real well for the GTD principle of next-action sorting, nor does “priority.”

In addition, I realized a few things about the way I use iCalendar-based calendars in general:

• I must use a separate feed for calendar and tasks, because nobody implements both of them correctly.
• I pretty much use Google Calendar solely for the email/SMS alerts.
• people use multiple “calendars” primarily for the ability to do color-coding. That is a UI issue which *should* be available as categories: one calendar for “Appointments” should be enough.
• most desktop task managers and mobile device task managers do not care about iCalendar/VTODO at all. Instead, they try to reinvent the wheel, which sucks.

On the latter point, I fully recognize that every GTD user is different, and the system is meant to be customized to the way you work.  But there are half a dozen “todo” managers for Linux that offer nothing beyond simple lists of items that you can cross off — like Tasque, Gto-do, Tasks, and so on.  Maybe a lot of people need those, but I don’t think it’s accurate to call what they do task management.  Task management is active, and it involves detail.  VTODO provides for that; it enables you to keep track of partial progress, categorize and sort what you need to do.  It has a real data model behind it.

The lightweight apps would better be described as checklist managers.  I don’t see that they provide any functionality beyond what is available in a simple notepad app like Tomboy or Gnote.  If you need that, that’s fine.  People need list management, it’s great for grocery shopping. But I want task management to be better than that.  That’s why I undertook GTD, and that’s why I tried to implement it in VTODO.

VTODO is probably always going to be the neglected sibling of VEVENT.  Probably better off than VFREEBUSY and VJOURNAL (seriously, I still can’t figure out what good the latter’s supposed to be), but supported secondarily.  In thinking about how hard it is to find a decent VTODO client, I realize I’m not forging new territory.  The same is probably true for any published standard.  It’s just that I see people attempting to reinvent the wheel a lot regarding to-do list apps, rather than even attempting to tackle it.  Which is a shame if there are already iCalendar parsing libraries out there — which there are.

Supporting RDS-TMC in any free software OS or app requires libraries to read and decode the data, and hardware that supports it.  The latter is the first topic of new info; it seems as though the Nokia N900 phone’s built-in FM receiver supports RDS.  That’s excellent news, as Maemo is the most open, just-like-desktop-Linux phone platform and has a developer community that’s one-hundred-and-crazy-percent motivated.

I’ve also stumbled upon a developer who is working on FM RDS support at codeplex; he is writing Windows code though.  The base library is http://www.codeplex.com/FM  and he is blogging about it as well.  Unfortunately, the code is only available under the Microsoft Public License (MsPL), which means it cannot be reused inside GPL’ed libs or applications.  But at least there’s knowledge.

Obviously, with HTC (ie Android) and Maemo devices supporting RDS generally, there are great possibilities for basic RDS usage, like having the FM tuner show RDS song info… supposedly Martin Grimme’s fmradio Maemo app  does read RDS data, but I haven’t found it to work for any of my local stations (this is not a bug report, though — it could easily just be my lousy stations).  Reading the Python code makes it look really straightforward, but it’s not immediately usable by other apps.  Which I care about because the more interesting possibility to me is RDS-TMC on these platforms.

Sources of data

That brings me to the next subject for update: a polished RDS-TMC stack with supported hardware still needs a live, broadcasting source of TMC information.  I’m having a great deal of trouble tracking down accurate info on TMC FM broadcasts in North America.

The Wikipedia entry has been updated several times since my last post, but is thin on references — and how lame is it that Wikipedia is my best source of information?  Allegedly “INRIX,” Navteq Traffic, Clear Channel and Tele Atlas all broadcast FM TMC … somewhere.  Where exactly is not specified.  Even the Navteq Traffic wiki page lists a few big cities, but without an external reference.

Worse, the suggestion is that commercial TMC broadcasts are often encrypted in one way or another.  And you guessed it, there is little in the way of public information about that….

License compatibility of data

An even bigger  problem, however, is the legality of using TMC data.  The trouble hinges on the fact that TMC messages use location tables to compactly encode where events are happening, and the location tables are not available for free.  Then again, it also hinges on the fact that private companies like Navteq Traffic collect the road sensor data and sell that as a service to the people who actually broadcast the FM signal.

In the long run, there is at least a possible workaround for the TMC location table nastiness: TomTom has started an open source location referencing project called OpenLR.  I wrote about it in September.

As I mentioned last time, there are also alternative methods to grab rough traffic information, such as Floating Car Data aggregated by GPS-equipped cars and phones. I still don’t think there’s a free software project collecting that info.

The End!  I know I’m only barely scratching the surface of this subject; it’s way outside my usual beat so I’m doing a lot of lernin along the way.  Comments welcome.

For one thing, this behavior is almost always prompted by the user attempting to quit the app (such as with the “X” button), so it’s incorrect. Quitting is the “common case;” the common case should be fast, and should be consistent across the desktop.  When I click the “X” on Thunderbird or EOG, the window/app quits.  So when an update release of Rhythmbox decides that *it* will no longer quit, but simply minimize to the tray on “X,” it is breaking the convention and detracting from the consistency of the desktop.  Tenfold more annoying when the behavior appears in one release without warning.

But the second and more fundamental complaint I have is that there is no advantage to minimizing to the notification area.   There, each app is represented by a single icon.  In the default GNOME panel’s window list, each app gets its icon and the window name if space is available. That’s right, IF.  There is no space saved by minimizing to icon-only form, because the extra text of the app/window name is only displayed if the required space is free.  The other notification-area-icon uses (displaying a blink on activity, popping up a message) are also available to the app when minimized to the window list.  I frequently “check my messages” by glancing at the window list to see if the window name has changed (e.g., Inbox (32), Facebook (New message from CrazyDudeFromHS!)).

In other words, minimizing to an icon in the notification area just needs to go, period.  There are certainly use cases for apps needing to live only in the notification area (such as Update Manager alerts), but for interactive user applications, there’s no case, and no benefit.

3-D movies mess with those independent senses; if there is shallow depth-of-field, we can look at part of the image and it stays out of focus, but still feels 3-D because of depth cues caused by the high-tech magic of the imagery.  If there is deep focus, we don’t have that screwyness, but we’re limited to the odd camera lenses  (often wide-angle) that produce deep focus, or very peculiar lighting to cater to the more stringent aperture requirements.  Either way, that stops looking natural after a few hours.  Citizen Kane is all peculiar photography, but you can’t watch everything shot that way.

In short, I guess you can count me among those who really thinks 3-D  “looks cool” to the eye because it’s so UNnatural.  So it’s novel, yes, and impressive, perhaps, but I’ve never thought it made anything look better.

Is this possible?  I’d like to create a mouse-deformable elastic SVG image.  In other words, the user can click anywhere inside the image and drag the mouse around, and in response the object(s) underneath the cursor would be stretched in the direction of mouse movement, as if they were rubber sheets.  The clincher is elasticity — I’d like the distorted objects to animate back to their original shape on mouseUp or loss of focus.

I’ve been reading up on SVG animation docs last night and this morning, but I haven’t found any actual examples that come close to what I’m talking about.  Most of the tutorial sites deal with primitives (and justifiably so, of course), and this concept clearly involves  different stuff … restoring original positions of the nodes, etc.  Got any help?

Thx!

Which got me to thinking about real-time traffic data.  The situation is exactly like the pre-OSM map situation: the “data” is public and free, and consumers have to pay to see it because there is no free alternative.  Ripe for change.

It’s a complicated subject, but in broad strokes there are two major ways to determine traffic information: listen to public Traffic Message Channel (TMC) information on the radio, and aggregate individual user motion culled from participating GPS devices on-the-road.

TMC is a form of Radio Data System (RDS) broadcast and is a published standard. RDS is a sideband of FM radio, and is also used to broadcast song titles by participating FM stations, emergency alerts, and a few other information types. The trouble is that so few devices pay attention to the RDS channel — only a handful of car radios do, and expensive in-vehicle navigation systems do, and that is about it. So the free RDS-TMC data is flowing right past all of us, doing no good.

Making use of it means getting it into the computer, and that seems to have some prerequisites: first, an FM tuner; second, that FM tuner must provide raw access to the antenna, not something hardware-converted directly into a stereo audio stream; third, something to decode the RDS-TMC data stream itself; and fourth, a database to look up the highly-abbreviated hexadecimal TMC messages and convert them into useful stuff like place names.

As near as I can tell, there is exactly one GPL software package capable of reading RDS: srdsd. Unfortunately, it is built to be hooked up to external tuning equipment, perhaps because the authors are as interested in RDS encoding as decoding. There are a few hardware adapters out there specific to RDS, bluetooth and USB, but they are all from one company, GNS, and naturally there are not free drivers. So the big question is how many FM tuners in Linux boxes can actually receive RDS signals?

Scratch that; a better question is how many FM tuners in cell phones can receive RDS signals? Supposedly many can, and suposedly many GPS devices are also capable of RDS decoding, but so far I have not turned up a definitive list.  Apparently some HTC devices can, because there is a shareware project to support them. The Dash Express and TomTom dashtop devices have RDS-TMC built-in or available as add-ons.

Anyway, to sum up, here is what I think would be required to build a crowd-sourced free traffic data source: daemons running on mobile (or desktop) devices that receive RDS-TMC data from nearby FM transmissions, and report what they hear to the central database. Of course, each device can utilize the local data for its own routing purposes; the aggregation would benefit users who don’t have a device and assist in route planning by showing a broader picture. The good news is that “real time” data here is far slower than with GPS tracking; on the scale of one update every few minutes, let’s say. Stationary devices could participate, too, since relaying the information is helpful to everyone even if you yourself are not on the move.

Unfortunately, I have no idea how many FM or GPS devices are out there that can pick up RDS-TMC, so I can’t even begin to speculate on what the coverage would be like. It would require each device owner to run specialized (albeit unobtrusive) software on their device. The other big option would be to have GPS-capable devices simply phone in their position and speed (anonymously, hopefully), then aggregate that.  Far more devices could participate, no RDS-TMC drivers or decoding needed, but it would still involve widespread participation to provide meaningful traffic updates.

Any thoughts?

The trouble is implementing GTD in software — there are a zillion and a half software solutions, all of which are single-purpose, incompatible with each other, and walled data gardens.  Most are not even cross-platform, nor do they support networked backends, meaning you must keep duplicate copies of your info and worry about syncing it. I’ve learned to dislike such solutions for personal data — I want my personal wiki to be available to me wherever I am, I want my addressbook available on every device where I might need to call, email, or send an IM, etc.  So I don’t want my GTD projects sealed in a single-purpose app on one computer.

I have found a GTD Web app that I like quite a bit: Tracks.  It is free software (of course), it is simple in its interface, and it provides output data in a lot of useful formats — including iCalendar feeds. I can access and update Tracks from desktop Linux, Mac, Blackberry, Maemo, and Symbian platforms — all of which I use regularly. The only trouble is that it produces read-only feeds, meaning it does not integrate into any of the available calendaring apps. That would be too easy.

But more importantly, looking at Tracks got me thinking about how to represent GTD information in a standard format. Since it is essentially calendar scheduling and to-do management on roids, the best fit of any RFC’ed standard is VTODO.  Lots of calendaring apps already support VTODO, although in most it takes a back seat to VCALENDAR.

The question is how to represent GTD’s unique ideas in VTODO. As a refresher, the important concepts in GTD are that you track “next actions” — single-step to-dos that are more easily managed and attacked than large-scale projects.   But you also keep track of projects as a whole, and you sort your next actions by context — at home, in the garage, calls to make, emails to send, etc.

Though individual VTODO tasks are a natural fit for next actions, how to map projects and contexts is not as clear.  VTODO has 33 defined properties (although two of them are mutually exclusive, if I read correctly).  Some are basic (description), some are calendar-like (duration), some computery (geolocation), some Exchange-like but potentially useful (attendees).

The “categories” property seems to be the only real option for GTD incorporation — but is it better used as a “project” field or as a “context” field? Whichever you choose, the other field will have to be represented some other way, perhaps as an iCalendar calendar. That is because VTODO items must belong to an iCalendar; they cannot be separate. Thus you cannot just have a single calendar for all of your GTD items. You could have one calendar for each context, and within it use VTODO “categories” for each project, or you could have one calendar for each project, and use the VTODO category to denote the context associated with the action. Which is better?

At first glance, it seems like one calendar per context is better; contexts are less transient than projects, and if you wanted to make certain contexts available only on certain devices, the calendar subscription method makes that possible.  What doesn’t work so well is that most calendaring apps don’t pay much attention to “categories” support — predefined categories are always trite alternatives like “work” and “birthdays,” you cannot create new categories from within the task manager, you cannot vary display colors on the basis of category, and so on. You are also supposed to be able to assign multiple categories to a VTODO task, but that is also unsupported in the client apps I have tried — Thunderbird, Chandler, Evolution, probably some more….

In fact, as I am typing this entry right now, I’ve discovered that I cannot open and edit existing tasks in Thunderbird/Lightning.  I can right-click and access menus for progress, priority, and calendar, but progress and priority are grayed out.  I certainly can’t change the due date, location, or status.

I guess the ultimate question is why are there so many single-purpose GTD silo apps out there, while our existing calendar applications need so much work on task support. Am I missing something? Is there a killer task-supporting calendar out there?

Just last week, I received an email from Ted Felix, the PhotoCD decoding ninja who did all of the groundwork for the applications I mentioned in the original article. Since the piece has gone into read-only archive mode following the transfer of Linux.com from SourceForge to the Linux Foundation, I’m posting the info Ted sent to me here, instead.

The news is the launch of a new command-line tool called pcdtojpeg. Pcdtojpeg appears to use Ted’s luminance look-up-table (LUT), which correctly converts from .pcd’s weird PhotoYCC color model to standard sRGB without blasting out the highlights. I haven’t used it yet to report on any other fancy features, but it’s good to see work in this area continue.  I only wish it were pcdtotiff….

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