I’ve been reading about GNOME Shell this week, in preparation for GNOME 3.0.  A lot of the UI changes I am ambivalent about (workspaces, for example, I never, ever, ever, use; consequently I could not care less how their behavior changes), some of them I think are great, others I’m not so sure about.  The one I’m most interested in learning more about is the demolition of the Applications menu, because that is the primary interface for launching apps, which are, of course, the things we need to Do Stuff.

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.

Comments(0)

This is a follow-up to my post from a few months ago about mapping GTD concepts to iCalendar.

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.

Comments(0)

I really like the fact that Ubuntu is revamping the GNOME “notification area” because as it stands now, it is a trough that accumulates interface debris.  But aside from the inconsistency, the one use case I don’t understand is minimize-to-tray, in which an application disappears from the window list (ie, usually disappears from the panel), but still lives in an icon.

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.

Comments(0)

I’m busy. And like everyone and his brother (although not my brother), I’ve read David Allen’s Getting Things Done (GTD) and thought about how his organizational theories might line up with the way I work.  If you’re uninitiated, GTD is a collection of methods and tidbits that Allen says are better for keeping your projects organized and your head clear than the old-fashioned alternatives.  It has quite a following, and I like a fair number of the informational nuggets inside.

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?

Comments(0)

Way, way back in aught 7, I wrote this rarely-read piece about the trials of converting the legacy PhotoCD (.pcd) format into something useful on a modern day computing machine.  The principle problem was that since no new files were being produced in .pcd format, the knowledge of how to correctly decode them was slowly beginning to atrophy, even though the spec was open and the source code to tools like ImageMagick was open as well.

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

Comments(0)