Welcome to WWDC and especially welcome to the first session on automation today. We have two. This one's an overview of all the new different things in automation, and there's a lot to talk about today. I'll be joined in this presentation by Chris Nebel. He's the Senior Automation Engineer and, when he comes back from being wired up, he'll stand over here and do some of the demos. But, like I said, we have a lot to talk about. There's been a lot of work and a lot of changes, and I think you're going to enjoy some of these things. So let's begin.

So what's new in the world of automation? Well, without actually just bullet pointing the whole list, we're going to be talking about Automator and AppleScript. Especially we're going to introduce some new features. They're very powerful. Some of them are pretty dramatic. I think you're going to find that they become your favorite things to work with.

And we're going to look at multiple computer file access. We'll be looking at some security transparency issues, some new OS X integration that we've created, and getting your computer to pay attention to what you want it to do for you. So those are my mystery topics here, and we'll begin with the simplest multicomputer file integration which is iCloud support, specifically documents in the Cloud. Now, you're all familiar with how this works. You can create a document on one computer. You store it in the Cloud, and it automatically gets pushed to another computer using your same iCloud account.

Now, through the magic of automation and iCloud support, we've incorporated this into the AppleScript Editor, and it works in the same way that you're used to working with other applications that have document in the Cloud support. You can drag your favorite scripts and applets right into the iCloud window. They'll automatically load and go up to the server. And then you can search based upon tags that you've applied: key words, names, those kind of things.

And, in addition, you can use some of the resources of the iCloud viewer to sort and organize your scripts and to be able to use the shared menu to send them, share them over iDrop, AirDrop or iMessage or something like that. So here's an AirDrop example where you're taking something from your Cloud and you're sharing it across. Hello there.

And we've incorporated this, too, for Automator as well. So not overly dramatic, but you know what? Being a script hoarder like me, I'm actually starting to like having one place that I can go to where I know I'll find what I'm looking for and copy it to the machine. It's been very, very useful. I think you're going to find it useful too; and you'll soon make this just part of your normal everyday life with the editors.

Next we're going to look at automation applets and security. So the other day I get an email from a friend of mine, Trudy Anchover. She's head of the -- she's Director for the Bay Area Forest Scouts, and she was at a conference with me. She saw me demonstrate this little photo droplet. And she asked me in an email, you know, Can you share that with me? It would really help me out. So I didn't think twice about it. I just, you know, instantly replied in an email message to her, addressed the email message.

I found the droplet, added it to the email message, and sent it to her. I didn't think twice about this. And then I send it to Trudy. So when Trudy gets it on her machine, she takes the droplet from mail, drags it to the desktop, and is ready to use the droplet.

She selects an image and drags it on top of the droplet. And, instead of getting processing, she gets this dialog saying that this droplet can't be run because it's from an unidentified developer and that her settings for security are set to only use apple -- applets from the Apple Store or from known developers.

Now, that's because, in the Security and Privacy Control Panel, she's using a default setting which is for Mac App Store and identified developers. Trudy's not a particularly sophisticated user, and so she doesn't know how to bypass this or anything. It just -- to her, it's just broken. And it's really my fault because I forgot a very important thing is that Automator and AppleScript droplets and applets are applications. And, because they are applications, they're subject to the same level of security scrutiny as any other application on the OS.

So, in order for them to function correctly, they really do need to be signed to be Gatekeeper approved. And you can try doing that with the Terminal and some magic commands, if you like; but now in Mavericks we are introducing code signing support built into our editing apps.

Yeah. Really nice. And it requires that you have, you know, your developer ID, which you do, and that you have the Xcode installed with the command line tools. And, since we're all developers here, you're used to this concept because you've been preparing your apps for the Store anyway. So you're used to sending out signed copies.

And you already have your developer ID and certificates installed into the keychain. So, once you do, then you can use this new feature. And let me show you what it looks like. Here, in the AppleScript Editor, I'm going to export the droplet for Trudy. And so I go to the File menu and choose Export.

