|
Apple
Peel
|
|
Mac
OS X at Work - Part 3: The Finder - Long File
Names, Columns, Toolbars
|
©6-27-01
Pierre Igot
Table of Contents
Long
File Names at Last… but at a Price
File Name
Abbreviation Schemes
Inconsistent
Behavior
Different Ways
to Look at Files
Click Me Click
Me Not
The New Toolbar
Too Easy to
Customize, Not Customizable Enough
Infinitely
Looping Aliases
No Mac OS X feature has, so
far, generated as much discussion (or controversy)
as Mac OS X’s own Finder. While the
most common complaints have dealt with obvious performance
issues and bugs (of which there are quite a few),
OS X’s Finder also introduces a whole array
of new approaches that warrant closer investigation.
In today’s installment of our “Mac OS X
at Work” series, I’d like to explore some
of those new additions, and their consequences for
both long-time and novice Mac users.
Long File Names at Last…
but at a Price
While the issue of the length of files
names is not specific to the Finder itself (it affects
all applications), it is obvious that the Finder is
the application most affected by it. In fact, in recent
times, the classic Mac OS Finder had also become
the one application that had the greatest effect on
it for the end user. Indeed, in the good old days,
the classic Mac OS used to support file names
of up to 31 characters (including punctuation marks
and spaces). When the competition (DOS and Windows
up to 3.1) was stuck with file names of the severely
restrictive “8+3” form (file names of
8 characters maximum followed by a dot and a three-letter
suffix indicating file type), the much higher flexibility
of the Mac OS used to be a source of pride.
Those 31 characters soon became a limitation,
however, when people started working with an exploding
number of files and having to deal with organizing
them in an efficient fashion. With OS 9, Apple
introduced system-level support for longer
file names (up to 255 characters), but, for various
reasons, it never got around to actually implementing
the ability in the most important environment for
file manipulation, i.e. the Finder. In other words,
the latest versions of the classic Mac OS do
support longer file names, but the versions of the
Finder included with the system do not. In shorter
words, the ability was useless.
This is no longer the case with OS X.
The Finder does support longer file names.
Third-party OS X applications, however (i.e.
those that are “carbonized”) don’t
automatically support them as well. If you try to
save a file in BBEdit or Explorer for OS X, for
example, you will still hit the old 31-character limit
in the “Save As…” dialog box. That’s
because (I am told) Apple has yet to provide
third-party developers with the proper development
tools required to implement support for the feature.
The use of very long file names is therefore limited,
so far, to the Finder and those other OS X applications
that support them (such as Apple’s own TextEdit).
However, as you are surely aware, the fact that the
Finder supports them obviously means that you can edit
the name of a file created by, say, BBEdit and make
it longer than 31 characters. What happens then when
you try to open the file again with BBEdit (which doesn’t
support such long names)? Well, OS X uses a clever
— if not particularly pretty — trick in
which the extra portion of the name is replaced by a
unique string of characters that looks like a 2-byte
hexadecimal number (such as “#D9CB”), appended
to the beginning portion of the file name. This shortened
file name is the one that will appear within BBEdit.
But, when you save the file, its longer file name is
preserved.
OS X actually uses the same trick
for applications running under the Classic environment.
Obviously, those applications were written for the
classic Mac OS and were never meant to —
nor will they ever — support longer file
names. Here again, however, if you try to open a file
that’s longer than 31 characters with a Classic
application, it will be shortened using the same type
of unique identifier. It’s a fairly smooth process
all things considered, even if one hopes that Apple
will soon provide developers with the necessary tools
to make sure that we only have to deal with this in
older applications (which we can slowly eliminate),
and that most users will not have to deal with it
at all.
File Name Abbreviation Schemes
Once you start dealing with fairly long file names,
however, new issues arise. One of them is how to abbreviate
them in contexts — such as list views —
where they cannot be displayed in full due to a lack
of space. The problem isn’t new: Apple already
had to deal with it under the classic Mac OS, as
it couldn’t always display 31-character long file
names in full. The Mac OS used to truncate the
end portion of the name and use an ellipsis
(…) to indicate the incomplete status of the name.
In OS X, things have changed. The Mac OS still
uses the ellipsis, but it appears in the middle
of the file name. Depending on how much horizontal space
is available, the system uses the first few characters
of the file name, then the ellipsis, then the last few
characters of the file name. The number of characters
left depends on the available space. If you try to make
a window that is in Columns view as narrow as the Finder
will allow — to the point that it can only display
one character per column — then the ellipsis is
the only character left. Such an extreme action
makes it rather difficult to identify the files by their
names, and is obviously not recommended…
In List view, the length of the visible file name is
determined by the width allocated to the corresponding
“Name” column (adjustable at the top of
the window). There is a minimum width, which makes it
impossible to bring the character count down to one
as in Columns view, but the mechanism for abbreviation
is the same. (The Finder also uses the same mechanism
for columns such as “Type” or “Size,”
which can have fairly unsightly results as those columns
do not have the same minimum width limitation. For the
“Date Modified” column, however, the Finder
is smart enough to truncate the time stamp and only
display the date (without the time) when the column
is too narrow.)
I suppose that there are arguments
in favour of each approach (the classic Mac OS
ellipsis at the end or the OS X ellipsis in the
middle). One of the reasons for the change is, quite
likely, that file suffixes (such as “.txt”,
“.rtf”, “.mp3”, “.mov”, etc.),
while not exactly mandatory, are destined to play
a greater role in the UNIX-based and Internet-friendly
OS X than they were in the classic Mac OS.
Such suffixes should therefore remain visible as much
as possible. One other argument in favour of the OS X
approach is that people tend to differentiate between
files by changing their last characters — by
numbering files, as in “Letter 1”, “Letter
2”, etc., or by using the date as part
of the file, as in “Letter 06-05-2001”,
“Letter 07-04-1999”, etc. This used
to be a significant problem in the classic Mac OS
when there wasn’t enough space to display the
file name endings. Characters differentiating file
names from each other are more likely to be in the
beginning or in the ending of the name.
On the other hand, the fact that the
ellipsis is now in the middle means that many file
names are likely to become illegible or less useful
sooner than they were in the classic Mac OS.
If you had to choose between “Letter to Stephanie,
05-…” and “Letter to… -06-2001”,
for example, which would you choose? The problem is
compounded by the fact that, in Columns view, each
column can be quite narrow (depending, obviously,
on the width of your window), which makes such occurrences
far more likely.
All in all, however, file name abbreviation
obviously creates a no-win situation. No matter which
abbreviation scheme you adopt, you are going to lose
some information. Whether OS X loses
more or less information through abbreviation than
OS 9 is largely dependent on your own file naming
conventions and choices. Before you start cursing
at OS X, therefore, I suggest that you take this
opportunity to review your own file-naming habits,
and make some new choices that can take better advantage
of the new approach.
Inconsistent Behavior
One other issue with long file names
and the Finder is how to display them in the “Get
Info” window, which is now a kind of “Inspector”
palette whose content changes depending on the selected
file. As has been mentioned elsewhere, the new Inspector-type
approach has a major drawback, which is that you can
only display the information on one file
at a time. It makes it much more cumbersome to compare
two different versions of the same file (or folder).
I certainly hope that Apple will soon remedy this
situation, by adding, at the very least, the option
to open a second (or third, or fourth…)
“Get Info” inspector window whenever necessary.
Get Info for file
with long name
As regards file names, however, the
problem with the “Get Info” window is
that, no matter how long the file name is, it persists
on attempting to display it on one single
line. If the file name doesn’t fit in the small
box next to the file icon, instead of abbreviating
it, the Finder only displays its ending, and you need
to click in the name and actually use the left cursor
to scroll back towards the beginning of the name.
I’ve always found that approach rather annoying
— and, here again, I cannot help but think that
Apple had other, better options. For example, when
you want to edit a file name in the OS X Finder
and click on it to select it, if it was in abbreviated
form, the Finder now displays it in full (over several
lines, if necessary, thus temporarily covering whatever
is contained in those other lines) for editing purposes.
I fail to see why a similar approach couldn’t
be adopted in the “Get Info” window. It
would actually make the whole experience of using
the Finder more consistent.
(It should be noted that this behavior
doesn’t apply to locked files and read-only
volumes such as CD-ROMs — when you click on
the name of one of those, if it’s in abbreviated
form, nothing happens. Apple apparently doesn’t
think that you’ll ever want to see
the full name of a locked file or volume, without
wanting to actually edit it.)
Different Ways to Look at
Files
One of the most talked-about features
of the OS X Finder is the new view mode called
“Columns,” which lets you view two or
more columns representing the hierarchy leading to
the location of your current file. This new view mode
introduces an entire set of new behaviors which I
will examine more closely.
First, however, it should be noted
that this Columns view is really only the “tip
of the iceberg” — the most visible aspect
of a decidedly new approach. The classic Mac OS
UI is famous for having introduced the “spatial
metaphor,” i.e. a visual environment where computer
file storage is akin to, well, traditional “real-world”
file storage, with files in folders, folders within
folders, etc. In the classic Mac OS, the
consistency of this metaphor is actually quite strong
and, indeed, remarkable — which has contributed
a lot to Apple’s reputation as “interface
experts.”
For example, in the classic Mac OS,
if you double-click on a folder icon to open a window
displaying the contents of this folder, and if a window
displaying the contents of this folder already happens
to exist in the Finder environment, then the Finder
doesn’t open a new window with the
same contents, but activates (brings to the
fore) the already-open window. In other words, for
each folder, there can only be one window displaying
the contents of that folder. This makes sense in a
metaphor that attempts to be a faithful reproduction
of a “real-world” file structure —
in the real world, a file cannot exist in two different
visual locations at the same time.
The new Finder, on the other hand,
isn’t concerned with such constraints. Apple
did a good job of preserving (or restoring, after
hearing people’s feedback following the release
of the Mac OS X Public Beta) the traditional
spatial metaphor of the classic Mac OS. But the
very fact that the cmd-N keyboard shortcut is now
the shortcut for “New Finder Window” rather
than “New Folder” is a clear indication
that the new Finder is more about finding
things as quickly as possible than it is about preserving
the apparent integrity of the spatial metaphor.
The new OS X Finder approach offers,
and actually favors, the possibility of viewing the
same file from different angles, i.e. in different
windows, at the same time. There’s nothing that
says that you can’t have 10 different “Finder
windows” all displaying the content of the same
folder at the same time. The benefits are obvious:
for example, you can keep a window open with the contents
in List view in order to keep an eye on file size
— and at the same time have another window open
with the same contents in Columns view, in order to
keep an eye on the structure of your file/folder hierarchy.
Two ways to look at
the same file at the same time
I personally found it quite easy to
get accustomed to this new approach after I started
using OS X on a regular basis. After all, it’s
not like the traditional Mac OS approach was
absolutely, “purely” spatial. You still
had to “view” a file from a different
angle (the “Get Info” dialog box), for
example, in order to access some of the information
about the file (such as the creation date, the file
sharing status, etc.) — and file “previews”
in Open/Save dialogs were, yet again, an attempt to
compensate for the lack of information available through
the purely (or purer) spatial approach.
The truth is, until someone comes up
with a UI that enables the user to access all
the information about a file (including its contents,
its size, its “age,” its location, its
“shared” status, etc.) through a
purely spatial metaphor (possibly with a 3D type of
environment, with zooming effects, etc.) —
until then, the “spatial” metaphor will
only ever be partially implemented, and the
approach favored in OS X is just a slightly less
intuitive, but more powerful variant of the one favored
in the classic Mac OS.
I have grown quite fond of the Columns
view, in the few months that I have been using OS X.
I have always tried to keep my documents organized,
in folders, subfolders, etc. — and the
easy-to-browse hierarchical view provided by the Columns
view mode is just unbeatable in that respect. If you
click on the wrong folder in a list of folders, for
example (which can happen quite often in my experience),
you can easily correct your mistake, because the correct
folder is still visible right next to the one you’ve
just clicked in the left-most column — whereas,
in the classic Mac OS Finder, if you double-clicked
on a folder to open it and it turned out to be the
wrong folder because you didn’t “aim”
accurately enough, you had to at least close a window
or, worse still, use the title bar pop-up menu, if
you had the option key depressed so that the containing
window would automatically close, in order to save
space.
Click Me Click Me Not
This is not to say that the Columns
view does not have its share of flaws — which
will need to be addressed as part of Apple’s
on-going efforts to fine-tune the system. One of those
flaws has to do with the fact that browsing the Columns
view is done through single-clicking
on files rather than the more traditional double-clicking.
As soon as you click (just once) on a given file or
folder, the Finder changes the focus to the column
containing that file or folder, highlights the selected
file or folder, automatically scrolls left or right
in order to place the corresponding column in the
“center” of the window, highlights in
a lighter color the containing folder one step higher
(one step to the left) in the hierarchy, and displays
the contents of the folder in the column to the right
if you’ve selected a folder, or a preview of
the file if you’ve selected a file. This cascade
of events triggered be a single click makes sense,
and is useful most of the time.
The problem is that, when you actually
double-click on a file in order to
open it, the Finder still registers the first
of your two clicks as a single click for browsing
purposes, and therefore still scrolls one column further
to the right. This can be rather disconcerting, as
the scrolling actually is already taking place as
you are effecting the second click on the file. It
seems to me that, when one double-clicks on a file,
it indicates in no uncertain terms that one just wants
to open the file, and not to access a preview
of it or scroll further down the hierarchy. A double
click is a double click, and two consecutive single
clicks are two consecutive single clicks. It simply
doesn’t make sense that the first click in a
double click is interpreted both as the first
click in the double click and as a single click in
its own right (which triggers the cascade of events
described above) at the same time. The solution to
this is to set the Finder to respond differently in
case of a double click, i.e. by not registering the
first of the two clicks as a regular Columns view
single click, but only as the first of the two clicks
in the double click. (It’s funny how simple
things such as clicking on a mouse button can take
so long to explain, isn’t it?) This actually
reminds me of this absurd behavior of Microsoft Word,
which, when you click once on the ruler to
place a tabulation mark and then click a second
time to move that mark or place another one,
also registers those two clicks, which are
obviously intended as two separate actions, as a double
click, and opens the Paragraph formatting dialog box
for which double-clicking on the ruler is a shortcut!
You just know Apple is treading a dangerous path when
flaws in its interface can be compared to flaws in
a Microsoft product… Let’s just hope this
gets fixed soon.
Another problem with displaying previews
of files when the user single-clicks on them in the
Finder is that, due to the inherent slowness of today’s
hard drives (no matter how fast they are, they are
still too slow for many tasks), it can still take
time to load a preview of a big picture or movie file.
If one clicks on a file by mistake, there is no way
to stop the Finder from loading the preview —
which can take up to several seconds sometimes —
even if one is quite sure that one doesn’t want
to view it. This is a problem not only in the Columns
view in the Finder, but also in the Columns view used
in Mac OS X’s Open and Save dialog
boxes, which behaves in an identical fashion and therefore
suffers from the same flaws.
Another big drawback (for the moment)
of the Columns view (especially in Open and Save dialogs)
is that typing the first letters of a file/folder
name in order to get the system to jump to the corresponding
file names simply doesn’t work at all. This
can be extremely frustrating, as it effectively forces
you to use the mouse, even when you want to do everything
with the keyboard (which can often be much faster
and more efficient). This definitely needs to be fixed
by Apple as soon as possible.
The New Toolbar
Each OS X Finder window also comes
with an (optional) toolbar containing buttons which
provide direct access to certain locations. The “Favorites”
button, for example, automatically places the focus
on the contents of your Favorites folder in the current
window. It is important, because, up until OS X,
the use of the Favorites folder was somewhat limited
to Open and Save dialogs and to the Apple menu. It
is now accessible directly from within any Finder
window, which makes more sense if you want to encourage
people to actually use the feature — while many
Mac users, in my experience, still don’t. (Due
to the new file structure in OS X, with many,
many new folders and the inherent multi-user system,
it is actually quite likely than many Mac OS
users will eventually feel compelled to learn
how to use this “Favorites” feature at
last.)
Favorites in Columns
view
The current approach with the OS X
Finder tool bar, however, is still not optimal. For
example, when in Columns view, clicking on the “Favorites”
button in the Finder tool bar shows the contents of
the Favorites folder in the second column
from the left, while the leftmost column shows the
contents of the folder which contains the
Favorites folder (i.e. the Library folder of the current
user). This doesn’t make much sense to me. If
I want to access the contents of my Favorites folder,
it’s highly unlikely that I’ll change
my mind all of a sudden and decide to explore the
contents of the folder containing the Favorites
folder (i.e. my Library folder) instead. It would
make much more sense if the default behavior was to
put the contents of the Favorites folder inside the
leftmost column in Columns view.
As well, while the more accessible
Favorites folder is an improvement over the classic
Mac OS, the Finder still badly needs easy access
to a “Recent Folders”
folder as well. There is no reason why there shouldn’t
be an optional button that enables you to access a
list of aliases referring to the most recent folders
you have been exploring or using. This is the type
of functionality that third-party products such as
Default
Folder have been offering for years, and it’s
about time someone at Apple noticed that such products
do actually meet the very real needs of many Mac users.
The OS X Finder does have a “Recent
Items” feature, but 1) it only lists recent
applications and recent documents, not recent folders;
and 2) it is only accessible through the new
Apple menu. The Finder toolbar is now the ideal tool
to take UI flexibility to the next level, and help
Mac users work even more efficiently.
Too Easy to Customize, Not
Customizable Enough
Speaking of tool bar buttons, there
are other things that Apple might want to fine-tune.
This tool bar is customizable: you can add your most
frequently used folders to it, and they will thus
be accessible through a single click. You will even
be able to drag items directly onto your folder icon
in the tool bar in order to move the items to that
folder. The problem, however, is that the tool bar
is a bit too easy to customize: all you have
to do is drag an item from the current window to the
tool bar, and the Finder will automatically make room
for it where you are pointing your cursor and insert
it when you release the mouse button. But it happens
far too often (in my experience anyway) that, when
you drag an item to the tool bar that you actually
simply want to move to a folder that’s
in the tool bar, if you don’t aim accurately
enough, the Finder will end up adding your file to
the tool bar itself instead of transferring it to
the folder you were targeting. (This also happens
if you add a Trash button to the tool bar as well,
and use that icon often to quickly drag items to the
Trash.) I believe that, at the very least, dragging
items to the tool bar should only be interpreted as
indicating a desire to customize the contents of the
tool bar if some modifier key is depressed at the
same time. The default interpretation should be that
the user wants to drag the item to one of the elements
of the tool bar, not to customize the tool bar. Unless
you are a customizing maniac, it’s quite unlikely
that you’ll want to customize your tool bar
as often as you want to simply transfer files to your
favorite folders or move them to the Trash.
"Oops!" was going to
the tool bar Trash and then...
The other limitation of the tool bar
pertains to the fact that it’s not fully
customizable. Since the contents of the tool bar,
unlike the contents of the good old Launcher in the
classic Mac OS, do not correspond to aliases
in a “Tool Bar Items” somewhere in your
Library folder that you could easily manipulate, you
cannot easily change the appearance
of your tool bar buttons. You cannot, for example,
easily change the name of a tool bar button to a shorter
name so that the button doesn’t take up too
much space in the tool bar, or change the folder icon
so that not all the buttons referring to folders look
exactly the same. (The contents of the tool bar are
actually stored in an XML file, so I expect that,
sooner or later, a third-party developer will provide
us with a tool to further customize them using a user-friendly
graphic interface. One way to do it would be to enable
control-clicking on tool bar items in order to access
editing commands through a contextual menu. At present,
control-clicking on a tool bar item is no different
from simply clicking on it.)
There is, however, a work-around of
sorts that you can start using right away: instead
of dragging the actual item that you want to add to
the tool bar, you can first make an alias
of this item and store it somewhere else. You can
then change the icon of that alias, change its name,
and then add this alias to the tool bar instead
of the original item. The button will behave in exactly
the same way as the actual item would. The only difference
is that the button icon will inevitably sport one
of those small curved arrows now used to symbolize
aliases in the Mac OS.
Infinitely Looping Aliases
There is a problem in OS X with
this curved arrow symbol, by the way. In Columns view
and List view, under ordinary conditions (i.e. with
a reasonable icon size), the arrow is simply way
too small. It is often barely noticeable
— and, since Apple has decided that it would
no longer use the italics font style to indicate the
difference between aliases and actual files, there
is often no way to tell— other than by
squinting your eyes to the extreme — the difference
between a regular file and an alias. This needs to
be fixed.
Apple might also want to restore some
other kind of visual indication that a folder is an
alias rather than an actual folder. Indeed, with this
barely visible arrow symbol, in Columns view mode,
you will often see file hierarchies that seem to make
no sense whatsoever, because the Finder displays the
contents of the folder alias as if it were the folder
itself, but there’s nothing that indicates this
difference in the display.
Interestingly, Apple seems to be aware
of this issue, because the OS X Finder makes
it impossible for you to put an alias of a folder
inside that very folder. (It simply refuses to do
so.) However, it doesn’t prevent you from putting
an alias of a folder inside a folder inside that folder
(i.e. two levels down in the hierarchy). You can thus
end up having a Finder window in Columns view with
an “infinite loop” type of file hierarchy,
that looks something like:
Folder containing folder
containing alias referring to folder containing folder
containing alias referring to...
where the leftmost“Documents”
is the actual Documents folder, the “Letters”
in the next column is a folder inside that Documents
folder that contains an alias referring back to the
Documents folder at the top of the hierarchy, which,
obviously, contains a folder named “Letters”
that contains an alias of the Documents folder, etc.
You get the idea. Apple should obviously not
eliminate the ability to put an alias of a folder
somewhere down the hierarchy inside that same folder,
but it should provide the user with some kind of visual
feedback that indicates, clearly enough, that he’s
browsing through a “virtual hierarchy”
based on aliases of folders rather than the actual
hierarchy of the file volume itself.
This could be achieved through the
use of various shades for the column background color.
Right now, the background color in all columns in
Columns view is desperately white, and is not customizable
at all (whereas the background color in Icons view
is). Not only is this probably too bright
for many people, but a variety of shades of grey (or
another customizable color) in Columns view could
easily be used to enhance the user’s browsing
experience and reflect the difference between a hierarchy
of actual folders and a hierarchy based on aliases
of folders.
It is also unfortunate that Apple did
away with the Platinum list view color scheme, which
used lines of solid grey separated by thin lines of
white. This scheme was a welcome addition to the user
experience, as it helped guide the eyes through sometimes
very long lists of files.
Next Time: More on OS X's Finder
See also Part
One and Part
Two of this series.
Pierre
Igot
