Tag Archive for ‘Workflow’

Reports of Workflow’s Death Have Been Greatly Exaggerated ➝

Federico Viticci:

In the first update following Apple’s acquisition in late March – and despite rumors that claimed the app would no longer be supported – Workflow has today restored some of the features that were removed in version 1.7.3 of the app (which was released when Apple confirmed the acquisition) and has brought a variety of changes and improvements, including new Apple Music actions.

I don’t know if this update is a sign of things to come, but it’s nice to know that Workflow hasn’t been completely ignored by its developers since the acquisition. And the inclusion of new actions in this update gives me renewed hope for the future of the most important tool in my iOS arsenal.

Workflow Team Has No ‘Further Updates Planned’ ➝

Benjamin Mayo, writing for 9 to 5 Mac:

Via iGeneration, it seems that the Workflow app is in maintenance mode and unlikely to gain any new features in the foreseeable future. According to an email reply a user received from Workflow support, there are no ‘further updates planned’ for the automation app although they will continue to maintain its existing functionality — presumably with occasional bug fix releases.

I had unreasonably high hopes that Apple would continue to develop the Workflow app into something much more powerful than it is today. But unfortunately, that doesn’t appear to be the case. We shouldn’t expect anything more than bug fixes going forward.

I don’t think most Workflow users will turn to alternatives anytime soon, though. Primarily because there aren’t any other good options. Launch Center Pro and Pythonista immediately come to mind, but one of them is too underpowered while the other has a high barrier to entry.

The last remaining hope for iOS power users is that the team behind Workflow are currently working on a replacement, built from the ground up within Apple, that will ship before Workflow no longer functions. We won’t be seeing any new features until then, but as long as what we have now continues to work, I think it’ll turn out okay.

Apple Acquires Workflow ➝

Matthew Panzarino, reporting for TechCrunch:

Apple has finalized a deal to acquire Workflow today — a tool that lets you hook together apps and functions within apps in strings of commands to automate tasks. We’ve been tracking this one for a while but were able to confirm just now that the ink on the deal is drying as we speak. […]

Workflow the app is being acquired, along with the team of Weinstein, Conrad Kramer, Ayaka Nonaka and Nick Frey. In a somewhat uncommon move for Apple, the app will continue to be made available on the App Store and will be made free later today.

I couldn’t be happier for the Workflow team. They’ve built one of the most innovative applications for iOS and grown it into an absolutely essential piece of any iOS power user’s arsenal.

I would typically be concerned about the app’s future in situations like this. But Workflow will continue to be made available in the App Store, for free, and this has me hopeful. I expect subsequent versions of the app to have access to much more powerful actions with APIs that aren’t available to third-party developers.

The Best Lock Screen Widgets for iOS ➝

A great list of iOS widgets by Lory Gil. I make extensive use of widgets in both my iPhone and iPad, checking them several times each day. Here’s my current setup on iPhone:

And on iPad, I also use Omnistat’s battery widget, PCalc, and CornerTube.

Ulysses 2.6 ➝

Mike Bates, on Ulysses 2.6:

I’ve been part of the TestFlight group that’s been using the beta throughout it’s development cycle, and it’s a terrific update to what I’d call my favorite app. […]

The app is what I consider to be the best writing environment for the most people. It’s well-designed, well-equipped with features, is customizable to fit your liking, is developed by an attentive & small(er) team, and all gets out of the way when you need to get down to writing.

I’ve been in the Ulysses beta group for several months, as well, and couldn’t have been happier with this update. I still use my own workflow for publishing to WordPress, but I’m excited about trying Ulysses’ native solution soon. From the sounds of things, it’s incredibly well thought out and offers all of the features I need for my own unique setup.

Push to WordPress v1.1

Push to WordPress Date Picker

When I shared my original workflow that publishing text in Ulysses to WordPress, I knew it wasn’t perfect. When run, Workflow asked for the URL slug, tags, post type, custom field contents, and didn’t actually publish the post — only saving it as a draft, meaning you’d have to hit publish from the WordPress dashboard. All of that has changed with version 1.1 of Push to WordPress.

What makes all this possible is the new template I’m using for writing. I first discussed the new template when I shared my Launch Ulysses Workflow and more recently mentioned it in my update to Push to Ulysses. The latest template is only a slight modification of the original, but makes a world of difference when paired with this new version of Push to WordPress.

The Writing Template

The first line of my template is always the title and uses a second level header for feature articles and a third level header for links. The different headers are important because the workflow uses that information to determine what category to use when publishing and whether or not to look for custom field content.

The second and third line of my template is the URL slug and tags, respectively. This data is grabbed by the workflow with a regular expression and passed on to WordPress automatically. This is perhaps the most important change from the previous version because this information is now saved in Ulysses alongside the post content, rather than only existing in your WordPress database.

After the post tags I leave a line of white space followed by the post content. The white space is there to provide a visual differentiation between the contents of the piece and the administrative information. It could probably be omitted if you’d prefer to — I haven’t tested it, but I’d love to hear if you do.

