[Proposal] Formats and extensions : towards an end-user-friendly management
moramarth at gmail.com
Wed Jun 20 08:33:52 PDT 2007
For a basic 60-years-old John Doe use, since the beginnings of his digital
life 20 years ago, facing files' names+extensions and formats has been
becoming closer and closer to nightmare :
The numbers of formats used by average Joe rocketed through the roof :
multimedia files as movies are common now, lots of new formats for the same
task (ex: PNG, SVG for images, GIF and JPEG are still common), etc. Two
examples of concrete and common nightmares :
Dear Joe, you used to listen to mp3 files ? Now, there's better formats.
mp3++ = mp4 ? Actually this time, it's for video, the sound one is m4a, but
the files are commonly referred to the format name : AAC. Headaches ? Wait,
there's WMA, Real Audio, Ogg/Vorbis (don't confuse with Ogg/theora), …
Dear Joe, you foolishly thought you could play this .avi as the previous one
? But the required codecs are different ! Exactly, it's a set of formats,
not just one, and only the container is publicized by the extensions.
Headaches again ?
Fact is, nowadays, extensions are a true miserable failure : it's scarcely
helpful for the end-user to foresee if he could read or not the files, it's
overloading the file's name, and a lot more.
Yet, how to handle the issue (allegedly) tackled by extension a more elegant
Fortunately, lots of uncoordinated improvements already show us useful clues
First : MIME-Type in the meta-data and libmagic to clean up after files made
or send by low-quality way. I'm not skilled enough, but some competitors'
ideas are deemed even more efficient  according to some smart people.
Second : Icon's preview  ! If the end-user gets a preview right in the
icon, he knows *without technical computer skills*, the icon's file is
supported, dead-brain simple way.
Know issues : We need to be able to send files through legacy files systems
as in a FAT USB-key. We also need to keep compatibility with command lines
as rm -f a/path/*.wma
We truly need to extend preview system to all formats. A competitor
anticipated in a wonderful way this intention , as cover flow effect, to
browse a list of images or movies.
To keep compatibility with FAT files systems, why not just keep the
extension and hide it at least in the graphical interface ? It also keep
compatibility with all command lines. Further more, for the terminal, why
not a system asking for meta-data, instead of extension. For example : rm
-f a/path/*#wma where # means "with 'following' as meta-data. Another
smart guy evoked the idea, and indeed, it sounds great in my unskilled ear
: cp a/path/~*#sound,jazz path/to/backup and all the jazz music of the
folder is saved, not the jazz images, not..., only what he desired.
Dirty extension are even less necessary.
Yet, some issues remains : if a addressee can't read a file, the sender has
to know the file format. That's why we would likely still bother the
end-users with formats when creating a files, or when an error occurred,
But only formats names are required, not extensions, first gain. Then,
instead of just prompting an error, we could first ask him to install format
support : reducing the actually problematic formats number.
We could extend the user experience in a very consistent way : same
management of restricted files/folders, of remote/unmounted folders, for
files' protocol instead of just format, as a bittorent file, ...
It likely would be better for the preview to be built by the file default
application/engine, in order to ensure opening the file opening is actually
going to work.
The system is also scalable : if the (standardized) meta-data is the icon
key to build the preview, let's imagine, for example, one kind of
spectrogram-based sound preview for alternative music, another for jazz
music, another for rock music, and so on, as we wish, according to the
We should care about preview explicitness : the preview of an editable ODT
should differ from an (almost) only printable PDF, by instance.
*by the way, notice the file double-extension, very user-friendly
 http://www.apple.com/macosx/leopard/features/finder.html &
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the xdg