[Usability] File type system redesign

[Seth Nickell <snickell stanford edu>]

File Type System Interface Redesign
-----------------------------------

---Interface Purpose----------------------------------------------

When designing an interface its important to first identify what the
interface needs to accomplish. What does the user want to accomplish
with this interface? Why is this information important to the system?
etc.

  The file type system has two major functions:

  1) Provides the environment with the mapping between document-type 
     space and application space, allowing documents to be opened in 
     the appropriate user-preferred application(s).

  2) Defines document-type space, providing the environment with
     an icon and textual description appropriate to the type.


---Past Art-----------------------------------------------------

Its important to consider past art in order to get a head start on
problems you may encounter (and may not be able to predict a priori),
and garner ideas on how to structure the interface. Its also very
important to consider where past art has failed in order to avoid
repeating their mistakes.

File type systems have traditionally been very difficult to use. This
has been hard enough to use in Windows that a recent article even
accused Microsoft of intentionally making it difficult to change
document<->program mapping. Based on a poll of 22 users familiar with
the Windows file type system and some basic use observation, the primary
problem encountered changing file types is not the complexity of the
interface modifying file types (though that doesn't help) but is
actually FINDING the correct type in the giant central list.

This problem is shared between the existing file type capplet, the
Windows file type system, and to a lesser extent the KDE file type
system. The KDE system may have identified this problem and tried to
alleviate it by turning the list into a tree. Trees can make it easier
for users to handle large numbers of entries. Unfortunately the tree is
based on an archane technical detail, the initial part of the mime type
(application/ , text/, image/, video/, etc). While this may be helpful
for image and video in some instances, users cannot be expected to know
what falls under application/, what falls under text/ etc. For example
to change the mapping for MathML files, users would have to know to
navigate to text/mathml (or something like that). This is incredibly
non-intuitive and requires a priori knowledge most users do not possess.

Additionally, a huge percentage of entries fall under application/, a
very nebulous category including things that have not been approved for
inclusion into standards controlled areas such as image/ and video/. Why
should users have to know or care whether their media type has been made
a standard when navigating a file type capplet? Thus I would judge the
KDE menu's organization to aid certain advanced users (myself included)
who are familiar with MIME types, and to have a significantly negative
effect on the majority of users who will now have to browse a number of
branches to find their type (additionally, listings in the tree are done
using mime type, no human readable form). Aiding somewhat is the "file
pattern" search feature, but I don't think most users will know what a
file pattern is. I eventually figured out that for most files this is
the extension, but not before I tried unsuccessfully to search for
things like "Microsoft Word". If we provide a search feature it should
also operate on the human readable forms and should allow for imprecise
matches.

The only exception to the basic file type system is the Macintosh. MacOS
has a very firmly ingrained idea of the creator application and
applications which are allowed to open a particular document. Changing
this association is not provided as a basic feature of the environment
and requires hacking at resource forks. This is very inflexible and the
cause of much grief at times, but has a huge advantage: the Macintosh
entirely dodges the centralised MIME type system.

---Usage Exploration------------------------------------------------

It appears that the vast majority of use cases for manipulation of
application<->document association follow this basic pattern:

1) User has a document
2) User would like the document to open in application foo
3) User realizes that they'd usually like this to happen
4) User decides to change the association

This suggests that the interface for manipulating document<->application
association should be localized to a particular file type (based on the
file in question).

In general, I think a similar pattern holds for wanting to change the
icon for a file type, or perhaps its description (I think changing the
description is probably a more unusual operation, but there are no real
problems to providing the option), or perhaps add an extension to the
list of extensions for a particular type.

In almost all cases the user has a document in front of them OF THE TYPE
IN QUESTION. We should use this extra information to completely
eliminate the giant hard to navigate list, nixing the worst usability
problem in changing properties for a file type.

Nautilus goes part of the way here, making it possible to jump to a
specific entry in the mime database given an application, but you have
to know to navigate to "Open with Other Application", then "Go to
Control Center". Also, the list is still displayed which adds a great
deal of unneeded complexity to the display and the interface.

Exploring real life instances, it is very rare that users want to change
a bunch of types en masse, and even rarer that they do not have
documents of this type. Hackers are often very reluctant to remove a
"potential feature" but in this case the usability gains from removing
the centralized list far outweigh the potential feature of being able to
change a bunch of file types you don't have documents for. In terms of
changing many document types at once, I would contend that it is
actually easier in many cases to navigate your own documents tree and
find documents like that and change their type then to navigate a huge
list of potential types (the vast majority of which any given user will
not see, since each user has a very different set of document types they
actually interact with, but the list lists all possible types). 

