Apr
15
2013

When we announced a new format for linked posts last week, I hadn’t set up a proper workflow to create linked posts on the iPhone and iPad. Driven by annoyance, I put together a Drafts action and a bookmarklet to help me post links to WordPress with or without additional text and quotes.

Our linked posts use a custom field to link back to the original source and format the clickable titles that you see on the site. Tom Witkin’s Poster is my default app to publish posts on MacStories from iOS, and, fortunately, it has support for calling and assigning values to custom fields from the URL scheme. On the other hand, Agile Tortoise’s Drafts, my favorite app to chain multiple actions together, can launch custom URL actions differentiating between the first line of a note and everything else after it. That seemed like a good opportunity to separate my source URL from any possible text I wanted to add to a linked post. (more…)

Mar
13
2013

pythonista

In January, I tried to put together a bookmarklet to send the webpage currently open in Google Chrome for iOS to Apple's Safari. That turned out to be a surprisingly complex effort as Google didn't think offering an “Open In Safari” option would be a good idea, and the app's URL scheme produced some interesting results when opening and closing Chrome.

I was reminded of the bookmarklet this morning by reader @CNWLshadow, and I realized that I never posted the solution I settled with. It consists of a browser bookmarklet and a Pythonista script, and it works with just one tap.

(more…)

Feb
10
2013

A few weeks ago, I took a look at the automation possibilities opened by Drafts, Agile Tortoise’s multi-purpose text app. In the article, I mentioned how a bug prevented Drafts from “linking to itself” more than once:

Therefore, my idea for cross-posting was: I can link to Drafts itself, and if the first action is successful, I can link to Drafts itself again. Essentially, I wanted to leverage the built-in App.net and Twitter actions to avoid the use of any third-party app. Unfortunately, there’s a bug in the current version of Drafts that doesn’t make that kind of action work.

With an update to Drafts released yesterday, Greg Pierce has brought various improvements to the app, including support for more customizable timestamps and dates using strftime, date and time tags for file names and URL actions, and a new way to encode strings with curly brackets.

Seemingly minor, the option to more easily URL encode strings is actually a very welcome addition: like in the latest Mr. Reader, instead of forcing the user to encode a URL into a longer string, you can simply put a URL inside {{ }} and let Drafts take care of encoding it. It means I can now experiment with building more complex workflows that contain actions for more external apps and, more importantly, for “sequential” tasks in Drafts itself. Easier encoding means we construct URLs that will tell Drafts “do this, and then do that” in a single workflow.

Those who follow me on Twitter know that I’ve been trying since yesterday to see how many apps I could chain together in a workflow, mainly out of curiosity and as a “proof” of concept. First, I tweeted about a Mr. Reader -> Drafts -> Poster workflow that would take selected text from an article, convert its Markdown to HTML, and then send it to Poster; the workflow consisted of three apps chained together, but I knew I could try to accomplish something a bit more ambitious. I kept on experimenting with Drafts URLs, and eventually I managed to build a single workflow with 3 apps and 4 different tasks involved. I’m posting it here for two reasons: a) I believe it’s a quite useful workflow; and b) it can serve as an example of what Drafts can do when you understand how to properly link multiple apps together. (more…)

Poster is my favorite iOS app to post articles to WordPress. I recently took a look at version 2.0 and the improvements developer Tom Witkin made to further streamline the app’s posting workflow. Today, Tom released another update that adds support for custom fields to the URL scheme and brings 1Password integration.

Like other apps have done in the past weeks, Poster now sports a 1Password button when setting up a new site that requires authentication. The button will take you directly to 1Password, searching for “wordpress” by default. Once you’ve found your login item, you can copy the password and go back to Poster. I believe this sort of non-forced integration is really nice and ultimately beneficial to the end user, as it makes using multiple apps for a single task less cumbersome. (more…)

Jan
22
2013

When there are no actual news or notable app releases, I prefer investing my time in creating something for other people.

