I am Sal Soghoian; I'm the product manager for the Automation Technologies at Apple. My title is something that is constantly morphing over the last ten years of me being at the Mother Ship. It's always going to be product manager for Apple Script. Because that's what I started off in 1997. And I'm also Product Manager for Animator, and Product Manager for Scripting Bridge, and product manager for -- a couple other things that you'll know about eventually.

And -- so -- they had to come up with something. And what does Phil call me? The Scripting Guy? The scripting guru. And Steve calls me "Saul, who y'all know." So the new title kind of takes it all in, into a nice little compact thing of Product Manager, Automation Technologies. Sounds real familiar. So this session is about automation.

And it's about our vision of automation on the platform, how we've evolved, and where we're going, and where we think the tools that we want to provide for you should go as well. And it's also about you. We really implemented this session -- it wasn't part of the original plan -- but we got so much feedback that we added this session for you, so that you could tell us what you need.

You could tell us whether our plans and insights are accurate. Are they going to serve your purposes for what you have to do with automation. And if are we going in the right direction. So what you're going to see I'm going give an overview basically about the automation technologies that we have.

Well, how they work together, what's the big picture. And then I'm going have some gentlemen come up on stage with me and we're going to answer your questions and listen to your feedback. Good, and blistering, both. With much relish and resolve. So any questions so far? Okay. Let's begin. Let's start with AppleScript.

Now AppleScript is the premier scripting language for Mac OS X. It is the native scripting language for Mac OS X. It's been around since 1992. I feel like I've lived every part of that. And it's a tremendous technology and lots of companies use it to automate what we do. Lots of individuals, lots of professionals use AppleScript and rely on it every day. And we love it at Apple, it's just getting better and better. So let's look at some of the thing that's we've done with AppleScript for Leopard.

It's plumbing. Every so often you get those operating system releases where you don't see the glorious frosting features or candles. We really just go in and, like, tear out walls and fix plumbing and fix wiring. And this is one of those releases where we really wanted to get in and lay the foundation for AppleScript to move forward. And there were a lot of things sitting there that had to be done that weren't done. So we really focused on some issues that we think are glamorous, but a lot of you might not. But you consider essential.

First of all, 64-bit support fdor AppleScript. A necessity if we want to keep living on the platform going forward. But you won't see any difference between what you're doing today with AppleScript and with 64-bit. There's many languages and improvements in the scripting frameworks. The Cocoa scripting frameworks got a lot of revving this year. And in this operating system release.

And that enabled us to accomplish some pretty interesting and powerful things. And it solved a lot of bug issues for our customers as well. Mark Picciareli covered it in detail in his session a couple days ago -- or was it yesterday. I can't remember any more. It's all one code-blur.

That's good -- code-blur. And so scripting frameworks have been revved considerably. We'll look at that. And finally, Unicode support. With AppleScript, it's a long time of having to coerce string types back and forth, and then getting caught in all kinds of little weird details about working with text. And now we've introduced complete Unicode support, so it makes it a lot easier.

And I'll start with that. So Unicode support in AppleScript is complete. It -- all the text is considered Unicode. Any kind of operations you perform on text, like, concatonating them together it -- in Unicode. And you can also use this architecture to translate between certain characters. So if you want the smiley-face guy character you can actually say, I want Unicode I.D., 9787, and you'll get this character. So this is a really important thing for people that work with text and AppleScript. And we're very glad that its finally there. Let's see, Unicode was, what, four years ago or something? So, it's here.

64-bit support enables us to move AppleScript forward to where we want to go. And we want to move it forward every year and every release. But we had to put this in there so that we could be part of the operating system and get done what we needed to. Most of AppleScript will remain the same for the way you use it. There are a couple of APIs that are going to be changing and they're listed there.

And for the updated scripting frameworks, quite a bit was done, especially around SDEFs. SDEFs is the way -- it's the mechanism for defining what a scripting dictionary is. And it's been modernized and it's made dynamic now. It supports dynamic SDEFs, as well as some hidden attributes, some synonym elements as well.

And there's new APIs inside of it. So that you can -- it's almost like a little plug-in architecture where you can introduce better descriptions, links to other data, code samples can all now be part of your dictionary using the new S def. And it's really helped make things so much better for the scripter. Because you want to find out the information you want to find out. You're in the middle of writing a script. You want the dictionary to provide you with as much data as it possibly can. And this really does modernize that procedure.

