Testing on Blot

Testing Out Blogging on Blot.im

I set up a test blog on Blot, which is effectively a Markdown based blogging platform with which you save your posts to a Dropbox folder, and the system does the rest from there.

Its kind of cool for Micro.blog type usage, and the cool thing is it is a true IndieWeb environment as the files sit in your own Dropbox account.

I had previously played around with a similar service (Scriptogr.am), although when that went away[1] I focused on just my WordPress blog. I have however moved across all the files from the old Scriptogr.am blog, and that content is live on my site.

Today I set up a combination of a Workflow workflow and a Draft action to simultaneously post new micro-posts created in Drafts to both sites.

I will also take a look and see whether I will push all my Markdown files for longform posts to both sites. For this post, for example, I will publish to the WordPress blog from Byword, then move the file to the Blot Dropbox folder.

Whats the advantage of doing this?

  1. Playing around with a new platform is kinda fun.
  2. Backing up my posts in a reusable format.
  3. Somewhere to redirect people if my WordPress site goes down.

Interesting times.


  1. Looking at the Scriptogr.am website it appears that some new social media app/tool is coming soon to that domain, with a very similar logo.  ↩
This post also appears on:

7 Reasons Why Posting on your own blog (first) is better than Medium

Over on The Writing Cooperative, a blog hosted on Medium, Anna Sabino writes about 7 Benefits of Writing on Medium over Having Your Own Blog.

In this post, Ms Sabino articulates 7 reasons why posting to Medium have worked for her. I suggest that she is missing an important opportunity—to write first on her own blog, with the post syndicated to Medium, and then on to the group blogs such as The Writing Cooperative.

I’d like to take a look at Ms Sabino’s seven points, and add some thoughts to back up my perspective. My thoughts in italics follow Ms Sabino’s comments in bold.

  1. It’s faster to build a sticky traffic on Medium. The sticky traffic likely comes through the journals (group blogs) on which the original post is being shared, and would be the same with content created on a self-hosted site and syndicated to Medium.[1]
  2. It’s motivating when you see your posts are being read. Undoubtedly true. But having your posts syndicated from your own site out to Medium and potential other places is going to multiply that same effect by taking your content to more audiences, not just the audience that reads Medium.
  3. All the blogs are in one place. I don’t know the stats on how many blogs Medium hosts, and what percentage of the overall number of blogs that comprises. I’d hazzard a guess that it is much less than ‘all’ the blogs, and likely in the single digits.
  4. Medium interface is very clean and pleasing to the eye. And pretty much identical to every other blog on Medium, and you are subject to the possibly changing tides of Medium’s design aesthetic. As John Gruber notes “every Medium site displays an on-screen ‘sharing’ bar that covers the actual content”..
  5. The exposure on Medium, which gets over 30 million visitors a month is huge. Basically the same as point 2.
  6. Medium shows up high in google searches. Yes, and if the syndicated post on Medium links back to your original post, the search engines will find the originalbl post even more quickly. Both copies of the post will be discoverable by readers, not just those that read Medium.
  7. You can start a blog on Medium instantaneously. As can be done with a WordPress blog and in the near future a Micro.blog. Self-hosted WordPress blogs can easily be setup on a range of hosts.

I quite like Medium, and regularly read posts on it. It is in fact how I came to find Ms Sabino’s post. I syndicate many of my posts there. It is a decent source of readership, and to be honest I should submit more articles to journals.

Medium, however, has the inherent problem of being someone else’s playground. They might pack up their toys and go away, taking our content with them. Or they might start putting our content behind a firewall, reducing potential readership. They may even monetise our content without sharing that with us.

Because it is, ulitimately, their platform.

The problem is the same with any other environment that you don’t own (yes, that would include WordPress.com and others).

I personally prefer to maintain my own blog, which is a WordPress blog hosted on independent servers. This blog then syndicates to a couple of places. This is the spirit of POSSE – Post to Own Site, Syndicate Elsewhere.

Most long-form posts are syndicated in full to Medium and Tumblr, with the titles of these long-form posts sydicated to Micro.blog and Twitter. Micro-posts just go to Micro.blog and Twitter.[2]

I might (re) add Facebook and/or LinkedIn syndication at some point. These would actually be the biggest multiplier of readership. But I prefer quality over quantity, and the quality of commentary from Micro.blog readers, in particular, is outstanding, while there is a lot of noise from Facebook and LinkedIn (in my experience).