And when I do, I get the dropdown sheet. You'll notice that there's a new pop-up menu at the bottom of the Save sheet and it says code sign. It's for code signing and, by default, it's set to don't code sign. But if you do click that pop-up menu, all of your developer identities that are installed on that computer will appear in this list.

It's just simply a matter at that point of choosing the identity that you want and then clicking the Save button, and it will save a copy of that droplet or applet signed ready to deliver. So, if I had done this for Trudy, she wouldn't have had any of the problems that she came across.

For Automator, it's a similar process. So here I have a workflow open in Automator. This is one I use for video editing quite a bit and creating a compressed video version from raw source. And so, to do the same export, I just go to the File menu, choose Export.

I get the Save sheet in Automator. And at the bottom of the Save sheet in Automator is also a code sign pop-up menu. Again, I can select from that menu the developer identity that I'm looking for, pick that, and then just click Save. The applet will be saved to wherever I indicated, and it's signed and ready to be distributed. It's really that easy to use these. And, to show you that, I'm going to turn to my friend Chris Nebel and have Chris demonstrate. Thank you.

Thank you, Sal. So let's take a look at how Maverick makes it easier to code sign your workflows, applets, applications so you can distribute them to other users. So I've got an applet I've been working on here. Notice getting this out of iCloud. It's working on another machine.

And I worked long and hard on this applet. I'm very proud of it. I'm ready to send it out to the world. And, historically, what I would do is I'd just, you know, stick this in an email message, send it off, and the other person would grab it from there. So I have an applet that simulates uploading and downloading it, so it will pop up in the Downloads folder.

And, if I open this now, I get this dialog, and it's saying that it can't open this because it's from an unidentified developer. This is the default Gatekeeper policy on everyone's system. And OK here doesn't mean "okay, go ahead and run it". It means "okay, we're done". There's nothing to do here.

This applet simply won't run. And there is a workaround. You can Control click on the applet, open the long way and you'll get a different dialog. But, for most users, as far as they're concerned, it's busted, right? All they can really do is throw it in the trash.

So how do I -- how do I make life easier on my users here and not have them think I'm a complete idiot for sending them broken applets? So, in Mountain Lion, we added an Export command to Script Editor. The whole point of Export is to save the script for distribution.

In Mountain Lion, the main thing that it did was it allows you to save the script as run only, taking that out of the Save As dialog because who here has accidentally saved a run-only copy of their script over their real one? Uh-huh. I thought so. So Export makes that a little harder to do.

And now, in Mavericks, here's run only but here also is code sign. So last year we showed you how to do this in Terminal, but now it's built right into Script Editor and into Automator. And so, if I pick my -- my developer ID here, I will save that to the desktop.

Yes, I want to allow this. So now I have my code-signed version. If I up and download that and run it, now I get a different dialog. It says this is downloaded from the Internet. Gatekeeper is still not too sure about this Internet thing. Kind of new. But now it's Cancel and it's Open. So, if I open, it goes ahead and run -- and runs.

So that is how -- so code signing will make your life easier. Mavericks makes your life easier code signing your applets because it's now built right into the editor you're already using. And it makes life easier on your user because they don't have to worry about long hand waves of dealing with nonsigned applets. Sal, back to you.

Thank you. So it works with Automator and AppleScript applets and droplets. They're applications. You have to remember that, if you're going to distribute them now that we have Gatekeeper, it -- its default settings, you might want to just quickly do an export. Code signing will even save it as run only if you like to as well. And this has all been integrated. You can see it's a very simple process. Take advantage of it. Next we're going to talk about extending the power of AppleScript. And we're going to be doing that with something that's brand new, and it's called AppleScript libraries.

Now, why libraries? Well, I assume that many of you are like me. You're the kind of person has hundreds and hundreds of your favorite routines that you've written over and over and over for lots of different situations and scenarios, and you want to be able to use those in multiple scripts.