And then we've had a little bit of a problem with error sensing and error handling since we moved over to Mac OS X. Basically we haven't had any. And -- and it's been fixed now. In Leopard. You might notice it when you would get an error and it would be something like NS receiver -- blick-black blick-black blick-black -- for -- well that's all been fixed now.

So we have this example here. Where I'm asking Xcode to get the name of the front document and if there's no front document, this is what you used to get. See, isn't that lovely? Receiver evaluation, script error, and then four. Doesn't know what it means. But now in Leopard that's been fixed and corrected so that you actually get back something that's telling you, hey, Document 1, it's an invalid index. There is no Document 1.

- We go for cheap applause. We don't care. I am totally shameless. I have no morality whatsoever, right? I'm a Product Manager.

Did I say that? Okay. I work for you though. Don't get me started. Okay. So that's a real available thing to have so that you can actually figure out what's going wrong with your script. And we're sorry it took so long. But the main thing is we've never given up on this technology. We've never given up advancing it. We love it, we believe in it. It's going to be with us for a long, long, long time.

Now we have some new things. We didn't, you know, just do plumbing. We did add a couple new things that you've been asking for. And here's one in particular that I love. This is something I really enjoy. Coming from the background of being a scripter for a dozen years or so -- 15, 16 years -- I always would write scripts for different people and you put the script on their machine, and they tell you, well, it's asking for where Quartz -- gik-gik gik-gik -- is. And if they had renamed the application they couldn't find it, and there were all kinds of problems with trying to get scripts to run correctly in a generic way. Well, we have a new application object model that goes a long way to solving this problem.

So you can -- instead of just saying, tell application aperture, or tell application mail -- you can now use these other ways to address the application. For example, you can address if you know where the application is, you can address it by a POSIX path. Tell application, slash, application slash mail dot app. And it will talk -- your script will compile, and the script will execute based on where the application is. You can also now talk to an application. You can direct your commands to an application by the application's bundle identifier. And by its four-character code.

Don't encourage me, I'm telling you. Which is really great. Because, you know, it's just so much better. This way you don't have to worry about the language, you don't have to worry about how they named the file or anything. You just say, com dot Apple dot mail, or the four character code of e-mail. Whatever one you want to use. And that's really great. So this kind of solves the problems that we've had about making sure that your scripts compile. And that you can put them in your applications with the knowledge that they're actually going to work under most situations.

Now, in addition to this, we've added a couple more intrinsic properties that work hand in hand with this to make it a little bit easier for you to write scripts that work. And so you can get the version of an application just by asking for the version. You can get the I.D. of an application or its bundle identifier by asking for that.

And you can also see if the application is running, and if it's the front most application by just asking if application Mail is front most, then do this. Otherwise, launch Mail. Or if application mail is running, do this, otherwise launch Mail. So no more sub-routines trying to figure out if an application is running using system events, and parsing four-character I.D.s. It's a simple statement now. Which is the way AppleScript works.

You like that one? Please don't throw something. Okay now this is what the commands would look like when you use them. You can see in the little purple area, that's exactly what they look like. Very useful stuff. I guess if there's one word for this release, it's useful.

Now something people have been asking for forever, is the ability to read and write property lists. We added the ability to read -- are you going to do it again?

These guys did the work. I'm just taking the glory here. So we introduced in Tiger the ability to read property lists.

But if you actually wanted to write them back you could to go to a do shell command and use the default framework to get that done. No more. We now have the ability to actually generate property lists on the fly, go in, alternative their properties, create new properties, that kind of stuff. So you won't have to use the do shell script any more. You can write files that work with your scripts, you can put them in your own bundle, you can write them to user prefs, wherever you want to be. It's a great thing to have.

And we -- this is very important -- we have updated documentation. The documentation --

Thanks to Steve. We have current documentation that will be current with Leopard, which is wonderful of the so you will finally be able to have a reference point to go to.

See, we're really trying to lay the foundation here. We're putting down the roadway, we're laying down the asphalt, we're doing the concrete, the whole thing correctly. My hero is the guy who replaced that span over there that burned down. So if we can be that good, it would be wonderful.