Continuing my ongoing series of tips on iOS URL schemes, here’s an adaptation of my existing Due bookmarklet to work better with Google Chrome for iOS (which, as I’ve pointed out several times, has a very nice URL scheme). The following code (to install it, simply copy it and paste the entire string into a bookmark) grabs a webpage’s title and URL and sends them to Due (also powered by a great URL scheme). (more…)

Sort of. Here’s a fun experiment.

Today, I wanted to quickly send a URL from Chrome for iOS — my default browser — back to Safari. I know there are ways to do Safari-to-Chrome, but I wanted the opposite: from Chrome back to Safari. I needed to install some custom Mr. Reader actions, and Chrome was giving an error when tapping on the downloadable files. I figured I could make a bookmarklet to take the current webpage in Chrome and send it to Safari.

Not so fast. There’s no documented URL scheme on iOS for opening web links in Safari, except, well, the http:// scheme itself. In testing various bookmarklet ideas, I thought that replacing googlechrome with http in Jon Abrams’ bookmarklet would force Chrome to send a link to Safari. But as It Turns Out™, doing this sort of trick in Chrome for iOS:

javascript:window.open('http'+location.href.substring(4));

…simply opens a new tab in Chrome.

What I ended up using is a hack — and a very curious one — to leverage Chrome’s support for x-callback-url to open a link back into Safari. I was inspired by Cormac Relf‘s script, which I discovered yesterday when he showed me another script he made for Pythonista.

javascript:window.location='googlechrome-x-callback://x-callback-url/open/?url='+encodeURIComponent(location.href)+'&x-source=Safari&x-success='+encodeURIComponent(location.href);

As you can see above, we’re telling Chrome to open a new tab using…itself. The trick, at least theoretically, is to use an encoded location.href string to call back Safari, which is registered for the http:// scheme that Chrome, in this case, opens “externally”. Displaying x-source is needed per Google’s URL scheme specification; the name you give to x-source will be displayed as a “back” button in Chrome (as shown in the image above).

This is a profoundly inelegant and ultimately flawed solution. To make this “work” you have to:

  • Type the bookmarklet’s name, because Chrome has no bookmarks bar;
  • Nothing will happen.
  • Close Chrome;
  • Re-open it;
  • A wild new tab appears!
  • Tap the Safari button. It’s super-effective.
  • Safari will launch the link, closing the additional tab Chrome decided to open.

What is going on, exactly? Via JavaScript, we’ve forced Chrome to open a tab in itself, but doing so with x-callback-url inside a bookmarklet creates, for some reason, quite a strange behavior: the tab isn’t opened unless you close and re-open Chrome, therefore partially defeating the whole purpose of this bookmarklet, which is to quickly open a webpage in Safari. But, in spite of the clunky process, a new tab with a “Safari button” is created nevertheless, allowing you to tap it to launch Safari and close Chrome’s extra tab.

My conclusion is that we have three solutions: a) it’s not possible to create a straightforward Chrome-to-Safari bookmarklet; b) it’s possible in another way that I haven’t explored; or c) it’s possible with the x-callback-url hack, but in a different way.

If you have ideas, ping me on Twitter.

Jan
15
2013

Poster 2.0

Posted by at

Tom Witkin’s Poster is my favorite WordPress blog editor for iOS. Poster comes with a clean interface, support for Markdown (the app can convert plain text Markdown to HTML before publishing), and full WordPress integration. The app’s excellent support for WordPress features like custom fields, drafts, slugs, and images means I don’t have to write on the iPad and later “adjust everything” on a Mac before publishing. Poster is, in fact, a core aspect of my iOS automation workflow.

Poster 2.0 is out today, and it’s another fantastic update that reassures me Tom is committed to making this app the best WordPress editor for iOS. The interface has been further refined, and it’s now easier on the eye with an even deeper focus on content rather than UI chrome. I don’t use these for MacStories, but Poster now supports WordPress custom post types and excerpts, alongside the “sticky” functionality that we use every once in a while to pin a post to the top of the site.

