Tag: workflow

More good stuff:

The prerelease version of Automator currently comes with 123 Actions that are grouped into categories according to function. The categories include Mail, Find, Alert, People, and iPod, and users can search for Actions using Tiger’s standard Mac OS X search field. The alternate view command groups the Actions by keyword, which can be a quick way to narrow down the choice when searching for a particular Action. The set of Actions offered to developers is not restricted to Apple’s own applications: currently it includes Actions included for Microsoft Corp.’s PowerPoint presentation software.

So the taxonomy is not organized for the user based on application but rather on typical work tasks (for home users, that is–Apple’s primary audience). As it should be.

A few posts ago I mentioned that Apple’s new Automator tool was a potentially interesting development vis-a-vis workflow learning. Well, a new article at MacWorld surfaces this fascinating additional tidbit:

With the Automator, you don’t have to write a single line of code; instead, you build a flow chart. On the left side of the Automator’s window, you can pick from a large collection of “actions” organized into 16 categories–Apple is supplying more than 100 actions, and developers can add even more for their own apps–which you drag into the Workflow area. As you drag items in, they connect to one another. By building up a series of actions, you can create a complex series of tasks that incorporate several different Mac programs.

In essence, Apple is creating a workflow taxonomy. It will be interesting to see how this develops.

The evolution of workflow learning follows the evolution of workflow automation. The reason is that, in order for workflow learning to…er…work, there has to be a way to look into the software system and find out what events are happening in the context of a pre-defined workflow. These are exactly the same things that you need for workflow automation to work as well, and while I suppose that in principle software could evolve to support learning before it supports automation, the truth is that there is bigger money in automation and therefore automation leads. (Teaching somebody how to perform a task in real-time is a great money saver, but making that person unnecessary to perform the task is an even bigger money saver.)

So. Apple and Microsoft both have automation scripting technologies. For Apple it’s Applescript. For Microsoft the choice isn’t as obvious. The clearest contender would be VBA, and Microsoft now has a new technology due out in its forthcoming Longhorn OS called “Monad.” (For a long and geeky explanation of Monad, check out this MSDN video show and fast forward to about 45 minutes into the program.) The existence of these technologies means that each OS is exposing ways for users (or, at least, developers) to find out what is going on in a process and manipulate it.

The thing is, in order for the vision of workflow learning to come to full fruition, you need for individual knowledge workers (ugh, I hate that term) to be able to access that information and influence the workflow (or at least comment on it) peer-to-peer. Remember, the goal we’re after is some magical emergent moment when we’re all flying the plane together in real-time. So having information about ongoing workflows exposed to the geeks isn’t good enough; we need workflow access “For the Rest of Us”.

Enter Mac OS X 10.4, the upcoming version to be released in the first half of next year. It’s visual scripting of workflows. And it’s simple and beautiful. Basically, Apple has exposed workflow events for just about anyone to understand and use. To see a demo of this technology, go to http://www.apple.com/quicktime/qtv/wwdc04/ and fast-forward to about an hour and twenty-five minutes into the show. It’s a fairly small step from this demo to the notion of triggering peer-to-peer contextual commenting and support systems.