So let's review. For AppleScript you have fully integrated unit code support, 64-bit updated scripting frameworks, enhanced application object model, isn't that great? Read write Mac OS X property lists, more reliable folder actions. I didn't have time to get into that. But yes, it has its own little process now, and it's running from the file system so it should be much more reliable for you. Especially on modern volumes.

Current documentation, and some extras that I didn't get to mention. In the script editor we now have a string compression command. It's in the preferences. And what that does is if you have a lot of text in your scripts and they're taking up this much space and you want them to take up this much space, you set that bit and it collapses all the tabs and returns down into slash R, slash T. So you get a nice little block of text like this in your script.

There's also -- Image Events now has a pad color property. We had the ability to pad, but we couldn't do anything but black. And a lot of people said, duh. And we said, oh. Pad color property. It's in there. And there are lots of new scriptable items within the operating system, including the dock, the network system preference pane, and accounts. And you'll see applications like iChat that are robustly scriptable with your own event handlers now. So there's a lot going on for AppleScript in Leopard. We love the technology. It's really moving forward. That's AppleScript.

Great.

But we can't accumulate more time. And the only way you get time is automation. Automation gives you back some time. Whether you waste it watching the automation run, that's up to you. But -- but automation is our vision. So we have to figure out a way in order to spread that around.

Because as good as AppleScript is, it is just one language. It's one set of individuals. It's one kind of scope. And we have so much more in the operating system that could take advantage of Apple events. It could take advantage of really nicely scriptable applications. And so we had to figure out a way to do this. And some very clever minds, nodding your way, came up with the idea behind Scripting Bridge.

So the current AppleEvent APIs, if you wanted to write an Apple event in your code you could use some application control with NS Apple event descriptor, you could run scripts with NS AppleScript. And you could edit scriptings by using the OSA kit. That was your current options. Let's take a look at them. So if you want to send an Apple event between your app and somebody else's app you could write an NS Apple event descriptor.

Yeah. It's fast and efficient, but you know, it's complicated. You have to know the four character codes for your app and for the other guy's app, and they're not published anywhere. And you have to figure those things out. But it is a very fast code. But it's difficult.

You could use NS AppleScript, which is pretty simple. It's basically you take a string, an then you run the string using the scripting architecture. I mean, that's it. But it's really hard to scale that. It takes longer to execute because it has to load a bunch of resources into memory. And it doesn't scale well, like I said.

So it works, but it's not always the best. Plus you have to know how to write AppleScript anyway because that string that you're putting in there is AppleScript. Right? So that's your opportunity. Now in Leopard we introduce this new thing called the Scripting Bridge. And it's fast, efficient, and simple.

And the way you do it is, the first step is, you use a little command line utility that generates some header files. And this is what basically the command line looks like for generating this header file for iTunes. You add your header files to your projects, link the Scripting Bridge to your framework and then you start using it. It's really -- there is no step three. That's basically it. And so with this, you can get an attribute, set an attribute, get an element, create an element, call a command -- those kinds of things -- right from within your code.

Now let's take a look at the Scripting Bridge code for multiple languages. It's not only for Objective-C, but it's also for other languages in the operating system that are popular with developers. So what does it take to get the name of the current iTunes track? What am I playing there? I didn't even look. Oh. Okay good.

Talking Heads. That's all right.

Always got to remember to check your slides before you put them on the air, right? So this is what using Scripting Bridge -- it would look like to get the name of the current track in Objective-C. And you can see you're basically doing some imports, you're importing your header file in the Scripting Bridge framework. And then you have this call here and it -- you're basically instantiating it, an then making a call for the current track. Not bad. If you want to use Python, you could use -- the Scripting Bridge with Python, which isPyObjC, and do the same kind of thing.

Send an Apple event over to iTunes and get back the response. You can also do it using Ruby Cocoa. And you could also, you know, do it without Scripting Bridge, which is the old NS AppleScript, or you could do the whole thing in AppleScript as well. So you could use any of those. Your coding options now are AppleScript, Ruby, Python, Objective-C, all of those things you can use because of the Scripting Bridge.

So this really makes it easier for developers of normal, native Mac OS X applications and Web applications to create Apple events and send them back and forth. And what does that give you? That gives you inner connectivity between different applications and a wonderful user experience for customers That's what this is all about.