So I have four or five things if I have a script that's dealing with text I'm going to be pasting these in the bottom part of my script. Now, if you also are the type of person that relies on third-party scripting additions to provide a missing command like especially something with text handling, you're going to like libraries. And if you just want to simplify your scripts, you're going to like libraries.

Now, it started for me by having a routine that I like to use, and then I started using it in multiple scripts. And it was quite useful. I would just copy this thing from, like a clipping. I would paste in. Then I found another routine that I used, and then I would paste that into some of the scripts that I had. But then I started changing some of the routines and then I added new ones and then it just became this thing of I couldn't keep track of all the different stuff that I had. So new in Mavericks we're introducing AppleScript libraries that will help address this issue.

And what they are is a new plug-in architecture for AppleScript that allows you to create your own libraries of commands and gives you quick and easy access to them without having to go through a bunch of -- of hoo-ha to get to your handlers. Now, they're different than scripting editions in a couple ways. First of all, you can write them in AppleScript.

You don't have to write these in C or C++. You can write them in AppleScript. And they're controlled by the script that's calling them, so that manages your script libraries. It means that the library is only loaded and it's only available when your script tells it to load. And it helps avoid terminology conflicts that way. It helps deal with resources. And the script library commands are run by the process that's executing the script. So it's a lot smoother to deal with.

In addition, these libraries can take advantage of AppleScript Objective-C, so the wealth of the Cocoa frameworks and all of those classes and methods now come into play in the libraries that you write yourself. You can use some AppleScript Objective-C and talk to the NS string class and use some of its methods as well.

In addition, your libraries can contain their own terminology. They can publish their own terminology. So you can make custom terms that represent the complex handlers that are parts of your library. Yes. It's really, really nice. So, instead of remembering a handler name, I can just put in some terminology and it will work perfectly.

Now, in support of that, we've created two new constructs. The first is something that we're calling a script library reference. And what it does is it does a couple of functions. It locates the script library for you automatically and prepares it for loading and use in your script. The second is something brand new. It's called a use clause, and it is really a command for importing terminology and making it globally available in your script. Very powerful. A lot of fun to use. Let's take a look at this.

So, in its simplest form, simplest form, an AppleScript library can just be in AppleScript routine that you have like this simple routine here for converting the case of some text from uppercase to lowercase. You can have this very simple AppleScript handler that you've created. You take that, you place it into a script. Then you compile it. You save it. And, in this case, you just save it as a script file.

Next, in your home library folder, you create a new folder called script libraries and then drag your script file, your new script library, into that folder. Now you've installed it into the script library, AppleScript library system. That's all you have to do. So, to use it, it's just a matter of typing the word "script" followed by the name of your library. And you don't have to use .scbt or anything, just the name of your library.

And, when you compile this, it becomes a script library identifier. That is now a representation of your script library. The AppleScript architecture automatically located it in the script libraries folder. It's prepared it, ready for load. And now that it's an identifier, you can target it using a tell verb or a tell block like this example where I will be calling one of the subroutines or one of the handlers within that library script, pass it some text -- how now brown cow -- and use a numeric indicator to indicate I want uppercase. So when this gets run, the library is loaded, the information is passed, and the results come back to you automatically.

Very simple way to make a library. Just very functional but easy to do, easy to install, and easy to use. Now, in its more advanced forms, a library can have its own terminology. And here is the dictionary window for an AppleScript library. It has a single suite, and the suite is called AppleScript Text Utilities.

This suite has two commands in it: one for changing, transforming text; one for replacing text. It has a definition for the suite and shows the definition for each one of the individual commands. So in an advanced form of a library, you can have this terminology available for you and for your customers and for everybody else to use.

So no longer are you calling a handler name or having to remember a handler name. Instead, you can now use terminology like transform text, how now brown cow to uppercase. And this will function exactly the same way as a library did before. Now, that's in the more advanced format.

