Good afternoon. My name is Kerry Hazelgren, and welcome to the last session before the beer bash. We'll try to get you out of here on time, so don't leave early. I'm the Automator Engineering Manager, and today we're gonna talk about building and leveraging Automator Actions. We thought it would be a good idea, since we've got so many new people here at WWDC this year, which is a good thing, to give you a high level overview of what Automator is.

Then we will talk about building Automator actions and later on how you can run Automator workflows in your application. So what is Automator? Well, the most important thing is the name of the robot is Otto. So just remember that. Well, that can sometimes be either repetitive or time consuming, or perhaps it's something that's critical for your job or for your business, something that needs to be done in exactly the same way every time. And maybe there's many steps that are required, and they all done in exactly the same order. Well, Automator is perfect for this sort of thing.

Automator makes it really easy to automate your daily tasks because we've got a simple drag and drop user interface. And it's designed for everybody. So you don't need to know how to script or code in order to create a workflow. If you open up Automator, you'll see a document window that looks something like this. On the right-hand side, we have Automator, or the workflow view. Workflows are composed of actions. And actions are just simple bits of self-defined code that have an input and an output.

To the left of that is the actions library. Automator ships with over 200 actions right out of the box, with many more provided by developers such as yourselves. And we compose or arrange the actions by category, and we have a wide variety of categories that we tailor to, such as music, images, PDF. We even have a documents category, or I'm sorry, a developer category, with actions so that you can create a workflow that will check out your source code, build your Xcode project, and even package it up for distribution. Thank you.

Now, in Letbird, we added some nice new features that I thought I'd quickly go over. The first one is recording. The reason recording is really nice is because there are some applications and services that aren't automatable in any other way because they're not scriptable. So with recording, you can let Automator keep track of your mouse events and keyboard events, and then when you're done, Automator will add this watch me do action to your workflow. That every time it's executed, will replay those events as you perform them. So it's a great new feature for Automator.

The next one is starting points. Pretty much every workflow begins with an action that provides your workflow with data. So what we wanted to do was give you a way to easily identify the type of data that you want to work with in your workflow. And then we take your selection and identify the appropriate action and add it to the workflow. So it's kind of a way to just easily get you started building your workflow. Thank you. The third one is workflow variables. Variables in Automator workflows act just like variables in any computer program. You can use them to store data and retrieve that data at a later time.

Variables in automator workflows can either store and retrieve the data that's flowing through the workflow, or they're often used in conjunction with settings of automator actions, so that simply by changing the value of a variable, you can alter the behavior of that workflow when it runs. So it makes workflows more flexible.

Now, in Snow Leopard, we've added a few things that are important for you to hear. The first one is 64-bit. Now, in conjunction with the whole effort of Snow Leopard to increase performance and streamline things, Automator is 64-bit in Snow Leopard. So if your actions are not built for 64-bit, Automator will not be able to load them. Thank you. Bear in mind that this only applies to Cocoa automator actions. Since AppleScript and ShellScript actions are not compiled binaries, it doesn't apply to them.

The other thing is garbage collection. Now we've taken the step to make Automator garbage collected as well in 64-bit. So your actions also need to support garbage collection, or else Automator will not be able to load them. We thought it would be a good time to take both of those steps at the same time. And while you're adding 64-bit support, go ahead and add garbage collection support.

And then lastly, we've got some new APIs that we'll be talking about. So how does this concern you? Well, we've created a very open system whereby you can create Automator actions for your application. When you do so, you make your application available to new users. They're available in a new and interesting way to them. And when users of Automator are creating their workflows for, say, their critical task.

they may find that your action fills a need that they have in that workflow. And so once you're part of their automated workflow, they'll stick with you. Because once you automate something, you don't ever want to go back to doing it manually. So it's a good way to get new customers and to keep them, hold them hostage, no, keep them as part of their daily workflow. So to talk more about, there's another build there, to talk more about creating Automator actions, I would like to invite up Emilie Kim, our Automator ninja.

and today we're going to talk about building and leveraging Automator Actions. Before we get started, let's first take a look at the big picture and see how all of these fit together. Actions are the foundational building blocks of Automator's technology. Without actions, you wouldn't be able to create workflows. And if you couldn't create workflows, then you wouldn't be able to add functionality to many applications, most importantly, your own application. So that's why today we're going to focus on how to build Automator actions and then what you can do with the workflows that result from those actions. So first, building Automator actions.