It enables you to tie on to other applications. Go to other sources within the system. Because the system is built upon Apple events. And that will never go away in Mac OS X. It's our messaging architecture. And now using Scripting Bridge all this is exposed to you in a language that you're comfortable writing.

And you can mix and match. So what does this mean for AppleScript and for developers? What does the Scripting Bridge mean? Well, once upon a time there was a group of, like, tough play dough guys, right? And these guys dreamed about and talked about writing AppleScript and having scriptable applications, you know? That's what's on their mind all the time.

So these guys you know, were trying to evangelize and trying to evangelize, because they knew the power of automation. They saw it every day in their lives. They saw what it did for people. They saw what it did for their customers. It gave them speed, accuracy, consistency. It was scaleable. They loved it. And they were trying to get developers to make their app scriptable, which is the number one problem facing automation. Get me good, scriptable applications. But the problem was these guys were all alone.

So by creating the Scripting Bridge they were joined by the guys who write Objective-C, and they were joined by of the guys that write Ruby, and they were joined by the guys that write Python. And soon there was enough of them that developers started paying attention to the idea of automation, and the idea of scriptability, and making their apps Apple-event aware.

So this is a good thing for non only AppleScript, but for the entire OS. Greater access for all languages deliver some real benefits. More scriptable applications, better quality scripting dictionaries, and more creative workflow solutions. Because all the languages can work together around the magic of the S def, and the miracle -- the absolute miracle of Technote 21O6.

That's the real power of Mac OS X is in the fact of the integration that this operating system has. That's its strength, that's its power. You know, it's almost like a country where you have lots of different people living in it and they're very creative and they're crazy, but lots of stuff gets done. Well, that's the way it is here. So this is good for everybody.

Especially -- you're going see more scriptable apps, like those from the Omni Group, like those more scriptable apps, yes, from Apple Computer. Especially in Xcode. Did you see the scriptable that they put in Xcode 3 with that environment thing in there, you can drag scripts and work flows in? Ooh! That is powerful. And you can key assign. So you can sit there going tick tick tick tick tick tick ah -- then grab a donut, man. It's great. And Adobe has excellent scriptability in their applications too. And so does Microsoft. Microsoft's really getting into scriptability.

So the story because of Scripting Bridge and because of what we're doing now in Leopard, the story of automation in developers and scriptability is really going to take a giant step forward this year. So what's -- what's -- what's going to happen with these guys? Nothing but good. And if I had to make a forecast, I'd say that scriptability is going to go this way in 2008.

Golf clap? Okay.

Speaking of Microsoft, here's a little side story. So you know Microsoft Office, the new Office that's coming out? Well, for years Microsoft has used this language as its means of controlling its suite of tools, Visual Basic. Well, they're dropping Visual Basic and on the Mac they're going with AppleScript and Automator and will be shipping with AppleScript support and Automator support built in for their products.

And as a matter of fact, they sponsored a special issue with Mac Tech that's about 150 page article detailing step by step how to convert VB to AppleScript from Paul Berkowitz. I think you might find it interesting. Just a little side note and an idea about the kinds of things that are going to be happening for automation on the Mac platform this year. So that's Scripting Bridge.

Now Automator. Automator is a one of a kind tool. And when we introduced it in Tiger it was well received, a lot of people liked it. We won an Eddy for Best Productivity Software, which was really great and we appreciate it. And the idea behind Automator was to create a tool that normal people could put together steps like a recipe and have that recipe do something for them on the computer.

You could take -- so our vision was to take chunks of functional code and put them in these wrappers called actions. And the actions could have a little bit of UI where the customer could set the parameters in the particular code source. And that you could drag these actions together into this thing called a workflow and then execute that. And it's been very, very successful. But it's had some initial limitations because, you know, it was a 1.0 product. We got it out there and it worked good, but it needed some more advancing. And in Leopard we've really matured the product considerably.

You might notice this because Auto -- that's Otto -- we're on the Web site. We're on the Apple Leopard Web site. Yes, we are the feature numbered 17. We're the last feature on the page. But hey, we're on the page. That means that there's 283 other features that aren't on the page.

