This would make a great blog post

Dave Winer will sometimes link to the above image as both a reminder, and perhaps chastisement, that we should own our words and our creations.

But, despite what the terms and conditions on various services say, the practicalities of this are harder than ever.

Social media has increasingly taken the conversation away from blogs and we respond in situ because, if we don’t, people are unlikely to follow links to read our response.

Ain’t nobody got time for that 1

We suffer from the inherent importance of context in our fast paced, online world.

Thoughts & fragments

We have many thoughts sent out as tweets, Facebook posts, and comments or replies; fragments, quickly captured and just as quickly forgotten, when they should be more deeply explored and exist as complete entities rather than throw-away artefacts.

This was all brought to mind when I saw Tweedium, a tool to combine tweet storms into Medium posts. While many of our tweets etc. are frivolous we must recognise the importance of things we say in the social sphere and that they should have a more prominent, permanent position instead of being washed away in the stream.

Blogging and social need a reboot but this is unlikely to happen as the networks want to retain control even as they advocate openness.

We need enhanced interoperability. We need to be able to write where we want and flag it as a response to something elsewhere, to embed what we have written in situ so that links don’t have to be followed.

How do we do it?

There has to be a culture of sharing and embedding social objects: an extended “article” card type in Twitter to display full posts – maybe the AMP version of a page; cross-publishing a blog post to Medium and then retrospectively marking it as a reply to something else, for example.

There are ways it could be achieved if only there is the will.

We may have linking and cross-posting but we need the networks to develop and adopt tools allowing a more flexible migration of data, if not between the different social platforms, at least between platforms and external sites.


  1. To quote the meme 
This would make a great blog post

Google’s messaging bait and switch

Most will tell you that Google doesn’t get social, many will even take great delight in doing so.

Buzz was a decent offering with a good community vibe, but was hampered by being solely within Gmail and forever tarnished by the initial privacy snafu.

Google+ was a bold move with great potential but most didn’t seem ready for the approach taken with it: everything linked to identity; a social layer as much as a social network. And privacy advocates decried its reach.

Google pulled away from its original intent once it became apparent that people (and regulators) didn’t want social tied to everything leading them to refocus on Communities.

Then came Spaces – a seemingly cut-price version of those communities for small groups, but even this is being criticised for poor implementation.

Not a good track record.

Leapfrogging the competition

Jamie Davidson wrote an incredibly insightful post in which he posited that Google’s new iOS keyboard – Gboard – was a way for Google to disrupt the messaging landscape dominated by Facebook with Messenger and WhatsApp. A seemingly brilliant plan to insert itself into every other platform and usurp their power.

Davidson argues that chat and messaging is now the killer application on mobile and, if you factor in Mike Elgan’s notion that social networking is slowly dying in favour of private networking, you can’t help but see the pattern.

But there’s more.

As soon as I saw the announcement of Google’s new messaging app Allo my instant reaction was that this might actually be a remarkably clever power move by Google.

People love Gboard saying it is the first 3rd party keyboard on iOS that can really hold its own and be a viable alternative to the standard iOS offering. By having search integrated into the keyboard you avoid much of the need to switch out of the host messaging app – an incredibly powerful proposition.

But, placed alongside the announcement of Google Assistant, it is almost as if Google is saying “Gboard is powerful, we know you like it, but just imagine how much better it would be if it was integrated into its OWN app.”

Bait and switch.

Google is being criticised for having too many different messaging apps with overlapping remits – almost a throw enough at the wall and see what sticks approach.

This time they could be on to something.

Although we still have a while before Allo launches, the only thing that surprises me is that Gboard wasn’t released much earlier, and far wider than just the US, to give users more time to get hooked. Bait and switch but with an improved payoff.

It’s a clever ploy that might just work.

Google’s messaging bait and switch

Improving the Medium plugin for WordPress

Between Facebook’s Instant Articles opening to all and the Medium posting API we are entering an age of distribution: post once, publish many. Publishers and bloggers can retain control over their own space but take advantage of the network effect inherent at other properties to gain traction.

The Medium plugin for WordPress is a good start for writers not wanting to migrate their blogs, but currently feels unfinished; there is more that can be done to make it a truly effective tool.

Here are a few ideas:

User configurable link text

When enabling the option to cross-link posts between your blog and Medium (and why wouldn’t you?) the plugin inserts the line “Also published on Medium” at the end of your post.

