Of course, we immediately get questions about when we’re going to put all our apps in Workflow Extensions. It happens with every new Apple technology release. “When will you do an iOS version?” “When are you going to create a Watch app?”
Since these are Workflow Extensions we need to think about workflow. What makes sense being in the host app, and what does not make sense? What makes sense are workflow apps that you “touch” and get back to FCP X. Workflow apps where you go away from FCP X, perform some combination of activities and then go back to FCP X, do not make sense.
Thus, asset management, review and approval, and training apps make sense. You want to view the reviewer comments in FCP X, in the native timeline or clip being commented on. You want to search for a clip and bring it to FCP X.
As we proved in 1999 with the first of our training products, The DV Companion for FCP, having the instructional video floating over the app makes a lot of sense. (Technically Workflow Extensions don’t float, but they are there in the app, so it’s much the same.)
A limitation on Workflow Extension is that they must have a single interface window, so document based apps aren’t suitable.
So, when it comes to the Intelligent Assistance Software and Lumberjack System apps, it makes sense for some to become Workflow Extensions, and not others, based on workflows. Apps like Producer’s Best Friend – where you generate reports and then get back to FCP X – or Sync-N-Link X – where you have clips in FCP X that you want synchronized and immediately sent back in FCP X – make a lot of sense.
Conversely Change List X makes less sense in a Workflow Extension because the output is not used in FCP X at all. Similarly the two translation apps don’t make much sense as Workflow Extensions.
For Lumberjack System, Lumberyard makes sense as a Workflow Extension because – again – it uses Event Clips as the input and the result is updated in FCP X. noteLogger and backLogger make no sense as Workflow Extensions because the are used before FCP X. They are, as is real time logging in the iOS app, “pre editing” tools to be used before the NLE.
Similarly Lumberjack Builder not only makes no sense as a Workflow Extension, but isn’t even possible. Builder takes an input from FCP X (Event Clips) but work continues in Builder. You can update an Event with Keywords logged in Builder (because it’s more efficient) but Builder is really designed as a companion NLE to FCP X, again to be used before finishing work is done in FCP X.
Transcription Workflow Extensions only make sense if you haven’t really considered the workflow. While it wasn’t automated transcription, Lumberjack was first to bring transcripts into FCP X back in early 2015 for the OJ Simpson Documentaries. We discovered that even a perfect transcript in FCP X is still a terrible workflow. Searching is difficult, and there’s no way to build a story based on text, the way transcripts are used.
Getting transcripts into FCP X is solving the wrong problem, which is working with transcripts in a way that makes sense. That’s why Greg and I spend a lot of time thinking about the workflow, and realized there was no way that transcript workflows could be grafted into FCP X, and it was/is our belief that it’s not a high priority for the Pro Apps team. So we built an entirely new kind of NLE for text driven editing.
Being a document based app, meaning you can have multiple documents open at once, with each document carrying multiple stories, it can’t be shoehorned into a Workflow Extension, but more importantly it would be the wrong thing to do. FCP X is not the place to be editing with text.
So, when thinking about Workflow Extensions, consider what workflow problem they solve. Where the Workflow Extension functionality is used IN a FCP X workflow, it probably belongs in a Workflow Extension. Where it independently enhances FCP X workflows, either before or after the primary FCP X work, then it isn’t appropriate for a Workflow Extension.