Which means, hey, we're in the top 6 percent of features for Leopard. You see how marketing works, it's really tricky stuff. You've got to stay away from it. So let's take a look at some of the features in the new Automator that are really going to advance this whole concept of automation and provide you with a set of tools that are going to take you in some surprising and interesting places over the next year.

The first is that we have, like, Starting Points. It's kind of a workflow assistant. One of the problems that people often have is they just don't know how to do that first workflow. They don't know how -- well, how do I get started with this? I heard this so many times over the last year. How do I get started with Automator. I tried it.

It didn't work. So we created this thing called Starting Points. And it's really like a step by step little tool that guides you through the process of getting started with a workflow. And it looks like this. When you open up a new Automator document the sheet drops down and you have different categories of workflow area. Like you have a custom, which just creates a blank work folder. But you have files, folder, music, audio, photos, and images.

So if you select one of those there's a couple pop ups. It tells you what it does and then it says well, where's your content coming from? So you could choose -- well, I want it to come from my computer's camera. Okay, then what do you want to do with this? Well, take my picture when the workflow runs. And then when you click choose, it inserts the appropriate action already set up for you.

So that's a really nice, handy device to get you started in work flows. And you'll find that a lot of those things can just be accomplished by answering some simple questions. And then when you get the hang of it, it makes it easier to turn off. The thing.

The feature. Yes, that's true. So you have categories, files, folder, music, audio, photos, images, text. And you use custom to bypass, or you can disable this once you're up and running with Automator. You can disable it from the application menu. That's the first feature. The next feature. We streamlined the interface considerably.

You can get to the things that you want to access, the bit of information that controls much quicker, much easier in this version of Automator 2 than prior. And let's take a look at some of the things. So here's your basic workflow window. One of the things you'll notice right away is that on the left-hand side we no longer group by application.

People don't know what application is responsible for doing something. They want to do something with photos so you click on, like, the photos category, and then all of the actions, regardless of application, are displayed there. Because it makes a lot more sense to go by categories like this than it did by just working on a single application.

But there are also smart folders there that you can search by certain parameters and location by actions, like what is the most relevant, what are the ones I just added. And you can create your own folders and put your favorite set of actions in them as well so that they're always a click away to get to the actions you need to create your workflow.

And all of our little views now are pop in, pop out, or slide in, slide out. So you can slide out the description field and slide it back in by clicking a little button down here at the bottom left right there, and that will send that in and out. The same applies for the log.

The log now pops in from the bottom by clicking the log button. Prior, it was like this thing that hid down underneath the doc And you could never get to it. So now it makes it easy to see what's going on with your workflow as the workflow is progressing.

And there's also a new pop in field for the variables. And this is a table that contains the name of the variable and then whatever value it has. Any variables used by the workflow will appear in this view. And I will talk about them in just a second.

Also, we have a built in Media Picker. You can see that it's accessed from the top left of the tool bar. And this allows you to use the media that's on your computer. Whether it's aperture, iPhoto, iTunes, or movies, if you need to get stuff and bring it into your workflow there's now a built in Media picker, which is great.

And if you want to hide the library completely, there's a control in the top left for doing that as well. So window management now in Automator is much better, much quicker, much easier, and much smoother to get at the information that you need. Well, we took this same idea that we worked on with the window and we encapsulated that as well into the Automator actions. So here's an -- excuse me -- here's an action called scale images. And what it does is it takes image files that are passed to it and scales it in some kind of format that you've decided upon.

Now once it's been used, if you want to see the results of that action you used to have to drag another action called view results, find it, and then drag it in after it. Now we've put a series of data accessors here at the bottom, you see results, option, and description. So if you click the results, you can see the results of that particular action's last run.

In this case, it scaled a group of images, so there are the images, the thumbnails of the images that it scaled. Now you can view that particular results data in a variety of ways too. You can view it as a list or paths to the files that were processed. And you can also view it as a list of AppleScript alias references to the images that were processed. And all of this is right there under that little command within the action. You don't have to add anything else. The information you need is right there.

Next to it is another little gel called options. And one of the things that's really great about Automator is you can make it a generic workflow by presenting some of the action UI during the workflow execution. And you do that by selecting the check box that says show this action when the workflow runs.

