The answer to bloatware: Mac OS X’s System Services

By Thomas Riley (staff@macedition.com), November 9, 2001

Our applications are too big, too complicated and too expensive. While this idea is an important concern for consumers, the major software developers have turned a deaf ear and continued on their merry way developing larger and larger applications. With each revision of a single application, there are dozens of more features to learn, some to relearn, and others to forget. There is a promising feature of Apple’s new operating system that has received very little attention in the Macintosh press and online community discussions, but which may offer a glimmer of hope for this quagmire. OS X’s System Services offers a small step towards a new paradigm in Tool-Application-Operating System relationships, one that can counteract the growing size of applications and make software both easier to use and less expensive.

In the standard interface relationship of a modern operating system, the user starts an application from the operating system and then uses one of the application’s provided tools to work with data. For example, if the user needs to write a short note, she would first open SimpleText from Mac OS 9’s Finder interface, then start typing the note. In SimpleText she could make a selection and (for example) change the font size or style. However, SimpleText does not have a spell-checking tool. If the user needs a spell-checking tool, she must copy and paste the text into Microsoft Word (for example), spell-check it there, and then copy and paste the corrected material back into SimpleText.

This is a simplified example, but it illustrates the status quo, where computer users spend hundreds of dollars on huge programs that do everything any user might want to do. These programs can sometimes contain thousands of tools, of which the majority of users would only use a small fraction. The industry solution of releasing “lite” programs is an inherently incomplete one for the simple reason that it is nearly impossible to set an essential group of functions that match a diverse group of users’ needs. The plug-in strategy allows third-party developers to help patch the productivity holes in an application, but it is up to the application to support plug-ins. Even those that support plug-ins tend to be “super-sized” with features and a corresponding price.

One part of the solution to this problem was the OpenDoc initiative, which Apple attempted to bring to the Mac OS in the mid-1990s. This was a modular application approach, allowing users to bring different media together inside a “compound” document and edit it there. However, in this approach there is still a dependence on individual applications to provide the editing tools, as well as the confusing result of having different tools available for editing, dependent on where the cursor is in the document.

Another way of addressing the problem, discussed in Jef Raskin’s The Humane Interface (ACM Press, 2000), is the use of tool sets. Software companies could sell sets of tools for working with data, instead of entire applications. Thus, a user could buy only the tools necessary for her needs, and the user could adapt the system as those needs change by merely purchasing new tools. This also allows the user to shop more effectively, by mixing and matching tools from different companies, creating more direct competition between companies and lowering prices for consumers. Raskin’s discussion of concepts by Larry Tesler (of Xerox PARC) and others actually goes as far as proposing the abolition of applications, but a revolution must be fought one battle at a time.

Together, these two concepts supply a future that OS X’s System Services could help create. Services is a system-level approach to sharing tools between applications. Its current implementation has been summarized as “cut-and-paste on steroids.” There are two types of services: provider services and processor services. Provider services give data to the open application. For example, the Grab service provided by OS X produces a screen shot and leaves it up to the application to display the resulting TIFF file. Processor services take data, manipulate it and then give back the resulting data. A program such as TextEdit can thus provide selected text with spell-checking services from a central customizable dictionary.

Any application may provide its tools as a service, and developers may also provide services outside of applications. Available services are advertised to the system in the Applications and Library/Services directories. When a user starts an application, the system builds a list of services that can be used with the type of data that the opened application handles. When a selection is made and the user accesses a particular application’s Application menu (just to the right of the new Apple menu) and scrolls to the Services section, the system displays a list of only those services which accept the data type selected as input. For example, if a picture is selected, the Services menu will not provide a tool to spell-check the selection; if text is selected, it will not provide a tool to invert the image. (However, a mature implementation of Services could possibly provide tools to scan a picture for textual characters to perform a spell-check on, as well as to change text to a bitmap and then invert the result.) When a tool is selected, the data is manipulated accordingly and replaced inside the document by a processor service; or a provider service might take the selection of a URL and open a Web browser to that address, in which case, no data would be modified in the original application. Also, just as in Raskin’s proposal, the Services architecture allows developers to build tools that are separate from applications (without a stand-alone interface) which can then be accessed from any application.

Services can provide many advantages for consumers over the current Tool-Application paradigm. First, it can provide less expensive and more efficient purchasing to software consumers. Second, it can shrink the amount of unused application code taking up space on consumer hard drives. There will no longer be a need to install three large programs for editing text if one will supply most of the functionality required, and the holes can be patched with Services. Finally, it can consolidate user preference information using a tool that any application can access. For example, every text application can now share one spell-checking tool, creating a systemwide dictionary of your custom spellings. Every program that uses text as a data type (such as e-mail, spreadsheets, even the OS for items like filenames) would then be able to spell-check from that one custom library. Services allows software tools to become useful to the user, instead of merely useful to the application.

The economic ramifications of this powerful concept will prevent most large corporate software developers from taking advantage of Services. These companies are currently dependent on consumers purchasing $500 applications every two years. The modular approach to software, where users buy the best product for each need, and can combine those products easily is an approach that benefits consumers. If this revolution is to begin, it will start, like any revolution, from the grassroots level: with shareware developers and sites like ResExcellence providing users with custom functionality.

However, the current implementation of System Services is only a small step towards the revolution. It was originally only available to Cocoa applications. (With OS X 10.1, it has been made available to Carbonized software, for unported applications.) Most importantly, Services does not solve the larger problem of integrating media within a document, as OpenDoc did. Their fundamental difference, tools integration versus media integration, is an important one. A user should be able to send an e-mail of text with a sound clip inside it, without being forced into the text-attachment formula. For Services to truly revolutionize user productivity, content must be approached in an object-oriented fashion. This will require either an application that can handle data in this manner, or a simultaneous grassroots renewal of interest in OpenDoc or equivalent technologies.

These ideas may be years away from fruition, but they are not pipe dreams. With a strongly committed user base as experimental and creative as Apple’s, the Macintosh is the perfect vehicle to develop these concepts. System Services is the proverbial small step forward, but most importantly, it is a step in the right direction.

To learn more, Jesse Feiler’s Mac OS X: The Complete Reference (Osborne, 2001) is the only OS X guide out to discuss Services, and he devotes an entire chapter to the topic. For developers, Apple’s developer documentation is an excellent starting point for examining the concepts involved. And finally, for a look at what computing could and should be, Jef Raskin’s The Humane Interface is a great introduction with good documentation for further reading.

E-mail this story to a friend