Jan 98 Viewpoint
Volume Number: 14
Issue Number: 1
Column Tag: Viewpoint
by Eric Gundrum
A Call for a More Open Mac OS
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.