And to get at that, it's now just a simple click away. There's no disclosure triangles necessary. And finally, if you want some information about the action, if you want a description about how to use it and what it is, you no longer have to select it and go down to the bottom of the window. The description for the action is right in its own view. So all of this information is right there for you. It's quick, easy to get to all the times you need.

It's a new streamlined interface for Automator Next, workflow variables. Now this is where we really start upping the power. You know, one of the nice things about the Animator is its simple to use. You drag some images in, you select a scale thing, you do this -- you run, it's done, you can save it and -- but you can never really customize it. For example, it was hard to try to get the files named a certain way. Or I want the current date attached to a file name. Or I want it to use this folder instead of the one that's on the pop up.

But I'm not sure what that folder would be on the other user's machine. So it was harder to generalize work flows with the first generation of Automator. And now using workflow variables, it allows you to create variables and use them throughout the workflow, and the information gets passed from action to action.

Let's take a look. You reuse this information throughout the workflow, and you can also use it to generate things like paths, user information, system information. So current IP address to the machine. Users dot Mac name, users last name, that kind of stuff can be generated so that the work flows you create and use in your applications will work on multiple machines regardless of how the user has them set up.

Now workflow variables are scattered throughout the entire interface. They're always just a simple drag away. So let's look at some of the places. There's a new gel here at the top left that's right next to actions. Actions -- if you click the actions gel you see all the actions in the application. If you click the variables gel, you see all the variables that are installed in Automator as well.

And on the left-hand side underneath that you can see the different categories of variables. There's date and time, location, system tech data, utilities, user information, that kind of thing. And when you select a particular category here at locations, you can see that the variables for them appear in this column to the right.

Some of the variables have the little gear meaning they're smart variables. They generate data based upon a certain parameter. And some of them are customizable, and some of them are empty and you could use them yourself, like the new path variable there with the blue V. You could indicate your own path and use that in the workflow.

Variables when used within actions can be used on pop up menus, especially those for paths. They can also be used in text fields, as you can see here where the name of the file will be the guest's name, and then today, slash, then today's date. And you can instantiate variables to grab the contents of a variable by just dragging the variable into the workflow area, and you'll see this action called set value of variable. That's mark number four there. So you can use variables right in the workflow.

And as well, you can monitor and edit the variables that are in your workflow that appear in the variable table that I told you about earlier, where you have the various variables and their value is indicated. And you can access that through the little pop up control. And when you select a variable and control-click it, you can pop up its edit window.

This particular variable doesn't have much to edit. But any kind of properties that the variable have will appear in one of these little pop up menus. So workflow variables can really change the way that you use Automator and makes it so much easier to customize things. You can store data in them, you can generate data, runtime, do runtime variables like paths, user information, and system information. So that's workflow variables.

That's a lot, isn't it? It's coming on. Now here's the one that's very popular. It was much requested. What do you do if you're trying to automate an application that doesn't have a scripting dictionary. What do you do if the application has a dictionary but it's missing some things.

What do you do if there's a dialogue that comes up and you have to press a button. Well, we have a new feature in Automator 2, and it's called -- an action called Watch Me Do. And it's basically UI recording and playback, or it acts like a virtual user action. And the way it works is like this.

It does interaction between dialogues and windows, it will control actions that aren't scriptable, and it works like this. So when you press the record button, a new action is included into the workflow. You get this little floating window. When you're done doing what you want, you click the stop button on it and everything that you did is now represented in this new action. This action is self contained. You can save it, put it in your workflow, drag it into another workflow if you want.

In this particular case, this actually works. You can do this on your copy of Leopard. I recorded switching -- using the system preference start up disc and I switched back to my Tiger partition. And I recorded the whole thing. So I made myself just a little double-clickable tool to do that. And when this is run in Automator, you get it playing back everything that you would do by hand. Just like that. Very cool.

Now be aware that not all applications support accessibility equally. That's an ongoing process that's getting better as time goes on. And so just if you do come across a glitch it might not be recordable because of support for accessibility. In which case you can then convince your developer that I really need this. If you're not going to give me this, then give me scripting dictionary. Otherwise I will camp out on your yard and I will never go away.