So here's an example script talking to the Finder application, and this contains a tell block addressing an AppleScript library. You can see it right there where it's going to basically take the name of some selected folders in the Finder, and it's going to iterate all of these folders getting their lowercase names and converting them to uppercase names. So that's the purpose of the script.

Now, you'll notice that, by having an individual tell block for every time I want to talk to this library, in a small script like that, I can get away with it. But, in a larger script where you repeatedly might go back and refer to this library, that's a little clunky to deal with.

In addition, there's another issue going on here. You'll notice that there is a variable called "adjusted name" that's actually going to store the transformation result, hold it for a second because it was within a tell block, and then use it later on in the script for the Finder to assign the name of the selected item to that transformed name. So you're doing this little dance because of this tell block. And, again, this makes it a little clunkier. It works, but it's not smooth syntax. So we've come up with something to address this issue.

And I'm just going to make a little room at the top of the script, and were going to insert something new. It's called a use clause. And this use clause is an importing command that says "Use this library." There's a script library identifier. And that means it will take it, load it, and make its resources and handlers available for the script globally.

So, because I have a use clause here, I don't need to have the tell block around my statement that calls my library. I can remove that. And I can also deal with that little back and forth about having you create a variable to store the contents of the command and then reapply it and instead put everything on one line so that the Finder can say "Set the name of the selected file to the results of this transformation." And then it just becomes one seamless, transparent line. So we can go from this little clunkiness to a very smooth example with this new use clause ability.

And it works the same way as anything else. It works totally smooth. It's transparent. Now, let's talk about the use clause for just a second. It's about importing terminology, and it allows you to import the terminology of script libraries and applications. So the importing commands, when you import an applications terminology or a script libraries terminology, they are available globally through the script. You no longer have to address that application or that library. It's not necessary.

And you can also use this use -- use clause to specify the use of a particular version of AppleScript or a particular version of an application or even a particular version of a script library. And it sure does make -- streamline the script syntax that you have. It makes things easier to see, conceive, and use. So here to show you the use clause is my friend, Chris Nebel.

Okay. I personally am really excited about this feature. This is, like, my favorite AppleScript feature in a long time. It's one of those ones that makes you wonder why it didn't always work this way [laughter]. So let's see how it affects an actual script. So I am the team mom -- that's the actual job title -- for my neighborhood soccer team. Basically, it's handle all the administrative stuff so the coach doesn't have to.

And part of the job is forwarding email around. Someone -- someone on the team sends me an email. I have to send it out to the rest of the group. But the rules are a little tricky. I want to send it to everyone else in the group except for the original sender. Them, I want to Cc. And mail can almost do this but not quite. If you put an address book or contacts group in the To field, it can expand it out to all the people.

But then it's up to me to actually find the right person and pull them over to the Cc group. It gets a bit out of -- it gets a bit messy after a while, especially when you have to do ten of these a day. So -- but, automation, one of the things it's for is for filling in the gaps when the system almost does what you want but not quite. So here's the script that I wrote to handle this for me.

So we tell application mail get the current selected message; forward that message. It creates a new forwarding message ready to be filled in. And then we flip over to Contacts. I have a group defined Neighborhood Team so -- with every person in that group, filled out an email address for them, and then we flip back to application mail. And, if the sender of the original message contains that name, then we want to add them as a Cc recipient; otherwise, it's a To recipient. And this works well enough. Let's see it in action.

And the message was originally from John. He's been Cc'd. Everyone else, it goes "To." So, obviously, the script works. But you notice the sort of back and forth tell -- tell this, tell this, tell that, tell this, tell that. And that's very typical of any script when you're talking to more than one application.

You have to flip back and forth between them a lot. So wouldn't it be nice if the -- if AppleScript could figure out which application you're actually talking to just by the terms that you're using. Well, that's pretty much what use does. Let's look at how the script changes.

So two use statements at the top. The first one is application mail, and I'm also defining a shorthand name for it that I can use later. It's essentially a property whose value is application mail. I'm also going to use application contacts. The first line is pretty much the same. Get the selection of mail. I have to specify that it's mail selection because contacts has a selection to. So got to be explicit there.

