Ever wanted to track the changes to a webpage but found there was no easy way of doing it? The Hillingdon Council website makes this easy by generating an RSS feed for every page.

At the bottom of each page there’s a “Subscribe to this page” link and feed icon. The site also makes these feeds easy to find by putting them in autodiscovery tags, providing a consistent way to subscribe in each browser.

Using RSS as a mechanism for receiving page status updates makes much more sense than writing a custom subscription system and requiring user registration such as on Sutton Council’s website.

There’s plenty of scope for Hillingdon to produce more comprehensive specific feeds for other uses but this is a very useful feature in its own right. Combined with a feed-to-email link on every page to a service like Feed My Inbox it could see a lot of usage.

Let’s also remember that there’s more to life than RSS. Other feed formats and APIs are more appropriate for different types of data such as iCalendar for events.

1. Validate your feeds

It only takes a moment to validate a feed. Invalid feeds can cause all kinds of unexpected weirdness in feed readers and other applications. Find any errors and fix them.

2. Use autodiscovery

People that use feeds a lot love autodiscovery. It provides a consistent way of finding and subscribing to feeds from any website. Put an autodiscovery <link> tag on your home page for every feed you’ve got and a tag on every interior page that’s got its own feed, eg. a tag for the news feed on the news page.

The standard tag format for RSS autodiscovery is:

<link rel="alternate" type="application/rss+xml" href="http://www.anytown.gov.uk/news.rss" title="Anytown Council News" />

and for Atom autodiscovery, use:

<link rel="alternate" type="application/atom+xml" href="http://www.anytown.gov.uk/news.atom" title="Anytown Council News" />

3. Use standard feed icons but only as direct subscription links

Whether you’re using RSS or Atom feeds, the standard feed icons are the common “beacon” style ones from Feed Icons. Get rid of the old orange rectangular “RSS” and “XML” text icons if you have them — they’re obsolete.

But don’t use the feed icons as illustrations. They should be clickable links directly to the feeds themselves so that people can subscribe. Avoid using them to link to RSS help pages or anything else.

Think: When I see this icon, I can click on it to subscribe.

4. Put your feed icons at the top of the related content

In-page feed subscription icons should be placed as near to the top of the related content as possible. Don’t bury the icon at the bottom of a list of news headlines, or even worse, in your page footer or a sidebar. Try to reinforce in your readers’ minds that the feed is an alternative way of viewing the same content.

5. Check your feeds in an RSS reader

This will often show up odd things in your feed that a validator won’t catch — like all your item dates being the same, for example.

6. Don’t lose your subscribers when your feed moves

If your CMS will let you, publish your feeds at permanent URLs. If it won’t, you’ll lose all your subscribers when you move to a new CMS and the URLs change.

If this happens, use an HTTP 301 redirect to tell your readers’ clients that the feed URL has changed permanently. Here’s how you do it.

Alternatively, proxy your feed through FeedBurner which will give it a permanent URL (and a few other toys to play with like usage stats, too).

7. Don’t offer the same feed in more than one format

People have got better things to do than to try to decide whether they want to read a feed in RSS 2.0, RSS 1.1 or Atom 1.0 format. Choose a single format for your whole site and stick with it. In practice, all formats work in all applications anyway. It gives you less to maintain and one less thing to worry about.

8. Shorten your item links if they’re longer than 255 characters

Some RSS reader applications use 255-character long fields to store item links. Some links are longer than that and will be truncated (and therefore, broken). If your CMS serves up item URLs longer than 255 characters try to run them through a URL shortening API like TinyURL first so they’ll always work.

9. Write a sensible feed title

The bit in your feed’s <title> element is what gets displayed as your feed’s title in RSS readers and other applications. Usually this should be your organisation’s name and a short indication of the content, eg:

• Anytown Council News
• Anytown Council – what’s on
• Anytown Council Job Vacancies

Far, far too many feeds just have either the “Anytown Council” or the “news” bit, forcing users to rename those subscriptions in their readers if they’re going to make any sense at all.

Here are some bad examples from the Mash the State database:

• Council Website Updates (but which council?)
• Events (for who?)
• Jobs Vacancies (sic)
• Latest Online Consultations
• Travel Information
• www.anytown.gov.uk::Latest News (get rid of all that clutter)

10. Create an easy subscribe-by-email service

Many councils provide email alert services to keep their residents up to date. This is a lot of hassle, having to deal with bounces, unsubscribes and maintaining the whole mechanism. If you’ve got RSS feeds it only takes a moment to let people subscribe to them by email using third-party services like FeedMyInbox.

