UI Automation and Lessons Learned

Questions & Suggestions
1

#Break UI Automation tasks into granular sub-macros

I'll make this short-ish and to the point. I may post other lessons, but I think this specific hard-earned lesson should be shared.

I use Final Cut Pro X (FCPX) a lot, and I built a lot of KM automation macros to make things easier. Apple recently released a new version of FCPX, and a lot of my macros broke. And I earned an important lesson, which I'll share here.

The lesson is this: Place every single bit of automation in its own sub-macro, so there's only one place to change things.

Here's an example of something that changed in FCPX: You used to be able to select a clip in the timeline, press ⇧F, and FCPX would find the clip in the browser, and set focus to the browser window.

It's just one keystroke, right?

So I just repeated this action anywhere I needed it.

But now, while ⇧F still finds the clip in the browser, it no longer sets the focus to the browser window, which broke a bunch of things. So now I have to find everywhere I simulated ⇧F, and change it.

##Here's what I should have done:

When I simulated the ⇧F keystroke, what I really wanted to happen was "Find" and then "Focus". So now I have these macros:

So now, instead of using

I use this:

Which leaves me with only one or two places I have to change, if something breaks.

###So here's what I've got so far, but of course I have a long way to go:

So that's my recommendation to everyone who automates UIs. Break tasks into very small chunks, and make sub-macros for everything.

###You might want to get this macro, if you don't already have it:

This makes it easy to select one of the aforementioned sub-macros, then paste in an "Execute a Macro" action that calls the sub-macro.

4 Likes
2

I created a Group called Subroutines. I place any macros in there that only exist to be called by other macros. They have no triggers on them.

3

Yep, I do the same, except I call my group "Sub-Macros"

4

I am thinking of adding direct support for something like Subroutines in a future version of Keyboard Maestro, so hopefully that will encourage people to use this advice (plus maybe make it a little easier, although probably not much).

5 Likes
5

Awesome! Multiple parameters would sure be cool, but I have no idea how you’d implement it.

6

I’m thinking something like the Plug In actions would look with multiple fields. Not sure how it would work inside the subroutine. Might have to implement local variables somehow. Anyway, its just a thought at the moment.

7

Well, it's certainly a good thought!

Might have to implement local variables somehow.

How about adding a special token that is indexed, so it would be something like %Param%1%", %Param%2%, etc? Since %TriggerValue% is local, I would think you've already got some logic present for local tokens which might help.

Just a thought.

8

That is definitely possible, but named parameters would obviously be easier to understand. Not sure what would happen when you change the subroutine though.

9

@DanThomas I’ve seen your great advice in here and other forum posts and have been curious about your strategy for naming macros. It looks like you use a prefix that includes the app name plus the type of thing is controls? (UI)

Do you follow this naming structure as well as organizing them into folders by project?

For me, some subroutines can apply to several different projects I’m working on so seems like a better idea than what I do now (putting all routines and subroutines in same folder according to project).

If you’ve discussed your naming structure somewhere else maybe you’ve got a link?

Thanks for all your help!