2488 words
on
Mac OS X
It has been Stevenote time on Monday – featuring announcements about the next big cat – and while I may be a bit late to the party, I'll nonetheless offer my €0,02's worth of comments on that and the odd points I consider related to it here.
Main trends
The reoccurring themesI saw in this keynote were the following: Under the hood improvements, SDKs for everything and putting other developers out of business. OS X is stable enough for me not to care about the first anymore – I don't need 64 bits or command line tools but I can see how they are good for the platform in the long run.
Seeing Steve announce SDKs for all the main features he presented was good. If these are any good – we've been through too many instances of description forthcoming
and immature first-generation technologies to give any credit to these announcements before actually seeing them work, I guess – but if these are any good, I think it means a big deal. It won't take years for third party products to be able to tie in with new developments in the OS, as was the case for the address book, say, but they can be around right from the start.
References to Apple working against their developers by replicating their functionality will be made throughout the coming paragraphs wherever obviously appropriate. While Apple may have good reasons to do so and they may either improve the functionality of the stuff the 'rip off' by integrating it into the whole OS or making them more accessible and suitable for general consumption by stripping out unnecessary options, I feel that Apple is treading on dangerous ground here. While some may argue that some of these 'rip offs' technically aren't 'rip offs' at all – it is sure that the announcement of the inclusion into the OS of the rough equivalent of a third party tool will rubbish the efforts of the tool's developers and seriously harm their business.
Of course there may be room remaining for the third party tools, because they are more versatile or simply better and developers may find a way around that (like in the case of Watson), but surely it is not a way that makes Apple keep or attract developers to develop for the Mac or even bet their whole business on the Mac platform.
Finding things is a big topic for me – be it in the context of
launcher applications or
filter fields. Both help you locate whatever you are looking for with ease, using a short description you type in. With the number of files on an average hard drive being in the gazillions these days, you'll need an effortless find feature like that to manage your stuff efficiently. Everybody who has used or even read about BeOS will know this.
And apparently even Apple does so these days as their presentation of 'Spotlight' suggests. I think this could be big. But it may as well be not.
The first issue here are metadata. While Apple have been moving away from metadata in the past years – think file name extensions – suddenly metadata will be king again. Strange. I hope this works out well and in a consistent way.
Next up is content indexing. It has been around for ages. And it was pretty good on OS 9. I've found it much worse on OS X although it should be much better there with proper multitasking allowing the system to update indices in the background effortlessly – just that it didn't because Apple thought that having to update indices manually was a better way to go. In addition performance of content indexing was much worse – probably with those annoying Unix access rights having to be the scapegoat for taking the blame for that (I'd blame engineers, though): Indexing your hard drive means you litter it with invisible folders and performance isn't exactly stunning. All this suggests that Apple would have to put quite a bit of re-thinking and improving things into this before it becomes good.
The next point is extensibility: Steve said there will be an SDK. But will that be good enough? We are looking for new applications transparently adding their reading capabilities to the indexing system, right? Without any worries about security or privacy, of course. And with a good performance.
Probably Next style services as we know them would be well suited for this. Every program can offer services for opening files to other programs, thus extending their capabilities. Hence, making every program offer a conversion service from its native file format to text to the whole system may take us a long way towards comprehensive content indexing. But as far as I can tell, these days you always have to launch the whole app to run a service – rather than just running the code that's needed without showing up in the UI or using up a lot of resources. People won't want to launch XPress just to index a document they received. At least not at the current launching speeds. So a bit of extra work will be needed here.
[While Apple are at that, they might as well make the Finder's preview feature extendible. Seeing that they didn't take that on for years doesn't exactly make me want to hold my breath.]
Yet other pitfalls may include internationalisation – if I can find 'greyscale images' will this find the same as 'Graustufenbilder'? Should this depend on your system language (or even more funnily, as in all OSXs so far on the language of the current application)? Thinking along those lines suggests that a lot of care will have to be taken. And what about other metadata types that haven't been foreseen by Apple's engineers? Will the system be able to cope with that.
That were the technical bits I could think of, so let's look at the UI: First note, that the whole indexing system seems to be just that – all data keep on living in their respective applications. Contacts in the address book, songs in iTunes, e-mail in Mail and so on. It doesn't look like we'll be having a truely versatile Finder (as in BeOS or even those nice extensions they did for PowerTalk) anytime soon. There will be just one search bar – that suspiciously resembles LaunchBar in its looks – to access the gathered information in one place.
Also note that Fitts' law may be back in the MacOS with the search icon in the corner. And that at least Steve's demo looked like 'smart folders' in the Finder can only live in the sidebar. Finally I could also bitch about the plethora of new button styles to been seen in the screenshots but let's do that later when people can't rebutt that point by pointing out this is pre-beta software.
Verdict: A lot of potential, with plenty of opportunities for Apple making mistakes on the way.
Finally let me mention that Steve's demo showed off what was long overdue in address book and could obsolete our very own GeburtstagsChecker. GeburtstagsChecker has quite a few but not overwhelmingly many users (the latter is upsetting because it's quite nice – I tend to blame the fact that English speakers tend to not download applications with a foreign name because they're square...). I am quite positive as well that this particular feature won't kill GeburtstagsChecker, though, as it is much better than address book. Let's hope that iCal won't integrate with the address book for a few more years then...
RSS support for Safari. It does look neat in the screenshots and it's a nice thing to have. It may also be a good way to stab developers of RSS readers in the back if it turns out to be 'good enough' for most people.
What I really find encouraging about this, is a different, much simpler thing, though. It's the simple fact that Safari will use information (link tags, I guess) from the web page and do things in its own UI as a consequence. Perhaps we'll even see buttons for other things such as next/previous, home or index one days, just as we had them in iCab.
What I found discouraging was that there seems to be a new find field for RSS. The one minute they introduce a neat system-wide indexing and finding feature and the next minute they clutter your browser with yet another find field. Odd. I hope these things will be tied together better.
Finally, there is word of Safari being able to archive pages and search bookmarks. Nice and necessary.
Verdict: Good to see progress in Safari. But I am afraid it may become too cluttered.
Huh? The return of the desk accessory? Apple finally admitting that OS X's application launch speed and Dock waste of space are inadequate? Yet another way to run and crash many applications in a single process, like SystemUIServer? Apple having lost their minds and taste completely? Trading in the last bit of HIG for shameless skinning just because we can
and it's shiny? I am not impressed.
There may be merit to the idea of Dashboard, just as there are people who like Konfabulator. Indeed there are many little applications that you may want to have around briefly to gather some information. My primary candidate for this
would be the screen hog iCal... But shouldn't this be done 'cleanly' by tying in with existing applications as far as possible – if only to avoid a widget management nightmare?
Why have an ugly 'widget' to control iTunes, if you have – erm – a perfectly good iTunes to do the same thing? Why have another calculator (in particular after Apple's engineers finally managed to program it in a way that it can harness my computers alleged multiple gigaflops do basic arithmetic at the same speed that I type in just the fourth revision of OS X)? Why replicate Stickies or the Address book? (particularly as you should be able to look things up in the latter via 'Spotlight' anyway).
All this seems pretty pointless to me. It looks cool, but that's about it. Figuring out a way where applications can provide a special 'Dashboard' should have been much better (and harder I suppose). I.e. there could still be a button for this feature which would simply present you with the existing calculator, iTunes's mini window and so on.
It has been pointed out that widgets can be created using web technologies and are rather easy to generate. This scares me as I see hordes of crappy widgets flooding Versiontracker in my crystal ball.
Verdict: No sir, I don't like it.
Visual scripting. This may be a big deal – if it works beyond the demos and is easy to extend by other applications. I frequently find myself hoping for a little throwaway script to automate some task. But AppleScript's notoriously unreliable syntax has taught me that all but the most basic things are quicker done manually. This might change.
I also feel compelled to mention the icon. While my geeky side appreciates the robot holding a pipe – in fact I have always dreamt of an application that harnesses the power of Unix' pipes (can Automator do Unix commands?) in a GUI – I must admit it looks like a rocket launcher and thus a combat robot in the screenshots. It may also turn out to be one of the icons that are hard to recognise when shrunk to a small size in the Dock.
Verdict: A lot of potential. Let's hope extendability will be good enough for the potential to reach beyond Apple's example scripts.
Cool improvements with smooth graphics effects for iChat – but probably quite useless for most people most of the time. Let's hope the improved iChat manages to reliably establish a single audio connection in any situation and will display your Rendezvous contacts in the same lists as the AIM ones. But those points are probably too basic to hold your breath for.
Verdict: Ah, well. Next.
Apple is right to make a big deal of synchronisation. With more and more little gadgets around that want to carry my data it becomes more and more important. Finally being able to have APIs for applications other than Apple's to tie in with system wide synchronisation of preferences or data will be good. Let's hope Apple designed this open enough to be truely useful. Let's also hope they improved the speed in comparison to iSync.
The real problem I see here is the tie-in with the iTools service. If this is a feature of the OS, you shouldn't have to fork over a lot of money just to be able to move your addresses or settings from one computer to the next.
Verdict: They're aware of the importance but may be greedy enough to blow it.
System wide graphics effects. That's quite cool and may save a lot of reinventing the wheel. Speed-wise we probably won't be impressed unless we have modern graphics cards. My question here is whether this will go the way of QuickTime effects. Those have been around for many years. And only very few applications seem to actually use them. Apple will have to make this really easy for programmers.
Perhaps we can even get a simple Apple-built multi layer image composition demo application. That would solve many tasks 'out of the box'. In addition I hope that even old-fashioned applications like GraphiConverter will be able to integrate this easily as all those filters would be a great improvement.
Verdict: I may be overly optimistic here, but I like it.
End
I skipped a few things like the new spoken interface or H.something video codec. Alltogether, this seems like a less exciting update to me than Panther was as far as everyday usability is concerned - Read: I won't have to spend the next nine months nervously shuffling around my chair in anticipation. That's a good thing. Let's hope that Apple do some solid work for the underpinnings and the SDKs for developers live up to expectations. Let's also hope they use the opportunity of the next cash-grabbing round to fix long standing
bugs in OSX like networking, the Finder or the decimal separator (which is well over its second anniversary in bug reporter by now).
Further reading
July 1, 2004, 19:34
Tagged as
Mac OS X.
