|MoriGTD||Comment | Log in | Print | Subscribe to this page|
Mori is an excellent outliner/notebook/PIM for the Macintosh that I used some time ago to implement a flavor of David Allen's Getting Things Done personal management system (GTD). This is a legacy page about my Mori GTD implementation that may be helpful to current Mori users. There have been several approaches to GTD using Mori, notably a plugin written by Jeff (BMEguy) that is really slick and includes excellent support for repeating events (the files and a video are linked from the Mori Users Guide).
Of course, variety is great and GTD is meant to be flexible, so I implemented my own system in Mori that emphasizes some features I like. I'm not a Cocoa coder, so there's no plugin, but there is a bit of shamelessly borrowed and lightly edited Applescript. I've described my approach below along with a bit of commentary about Mori and GTD, in case some of these ideas might be useful to others. Some familiarity with GTD concepts would be helpful, but hopefully not required, to follow the discussion. This isn't a guide to GTD, though, so I mention but don't fully describe basic GTD activities like processing the Inbox or triaging items between actions, "maybes," and reference.
Download: Mori GTD Notebook 2007-03-06.zip contains a commented notebook with folders and smart folders set up, and Applescripts for inserting context into entries, archiving and printing checklists.
The basic layout of folders is shown in the screen shot to the right. There is an Inbox, Next Actions folder, and folders for daily and weekly review, which are common GTD artifacts that I'll return to in detail further on. I have a separate Active Agendas folder, which I'll also describe below. The Single Tasks folder holds individual tasks or errands that aren't attached to a project. Most of the content is in the Projects folder, which is shown expanded. Finally, there is a Possibilities folder (usually called "Someday/Maybe" in GTD lingo), an Archive and a Reference folder. There are two user-defined data columns, Context (text) and Archive Date (date). Archive Date normally doesn't display. The displayed columns are Label, Title, Context and Due Date.
In usual GTD style, the Inbox folder receives snippets and ideas through the day which get organized, or "processed," at review time. In Mori 1.6 (released April 2007), copied or selected text from other applications can be quickly directed to new Inbox entries via either the dock menu or a system service, if Mori is running in the background with an open Notebook. The Inbox and its processing are usually one of the most important parts of GTD, and tasks are typically considered to come through the Inbox before they're matched up with their projects during the processing step. In my case, the Inbox is less important than usual because much of my task generation occurs during project planning (more below).
The Projects folder contains a set of subfolders that represent projects containing multiple tasks. This is a fairly flat list--I try to avoid grouping projects together in a folder when, for example, they are related by administrative unit or some other quality and I also try to avoid large subprojects. David Allen recommends keeping the project list flat, even if it is very long. After some experience I've come to the conclusion he's right. Dealing with the increase in structural complexity that comes with expanding the hierarchy outweighs the decrease in visual complexity at the top levels. I'll order projects so that related ones are neighbors and I'll occasionally use small subprojects within main projects, but for the most part I like all the projects visible at the same level even if that means scrolling.
One of GTD's most important qualities for me revolves around its lightweight approach to project management. I do creative work myself, I collaborate with others in doing creative work, I have staff that report to me for supervision, I report to several people up the administrative chain and I have students. The working environment is interrupt-driven and projects are constantly shuffled between front and back burners based on needs, schedules, resource availability, etc. Standard project management software and Gantt charts have never worked well for me in this changing environment. The GTD approach of managing multiple to-do lists (one per project), specifying next actions for each project, and merging the next actions into a single list to work from for task selection was a revelation to me and it really fits my planning needs. Others have called this a "multidimentional to-do list," referring to its project, context and temporal (next action) dimensions. In my implementation, most of the tasks are generated during daily project review (rather than coming through the Inbox), and each project has a list of to-do items leading into the future as far as is reasonable. These lists of to-dos are revised each day, including the selection of items that will appear as Next Actions.
The notes of the project folders themselves provide a hub for links to resources in file system folders and particular useful files, as well as containing current notes about the project. Each project has a file system folder on the hard drive for files (PDF, presentations, word processing, data) and a link to this file system folder is in the project folder's note text. Links to other Mori or file system folders and particularly important files can also be included here, as well as reminders, commentary and all sorts of other floating project information, essentially creating a control panel for each project that is distinct from the items contained by the project folder. The availability of the project folder note text as a project information hub that displays immediately as soon as the project is selected is unique to Mori; trying to do this with a text/RTF file mixed into the folder with tasks and other files is considerably more awkward and one of the key drawbacks for programs like Journler and DEVONthink as compared with Mori.
Mori isn't perfect, though. Embedding a link into the note text is more awkward than it should be--just dragging the document or folder to the note area should create a link named for the document (as in Journler or VoodooPad). There should be a preference to turn off link underlining to improve readability. There could be some creative things done related to displaying linked documents or folders as entries rather than only embedded in notes text, which would also allow interesting approaches to annotating linked documents
The items contained by the project folders include tasks at various stages of their lifecycle, informational notes (I may start putting these in a subfolder routinely but for now they're mixed with the tasks), and an Archive folder that receives completed tasks and notes that are no longer current (the approach to archiving is described below).
Tasks are generally created during project review or as a result of Inbox processing. They have four states: anticipated action, next action, waiting and completed. The states are indicated by the color labels, blue, green, yellow and gray, respectively (indicated by the colored dots in the screen shot above). I've also considered a red for emergency but haven't really found a good use for it (by definition, emergencies are generally known and don't need reminders). I haven't thought of any other useful states, though there are other colors available. Color labels work well as state indicators because you can change them easily using a popup list on the label column and they don't take up very much room in the display (though they're quite visible). It would be even better if you could edit the text associated with the color labels in the popup menu (I believe Jeff's mGTD plugin supports this). I don't use the traditional checkbox for "completed," since it seems like just another state in the task lifecycle to me and I can save a column by using a color to indicate complete. This approach differs a bit from mGTD, which uses textual abbreviations and a checkbox to represent these states. That approach has benefits but I tend to like this as having less friction in use (just a quick click to change) and saving space.
Tasks are usually created as an anticipated action some time before they become next actions, and the list of the (blue-labeled) anticipated actions in the Project folder provides a rough overview of the near-term project plan and order of tasks. As part of the daily review of projects, next actions are selected (labels changed to green), allowing those tasks to appear in the Next Actions smart folder. If a task needs to wait or must be delegated, its label is changed to yellow and it appears in the Waiting smart folder. When a task is completed, it's label is changed to gray and it is swept up in the archival process (below).
Tasks are also tagged with a context (in a user-defined data column) in the usual GTD style, which is related to the location, necessary resources, time/energy or other requirements for carrying out the task. Contexts allow tasks that cannot be carried out in a particular setting to be ignored. In my implementation, contexts are set by selecting one or more task entries and choosing the Applescript from the script/context menu named for the context (below left). These are simple scripts that drop their name into the context column (just duplicate the context script as many times as you have contexts, and name the scripts for your contexts). There is also a due date column for deadlines which allows deadlines to be tracked and those tasks to be selected for display in a folder of dated tasks.
Agendas (above right) are a special type of context that are useful for repeating meetings with particular people or groups. Putting a task on an agenda for a meeting means that the list of all tasks across all projects that are labeled with that agenda can be displayed easily in preparation for a meeting. These are legitimate contexts--they are conditions (the meeting) required to carry out specific tasks, but because they're specialized to meetings it's useful for me to separate them into their own category of contexts.
Tasks and notes labeled in gray are archived by the "Move completed to archive" Applescript in the script menu (see menu shots above). Generally this is done daily, as part of the daily review. The script moves all items in the "Current Completed Tasks" smart folder (this is a list of all the items labeled in gray, located in the Daily Review folder, see below) to Archive folders within their project folder (creating an Archive folder at that level if necessary). As part of the move, the label is set to none and the user column "Archive Date" is set to the current date (this is not displayed). The result of this is that completed project items are accessible in the project's own Archive folder. In the main Archive folder at the top level there is a smart folder that contains all items that have Archive Dates, irrespective of their projects, which can be sorted or searched. When projects are fully completed, their folders are moved manually into the main Archive folder.
During daily work, items are captured to the Inbox for future processing and tasks are selected from the Next Actions smart folder for attention (the first two lines in the sources pane, in the first screen shot and the screen shot below). The notebook also supports daily and weekly review (the third and fourth lines in the sources pane, expanded in the screenshot below.
The Daily and Weekly Review folders (right) aggregate information to support those standard GTD reviews. Mori's notes for the folders themselves are convenient to use to display a list of the steps in the review. In addition to managing information contained in Mori, the daily review outline shown here includes items like checking and printing my calendar, which is part of the review but outside of Mori.
The tools for the daily review (expanded to the right and also shown in the entries pane) include a smart folder containing all the Active dated tasks from the oldest (including past dates) to the most distant future tasks in chronological order. This normally will show upcoming tasks. I like this approach better than a limited folder for "upcoming this week" because it lets me see the closest tasks at the top, but I can also scan out to the future as far as I want. This functions similarly to the 43 dated folders in some GTD implementations.
Next, there is an alias of the Next Actions smart folder for review, a Waiting smart folder that contains all yellow-labeled tasks, and a Current completed tasks smart folder that contains all tasks labeled in gray. The latter will, at this point in the review, contain the completed tasks for the previous day for inspection prior to archiving. After completed tasks are reviewed, the archive script would normally be run to set up the notebook for the new day. The next steps are to process the contents of the Inbox (an alias is provided), review and manage the contents of the Single Tasks folder and review and manage the individual project to do lists (discussed above under Managing Projects and Task Lifecycle). The daily review may also include a scan through the "Read-Review" folder, which is another standard GTD artifact. I implement Read-Review as a folder in the computer's file system with a link from the daily review outline rather than as a folder in the Mori notebook. It's typically full of PDF and Powerpoint files, Web archives and links to web sites, which I think are best managed in a regular folder. Ideally, I'd like to drag the next items to review into the entry pane, have them appear as link entries, and give them a green label. But for now I just drop in a task entry and put a link to the appropriate files in its text.
Many GTD implementations have separate smart folders for the various contexts. I haven't found these to be useful. When I plan tasks, I need to be in the projects view and I label next tasks in that view. When I'm choosing and carrying out tasks I'm in the Next Actions folder, which mixes contexts. I generally sort next actions by context and that has provided enough separation for me to focus on the correct contexts. I do have separate folders for Agendas (expanded above) because that's where tasks specific to particular meetings are aggregated from multiple projects, and it makes sense to isolate them from each other and the standard work contexts.
The Weekly Review folder (expanded above) includes a smart folder containing all Recent and future dated items (uncompleted dated items and dated items completed in the last week), a smart folder containing all Recent completed items in the last two weeks, an alias to the Possiblities folder, and a smart folder containing a list of Projects needing review (see below). These items, as well as several non-Mori items listed in the weekly review outline in the folder notes, are part of a the standard GTD weekly review.
Tracking project reviews
GTD reviews can be time-consuming, particularly the daily project reviews. In some cases it may not be reasonable or desirable to review all projects at once, and less active projects might be reviewed on a reduced schedule--but they would need to be tracked so they don't slip through the cracks. One way to handle this might be to schedule a project's next review with a dated task each time it was reviewed. I'm also playing around with tracking last modified dates, archive dates and/or project review dates, and alerting if projects age without changes, similar to NetNewsWire's approach with RSS feeds that don't change. In Mori 1.6, project folders can be tagged with one or more days of the week, and an Applescript or smart folders can assemble the set of projects due for review on a particular day. To my knowledge, none of the available GTD programs handles this issue particularly well.
I'm reasonably pleased with how this has turned out. It's relatively streamlined and attractive for me to use. Of the available systems, it seems to support the spirit of GTD (including the intended flexibility of the system) better than other software packages. It handles tasks about as well as dedicated GTD software, while providing a much better environment for both project notes and task notes than, for example, programs like iGTD, Actiontastic, or What ToDo. There is some friction in how Mori works, particularly in linking to files and folders on disk, capturing data into Mori, and needing Applescript (or something like iSnip) and a trip to the menu or keyboard to support entry of list elements into data columns (contexts and agendas)--a popup menu with a strategy for menu dividers would be nice--but overall it works quite well. The Applescripts need some error trapping to deal gracefully with all conditions, though this hasn't been a problem in routine use. The mGTD plugin provides some nice additional features (naming color labels--if I remember correctly--and solid handling of recurring tasks among others) at the expense of additional data columns and indicating task state with text abbreviations (the most recent version also uses colored labels, btw). If anyone is interested and there are questions about the notebook structure, I'd be happy to respond in the Mori forums. An annotated Mori notebook set up like mine is downloadable near the top of this page and from the Mori forums, and the download also includes the Applescripts, though they really are pretty simple and mostly edits of scripts available for Mori already.
|This page was last edited 8 years ago by harrison.||View page history|