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 going to 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 "Auto." So just remember that. Well, Automator, 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 have to be 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. 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.

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.

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.

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 bill there. To talk more about creating Automator Actions, I would like to invite up Emilie Kim, our Automator Ninja.

Hi, I'm Emilie, 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'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.

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." 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.

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 "am_bundle" 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, if you create an AppleScript Action, you'll be presented with this onRun handler that you can put your code in, and this is also what Automator will call. And then if you have a ShellScript 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 with 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's 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.

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 the 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 type 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 AppleScript 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 at Snow Leopard for Actions. So now, I'm going to bring Kerry up on stage for a quick demo. In this demo, you'll learn how to create an Action project. Then Kerry 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.

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 going to remove that in favor of some text. Where's my text? I don't know. Hang on.

Here'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. If we, 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.

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 AppleScript 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 Actions parameters.

So I'm going to select this pop-up here, and I want to bind its selected index to the parameters.

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 gonna 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 Emilie'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 popup 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 pop-up to the selected index, this needs to be an integer. And I'm going to set a value of zero, representing the first item in the pop-up. Okay, so now if we go back to our script, we can open up our Apple script and see that there is an on-run method. Every Apple script action has an on-run 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. So I'm going to 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 want to do is select 32-bit, 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. Ah, if I could spell it right. Garbage. There you go. And what we want to 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 want to add support for determinant progress. In order to do this, it's really easy. I'm just going to add three lines of code. Okay, at the beginning here, I'm going to 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, cuz we're using some new Snow Leopard APIs. Okay, with that, we can build and go. It's going to 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 Letterboxd Format. Now, what Automator is doing here is it's reading a property of that Action, the Convert Images to Letterboxd 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 Letterboxd Format. Now, our third image was Adjust Image Gamma, so we're going to add that. And then lastly, I want to open them in Preview.

And I'm just going to turn up the gamma a little bit, because 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 going to open them. And you can see it's really, the gamma's way off, and they're letterbox format because 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 Emilie back on stage.

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.

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 going to talk about adding workflow support specifically to your application. So, leveraging Automator Actions, adding workflow support to your application.

What you're going to 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 an 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.

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 frameworks 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." 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 Carrie 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. So.

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 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, 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.

Nice. 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, Emilie? Congratulations, Kerry.

So, what Kerry 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. Kerry already showed you the one-line way of doing it, which is using the AM Workflow 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 AM Workflow 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 AM Workflow to allocate a workflow object from it.

Once we have this object, we can do things like set the input for the workflow by calling setInput. 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 AM Workflow Controller comes in.

This is the controller object for workflows, and you can use it to run an AM Workflow as well as implement some delegate methods so that you can provide more control in your application as the workflow is running. To use AM 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 workflowControllerDidRunAction, then as the workflow is running in your application, you could provide a determinant progress indicator to show the user the progress that the workflow is making. Likewise, if you implement workflowControllerDidError, 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.

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 have to do it again. And I had to show it to you guys.

This developer has built their own Actions for their application and integrated workflows in their 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 Soghoian up on stage to introduce this developer.

Thank you, Emilie. We first met Savant Systems a couple of 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 multi-function 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 phone.

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 from Savant. And Michael Silva from Savant Systems is going to give us a demonstration about how their software integrates all this. Michael? Thank you. 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. 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. 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. For the, 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, so 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 of 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 Automator 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 Automator workflow that was generated. If you remember before when I hit this compile button, what the system was also doing was creating all of 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 Automator 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 Automator. 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 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 Dranz, 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.