I know they’re old-fashioned, but I really miss some of the system sounds that came with Mac OS 9 and earlier. They were lots of fun.

Fortunately, someone has converted them to AIFFs (along with some other formats) and you can download them all as the Mac OS Classic Sound Pack.

I’m a Wild Eep man myself. I like the way your Mac sounds slightly offended when you do something wrong and anxious when it needs to tell you something.

Are you using Tiger yet, and if so what do you think?

Actually, both my Macs are still on Panther at the moment, since I’ve spent all my spare time testing stuff on a pre-release version of Tiger I don’t have time to backup, backup my backups and switch over yet. However, I have been using various builds of Tiger for almost the last year (installed on a Firewire drive) and I think it’s fantastic. I’ve already found plenty of use for Dashboard, played around a-plenty with the updated Mail, Safari, Spotlight, Automator etc and here on Panther I’m missing the new features already.

What I really can’t wait to do is start to move my apps over to Tiger and take advantage of some of the amazingly cool stuff Apple has put there for developers. Over the next few months I think you’re going to see some incredible applications appear for 10.4.

Update: I couldn’t take it any more, I upgraded all my machines (I like the Archive and Install method) and installed Panther on my Firewire drive for compatibility testing – the joys of being a developer.

It’s all been pretty event-free apart from a problem with my iMac not automatically joining the Airport network. The answer, which I found in Apple’s Support Discussions, is here.

Something of an unexpected consequence of the forthcoming Safari RSS support on Tiger and Mac OS X 10.3.9 is that Safari 1.3 has changed the way it handles the feed:// URI scheme. Clicking on a feed:// link (like the RSS one at the bottom of this blog page) now produces a warning like this:

Or in other words, Safari is saying “I can’t handle these feed:// links, and I won’t let any other application handle it either”. How very useful! Before, clicking a feed:// link would open an appropriate newsreader application to subscribe to the feed. These apps generally ask permission to handle the feed:// protocol first time you run them. Will they have a choice on Tiger? I hope they change this soon.

Update: You are able to configure which application handles RSS feeds in Tiger – apparently! 😉 So, if they just sort out this Safari 1.3 situation, it will save a lot of headaches.

Update to the Update: On Surfin’ Safari, Dave Hyatt says:

The feed URL dialog that tells you 10.4 must be installed to view RSS feeds is simply a bug and not part of a master plan for global domination.

That’s a relief!

I reckon that one of the most underrated features of the Mac is (still) AppleScript. If you don’t already know, using AppleScript you can record and automate tasks, extend existing functionality, tie applications together and – using AppleScript Studio – even create proper standalone applications.

Here’s how it helped me lately and re-whet my appetite for adding AppleScript support to Feeder (I know, it should have been there in the first place, but it got postponed).

With Feeder, a common support problem is the FTP publishing. Not once since I replaced the CoreFoundation FTP stuff with cURL has one of these problems been an actual bug; it usually comes down to whether or not FTP Passive Mode is in use or something that I will politely term “user misunderstanding”. 😀

A big part of support is to get information from log files (e.g. your Console log or a crash log) to work out what is going on. With the FTP stuff, you don’t want to be logging all the time and Feeder doesn’t have a transcript window like real FTP clients, so I added a hidden preference to enable and disable this logging as needed.

You may already know that you can view and change an application’s preferences using the “defaults” command in the Unix shell. For example:

Using the command-line is a bit scary for many users, so I wrote a quick AppleScript to toggle Feeder’s “FTPDebug” hidden preference. You can download it here.

The script was saved as an application, so to run it you just double-click its icon. If you’ve never seen AppleScript and would like to see the code, just drag it to the Script Editor’s icon in your /Applications/AppleScript folder. You will see that it is almost English.

Yes, there’s stuff like VBScript and you can write Unix shell scripts, but I don’t think any other platform has anything as easy and powerful as AppleScript.

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.