Inspired by Automators, I’ve been trying to make greater use of Shortcuts. One thing I’ve been finding tricky is producing nicely formatted results. The “Show Results” action while functional doesn’t always produce output that is very easy to read.
I was wondering what techniques people have employed to overcome this limitation ?
The best workaround I’ve found to date is to format results using HTML, convert this to rich text and then use the “Quick Look” Action to view the output.
The attached example shortcut employs this technique to take details of an app (sent via the share extension from the App Store) and output them as shown in the second attachment.
Note that the Shortcut deliberately splits the HTML over multiple text actions to make it easier to see here.
Prior to Show Results being available, all the way back to the earliest days of Workflow, Quick Look and Notifications were all we really had visual feedback wise. For Quick Look, if you wanted something ‘richer’, then as you note, HTML to rich text and then view it has been the way to go. Formatting through HTML and rich text is flexible, and has quietly done the job for the past four and half years.
Unless there’s something specific that you are trying to achieve that you haven’t been able to with this, then you’ve got a great solution already.
It would be really nice to get better editing options for the text action text areas in an app update. The injection of variables at regular points makes reading it in from a separate file a pain to manipulate subsequently. But you should be able to drop the Nothing action - those are typically used for stopping input into an action where it is unwanted.
1 Like
Is this where a Drafts action - filling in a template - would help with the “interpolated variables” problem?
Potentially, it could.
Drafts has a template processing engine that will perform substitutions on double curly braced entries that represent standard variable structures (current date, title of draft, 4th-6th line of draft, etc.), and also custom ones defined by the user.
If we ported that to Shortcuts, you could use perhaps something like:
-
{{var:current date}} to sub in the standard current date variable.
-
{{var:foo}} to sub in a variable named “foo”.
-
{{dic:foo|bar}} to sub in the value of the key “bar” in the dictionary “foo”.
What we wouldn’t get is something to access magic variables. Unless we could be given a way to view the secret token the variable is assigned, then it’s opaque to us as the end user.
Similarly if we have, for want of a better term objects with attributes, like the latitude of a location. Being able to use some underlying reference for it would be ideal.
If we don’t have access to such references, we’re back to the days of setting lots of variables to access items of data. If we do have access, then we probably lose a lot of flexibility and reusability which would be a key driver in shifting things to a file; as well as improved editing of course. But it is for that reason that I think a UI improvement s probably what’s really called for here. Though a templating engine option as well wouldn’t hurt 
Thanks for the responses and helpful to know I was proceeding along the right lines.
Agree that reading the HTML from a separate template file would be a better way to do this as it would allow the use of a decent HTML editor with a preview function.
As you note, for this to be successful there needs to be a relatively simple way to substitute placeholders for variables in the template with the actual values available in the shortcut.
I’ve put together the following test shortcut that uses a dictionary to define the substitutions and a loop to apply these to the HTML text.
The first part of the shortcut defines a sample HTML snippet with placeholders (this is what would eventually be read in from a file) plus a dictionary of the substitutions to be applied utilising magic variables for the values to be inserted.
The second part of the shortcut iterates through the keys in the dictionary and applies the substitutions to the HTML text. There may be a more efficient way to write this, but it gives the idea.
1 Like
Pulling data from files wouldn’t be the issue. It is the placement of Shortcuts data into a file based layout template that is the issue - hence @Martin_Packer referencing the template processing that Drafts uses to substitute in data items by token references.
Sorry, not sure I understand your comment.
It was the token substitution challenge that I was suggesting an approach to.
So to clarify, in my example…
The “HTML Text” variable at the start represents what would be read in from the file and includes tokens delimited with double asterisks (possibly not the greatest choice of delimeter, but didn’t want to use curly brackets in case these messed up the dictionary processing later).
The 'Substitution List" is a Dictionary that uses the same tokens as keys and maps these to the relevant Shortcuts data values.
The loop then applies the substitutions thus inserting the actual Shortcuts values into the HTML ready for display.
Apologies I’d missed the bit where you said the HTML would be read from file and read it as the data 
This approach does rely on substitutions and pre-registering key values rather than token evaluation and native substitution as Drafts does it.
But the native and direct referencing really is just in the context of Martin’s query around an option Drafts has, which would provide, to some extent, a slicker solution with much less manual overhead - were it ever to become a feature in Shortcuts.
@sylumer, @RogerDowning do we think round-tripping through Drafts is feasible / desirable?
That was what I was actually alluding to, though @sylumer picked up my drift.
Feasible, yes. Desirable, that’s going to vary.
If you can’t easily get all the required data in Drafts, then it would be an obvious no.
If you can get the data, then it’s a case of performance I think. Round tripping to Drafts is slow in comparison to just running in Shortcuts, but potentially that could be balanced against ease of maintenance.
1 Like