I don’t discount the effectiveness and importance of Medium. I would just advocate owning your content and syndicating to various platforms as being a far more resilient approach.


  1. Ms Sabino herself acknowledges that contributing to The Mission and The Writing Collective are the source of the immediate exposure.  ↩
  2. I treat all my (original) Tweets (i.e. not replies to other Tweets) as micro.posts, which start in Micro.blog and are syndicated to Twitter. If Twitter goes away I still have my original content. At least from when I started doing this. I wish I had downloaded a copy of all my app.net posts…  ↩
This post also appears on:

App Support for iPad Centric Workflows

Its been some two years since Apple announced iOS 9, complete with iPad split screen and other multitasking functionality.

My iPads Pro are a key part of my writing, productivity and increasingly, photography, workflow. This is even more the case since the announcement of iOS 11, and all the incredible new iPad Pro centric enhancements.

Most of the apps I use on a daily basis to support my workflows have embraced and support iOS multitasking, including the split screen functionality. These apps include:

  • Bear
  • Byword
  • Draftsd
  • iBooks
  • Lightroom
  • Medium
  • Micro.blog[1]
  • OmniFocus[2]
  • ProtonMail
  • Reeder
  • Slack
  • Spark Mail[3]
  • The Photographers Ephemeris
  • Timepage
  • Tweetbot
  • Ulysses
  • V for Wikipedia
  • 500px

The list of apps that have refused to provide support for iPad Pro users is, fortunately, much shorter.

  • Affinity Photo
  • Flickr
  • Kindle
  • Pocket

I can kind of forgive Affinity as its quite a new app, and in the photography editing space which kind of develops a whole screen mentality.

But Kindle and Pocket are core reading/research/writing workflow apps. To be core to these types of workflows, the apps need to support iPad Pro type functionality.

Kindle holds a near monopoly, but Pocket has competition. I can’t help but wonder whats holding them back.

Doing this personal analysis of the core apps in my workflows it is pretty pleasing to see that most apps are well positioned to support the growing importance of iPad in a mobile lifestyle. And it is pretty telling to me that at some point I will need to make a call about apps that don’t support my workflows…


  1. Which was only released today.  ↩
  2. And I am pretty sure most other Omni apps  ↩
  3. And other apps from Readdle  ↩
This post also appears on:

On Likes, Faves and Sharing

I’ve been thinking a little more about what Jack Baty wrote about the notion that likes on social networks should be private.

Jack suggests that likes (and faves, and hearts, and…) should be visible only to the “Like-or and the Like-ee”.

For the Like-or, Jack’s approach allows them to keep a list of things they have liked, and to send a vote of thanks to the author.

The Like-ee receives said vote of thanks[1].

Personally I like the first part – a list of the things I have favourited in a service like micro.blog would be a useful thing. If there was a JSON/RSS feed, or if I could use an API to do something with things I favourite with a service like IFTTT, then I could do useful thing with those Favourited items, such as:

  • add them to a link blog
  • add them to a bookmarking service like Pinboard
  • append the item to a note or next actions list

These are good uses of Likes and Favourites.

The second part – the vote of thanks – could be a good thing, if (and IMHO ony if) that aspect is private as Jack suggested.

The problem I am seeing is that many people put very little thought into Likes ’and Faves.

Clicking a link to Like or Favourite favourite takes a single second, and even less thought. People do it routinely, move on and often give no more thought whatsoever to the topic.

IMHO, the best way of registering thanks and supporting the efforts of the author is to take a few moments and to write a meaningful reply — perhaps in a comment, or better yet perhaps by making your own (micro) blog post — and linking back to the original.

What I am suggesting is to take mindful action, expressing what it is you like in a way that gives real feedback to the author.

Sharing is important, because as micro.blog user John Johnston mentioned, curation is important. One of my key personal uses of micro.blog at the moment is as a link blog for interesting things I’ve stumbled on across the web[2].

Sharing has the potential of increasing the audience for content by exposing it to your audience, hopefully leading to healthy discourse about content and the ideas behind it.

The mindless liking of ‘stuff’ has the potential of a dumbing down thinking. By liking and faving we may well only be providing mindless positive reinforcement, and avoiding critiquing stuff.

Lets face it, a lot of stuff that is being shared on the web really needs to be critiqued.

Ideas get better, and the world gets better, when we, collectively, are willing to deeply consider and develop ideas, share those ideas and be willing to receive honest and considered critique.

Its nice to receive positive feedback, but it may not be healthy to receive only positive feedback.

Ideas need to be shared, and ideas need to be challenged.

