• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Type/Creator Codes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Type/Creator Codes


  • Subject: Type/Creator Codes
  • From: Jamie Curmi <email@hidden>
  • Date: Tue, 15 May 2001 19:56:43 +1000

Hi All,

Since I started the original thread, I thought I should just say something. Hopefully Apple have got the message from the responses here, and, I'm hoping, the feedback you've all given them through the MacOSX web page.

First, I didn't mean to make a flame war out of this. I was asking a serious question - thanks for all the great responses.

However, on the topic of extensions, I would like to just say a few things.

First, whether you like using extensions or not, mixing file name and file type is very bad from a usability perspective - regardless of the fact that Windows does it that way, as did NeXT (I believe). You should never be able to change a file's type by editing its name - this is basic good usability. It is part of the reason why Windows started hiding the extensions.

Having seen Windows users in the past change the extension of a GIF file from .gif to .jpg and believe that they had now created a JPEG - this should be evidence enough. Try this on OSX and you'll see the icon actually change from a GIF to a JPEG - even though this is not a JPEG. This is one of the biggest problem with using such a system.

Or having a text editor save a file with an extension you didn't request (like TextEdit) - another example of poor usability. Then when the user removes the extension so that the file name is like they originally wanted, and finding the file is no longer launches TextEdit?

Clearly just hiding all the extensions is not a solution, as some files do require extensions to be shown - for example source code (.c, .cc, .h, .java). But to blindly have all extensions showing, editable, AND essential for association in the interface is just poor all round. Clearly most Mac users are not happy with this, and I'd think anyone with a usability background is in total shock that this wasn't resolved earlier (didn't Apple once have the best usability people in the business?).

There are much better ways to do this - and OSX is capable, regardless of the file system being used. But file extensions like they are currently are probably the worst way to do this.

I am hopeful that Apple are working on something, and it will be revealed very very soon. If not though, I think there may be a revolt. I get very concerned when Windows is looking more usable than the Mac, as should you all.

One final thing I'd like to say. I am a Unix programmer - 10 years now. I basically came over to the Mac recently - mainly because of OSX. However, I'm sick of people characterising Unix users as wanting extensions on files, or Unix somehow requiring extensions to work. Unix has NEVER required extensions on file names. They have sometimes been used in the past because there was no way to determine the type of a file easily by just looking at it - no icon for one thing in the early days. They're convenient from a terminal. But I have scripts on Solaris at work without extensions - for example sh, perl, csh scripts etc. Executable don't end in .exe. Text files are often without extension such as README, INSTALL etc. Adobe FrameMaker on Solaris is quite happy to save files as "My Letter". Don't think for one minute that just because this is Unix underneath you need to throw out all the usability ideals of the Mac.

Jamie


  • Follow-Ups:
    • Re: Type/Creator Codes
      • From: Michael Dagate <email@hidden>
  • Prev by Date: Re: Newbie Question about Document/Window/Text Field
  • Next by Date: Re: changing entire content view of an NSWindow
  • Previous by thread: Re: Type/Creator codes
  • Next by thread: Re: Type/Creator Codes
  • Index(es):
    • Date
    • Thread