What you're going to learn in this part of the session is how Automator Actions work, how they work conceptually, and what they're made out of. Then we'll talk about what's new in Snow Leopard with respect to actions, and then we'll see a demo of how you can actually create your own actions.

What are Automator Actions conceptually? Let's say you had a bunch of pictures and you wanted to make them smaller. An Automator Action might be something like scale images. It does one task and it takes input, which are your first set of images, and then it provides output, which are your smaller images.

So you might say to yourself, that's not very impressive. That's just one thing, scaling images, any photo program could do that. But now let's say you wanna create a, let's say you're here at WWDC and you have these great photos that you took while you were on vacation, and you want to send them to all of your friends who weren't able to come to WWDC just to rub it in their faces.

So you might do something like get a set of actions such as scale your images, rotate them, apply a color filter, and then email them to your friends. Then that way they can see what a great time you're having here. You can kind of think of this workflow as a set of Unix pipes. You have a bunch of commands, and then data flows through them as they would in pipes.

So you take your big images, and you send them through these actions, and then out on the other end, you get an email message that has these pictures as attachments to them. And you can run this workflow over and over again. That's the power behind Automator. And it'll do the exact same thing every time to all of your photos. At least until you don't have any friends left because they think you're a jerk. So.

Now that we know about that, let's talk about how we can make these automator actions. There is a common misconception that automator is simply a front end for AppleScript. If there is one thing you take away from this session, it is that this is false. Automator is not a front end to AppleScript. So the next time you say to someone, oh, yeah, I was at this automator session at WWDC, and they say, oh, really? I thought automator was just a front end for AppleScript. You can say, no, that is not true. Swear to it. So the first kind of automator action you can create is Cocoa. Notice how the word "AppleScript" is nowhere on this slide at all. Cocoa actions are written in Objective-C, and you can take advantage of all the Cocoa frameworks available to you. Now, that being said, you can also create AppleScript actions. And then, last but not least, you can also create actions in any scripting language of your choice. For example, Ruby, Python, or Bash. So now that you know how you can make automator actions, Let's talk about what kinds of applications you can interface with. Actions can be made for anything that provides APIs, such as a framework. You can also interact with anything that has a scripting interface, such as iTunes or iPhoto. Hopefully you all went to the Making Your Application Scriptable session earlier today.

You can also interact with command line tools such as HDI Util to make Automator actions. So now that we know conceptually how Automator actions work and how we can build that make up each Automator action. First, we have source files. Pretty straightforward. Then we have a user interface on top of that. This is how your user sees your technology when you're making Automator actions in Automator. And we also have action properties. So we're going to talk about each one of these in a little bit more detail. First, let's talk about source files. As I already mentioned, there are three different kinds of actions you can make: Cocoa Actions, AppleScript Actions, and ShellScript Actions. These actions can be created in Xcode using templates that we've provided for you. If you create a Cocoa Action, Xcode will create a subclass of AmBundle Action, which is part of the Automator framework, and then your code goes into the runWithInput method. This is the method that gets called when Automator asks your action to run. Likewise, Likewise, if you create an Apple script action, you'll be presented with this on run handler that you can put your code in and this is also what Automator will call. And then if you have a shell script action, you'll be presented with this template file that you can change however you want. So that's source code. We're all developers here, so we don't really need to spend too much time on this. Presumably, you all know how to code already. So let's take a look at the user interface, which we might need a little bit more help with being engineers and developers here. So the user interface. Like Mac OS X applications and like iPhone applications, you also make automator action user interfaces using interface builder. As you can see, you're presented with the standard library that you use for any other UI and you can put any of those in your actions view.

Specifically in the Automator palette, we have two Automator-specific controls. We have first AM token field. As Kerry mentioned in the introduction, in Leopard, we added variable support to Automator. This is how users can add variables to your action to provide a more custom workflow every time they run it. And so you should use this instead of a standard NS text field when adding these controls to your action.

Next, we have ampath popup button. This is a popup button that's been pre-populated with certain common locations on the user system, such as the desktop, the documents folder, or the pictures folder. You should use this popup button when you want to provide location-specific controls in your action, such as copy finder items. Where should you copy them to?

