In this tutorial we’ll look at a new workflow. It presents a multiple-selection list containing all of the unique URL’s from the current browser window. After selecting URL’s they are placed at the the end of the document in Markdown reference link style with (hopefully) unique markers.
But that’s not a problem if you are reasonably good at debugging in Editorial. So let’s get better at that.
Sideline: Debugging Editorial
I’ve discussed some methods for general debugging in a my Fountain workflow article. In that post I highlighted how important it is to pipe intermediate output to the console. This is such a common task that I have saved a custom action that makes this easy. It places input on the console and then stops the workflow at whatever location it is inserted.
This custom action is really three actions. It’s an Conditional Block action that contains a Console Output and Stop action. The trick is how we toggle this block on and off.
We just setup a little true or false evaluation. When 1 is Equal to 1 then the output is generated and the workflow stopped. To turn the block off, we setup a false statement like 1 is Not Equal to 1.
To save a custom action, give it a unique name by tapping the down triangle on the action (the Conditional Block in this case). Then hit Save Action as Preset. The new action will appear in your custom action section at the top of the Editorial actions list.1
While developing this workflow, I activated the Pause Before Running feature available on most actions. This functionality gives us two big bonuses in Editorial workflow development:
- Steps through our workflow at a specific break point
- Allows us to temporarily change the variable without changing the action settings.
After hitting the blue continue button, the action is executed with the temporary code and the workflow continues as normal.
- No access to Editorial variables inside JS
- No option to write data from JS to an Editorial variable
- No JS syntax highlighting
- No JS autocompletion
- No full screen JS editor
- No JS documentation
But with some basic troubleshooting, it’s not much different than old-school web development.
Let’s go over what’s going on in this workflow.
This is simple JS. There’s no tricks. It asks the current document for the number of links on the page with document.links.length and then loops over all of them and adds them to a list called urls.
At the end of the JS we need to pipe the list out of the action in a format that Editorial workflows can understand.
Improving the Browser
Here’s another example that is a bit more sophisticated from the team behind iCab
I saved this workflow as a browser bookmark and now I have a quick little highlighter in the Editorial browser.
Go to the Editorial browser and create a new bookmark with the following URL:
When you trigger this bookmarklet, you get full Quix functionality. Here’s a quick video demo:
Sure, this is something you can do in most iPad browsers, but now you have it in Editorial too.
I’ll suggest getting familiar with the hidden features in many of the Editorial actions. For example, the Pause Before Running setting is available on most actions and can make life a lot easier when working on a complex workflow. Patience and experimentation is almost always rewarded.