Re: [Usability] File type system redesign


On Mon, 15 Oct 2001, Nils Pedersen wrote:

> > 2) A better solution would be to make the mime type system localized to
> > document (well, really document-types) by putting it in the file
> > properties tab in Nautilus like so:
> >
> >
> 3) Another complimentary (although harder to do it generically) method
> would
> be to also have mime type system 'localized' to the application. I
> really hate
> duelling browsers, media players, and the like.

Before taking a decision on this, I suggest having a good look at how
OS/2's Workplace Shell handles this type of issues.

Many of Seth's ideas come a long way in the direction of the WPS approach,
but I'll first briefly explain this approach as good as I can and let you
judge yourself. If there are more (ex-) OS/2-users on this list, please
correct me if I forgot something.

In the WPS, associations work in both ways: application -> document and
document -> application. The WPS maintains a central database of
associations that isn't visible to the user, unless the user starts
tinkering with INI editors.
Associations, in turn, are divided into two non-mutually exclusive types.
One is association based on file extension, the other is based on object
class (comparable to mime type). Both association types work transparently
in parallel.
When an application is installed, it can register itself as being capable
of opening files of class Xyz and/or files with the extension .xyz . It is
important to note that the WPS has the concept of a "default application"
for a certain file type/class. The default application for a certain file
type/class decides what a documents' icon looks like.

Now, imagine a scenario where the user browses the file system and
encounters a Xyz document which he wishes to open. Two things can happen:

1) the user double-clicks the Xyz document icon. The document is opened
with the default(*) application for this class.

2) the user right-clicks the document icon. A context menu pops up. The
top menu item is 'Open' and it has an arrow next to it indicating
a cascading submenu. The user moves the mouse cursor to 'Open', clicks,
and the submenu shows all applications that are capable of opening this
document. The default(*) application is indicated with a small diamond
drawn next to its name. The user selects the application he wants to use
to open this document.

Another scenario. The user has an Xyz document that he never wants to
edit, but only view from time to time. So it is preferable that, when this
document is opened, not the full-blown editing application is started, but
just a viewer. There is a viewer application installed on the system that
has registered itself as capable of viewing Xyz files. This is where the
document -> application association kicks in.
The user right-clicks the Xyz icon and selects 'Properties' from the
popup menu. He goes to the tab where associations can be edited. There, a
list of registered applications for this type/class is shown and also a
possibility for manually entering another application exists. The user
changes the default application *for this single document*.

This approach works very well, but there are a few caveats that should not
be repeated in GNOME:

- No easy way is provided to change the default application for all
instances of a certain file type system-wide. Third-party tools are used
to make up for this omission.

- The document -> application association settings are a bit too
well-hidden within the file properties pages. Seth's mock-up already shows
that associations in his design are easily discoverable under an Actions

- The WPS INI files were a bit vulnerable to corruption. It would be wise
to maintain older copies of the associations database and also to provide
the capability to go back to an earlier version of the associations. But
this is not only true for associations; the entire GNOME desktop could use
a WPS-like backup mechanism.

A final note: I don't like the text 'Open this file and other PNG images
with:...'. When I change file properties I change them for that file
alone! Forcing the change to be global feels too much like a windoze
straight-jacket. (sp?) A checkbox to apply this change to other files of
this type *could* be useful, though.



Reinout van Schouwen
e-mail    : reinout cs vu nl
mob/voice : +31-6-44360778 / 084-8750706

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]