Now that we've talked about a little bit how you can design your actions, and Kerry will show you in more detail in the demo, let's talk about a few guidelines you should follow. First, you should keep it small and simple. This means using small controls and small labels and maintaining a 10 pixel border around all of these.

You also want to follow standard Aqua guidelines, and Interface Builder will help you out with that by showing you these guides in the view in Interface Builder. You also want to provide feedback to your user. Let's say you have an action that populates its pop-up buttons with the names of all the iTunes playlists that the user has. This might take a while, so to do this, you should show a progress indicator in your action to make sure that the user knows your action is still doing something and loading the UI. Another example might be if you had an action that prepended text to the beginning of file names. you should make sure that the user knows what this will look like when they run your action.

To provide more inspiration, you can also look at actions that ship with Automator, and you can also read the Automator programming guide for more details on how to actually design your actions. So, we've talked about source files. We've talked about the user interface. Now let's take a quick look at action properties.

The target inspector of your action project is where you define action properties. This is a front end for the info.plist. Here is where you can define things like your action's name as well as the description, so your user knows what your action is going to do before they actually have to run the action.

You can also define a category so that your action shows up in the right place in the automator's library, as well as keywords, so when the user searches for keywords, your action shows up appropriately. You can also define the parameters here. This is what connects your UI to your code, and Carrie will tell you more about that in the demo, as well as input and output types.

Automator actions have specific input and output types for each action. So for example, if your action only deals with iTunes playlists, then you should set your input and output types to be iTunes playlists so you don't receive something like iPhoto photos in your action. So now that we've talked about all three of the components of Automator actions, let's take a look at what's new in Snow Leopard when it comes to actions.

First, 64-bit. Kerry mentioned that Automator is now 64-bit, so your actions should be also. All you have to do is go to the build settings of your project and change the architectures to be 32-64-bit universal. Likewise with garbage collection, change Objective-C garbage collection to be supported. And again, this only has to do with previously developed Cocoa actions, not AppleScript actions, not ShellScript actions, and not actions that you've created on Snow Leopard.

We've also allowed you to define custom UTIs in your FOP list if you're defining UTIs that are specific to your application, as well as provided you a way to dynamically change the input and output types of your action, and we've provided API to show determinate progress as your action is running. And I'm going to talk about both of those in a little more detail.

First, dynamically changing input and output types of your action. Automator ships with an action called Find Photos in iPhoto. This action has a pop-up in it, so you can find either photos or albums. And then depending on what you choose, the output of the action will be different.

Previously, there was no way for you guys to take advantage of this and create more dynamic and flexible actions. But now we've added API to AM action to let you do this. You can now get the selected input type as well as set the selected input type as well as get the selected output and set the selected output type. Try saying that very quickly.

Also, we've added the API to show determinate progress as your action is running. This provides a great user experience for your users because now they can see, as your action is running, the progress that it's making. So instead of it just being an indeterminate progress indicator, they can actually see that your action is making progress and an expected idea of when it might be done. If you now look in the lower left corner of the action, you'll see that when an action takes advantage of this API, you'll see a determinate progress indicator now. And you should all definitely take advantage of this.

We've added new API to AM action, which is progress value and set progress value, and then we've also made it an Apple scriptable property, so all Apple script actions can also take advantage of this. So we've gone over how Automator actions work, what actions are made out of, and then what's new in Snow Leopard for actions. So now I'm going to bring Carrie up on stage for a quick demo. In this demo, you'll learn how to create an action project. Then Carrie will show you how you can implement the source, design the user interface, as well as set the action properties that we talked about, and then how you can also update your actions for Snow Leopard. So, Kerry? Thank you.

Don't want to get the wrong water. I think she's coming down with a cold, right? Okay, first thing I want to do is create a simple shell script action that will find some images on the system. So when I open, I'll go to Xcode and select new project from the file menu. And you can see on the left hand side here in Xcode 3.1, there are some different categories. And we have a category for Automator Actions. And inside that, we have three different templates, one for each of the different kinds of Automator Actions that you can create. So I'm gonna create a shell script action. And label it, find images.

Okay, so now we get the project and let's look at it. We have a scripts folder here instead of a classes folder. And inside the scripts folder, there is a shell script, an empty shell script. Well, it's mostly empty. We just have a cat command here and we're gonna remove that in favor of some text. Where's my text? Hang on.

