Never get confused by your filesystem again, thanks to overly verbose documentation harassing you at every step. Also apparently no one uses filesystems anymore now that computers have become phones.
Back in the ancient days before iPhones, people would store files in a hierarchical fashion in “folders” or “directories” on their computers.
Sometimes, despite relatively descriptive folder names, it is not clear what a folder / directory actually is. For example, on Mac OS X, a casual user may be flummoxed by the presence of the “Library” folder on their hard drive, or surprised to see unusual directories for software that they perhaps installed but do not recognize.
This is especially frequent when a program has support files under a company name. For example, if a person did not know that Photoshop was made by Adobe, they might be mystified by the sudden presence of many “Adobe” support files on their system.
Proposal: allow comments to be attached to files and folders
The proposal is simple: to allow descriptions of folders to be easily visible in the user interface.
Associating a comment with a file / folder is (surprisingly) already a multi-decade-old feature in Mac OS. However: no one ever uses it because:
1) it is extremely inconvenient to actually view the comments
2) since it is never used, it’s not worth checking for comments, because there won’t be any.
Fig 1: The Mac OS actually provides a built-in way of annotating a file or folder, but no one ever uses it, perhaps because it’s in a very out-of-the-way location.
To fix this, we will attach comments to the folders in a more obvious fashion, as shown in figure 2.
Fig 2: The gray region at the top of the window is a comment about the purpose of the directory. No more need to search online when you are mystified about which program created a folder, or whether it’s important to system operation.
Another reason no one used Mac OS comments is that, historically, they were extremely easy to wipe out with certain common system-cleaning operations. We could make the annotation system more robust by simply storing the comments as an invisible file (perhaps “.dir_comment”) in the folder that the comment applies to.
This would also make it easy to implement the commenting system in the shell; perhaps the “ls” operation could display some context about a queried directory as shown below
Fig 3a: In the terminal, a directory listing typically looks like this. If only we could easily discover what the “Library” directory was!
Fig 3b: An “enhanced” version of Fig 3a, where the directory shows some information about itself to the user.
Fig 4: This feature may be particularly useful when it comes to describing software that has been added to the system. For example, a user may be curious about the “TeX” directory, and wonder if it is an important part of the system, or if it was some piece of software they installed several system versions ago and forgot about.
This would be easy to implement as a wrapper to the ls command that would print the contents of a file before printing the directory’s contents.
PROS: This feature would promote sales of larger monitors, since all the documentation would crowd out actual on-screen content.
CONS: It is likely that every description will be as cryptic as a typical UNIX man page (“manual page”). See bonus Fig 5 below for an example.
Fig 5: With a clear synopsis like this, it’s obvious why the man page for “scp” does not bother to include any examples of how to use it.