Tag Archives: Web

How to turn a Podcast RSS feed into a website

As I wrote previously, getting started with a Podcast can be very straight forward. Todd and I wanted to add some personality to our show’s online presence, so we decided we needed a website. A lot of the information that would normally go on the website is already available in the Podcast’s RSS feed, so I started thinking about a way of not duplicating this effort. The Keep In Touch show is a hobby, and given how busy (and lazy) I am at the moment, I needed a pragmatic solution.

TL;DR

KeepInTouch.fm runs on Jekyll and is updated every time we publish an episode using our fork of the Jekyll RSS importer. We upload the episode and its metadata to our Podcast host and then we point the importer at the Podcast RSS feed. If needed, we customise the blog post and then push it to GitHub. GitHub pages then automatically updates the website.

List of requirements

We wanted the website to provide some fairly basic functionality:
– general information about the show, and a the ability to subscribe to the Podcast
– a blog/website where each episode can have its own page
– each episode page would need to privide visitors with the ability to listen to the show, and to find shownotes, links, and other relevant information

As the administrators of the website, we would need:
– a modern website: responsive, fast, and secure
– an easy to maintain set up (i.e. no hardware / software maintenance)
– a simple updating mechanism
– a simple way of transforming the information we had already provided in the Podcast’s RSS feed

The solution

GitHub Pages was the first option we considered, and luckily it ticked all our boxes. We quickly set up an organisation and picked a simple, but quite configurable jekyll theme for the site.

The only friction I still had to deal with was the “transformation” of the Podcast RSS feed into blog posts on the site. Jekyll does come with an RSS importer, so I gave that a go. Most of the metadata was extracted nicely, but there was no way to play the show without changing the post manually to link to the mp3 file that was actually available in the RSS feed.

Open Source FTW

Luckily, the Jekyll project is open source, which meant I was able to fork the RSS importer, and turn the RSS audio enclosure into an HTML audio tag. All it took was 13 lines of code.

The result

Today, my workflow couldn’t be (?) simpler:
– Record and edit the show
– Upload the episode and it’s metadata (i.e. shownotes) to the podcast host
– Run a simple script to fetch the new episode (and turn it from a feed Item into a blog Post)
– Push the new post to GitHub

If you found this post useful, please consider subscribing to KeepInTouch on Apple Podcasts, Google Podcasts, or wherever else you listen to podcasts. If you like what you hear, please leave a review. Lastly, please send us your feebdack via email or twitter @KeepInTouchFM.

Do you want to own your status updates?

After backing Manton Reece’s microblogging kickstarter I decided not to wait any longer and setup a MicroBlog section on my website where I would keep my short form updates. This post covers my goals and the approach I took to achieve these goals.

Goals

There are just a handful of things that I thought I’d need:

I own my content. I don’t mind posting to Twitter (or Medium) but the canonical location for my content is my own website
It’s easy. I can easily separate short form content (ie. statuses) and long form writing (ie. this post)
I still engage via Social Media. I can publish short form updates to my own website, and then the entries get cross-posted to Twitter
I can post from my iPhone without needed to make edits from WordPress before publishing

Approach

I tried a few approaches (involving a range of apps such as IFTTT and various WordPress plugins) before I settled on the approach below.

It’s easy to own my content

My website is currently running on a self-hosted WordPress installation. There were two options here:

I import all my Twitter posts under a special Category, or
I post on my website first and then cross-post to Twitter

Option 2 feels more like “doing it right”, and, should anything go wrong in my setup, I never lose any posts I made from my own website.

What I decided to do was to:

create a new Category called MicroBlog
update the Menu to include this new category
replace the stock RSS widget with Category Specific RSS and use it to surface the MicroBlog RSS feed into the side bar
exclude the MicroBlog posts from the main page using the Ultimate Category Excluder plugin
make all posts in Category use the post format “status” so they looks consistent and timeline-like
remove all extra post decorations (ie. sharing) from the list of posts, but leave it on the post page itself
not use a post title, in order to mimic a status post more accurately

With these changes in place I ticked the first couple of boxes. What was left was to sort out cross posting to Twitter and publishing while on the go.

Sharing status updates to Twitter / Social Media

Posting to Twitter proved to be more difficult than I thought it would be. The obvious way, via Jetpack’s Publicize feature, seems to share only the link to the post when a title is not present. Therefore I had to look for other options, although I’d much prefer to just use Publicize.

