Great news for security-conscious users of Day One, the journaling app for iOS and MacOS. Generating and saving the encryption key on iOS was quick and easy. Getting the newly encrypted journal into the Mac app was a bit less obvious. Rather than selecting an existing journal or adding a new one, you have to sign back into your Day One account and allow the app to sync before you can see and unlock your end-to-end encrypted journal.

This humble site has seen a number of changes over the last few weeks. As more of my work of late has been focused on research, process, workflows, and strategy, I’ve been itching for ways to stretch my design and development muscles. Below is a summary of the work I’ve been doing to improve your reading experience and my publishing experience.

NightMode

Ever since I lost my Kindle Paperwhite on the flight from Brussels to Entebbe, I’ve been doing the majority of my reading on my iPhone. This has served to emphasize one of my favourite design features of modern reading apps: night mode.

Leaning on the work of Chris Coyier, I first added a simple function which changes between light and dark themes depending on your computer’s local time. Thanks to SASS, I can produce as many colour themes as I’d like just by changing a few variables.

Of course, as someone who cares deeply about his own reading environment, I wouldn’t want to prevent you from viewing the site how you’d prefer. Using some more JavaScript and HTML5’s localStorage and sessionStorage, I’ve added the ability for you to override the time-based theme to suit your own preference. I’m storing your preference in sessionStorage so it will reset the next time you visit this site.

You can have a look at how I’m doing this thanks to…

Public Github Repo

I’ve learned everything I know about design and development through experience and the generosity of others. Just last night I was having a conversation about viewing the source code of my favourite sites to see how they’re made. I did this back when I first started in design and still do to this day.

On a few occasions I’ve published some tips and tricks here on the site, but recently I’ve been thinking about how I could share even more. Of course one option is to continue writing and publishing what I know and I certainly intend to do so. However, I realized recently that by opening up the entire codebase for my site to the public, anyone can have a look under the hood and learn from both my successes and my mistakes.

Since its inception, this site has been my playground for learning and experimentation. By opening up the code for you to see, my hope is you will be inspired to follow a similar path.

Microblog

The dozen or so of you who subscribe to my feed may have noticed an increase in posts from me this past week. This is due to the recent addition of micro posts, small title-less musings that fall between longer-form posts like this one.

Back when I used ExpressionEngine to publish this site, I used to have a section called “asides”. These were always links to other sites with a bit of personal commentary. At times these links were interspersed with the long-form posts, other times they lived on their own page. Currently, the new micro posts only live on the homepage of this site.

The way I’ve designed the new micro posts makes linking to other pages optional. While some may link out, others will feel more like a tweet. Until Manton Reece’s new service, Micro.blog opens to the general public, I’m using IFTTT to post these to my Twitter feed.

Probably the best part of adding these short-form posts to the site has been the inspiration to finally find a solution to a problem I’ve faced for almost 5 years now, which was…

Publishing from my iPhone

When I had finally had enough of ExpressionEngine, I started publishing to Tumblr for one very simple reason: it was the only way (outside of using WordPress) I could see to publish from my iPhone.

While the Tumblr app is a great app, I’ve always struggled philosophically with the fact that Tumblr is a hosted service. This means someone else could shut it down or repurpose its content for nefarious purposes at any time without my consent. If the recent del.icio.us announcement is any indication, it’s not unreasonable to foresee Yahoo-owned Tumblr suffering a similar fate.

Eventually, this philosophical divide felt more important than the need to publish from my phone. At the same time, I had become far more comfortable working in terminal and decided to publish my site through Jekyll.

The transition from Tumblr to Jekyll happened over a year ago. While I’ve enjoyed publishing via the command line on my computer, the nagging desire to publish directly from my phone never waivered.

My first attempt at solving this problem was to use Siteleaf, a cloud-based platform for publishing static websites. Siteleaf provides users an online dashboard — similar to the WordPress dashboard — that allows you to publish posts and pages to a Jekyll site using a beautifully designed GUI.

As great as this experience is on a desktop, the only option for publishing through Siteleaf on mobile is though the mobile web app. Having to wait for the web app to load and not having the ability to draft posts offline made this solution untenable on the phone.

My optimal solution is to use a native app (or apps) to publish to my site. After a bit of research, I found Kirby Turner’s method of posting to Jekyll from his iPhone to be a good place to start. Kirby uses Editorial to write his posts and Editorial Workflows to publish to his site through Working Copy, a git client for iOS.

I downloaded Editorial to see what it was like and have really enjoyed writing this post in it. However, Editorial is a bit too cumbersome when I want to post a micro post. To me, those are more like tweets and should take far less time to compose than is required by Editorial.

Drafts is an app that gives you a blank sheet each time you open it. It’s the quickest way I’ve found to go from having an idea to jotting it down so as not to forget and I’ve used the app for this purpose for several years.

