Volume Number: 14 (1998)
Issue Number: 1
Column Tag: Viewpoint

Viewpoint

by Eric Gundrum

In recent years, most Macintosh developers have looked to Apple to provide the innovation of the Macintosh platform. We had no choice. To change the look and feel of main components of the operating system meant unreliable, system-wide patches, and these left the developer to the whim of Apple engineers who changed the underlying data structures, on which the developer's patches relied, just because they could. This is a tough area to make a business, but some developers still stuck it out. Nonetheless, there are fewer such products available today, and they generally receive the blame before anything else for unexpected system behavior, rightly or wrongly.

It seems clear that the new Apple no longer has the resources to be as innovative as they once were; we developers have to do more of it ourselves. However, Apple can still help; they can start opening the OS to make it easier for third party developers to replace complete components for the entire system.

Recently, Apple has been developing support for multiple themes to provide the user with choices for the overall look and feel of the Mac interface. I just hope they go far enough. This technology can allow independent developers to produce alternative interface themes. We can have a Windows 95 theme to help the Mac better fit in Wintel environments. We can have a cartoon theme for the kids. Novices can have themes making it easier to learn their way around a computer. Expert users can have themes which allow them to be more productive. Because Apple (hopefully) is clearly defining the API between the various components of themes, we developers can easily explore new interface technologies without the risk of unreliable system patches.

If Apple opens the system enough, and in the right places, we can fix their mistakes (like the gray menus and window backgrounds of the Mac OS 8 Finder) and we can try out new things. In fact, I'd very much like to see a stronger separation between the Finder and the general operation of the operating system. (After all, the Finder is just another application, isn't it?) There are great opportunities to provide alternatives to the Finder. Some people want a Finder alternative that takes less RAM, and they are willing to give up features to get it. I'd like a Finder that makes better use of sound and motion to enhance productivity.

Does anyone remember Sonic Finder and Motion Finder of the late 1980s? Sonic Finder provided audible feedback to various Finder activities such as copying, moving and trashing files. Motion Finder allowed icons and windows to be thrown across the screen. Instead of dragging an icon from the upper left corner of a 20 inch display to the trash in the lower right corner, a simple flick of the wrist was enough to send the icon sailing in the direction of the Trash. If my aim was good enough, the icon made it in, and the file was deleted. There was even a version that combined these features. These tools were developed as explorations in alternative interfaces. Apple probably abandoned them because they would not work for a majority of users. Unfortunately, those of us on the fringe were abandoned in the process.

Now, if only Apple would open up the OS enough that we developers could plug in our own alternative interfaces, then we could again see some real innovation on the Macintosh.

Navigation Services, an Open Design?

One example of Apple moving in the right direction is their Navigation Services technology. This will be a replacement for the Standard File package we have all come to love and hate. Navigation Services will provide a new file system navigation interface for all applications that use it. It is supposed to provide a variety of hooks for developers to enhance its capabilities. I am hoping that with this new technology, Apple also allows developers to write complete replacements of the Navigation Services libraries. Apple is going to the trouble to define the API between Navigation Services and all applications and the API to the file system, Apple also should be open enough to let us developers completely replace the Navigation Services with our own version if we think we have a better idea how to implement it.

There are many similar opportunities for Apple to isolate collections of capabilities into separate libraries, encourage application developers to make use of the new libraries, and allow users to replace those libraries with alternatives written by other developers. (Text Services should be foremost on everyone's mind.) This approach to system software development is similar, in principle, to the component nature of OpenDoc. Rather than have all OS operations dictated by Apple, users could choose to replace Apple's standard behaviors with alternatives that better suit their needs.

Now, I don't advocate that Apple try to turn the Mac OS into another OpenDoc. There are a variety of factors that contributed to the demise of OpenDoc, but there also were some worthwhile features of that technology. We should not throw them all away simply because OpenDoc failed. As long as Apple sticks with their current policy of improving the OS incrementally, they will successfully avoid the single biggest reason for the failure of OpenDoc, QuickDraw GX, PowerTalk and others. Apple has to ease us into using the new technologies one step at a time, and as the hardware advances to support them, that the size of the OS doubles with every release, rather than dump so much on us at once.

Most of all, I want Apple to open the entire OS to third party enhancements, but cleanly. Then I can buy or write my own innovations if I don't like what Apple is supplying.