Micro.blog users Jean MacDonald and Shannon Hager have both recently on undertaking what Jean referred to as a ‘Like fast’.

I think this has potential – let’s stop mindlessly liking stuff, and mindfully replying to, critiquing and sharing ideas.

Starting with this post.


  1. Not on micro.blog, where at the moment favourites are visible only to the Like-or.  ↩
  2. Of course, it goes without saying that sharing an idea for discussion doesn’t mean endorsement…  ↩
This post also appears on:

Micro.Blogging — The Future of Short Form Blogging?

A while back I wrote a post called The Micro Blogging Evolution Begins, in which I discussed being a Kickstarter backer for the Micro.Blog initiative by Manton Reece@manton.

Since then I, and other Kickstarter backers, have experimented with this new platform and its iOS app (developed by @manton). Some of the initial users are lurking, some haven’t really done anything with it (yet), and the rest of us are trying to see how it fits into our writing.

At its core, micro.blog is a way of making short blog posts, either on your own, existing, blog, or on a hosted micro.blog. As a Kickstarter backer, I have both — this blog at DesParoz.com and desparoz.micro.blog — and have been playing around with both approaches.

The key to micro.blog is that regardless of where you host your content, it is on your own platform, but then there are powerful social interaction tools. The stream is comprised not of tweets inside a “walled garden”, but instead of micro posts from all over the web that are loosely coupled to gain interaction.

Noah Read described micro.blog well in an excellent blog post:

Micro.blog is a social timeline, similar to Twitter, where you can post short snippets of text with links and photos, and converse with others. The biggest difference from most other social networks is where these short posts come from. They come from people’s own websites, where they control the content and can do whatever they like. Micro.blog aggregates its feeds from each member’s personal site and gives people chances to reply and favorite content on the the service.

You should take a read of Noah’s post to get a better understanding of micro.blog.

Blogging pioneer Dave Winer emphasised the importance of owning your own content, and not being constrained to fit the format of platforms in a post on wanting his old blog back:

Before 2010, on my blog, I could have long and short items. I could use HTML. Link to as many places I wanted, where ever I wanted. There was no character limit, so the short items could grow if they needed to. The same format could accommodate post-length bits with titles that were archived on their own pages. Every item appeared in the feed, regardless of length, regardless of whether it had a title.

I think Dave nailed it nicely with this post[1]. Over the years since blogging took off platforms like Twitter, Medium, Facebook and others have sprung up and provided various “solutions” to people sharing ideas, thoughts and content online. In the process they created (at least) three problems:

  1. The content has to be shaped to a fit a platforms requirements (e.g. 140 characters); and/or,
  2. The content has to be shaped to fit algorithms (SEO); and/or,
  3. The content ends up in a “walled garden”, in which it is virtually (or actually) owned by the platform.

micro.blogging forms a part of the Indie Web approach where content owners should own their own content, where they focus on writing, designing or otherwise sharing content for humans first (perhaps primarily, or even just, for themselves), and not to serve an algorithm.

Another key aspect of the Indie Web is the concept of POSSE wherein a writer publishers first on their own platform, and then syndicates to other platforms. This post for example will be published first on DesParoz.com, and will syndicate to my micro.blog and Twitter feeds as well as to a mirror site on Tumblr and perhaps to Medium.

micro.blog and IndieWeb tools are important parts of this process. The ‘glue’ that helps to bubble the underlying content up into the social web.

The potential of micro.blogging is best expressed by blogger and micro.blogger Colin Walker in an excellent post on the State of Blogging:

Blogging seemed to die back for a while but, as I wrote more recently, getting involved with the Micro.blog and, now, #indieweb communities has meant finding people who are, again, enthusiastic about their own sites.

So where does it all stand for me?

My main site here at DesParoz.com will continue to be the home for my content, including micro posts. My hosted (paid) micro.blog site will be a link blog, and the overall micro.blog feed will marry up all my content, providing the underlying social glue.


  1. As I am about to publish this site, I’ve just noted that Dave has also published about why he won’t point to Facebook posts  ↩
This post also appears on:

The Micro Blogging evolution begins…

I backed Manton Reece’s Micro.Blog Kickstarter, and have today received my Micro Blogging beta account.

I love the concept that you own your own content, hosting it on your personal blog and your personal micro blog, and then cross-posting out to other sites and feeds. We should all own our own content, and not trust that the various social media platforms will stick around and play nice.