There we go. There's my text. We're going to remove that in favor of some text here. And this is just going to run a simple spotlight search for some images in my pictures directory. Now, since I'm just doing this for myself, I'm going to stop there. I'm not going to go any further. I'm just going to build and go. And what this will do is compile the AppleScript action, or the ShellScript action, I should say. I keep perpetuating that AppleScript stereotype. It's going to compile the ShellScript action and launch Automator. Now, since we didn't configure it anymore than we needed to, it's going to appear in the other category. And there it is.

It's called find images. And we have just the default user interface on it. And as you can see down here, we also just have the default description. But that's okay. If we run it, we'll see that it runs. Oh, that's pretty loud. And if we look at the results, we can see that we've got some images here. I thought I had one of a petunia, but that's all right. So this is good enough for me. However, we're going to distribute this action with our application or give it to someone else. We'd want to set it up a little bit more so it looked a little prettier. So I'm going to do that next. Let me close this. Thank you.

And close this project. Now, I have an AppleScript action here called "Convert images to Letterboxd format," which is what it does. And as you can see in the project here, instead of a shell script file, we have an Apple script file. I will come back to that. First thing I want to do is open up the main.nib and connect up my user interface. Now, every action has a parameters dictionary. And so in every nib for every automator action, we have this object controller, which is bound to the parameters dictionary.

of our action. So what I want to do now is connect my user interface element to that object controller so it establishes the Cocoa binding all the way into my project, my actions parameters. Thank you. So I'm gonna select this popup here, and I wanna bind its selected index to the parameters. and set the key path to a key path that I've created called conversion method.

And that's all we need to do with the nib. So it's fairly simple. Just create your user interface, bind it up to your parameters object. And with that, we can save it and close it. Now what I need to do is add the parameter conversion method to the parameters dictionary of my object. And to do that, I'm going to open up the target inspector for my project. This is just a typical target inspector for any Xcode project, except that when you're inspecting an automator action, in the properties pane here, this lower section, as you saw in Emily's slides, is specific to automator actions. And we have a lot of properties here that can be edited, such as the action name, the application and category, which determines where it shows up in the library, and the icon.

There's also some other, if you pop up this pop-up here, there's some other parameters that you can, or settings that you can change, such as the input and output type. And here we've got the action set to an AppleScript alias object dot image. That's a very specific AppleScript type, saying it's an AppleScript object that represents an image. It's always good to have a very specific UTI type for your actions so that Automator can deal with it. So what I wanna do is go to the parameters and add one called conversion method.

And since we bound our popup to the selected index, this needs to be an integer. And I'm going to put a value of zero representing the first item in the popup. Thank you. Okay, so now if we go back to our script, we can open up our AppleScript and see that there is an onRun method. Every AppleScript action has an onRun method. And in this line right here, we can see how we can get the value of our conversion method in the parameters dictionary to, you know, to read that in our script.

So with that, I can build the A action, and it built. And I'm not going to run it just yet, because I've got one more action to work on, and then we'll create a workflow that contains all three of them. Thank you. So I'm gonna close that for now. And I'm going to go to my next action, which is adjust gamma. Now this action was written a few years ago, and it actually ships as an example action in developer examples. The thing we need to do here is update it for Snow Leopard. It's a Cocoa action, so we need to make sure that it builds for 64-bit and has garbage collection support.

So let's just open up our target inspector, or actually our project inspector, and we'll go to the build pane. And right here with this architectures row, what we wanna do is select 32-64-bit universal. And that's all we need to do. Now it'll build two-way, 32-64. And then to add garbage collection support, I find the easiest way is to just search for garbage. If I could spell it right. Garbage. There you go. And what we wanna do is choose supported. Okay, and that's all we need to do there.

Now looking at our source code, you can see now instead of a script, we have class files. If I open up adjustGamma.m, now I wanna add support for determinant progress. In order to do this, it's really easy. I'm just gonna add three lines of code. Okay, at the beginning here, I'm gonna add one line that just sets our progress value to zero, to just initialize our progress value.

Then down here a little bit further, we have a for loop. And this is the one that processes each image that's passed to the action. So sort of at the bottom of this loop here, I'm gonna add two more lines. One of them is just a counter that updates each time through the loop. And the next one just sort of calculates based on that counter, it updates our progress value.

