One irksome thing about creating RSS feeds, as opposed to having them generated by a content management system such as a blogging tool is the laborious text entry required, particularly with URLs. Another thing is repetition. For example, if you have a podcast called “Daily Source Code” and each item in your feed that announces a new show has the title “Daily Source Code for [date]”, it can be a pain to type all that every time.

With Feeder, the aim is to make editing items in your feed as painless as possible. Templates can hold default values and Feeder auto-completes fields from other entries in the feed, just like in a web browser. Feeder will also update publication dates when an item is saved and when the feed is published and Feeder 1.1 will automatically generate GUIDs (Unique IDs).

Unique identification for items in your feed is very important for aggregators (i.e. news-reader apps, browsers, iPodders, etc) to be able to tell when an item has been changed. If no GUID is present, many aggregators try to achieve this by other means. Feeder 1.1 also warns you when you try to change an item’s GUID, since that could cause an aggregator to think the item is completely new and show it as a duplicate. It was NetNewsWire’s Brent Simmons’ posts on his blog that prompted me to implement this.

Just as with autocompletion and automatic dates, Feeder doesn’t get in your way if you don’t want this automation. You can set every item in a feed to automatically generate a GUID when saved (or not) and override this setting on a per-item basis. Feeder can also generate a GUID on demand. To keep the interface sleek, I created a new control to do this (I call it an ActionTextField). Click the gear icon and you see a menu with the relevant commands.

I know you shouldn’t create new controls on a whim but Apple seems to do it all the time and nothing else seemed to fit, apart from a drop-down arrow, which I felt was more appropriate for a combo box (list of values) than for doing this sort of thing. I also considered something like Address Book’s rollover fields, but I know so many people don’t realise what these are for until it’s pointed out I felt something more visually obvious was appropriate in this case.

Another area of automation introduced in Feeder 1.1 is to do with enclosure uploading, but there’ll be more about that in the next post.

Feeder 1.0 was $24.95 and Feeder 1.1 is $29.95. There are a number of reasons for this hike, and since there is always a VersionTracker who thinks that software should be cheaper (not that anyone has written in to complain) let me say a few things on this.

Firstly, $29.95 is not much money for something with as many features so well implemented as Feeder; features only possible because someone has dedicated around 6 months of their lives to designing, developing, marketing, supporting and refining it. If anyone out there thinks you release something like this and become instantly rich, you must be joking. I often work about 60 hours a week and earn only half the British minimum wage, but I love what I do and don’t mind being poor as long as I can survive.

Besides, if you run a business, Feeder can pay for itself in no time. RSS feeds almost automatically propagate around the web. My web site alone gets 10 times as many daily visits now as it did before it used an RSS feed for product news.

Another more important reason is the weakness of the dollar. Since the Federal Reserve has flooded the world with greenbacks it’s become much more difficult for foreigners who need to trade in dollars to make a living. I am around 15% worse off now than when I started selling software and some 25% worse off than when I was planning to sell software. I have been trying to bear the brunt of this and do cunning things like have all my web hosting in the US so when my business’s income goes down so do my expenses. However, I can’t make the cost of living in the UK any cheaper – it’s often more expensive that the US and it’s rising all the time.

One answer to this problem would be to move to the West Coast, but unfortunately that’s not going to happen. Another alternative would be to set my prices in Pounds Sterling, but that would upset even more people as the amount moved up and down. Like it or not, the US Dollar is the world currency and one most people are most likely to understand.

And then there is the price the market will bear. Even Feeder 1.1 is cheaper than its nearest competitors on Windows by some $10 to $20, and in balance those applications don’t particularly do anything more for the money and overall, probably less.

The final and most significant aspect of the price hike comes down to support. I work hard to try and answer everyone’s support and feedback emails as quickly as possible – these are my first priority every day – and I will work with people until the problem is resolved. Feeder users get this support for free, whether or nor not they’ve already paid for the software. You’d never get this responsiveness with more commercial applications and while this level of service is customary in the shareware world the rub is that so much of the support I get for Feeder is not actually about the application itself, but RSS in general, recalcitrant iPodder applications and sometimes people’s understanding of HTML amongst a host of other things. I try to minimise this support through Help files and more frequently updated online FAQs all available through Feeder’s Help menu, but not everyone reads these things before they get in touch and not every problem is obvious at the outset.

I’m not complaining – I enjoy all this, but it all takes time and time is money. After releasing Feeder 1.0 I ended up spending most of the first two months doing just such support work full-time, along with a few minor fixes and tweaks. In order to create quality software and provide great support, you’ve got to be able to do it full-time and in order to do that, you need to make a living. One thing feeds the other.

So I want to thank everyone who’s purchased Feeder and for supporting the creation and further development of this great little app. I love you all 😀

When working on any 1.0 release many things can be very difficult to judge, particularly when working on something that hasn’t really been done on the Mac before. There were some free and shareware applications to create RSS feeds on the Mac at the time Feeder was released, but they all just did the job, if that. There are some Windows equivalents, but I don’t have a Windows PC and besides, they wouldn’t help me work out how it should be done on a Mac. I started with a blank canvas, which is good.