But then we can forward the message. And notice there's no tell block here. The compiler knows that, forward, mail is the only thing that defined forward; so it will send that to mail. And then we repeat with every person in a group. No tell blocks again because it knows that person in group are defined by contacts and not by mail.

You're building up the mail address if the sender of the original message were actually getting this straight from mail instead of prefetching it, and this actually comes from contacts. We're mixing two applications in the same statement making you to Cc or To recipient. And, again, there's no tell blocks anywhere here. And, yet, it works exactly the same.

So, essentially, what use does is it lets you get rid of all the bookkeeping that the computer really ought to be able to do for you. Notice that this script, this new script, is much narrower than the original one. It gets rid of all the tell blocks so you can concentrate just on your application logic and not have to worry so much about exactly which application you're telling to do what because AppleScript should be able to do that for you. Now it can.

Yeah. It's going to take me a while to wrap my head around all the different places I can use the use clause, but I'm very excited by it because I've been able to do some really interesting things in a single line statement that it would usually take me multiple lines and multiple tell blocks to do. It's a very powerful construct and especially when it's used with libraries. It's great.

So, AppleScript libraries, they are a new plug-in architecture that allows you to get at your favorite handlers. You can create these yourself. They're different than scripting additions because you can write them in AppleScript and that the script manages their use and use of resources as well. They can also have access to AppleScript Objective-C, so that means the world of Cocoa, methods and classes are at your disposal. And you can publish your own terminology for them as well. In support, we've added the new script library reference and, as we just demonstrated, the new use clause to help automatically find, locate, and load these things globally for you.

Now, we have a session this afternoon on just libraries where we get into detail and show you how to construct a library, not only a simple one but one in AppleScript Objective-C, one that actually has a terminology. And, for the first time anywhere in the world, we will show you how to write a scripting dictionary file or an sdef [laughter].

It is sick, sick, sick. You can't miss it. So that's this afternoon. It's right in this same room. It session 416 at 3:15 pm. If this is interesting you, I suggest please come to this. When you're done, you'll really understand them and be able to start using these. They're very powerful.

Next we're going to talk about notifications. Informing the user of what's going on. So the other day I was reading this blog about how they got it right in OS X with the Notification Center. And the guy says, "Yeah, man. You know, they -- they're located in a central location. They're organized by application.

And they disappear quickly so that there is no clutter on your screen. It's really nice that they're there. And it can even provide a mechanism for you to respond. And, in the new version that you've seen, you can even have replies and stuff like that. And, you know, they're designed not to annoy you or get in the way. [Laughter] And they should never, ever leap, jump, or hop and definitely not bounce." So I'm showing you this because, for many, many years, this is the way that scripts tried to notify you until now.

So we've added notifications support in Automator and AppleScript. And we've integrated it [applause] -- yes. And we've integrated it in both applications and -- so that there's no more need for these mobile dialogs that just kind of hang around, and you can now create your automations that are 100 percent bounce-free [laughter].

So let's take a look at how this works. There's a Notifications Control -- System Preference pane, right, in the Master Preference pane. If you open that in Mavericks, you'll see that your favorite, you know, automation applets and droplets appear in the list of applications like everything else. And you can select them and set their preferences. For example, I can select my photo droplet, and I can choose that it will display as an alert. Or I can even say, No; I don't want any display. Just use the sound.

Or, if I have something that I use quite a lot and doesn't require a notification, then I can just turn it off and take it out of the Notification system by just clicking that checkbox. So, when it comes to Automator, many people don't know that, when you run an Automator workflow or applet, it does provide some feedback. And you'll notice at the very top of your menu bar there's a gear.

