I tend to think that bloat in applications is often a problem of perception. For example, when Microsoft Word 6 was released on the Mac, the biggest complaint was how bloated it was, not to mention everything else, like being clunky and completely un-Mac-like, needing far too much memory and too slow.

Granted, Word has an awful lot of functionality for a word processor, but the v.X version seemed to solve most of the problems with improved performance and a streamlined interface; it looks remarkably more Mac-like and much better than the Windows version. Memory usage matters less these days for a variety of reasons, and this is A Good Thing because having stuff in memory is faster than getting it from disk. Some people still regard Word as bloatware and if you scratch the surface you can still find some quirks and occasionally too many dialog panels and tabs within dialogs, but I think for what it is and what it does, it’s an acceptably Mac-like experience. The point is it doesn’t feel anywhere near as bloated now, despite actually having more functionality than Word 6.

In Word 6’s case, bloat was a perception of excessive functionality causing slow performance. Excessive functionality can be the cause of performance problems, particularly with startup times, but these things can be worked around, for example, by optimising code and only loading things when you need them, not all at once. Word 6’s biggest problem was its user experience.

Now let’s look at iPhoto. Most people don’t consider this to be bloated and while it’s not always been regarded as the fastest app on the block it’s managed to stay within the threshold of acceptability for most people. It actually does an awful lot for what is supposed to be a digital shoebox – importing, organising into albums, slideshows, printable books, web publishing and some basic but increasingly more useful image editing features amongst other things.

Or take iTunes – a digital jukebox that imports and organises music, converts audio files, burns CDs, streams MP3 radio, syncs with iPods and other MP3 players, “transmits” and shares music over a local network and even integrates with its own online music store. Yet in no way do these apps come across as being bloated. They work intuitively and they’re focussed on the task in hand. In fact, they’re so easy sometimes people find it hard to believe that all you have to do, for example, is click the Burn button and pop a blank CD in your Mac. “Is that it?” they ask. Yep!

With these two iApps in mind, I’d like to narrow my definition of bloat now from excessive functionality causing poor performance to “unnecessary functionality”, which boils down to poor design. This is the one thing I really want to avoid in my apps – tricky when you receive so many feature requests, which sometimes conflict with each other. I want my apps to be as intuitive as possible while still being packed full of useful functionality and without any degradation to performance. I believe that you can have it all, but you need to put a lot of thought into achieving this. Good! That’s the fun of it.

I wanted to mention all this not only because it’s so interesting to me but also before I write about the future of KIT. Keep this in mind when you read that post.

… No, not me!

I released Feeder 1.0.3 today. If you were to look at the list of changes you’d find nothing earth shattering, but the first item on the list is the reason I released this version now. The change was to strip out nasty control characters that could be pasted in from Dreamweaver, invalidating the feed.

I received a support request where FeedValidator was complaining about an early end of file in a feed. I checked the file in vi (then remembered I have TextWrangler, which can also show invisible characters and is free) and saw these ^@ (null) characters at the end of every chunk of text. Since these null characters are invisible, you can’t see them in the GUI – the cursor just gets stuck for a tap as you try to arrow-key over it. Otherwise, you won’t see anything wrong.

From a developer perspective, because text strings can be of variable lengths, strings in the C programming language are normally null-terminated – i.e. the text is followed by a null character (binary zero) to signify the end of the string; the size of the string field in memory can be much bigger. Variable-length strings can be handled another way by specifying the string’s length somehow. Maybe Dreamweaver has got the length one character too many, or maybe it needs this character for its own purposes.

Rant Alert!

In any case, this is really annoying! Applications shouldn’t put strange invisible characters on the clipboard and make it available to other apps. On the Mac, when an app puts something on the pasteboard it can supply a variety of different formats (e.g. RTF, Plain Text). It’s then up to the receiving application to use the richest or most appropriate type available. An application can also use its own proprietary pasteboard formats which only it knows about and uses. If Dreamweaver needs these null characters, that’s what it should do.

Additional Thought: I listen to Adam Curry’s Daily Source Code podcast, and I’ve heard him mention problems with strange characters in the OPML files used on iPodder.org. Like RSS, OPML is XML. I wonder if Dreamweaver is one of the culprits. It might not be the only problem they’re having, but I bet it’s one of them. If you’re getting weird errors validating a feed or in your OPML files, a good text editor like TextWrangler will be able to show these invisible characters. Look for things that start with ^

Rant over! Big thanks to Paul Figgiani at The Point Podcast for reporting this error and helping me to fix and test it, amongst other things. If you’re interested in getting tips on making really professional, high quality podcasts, Final Cut Pro and Macs in general, you should check out his show.

Looking at Reinvented Software’s news page or feed, you may think that all I’ve done since the 4th of March is read the MacUser review of Feeder over and over again (did I mention the 5 mice rating?), but you’d be wrong.

A day in the life of a full-time software developer can be long and varied and little of what you do is actually developing software, but what comes with it.

A lot of time is taken up by support requests, especially the first month after releasing something. Usually these aren’t bug reports but questions, compliments, feature requests and occasional misunderstandings. With Feeder in particular I get a lot of questions about how people can best work with RSS feeds on their site, glitches with podcasting software and so on. I enjoy doing this stuff, it’s great to connect with people and find out what they’re doing, but it can really gobble up hours of the day.

The other side of things is taking care of the site and back end systems. Behind the scenes I have a system which integrates with PayPal and Kagi to accept payments and generate registration codes, send out lost codes, etc. Last week, despite me making no changes whatsoever, my server decided to stop talking to PayPal, which meant me doing everything manually until I could get it fixed. It turned out to be problem with my hosting company’s network, but it all adds to the workload. Incidentally, I’ve also got a front-end system called ReRegister (shown in the screenshot) so I can work with my online database in Cocoa comfort. Mostly these things save me time and allow me to stay in bed while the money pours (er, drips) in, so I shouldn’t be too huffy when things go wrong.

Anyway, in the meantime, all that feedback I receive – or at least the valid stuff – is being sifted into x.x.x bug release versions, converted into hints and tips on my site or added to a list of new stuff for the next version of Feeder, which I’m desperate to start soon, but haven’t had the chance. Ironically, releasing Feeder 1.1 will cut down on the support work that is keeping me from starting it. A month ago I foolishly told a lot of people it would be out in a month. Well guess what – it’ll be out in a month.

I’ll be writing a bit more about the future soon. If I get a chance 😉