That's all I need to do there. Now, one last thing before I build and go. I need to change from the 10.5 SDK to the 10.6 SDK, because we're using some new Snow Leopard APIs. Okay, with that, we can build and go. And it's gonna compile 32-bit, 64-bit, and launch Automator when it's done.

Okay, as you recall, our first action was in the other category called find images. Our second action was in the photos category called convert images to letterbox format. Now, what Automator is doing here is it's reading a property of that action, the convert images to letterbox format, which says this action performs an irreversible operation on these files, and it suggests that we add a copy finder items action before it to make a copy of the files. So we want to do that. So I click add and it'll add copy finder items and then it'll add our image. Convert images to letterbox format. Now our third image was adjust image gamma. So we're gonna add that. And then lastly, I want to open them in preview.

And I'm just gonna turn up the gamma a little bit 'cause it's kind of a subtle effect and it sort of adjusts the contrast of the image. So now when I run this, pay attention to the progress. You'll see adjust image gamma should have a progress indicator here, a determinant progress indicator. We've also implemented that in copy finder items, but the other ones will show indeterminate progress. So let me run it.

And you can see as it processes, here it's processing these files. and it's gonna open them. And you can see it's really, the gamma's way off, and they're letterbox format, 'cause we've got these mats here on the side. So it worked, and it worked despite the fact that these are three different types of images. They work seamlessly together because Automator knows how to convert image types from one format to another. And with that, I'd like to invite Emily back on stage. Thank you.

Thanks, Kerry. So what did you learn in the demo? Kerry showed you how you can create Automator actions using the templates in Xcode. He also showed you how you can implement the action source, as well as design the user interface and set the action properties. And then he also showed you how you can update your actions for Snow Leopard and take advantage of the new APIs that we've provided for you.

So now that we know how to build actions, let's go over a few simple guidelines for creating actions. First and foremost, keep it simple. If you find your action has five tabs and a tab view, and each tab has its own functionality and its own set of controls, maybe that means your action should actually be five separate actions. Keep in mind, users put actions together to form whatever workflows that they want to create. And so if you provide them more flexibility by providing smaller chunks of your technology, then they would very much appreciate that, and it would make things a lot easier and simple for people to use. You should also follow the published guidelines in the Automator Programming Guide, and you can also use shipping actions in Automator as good examples of what to do when designing your own actions. students.

So back to the big picture. We talked about how you can build Automator actions. And keep in mind that Automator actions are the foundational technology that is behind Automator. With these actions, we've now enabled workflows and workflow support in applications. And so with that, we're gonna talk about adding workflow support specifically to your application.

So leveraging Automator actions, adding workflow support to your application. What you're gonna learn in this part of the session is how you can build workflows and run those workflows in your application. Then we're also going to take a look at the workflow classes that we offer in the Automator framework for you to use so that you can have more control when running workflows in your application. So workflows are everywhere. Not only are they in Automator, but you can also save workflows as standalone applications and distribute them to your family and friends.

You can also find workflows in Xcode's Organizer, as well as plugins in a variety of other applications. And now you can find workflows in your own application. Now, you might be asking yourself, why should I be interested in this? Why is she telling me about this? Well, Automator is an extremely powerful tool. There's so much technology behind it, and now you can harness all of that power and put it in your application. Automator allows you to do rapid feature development for your application. And to give you a concrete example of this, I'm going to give you a little example. problem.

Let's say it's late Friday afternoon. You're about to head home, and your boss comes to you, and he says, man, I've really been playing around with my MacBook, and this EyeSight thing is so cool. Let's add this picture-taking functionality to our application, and I want it before you leave today.

And so you're thinking to yourself, man, tonight I was going to go home, put some bubbles in the bathtub, watch some Battlestar Galactica, and now I have to stay here and do this. You might not even know where to begin. What framework should you be looking at? How should you be doing this? Well, that's where Automator comes to the rescue. All you'd have to do is open up Automator, drag over the take video snapshot action, which does precisely what you want it to do, which is use the eyesight to take pictures, and then save that workflow.

And with just a couple lines of code, you add it to your application, and the feature's done. That's it. So you might be thinking to yourself, that's a little bit too hard to believe. But I'll bring Carrie up in a second just to show you that. So with that example, you can see how Automator now becomes your plug-in development environment. You can pretty much just drag whatever actions you want to form the workflows you want to add the functionality that you need in your application. And now Automator pretty much becomes the new Xcode. You don't even have to type any code. So talk is cheap. I'm going to bring Kerry up for another demo, and he's going to show you how you can create an Automator workflow to do what you want it to do and how you can add features to your application with just a few lines of code and how, in fact, it's so easy that even a manager can do it.

