Help! There's a Piece
of Windows in my Mac OS X!
And it's even OFF by default... Steve, save us from
whatever pointy-haired manager thought this was a good
idea!
Sept 19, 2001
After receiving some clarification and doing some
research on how Apple has in fact gone about implementing this
feature in Mac OS 10.1, I have reconsidered many of my opinions on
the subject. Foremost in importance in changing my mind is the
thought that Windows users resent Macs because the files they get
from Mac users never have extensions-- and we want Windows users to
like Macs, not resent them. So after discovering some of the
rather interesting ways Apple has tackled this problem (no, it's
not a simple matter of "chopping off everything after the final
dot"), I have sent a piece of feedback to Apple outlining my
revised opinions.
Naturally, this all may seem a bit petty compared to the scale of
the world events that now occupy all our thoughts... but at the
very least I wanted Apple to know that my faith in their ability to
design software the "right" way, while it was shaken for a while by
the issues I wrote about on August 2, is for the most part
restored.
Aug 2, 2001
Hiding File Extensions in Mac OS 10.1-- why it's a BAD idea
One thing is clear, at least, from the public history of Mac OS X to date:
The Feedback page does indeed work. Apple listens to the reports people
send in. What we say to Apple does make a difference, and so Mac OS X will
indeed become one of the most community-designed commercial operating
systems in history.
However, one other thing that's clear is that Apple is capable of
misinterpreting some of our comments, misunderstanding some of the issues
we bring up, and implementing ill-advised solutions that aren't as well
thought out as they could be.
I'm thrilled by most of the upcoming features and enhancements in 10.1
(http://www.apple.com/macosx/newversion).
The update promises to bring performance and functionality that we've
only dreamed of to date. Almost all of the proposed changes listed on
that page are excellent-- all except one. They propose to add an option
to hide filename extensions.
This is a terrible idea, both from a user interface and usability
standpoint and from a security and functionality standpoint. It's a
regrettable Windows-ism that has led to all kinds of problems in Windows
that could have been alleviated quite easily at the outset with a better
initial design-- a design that the Mac OS has always had, and now is only
missing because of time-to-market concerns (I hope). Hiding filename
extensions is a bad, bad, BAD design concept-- a band-aid over a shoddily
designed app binding system, and the Mac OS can do without it.
Many users will think "Oh, good, they're giving us an option. New options
are good." Well, first of all, more options are not necessarily a benefit.
A major part of what makes the Mac OS what it is is its ease of use and
its well-designed user interface, which comes from a carefully chosen set
of options being presented-- only those that the user needs, with anything
more complex hidden in "Advanced" panels. Giving the user the option to
hide filename extensions is just asking for trouble. We'll have new users
bewildered by the concept of files that are named one thing in some
circumstances, and another thing elsewhere. We'll have tech support people
trying to work around that additional level of complexity when trying to
track down system problems. We'll have chaos, much like Windows users
already have. Windows power users always say the first thing they do when
they install a new copy of Windows is to turn off the "hide filename
extensions" option. But power users are a very tiny minority, and the rest
of the world has yet another mysterious bit of computer trivia to contend
with.
The Apple page claims that the new option is to benefit "long-time Mac
users who prefer working without [the filename extensions]". This is
simply NOT the way to provide that benefit. Power users who prefer to work
without filename extensions will simply remove the extensions by renaming
the files, NOT by flipping some global switch somewhere that puts masking
tape over the files' labels. In my Movies folder, I have files with names
like "allyourbase.swf", "Terrible Secret of Space", and
"ninjakitty.mpg.mpeg"... some of which I want to keep with their
extensions, some of which I don't. A global switch wouldn't do me any
favors here. I want to see the extensions on the files that I will be
transferring to other platforms, but I want to be able to remove the
extensions on my OWN files-- the ones that I'll only be using on my Mac,
or sharing with other Mac users-- and have the file still retain the
proper icon and remember which app to open in. With type/creator codes
properly set, like it always has been, that's what will happen
anyway.
|
My Movies folder: the way
things ought to be. |
If we allow extension hiding in Mac OS X, we'll end up creating files
like that "ninjakitty.mpg.mpeg" I mentioned-- probably created or saved
by someone who perfectly innocently got confused about whether he was on
a machine with extensions hidden or without. Do we want to go down that
road on the Mac? And what about Outlook viruses? Many of them are
designed to take advantage of exactly that confusion. There's one making
the rounds right now (SirCam) that sends out attached files with names
like "essay.doc.vbs" and "Picture.gif.lnk", and most users react with the
knee-jerk "Oh! A .doc file... that opens in Word!" and innocently
double-click on it. If we start down that slippery slope, very soon we'll
be just like Windows XP, which installs by default with a "Shared Music"
folder that has three files in it called "music"... actually they're
music.asx, music.wma, and music.bmp, but the extensions are helpfully
hidden. Thank you so much, Microsoft.
|
Windows XP
being "helpful". Or perhaps Mac OS XII... |
The feedback that Apple is responding to is from people like us who
noticed that some of the NeXT-derived apps that Apple bundles into the
OS-- TextEdit, Mail, Preview, and so on-- don't set type/creator codes,
and rely on filename extensions to map files to themselves. If you remove
the extensions, the files lose their icons and app bindings. That's a
ludicrous throwback to the 80s by comparison to the robust and flexible
system of type/creator codes and default icons and the Desktop database,
and MacInTouch readers kept up the outraged rhetoric about it for weeks--
but eventually we all agreed that the fact that these apps didn't support
type/creator codes was most likely due simply to the apps' legacy nature
and the short development time. New versions of these apps and Cocoa that
fully support the type/creator code API are sure to be forthcoming. But
Apple took our complaints to mean simply "We don't like to see filename
extensions!" rather than "We don't want our applications to rely on
filename extensions instead of type/creator codes!"... and they helpfully
tried to "solve" this by offering to hide the extensions. This doesn't do
a thing to address the underlying weakness of design that results in
having to rely on the extensions. It's a quick and dirty piece of
deception that lies to the user. It's like customers clamoring
for Ford to put a V-8 into one of their 4-cylinder models, and
Ford responding by putting a "V-8" sticker on the car's fender.
It's important to realize that it's potentially even more dangerous on
the Mac than on Windows for filename extensions to be hidden. On
Windows, if you see a file with a "picture" icon and a filename like
"picture1", you know that the system has extension hiding turned on--
because the file wouldn't have the proper icon otherwise. On the Mac,
what you see is what you get-- the filename is as shown, with no hidden
trickery or extensions lurking up the OS's sleeve, and no constraints on
what the file has to be named. But in Mac OS 10.1 with extensions hidden,
if you see a file called "picture1" with the Preview icon, you have no
idea what the file's real name is-- it could be "picture1.gif", it could
be "picture1", or it could even be "picture1.foog"-- and it will still
open in the proper app and have the proper icon if the type/creator codes
are set properly. Those are all valid names. ALL names are valid. The Mac
even allows custom icons, which even further confuses the issue-- IF
extensions are hidden. But everything "just works" if extensions
aren't allowed to be hidden.
There are two kinds of files we need to be talking about here:
files that are native to the Mac OS and not likely ever to be transferred
to a non-Mac platform; and files that are intended to travel between
platforms through the Web, e-mail, and other transfer methods. Likewise,
there are people who create content for cross-platform use, and there are
people who don't. I contend that people who create content for use on
the Web understand how filename extensions work on other platforms.
They don't need to have their hands held. They've never been confused by
extensions on files they download or create in programs that attach
extensions for them. They *need* those extensions to help them create
accurate Web content. They need to know the filenames as they truly are.
But users who don't create such content-- well, they'll be working
primarily with Mac-only files, and so they don't need to have the option
to hide the extensions on files. Pictures they download will tend to have
.jpg and .gif extensions, but so what? If those files have the
type/creator codes set properly, they can delete the extensions! The
files will still work! If they want to remove the extensions from a big
bunch of files, why not make that a contextual menu option-- "Remove
Filename Extensions" from any selected files-- which would rename them
all at once? If they want to send the files out to their Windows-using
friends, applications can map extensions onto them automatically as
they leave the computer so the user doesn't have to worry about it.
This is OS-level trivia that computers deal with much better than people.
So why make the users shoulder the burden?
And if you choose to hide extensions, what about files called things like
"My Diary 4.5.2001"? What would it show up as-- "My Diary 4.5"? That's
not helpful. and what about "com.apple.whatever.extension" and so on?
Multiple name parts abound. Why are we arbitrarily chopping off the last
one when we display it? Gaah! It's just not going to work. It's not going
to help anybody.
What I want is to be able to take "My 2000 Taxes.pdf", chop the .pdf off
the end of the file by renaming it, and have it still appear and operate
the same as it did before. That's the system we had in the old Mac OS, and
it was GOOD. Mac users who created files to send to other platforms have
always done fine with extensions-- they've never been confused or
irritated by them; they've understood that they're a fact of life for
non-Mac platforms, and they've never regretted that they can't hide the
extensions from their own delicate eyes. But now, we have a system where
files-- even those that are part of the OS-- are improperly typed and
dependent on extensions. "Late Breaking News" was always a hallmark of the
Mac OS... a nice-looking filename on a file with a newspaper icon.
Perfectly understandable. But now we have "LateBreakingNews.help"... agh!
Gross! And if you remove the .help from the end, the file loses its app
binding and icon. That's hideous. And all because the designers didn't see
fit to give the file proper type/creator codes and a nice-looking
filename.
(Actually the file does have type/creator codes, but the icon is a custom
one-- it's still all fouled up. I'm just using this as an
example.)
What we need to do is fairly simple. Have all files that are
created by Mac applications require and prefer type/creator codes.
Extensions should only be used on files that are destined for
cross-platform use. Applications that create such files should OFFER to
add an extension, but not require it-- see Photoshop for this
functionality in action. Adobe got it exactly right. Photoshop gives you
a Save box with the basename highlighted, and an appropriate extension
for the file type appended-- you can delete it if you like, if you won't
be putting the file up on the Web or sending it to a Windows user. And it
sets type/creator codes so it will still open in Photoshop no matter how
you rename the file, but a Photoshop-created JPEG file will still open in
Preview and PictureViewer and any other app that claims to be able to
open JPEG files. It's a sytem that's beautiful and elegant, and it
doesn't need to be screwed with.
|
Photoshop's
Save box-- an excellent and flexible design. |
"File extensions help Mac OS X maintain full Internet compatibility",
Apple's page claims. Well, yeah, but we shouldn't have to DEPEND on them.
The old Mac OS had the Internet Control Panel, which watched for incoming
files (entering via HTTP, mail, FTP, and so on) and assigned type/creator
codes to the files according to a lookup table keying on the filename
extensions. That's fine, especially if we have control over that lookup
table and what apps it decides to map to what extensions (which we don't
at the moment). But now, bare extensions are treated as the authoritative
method for typing foreign files-- they never go through a process where
they get type/creator codes. Functionally it works the same-- except
if you rename the file. Take off the extension on a foreign JPEG
file in OS 9, and it still opens in PictureViewer. Do the same in OS X,
and it turns into a clueless blank Document. This is just plain
dumb. We need the functionality back that we used to have with the
Internet Control Panel. Hiding filename extensions just cripples us in
that regard-- it makes it even harder to do what we really want with the
files.
Apple is on the brink, here, of succumbing to true Windowsian design hell
by deciding to allow people to hide an arbitrary part of the displayed
filenames. What we need is not to sweep the obvious design flaws of Mac
OS X's current file typing system under the carpet and pretend the
extensions aren't there. We need to fix the problem at its core, by
making sure the Mac's ever-superior app binding system continues to be
the way it's done on OS X. Hiding filename extensions doesn't do anyone
any good. It will confuse new users and annoy power users. We
can't even make it an option-- that will just add an unneeded layer of
complexity to the system and make troubleshooting that much harder.
Stupid options like hiding filename extensions were what drove me away
from Windows to the Mac in the first place, and I don't want them
following me here!
The great thing about the Mac is that it continues to work no matter what
you do to files through their exposed and mutable pieces of meta-data
(e.g., filenames and icons). You can give a file whatever name you want,
you can apply your own custom icon, and it doesn't blink. But Mac OS X is
at a crossroads. It can either properly fix the oversights that are
crippling our ability to do those things... or it can cover up those
oversights with band-aids and whitewash, turning our slick, elegant system
into a scarred, badly healed mess just like Windows. Apple has the final
say on this, of course; they're the ones doing the actual work, and so
they do deserve immense respect for accomplishing what they have so far
and for so many of the other great planned enhancements. However, we do
have the power to help make sure Apple does the right thing on this
matter. We love our platform too much to see it wounded like this.
If you're with me on this, please help me let Apple know how important
an issue this is. Use their Feedback Page to ask
them to remove the "Always show file extensions" option, and fully
support Type/Creator codes in all bundled system apps and in Cocoa. We
can make a difference!
Related Links:
- iGeek: File
extensions -vs- type/creator
David K. Every, creator of MacKiDo, claims that both the Windows
file-extension method and the Apple type/creator codes are flawed... but
the Windows way much more so.
More to come as the word spreads...
© 2001 Brian Tiemann (btman@mac.com)
Apple, Mac OS X, NeXT, TextEdit, Mail, and other names are trademarks of
Apple Computer, Inc.