Nor did I have time for public beta testing to fish around for feedback; the day I released Feeder 1.0 was only a week or so before I ran out of money completely. It was make or break time for me and the business and I’d already started applying for jobs. My friend Hans was the only person who saw and helped me with earlier builds, because he was the only person I knew who was techie enough to get going without me having to explain everything.

I wanted to release Feeder much sooner but the more I read the spec and tried to translate it into an easy and intuitive interface, the more problems I found. It became quite a challenge to create what I think of as good design: something you don’t think about, something that just works. I eventually worked it all out, realised I needed to go much further than I had ever intended, abandoned living any kind of life and locked myself away for a number of weeks to work on it night and day until it was finished.

RSS is a fairly simple format, but there is a lot of information in an feed. Putting all this on screen results in a mass of confusing fields. Each item in a feed can have up to ten different elements: title, link, author, categories, comments, guid, pubDate, enclosure, source and description, but some of these elements can have many attributes (e.g. enclosure has url, type and length), so you end up with 13 editable fields and need to allow multiple categories, each with 2 fields each.

It had to be broken down – so much information made RSS look more complicated than it really is. It’s a perception thing, it’s why people dread filling in long forms, yet when they actually get around to doing it find half the sections don’t apply to them. Likewise, I believed nobody would need all the features of RSS all of the time but couldn’t omit anything either. Think about it: when I started the design in November 2004 podcasting was just starting to gain momentum; if I had ignored the enclosure element Feeder would have been useless to what would become over half its user base.

With live bookmarks in the likes of Firefox and OmniWeb and – vitally on the Mac – Safari’s RSS support on the way, I foresaw a whole new band of people who would want to use RSS for other reasons: software developers announcing product releases, clubs and associations announcing news, dates and venues; the sort of web sites that don’t use a content management system to generate a feed automatically; the kind of people who run mailing lists to interested, opt-in readers.

More specifically, Hans asked me what I thought the experience level be for the people that used Feeder. I told him I was aiming at the sort of person who might attempt to hand-code a feed themselves but would rather not, like a Dreamweaver user who understands HTML and CSS but would rather the coding of that stuff was taken care for them, but I also wanted novice users to all that stuff to be able to get up and running just as easily. In short, I wanted Feeder to be an RSS creation app for everybody.

I believed the way to achieve this was to reduce complexity and the only way I could see to do that was to rationalize what was displayed on screen. This is where Feeder’s templates came in. Many design applications use templates as a way of getting people started, usually with a layout and some placeholder text. Feeder’s templates would work along similar conceptual lines to determine which fields are shown in the edit windows and set default values for new items in the feed. Check the box next to the field you want to show and enter default values into the fields. By default you would be shown the basics required for a decent-looking generic feed.

Support for templates in Feeder 1.0 was quite limited. You had a default template applied to all new feeds and each feed could be customised after its creation. They solved the problem of reducing what was visible on screen but many people still found them difficult to use.
With Feeder 1.1, I aimed to simplify that by supplying a set of predefined templates that could be applied or customized when a new feed is created or at any point after that, plus people can create their own templates, duplicate or edit the predefined ones and revert them back to the originals if needed. When choosing a predefined or saved template, you just see a simplified version of the Edit Template sheet, but click the Customize button and the sheet expands to show all the options available.

Click here to see a movie of Feeder’s templates in action.

I’m very proud of the templates in Feeder 1.1, I think they are a unique solution to editing items in RSS feeds. They allow the user to focus on what matters and have everything they need at their disposal and keep everything else out of their way.

It’s a week since the release of Feeder 1.1 and so far it’s been surprisingly quiet on the support front considering how many new features there are and how many other things had to change to make the new features possible. A small bug-fix release, 1.1.1 should be out next week – it makes sense to let things settle down before releasing that, since nothing in it is particularly earth-shattering – thankfully!

I want to write about some of the changes in 1.1 and there will be a series of posts on this subject. I’ve neglected the software development side of this blog for a while because it can be hard to talk about what you’re developing when you’re head’s well into it and you’re not entirely sure what will make the final cut.

Two things that didn’t make the final cut were AppleScript support and HTML export / publishing. I’d mentioned that these would likely be in 1.1, but I was working against a fixed deadline and had to do what needed to be done to meet it. It’s not that Feeder itself was running late but that other things got in the way, most notably Tiger, which devoured a lot of my time thanks to KIT not working with some of the final builds.

Anyway, I need to make a special mention for two very special people who ensured that 1.1 made it out in time and with all the features that it has – my best friends Claire and Ade. Without your help, Feeder 1.1 would probably still not be ready or even if I had released it, it would not have been anywhere near as good!. Also, I could not have managed to move home without you.

Thank you, thank you, thank you!

I forgot yesterday to mention a few more Feeder appearances in the world of print. In addition to its two mentions in Macworld UK‘s June edition, Feeder will also appear on the CD. It also appears on the CD for the May issue of MacAddict and on the CD of the June issue of Macworld US magazine.