And when I’m composing links, the URL I’d like in the custom field is placed on the very last line of the Ulysses sheet. This is also separated from the post content by a single line of white space, for clarity. Push to WordPress (v1.1) only looks for custom field content when you’re publishing a link — again, differentiated from feature articles based on the title’s header level.

The Workflow

Push to WordPress (v1.1) is all about streamlining the publishing process. I grew to hate the numerous prompts I was given after initiating Push to WordPress and I made every effort to eliminate as many as possible. I’m happy to say that the new workflow asks for a single piece of information when run — the publish date.

Setting the publish date wasn’t even a feature of the original Push to WordPress workflow. The idea was to give myself an opportunity to preview the piece from WordPress’ dashboard before scheduling it to publish. In real world testing, though, I was almost never hitting the preview button. Rather than continue to pass the user off to Safari to set the publish date, I’ve implemented it within the Workflow.

But there are still occassions where I’d like to preview a post before it goes live. For those instances I’ve added a Copy to Clipboard action immediately following the Post to WordPress action. What this does is save a URL to the clipboard that uses the article’s post ID. If you’d like to preview before publishing, simply choose a future time for publishing and paste the URL into safari after the workflow’s completion. If anything looks off, you’ll have the opportunity to fix it before it goes live.

Another major pain point with the previous version of Push to WordPress was that the workflow asked you to choose the custom field URL from a list. This was due to my own hesitation about allowing workflow to grab it automatically. I was concerned that I’d end up with the wrong URL in my custom field and used the Choose from List action as a crutch.

My concerns weren’t completely unfounded, though. I did run into a problem when publishing links to Daring Fireball articles. After some testing, I realized that Ulysses automatically inserted backslashes, on imported text, before characters that would normally be used to markup text in Markdown. I remedied the bug by implementing a Replace Text action that swaps any instance of a backslash followed by an underscore in the custom field location with just an underscore. Now, as long as you’re following the template guidelines, Push to WordPress (v1.1) never uses the wrong URL or a botched URL for custom fields.

Push to WordPress Version 1.1

Push to WordPress (v1.1) is activated from the “Run Workflow” action extension, when viewing Ulysses’ export screen, and performs the following process:

  • The exported text is saved as the variable “Raw”.
  • The top line of text is isolated with a regular expression, converted to rich text, capitalized with title case, and the result is saved as the variable “Title”.
  • Workflow loads the original input text, removes the first line, and save as the variable “Sans Title”.
  • The new top line is isolated with a regular expression, changed to lowercase, any spaces are replaced with dashes, and the result is saved as the variable “Slug”.
  • Workflow loads the variable “Sans Title”, removes the first line, and saves the rest as the variable “Sans Title Slug”.
  • The first line of “Sans Title Slug” is saved as the variable “Tags” and the rest as the variable “Sans Title Slug Tags”.
  • Workflow asks you to input a date and time and sets it as the variable “Date”.
  • Workflow gets the variable “Raw” — the original input text — and looks at the first line to see if it’s written as header 3, which would indicate that you’re publishing a link.
  • If you’re publishing a link:
    • Workflow gets the variable “Sans Title Slug Tags”, and looks at the last line for URLs, removes any backslashes preceding underscores, and saves it as the variable “Link URL”.
    • The bottom line of “Sans Title Slug Tags” is removed and what’s left is converted into rich text and passed to the Post to WordPress action.
    • Workflow publishes the post with the proper title, tags, URL slug, publish date, and custom field data.
    • The resulting post’s URL is saved to the clipboard for previewing.
  • If you’re publishing a Feature article:
    • The variable “Sans Title Slug Tags” is converted to rich text and passed on to the Post to WordPress action.
    • Workflow publishes the post with the proper title, tags, URL slug, publish date, and custom field data.
    • The resulting post’s URL is saved to the clipboard for previewing.

It’s important to remember that this workflow is designed to accept plain text, written in Markdown, from Ulysses (these are my export settings). My guess is it’ll work with any text editor that can export Markdown as plain text, but I’ve only ever tested it with Ulysses. If you decide to give it a go with another editor, let me know how it works for you.

And of course, it’s unlikely that you’ll be able to use this workflow right out of the box. I doubt there are too many people that have the exact same needs and setup as I do. But the great thing about Workflow is that you can borrow, alter, and extend upon other users’ work until you have ts something that suits your needs. Just think of Push to WordPress (v1.1) as a starting point for your own publishing workflow.

If you’d like more context about where this workflow came from and my thinking behind its initial build, my piece introducing the original version — alongside links to download it — will continue to be available.

Push to Ulysses Version 1.1 ➝

I’ve published a small update to my Push to Ulysses workflow. The new version uses my new writing template — originally discussed in Launch Ulysses Workflow — and makes use of Workflow 1.5’s Ulysses integration.

Upload Image Version 1.1 ➝

I’ve published a small update to my Upload Image workflow. The new version automatically resizes images wider than 2048px to help reduce file sizes on high-resolution photos.