Every year. She's actually being really nice to me this year. You should have seen her last year. Okay. So what I want to do is... If you've been to more than one WWDC, you've probably seen the Sketch application demoed. So we're reusing that. And what I've done is add a workflow to this project. It looks a little weird because Xcode treats... Workflows are stored as document bundles, and Xcode treats every bundle as just nested folders. But if we open it in the finder, with the finder, you can see that this is just a workflow, and it contains the take video snapshot action. Very, very simple workflow. And then what we've done, what I've done, is in the window controller class for this application, I've added this take photo responder method. And as you can see, it's only about seven or eight lines of code. And what it does is it gets a path to the workflow out of the bundle, and then it calls this important line right here, and workflow, run workflow at URL, and it gets a URL from the path with input.

We're not doing anything with input this particular time. And then there's an error parameter. And so it'll run that workflow, and when it's done, it will return the results to our application here, after which I will create a graphic for the document. So let's build and go and see how this works. Okay. Okay, so here's our Sketch whatever application. And in the Tools menu, there is now a Take Photo command. So I want to take a photo. And there we go, we see that the workflow is running. And I can take a picture.

I could add effects to it and everything, but I won't. So when I click set, the workflow will complete running and it will return the path to that document to Sketch. So we can even Sketch on top of it. All right, so you can see it worked just fine. And really, I mean, it was really simple. Seven or eight lines of code is all you needed to add such a nice feature to your application. So with that, Emily?

Congratulations, Carrie. So, what Carrie showed you how you can do is easily create an Automator workflow to add functionality to your application with just a few lines of code. As you can see, Kerry didn't need to know anything about the ImageKit framework, which is what you'd need to know if you wanted to take advantage of the PictureTaker. And so all he had to do was drag out that action and use it in his application, and he was able to do this. However, this is sort of the managerial way of doing things. You saw him using the AM workflow class method to run the workflow. And we're developers here, so we actually want to take a look at the Automator framework.

So the Automator framework is made of three workflow classes. We first have AM workflow. Then we have AM workflow controller. And then finally, we have AM workflow view. These three classes follow the standard model view controller paradigm. And we're going to be talking about each one of these in more detail. First, let's talk about AM workflow. This is the workflow model object, and you load a workflow file, and you can create an AM workflow object.

Carrie already showed you the one-line way of doing it, which is using the amWorkflow class method, run workflow at URL with input error. However, what if you want more control over your workflow? What if you want more control over the actions and which actions are going on? So here we need an amWorkflow object to take advantage of these. So we'd create an NSURL pointing to the workflow on disk, and then we'd give it to amWorkflow to allocate an workflow object from it. Once we have this object, we can do things like set the input for the workflow by calling set input. Likewise, we can also get the output once the workflow is finished running by calling output. Now, you might be asking yourself, well, output happens after the workflow is finished running, so how do I actually run the workflow? That's where amWorkflowController comes in. This is the controller object for workflows, and you can use it to run an amWorkflow as well as implement some delegate methods so that you can provide more control in your application as the workflow is running. To use AIM Workflow Controller, we set up the workflow as usual, and then we create the controller, and then you call setWorkflow on the controller, and then you tell the controller to run, and that's it. It'll run the workflow for you. But if you want more control, like I mentioned earlier with the delegate methods, you need to set the delegate on the controller, and then you'll be able to implement these delegate methods. For example, if you implement workflowControllerDidRun, you'll be able to get the output of the workflow after it's run and do something with that in your application. You could also, for example, notify the user when the workflow is done running. If you implement workflow controller did run action, then as the workflow is running in your application, you could provide a determinate progress indicator to show the user the progress that the workflow is making. Likewise, if you implement workflow controller did error, if something happens to the workflow while it's running, you could notify the user or try to rectify the problem yourself.

So we have AM Workflow and we have AM Workflow Controller, and now we can add all these features to our application. But what if your boss then also said to you, wow, you did that so quickly, now I want you to provide a UI so that users can take advantage of these new features and customize it however they want. Again, Automator comes to save the day, and now let's talk about AM Workflow View. This is the workflow view that's actually in Automator. You can now put this in your application. You can get this view in Interface Builder, so it makes it very easy to use, and you can let the users edit the workflow so that they can customize this feature however they want.