The choice I settled on is an IFTTT rule: “when a new feed item is added to parfene.com/category/microblog/feed post a new tweet to @nicktmro”. The issue with this approach is that IFTTT doesn’t have a smart way of appending a URL to the post when it is over 140 characters, so I was “forced” to append a URL to the original post. It’s not very tidy but the counter argument is that it drives traffic (and search engines) back to the canonical location of the status update.

Posting while on the go

I carry an iPhone and a Pixel with me all the time. Posting updates to my website is a task I assigned to my iPhone.

I seek speed and simplicity when it comes to capturing my thoughts, which is why I use Drafts for almost every form of text capturing. This text sometimes ends up in iMessage, or in OmniFocus, or in an email, or in my Clipboard, or in WordPress… You get the idea.

I looked at the existing Drafts actions but I soon realised that I needed to be able to post exiting text and snippets, too. I needed an extension point. Enter Workflow. By delegating the communication with WordPress to Workflow I managed to increase the ways in which I drive content to my website.

Here’s how it all works:

I have a workflow that expects text input (or extracts it from the clipboard)
The workflow presets the WordPress category, post format, etc
This workflow is added as an action to Drafts

Now I’m good to go. When I choose to share my next status update all I do is go to my usual app (Drafts), write a snippet of text, and choose the Post to Parfene.com action.

Wrap up

I encourage you to try microblogging for yourself. My post is lengthy but you don’t have to do everything in one sitting. You don’t even need to fully automate everything, like I have.

This approach has made me feel more involved, engaged, and responsible with regards to the things I share with everyone. As somebody who oftentimes doesn’t count to five before he speaks, this should be a positive outcome…

Log In – A recipe

In a previous post I was talking about the log out experience, and the contents and functionality that I think should be included on the Logged Out page. Today I will tackle the Log In page (if you really must have one).

If you must enforce the use of an account then this should happen as painlessly as possible. Both you and the user are probably in agreement that this step is required only because we haven’t yet come up with a simpler way to establish this trust relationship. Further down, you can find a few suggestions on what may become, one day, a more seamless authentication pattern.

The authentication & authorisation topic is large. In a nutshell, identity verification takes into account three factors:

Something you know (username, password, secret question, etc)
Something you have (physical token, card, dongle, phone, etc)
Something you are (fingerprint, retina scan, voice recognition, etc)

In this post I will only discuss the first point above. Even when I include items from points 2 and 3, I will do so with the intention of making point 1 simpler, rather than to increase the security of the authentication mechanism. In this post I’d like to stick to making things easier, rather than more secure.

Ingredients

The Log In page must have a few basic ingredients:

Credentials form. The focus should already be given to the first field (i.e. user id). Avoid captchas at all costs.
Password recovery link. Usually the “Forgot your password” prompt will also follow a predefined number of failed log in attempts. Care must be taken around “leaking” valid email addresses.
Sign Up option.

On top of the the above items, there are a few more ingredients that can help make the log in experience more painless:

Language switcher. If you’re site is localised, then this is a must have. Always include the current UI language in the list of available languages (so that the user always knows that they can switch back to it).
Password privacy toggle. Some passwords can be quite complex. If the user is in the privacy of their own home they may prefer to see what they’re typing.
Remember me. I’m not a huge fan of this option. I feel like this toggle is better placed in a global settings area of your site.

Recipe

Twitter’s Log In page is minimalistic

Mix all the must have ingredients above, add your preferred nice to have items and you should get a pretty decent log in form. Rather than me drawing up a log in form, I chose to complete the picture and include the log in forms for the sites I mentioned in the Log Out post.

Facebook is not confused; it’s on a mission

Notice how Facebook almost gives more priority to the Sign Up process. That is probably tied into their drive to get more users onto the platform (warning: pure speculation). The other very interesting thing about Facebook’s Log In page is just how similar it is to their Logged Out page. Can you spot the difference?

For some inspiration, have a look at this set of Mobile Log In pages.

One day

Here are a few suggestions on how authentication could, one day, be simpler.

Trust my location

If I Log In from the a certain location (IP / WiFi / etc), there are no other people using the site, I always use the same browser, etc then maybe you can “assume” it’s me. Maybe you can prompt me to allow you to make that assumption?

Delegate the identity check

To my phone. If my mobile device has just started using the same public IP, or is in the proximity of the device that I am trying to Log In from, you can probably “assume” it’s me. If you want to be sure, maybe you can build support for Handoff / Continuity in your site and trust my mobile device to do the authentication.

Voice sign in