And, if you've ever seen that or even caught your eye with it, if you click on that, it will show you every workflow that's running and generally give you an idea about where the workflow is. But you have to hold the cursor down. And, if you're still holding, you might get this notice that says the workflow ended. But most people don't know about that and so, generally, the way that you know that a workflow is -- is finished is nothing. There's nothing there to show you.

Now, with the Automator in Mavericks, we've introduced a new notification action, and this will cause a notification to occur. And you can insert it more than once in your workflow if you want. You could put it into the start. You could put it in key points in the workflow.

You could just put it at the end. Whatever works for you. And, in addition, it provides various options for which one of the fields you want to do, and it also supports Automator variables, workflow variables. So we can have dynamic information in that dialog related to the workflow that was run.

Now, why would you need this kind of thing in a workflow? Well, here's a workflow that I use myself for home movies, and it's a video compressing workflow. Anytime I shoot a bunch of stuff on my iPhone or a camera, I take the raw files and I run it through this droplet. And let me just walk you through it real quick. So it's an applet, so you can see at the top it says it receives whatever you drop onto it.

And then the first action, I have a find -- filter finder items, so it looks just for movie files. In case something else gets accidentally dropped on it, it ignores it. Then, the next action is creating a workflow variable that stores the references to the raw movie files. Then I proceed to do the first encoding at a lower thing of 480p to a certain location on my drive.

Next, I append a -480p to the end of the name of all the created video files so I know which ones are the lower resolution. Then I use a workflow variable. I call back that workflow variable. I get the original list of source references. I perform another encoding pass using 720p or 1080p depending on where I'm going to, to a certain location. And then again I append to the end of the name.

So this workflow can take quite a while to run. If you drag four or five 10GB files onto this, it can go on for quite a while, and you have no idea of knowing where you are in this process. So this is an example of a workflow that you would want to add a notification to.

And to do that it's pretty easy. You just open up your library view. You search in the Search field for notification. And you'll see that it appears in the list of available Automator actions. Hit the Return key; it becomes selected. You can see the display of information about the new notification action. Hit the Return key again and it will automatically inserted it into the bottom of my workflow. Then it's just a matter of me filling out the fields the way I want, saving it.

So now I drag my video file on top of that. And I hit the gear, but after a period of time, the first encoding thing appears on my desktop. Then some more time goes by, and the second encoded file appears along with a notification. So now I know what's been processed.

If I come back from eating my doughnut or lunch, whatever, and I just look at the machine, I can say, "Oh, great. The encoding went fine. Okay. I'm ready to do the next batch or something." And because the parameters are settable in the System Preference pane, I can choose to have that be an alert that demands that I close that alert so just as a confirmation as well.

Now, for AppleScript, what we did is we added a new command that's part of the standard editions, and it's called Display Notification, of course. And here's the verb. There's an optional parameter with title. There's another optional parameter here for subtitle. And you can put the name of the sound file that you want to have play. Now, all those are optional parameters, but you have to use one of them.

And it creates a notification. So, in that example I sent to Trudy, this is basically the repeat routine. I would just open some space here after the repeat, insert that into there so now there's display notification. And I can add custom data like the number of items that were processed into the final message so that, when I drag a bunch of images onto the photo droplet, it processes. And, then, after a while, it will display the notification with the custom information. It's that simple to use. So here to show you notifications in action is Chris Nebel. Thank you.

Thank you, Sal.

Okay. So I've got Sal's encoding workflow here. Let me get that started. And, like he said, you can see that it's running from the spinning gear menu. But, when it's done, all you get is just the gear disappears. You'd like some better notification of this. And in the past you'd use a modal dialog to do this, but that's really the wrong interaction method because a modal dialog is an alert.

It is saying, "Oh, oh, here. Sir, sir, sir. You've got to see this. You've got to do something about this. It's right here. Are you even paying attention to this?" Whereas a notification is much more passive. It says, "Oh, hi. So, yeah. This thing happened and, yeah. If you want I can hook you up with, you know, a guy. But, you know, if you don't, it's cool.