As I don’t have comments enabled on my blog I have edited the plugin so that the line reads “Leave a reply on Medium” – a subtle difference which also gives a reason to follow the link. The only problem is that any time the plugin gets updated I have to re-make this change.

By adding a custom field to WordPress to hold it, the plugin could even support per-post text allowing for contextual customisation rather than always using a default value.

Having the ability to change all this via a settings UI would be a very nice touch allowing bloggers to personalise or brand the text and really get creative.

Original v modified

Toggle using the featured image

If your blog post has a featured image the plugin appears to use that as the leading image for your Medium post. If the original WordPress post includes the same image at the top this leads to duplication when cross-posted.

Current options are to either publish your post without a featured image, avoid the duplication and add it later or edit the Medium version of the post to remove the extra image.

Adding a toggle to ignore or include the featured image would stop this and reduce the need for any follow-up action after posting.

Tagging

The benefit of “post once, publish many” is that it reduces the friction associated with distributing your work across multiple platforms.

As with featured images, it is also frustrating that after hitting Publish you have to visit Medium to tidy up and add tags to your post.

It would be incredibly helpful if any tags applied to the WordPress post (or the first three if there are more) were passed to Medium and also applied there.

Edit replication

Currently, the plugin is a one time, post only affair where any changes made to the original version do not get replicated to the Medium version of the post. Syncing edits between versions of the post are high the wish list.

Obviously this is more of a technical challenge, and would involve more work, but I don’t see why it wouldn’t be possible. The Medium app allows editing so the API obviously supports it.

Any changes made within WordPress could then be synced to Medium so that readers would have access to the same version of the post regardless of where they see it.

Stable

The plugin is a pleasure to use And is incredibly stable and, beyond the annoyances above, I have never had an issue cross-posting. With a few tweaks, however, it could be completely frictionless.

Improving the Medium plugin for WordPress

It’s all about the meta!

The news that Twitter may soon exclude links and images from the 140 character limit has been widely greeted with cries of “it’s about time.”

Some were, however, equally disappointed when the rumoured increase to 10000 characters was rejected by the board in favour of retaining the existing flow of the stream.

We have been able to embed various media in Tweets even before the launch of Twitter Cards, so why not larger blocks of text?

But it could go further.

Twitter is live, is now, but we cannot solely rely on 140 character snippets and videos. Despite what appears to be in vogue, live video is not the great panacea for online services. Mobile connectivity has improved dramatically over recent years but there are still many dead zones and relatively low monthly data caps that often make live video impractical.

Besides, believe it or not, people still like to read!

Having real time updates on current events is fantastic, especially when they are from eye witnesses, but what we gain in speed we often lose in clarity. Inaccuracies and bias can manifest. It is, therefore, good to have more in depth pieces follow the initial reports which have the important luxury of being fact checked.

News breaks on Twitter so why not also host it after the event?

Facebook has Instant Articles, Google has AMP, surely it would make sense for Twitter to provide for something similar; publishers could embed a news article or blog post directly in a tweet (rather than just a link) so it is native, pre-cached and instantly loaded.

As with Instant Articles, ads could be sold against these articles and the revenue split between publishers and the network. Maybe bloggers could even get in on the action encouraging more to cross post.

Looking at the examples of Facebook and Medium it appears that – at least part of – the route to success is to be both publisher and platform.

Perhaps Twitter should follow their lead.

It’s all about the meta!

Drafts and Ulysses: a (very) quick comparison

I do everything on my phone including blogging, both the actual writing and posting.

I’ve been writing on my phones for years, always having the phone with me means that I can tap down thoughts as soon as they strike. But actually transferring that to the blog used to mean sending the text to myself and doing the backend tasks on a PC.

Improvements with both hardware and software mean that we can now be fully mobile bloggers without recourse to desktop operating systems and applications.

Since Automattic introduced native Markdown support for WordPress via the Jetpack plugin it has been easier than ever to write and publish. I recently took some time to rethink how I write, deciding to stop experimenting and focus on one app: Drafts 4.

I first used Drafts a few years ago before switching to Android for a couple of years (mainly due to the desire for a larger screen) so it was natural to come back to it after returning to the iPhone. It gives me almost everything I need.

Almost.

My post on workflows was conflicted, torn between making the most of what I have versus alternatives. I wanted to examine exactly how I write and what I need.

In truth I need very little.

It might, therefore, seem somewhat contradictory to begin looking at another app, another workflow, but the opportunity to beta test Ulysses on my iPhone (with the inclusion of direct WordPress publishing) was too good to pass up. I had not, previously, been able to justify the cost of the app sight unseen so beta testing is a great way to “try before you buy” whilst providing useful feedback to the developers.

