In “A Feature Request for Apple Mailâ€, Jochen Wolters talks about introducing workflows into Mail.app. I think this is an interesting idea, but it doesn’t go far enough. Mail may be the app where many of us organize most of our administrivia, but it isn’t the only one. Apple should give better exposure to the excellent metadata system it created for OS X 10.4, and make projects and workflows canned datatypes in it. Apple is already taking baby steps in this direction with the to-do service built into the future version of Mail
How would this work?
Let’s take a typical translation job for me. It may involve four or five e-mail messages, a couple PDFs, and a couple of Word documents; if I wanted to get really organized, I’d add an item to my calendar showing the deadline. These are all disparate types of data managed through different applications, but they’re all related. Every job goes through a few stages (some of which are often skipped): inquired, estimated, accepted, underway, completed, invoiced, paid. Different activities may have different workflows (I’d need a completely different workflow for my fire-equipment business). So I need to A) define general types of projects and the steps of a workflow associated with each one; B) conveniently set up new projects and indicate their project types to pipeline them into a specific workflow; C) conveniently associate messages, files, etc, with a project; D) view and change the state for each workflow. It needs to be dead-easy: the marginal effort to assign a message to a project rather than just skip to the next message needs to be vanishingly small. I imagine hitting a magic key that pops up a list of active projects to choose from (with the option to create a new one); if any text is selected, a new project is created with that text as the title.
Mail Tags permits something like this, after a fashion, but only within the world of Mail.app. This might be enough if you’re content to use mail as a PIM, but I’m not (and it would get ugly trying to deal with files, and Mail Tags does not currently work with IMAP as described in that article). What I’m describing would need to be a system-level feature that was exposed in mail messages, setfile dialog boxes, the Finder, etc.
Projects could be viewed through the Finder, like smart folders. The viewing window for mail messages could include a banner showing a menu of pending projects to select from; once a message was assigned to a project, a row of buttons would be used to show and change state (this could also appear in the Finder window for the project).
Update: After doing a little more noodling on this, I’ve come up with the following bezel displays
The three would not all appear at once. I envision that for an unassigned file, the magic key would bring up the first; if the user selects “New Project…†it transitions to the second; pressing the space bar would flip it to the third. For a file that has been assigned to a project already, it would go directly to the third. Those aspects of the workflow setup that couldn’t be controlled through this interface would probably be handled through a preference pane. The bezel would act on whatever document window is foremost.
At a basic level, there’s almost nothing in the data model for this that couldn’t be handled through OS X’s existing metadata constructs; the one thing that could not be would be a table associating project with project type/workflow. And so there’s no reason a third-party developer couldn’t do this right now. At a more advanced level, ideally there would be hooks added that would tie project-related events to other events, for example, when the mail client is foremost, setting a project on a message might close that message and move to the next. In MS Word, saving a file with no project would bring up the project-assignment bezel.
In fact, there’s already a program, SpotMeta, that lets users create enumerated types of metadata and apply them to files. As clever as it is, it’s a little clunky to use, and doesn’t have a straightforward way of working with mail messages, iCal events, etc (though technically, it could work with them).
Dealing with items that have been tagged with a project and workflow state could mostly be handled through smart folders in the Finder, in Mail, etc. Ideally there would be some kind of universal viewer (most likely hacked onto the Finder) that could show the contents of all the various datatypes corralled into a workflow.
Entourage has a notion of “Projects” that will group messages, events, contacts, and tasks into groups w/ spiffy workspace-style summary views. You can use rules to automatically route messages into the project views.
It’s a bit clunky to try to manually add messages to projects, though. Also, if you try to define your projects in the GTD way (every outcome that has more than one task), then you suddenly have a very cumbersome set of projects to try to manage – i.e. it doesn’t scale very well.
The critical plugin for mail.app for me is Mail Act-on, which gives you customizable and quick keyboard shortcuts to do any number of complicated tasks with your inbound menu (`a = archive, `k = send to kinkless gtd, ‘c = send to ical, etc etc.)
Yeah, I envision an interface similar to Mail Act-on for part of it, but that’s only one piece of the puzzle. The problem with using Entourage is that, well, you’re using Entourage.
[quote]Mail Tags does not currently work with IMAP as described in that article[/quote]
That has recently been addressed in our latest version now in public beta. Can be found at http://www.indev.ca/MT2Beta.html
No bezil displays (yet) but Desk Lamp will allow you to assign projects and keywords to your documents and search them with any spotlight app. It even intergrates with MailTags so you can share metadata beteen them.
Adam:
Adding workflow support right into the OS sounds very cool indeed, and it’d be the next logical step after throwing in the system-wide to-do service. The way you describe it, reminds me a bit of the venerable Claris Organizer, which allowed linking between contacts, notes, appointements, to-do’s etc. via a simple contextual menu. It’s weird that, at least to my knowledge, no other app has implemented this in the same straight-forward and intuitive manner.
What made me write up that blog post you refer to, though, was that I would like to see workflows to things well beyond connecting data items and assigning a project state. It’s about what the workflow does: to use an example from your mock-up, as soon as you set a project to “completed,” the workflow should automatically create an invoice email, using the data linked to that project for adding customer contact details, a list of the work done, pricing info, etc. As soon as you have proof-read it in Mail and sent it off, Mail should then tell the workflow to advance the project state to “Invoiced.”
In other words, a workflow that lists the steps within that workflow and tracks a project’s status and associated data is neat. But being able to hand off all the administrative and maintenance overhead — all those annoying repetitive tasks in iCal, Mail, etc. that are required to actually step through the workflow — to a flexible system based on AppleScript/Automator would take this stuff to a truly new level, IMHO.
GreetinX,
Jochen.
Jochen–you’re right. That would be more useful. I wonder if there would be a way to make it so that “things happen” within the framework I described.
If you attached a script (or more likely, a script alias) to a project, so that its state changed along with the other files in the project, it could occasionally interrogate itself for its own state and take appropriate action.
Though admittedly that only takes care of the “if state, then action” formula, and does nothing to solve “if action, then state.” Not sure how that would be handled.
Adam:
How about assuming an event-driven model in which the state of a project can only be changed as reaction to an action being performed (let’s consider manually setting the state of a project an action, as well).
In that case, any time an action is performed, an event would be sent to the project, causing it to check whether all requirements for advancing its state within the given project/workflow have been met, and update the state accordingly. Which, in turn, could trigger more actions.
I guess that implementing the underlying architecture shouldn’t be all that hard (Cocoa’s delegate mechanisms come in real handy here); it’s the user-friendly UI that’s the main challenge.
N.B.: If I were using a proper “follow-up blog comments” workflow, I’d have replied earlier. ;)