See you [laughter]." And that's what we just got if you weren't paying attention as it flowed by. Our notification showed up and, if we look in Notification Center, it's still there if we happen to be away at a coffee break or something. So let's see how we did that.

I have it open in Automator over here. So the basic workflow Sal explained to you already, filter out the movies, encode them, encode them, add the name, encode then again, add the different name. And, at the end, we have display notification, finished encoding. So this is nice, but we can do a little better. We'd like to get a notification about what items just got encoded because we might have several of these in flight at once.

Now, we happen to already have the input file stored in a variable. We had to save them because we were going to -- we have to feed them into two different encode media actions. So we can just take that variable and put it into the message here because all these fields support -- support variables. Save that. And now, if we do our workflow again -- I'm using a shorter movie this time so it won't take quite as long. There's one file; there's the next and says finished encoding, menomena.

So let's try something now a little more complicated and a lot more geeky. So there are lots of system services, low-level system services that tell you what they're doing simply by writing out to a file. They write out to a system log. And, you know, that's okay as far as it goes. But, you know, here's an example. I have a machine that other people log into. And, you know, they are nice enough folks, but they get a little, shall we say, overenthusiastic about using Pseudo, and I like to keep an eye on them.

Now, Pseudo is one of the system services. It writes into a log. So anytime something goes on, you know, we can keep an eye on that using Syslog. So this just writes out a message anytime Pseudo logs a message. And I'm going to pipe this through sed to clean it up a little bit so I just get a simplified version.

And, if I come over here and say Pseudo-something, there's my message popping out. So this is nice as far as it goes. But, you know, I've got lots of Terminal windows blabbing text at me all day. Odds are good I'm going to miss this one. You know, it might get covered up. I'm not necessarily looking at Terminal. But, you know, hey. Notifications. Let's see what we can do with that.

So I have a script that I wrote here. If you don't know Perl, don't be afraid. This is just what I'm more comfortable with. So what this does is it's going to just sit in the loop reading lines of text as they come in. And, for every line of test, it's going to run the rest of the script.

So this little hunk of line noise breaks up the input line into three chunks, breaking on colons. So we wind up with three pieces: dollar one, dollar two, dollar three. And then we'll use those to build up the parameters for a display notification command. That's how you do notification from AppleScript.

And then we're going to run that assembled script using osascript. Osascript is how you run a script from Terminal. So, if we run that -- and if I can spell it correctly -- we can give it some text, break up by colons, and watch the corner of the screen there. We get our little notification.

So now let's take the previous command we had, the Syslog command, and pipe it through notification filter. So, now, this will just sit here running. I can minimize this window or whatever. But someone comes along and does Pseudo; I get an actual notification that shows up wherever I am.

And that is just a few ways you can use notifications to improve the awareness of your workflows that are running on your machine. Sal?

Very cool. I like to know everything that's going on in my house on every computer everywhere. I want total awareness through notifications. So notification support in Automator and AppleScript, it's been integrated right into the editing applications, that you have resources for Automator to do it, for AppleScript to do it as well. This means you don't have to create these modal confirmation dialogs, and now you can be 100 percent bounce free. So that's notification support. Next I'd like to talk about accessibility integration.

Now, some of you might be familiar with Speakable Items. How many people in here have used Speakable Items? Quite a few. Quite a few. And it's an architecture built into OS X in the accessibility frameworks and allows you to speak commands to your computer and have them perform them for you.

And it has a lot of integration. There is a lot of customization built into the standard set of commands. For example, you can say, Mail this to mom, and it will understand who mom is. You could say meet with Karl Whelan [phonetic], and it will look up Karl Whelan in your address book and then create a new meeting for you in Calendar.

It has a lot of other commands that are just basically, you know, work things like open iPhoto, bring this window forward, that kind of stuff. But it's very useful. So a lot of people use this who are not involved in accessibility issues. It's just a nice power feature to have. So what we've done in Mavericks is we've created a new entity called Speakable Workflows. It's a way of saving your workflows into the Speakable Items' architecture and have it work for you automatically. So you can extend a set of commands that are available by voice using Automator.