An example of why this is easier: I don't know exactly what the
"Microsoft Word" description will be called. Will it be "Microsoft Word
Document", "Word Document", etc. Searching a giant alphebetized list is
a pain. Searching would improve things some... But I know exactly where
I have a Microsoft Word document on disk I could navigate straight to
and change association. If I'm changing 10 file types or 1 I still
believe its usually faster to find a file of a particular type on my
system and change the association. If a user does not have a file of a
certain type, they probably aren't concerned with its association.

---Design Proposal------------------------------------------------

Provide access to all functionality in a completely localized manner, in
the Nautilus file properties dialogue.

In order to simplify the interface, split the two major functional areas
from each other. Users should not have to understand that they affect
the same database. It is important to understand the difference between
the engineering model and the user's conceptual model. Just because we
understand that they affect a similar range of properties does not mean
that the user will understand this technical connection.

The user's conceptual model (except insomuch as it has been forcibly
shaped by Microsoft Windows) probably does not consider
application<->document mapping and document<->icon mapping to be a
similar category of problem. Just because they both affect the same
database does not mean this distinction should be exposed in our design
model. Our design model should try to accomodate the user's most natural
internal model. The underlying architecture should continue to be a
database, but we should not impose this conceptual model on the user. To
the user this is now localized information, not information stored in
some central database.

Thus, we create a seperate "Actions" tab and "Type" tab (I'm not happy
with the name of the type tab, but I haven't had enough time to think of
a good name for it).

Actions tab mockup:
   http://beauty.stanford.edu/actions-tab-mockup.png

Clicking on add application should provide a list of applications which
say they can handle this type (but aren't in the preferred list, e.g.
the list that shows up in the Nautilus open with menu). Pressed further,
the system will allow the user to create a new application entry, or to
simply navigate for a binary to execute the file with. I have yet to do
a detailed prototype of this interface, but it will not have to be a
very complicated interface.

I haven't finished glade-ing my mockup for the types tab, but basically
it contains the description in a combo box (called the type name, the
user shouldn't have to know that the database is really keyed by the
mime type, to them the human readable type name is the important type),
a click-to-change style icon, and a list of extensions with add and
remove buttons below them. A progressive disclosure button will display
more advanced options like editing the MIME type.

This brings up an interesting case, which is when the user wants to
change the properties of a type that does not exist. I see two
reasonable solutions to this problem.

The first is to implicitly create new types when they edit the
properties. If the type does not exist in the database, all entries are
blank except for the "Extensions" list, which should contain our best
guess for the extension of the file in question (this is not difficult
to do in the general case). To complete the type, the user just has to
type a type name. The mime type will be automatically created from this
information. Its a bullshit mime type, but its as good as the user would
do if they were forced to provide this information. Users who know what
they are doing will be able to change the MIME type, and users who do
not know what they are doing would do a worse job inventing a MIME type
then the auto-mime-type maker will do (insomuch as the auto-maker will
at least put things in application/x- format, which users probably
wouldn't).

The automatically constructed bullshit mime type will be created from
the textual description. For example "Microsoft Word Document" would
turn into application/x-microsoft-word-document (of course, this
wouldn't happen for this particular case because we already hav ethe
correct type information for MS Word docs entered into the GnomeVFS
database, but imagine for some new type not yet in the database).

Another alternative to implicitly creating the type is to launch the
user through a simple druid creating a new type. So when they navigate
to the type tab for a file who has unknown type, it would have a button
and a label saying something like "The type of this file is unknown,
would you like to create a new file type entry for this file or
associate it with an existing type?". Then the druid would try to figure
out if there's an existing type but the extension was unknown, or if a
new type needs to be created and ask the appropriate questions.

For an unknown file type, the controls in the actions tab should be
greyed out and an explanatory label should be provided telling them the
file type is unknown and to create a new type by clicking <here> first.

This interface basically combines the simplicitly of the Macintosh
interface (not having to worry about a big global database) with the
flexibility of the KDE/existing-GNOME/Windows solution. The user is not
exposed to the database concept (see "The Inmates are Running the
Asylum" by Alan Cooper for examples of how this sort of engineering
detail ends up controlling the interface (which is BAD)). File type
settings are now provided at the point and place where the user actually
wants to manage them.