What if there was an app on my computer that I could start and I could say: “log me in to Facebook”? This app could check my voice, unlock my keychain, extract the credentials, start a browser/tab and fill in the form for me.

Log Out – Please take me with you

Your user has logged out (Signed Off, Logged Off, Signed Out, etc). What happens next?

Many online experiences end there. I believe that to be a missed opportunity. The page that gets displayed to the user as a result of logging out is an integral part of the online experience that your site provides.

Why has the user logged out?
A few reasons spring to mind:
1. they want to switch accounts
2. they’ve been inactive for too long and the system logged them out
3. they have finished using the site and they use a shared computer

These are just three possible reasons, but they are probably enough to draw some quick conclusions about what a good log out page may contain.

What should the logged out page be?
Regardless of the reason why the log out took place, the user should be shown a confirmation message. They need to know that their wish was granted, or that they have been logged out for some other reasons (such as their inactivity).

Facebook invites the user to “stay connected”

Twitter asks the user to get the apps

Reasons 1 and 2 above virtually require that a log in form be present on the page.

Reasons 2 and 3 can be regarded as an opportunity for reaching out to the user with an invitation to continue their interaction with your site through a more personal channel, a channel that is secure and omnipresent: the user’s mobile device!

Why not remind the user about your mobile app, or your mobile website. Tell them to take you with them by installing your app. Better still: make the most of features such as Continuity to allow the user to continue their session on their mobile device.

The rest of the content that should go on this logged out page is not so obvious. It’s not just a matter of taste, it’s also a matter of personality. You can consider the user disengaged and show them an ad. Or you may take this opportunity to strengthen your brand. You may even go all melodramatic and put a “sorry to see you go; please come back soon” message.

Whatever you decide to do, just try and think of this page as an integral part of your product. Don’t think of it as the end of the line and you may end up building an avenue for increasing engagement and retention.

Apps vs. Websites – The ownership perspective

This topic has been covered time and time again. Typically, these articles cover a mix of technology, performance, ROI, look and feel, and other such metrics.

Today I’m going to suggest that the end user’s ownership of an app (as opposed to a website) is one criteria that businesses should consider when making the decision to build a Native App. I’m also proposing that building a Responsive Website is no longer an option, but an expectation.

In 2014, even the cheapest smartphones come with HTML5 capable browsers! End users do not and should not have to understand why a website is different, and sometimes even feels alien, when viewed on a mobile device. The time when we had to compromise on mobile because of technical reasons is long gone. Let’s leave this here.

If the mobile browsing experience is in the same class as the browser experience then why should you even consider an app?

Unless you’re planning to build an amazing app that you plan to support long term, keep up to date with the fast evolving mobile UI/UX, in which you utilise the mobile platform paradigms to the point that the user feels like it was built in collaboration with the designers of the first party apps, then you probably shouldn’t build an app.

The subtlety here is that it all boils down to the fact that you own your website, but the end user owns your app.

If the user has a bad experience on your site, they can’t get rid of your mobile optimised (hopefully responsive) website. Your links will always work, even if they remove all shortcuts or bookmarks. A short url, a web search result or an ad will always be able to bring them back. When they’re back you’ll have a chance to make them change their mind and convince them to return in the future.

On the other hand, if the user has a bad experience with your app, they can simply forget the app ever existed on their device. They will delete it and they’ll do that almost as a punishment for your failure to delight them. Deleting the app will close all the communication channels once provided by that medium: all extensions and widgets will be gone, all URL schemes will seize to function. The reality is your app is competing with potential photos of their friends and family, or with another app that is more in fashion than yours.

The end user owns your app because they install it, they dedicate disk space to it, and they can get rid of it if they choose to. They are in complete control of this lifecycle and, you may not realise this, this lifecycle has financial and psychological implications.

Unlike accessing your website, when installing your app the user is likely to be asked for their password (or fingerprint for Touch ID). Even if your app is free, the psychological connection is made: they acquired your app. They are now using disk space just to have your app around.

Your app must be delightful, it must add value every time it’s used, otherwise the user will eventually run out of patience and delete it. Once they do, you will face a big uphill battle to convince them to give your app another try.

There is no such psychological attachment to your website because the user is not involved in the site’s lifecycle. They usually just “ask” a search engine for it. When they run out of space for their next photo they won’t think which sites they can remove…

If you can’t build a delightful mobile app, then you’d better have an amazing responsive website. The reality is though, that if you don’t have both, then it’s likely that you’ll never be the first port of call for a mobile user.

Nick Parfene

Technology. Community