This is what the workflow view looks like in Interface Builder. As you can see, it's also part of the Automator palette. You can also set it up programmatically by creating a workflow view and then setting it on the controller. So... That's AM Workflow, AM Workflow Controller, and AM Workflow View. AM Workflow provides you one line method so that you can run workflows from your application and add features. AM Workflow Controller gives you a little bit more control when you're running workflows in your application, and AM Workflow View allows you to empower your users with customization of your features. So this is great. This is the Automator framework.

And now we can see how this all fits together. We have the actions that we built earlier in this session, and then we can use those actions to create workflows and then use those workflows to put in our applications. Now, we could do a demo then just using the actions that we created earlier and putting them, showing you how they work in an application again, but instead we decided to bring up a third-party developer who's done something so phenomenal with both of these technologies that we just had to show it to you guys. This developer has built their own actions for their application and integrated workflows application to do something that was just so incredible. I couldn't believe it when I first saw it, and I'm sure you guys will be just as impressed. So I'd like to invite Sal Segoyan up on stage to introduce this developer.

Thank you, Emily. We first met Savant Systems a couple conferences ago when they approached us about wanting to integrate Automator into the technologies that they were developing for the home. And since then, what they've done is so impressive. So we wanted to share it with you today, and they've been very kind in agreeing to come down here. And let me tell you a little bit about what they do so that you can better understand it. It has a catchphrase to it called home automation, but it's not quite what you think.

And in the way that adding Mac OS X to a phone really changed the way that the communication industry works, adding Mac OS X to the home has really changed the way that you interact with your house through very innovative Mac-based devices and interfaces like touch panel displays and through multifunction controllers that control different aspects of communication. And even furniture that becomes more than just furniture. It also becomes a way to interact with the environment in your house and to access media and information about your family. And it can also integrate with the phone as well. The new iPhone also provides this kind of integration to do this. And these systems are placed throughout the house in key locations. There's dozens and dozens of zones created in the various rooms of the house involving hundreds of components and hundreds of software utilities. Now, all of this is called home automation, but it's actually so much more. There's media storage and media presentation. There is environmental and lighting controls. There are communications with news, weather, and sports updates. There's monitoring and security systems. All of this coming under this umbrella called home automation.

Now, Savant has addressed each area of this particular technologies using their software called RacePoint Blueprint. and it uses the technologies of Mac OS X like Core Animation and QuickTime and Quartz Composer and Bonjour to accomplish the integration of all of these components with an interface that the customer finds pleasing and inviting and provides them with the functionality that they need. And underneath the entire thing is Automator. So what you're about to see is Michael Silva from Savant Systems is going to give us a demonstration about how their software integrates all this. Michael?

Good afternoon, everyone. This is a real privilege to be invited here by Apple and the Automator team to come and talk about how Savant System uses Automator. We're really excited about the technology in Automator, and it's done some really wonderful things for us. So let's kind of dig right into it.

As Sal mentioned, we have an application called Blueprint. The intent of this application is to allow home systems integrators and systems installers to very easily configure, customize, and, in effect, program our system to accomplish home automation and home control without the need for writing any code on the part of that integrator or installer. So this is the main window for Blueprint, and we have here an example configuration. The first thing that an integrator installer does with Blueprint is organize the components that they will control in the house into rooms or zones. So in this small example configuration, we have a living room with a high-definition display, speakers, and one of our touch panel user interfaces. We also have a bedroom with a television of its own and another user interface. This one happened to be an iPod Touch. And we also have, in this configuration, shared resources. These are usually source devices. In this case, we have a Blu-ray disc player, an Apple TV, and a lighting controller to do lighting control within the house.

I just wanted to give you a quick example of, let's say we wanted to add cable television control. We start off by opening our library. This is a library of all the components that we can control. There's roughly a thousand in the library today and we're always working on it. What I'm going to do is actually look for a cable TV receiver. For this example, we're going to use one from Scientific Atlanta. It's a high definition cable TV receiver. I simply drag it out into the shared zone, give it a name. And from here, I then bring it out into this layout view. Now, Blueprint is based on a very simple schematic model.

