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.

With all this talk about Feeder, I should stress that I’m in no way saying KIT is history, but before I write about its future, let’s take a look at its past for a change.

I’ve always missed the Scrapbook and Note Pad desktop accessories (later apps) that came with Mac OS 9 and earlier. Fast to load, always available – perfect. At the time, they did exactly what I wanted them to do. You could drag and drop (or cut and paste) text, graphics, QuickTime movies, sounds, or anything really to the Scrapbook and it would store it away for you. The Scrapbook app was always available in the stripy Apple menu and when you needed something from it, you could just drag it back out again.

It was the same with Note Pad, which actually did look like a notepad and was so cool in the way you could turn the pages. It was just so handy for jotting down those little bits of text when you don’t want to create a new document, save it and have to find it again later. I never thought Stickies would be an adequate replacement – it’s just not the same. I never saw anything on Windows quite like these two little apps.

When Apple took the decision not to ship either of these apps with Mac OS X, tens of replacement notepad apps appeared. I wrote one of the first of these called Notebook (before Circus Ponies’ Notebook and HogBay came out), which was available for the Public Beta. My version was free, and well received (free things that work usually are!), but it’s hard to write and maintain an app when you’re working more than full time on other things.

The notepad market seems to have stabilised now and there are some great apps out there, although I find none do exactly what I want. By Mac OS X standards, the original apps are nothing special, and Note Pad is recreatable in a hundred or so lines of code, but they have a certain charm, just like the Mac itself. I wanted to recreate that charm and bring the usability up to Mac OS X Panther standards.

Let me make it clear – KIT is not a notepad app, and the name itself (Keep It Together) suggests something more. Indeed, its notetaking features could use more work, but it does aim to fill the collective gap left by those two useful utilities. Think of it as iTunes for your files. A user review by “Cynthia” on VersionTracker sums KIT up better than I have managed to date:

“DRAG – DROP and SEARCH – Imagine being able to throw everything in a drawer and find it by calling it’s name… great.”

Scrapbook and Note Pad had their own database files, which could easily be corrupted. There’s no need for that on Mac OS X, so KIT does with files what they did with text and media. KIT allows you to organise all that stuff into groups and smart groups (like iTunes’ playlists), sort them, color categorise them, and its USP was the integration of Apple’s SearchKit technology to find text in any file, including PDFs, as you type.

Despite its simple exterior, KIT is actually quite complicated underneath, using a plethora of custom views (e.g. the iPhoto-like images with shadows), multithreading (to do indexing and large amounts of file copying) and wouldn’t have been possible without Cocoa’s bindings technology, which is why it will only work on Panther and how it works so fast and so well. It’s not unmanageably complicated however – I’m very proud that I took no shortcuts or easy ways out – it’s some of the best code I’ve ever written. Three days after I finished the coding (but a month or so before I released it – needed to do the website, registration system, help pages, etc) Apple announced Tiger and Spotlight and suddenly KIT didn’t look so useful after all.

However, that’s absolutely not true. In the next KIT instalment, I’ll explain why.

I said I was going to write a little about the future. There’s more going on than I can say here, but I can tell you things that are pretty certain.

Feeder 1.1 will be the next major release to come out. I’m very happy with the reviews and feedback this application has received. It was kind of like working in the dark, while there are other Mac apps out there for editing feeds they’re either free or hopeless and lack even the most basic functionality beyond editing items in a feed. On Windows I know of two roughly equivalent products (one was released after I’d started Feeder) – NewzAlert Composer and FeedForAll. I’ve had some requests from Windows users about doing a Windows version of Feeder – it’s not going to happen – I just direct them to either of these.

Feeder has comparable core functionality to both, but each has its unique features, which is cool. Also, while all three apps might do the same, they all look and work quite differently. Feeder is the most affordable at $24.95, NewzAlert Composer $29.95 and FeedForAll is $39.95. I should also mention here that for a while now, the USD to GBP exchange rate has sucked and always seems to be getting worse, so it’s possible Feeder’s price will have to rise in the future. It’s really difficult to be about 20% down on where you want to be. I know I have the market cornered, but that won’t last forever; I want to charge fair prices and Mac users can be savage in their analysis of a product’s worth. So I’m hoping the extra stuff in 1.1 will make Feeder worthy of a possible small hike, but what I’d really like is for the hike not to happen. Are you listening, markets?

And what will be in Feeder 1.1? In a nutshell, more publishing options and some extra polish. I’m pretty certain most of the following will make it through, barring any technical difficulties:

• Secure FTP
  This should have been in v1.0, but the Open Source library I wanted to use vanished from the net. It’s back now, but in the meantime I found an alternative. Choice!
• .Mac Publishing
• File Publishing
• HTML Export
• AppleScript Support
• Better podcasting support
• Improved templates

That’s quite a simplified list, there will be much more than that but these are the things people have been asking for. Feeder will be tweaked and refined in all sorts of small ways that might not immediately be obvious, but should feel perfectly natural.

I’ll write a little about KIT soon.

In Why Podcasting Will Fail Hadley Stern writes that he thinks podcasting is a passing phase. He may be right.

I don’t agree. While it might continue to be refined and evolve, go more commercial and may even level out in a way, in essence it’s just using the enclosure element of RSS as a delivery mechanism for audio.

So podcasting can deliver everything from an audio blog to radio on-demand, music, church sermons, news reports, or just someone screaming for five minutes. It has a multitude of uses and I believe it’s here for the foreseeable – until something better comes along.

Update: This has been followed up by Chris Seibold in Podcasts are Here to Stay (and that is a Scary Thought). I agree.

… 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.