Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!uwm.edu!uwvax!titanic!tonyrich From: tonyrich@titanic.cs.wisc.edu (Anthony Rich) Newsgroups: comp.sys.mac Subject: System 7.0 concern & wish list (LONG) Keywords: System 7.0, Finder, filenames Message-ID: <8821@spool.cs.wisc.edu> Date: 11 Oct 89 01:17:19 GMT Sender: news@spool.cs.wisc.edu Distribution: comp Lines: 162 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.