micro.blog definitely in its early stages, with even functions like finding other users still quite complex (although it is apparently coming soon). If you’re not reasonably tech-savvy, I’d recommend waiting until the beta is over (or at least in later stages). If you are tech savvy, join the conversation.

Masterful story-telling in the first trailer for Star Trek: The Force Awakens

Like most people who have a love for sci-fi, I eagerly watched the first trailer for Star Wars: The Force Awakens yesterday. [1]

After watching the trailer for the fifth or sixth time I started to really notice the masterful story-telling – exemplified in the words and tone; and the vision and music.

Words and Tone

In the entire 60 second clip there are only 15 words spoken:

There has been an awakening; have you felt it?

The dark side… And the light

In those words we can see a couple clues:

  1. he dark and light sides of the force have been dormant since the timeline of The Return of the Jedi
  2. Both have awakened

What was equally telling was the tone used – clearly the tone used was spoken from the darkside, with the voice over having a distinct Emperor Palpatine feel about it.

Vision and Music

The trailer starts with what appears to be the planet Tatooine [2] with some level of chaos as people and droids run from something. We then cut to an organised force of Stormtroopers amassing.

Ultimately we then see vision of what seems to be Han Solo’s spaceship, Millenium Falcon as the classic Star Wars score kicks in.

I am looking forward to the new movie[3], and I am excited by what appears to be a strong foundation of masterful story-telling at the hands of JJ Abrams and crew.


  1. OK, actually I probably watched it ten or more times.  ↩

  2. The same planet which featured at the commencement of the original Star Wars (aka Episode IV or A New Hope).  ↩

  3. Star Wars: The Force Awakens is due to be released on 18 December 2015.  ↩

Ello to the future of social media?

Thomas Hawk on his movement from Facebook to ello.

I’ve been increasingly disappointed with my experience on Facebook. I find that fewer and fewer of my friends are seeing what I post and engagement is increasingly going down.

I’m seeing more and more “sponsored” posts and advertising crowding out organic content, which probably plays a part in this…

I have danced with completely deleting my Facebook account for quite some time. There are a few reasons why I haven’t done so yet, but I view content there occasionally and post content there rarely. When I do post to Facebook its generally reposting from a blog post, or cross posting from my Instagram feed.

Again, Thomas Hawk nails it:

I feel respect for my content on Ello, which is shown large in full high res glory. This is why I put more of myself into my art and photography on Ello than any other site. The respect feels greater.

