🚀 go-pugleaf

This rather long posting is:
   1)  An observation about the conventional use and abuse of filenames.
   2)  An plea to Apple to prevent things from getting worse in System 7.0.
   3)  A few suggestions as to how that could be done.

BACKGROUND

A previous posting to this newsgroup suggested that System 7.0 should allow
filename pattern searches, so that one could, for example, find all
Stuffit files by searching for filenames ending in ".sit".  Applications,
scripts, or people could then use filename pattern-matching to select and
process a group of related files.

The goal is good, but I think the technique of matching filename patterns
is the *WRONG* way to get the job done.  Apple, please DON'T!

A filename should simply be a meaningful name that tells a person a file
contains, or, if it's a program, what it is or does.  That's ALL it should be.
Trouble is, it has become common practice to "encode" additional
information into filenames, like the file's type, its version number,
whether it has been compressed, and the like.  It's not unusual to see
files with cryptic names like "xmodem17.hqx".  Filenames aren't the right
place to store all that information, and pattern matching based on nonstandard
naming conventions isn't a reliable file lookup method.

WHAT I'M AFRAID MIGHT HAPPEN

My fear is that if System 7.0 makes it easy to do filename pattern matching,
people are going to be even more encouraged to rely on filename encoding,
either sticking with the old MS-DOS "8-dot-3" format for compatibility,
or even worse, NOT sticking with it and introducing all kinds of nonstandard
conventions.  There's the potential for a big step backward in user-
friendliness for the Mac, and it will make it impossible to develop utility
programs or scripts which *reliably* find and process groups of related
files.  The mechanism may defeat the goal.

DISCUSSION OF THE PROBLEM

The basic problem is that it takes a lot of info to describe a file.
MS-DOS or Unix file systems don't store much info about files, but the
Mac does better.  For example, version numbers can be stored separately
from filenames and can be viewed by picking Get Info from the FILE menu.
With a little effort, I think the Mac can do much better.

Even though the Mac stores more info about files than other filesystems,
System 6.0.x still has at least three serious drawbacks:

1.  You can't see enough of the extra file info on the desktop without
	asking for it (e.g., using "Get Info").

	If you use "View by Icon" you see only the filename and icon.
	"View by Date" shows you a couple more facts that you may not care
	about and omits some interesting things that you might, such as
	a program's version number.  That's why people compensate by encoding
	the extra info (redundantly) into the filename or even its icon,
	just so it's always directly visible.

2.  The system stores only a few predetermined facts about a file.

	Since it's impossible for Apple or anyone else to predict in advance
	ALL the interesting facts someone might want to store about a file,
	there should be some way of storing lots more *arbitrary* information
	about a file instead.

3.  There isn't an easy way for the casual user to write, access, and
	change the system-stored information about files.

    For example, how does one set the version number that appears in the
	"Get Info" box?  I don't consider using ResEdit or writing a program
	to alter file info or to create resources "easy for casual users."
	But changing a filename is, which is why users stuff file info into
	filenames now.
	
SOME SUGGESTED IMPROVEMENTS

So how can we improve the situation in future versions of the System?
Here are a couple of suggestions.  I'll bet you can think of more.

1.  Allow ANY combination of items of the system-stored file info to be
	displayed on the desktop in some kind of compact, legible format.

    Let me, the casual user, select what info should be displayed in the
	"View by Date" columns, maybe.  Or using "View by Icon", let me show
	a file's version number on a line under the filename.  I should be able
	to set up the Finder so that it shows me any info about files that I
	want to see.  I don't want canned choices like those in the current
	"View by Date", "View by Icon" menu; or if you want to keep those
	options for old-time's sake, add a "Custom View..." choice that lets
	me freely customize what file info is shown and how it is displayed.

	BENEFIT:  Users don't have to encode file info into the filename to see it.

2.  Give me a "File Info" dialog box that has at least two user-writable
	fields in it:  KEYWORDS and NOTES.

    The FILE INFO dialog box should display everything that "Get Info"
	displays now.  It should also contain two HyperCard-like fields which
	allow me to add more info about a file by just typing it in.  I want
	the FILE INFO to pop up when I option-click on the file icon; I don't
	want to have to first select the file and then go paw at "Get Info" on
	a menubar to get to it.

    This File Info box should have a predefined subfield on it labelled
	KEYWORDS.  There I can type any list of keywords or phrases that I
	want to.  This allows me to use KEYWORD RETRIEVAL to locate files and
	to select groups of files more reliably and flexibly than by pattern-
	matching encoded filenames.  You could provide a scrolling list of
	STANDARD keywords in this box that I can choose from, too, that
    Apple system utilities and third-party applications would recognize:
	"Pascal", "PICT", etc.  They wouldn't be limited to 4 characters like
	resource IDs are, although resource IDs could be included.

    There should also be a free-form NOTES field where I can enter any
	information I want to about the file.  If I later want to do text
	searches for strings in this field (either instead of or in addition
	to searching in the previous KEYWORD field), I should be able to do
	that; otherwise the System can ignore the contents of this field.  If
	I want to use it as a notes file or as a "read-me" associated with the
	underlying file, I could do that, too.  It would save having to create
	a separate text document that might get separated from the original
	file.  Rebuilding the desktop wouldn't destroy it.

	BENEFIT:  Files can be reliably located by matching Apple-standard
			  or user-defined keywords or user-defined text strings rather
			  than relying on cryptic, nonstandard filename conventions.

Perhaps there should be other fields the System could use, too.
A File Info box could contain a list of applications which can
or should be used to open the document if the application that created it
isn't found, for example.  If a user double-clicked a document when an
appropriate application wasn't present, the alert box that comes up could
then say something more informative, such as "One of the following
applications is needed to open this document: ..."

One last wish.  Normally, when one tries to copy a file into a folder that
already has a file by that name, an alert asks "Replace item(s) with the
same name?"  Clicking "NO" aborts the operation.  But if managed system
info like *file version numbers* are always user-visible, the Finder can do
a better job.  If the version numbers differ, the operation should complete
normally, since there really isn't a conflict!  If the version numbers are
the same, the user could 1) abort the operation, 2) request that one of the
version numbers be incremented, or 3) add a distinguishing KEYWORD or NOTE
to the File Info information to allow the copy operation to continue.

Bringing file version numbers out of the closet could be useful when a user
selects "SAVE" within an application, too.  A user could ask to create a
higher-numbered version of the file (keeping the same name) instead of
overwriting the existing file.  Or an application could provide a "SAVE AS
NEW VERSION" menu item which does that automatically.

To summarize:  Let me store and show more file info, give me keyword search,
and don't do filename pattern-matching in System 7.0.

If not, I'll bet we're right back to cryptic, nonstandard MS-DOS naming
conventions, and we'll severely undermine the usefulness of a command-line
interface or scripting capability.



** Claimer:  These ideas and opinions are strictly my own, but if you like
			 them, you can have them, too.  They're free.