[Usability]File Types Design

[Seth Nickell <snickell stanford edu>]

On Sat, 2003-02-15 at 14:29, Havoc Pennington wrote:
> On Sat, Feb 15, 2003 at 01:59:50PM -0800, Seth Nickell wrote: 
> > 1) Long term, the preferred applications system needs to either
> > complement or replace the file types system. Having both is
> > confusing.
> 
> Since we have too many things in Preferences menu again, merging these
> would be nice.

File types won't be in the Preferences menu at all... This was going to
be my next "public design", but I'll throw it out today anyway since the
two relate to each other.

http://www.gnome.org/~seth/open-with-tab-mockup.png

Here are some of the thoughts I used to guide this design:

1) Conceptually, changing "what opens this file" is a very simple and
fairly obvious operation. The interface should be just as simple.

2) The size of the list in a central database makes finding the file
type you are interested in changing the most difficult part of the
operation. This is the reason that we've rewritten the silly thing to be
"easier" a few times and it hasn't really been any easier after each
iteration (in fact, the current one is arguably the worst). The problem
needed interaction design not interface design.

3) Studying when/how people want to change "file type associations" I
have noticed that people almost always have a specific instance of the
"file type" in question when they want to change the association.
Typically they double click the file, find it doesn't open in the
program they want, and go to change the association. This is the central
use case

Here are some trade-offs the design makes:

1) A secondary use case that is much less frequent, is some people will
change several common file types when dropped onto a new computer. The
new interface is worse for this, which is bad, but its important to
remember to *optimize interfaces for the central use case*. Its still
not terribly onerous to go find instances the several file types people
want to pre-setup and change them (especially since these are always
types that the person has a lot of instances of).

2) The idea of being "in the Open With menu" is not made explicit. This
reduces some of the interface complexity, but may also fail to provide
the user with sufficient motivation to understand why they would want to
"Add Application" when they don't want it to be the default. I'm
planning to do some testing on this issue and find out if its a problem.
Still, I would rather optimize the interface for being so easy to change
the primary association that people ACTUALLY USE IT (most people stay
the hell away from file type associations with existing interfaces).

3) Its buried in the right click menu of objects. It would be good to
find a clean way to expose it in Nautilus' file menu. It might be worth
rethinking how the "Other Application..." stuff works (a not at all
obvious way to get at changing what's in the menu, what's not, what's
default, I might add)... and adding an entry for "Change what this thing
opens with".

-Seth