What I like about Poster 2.0 are the “minor” additions that make for a much better workflow. Custom fields can now be given a local label so that a friendlier name will be displayed in Poster instead of the actual name (e.g. “URLCustom_linked” becomes “Linked post”); the Markdown preview and HTML conversion now handles en and em dashes (something that annoyed me in the previous version of the app); if you edit a published post (as we usually do when we catch typos or make corrections), you can now save the edited draft locally before publishing. I also appreciate how the “Copy to Clipboard” action now only received a post’s URL (Poster 2.0 builds on the solid foundation of Poster 1.0 for post sharing), and the app is noticeably faster at syncing multiple posts at once.

There are two more changes I want to mention. You can now insert images at any point in the editor by tapping & holding and selecting the “Insert Image” option from the popup menu; I tend to do all my image insertion beforehand, but this is a welcome addition for those times when I may forget about an image. And last, Poster now supports Greg Pierce’s x-callback-url to return to a specific URL after completion. Poster already had support for a URL scheme that allowed post creation from other apps, but now you’ll also be able to create a post and return to another app.

Here’s a bookmarklet I made to grab a browser’s selection and use it as text in Poster, get a webpage’s title and use it as post title, open Poster, and return to the browser. This kind of URL callback enables a streamlined workflow for, say, discovering links in Safari, quickly posting them to WordPress, and going back to Safari again.

javascript:window.location='posterapp:///create?text='+encodeURIComponent(window.getSelection())+'&title='+encodeURIComponent(document.title)+'&callback_url='+encodeURIComponent(location.href);

I also made a quick video showing the process in action. Unfortunately, getting the browser’s selection only works on the iPad.

Poster is a great app, and while not revolutionary, the 2.0 update refines several aspects of the previous version and adds more powerful functionality for WordPress users and iOS automation geeks. I highly recommend it.

OmniFocus Browser Bookmarklet and Safari 6

Ever since upgrading to Safari 6 and Mountain Lion, I’ve noticed the OmniFocus bookmarklet I had installed stopped working properly. The OmniFocus bookmarklet is a handy addition to my workflow, in that it allows me to quickly save webpages I need to act upon at a later date, while preserving their title, link, and text selection. I often do this for linked posts that end up here on MacStories, or pages that I need to check out but that I’m not ready to bookmark yet (for that, I use Pinboard).

In theory, the OmniFocus bookmarklet should be capable of grabbing a webpage’s URL and selection (if any) as a note. However, of the two bookmarklets provided by The OmniGroup, none of them manages to successfully grab text selection on my machine running Safari 6 and OS X 10.8.1. So I set out to find a better bookmarklet, and I found this version by Alex Popescu that, besides working correctly, has also some nice integration with Gmail.

For Gmail, the bookmarklet creates a new task with the email title as the task title and a note with the current selection (if any), plus a from line in the form: From: email subject:(email subject) email_thread_url. For normal web pages, the bookmarklet creates a new task with the document title as the task title and a note with the current selection (if any), plus a from line in the form: From: page_url.

I tested this on Safari 6, and it works as advertised. The bookmarklet also works on iOS devices, albeit the iPhone’s Mobile Safari can’t send the current text selection from a page to OmniFocus.

Get the bookmarklet here.

Tap-Translate, a $1.99 universal app by developer Ronen Drihem, brings an interesting approach to translations on iOS, and more specifically in Mobile Safari. Tap-Translate, in fact, isn’t exactly an “app”: it’s an app whose only function is to let you install a bookmarklet in Safari that will let you tap on a word on any webpage to get an instant translation inside a cute yellow popup menu.

It works like this: once you’ve followed the steps provided by the app to install the bookmarklet (which allows you to choose from a variety of languages), you’ll find the bookmarklet in Mobile Safari (works on any iOS device, but I’ve also tested it in Chrome and Safari on the desktop) ready to give you inline translations on tap. The translation’s popup allows you to “speak” a selected word, or jump directly to the Google Translation page. Tap-Translate can also do entire paragraphs, and be dismissed at any time. It’s fast, easy to use and convenient.

At $1.99 you could argue you’re spending money to install a bookmarklet. The thing is, Tap-Translate works really well and, most of all, it’s integrated with Safari and it’s unobtrusive. Recommended.