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.
I am not a developer, but I do know that what
Apple calls “Cocoa” is not an interface.
Rather, Cocoa
is an application development framework or environment,
i.e. a set of tools provided to the developer to make
it easier for him to develop OS X-native applications
without relying on older Mac OS tools that were
preserved for “traditional” Macintosh
developers as part of the “Carbon”
application development environment.
In other words, developing a Mac OS X
application using Cocoa is the equivalent of starting
with a “clean slate” — whereas Carbon
is designed for traditional Mac OS developers
who want to make their existing Mac applications Mac OS X-native
with a minimal amount of porting work.
Both Cocoa and Carbon enable developers to produce
Mac OS X-native applications, i.e. applications
that run natively under OS X and do not require
the “Classic”
environment to run in Mac OS X.
What makes an application developed using Cocoa
different from a Carbon application is that Carbon
is still very much a work in progress, and that Apple
has been somewhat slow to provide access through the
Carbon environment to all the “goodies”
that come with the Mac OS X architecture.
And many of these goodies have a very visual
dimension, so that they can be perceived by users
of Cocoa and Carbon applications as differences in
the actual interface of these applications.
Since Carbon is a bit of a moving target and Apple
keeps adding to it, making gradually more Mac OS X
goodies accessible to Carbon developers, it is a bit
difficult, especially for a non-developer such as
myself, to keep track of what exactly is Cocoa-specific
and what can be used by both Cocoa and Carbon applications.
What makes things even more complicated is that, just
because a feature is made accessible to developers
in the Carbon environment, it doesn’t mean that
it will be immediately accessible to the users of
Carbon applications. Once a feature is made accessible
through the Carbon environment, the developers of
these Carbon applications still need to update them
to make use of this feature. And that process can
and will take months and even years in some cases.
Still, at this point in the evolution of Mac OS X,
it is quite possible, as an end user, to perceive
a very real difference between Cocoa and Carbon applications
with respect to their interfaces and the way they
interact with their users. And this awareness, which
is reinforced every day in my work, is making me more
and more appreciative of what Apple is trying to achieve
with Mac OS X in general and with Cocoa
in particular. This column is, of course, only the
point of view of an end user, and developers would
probably have lots more to say about the relative
benefits of Cocoa and Carbon. But ultimately, as an
end user, I cannot be bothered with the concerns of
developers. I need to focus on the usability, cleverness,
and intuitiveness of the end products that I get to
use — or am forced to use — in my
daily computing activities.
Brushed-Metal Look
One of the first questions that need to be raised
is whether it is easy to differentiate a Cocoa application
from a Carbon application. I don’t believe that
there is an easy, sure-fire way to do it without knowing
a little bit about software development. But, with
the introduction of Jaguar, some more or less useful
“hacks” have been released by third-parties
that can give us a better idea of what’s going
on exactly. One of these hacks is Unsanity’s
Metallifizer,
a utility which does just one thing, i.e. turn all
Cocoa applications who have a “normal”
Mac OS X interface (with its mostly white
aspect and signature striped background) into applications
that sport a “brushed-metal” look, like
iTunes and iChat.
iChat
window, with brushed-metal look
This is not to say that all Mac OS applications
with a brushed-metal interface are Cocoa applications.
In fact, the first application with a brushed-metal
interface was… QuickTime Player 4 for Mac OS 9.
But, with Jaguar, Apple has made the brushed-metal
visual appearance a core component of the system’s
interface, which, in Cocoa applications, can actually
been turned on or off by simply toggling a single
“switch” somewhere in the definition of
the interface. That is why Unsanity have been able
to develop a small utility that does just that and
“metallifizes” Cocoa applications.
As far as I can tell, Unsanity’s hack doesn’t
have any significant drawbacks. It doesn’t affect
application performance, and the fact that most metallisized
Cocoa applications work perfectly well with their
new look is a testimony to the brilliant simplicity
of Jaguar’s interface architecture.
While the usefulness of the brushed-metal look is
debatable, I actually enjoy it a lot — and enjoyment
is an important part of the computing experience when
you spend your whole working day in front of a computer
screen. The Mail application, in particular, looks
perfectly fine with a brushed-metal interface (thanks
to Metallifizer) and I find it actually visually more
pleasing than the original interface:
Mail
with Metallifizer
(One side benefit of the brushed-metal look is that
it turns solid areas in windows into areas that can
be used to drag the window around — instead
of being limited to the window’s title bar for
this.)
Cocoa Drawers
In particular, I find that the border of the brushed-metal
drawer (i.e. the mailbox drawer in Mail) looks better
than the normal one. Such drawers are, as far as I
can tell, an interface tool that is only used in Cocoa
applications. (Other popular Mac OS X applications
using drawers include the browsers Chimera and OmniWeb.)
Those who use mostly Carbon applications might not
even be aware of their existence — but I find
them very useful and unobtrusive. (They literally
slide under the main window when you close them and
disappear from view, even though they are always readily
accessible.)
That being said, their mode of operation still needs
some fine-tuning in some cases. For example, in Mail,
the only way to choose whether the
mailbox drawer slides out of the left-hand
side or the right-hand side of the window
is by dragging a message to the general direction
of the left edge or the right edge of the window.
Not only should there be another, more intuitive way
to change this setting, but it also should be less
easy to change it by accident, by just dragging
something in the wrong direction.
Dialog Sheets
Speaking of things that slide in and out, another
interface feature that is pretty much specific of
Cocoa applications is the dialog sheet. (Microsoft
Office X applications — which are definitely
Carbon, and not Cocoa, applications — use sheets
for their “Save As…” dialogs, but
since they don’t use them anywhere else, even
where it would make perfect sense to use them —
for “Print…” dialogs, for example
— I suspect it’s mostly a gimmicky hack
that they used to try and boost the sales of an otherwise
disappointing upgrade.) The idea is that, when a dialog
is specific to a particular document window, it should
not interfere with activities in other windows in
the program, and should therefore be “attached”
to the document window in question. Apple chose to
indicate this relationship in a very visual manner,
by making the dialog slide out of the title bar of
the window as a “sheet” that stays attached
to the window and moves with it, without affecting
other windows.
Dialog
Sheet - TextEdit
Dialog sheets are actually one of the few areas
where the brushed-metal interface doesn’t work
quite right (whereas it works quite well in the standard
Mac OS X interface theme). The “sheet”
that slides out actually sticks out and doesn’t
really look like it’s properly attached to the
window. Other than that, sheets are definitely a significant
improvement from a usability point of view, and it’s
a shame that they only seem to be available in Cocoa
applications so far.
Customizable Toolbars
While OS X’s customizable toolbars are
not the exclusive domain of Cocoa applications (the
first application to feature this type of toolbar
was actually Explorer 5 for Mac OS 9, even
before Mac OS X was available). But they
seem to be much more prevalent in Cocoa applications
— which is probably due to the fact that many
Carbon applications come with their own, existing
interface baggage and that their developers appear
unwilling to rethink that existing interface drastically.
(Office has its own, proprietary toolbar architecture.
Adobe applications have their palettes, dockable or
not. Etc.)
Toolbar
- Finder
I particularly appreciate the fact that Apple keeps
improving OS X’s toolbar feature. In Jaguar,
for example, Apple introduced a new behavior for the
button in the top-right corner, when used in combination
with the command key. Clicking on that button with
the command key down makes the toolbar cycle through
several different states, including one with smaller
icons, one with icons only, one with small icons only,
and one with text only.
Toolbar
with big icons and text
Toolbar
with small icons and text
Toolbar
with big icons and no text
Toolbar
with small icons and no text
Toolbar
with no icons and regular text
Toolbar
with no icons and small text
The only problem is that, right now, this only works
in a handful of Mac OS X applications, including
System Preferences and Mail, but not in the Finder
itself (presumably because the Finder uses a somewhat
more complex kind of toolbar, with less flexible items
such as the “Search” field, that can not
be easily reduced to a text-only button). Still, it
is a nice improvement, and one hopes that, like toolbars
themselves, it will be adopted in more applications.
Other aspects of the customizable toolbar still
need refinements as well, however. For example, while
the toolbar is only customizable through a “Customize
Toolbar…” command in most applications,
in the Finder it can be changed by simply dragging
something to it. There’s nothing wrong with
this in theory, as this means that the toolbar can
easily be used as some kind of temporary “shelf”
for documents and folders. The problem is that some
of the icons in the toolbar might be folders that
you want to use as destinations for items you are
dragging to them. In such cases, having the folder
move to one side in order to create a space for the
item you are dragging is not the
expected behavior, and it’s an annoyance when
all you want to do is put the item you are dragging
inside the folder that’s already
in the toolbar. You can still do this, of course,
but more often than not if you don’t aim properly
by dragging the item directly onto
the folder icon, then the Finder thinks that you want
to put your item in the toolbar and not inside the
folder.
The Dock itself is affected by a similar problem.
How many times do you want to customize the contents
of the right-hand side of the Dock by adding an item
(file or folder) to it as opposed to dragging an item
onto a folder icon that’s already in the Dock?
Apple seems to have decided that you will more often
want to customize the Dock — and I’m not
sure it’s the right decision. The Dock can only
hold a limited number of items before it becomes too
big or the icons become too small, and if you only
want to use it to hold a few frequently-used folders
that you want to drag items to on a regular basis,
then the default behavior (i.e. the Dock opening up
a space to let you add the item to it) will be an
added annoyance, just like in the Finder toolbar.
(It should be noted that you can actually disable
this default behavior by holding the command key down
while you are dragging the item — but that doesn’t
solve the problem, because it requires an additional
step for the behavior that should be the default one.)
Font Smoothing
Font smoothing (a.k.a. anti-aliasing) has been with
us since the early days of Adobe Type Manager and
TrueType fonts. But with Mac OS X it has
taken a giant leap forward, becoming the default behavior
for text throughout the system and applications.
While there is still some debate over the appropriateness
of this, on the whole, using mostly flat screens in
my daily computing activities, I find OS X-native
font smoothing (a.k.a. Quartz Text Smoothing) very
pleasant and very “print-like”. I have
not experienced the “fuzzy text” that
some people are complaining about. It might have to
do with my particular choice of fonts — but
that’s precisely one of the benefits of having
a choice. If you don’t like the way OS X
smoothes text, instead of turning text smoothing off,
try different fonts and see if there is a combination
that suits you better. You should also try to play
with your application’s zoom settings. For example,
I always use Word with a zoom setting of 150%, because
the definition of screens is now high enough that
11- or 12-point text (whether it is smoothed or not)
is actually too small on screen. (You can add a small
macro command to Word’s Normal template that
will automatically set the zoom to 150% for you and
resize your document window accordingly when opening
a document.)
In fact, I sincerely hope that computer screen resolutions
will continue to become finer and finer at a decent
pace, so that screens become closer to print and font
smoothing ends up becoming superfluous, because font
display is smooth enough without it (just like printed
text is). Of course, an LCD screen with a 300 dpi
resolution is still a long way off (and will require
graphic cards with huge amounts of RAM), but
we will get there eventually — and I, for one, am
looking forward to it.
Meanwhile, in the here and now, Quartz font smoothing
is the next best thing. It’s not perfect, but
it is much better than the type of font smoothing
we used to get in Mac OS 9 with TrueType
fonts (although ATM Deluxe’s font smoothing
for PostScript fonts onscreen was already better).
Until Mac OS X 10.1.5, however, Quartz font
smoothing was only available in Cocoa applications
(such as Mail or TextEdit). Fortunately, in 10.1.5
and in 10.2, Apple has made it accessible to Carbon
applications as well. (In 10.1.5, the feature was
actually buggy and unusable with PostScript fonts.
Fortunately, this has been fixed in Jaguar.)
The problem is that these applications need to be
updated to take advantage of it. Here again, Unsanity
has come up with a hack, called Silk,
which works reasonably well in Carbon applications
(such as Eudora) that have not been updated for Quartz
text smoothing yet. In other applications (such as
BBEdit and Mailsmith), the results are not as palatable,
and it is actually better not to use the hack for
those applications for now (you can turn Silk on or
off for each app on an individual basis).
Even in those applications in which Silk works,
or in those, like Microsoft Explorer and Word, which
have been updated to add a Quartz text smoothing option,
the result is less than perfect. If the background
color is anything but white, for example, you end
up getting a lot of whitish artifacts around the characters
— whereas such a problem does not occur with
Quartz text smoothing in Cocoa applications.
Quartz
Text Smoothing in Explorer
Quartz
Text Smoothing in Navigator (Chimera)
One hopes that this is something that Apple will
remedy in a future Mac OS X update —
although there might be practical limitations.
A Great Example
There are many more aspects of what I call the “Cocoa
interface” which I like and find quite enjoyable
(and there are still some that need more fine-tuning,
of course). To give you a quick idea of these other
features, I’d like devote the last section of
this column to a little gem of an application that
I have just discovered online a couple of weeks ago.
The application is a small utility called Can
Combine Icons (CCI). The name doesn’t sound
like much, but pretty much describes what the program
does at a fundamental level: it enables you to combine
two high resolution Mac OS X icons (of any
kind) into a single icon, to fine-tune the resulting
icon, and then to use that icon for whatever file
you want to personalize by copying it and pasting
it onto the file icon proxy in the Get Information/Show
Information window.
The usefulness of this application is pretty obvious
to anyone who sorely misses Finder label colors in
Mac OS X. If you put several document folders
in the Dock, for example, there is absolutely nothing
that distinguishes these folders from each other.
You can’t apply colors to your folders, so the
only way to differentiate them is to hover over the
folder icons so that the Dock displays the names of
the folders:
Dock
with generic folder icons
To put it simply, this is a very bad example illustrating
how Mac OS X is, in certain respects, still
desperately “dumb” when it comes to user
interface and plain usability. Fortunately, Can Combine
Icons comes to the rescue — and if very Cocoa-like
fashion, with a very simple, yet very powerful interface.
The main window, called the “Well”, holds
the two icons you want to combine and the resulting
icon:
Can
Combine Icons - The Well
CCI provides you with a “Library” of
icons to begin with, including all the usual suspects
that are already part of the standard set of Mac OS X
icons (closed folder, open folder, disks and hardware
icons, etc.). In this example, I am simply
combining the icon for a closed folder with a power
button symbol. But CCI lets you do much more: you
can colorize either of the two items (with adjustable
levels of saturation), you can tweak the drop shadow
effects, you can move or resize either icon, and you
can also add the “Aqua folder perspective”
to the second icon so that it appears to have been
pasted onto the folder in perspective. You achieve
all this using either menu options or the drawers
that slide out from underneath the Well — a
sure sign that CCI is indeed a Cocoa application in
all its simple beauty:
Can
Combine Icons - The Well with Adjustment Drawers
And then all you have to do is copy the icon and
paste it into the icon “well” in the Get
Information window for the folder of your choice.
In other words, with a minimum amount of work,
you can turn a boring row of identical folder icons
in the Dock into a much more colorful and intuitive
set of folder icons that reflect their respective
contents:
Dock
with set of personalized folder icons
As well, the Library palette in CCI can be enriched
with any icons — and you can actually use a
command to instruct CCI to scan any application package
for any icons contained within, that it will then
automatically add to the Library.
There are lots of other features in CCI that make
the application even more pleasant to use —
and, with a few mouse clicks, you can easily produce
lots of elegant, professional-looking icons for your
personal use. It’s Finder labels on steroids!
The possibilities are endless — and all of this
is yours for a mere $10. It is true that this represents
an added cost for something that some might feel should
be an integral part of the OS. But you can decide
to moan and do nothing about it, and spend $10 to
encourage someone who is obviously a talented Cocoa
developer.
Conclusion
I am not saying that Cocoa is perfect or that
it is the miracle solution to all your Mac OS X
problems, either as a developer or as a user. It still
needs improvements.
For example, several Cocoa applications need
work on the performance and reliability front. Jaguar
applications such as iCal
or the new Address
Book are too sluggish, even on powerful machines.
And the Mozilla-derived Chimera
web browser, which puts a native Cocoa face on the
Netscape-developed rendering engine “Gecko”
and which I much prefer to MS Explorer in several
respects, still suffers from too many unexpected crashes.
And there’s nothing more infurtiating than having
painstakingly opened and loaded a dozen different
web pages only to see them all disappear in an instant
due to an “unexpected quit”. (Chimera
does not have a History feature yet, and, unless you
have bookmarked the pages, you have to start your
browsing all over again.)
Still for all the remaining problems, when I use
Cocoa applications, I cannot help but feel that I am
catching a glimpse of what the future in OS X
will be: simple but powerful applications, combining
intuitiveness, fluidity, scalability, and sheer elegance.
Some of these qualities are accessible in the Carbon
environment and through existing Carbon applications
— but only Cocoa applications combine so many
of them into such simple, attractive packages. Cocoa
applications is the environment where Mac OS X
truly shines, and I can’t wait to see more developers
adopt the architecture as their main development environment
and to see the end users reaping the benefits of all
these improvements.
POST SCRIPTUM: I initially wrote in this column that text drag-and-drop was not available in Cocoa applications such as Mail or TextEdit. As several readers have since told me, this is incorrect. Text drag-and-drop is available in Cocoa applications. It's just not obvious that it's there. If, like me, you are used to clicking and holding the mouse button down and starting dragging the text right away, it won't work. You need to click and hold the mouse button down for about a second or so before you start dragging the text. Then it works perfectly fine, either within a given text block or between applications.
It's a shame, however, that this one-second delay is not adjustable. I, for one, am very much used to dragging right away, without delay. The delay is an added annoyance as far as I am concerned. One size does not fit all.
Thanks to all the readers who wrote with the correction. I did not intend to spread misinformation. In over a year of using Mac OS X daily, I just hadn't noticed that it worked that way. It's a case of being too accustomed to Mac OS Classic/Carbon ways. (Immediate drag-and-drop still works as it did in OS 9 in Carbon applications such as MS Word, without the delay.)
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.
The application is a small utility called 