Why another app?

Writing in Markdown is so simple, it’s just plain text after all; you don’t even a special app as long as you’re familiar with the simple markup. So why the need to try multiple applications that do a very similar thing?

As I wrote, there is always the hope that a different app will contain a feature set which streamlines the process and makes life simpler. Most Markdown editors take a similar approach so what could a different app offer to sufficiently differentiate itself?

In this case, the prime draw is native WordPress support but I have also been impressed by the glowing reviews. Along with other apps (such as Byword) Ulysses already supports posting to Medium, since I decided to relaunch my blog and cross post this is no longer a key factor – an extra “nice to have.”

Rather than write full reviews of both apps (this has been don’t more than adequately elsewhere ) I wanted to outline some of the areas that affect me as an end user, as a writer and compare the approaches taken by each.

Perhaps this is more for my own benefit, to search for the best workflow and decide where I am willing to compromise or not.

So let’s get into it

Being text editors that excel when using Markdown, Drafts and Ulysses might seem to be very similar – there is a good amount of overlap between them – but they take different approaches to similar problems.

File management

Both apps adopt standard email nomenclature: Inbox, Trash and (in the case of Drafts) Archive, but how each handles this is different:

  • Drafts lets you create filters to view a set of files, e.g. different sections of a project. All files will be in the Inbox or Archive
  • Ulysses works on a more traditional folder structure you might see in an email application and items are moved explicitly to folders

Both approaches are perfectly adequate, although Drafts filters require you to add specific text to files if you want to be able to group them together in this way. Think of them as Search Folders in Outlook.

Section/paragraph organisation

When writing we are often working with brief ideas, parts of a whole that we expand and move around to achieve a best fit and flow. This is implemented in a fashion in both applications albeit in separate ways:

  • Drafts has an overview mode that lets you drag paragraphs around within a single file
  • Ulysses, instead, has you split the file into sections and arrange these instead within its folder structure

A combination of the two would be preferable. Ulysses’ approach is obviously targeted towards larger blocks of text such as chapters. Dividing these larger sections would become unwieldy over time so the ability to easily reorganise paragraphs within them would be a welcome addition.

Drafts, on the other hand, would benefit from the manual sorting of files in a filter view providing users with true control over different parts of a project.

Commands and customisation

Both apps utilise an extended keyboard, an additional row of keys above the normal keyboard providing access to formatting, special keys, and other functionality beyond the simple act of typing. The approach each takes, however, is remarkably different:

  • Ulysses has a singular purpose: to enable you to write and the writing stays within the app. Although it can be used for anything, it is designed with longer works in mind. Because of this Ulysses feels much more structured (I deliberately don’t want to use the word rigid as that might have negative connotations). All of the additional keys and formatting options are always available housed within the three function buttons on the extended keyboard. You can choose which markup variant you prefer, which in turn limits the available commands, but that is it.
  • Drafts, on the other hand, is designed as a textual starting point. You begin in Drafts but the aim is to move the text out to other apps depending on what you’re writing. Notes, tweets, emails, reminders, anything; Drafts is built on flexibility and customisation. While it can be used as a self contained writing stage (and this is largely how I have been using it) this is not really where it shines.

Drafts v Ulysses extended keyboards

I deliberately wanted to outline these points before comparing the developer-written descriptions of the two products on the App Store:

  • Drafts, where text starts on iOS. Quickly capture text and send it almost anywhere!
  • Ulysses for iPhone and iPad is your one-stop writing environment on iOS.

The descriptions lay out their respective positions very succinctly. The interesting thing, however, it that because Drafts is so flexible it can be used as a one-stop writing environment with a little sacrifice whilst still being able to share shorter pieces of text with any other app that supports its methods.

Ulysses has a core purpose and, as such, is unable to replicate what Drafts can achieve due to this intentional lack of customisation, but that won’t cause any sleepless nights for it’s developers I’m sure.

Which is better?

When two applications approach a similar goal in such disparate ways it is incredibly hard to form an opinion on which is better, especially when they are not being used entirely to their strengths.

Simple, clean writing environments are now de rigueur, a distraction free experience essential. There is no help here for the indecisive.

Personal preferences normally count for so much. On this occasion, however, both apps are a pleasure to work with. Maybe it does come down to specific features like native posting support.

Oh, and before you ask, this post was written in Ulysses.

Drafts and Ulysses: a (very) quick comparison