Synergy for Tasks
To-Do List/Tasks was one of the four core apps to have a dedicated button under Palm OS. Yet its analog under webOS was not reworked using the Synergy idea of presenting data from different back ends with a common UI.
There is value in keeping a to-do list for oneself, but much greater value in tracking tasks performed by a team – what has been done, what needs to be done, when it is due, who's responsible for what. Most groupware supports some form of task list management. Properly implemented and used, it increases productivity by reducing the number of phone calls, e-mails and meetings required. These services are more than simple to-do lists; they are the working face of modern project management.
Accessing groupware from handheld devices increases its value – project plans can be reviewed and updated during a meeting (without requiring workers to have and bring distracting laptops), indeed any time people are away from their work stations: case study With full-time access to groupware, project plans become living documents.
Synergy: A Prime Differentiator of webOS
WebOS users praise the way it handles contacts and calendars, using Palm Synergy. Pulling the disparate elements of users' lives together has been one of the biggest selling points of webOS. Yet the user experience has not been consistently compelling. Jon Stokes of Ars Technica wrote one of the best thought-out reviews of the Pre on its launch (Ars Reviews the Palm Pre, part 1: the BlackBerry killer), but bailed out six months later, in part because webOS apps were largely clients for single cloud services – there was nothing compellingly different about the experience for him (RIP Palm: it’s over, and here’s why). He could access cloud services just as well from an Android phone.
webOS Task List Managers
Many users bemoaned the lack of a decent built-in task list manager, finding the existing Tasks application too simplistic for their needs. Some reviews of webOS devices found the built-in Tasks application adequate for their needs, but none cite it as a reason to switch to webOS. Existing third-party task list managers had some traction – reviews in the App Catalog often praise them in comparison to the built-in Tasks application. Outline Tracker Free made Computerworld's list of (“10 must-have free webOS Apps”). The application “To Do Classic” was popular, despite having essentially the same feature set as the built-in Tasks application.
However, almost no task list managers were included in the lists of must-have paid apps being blogged during Palm's Summer Half Off sale. The best-selling task list manager in the Palm Hot Apps promotion, Outline Tracker, placed around #52. Just under 20,000 users downloaded Outline Tracker Free (as of the start of July 2010). Using estimates of the total number of webOS devices sold, this is perhaps 2% of the user base.
Task management did not become key functionality for the average webOS user.
Proposal: Synergy for Tasks
I propose that Tasks be reworked using Synergy. DB8 would hold tasks from various back-ends, all inheriting from a common task type. The new Tasks app would display a unified view - users could see their in-house tasks from Outlook in the same view as client-related tasks from Basecamp.
We would need to harmonize the differences between Google Tasks, Done!, Trello, Basecamp, etc. by developing a paradigm which allows the user a single interface to all of them. Any task app has two main controls: one which controls *which* tasks appear, and one which controls *what order* they appear in.
Controlling Which Tasks Appear
A data model in which each task has zero or more "tags" (and tags can be added at any time) can encompass most paradigms. Tag names are one or a few words.
To-do-list-based apps, such as webOS Tasks, allow the user to display the tasks from one list. This can be generalized by treating the list name as a "tag". When the user selects the list name from a list of "tags", the list items are displayed, as they match the "tag".
Apps based on David Allen's "Getting Things Done" system allow displaying the user's set of tasks by "context" or "location". Contexts can be directly modeled as tags.
For backends that use the VTODO format, the CATEGORIES field maps directly to tags. For compatibility, tags could not contain commas.
Additional tags can also be generated. Project-based systems would add a tag for the project name. The account name or task source would also be a tag, allowing selection of all your Google Tasks, for example.
A key point is that tags can "mean" different different things. Some tags could be to-do list names, while others are GTD contexts and still others are "project" names. The Tasks app wouldn't care - the user selects a tag from the list of all tags, and the app displays tasks that match.
A beginning user can assign a single tag to each task, and treat it like a bunch of to-do lists. If he later adds multiple tags to slice up his tasks differently, he doesn't need to copy his tasks to a different system.
Controlling the Order
Many task apps have a concept of "priority" or "importance". Any system with two, three, four, five, six, ten or twelve levels can be mapped to a 60-level scale - and back again. Thus, harmonized tasks would have a priority on a 60-level scale. Tasks with no priority would be mapped to the middle value. The UI should probably be a range control, as that works the same no matter how many steps the scale has. (And any scale is just an approximation of the real world.)
Sometimes the desired order is by Due Date. (The DUE field for VTODO.) Some systems also support a Start Date. (The DTSTART field for VTODO.) Harmonized tasks would support both of these, but the user wouldn't be required to use them.
Alternatively, the user may wish to order tasks herself. Thus, harmonized tasks would store a custom ordering.
A popup list selecting between these alternatives (much like the webOS Tasks app) should meet most users' needs
Fields for other common properties, such as location, should be standardized, whether or not app makes use of them. Connectors can, of course, set prefixed properties to allow round-tripping all data for their backend model.
A Connector would need to be written for each back end. Like Calendar, there's no need to de-dupe tasks from different sources, so each Connector would map data from the backend into the harmonized format. In particular, each Connector would need to assign appropriate tags for incoming data, and map tags to appropriate backend data structures.
Since Connectors are much less code than full-blown apps, it's feasible to write a connector for a service that is not primarily a to-do app (for example, GitHub or ChiliProject). While each such "specialty" Connector might not have a large number of users, the relative ease of writing a connector means there could be many such Connectors.
Complementing the Connectors would be a service allowing any app to create a task, with user consent. (Analogous to the API for creating a Contact: Add Contact
A task may arrive on a user's plate from a number of sources (“inboxes” in GTD terms): e-mail, instant messaging, phone, in person, a meeting, or a project review. A task from the real world requires the user to type it in, but digital sources should not. The easiest typing is none at all.
Many times, receipt of an e-mail should generate a task. If users can only cut and paste the text of an e-mail, it arrives in the task list manager as an undigested blob. Metadata, such as the sender, is lost. There is no way for a task list manager to automatically assign metadata such as due date, nor to tag a task depending on which e-mail account it was sent to. Email apps could use the API to create tasks with pre-filled tags. The e-mail app knows about e-mails, so it is best positioned to create a task from an e-mail. Likewise, the phone app could inject tasks pre-populated with contact information.
- [Apps could also create Reminders from emails, IMs and phone calls]
This also provides a low-annoyance mechanism to prod users to perform system maintenance, such as installing updates, setting up backups, triaging full storage, etc.
The Create Task API can also have fields to allow "backlinks". Tap a button in a task created from an email, and the email app opens to that email. Tap a button in a task created from a phone call, and the dialer open, ready to phone that person.
Universal Search ("Just Type") on a single task pool has a cleaner and more consistent user interface. Associated code need only be written once.
Extending Synergy to Tasks is implementable and would help make LuneOS a compelling alternative.