Yosemite’s Speakable Scripts

October 17th, 2014

One of the cool new features in OS X Yosemite is a major expansion of the system’s dictation features. Not only has the dictation become more accurate and reliable (probably by leveraging the work that goes into Siri on iOS), but there are new integration points that facilitate really interesting workflows.

I developed FastScripts many years ago expressly because at the time I found it tedious to have to open a script in Script Editor, and run it. For quick-fix type scripts, it was easier to just do the thing than jump through the hoops of running it!

Over the years, Apple has improved the built-in mechanisms for running scripts, by adding their own standard script menu, and slowly increasing the ways in which scripts can be invoked through various built-in actions. Still, when it comes to organizing and invoking scripts by keyboard shortcut, I am convinced FastScripts is best.

But a nuanced feature of Yosemite’s Dictation feature actually leapfrogs FastScripts in one interesting area: it’s now possible to configure app-specific speaking commands that run arbitrary scripts.

I learned about this feature via Macworld’s Christopher Breen, who writes extensively about the new speech commands and how they can be used to create custom Automator workflows.

At first I griped that the commands could not be configured to run scripts, because that is what any reasonable person would infer from the selection of choices:


Granted, these are all fine choices and you can perform some pretty interesting tasks by configuring a specific spoken phrase to open a file, paste a specific text phrase, or simulate a keyboard shortcut. But why can’t I run a script?

Going out on a limb I chose “Run Workflow…” and navigated in the file chooser to my scripts folder. Lo and behold, you can run a script, you just choose one instead of a workflow and speakable commands will handle it with aplomb.

Whether or not you use FastScripts to accelerate script execution with keyboard shortcuts, I think you might find some uses for speakable scripts. Enjoy!

Update Oct 17, 3:17PM EDT: Well, my excitement may have been a little premature. It seems the scripts are run not as the streamlined items that they are but are instead sort of wrapped in an automator action and run. It’s nice that you don’t have to go out of your way to translate a script into an Automator Workflow, but unfortunately this means that “Speakable Scripts” do put up the little Automator gear icon in the menu bar, and are probably ultimately slowed down at least a bit by being run as a full-on workflow.

Update Oct 19, 5:50PM EDT: Wait a minute, maybe it is running them as native scripts. There’s just a change on OS X Yosemite with how the system runs scripts, such that they always show an Automator-style progress indicator in the menu bar. I find this pretty irksome as a default behavior because for example short-lived scripts don’t need progress to be indicated at all. I’ve also noticed that the system automation progress indicator is liable to pop up at semi-random location in the menu bar, and then leave a gap when it goes away.

6 Responses to “Yosemite’s Speakable Scripts”

  1. Paul Fowler Says:

    What an excellent find, I had no idea this existed and I’ve been running the beta for the past few months.
    I’ve just been playing about with it and it is amazing for switching apps, hide windows etc.
    I’m gonna have so much fun with this.

    Thanks for sharing. :)


  2. Doug Adams Says:

    This seems like a revised version of Speakable Items. Isn’t it?

  3. iOSXalt Says:

    Great find!

    Can you pass the spoken text as an argument to the script?

  4. Daniel Jalkut Says:

    @iOSXalt – oh that would be great, but I don’t know about that. Let me see if I can sleuth anything about it.

  5. Doug Adams Says:

    The HUD mutes iTunes while it’s waiting for spoken input. Not great at my house.

  6. Ray Robertson Says:

    I also noticed the random nature of the location for the “Automation” menu item. Plus, it doesn’t display the full progress description/additional description if the text is over 25 characters or so (see screenshot at my blog below).

    I agree with you about the typically short-lived nature of these menu scripts making much of this unnecessary. Perhaps using a notification would have been a better approach.

    Regardless, thanks for this post, which I linked to in my blog.


Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.