You can create a direct subscription link like this:

http://www.feedmyinbox.com/?feed=http://www.anytown.gov.uk/news.rss

This is how we do the black subscribe-by-email links on Mash the State’s council pages. You get a whole email service for nothing without having to pay a penny or do any more work at all. Just like with RSS in general.

Got any more good tips? Leave a comment and I’ll work them into the article here.

Enjoy.

I’d like to emphasise a point that Emma Mulqueeny has alluded to in her seven principles for digital engagement and which I also made in passing in my previous article on building local news mashups.

The web is rife with discrimination of the most insidious and socially-destructive kind. It largely goes unnoticed as those that are well-served by the web care little for the plight of those that are not.

I’m talking about the web’s widespread discrimination against machines.

Conventional thinking about “websites” focuses almost wholly on human users. In the best-case scenario, people turn up to a website, find the information they want or do the thing they want to do, then go away again. If the website is useful and provides that information or service, and if it’s usable and accessible, people can do what they want to do with a minimum of fuss and effort and be satisfied.

Many websites are a long, long way from being able to provide a good experience for human users but I doubt many don’t have it as their goal, however ineptly they may deliver on the details.

By contrast, providing for machine users mostly happens either as an afterthought or not at all.

Machine users are other programs, websites or software systems that could interact with your website by extracting data, inputting data, or both.

The simplest example is an RSS feed fetching a list of news articles or job vacancies. By providing an RSS feed, a website makes it easy for other programs to capture that information and re-use it in any way possible. They might republish that information largely as-is, combine it with information from other sources in a mashup or even derive statistical information from it. Or all of these things.

More generally an API allows information to be read from or posted into another system. Can humans search your website? Then provide a search API for machines. Can people place orders and make payments online? Then provide an ordering and payment API. Every form on your website should have an API that makes provision for machine users to post in data and get a machine-readable response. Every sequential collection of information should be available as a feed.

Providing for machine users by building APIs and serving feeds is ultimately about serving human needs. Until machines achieve some kind of consciousness they will neither know nor care about accessing information on other systems. Every program is written by and provides information for people.

APIs make it possible for people to write programs to use your information and services in ways that suit them, in ways that you can’t anticipate, in ways that you don’t have the resources to provide, through systems that you won’t have to maintain. Many organisations won’t like this. It means the creation of infinite new layers of intermediaries, third-party services that provide new interfaces to your information and services or whole new applications that combine your services with others’. If you think you can provide the best interface to your services for every conceivable context you’re a fool. If you think you should be the sole gatekeeper of your services then prepare to lose your customers to other businesses or see your citizens disappear to third-party services implemented through any means necessary.

Let’s snap out of abstractions for a moment and look at an example.

As an activist with Living Streets I’m always on the lookout for maintenance issues and faults on the street, particularly where they affect pedestrians. I can report street faults directly to my local council or I can use FixMyStreet, a national service that ostensibly does the same thing.

I always use FixMyStreet. Why?

• It’s easier. The user interface is better.
• It’s geographically agnostic. I can report a fault anywhere in the country without having to know which authority is responsible for it.
• It’s public. There’s a lot of value for me in being able to see other people’s street reports as I’m interested in looking at the wider issue of urban design and maintenance, not just getting a specific fault that bothers me fixed. I can browse other fault reports and see statistics for each borough.
• It’s flexible. I can get reports sent to me by email or through an RSS feed. I can file a report on an iPhone and soon through many other mobile clients.

Overall it’s just better, and better in so many ways that my council and most other councils will not be able to emulate.

Smart councils would realise this and most probably abandon their local street fault reporting systems. They could put their resources into developing a clean API between their own faults database and FixMyStreet (or any other similar application). They could actually invest in FixMyStreet itself. It’s open source, so why not? It’s not going to disappear, and if it gets superseded by another, better, open-source system, no-one loses.

It’s APIs (and often, ersatz, hacky APIs) that make this kind of thing possible. It leads to better services, greater participation, and more flexibility, diversity. We need to put machine users on parity with human users so that people can be best served.

If you’re building any kind of website or online service, serve a feed for every stream and an API for every form. Let this be your mantra: DDAM, DDAM, DDAM. Don’t discriminate against machines.

Like this? Follow me on Twitter or subscribe to my RSS feed.

I’m still frustrated and to a degree baffled by all those otherwise-wonderful sites that are serving up RSS feeds with just headlines and summaries. Where are the rest of the articles?

Sometimes this happens through laziness, sometimes with careful thought and intent but mostly through ignorance and fallacy.

Continue Reading »