Tag Archive for ‘Ulysses’

Backwards Compatibility for Ulysses ➝

Marcus Fehn, writing on Ulysses’ weblog:

We have always tried to be backwards compatible as best we could. Sometimes, this meant supporting four years worth of old systems, for the very small number of users still on one of these systems. While it didn‘t hurt much, it still hurt, because with every new device, every branch of every OS, we had to come up with (and maintain) explicit solutions for the old systems. At present, Ulysses runs on iOS 10 or later, as well as OS X 10.11 El Capitan or later. Some stuff was tricky.

Going forward, we will switch our policy to a simple rule of thumb: Support the current system, as well as the one that shipped before. It’s much more efficient, and it helps us move a bit faster. So once the new systems are live this fall, any new version of Ulysses will require either iOS 12 or macOS 10.13 High Sierra.

Marcus goes on to explain a bit more about why they’ll be supporting High Sierra after Catalina releases this fall — mostly because some of their users still use 32-bit apps. But I absolutely love how open and honest the folks behind Ulysses are about this. As we move further into an era where subscription-based apps are the norm, more developers should be making these sorts of policies public.

On Negative Reviews of Apps Transitioning to Subscription Pricing ➝

Matt Gemmell:

The important point is that, if you’re able to readily switch to a different app when your current one changes its payment model, then… do it. Just vote with your wallet, and don’t worry about it. To write a pissy review of an app you liked yesterday, in an attempt to vengefully damage their business, is pretty reprehensible, right? It’s like giving one star on Amazon because the delivery was late. Don’t be a child. Move on.

Ulysses made it very easy, either subscribe or don’t. And if you aren’t interested in paying for a subscription, it doesn’t mean you have to quit using the app entirely. The version you had before the subscription announcement will continue to work until a future operating system update breaks something. And that isn’t likely to happen until iOS 12 is released next year.

But I Already Paid for It?!?! ➝

Eddie Smith, in response to the “why do I have to pay (again) for software I’ve already purchased?” arguments, in the wake of Ulysses’ move to subscription pricing:

The software you paid for is still “yours” in the sense that it is fully functional (as you paid for it) and will continue working indefinitely. You “own” it, and it’s not going away.

Will it work forever? Hell no. Software isn’t the same as a cast iron skillet. Software isn’t going to work the same 100 years from now. It’s probably not even going to work 100 weeks from now without being nursed through the vagaries of operating system updates, security patches, and user-expected support. When the developer of a cast iron skillet is done, they’re done. When the developer of a piece of software is done, they’re out of business—because if a developer quits, so does their product.

I love this analogy.

Ulysses Switches to Subscription ➝

Max Seelemann, writing on Medium about the thought process behind their new business model:

I am not exaggerating in saying that this was the hardest decision in our whole time as professional software developers. After all, we have a system which currently works — after 14 years we are still around, Ulysses is still “a thing”, it’s even going better than ever before, and there are no immediate signs which hint at a change coming soon.

So why bother at all then? Well, we need a good way forward before we run into trouble. We want to make sure the app will be around for years and years to come. We want to heavily invest in its development, and this requires the right setting for our team, our families and our users. Writers want to rely on a professional tool that is constantly evolving, and we want to keep delivering just that.

I’m not a huge fan of subscription pricing, but Ulysses is the best writing app I’ve ever used and I don’t plan on switching anytime soon. The pricing is about as fair as one could expect when compared to what other companies are charging. I would have preferred it be $20-25 a year, but they didn’t come to these price points flippantly. And I can certainly appreciate that they’re offering the yearly subscription at a reduced rate for a limited time.

Markdown Comes to Simplenote ➝

From the Simplenote weblog:

Today we’re excited to announce that Markdown support has been added to the latest update of Simplenote for iOS.

To enable Markdown for a note, just tap on the ‘Markdown’ button in the note info panel. You can then swipe on the note editor to view the Markdown preview. Once you’ve enabled Markdown for a note, all new notes you create in the future will have it enabled by default. We hope you enjoy this handy new feature!

I’ve been using Simplenote ever since I moved away from Vesper last year. It’s a great app, but unfortunately, this new Markdown support is far from robust. There’s no inline previews or shortcuts to help with the syntax, which I would consider to be essential features. I’ll continue using Simplenote as my notes app of choice, but I’ll keep my Markdown writing in Ulysses.

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.

Backup and Restore in Ulysses ➝

Alisdair Daws:

Ulysses handles backups automatically. (My iPhone asked if I wanted to correct that to automagically. I was tempted.) The default setting is for Ulysses to keep hourly backups for the past 12 hours, daily backups for the past 7 days, and weekly backups for the past 6 months. You can also make a backup yourself at any time.

I’ve used Ulysses everyday for months and had no idea it was keeping Time Machine-like backups of my work. But I’m not surprised to hear that this feature exists — this type of attention to detail is the reason I chose it as my primary writing app.

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.