I am playing with ello too (find me at ello.co/desparoz and will certainly try out posting some images and words there to see what feedback I can get.

For me, for now, DesParoz.com remains my main venue to posting content (images and words), but some social media will continue to play part of communicating that – and will be an increasingly important part of the conversation that continues after the post. [1]

I have lots of questions about the future of Ello, but at this time Ello is seriously interesting.


  1. While comments are currently still enabled on DesParoz.com, I prefer the conversation to happen elsewhere – such as on the commenters own site, linked back, or perhaps now on Ello. I like John Gruber’s approach of keeping the site clean, an approach that sites like Re/code are now following.  ↩

Apps for Fever Update


Last week I published a post on the State of Play for Fever RSS and Apps, providing an overview of the iOS and OSX apps available to support Shaun Inman’s brilliant, self-hosted, RSS system Fever.

After a long period of little development on the app front, this last week has seen some exciting developments. I hope these new developments are a sign of things to come. I plan to review each of these separately over the next week or so, but thought a quick update would be worthwhile.

Fever Apps for Mac OSX

ReadKit – OSX (US$4.99)


ReadKit is a wonderful tool for Mac OSX, providing support for browser based reading and sharing services like Instapaper, Pocket, Pinboard and more, in a native app. It has already been an important part of my workflow for sometime, and the addition of support Fever in the beta of version 2 is an exciting development.

Whether you’re a Fever user or not, ReadKit should be a part of your reading workflow.

Fever Apps for iOS

Sunstroke – iOS Universal (US$4.99)


Sunstroke has displaced Reeder as my go-to Fever RSS app on iPhone, and since the release of version 1.4 last week, on iPad. Sunstroke has support for a wide range of social sharing and read later services (almost as wide as Reeder), and it has a gorgeous UI and a UX (user experience) that works best with my workflow.

At US$4.99 (A$5.49), Sunstroke is well priced as a universal app [1] and I suggest that this is the one iOS app for Fever, at this time. The developer is extremely responsive on App.net and Twitter.

Ashes – iOS Universal (US$5.99)


The Ashes app has been (re-) released as a universal app for iOS devices at an introductory price of US$5.99 (A$6.49). According to the website, it will increase to US$8.99 from 9 May. Ashes fully supports all native features of Fever, and has an elegant design. It is visually pleasing to use, and seems very stable.

At US$5.99 Ashes is appropriately priced for a niche product that supports both iPhone and iPad, and makes a good choice for someone wanting an all round app for Fever. The developer is actively talking to users on Twitter and App.net.

Reeder – iPhone (US$2.99)


Version 3.1 of Reeder for iPhone was released during the last week. This added support to the iPhone version of the app (which already supports Fever) for Feedbin.

Clearly the developer is focused on iPhone and Feedbin at this time, and so we will have to wait a while longer for iPad and OSX support for Fever. With apps like ReadKit and Sunstroke, this is no longer the problem it was only a week or so back.


  1. In the State of Play article, I mentioned that I thought Sunstroke was overpriced. Compared to Reeder as an iPhone only app, that stood. But for a universal app for iOS, the price is just fine!  ↩

Backing Up – Securing Your Files for the Present and the Future

Backing Up – Securing Your Files for the Present and the Future

In an increasingly paperless world more and more of our data is being digitised. While offering many opportunities, there are (at least) three challenges presented by this:

  1. Backup of data in case of loss or destruction of the host system;
  2. Accessibility of the data by others in the event of your inability to do so yourself; and,
  3. Usability of the data into the future (i.e. future-proofing).

Every inhabitant of the digital world needs to consider ensuring they maintain their data for now and into the future. This article addresses some of how I approach these tasks.

Over on SimplicityBliss, Sven Fechner recently outlined his comprehensive backup and emergency data access strategy for Mac.

Today I have not one, but effectively four different backups of my data. Three of them are always up-to-date, while the fourth one is the ‘nuclear event’ offsite contingency.

Sven has very ably outlined an approach that addresses the first two points in detail, and I’d suggest you read his article and digest his approach.

My own approach is not dissimilar, at least for three of the four levels described:

  1. Onsite backups with Time Machine (I use Time Capsule for MacBooks and an old Drobo for my iMac);
  2. Data in Dropbox (aff) and Evernote, protected with strong passwords and 2 factor authentication (Dropbox only for now). I am also playing with the Transporter for having my own distributed data.
  3. Cloud backup using Crashplan.

As for the third consideration – future-proofing – we need to think very seriously about whether the masses of data we’re producing daily today will be readable into the future. We have an unprecedented opportunity to capture data for future generations, but we have a responsibility to ensure they will be able to read it.

There are two aspects to this problem – the storage media and the format the data is stored in.

Try listening to an old mixtape you made on an actual cassette tape. I’d bet that most people couldn’t find a (working) cassette player in their house, so unless you drive an old car, you’re quite likely out of luck! Having as much stuff in the cloud as possible deals with at least the media part of the problem, as most cloud solutions will incrementally migrate their storage media, progressively over time. You should do the same at home.

As for the format, this is an equally important consideration. While it might be inconceivable that your current .doc, .jpg or .xls files might not be readable in decades to come, try opening an early 1990’s WordPerfect document. I dare you.

I don’t have a crystal ball, and have no idea as to what formats will be readable in the future. But my gut feel tells me this:

Storing your data in the most raw form possible gives you the best chance of being able to read it into the future

In other words, applying as few photographic enhancements as possible, or using little or no rich text formating is your best strategy for future proofing your data. If you’ve tried to “restore” an old photo, you’ll know you have more chance if you can use the original film (or negative) than if you use a print. If you’ve tried to scan old, heck, even read old text, you’ll know that the simpler the font the better.

My two main forms of data that I want to preserve are my photos and my writing.

I capture all photos in RAW format, and I keep the raw files of the keepers. Backed up.

This is also one of the benefits of having made the decision to write in plain text, using Markdown. Seriously, if you write and you don’t write in Markdown, go and learn more about it. It’s not difficult, and there’s even a great book to help you learn Markdown.

I only wish that I had started writing in plain text sooner. Some of my old writing is literally locked up on on 5.25" floppy disks in WordPerfect format. I have a project to do something about that.

We are in the digital era. Being productive in this era means backing, ensuring others can access if and when needed, and ensuring your data is available now and into the future. I urge everyone to consider an appropropriate backup startegy, including an offsite solution like Crashplan. I also suggest that you learn more about future proofing your data by using the simplest possible formats for storage, including Markdown for plaintext.

How do you backup? And how do you future proof your data?