And this is how it works. So, to turn on Speakable Items, you just go to the Accessibility Preference pane. At the bottom of the list of different accessibility features is Speakable Items. You select that and then just click the radio button to turn it on. As confirmation, you'll see this floating round window. That's the Speech Feedback window. When that's available, the computer is ready to respond to your commands. And, by default, you just press down the Escape key and say your command and it will start working for you.

Now, in Automator, if you want to create a Speakable Workflow, I have an example here. So I use USB keys all the time. I have one here. I call it Digital Briefcase. And, you know, I'm constantly plugging them into the computer, and then I have to go eject them.

So I have to find some dialog, whether it's an open dialog or finder window, find the stupid little down thing, click that, and then wait for the thing to eject and then grab it. I would really like to just be able to tell the computer "Eject Digital Briefcase" and, plop, it will just pull it out for me. So this is the workflow that does that, and I'll walk you through it to show you how to do this.

So it's an applet by default, and the first action is a Find Finder Items action, and it looks for two parameters. One, it looks for volume whose name is Digital Briefcase. Once it finds that volume, it will pass that to the next action which is just simply Eject Disc, and it will eject for us automatically. Then the next step is to specify some text I want as a response. And I type the word Done! and then have that spoken by a certain voice. I've chosen Samantha.

So then I choose to save this workflow. This will be my Speakable Workflow. And in the Save sheet you'll see that there is a File Format menu that says Application. Well, if I click on that, there's a new file format. If you have Speakable Items architecture turned on and installed on your machine, you will see this in Automator and it's called a Speakable Item. So, therefore, I can save this as a Speakable Item.

You'll notice that Speakable Item appears on the File Format menu, but it also automatically locates the Speakable Items folder which is within your Speech folder which is within your Home folder. In other words, that's the location that the speech architecture uses. So, when you save, you want to save it with a name being the name of the command. So, in this case, I'm going to say Eject Digital Briefcase, and that's what I want to be able to say to my computer.

I save that. It will install it into the Speakable Items architecture for me automatically. So the next time my thumb drive is plugged into the computer like it is here, if I want to, no matter what program I'm in, if I want to eject it, I just simply -- I just simply say the command -

So, in summary, this has been a great release for automation. We've had a lot of new stuff happening. Specifically, we added iCloud support so that you can have your scripts just distributed across all the computers that you use. We added code signing so that you can distribute your applets and droplets to every -- to your customers or to your friends without invoking any of the Gatekeeper responses.

We now have a new construct for extending the power of AppleScript through AppleScript libraries which you can write yourself in AppleScript and expose commands and terminology that you didn't have available before. And we now have introduced the new use clause that will really streamline the syntax of your scripts and add a lot of power and ability to them.

And we've implemented notification support in addition to our new Speakable Workflows. So that's quite a bit that's been going on this year. This is a great release for us. We're really excited about it. Now, if you have questions or more information I'll point to these four guys that you can probably beat up with Nerf bats or something to get answers out of them. And, in additional, remember the session on AppleScript libraries. And there's one more thing: Did you know this? Some of you might not know this but this is a special day for us because, 20 years ago at WWDC, AppleScript was released to the world.

And it's been a very, very powerful boon to our customers, to us, to engineers, to everybody to use it to create automations that really empower and change lives. It has been a fantastic language. It's constantly growing, expanding. And, as you can see, with this release, there's new things happening all the time.

So we just want to take this one opportunity on the 20th anniversary of this technology to say thank you to all the developers who made their apps scriptable. We want to say thank you to all the scripters that wrote and shared scripts with the community. We want to say thank you to all the customers that use AppleScript and rely on it every day. And to the engineers that make their apps scriptable and to the engineers at Apple that implemented AppleScript, we want to say thank you as well. So have a great conference. We'll see you later this afternoon, guys. [applause] Thank you.