Posting micro posts felt exactly up Drafts’ alley, so I adapted Kirby’s approach by using Drafts to write, Workflow to run the post through a series of actions, and Working Copy to commit the post to my git repo. While publishing the post isn’t quite as quick as tweeting, it feels really good to know my content is going to a place I own and control.

Feeds

Much like the last time I added short-form posts to my site, this time has necessitated the need for new RSS feeds. This was also the perfect opportunity to familiarize myself with the new JSON feed format by Manton Reece and Brent Simmons.

Head to the new Subscribe page to see all of the feed options available as well as an option to receive a weekly digest via email.

Back to blogging

Around this time last year, I was beating myself up for not writing as often as I would have liked. I said I was going to start publishing once a week which was a foolish thing to say. I was and am still a ways away from being able to maintain that kind of pace.

But, I’m feeling more motivated than ever to write and publish thanks to the effort I’ve put into making this site a better place for you and for me.

With the recent addition of the micro posts I’m now posting on this site, I wanted to see if it was possible to syndicate the microblog to Twitter.

As I was not a Kickstarter supporter of Manton Reece’s Micro.blog service, I won’t be granted access until its public launch. Micro.blog does exactly what I’m describing in this post, but since I’m impatient I figured this would be a fun thing to figure out on my own.

My first experiment involved using FeedPress to publish feed updates directly to Twitter. I connected my microblog RSS feed in FeedPress with my Twitter account and used the following format:

${text}  
${link}

Though my first post failed to get syndicated, FeedPress successfully tweeted the micro post I published earlier today. Instantly I realized the format I was using wasn’t going to be optimal. Because FeedPress added the link to the tweet, it appeared as though there was more to read when in fact everything I had to say fit in the tweet.

Of course, there may be times when the micro post is longer than 140 characters. In this case, it would make sense for the tweet to include a link to read the rest of the post. Unfortunately, FeedPress has no way to include conditional statements to only show the link when it’s necessary.

The solution I came up with was to create and connect another RSS feed to FeedPress that was tailored specifically for posting micro posts to Twitter. Thanks to Jekyll, adding new feeds is as simple as creating a new XML file.

Determining when to add a link

In order to determine whether or not to include the link, first I need to determine how many characters are in each micro post. This can be done by running a size filter on a liquid variable, like so:

{% assign size = post.content | size %}

This will get you the number of characters in the post.content variable. While this is a good start, it fails to account for characters which are used in the post’s HTML tags and special character entities. As such, you will want to strip the HTML from the post.content variable and then escape any special characters for XML. I decided to store the cleaned up content in its own variable.

{% assign content = post.content | strip_html | xml_escape %}
{% assign size = content | size %}

Next, I need to set a condition that determines when a link should be included. Twitter allows 140 characters in a tweet, so if my micro post is ≤140 characters, no link is required.

{% if size > 140 %}
    link needed
{% else %}
    // no link needed
{% endif %}

Truncating longer posts

Now that I know which micro posts require a link, I need to know how many characters I can include before I truncate the post and tack on the link. Links posted to Twitter are shortened using their t.co service which means all links are shortened to exactly 23 characters. This leaves me with 117 characters for my post content. I’ll want to include an ellipses and a space between my content and the link, so I’m left with 115 characters.

Truncating Jekyll posts is as easy as adding truncate: 115 to the post.content variable. Unfortunately, someone at Jekyll thinks three periods is the same as an ellipsis so I had to manually add my own ellipsis.

In the end, the variable I’m passing when size > 140 looks like this:

{{ content | truncate: 115, '…' }}

The resulting code looks like this:

{% if size > 140 %}
  <description>
    {{ content | truncate: 115, '…' }}
    {{ post.url | absolute_url }}
  </description>
{% else %}
  <description>
    {{ content }}
  </description>
{% endif %}

Connecting the pipes

Easily the most frustrating part of this process has been figuring out the best way to actually syndicate the feed to my Twitter account. I had hoped to continue using FeedPress, but for some reason links were being converted into an ellipsis.

After testing a couple of services, I eventually landed on using IFTTT to pull the latest RSS items and publish them to Twitter. It seemed during my testing that it was taking its time to poll the feed and push the update. However, when I tried Zapier I found the fact that it promised to check the feed every 15 min and then failed to do so was even more frustrating.

So for now, I think my best option is to continue using IFTTT which has been reliable if not particularly punctual.

What about JSON?

When I first started thinking about this problem, I was immediately excited about getting to play more with my new JSON feeds. Unfortunately, none of the existing services I could find would accept JSON feed as a source. Admittedly, it’s still very early days for JSON feed so it’s to be expected. It does, however, cause me to wonder just how long it might take to build a simple service around the idea…

But we’ll save that for another time.

See it in action

If you’d like to see this in action, you should follow me on Twitter. If you’re interested in seeing the final code for conditionally including a link in the item description, check out the code on Github.

Edit: I made an error when I posted the original version of this article. I had failed to realize I was calculating the size of the post.content variable before stripping out the HTML tags and special character entities. The article has been updated to reflect this change.