Applelust is looking to add writers to its staff. If you
are interested or want to be part of the Applelust community, drop us
a line with your resume or vita. We are always on the look out for good,
very smart, and reliable people to join the staff. If you think you have
what it takes, let us know.
Get a stuffed,
Word format of this column here
for print and reading.
(Please note:
These pages are designed to be extensible with your
window size. There is a Netscape 4 issue though we
have found. If you are in Netscape the page may not
fit your screen.)
Use the
to come back the Table of Contents from each
section.
Abstract
Those who have traditionally
appreciated the design principles of the Mac,
as well as those who simply have a gut feeling
that the Mac is 'easy to use', will know that
this is the case because of a huge amount of
research and theory on interface design undertaken
by the original Mac designers in the early 1980s.
These principles have stood for a long time,
and most of them are still very valid today
- conscientious Mac software developers still
adhere to them wherever possible. But Mac OS
X brings in a host of new ideas to the mix,
some of which can be viewed as 'design principles',
others of which can be viewed as bizarre mistakes.
This article looks at how these new ideas improve
the Mac user experience in some areas, and degrade
it in some others.
Introduction
For nearly twenty years now, Mac users
have stood firm in their contention that their operating
system of choice was easier to use than the alternatives.
Way back when, this meant that we had pretty icons
and a mouse to click instead of a cryptic set of keyboard
commands, for which the Mac was ridiculed a a "toy".
Later on, "easier to use" meant much more subtle things.
As Windows gained in market share and its feature
set came more and more closely to resemble that of
the Mac OS, our job became much more of a challenge.
After all, both operating systems had icons and a
mouse, right? Well, yes, but the Mac's vaunted ease-of-use
came from much more than just that, and now we have
our work cut out for us in explaining the benefits
of customizable icons, Type/Creator codes, applications
that can be installed anywhere on the disk with a
drag-and-drop, the Control Strip, and so many other
tiny details that make the Mac what it is and that
remain solidly out of reach of Windows users.
Now we have Mac OS X, and it's a beauty
to look at — that's hard to dispute. Of course,
the same people who ridiculed the original Mac as
a "toy" now make fun of OS X's candy-like controls
and bright colors, sneering at the "Fisher-Price"
style of case design as they finger the gangrenous-looking,
amorphous blobs that make up the Windows XP interface.
And at the same time, they snort at the Terminal in
OS X, wondering why we have a command-line interface
now, after all this time of extolling the virtues
of a total GUI environment?
Well, of course, the answer is that
we need it to harness the full power of UNIX that
lies under the hood of Mac OS X. But in that lies
the battle at the core of the operating system that
we will all come to consider our new home in the coming
months and years.
Apple in the present day is a mixture
of people from two camps. There are the dyed-in-the-wool
Mac people, who believe fervently in the design principles
of the original Macintosh Human Interface Guidelines
— an almost mythical document authored in Apple's
early days by (among others) Andy Hertzfeld, a giant
in the field of human interface design. And then there
are the Avie Tevanian-led engineers and designers
from NeXT, Steve Jobs' characteristically roguish
computer company whose purchase by Apple sparked the
Jobs-led renaissance of the Mac platform that we've
all been enjoying lately, as well as the technological
wonder that is Mac OS X. The coexistence of these
two traditions within Apple's walls has definitely
produced some amazing things: Cocoa, Carbon, Quartz,
Aqua, and all the other Mac OS X buzzwords with which
we're by now so familiar.
But the coexistence is uneasy. NeXT's
operating system, while its Mach kernel and BSD plumbing
have proved to be a home run for Apple's next-generation
platform, was in its day a hulking beast full of unfriendly
and bewildering quirks. Many NeXT engineers came to
Apple after having worked for years in an environment
where anything "Mac-like" was something to be avoided.
Hence many of NeXT's oddities like a "Black Hole"
that instantly deleted files instead of a Trash can,
reliance on filename extensions instead of Type/Creator
codes for file typing, and a refusal to display mounted
devices on the desktop.
Today, the marriage of Carbon (the
evolution of the traditional Mac OS and its adherents)
and Cocoa (the idealistic but quirky product of NeXT's
labors) has resulted in an operating system that's
schizophrenic in many ways. Because the user interface
has been completely reworked from the ground up, Apple
has had an opportunity to toss out many old and outdated
ideas and re-implement many features in a better way,
and indeed much of the operating system is more intuitive
and easy-to-use as a result, just as Apple claims.
But this wholesale redefinition of what the Macintosh
is has resulted in a minefield of interface decisions
that still need significant work before they're as
intuitive as the old Mac OS.
In this article we'll look at a few
of these features — the improvements, the reimplementations,
and the blunders that come together to make Mac OS
X what it is today.
Like Reading a Piece of Paper
The "Desktop" metaphor that Apple pioneered
in the original Macintosh was a revolutionary new
idea, and it wasn't the first metaphor that was proposed.
(One idea was not to have hierarchical "folders",
but stacks of "paper" on the sides of the screen,
and the user would run the mouse up and down along
it to turn up icons as it passed over them.) The idea
that won out was to have the Finder laid out in the
manner in which we read a piece of paper: left to
right, top to bottom. The most important items would
be in the top left (the Apple menu), leading the eye
to the right across the menu titles toward the application
menu, the system icons and date, and the hard disk.
As windows opened up, they would tile from the left
to the right and downwards, and finally the eye would
rest at the Trash in the lower right: the least important
part of the screen and of the OS.
Mac users who recognize these design
criteria will also notice that Windows' layout leads
the eye in nothing like that kind of familiar pattern.
The Windows user starts at the Start menu, in the
lower left, and then rises with the roll-out menus
up and to the right. Icons are arranged haphazardly
in the upper left, without concern for placement according
to importance (the Recycle Bin is right next to the
Network Neighborhood), and the Taskbar sits by default
along the bottom of the screen. There's nothing at
the top of the screen to indicate any kind of global
controls; each individual window, though, recognizing
the top as the proper place to put primary controls,
has its menus along the top under the title bar —
the opposite of the menu location for the operating
system (the bottom). This is a subtlety that few Windows
users notice, except to note that their system is
vaguely non-intuitive as to where you're supposed
to go next.
Mac OS X incorporates a little of both
of these ideas. Most of the layout is like it was
in the original Mac OS, except that we now have the
Dock, sitting (by default) at the bottom of the screen.
Because of its bright colors and its flashy animations,
it's the thing that draws our attention the most,
which means that our eye now is as likely to start
at the bottom of the screen as at the top. Actions
on Dock items move upward, drawing our eye up rather
than down, and new Finder windows can be launched
from the hard drive icon at the upper right or the
Finder icon in the far left of the Dock — completely
opposite corners of the screen.
Our path through the system is now
a more convoluted one than it was under OS 9, though
it's still vastly more intuitive than the Windows
way. And perhaps it's because of most Mac users' incidental
and unavoidable exposure to Windows over the years
that this is the way it is now: the bottom of the
screen is where the action takes place, while the
top is where you go to work within a particular task
— and from that point on, it's pure Mac.
The original Mac ideal made sense when
there weren't very many applications you could run.
When all you had were MacWrite, MacPaint, and MacDraw,
knowing how to find and open applications wasn't much
of an issue. But one strength of Windows is that with
applications always grouped under the Start menu,
users could be fairly sure of being able to find what
they wanted to run. On the Mac, apps could be launched
from icons on the Desktop, or from their installed
locations deep inside the Finder, but not much else.
Pop-up windows helped this, but they weren't perfect
either.
The Dock leaves little room for confusion.
One of the most common testimonials about Mac OS X
is that new users sitting down in front of it know
immediately where the programs are-- they're right
there at the bottom, in those big pretty icons that
bulge up when you move the mouse over them. And with
this in mind, the bottom of the screen does make sense
for a place where applications should reside when
"at rest", as though sitting on the floor
of a workshop. When you pick them up, or fire them
off, or launch them, whatever metaphor you care to
use, a motion that brings the application up from
the bottom and into your workspace seems perfectly
natural; more so than pulling it down from the top
(the ceiling?). And once you're inside that application,
the "piece of paper" metaphor takes over.
The Dock's new placement will probably turn out to
be just what the Mac needed as a refreshment of its
original design ideal that's in tune with modern computer
usage.
Window Controls: Then and Now
Take a look at the three lickable,
candy-like control buttons in the upper left of each
window. What's the biggest difference since Mac OS
9? No, it's not their pretty colors, though that's
definitely a point of contention for many people.
No, the biggest conceptual issue here is that they're
all grouped together, not on opposite sides of the
window.
The original Mac guidelines placed
the Close and Maximize controls on opposite sides
of each window. This is consistent with the idea of
separate handling of "destructive" and "non-destructive"
actions, where the user should be led to different
areas of the screen or down different workpaths for
the two different types of actions. Assuming the mouse
is at the right edge of the screen — which it
would be, after having opened an application or Finder
window from its icon at the right — the shortest
mouse path to a window control should be to a non-destructive
control. (It's worth noting that much of the Mac OS
was designed to require the shortest mouse movements
possible — an ideal strongly supported by later
additions such as the ingenious WindowShade, but knocked
down at a stroke by its replacement with minimization
into the Dock — requiring the user to move the
mouse almost all the way across the screen and back
again just to see what's behind a window.) It's more
work to move the mouse further to the left to reach
the destructive control, the Close box. This helps
to guide the user by encouraging actions that won't
cause any harm, and raising subtle barriers against
actions that will potentially discard important data.
Windows' window-control layout takes
none of these ideas into account. The three controls
(Minimize, Maximize, and Close) are grouped so closely
together that clicking the wrong one by mistake is
very easy. They're all placed at the far right, as
far from the control menus and icons as possible.
Further window controls can be had by clicking on
the application's icon at the far left of the title
bar, some of which duplicate the functionality of
the other control buttons. Not a very intuitive design,
nor one that guides the user in any way toward which
actions are "safe" and which ones aren't.
Mac OS X incorporates some of the bad
aspects of Windows' layout of these controls, but
at least it implements them in a less dangerous and
more sane way. The Close button is on the far left,
as always, and its red color denotes "Danger!" —
a more effective deterrent than many people realize
or will admit. Next up is the yellow Minimize button,
which sends the window to the Dock — a pseudo-destructive
action that is rightly placed closer to Close than
Maximize, the green button that non-destructively
resizes the window to fit its contents. The order
of the buttons is intelligent, if their placement
(all together and at the left, far from the Desktop
icons) is suspect. But even so, the buttons are separated
by enough spacing pixels that accidentally hitting
the wrong button is much less likely than under Windows.
Incidentally, a Mac OS X innovation
that has received surprisingly little press is the
dark dot that appears in the middle of the Close button
when the window is not "safe" to close — e.g.,
when changes have been made to the document. If you
see the dot, you know that you'll get a "Save changes?"
dialog box or sheet if you click on it. If the button
is clear red, you know that it will close immediately.
Perhaps it's good that all the buttons
are grouped at the top left. That placement is in
keeping with the "Like a Piece of Paper" metaphor
described earlier, and it keeps the three familiar
buttons out of the way of the much less-intuitive
oblong "Menu Bar" control at the far right. This button
has seen a lot of change since it was originally used
(in a round guise) for the short-lived "Single Window
Mode", in which windows would pop in and out of the
Dock as the user switched applications. In the first
of what has become many concessions to the clamorings
of user Feedback, this feature was dropped and the
button retasked after the Public Beta.
Making Your Mac Your Own
Something that Mac users take for granted
is the ability to customize their systems to a degree
that Windows users can only glimpse from tiptoes.
While Windows interface tweaks have been around in
the form of "Themes" since the advent of Microsoft
Plus! in late 1995, the extent of these tweaks has
been customized desktop pictures ("wallpaper"), window
colors, screen savers, and system icons and cursors.
Some of these (such as the custom cursors) can't be
done on the Mac. But when it comes to customizability,
the Mac platform has always had a number of significant
advantages on its side. Chief among these are the
ability to apply custom icons to any of your files.
While Windows users are chained into
having all their picture files show up with the same
boring icon in filesystem windows, and are forced
to use third-party image browser software to see thumbnail
previews of them, Mac users have always had the ability
to copy the contents of any picture in the Clipboard
onto the file's icon in the Get Info window, creating
a custom icon. Icons could also be copied from one
file to another, and the Clipboard, ever intelligent,
would transport all the different sizes of icons at
once. Clearing the custom icon would return a file
to its former appearance. With this functionality
in place, Mac users had a rudimentary but functional
way to preview images or movies, or simply to customize
the appearance of special files, with just a few keystrokes
and mouse movements.
Lately, Windows has made a few steps
toward providing some semblance of this functionality.
Windows XP, 2000, and Me have a "thumbnails" view,
in which any picture files in a folder window are
displayed as previews of their contents. But this
has more in common with Mac OS X's Column View preview
than with custom icons, a concept still not supported
at all in Windows. The thumbnail previews only work
with picture files, not with anything else (and they're
only 64x64 pixels, and can't be arbitrarily resized
as they can in Mac OS X), and it's a per-folder view
setting, not a per-file resource. Granted, some of
the functionality of the classic Mac OS is now ostensibly
in Windows, but only in a rudimentary way-- and while
Microsoft was struggling to get that working, Mac
OS X was bringing icon and folder customizability
to yet another higher level.
Mac OS 10.1 brought a heap of fixes
to bugs in the system that prevented us from taking
advantage of this delicious feature of the Mac. Finally,
we can again open an image in Preview, press Apple+C,
open the Show Info panel on a file, press Apple+V,
and the new icon is pasted in. It's even more reliable
than in OS 9, in which sometimes the Paste operation
would fail for no readily apparent reason. Now it's
nigh-flawless. And, as an added bonus, custom icons
in Mac OS X — naturally — can be up to 128x128
pixels in size, a veritable wilderness of available
space for detailed thumbnails (perfectly suited for
picture and movie previews), with full 32-bit color
and alpha-channel support. Stuff like this Windows
users can only dream about.
And Mac OS X brings more to the party
too. You can now set custom background colors or pictures
for individual folders. This provides unprecedented
freedom to application publishers, who until now (in
the classic Mac OS) have gotten by with amazing skill
at creating customized installer folders with "pictures"
composed of groups of custom icons with blank filenames,
all tiled together like houses of cards. Now it's
much easier, and the installers for Mac OS X programs
like OmniWeb and Iconographer come in beautifully
presented splash folders, making for a whole new ideal
in application installer design, as we'll see in a
moment.
Mac OS X isn't without its customizability constraints,
though — constraints that weren't there in OS
9. Apple clearly wants us all to fall in love with
Aqua, and therefore features like the throbbing blue
"OK" buttons, the system font, and the borderless
windows can't be as easily modified as with the earlier
system — and attempts by third-party customizers
have been squashed by an Apple Legal department that's
perhaps acting a bit too overzealously for its own
good. If they're not careful, Apple will discourage
some of the very creative talent that has resulted
in some of the best aspects of Mac OS customizability
in the past (remember the tweakable themes promoted
as a new feature in Mac OS 8?) and scare them away
from a platform that has always welcomed and thrived
on the input of its most creative users.
Registry? What Registry?
Installing a new application in the
Mac OS has always been a very simple operation. Almost
every app used the same familiar installer: a disk
selection panel, followed by a simple packaged copy
of the necessary files into the appropriate location
(usually the Applications folder). Smaller apps were
self-contained files without supporting items, and
so they could be simply dragged from their downloaded
disk images to wherever the user wanted to put them
— and that was that.
A far cry, indeed, from the Windows
Way: complex installer/uninstaller programs that don't
just copy files, but also interact with a central
system Registry. This is a database of cryptic keys
and values that are installed and moved around whenever
any program is installed or removed — often sloppily,
leading to an inevitable buildup of destabilizing
cruft that every Windows user recognizes as a steady
and inevitable progression toward frequent crashes,
application misbehavior, and painful troubleshooting
and reinstallation procedures — to say nothing
of the privacy and anti-piracy implications of such
a model. It definitely makes it easier for the system
to keep track of what's installed and whether the
proper registration keys are present, but... well,
somehow Mac users and application developers have
always managed fine without it.
Mac OS X brings us a new ideal toward
which app developers are already striving: the Perfect
Installer. In its simplest and most ideal form, a
Mac OS X application is installed simply by dragging
a single application folder or icon from a customized
"installer" window into your Applications folder,
or wherever you want to put it. This is possible even
for the most complex applications. No more VISE installers
to run, if they're designed properly: because in OS
X, applications are now "bundles", or specialized
folders that contain not just the executable binaries
of the apps, but all their resources: bitmap images,
localizable text strings, executables for multiple
platforms, property list (.plist) files — in
short, all the stuff that used to go into the Resource
Fork of an app. But now it's even better, because
we users can easily browse into the packages ("View
Package Contents") and do whatever we like with anything
we find in there... if we know what we're doing.
The practical upshot is that any support
files for an application that used to go into the
System Folder or elsewhere hither and yon in the system
is now ideally kept within the package — so even
the most complex app can be installed by grabbing
a single icon from the installer window and putting
it wherever you want it to go. Deinstallation is absurdly
easy too — just grab the folder and put it in
the Trash. Programs like OmniWeb, Iconographer, Snapz
Pro X, and many others have jumped toward at the chance
to pursue this ideal, and we as the users win. Installing
apps is now easier — and more fun — than
ever. We can thank NeXT for this.
Of course, Preferences now go into
each user's Library folder, and some larger apps will
have to have more complex installers to manipulate
the Frameworks (shared libraries, of a sort) that
must exist in a shared location... but overall, the
simplicity of installing and deinstalling apps has
advanced by a great leap.
Single-Clicking and the Web Metaphor
Steve Jobs has publicly said that he
dislikes the idea, first brought forth by Microsoft
in Windows 98, that an operating system should look
and act like a web page. According to him (and many
Mac users), it's a flawed metaphor, and blurring the
line between files that exist on the local machine
and files that exist on remote servers is pointless
and counterproductive. While Windows works harder
and harder to decentralize the individual desktop
and obscure the difference between the user's local
files and a Web page, Apple has shied away from the
idea.
Or has it? One of the hallmarks of
the web-like interface is the single-click action.
The original Mac designers held to the hard-and-fast
rule that a single click should be used to indicate
items, select items, move items — non-destructive
actions, and actions which do not cause any major
functions to execute that the user cannot control.
Mac users would click once to select a file, and double-click
to launch an application or open a file in its creator
app. Double-clicking, because of its inherent increased
effort, was reserved for functions that the user really
means to execute, to reduce the risk of accidental
execution of dangerous actions.
But the World Wide Web changed all
that. Suddenly, a single-click could take a user from
one page to another, from one server to a completely
different part of the world. While that seemed in
itself consistent with the meaning of a single-click
action, that all began to change when single clicks
on the Web could launch server-side applications for
e-commerce, submit forms full of data, and begin downloads
of files which would unpack and install on the client
side without much more than a thought. And Microsoft
decided that in order to make Windows more Web-like,
it would provide an option to make folders and applications
open with a single click instead of a double one.
Suddenly, with a single wayward click — from
a too-heavy hand and a casually moved mouse, something
that a curious cat could do — an application
could be launched, doing anything from grinding Photoshop
into memory to formatting the hard drive.
Not to be outdone, Apple gave users
something called "Button View" — an outgrowth
of the Simple Finder view for classrooms and kiosks
— in which icons appeared as buttons which would
launch their contents with a single click. At least
these were shown as buttons, a metaphor that had by
that point already become established as something
that signified a single-click action, while the Windows
method used textual links and a Web-like "hand" pointer.
Regardless of the presentation, few user-interface
gurus hailed this advancement as a great milestone
in computing history.
Meanwhile, users who had grown used
to the idea that a double-click was what launched
actions and single-clicks did nothing but select items,
were double-clicking on links in Web Pages. Web apps
that popped up a new window on the first click and
sent it into the background on the second meant that
inexperienced users lived a bewildered existence online.
Confusion reigned supreme, and continues to do so
to this day.
Enter Mac OS X and the Dock. Icons
in the Dock are activated with a single click. The
mouse pointer does not change shape over it or give
any feedback other than the optional Magnification
effect to indicate that a single click will launch
whatever icon you're pointing to. This is pretty clearly
a violation of the original Human Interface specs,
but the justification is that the Dock is a different
enough device from anything else in the system —
as different from the Finder as, say, a Web page is
— that single-clicking is a permissible action
to control it.
Is this a bad idea? It's hard to say.
Would we be better off requiring double-clicks on
icons in the Dock? I don't think so. You can't select
or rename anything in the Dock directly, so single-clicking
really would serve no purpose; the idea is that the
only reason you'd touch the mouse button while over
an icon in the Dock is to launch it. So this metaphor,
while it's definitely flawed as far as the original
ideal goes, represents a more modern style of thought
that takes into account users' convenience and experience
with the Internet and other single-click functions.
However, it does little to combat the confusion that
has seeped into public consciousness since the Web
came on the scene.
The Apple Menu
Up in the top left of the screen sits
the venerable Apple Menu. Initially a clearing-house
for the most commonly-used system functions (the Chooser,
the Control Panels, the user's most recently-used
items), and later evolving into a dumping ground for
all kinds of random junk installed by third-party
apps and power users, the Apple Menu very nearly died
out completely in Mac OS X. In the Public Beta, the
Apple logo sat at the center of the system menu bar
— and it didn't do anything if you clicked on
it. A great hue and cry arose from the users, and
Apple hurriedly moved the shiny blue logo back to
its rightful place at the far left. Its options included
items that had formerly been put (rather clunkily)
into the bold-faced Application menu: Shut Down, Log
Out, System Preferences, and (of course) About This
Mac.
The improvements to the menu have continued.
In 10.1, we got the ability to control the number
of items stored in the Recent Items sub-menu. The
Dock sub-menu got more options as well, and the Location
sub-menu (which used to live in the Control Strip)
retains its rightful place in this all-important menu
as the global configuration manager. (We can only
hope that Apple will eventually incorporate into the
Location menu all the old preferences we used to have
in the Location Manager: not just network settings,
but volume controls, Energy Saver settings, brightness
levels, and all kinds of other stuff that we like
to have set differently when we're in the privacy
of home than when we're in the bustle of the office.)
But perhaps most importantly, the tools
and shortcuts that used to be thrown willy-nilly into
the Apple Menu are now supposed to go into the Dock
— a tool that's specifically designed to handle
arbitrary numbers of objects of any type, thrown in
for easy access, removed when no longer needed, and
sorted in whatever order you like. (The Apple Menu
items used to be sortable only alphabetically.) So
the Apple Menu is now truly as definitive and consistent
as the global control menu ought to be. Chalk this
up as a definite advance in usability and intuitiveness
over the old OS.
Column View and Other Cool NeXT-isms
We've already mentioned "bundles",
a concept inherited from NeXT that has been adapted
to make application installation almost unbearably
easy and more "Mac-like" than ever. But this is just
the tip of the iceberg of new capabilities that NeXT
has bequeathed us.
To remain on the subject of bundles
for a moment, it must be said that applications aren't
the only items that can benefit from their structure.
TextEdit can save not just .rtf (RTF, or Rich Text
Format) files, but .rtfd format as well — which
denotes directories or "bundles" that contain images
and other objects as well as text documents and layout
information. This means that a single icon, behaving
exactly like a regular file, can represent a self-contained
package of all the relevant components in a complex,
graphically-intensive document. Microsoft Office v.X
promises to bring further support to this concept
through the ability to save similarly multi-object
documents in bundles as well. With such clout behind
the format, we can only assume that we'll be seeing
more and more files on our Macs that are actually
bundles — and which we can send to remote systems
containing all the relevant information necessary
to reconstruct the original document from components
in easily-manipulable, cross-platform formats.
But probably the most visible new idea
that NeXT has given us is Column View, a new third
view in the Finder to complement the existing Icon
and List views. Column View is such a grand idea,
it's a wonder that nobody ever thought of it before
— and that Microsoft was apparently so focused
on Apple as its source of new ideas to copy that it
didn't notice that NeXT had had the idea for most
of the 90's, and it only suddenly caused them consternation
when Mac OS X was released well beyond the closing
date for Microsoft to try to incorporate it into Windows
XP. Column View gives us the ability not only to see
the path history of whatever folder or document we're
looking at, but also to see a Preview of the document
in the rightmost pane, containing all sorts of useful
meta-data gleaned from the document's filesystem attributes
or bundled .plist files. This preview can take the
form of a fully-functional movie or sound player,
as we all know by now, and chances are that it will
continue to be extended with time, as it has in 10.1
with the new ability to resize the column widths either
in parallel or independently. For many of us, Column
View has become the default way to browse or computer's
files, and we almost can't imagine working without
it. Its only drawbacks currently include an inability
to sort the files any way but alphabetically, but
then, that's what List view is for.
The convenience of Column View brings
with it a trade-off, though. An oft-maligned and oft-lauded
feature of Mac OS 9 and earlier, Spring-Loaded Folders,
allowed users to drag files into deeply nested positions
in the filesystem by holding them on top of a folder's
icon for a moment, upon which it would automatically
pop open and let the user drill down another layer,
as far as he wanted to go. Mac OS X has no such feature.
Some users condemn the omission (and Apple's denial
that it has any plans to bring it to OS X), but still
others express relief that the feature — which
was turned on by default, and often meant that newbie
users would be startled by folders suddenly jumping
open for no apparent reason — has been dropped.
Apple does indicate that a replacement to this functionality
will be forthcoming in a future release of Mac OS
X, but we have yet to fathom what that might be.
But perhaps the biggest legacy that
NeXT gives to Apple is Cocoa, formerly known as OpenStep,
and its associated ProjectBuilder environment. Obtainable
freely as part of the Mac OS X Developer Tools, ProjectBuilder
and Cocoa provide what is probably the best and already
most widely-deployed and accessible fully object-oriented,
visual programming environment available. Students
can pick it up freely and tinker with tools that sate
their idealistic need for fully object-oriented programming,
and professionals can use it to build new apps with
developmental stability and deployment speed that
Mac developers have only been able to imagine in the
past. ProjectBuilder also expands to incorporate Java
and the WebObjects database-connectivity and web-application
development environment, providing a common interface
to all these tools. None of them were available to
casual users before, and now we'll be likely to see
an era of Mac development the likes of which we've
never seen, as the Mac and UNIX traditions come together
to appeal to new converts to the platform seeking
to express themselves as rebels and geniuses.
Filename Extension Hiding: The
Battle for the Type/Creator Codes
Now that we've lauded NeXT, it's time
to vilify them in due turn. One regrettable concept
which NeXT has brought to Apple is that of filename
extensions — those three- or four-letter text
strings following the dot at the end of files that
come from the Web (for example, the .jpg on picture1.jpg).
Mac users have in the past never really needed to
pay much attention to these curiosities of file naming,
because we have a much better system for figuring
out what a file should do when you double-click on
it: Type and Creator codes. These pieces of filesystem
meta-data define, in four-letter "signatures", what
kind of file it is, and what application created it
(and therefore should open it). Like the icon, the
filename is completely changeable. It's a mutable
piece of meta-data, whereas immutable meta-data (like
the Type/Creator codes, the "last modified" timestamp,
and so on) are much harder to modify without third-party
hack tools. We can name a file anything we want, and
it will still open in the right app when we double-click
on it, and it will also open in any other app that
claims to be able to open files of that Type. While
Windows users are faced with stern dialog-box warnings
if they dare to try to change or remove the extensions
on their files, Mac users can delete or change them
without a care in the world, or any unpleasant side
effects.
At least, that's the way it used to
work.
Excited first-time Mac OS X users who
used TextEdit to create a new text or RTF file were
taken mildly by surprise to find that if they saved
a file called "blah", it would be saved with the extension
".rtf" or ".txt" appended to the filename. More alarmingly,
if the users then renamed the file to get rid of the
extension, it would suddenly lose its TextEdit icon
and any knowledge of what to do when you double-clicked
on it. What the devil? What is this — Windows?
Why should a file's behavior depend on what you happen
to name it?
As it turns out, the bundled system
apps that come with Mac OS X — TextEdit, Mail,
Preview, and so on — do not set Type/Creator
codes on files they create. This is because there
has traditionally been no API in Cocoa (which, remember,
those apps were written in, many years ago as NeXT
programs) to set those codes, as evil and "Mac-like"
as they were to the NeXT folks back in the day. So
those files created by those apps would normally not
know how to open even with the extension appended,
if it weren't for an additional layer of file-typing
support added in Mac OS X: a system-level table of
recognized extensions, and what types and applications
they map to.
It should be clarified right away that Type/Creator
codes are indeed supported in Mac OS X, and almost
all third-party applications set them properly, even
Cocoa ones like OmniWeb (well, sometimes). The Carbon
group at Apple — those who are steeped in Mac
tradition and who want to adhere as closely as possible
to the age-old guidelines of human interface —
are fervently pushing for full Type/Creator code support
in Cocoa, but currently (even in 10.1) the NeXT-derived
apps don't set them. Carbon apps like AppleWorks and
iMovie do set them, but therein lies a vivid illustration
of the conflicting interests of the two groups within
Apple.
Anyway, a side effect of this battle
is that Mac OS X can now choose to be much more of
a team player when it comes to heterogenous computing
environments. Apple's PR people have been quick to
pick up on the fact that now that OS X recognizes
filename extensions, we can now automatically recognize
and use files from Windows users without having to
map Type/Creator codes onto them, and (more importantly)
we can send files to Windows users without having
them open up our Mac files with no extensions and
swear at those ^&%#$% Macs that don't know how
to send files that can be used on Windows. It's a
long-running sticking point in the Windows world,
something that has caused many a fuming Windows user
to foster a deep-seated loathing of those feisty rebel
machines and their clueless users. We can now mitigate
that problem by guaranteeing that Mac files always
have extensions on them, and therefore will always
be recognizable by Windows machines.
But wait! Why should we have to deal
with extensions? They're ugly! They represent a huge
technological leap backward from our system of Type/Creator
codes! What is Apple thinking?
Apple's thinking of practicality here.
Idealism is great, but if we stick to it too firmly,
we'll end up like the Amiga faithful: unwavering in
our support of the perfect computing platform which
no longer exists. None of us wants that. Instead,
Apple has offered a compromise: Filename Extension
Hiding.
If you remove the extension from a
file in Mac OS X 10.1, the file isn't actually renamed,
as you can verify in Show Info or in the Terminal.
The extension is merely hidden. If you add an extension
back onto it, it's simply un-hidden. Effectively,
the extension is being treated as a third piece of
file-typing meta-data, one that just happens to be
stored in the same field as the filename, and shown
or hidden at the user's whim, on a per-file basis.
This prevents users from saving files with names like
"picture1.jpg.jpg", and yet it allows for us to name
our files whatever we want — as far as the presentation
layer is concerned — just like in Mac OS 9. Thus,
with almost no added effort, we can be assured that
the files we e-mail to our Windows colleagues or burn
onto CDs will always open properly even on benighted,
extension-dependent systems like Windows, and yet
will display on our Macs the way we want them to be
displayed.
Apps like TextEdit, in their Save dialogs,
have a checkbox for "Hide Extension". This box is
checked by default. However, if you add to the filename
an extension that the system recognizes, the box will
uncheck and the file will appear with the extension
shown. You can further use the box to fine-tune how
you want the filename to appear.
Mac OS X 10.1 also perfects an additional
layer of control: the "Open with Application" field.
This allows the user to associate a particular file,
or all files matching a certain Type/Creator or filename
extension profile, with any application on the system.
It presents its recommended apps first, and additionally
lets you select any other app to handle the files
and provide default icons. Rather than setting the
Creator code to accomplish this (which could result
in huge disk-wide high-latency churn on bulk operations,
and would obscure the original creator app of the
file anyway), the Opener table sets rules that take
precedence above the traditional Type/Creator codes
and the new extension-mapping mechanism to give us
even greater control over our files' behavior than
ever before. To put it into terms we've already used,
the Opener of a file is now mutable meta-data, whereas
the Type and Creator remain immutable and intact,
as does the Extension.
Actually, a determined user can in
fact change a file's extension. Doing so will result
in a dialog warning that asks the user whether he
really wants to change the extension and risk screwing
up the opener mapping, both on the local Mac and on
remote Windows machines. This dialog, while annoying,
is designed to force the user to think carefully about
the operation, with the default set to not change
anything, and with the buttons reiterating the requested
change. It's made clear in no uncertain terms that
the user is treading on dangerous ground by mucking
with this semi-mutable meta-data, and steering clear
of it is the best policy. A global switch in the Finder
Preferences ("Always Show File Extensions") turns
off all this behavior, returning the system to 10.0.4-like
behavior, with all the risks of mapping loss that
implies for files that have no Type/Creator code set.
This is probably the most visible and
obvious of the results of the clash between the Apple
and NeXT sensibilities in Mac OS X, and one of the
biggest impacts on our "legendary ease of use". But
if we can keep from reacting too quickly or in too
knee-jerk a fashion to this new behavior, it actually
begins to make a lot of sense and show a lot of careful
design and thought on Apple's part in bringing this
feature to fruition. In the long term, the rewards
we will reap will come in the form of Windows users
who can receive files seamlessly from Mac users, and
who then will be much more open to accepting the Mac
as a viable peer platform — rather than grumbling
at extensionless files and listening to the Mac users
petulantly explain how their way is so much better.
Nobody ever made a Mac convert that way.
Still, it remains for Apple to crack
down on its own developers and not allow the support
for filename extensions to provide a decreased incentive
to assign proper Type and Creator codes for the files
their apps create. If those codes are always set,
as they always have been, these new features of Mac
OS X will barely impact on us. It would be close to
ideal if Apple could provide a function similar to
the Internet Control Panel in Mac OS 9, which provided
a visible table of mappings of extensions to Type
and Creator settings, and assigned those codes to
any new files that entered the system from the Internet
or mounted disks. With that redundant meta-data set
on all files, we'll have the flexibility of the classic
Mac OS along with the interoperability of Mac OS X,
and life will be good.
The Control Strip
The Mac OS was designed with the assumption
that people would need to customize their systems'
settings so seldom that those settings should be sequestered
away from the first tier of the Desktop, down under
the Apple Menu, in the Control Panels. This worked
well for a long time, while the number of different
behaviors a Mac user could set or control remained
small.
Eventually, Mac users became itchy
for the need to control the sound volume of their
machines in a more convenient way than opening up
the appropriate Control Panel. With that desire came
the need to change screen resolutions and color depth,
flip AppleTalk on and off, control audio CDs, and
many other functions that were just too inconvenient
tucked away in Control Panels. So while Windows 95
put a volume control thumb-control down in the system
tray, Apple introduced the Control Strip.
Popping into view when called for and
rolling away when no longer needed, the Control Strip
is an unobtrusive, modular collection of quick-access
commands that put the most common bits of many Control
Panels into easy reach. While it seemed ungainly and
counterintuitive at first, Mac users quickly came
to love the Control Strip and the ease with which
it allowed them to control their systems.
While Mac OS X was in its first stages
of development, the Dock was envisioned as a combination
of Desktop aliases, the Apple Menu, and the Control
Strip — incorporating the functionality of Control
Strip modules into an access device sitting in the
same place where the Control Strip used to be, along
with applications and documents and minimized windows,
wherever the user chose to place them. In the final
release of Mac OS X 10.0, user feedback had prompted
Apple to insert a divider line between apps and documents,
but Dock Extras — also known as Docklings —
were still the primary means by which users were to
control screen resolution, monitor battery life, control
AirPort connectivity, and other functions that used
to be accessible from the Control Strip.
Users quickly realized that while Docklings
were an excellent new concept for many functions —
the Massinova dockling maintaining a watch on a streaming
techno music station, for instance, and Space.dock
providing multi-desktop functionality — they
took up too much Dock space and were too little distinguishable
from other apps sitting alongside in the Dock. So
in a further break from the ideal of the Dock as originally
planned, in 10.1 Apple moved the Docklings' functionality
up into the System Menus in the title bar next to
the clock.
Now, our workflow takes us into the
upper-right corner to access our most commonly-used
system controls — about as far from the Dock's
default location as possible. It's taken Apple some
three iterations to do it, but we now have the Control
Strip's functionality back, but in a completely different
place from where it used to lie. In the terms of the
original Human Interface guidelines, this places the
controls in a more prominent and important place than
they used to be (the top of the screen) — and
the importance of the Dock, as we discussed earlier,
is somewhat inconsistent with the "as you would read
a piece of paper" workflow metaphor. It remains to
be seen how this will impact our efficiency, but we're
already getting used to it very quickly.
The remainder of the system controls
remain in System Preferences, the new, tightly-controlled
multi-paned application that incorporates all the
old Control Panels into new, slicker versions. But
it remains to be seen how hardware and software that
used to install customized Control Panels into their
appropriate folder in the System Folder, to appear
in the Control Panels sub-menu below the Apple Menu,
will be able to do the same thing under OS X. Will
the System Preferences application be able to incorporate
new third-party panels? How will they be organized?
It's all well and good now that OS X has inherent
support for most current hardware, but what about
the future? What about device-specific controls, like
mouse drivers and SCSI domain controllers? Only time
will tell.
The Chooser is Dead. Long Live...
Other Stuff!
Finally we come to one of the most
odd and confusing parts of the Mac OS: the Chooser.
This little tool, originally intended as a way to
switch between devices on the LocalTalk and serial
ports, came to be the all-purpose AppleTalk file-server
and printer picker. But its weird name was daunting,
and newcomers to the Mac platform had a hard time
understanding its purpose or its placement in the
Apple menu.
Mac OS X does away with the Chooser,
finally — and it will not be missed. Instead,
file-server and printer functionality has been broken
out into their respective corners of the operating
system — AppleTalk, NFS, SMB, and other file-sharing
protocols handled in the Go menu, and printers managed
by the PrintCenter utility which pops up to recognize
new printers or to handle running print jobs, and
then vanishes back into the depths of the system.
It's difficult to say whether the demise
of the Chooser is attributable to the Mac people,
the NeXT people, the Building 4 janitor, or what —
but it's pretty safe to say that it's a good idea.
Printer choosing is no longer something that has to
be managed with as much manual control as it once
did. File servers are kept in their own area of the
system, a press of Apple+K away from anywhere in the
Finder, and the browsing capability once built clumsily
into the Chooser is now handled in a consistent way
by the combined graphical and URL-based server location
method.
There's still progress to be made,
naturally. NFS and SMB shares do not show up automatically
in the browseable listing above the URL field; the
user must know the cryptic string to type in to mount
one of these shares. The string differs from NFS to
SMB to AppleTalk/IP to plain AppleTalk, and the file-sharing
feature of Mac OS X will not be complete until those
services are made graphically available, through SLP
or NMB-based discovery — both easily accessible,
open-source solutions that Apple could easily incorporate
in the next release. Only then will Mac OS X truly
be the network "team player" that it claims to be.
Conclusion: Into the Future
It's a great time to be a Mac user,
folks. The future of Apple has never looked brighter,
and there's never been this much interest in the Mac
platform from formerly uninterested users of other
systems. The story we have to tell them is compelling
and exhilarating, and it represents some of the best
thinking in the computer industry today.
Such an achievement is hardly without
its compromises, of course. We long-time Mac idealists
are going to have to learn to accept a few new ideas,
and be open to change in our beloved operating system.
There's strife in Mac-land, with opposing forces coming
together and trying to reconcile their own conflicting
ideals into a common vision, and the innovation that
comes from the compromises in that alliance is going
to define the Mac for the next several years. In some
cases, the management at Apple is able to see that
vision clearly, and knows how to handle the conflict
in a way that results in a newfound benefit for us
all. It's probably too optimistic to think that Mac
OS X will be hailed with the same reverence for its
ease-of-use as the original Mac was in its pure, theoretical
glory, but it's got hybrid vigor that will protect
it from the kind of idealistic stagnation and stubbornness
that resulted in much of the Mac's original fall from
favor and loss of market share and respect in the
last decade. With Apple's newfound wisdom born of
bitter experience, and a willingness to listen to
the needs of its users (through the ever-popular Feedback
form), the Macintosh we'll be using in years to come
will continue to be full of pleasant surprises and
the same joy of using the Mac OS that we always have
relished.
Due to feedback amount, you can discuss
this article in our forums. Go
here.
Brian
Tiemann is the co-author of FreeBSD Unleashed
for SAMS Publishing, a webmaster from back in the
days when that meant knowing what the <BODY>
tag did, and an Apple fan who has gone from his grade-school
//c+ through various DOS, Windows, and UNIX boxes
to come home to the Mac fold once again. And
this is where he's staying.
Stuffit
7 (10-18-02) Dr. Neale Monks. What purpose does file compression have
in this day of 100 GB hard drives? Is version 7 worthy of the upgrade fees?
Fireworks
MX (10-8-02) Dean Browell. Fireworks is more than just a pretty face;
The last app I needed to convert entirely to OS X delivers in upgrades and
features as well...
Dreamweaver
MX (10-8-02) Joel Davies. Not being satisfied with just carbonizing it's
product, Macromedia made sure that Dreamweaver MX was the killer app for web
design.
SliMP3
(9-6-02) Pat St-Arnaud. The SliMP3 is a small, simple and elegant network
devices that connects to any audio component with RCA inputs and lets you
browse, search and play music directly from your computer's MP3 collection.
Voyager
III v.3 (8-16-02) Dr. Neale Monks. Carina's Voyager is the grandfather
of Mac planetarium programs, but does it still have what it takes to keep
up the current generation?
CodeWarrior
8 (8-16-02) Douglas A. Welton. Doug dives into the latest version of this
robust multi-platform programming tool.
STM
Sports Backpack (8-9-02) Pierre Igot. How will this backpack designed
for the "global digerati" stack up when Pierre puts it to the test
with his mobile digital lifestyle?
Scope
Driver (8-2-02) Dr. Neale Monks. An alternative to the 'point and click'
telescope control paradigm: a powerful list-based utility for Autostar and
LX200 telescopes.
Apple
Final Cut Pro 3.0 (7-19-02) Michael Tate Jones. Tate reviews the video-editing
powerhouse Final Cut Pro 3 and sizes up its competition. Does Final Cut Pro
3 hold its ground?
Strata
DVpro RME (7-16-02) Matt Frederick. Matt Frederick. Matt takes a comprehensive
look at Strata DVpro, Strata's pro-level non-linear editor for digital video.
Stargazer's
Delight (6-28-02) Dr. Neale Monks. Looking for a viable shareware alternative
to the big commercial astronomy software packages? Neale may have found one.
TheSky
(6-21-02) Dr. Neale Monks. Neale takes a look at the easiest to use planetarium
program for the Mac.
NI
FM7 (6-21-02) Matt Frederick. Matt takes this software replica of Yamaha's
DX7 synthesizer for a test drive.
The
Digital Universe (6-14-02) Neale Monks. Planetarium program, astronomy
encyclopaedia and space flight simulator all rolled into one - could The Digital
Universe be the ClarisWorks of astronomy software? Neale Monks takes a look.
After
Effects 5.5 (5-31-02) Michael Tate Jones. Tate reviews the OS X native
version of After Effects and likes what he sees.
InDesign
2.0 for Non-Professional Designers (5-24-02) Pierre Igot. In the second
part of our review of Adobe InDesign 2.0 for Mac OS X, Pierre Igot looks at
InDesign from the point-of-view of the non-professional designer - and finds
plenty to like.
Corel
Graphics Suite, Part 2 (5-24-02) Dean Browell. CorelDraw returns in full
force and Corel R.A.V.E makes its debut.
Corel
Graphics Suite, Part 1 (5-17-02) Dean Browell. CorelDraw is back, and
it's brought some powerful friends that makes this Suite worth the look...
OmniGraffle
2.0 (5-10-02) András Puiz. Analog napkins are so 20th century --
this gem from OmniGroup knows (almost) all about diagramming. András
Puiz wishes all Mac developers developed a similar understanding of Aqua,
and of Mac OS X in general.
Watson
(5-03-02) Michael Tate Jones. Tate discovers a 'Swiss Army Knife' for OS X...
it's called Watson.
Brian
Tiemann is the co-author of FreeBSD Unleashed
for SAMS Publishing, a webmaster from back in the
days when that meant knowing what the <BODY>
tag did, and an Apple fan who has gone from his grade-school
//c+ through various DOS, Windows, and UNIX boxes
to come home to the Mac fold once again. 