All right. There's one more thing with Automator that's really the knock out feature. I think it's the hidden feature of this release. And it's called the Automator frameworks. So Automator appeals to the users, whether they're tech geeks, or whether they're normal people, or whether they're your father-in-law. You can create workflows and run workflows and do incredible things with them. We've seen that happen. You can build documents , you can download images, you can process any kind of data that you want.

But can you take advantage of the power of Automator within your own application. You're building an application and you go, wow, I would really like to have that ability in my application as well. But man, the amount of code I would have to write for that is phenomenal. Or you might want to have the ability of Quartz Composer in your application, put the amount of code you would have to write is just too daunting.

There's ways to do that now. We have an Automator framework that has three components. AM Workflow, and AM Workflow controller. These allow you to take an Automator workflow and make it part of your application. So you can have a button in your UI that's attached to an Automator workflow and executes.

You do that with AM Workflow. If you want to pass data into that workflow or change the status of a variable, or insert an action or reorder the actions, then AM Workflow controller will allow you to do that with your installed workflows as well. And then a third component of the Automator frameworks is this thing called AM Workflow view. And it allows you to take the Automator view -- that workflow view that's in Automator -- and put it into your own application UI.

So let's take a quick look at that. Here's run Automator workflow, here's my app. I put a button up in the top left. I want to be able to take a simple video snap shot using the architecture and the operating system. Do I need to learn how to write that code for that particular framework, the video framework? No. I can attach a workflow that contains the take video snap shot action.

And then my user clicks that button, the workflow executes, it brings up the thing, takes the picture, an then gives me the path to the picture that was taken, and then I can put it into my application. I didn't have to write any of the video code or any of the video handlers, or access any of those frameworks. All I did to use AM Workflow to be able to run an Automator action.

It's not so much the applause I was thinking about. It's just what that really is. That is if it's what I think it is, it's dangerous. So AM Workflow view takes this whole idea about incorporating Automator in your app one more step. Can you imagine being able to take this view here out of Automator and move it right into your own application so it becomes part of your UI. Your customers can create their own Automator workflows, save them, open them, edit them, right from within your app. They don't have to leave your application.

And you can choose whether you want your actions to be there, or whether you want, you know, different -- different company's actions, Finder actions in there as well. It's up to you what you want to do with that. But combine all of this power together and now you basically have an application plug-in architecture to the entire operating system with no code writing. In other words, that's it right there.

In other words, if I want to add Quartz Composer into my application, I don't have to write Quartz Composer code, all I have to do is use AM Workflow and AM Workflow controller and I can incorporate an action that has Quartz Composer actions built into it. If I want to have a Media Picker in my application I don't have to write Media Picker code. All I have to do is incorporate AM Workflow to run a workflow that contains choose image or choose photo, or choose movie.

And I get the Media Picker automatically, because Automator handles it. As a matter of fact if I want some system services like burning a disc, using Spotlight, using the Finder, and I want those in my app, I don't have to write the code for them. All I have to do is enable running a workflow. As a matter of fact, I can take any third party app that supports Automator actions and have them inside of my own app. Whether it comes from Apple or whether it comes from some other company.

I am -- I can take their knowledge and their expertise and make it part of the experience that my customers have on my application. It's a plug-in framework that's extremely powerful and it's all about automation. It's all about letting your customers about what they want. Because once they start using your application this way, they're never going to leave you.

They're going to stay with you through every revision and everything you do unless you break it. In which case they'll start looking for somebody else. But people don't have enough time. They are going to stay with something that works for them. In America, we say it. If it ain't broke, don't fix it. Once you give them automation, they're yours. You have loyal customers forever. And this is a brand new and exciting way to take automation to the next level.

So Automator in Leopard. We have starting points, a new stream lined interface, workflow variables, UI recording and playback, workflow looping, which I didn't get a chance to get into, dozens, 30 or so new actions, Automator frameworks, that's Automator. So what's the future of automation on Mac OS X? Well, the future's here.

It's in Leopard. All this work that we're doing, the ground work that we're laying, the roads and the pipes that we're laying down and the enabling architectures that we're putting in place with Automator and AppleScript and Scripting Bridge are going to set the pathway for you to take off and start using this.

And delivering it to your customers and taking advantage of it yourself. So as far as I can see, it's going to be a great day. This is going to be a wonderful year. And to listen to what you think I'm going bring some people up here with me to share this experience. Thank you.