[Proposal] Formats and extensions : towards an end-user-friendly management

[jib]

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
way?

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 [1] according to some smart people.

Second : Icon's preview [2] ! 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 [3], 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,
reading them.

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
theme.

We should care about preview explicitness : the preview of an editable ODT
should differ from an (almost) only printable PDF, by instance.

Links :
[1]
http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html#//apple_ref/doc/uid/TP40001319-CH201-DontLinkElementID_15
[2]<http://media.arstechnica.com/articles/columns/linux/linux-20060905.media/icon_theme.jpg>
http://docs.sun.com/source/817-5309/images/naut_viewpane_text_window.tiff.gif
*by the way, notice the file double-extension, very user-friendly
indeed*<http://developer.apple.com/documentation/Carbon/Conceptual/understanding_utis/understand_utis_intro/chapter_1_section_1.html#//apple_ref/doc/uid/TP40001319-CH201-DontLinkElementID_15>
[3] http://www.apple.com/macosx/leopard/features/finder.html &
http://www.apple.com/macosx/leopard/features/quicklook.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20070620/74adfbbe/attachment.html