The installer simply needs to describe to Blueprint the components that are used and how they're physically wired together. And then Blueprint sort of takes care of the rest. So what I'm going to do is first wire up the control interface. In this case, it's an infrared transmitter, so I'll wire that right in. And I'm also going to use a single wire, an HDMI cable, to wire in the audio and video that will be coming out of that cable TV receiver into our ROSI controller.

Once I'm happy with that, it's very simple to -- I use this compile button here, and this kicks off an analysis. A Blueprint will analyze the drawing that the installer has come up with and figure out what can be done. In this example, in the living room, in the bedroom, what can be watched there? Can I watch the cable TV as the wiring and the control setup that lets me do that? No errors came out of that, so everything's going well. From then, I can also now create initial user interfaces. So the system will automatically generate the touch panel or the on-screen display user interfaces.

By selecting one of the touch panels, I can now edit the user interface to kind of take a look at what it's done. And here's that cable television, the cable receiver that we added. By double-clicking on it, I now get a view of what the end user will see when they use the interface. So the question arises, well, how does Automator fit into all this? And this is kind of where I think things get really interesting. Each one of these buttons and controls that you see on this screen are bound to an automated workflow that our control system will run. And so what that means is I can look at, for example, this button here represents the power on for cable television. You want to watch cable TV in the living room, you hit this button. By double clicking on it, we can actually look at the automated workflow that was generated. If you remember before when I hit this compile button, what the system was also doing was creating all the default workflows. This workflow, all of the actions that you see in here are actions created by Savant, and each action typically talks to one of the devices that we're controlling, one of the components that we're controlling. So here you see we're powering on the cable TV receiver and powering on the rest of the devices needed in order to deliver the cable television content into the room.

Well, why did we use Automator here? Well, the main reason was because one of the keys of this industry is being flexible, customizing the system to each individual user, customizing each individual installation. So I'd like to show you a couple of examples of that. A very typical request that our installers or our customers deal with is integrating other features or controls, such as lighting control, in with an existing function. So when someone turns on cable television, maybe they want the lights to dim. Well, it's very easy to do. and actually I kind of skipped ahead, I'll do that again. All I need to do is drag out the action that corresponds to controlling the lighting system.

And then simply use that action to say, well, I want to set the dimmer in the room. And let's say I want to set the lights to 30% and have them fade over a three-second time frame. And just like that, I've changed the way our control system behaves. No need to write software, even, you know, no need to be technical. Simple drag-and-drop interfaces providing powerful programmability in our application. We're not limited to using just, you know, savant-built automator actions. We can use any automator action. Another very typical example that we have is when powering on these large, complex AV systems, a lot of times there are artifacts during the power on process. Speakers may snap or hiss because amplifiers are turning on or there's just different delays and timing issues. So it's very typical to want to introduce a delay between a couple of steps in order to give components time to warm up or to turn on it again to a stable state. So once again, using the standard automated pause action, I'm able to program the system to change the way the system behaves. This is a very, very powerful feature for our customers to take advantage of. Now by simply saving that workflow and exiting, that power button's behavior has now been changed.

So overall, Savant is very pleased with the decision that we made to integrate Automata. The flexibility, the ease of programming, the runtime performance are excellent traits, and they work very, very well in our products, and have really made a difference in changing the way the industry deals with customized home automation and integration. So that's it. Thank you.

So I think you'd all have to agree, that was pretty incredible. Savant has clearly taken Automator to the next level, and so we're very proud to have them here. So we promised we'd get you guys out of here in time for the beer bash. So let's once again take a look at the big picture. First, we talked about how to build Automator actions. Like we said, these Automator actions are the foundational technology behind Automator. And without them, you couldn't create lots of these, you couldn't create workflows to then add support to your application. So, What did you learn in this session? You learned what Automator Actions are, what they are conceptually, how they work, and what the components are.

You also learned how you can create Automator Actions by implementing the source, designing the user interface, and setting the action properties, as well as how to integrate workflows into your application by adding one-line features and utilizing the three classes in the Automator framework to have more control over the workflow as it runs in your application. So now, all of you are also Automator Ninjas, so you can go out and build and leverage Automator actions. For more information, you can talk to Matt Drance, our sharing technologies evangelist, or you can add yourself to the Automator developers mailing list. And there's also documentation and other resources at the developers website.