The future direction of the Nautilus UI

Some patches and recent discussion on this list have been in favor of
having nautilus use an "Object Oriented methaphor". I feel that we
can't really discuss the patches as such without considering the full
future direction of the Nautilus user experience. 

First the definitions of the competing metaphors. Note that what I
talk about below is the user experience, not the code, so object
oriented here have nothing to do with object oriented programming.


* Object Oriented Methaphor

 Object Oriented UIs is a subject in itself (which I know little
 about), but in the context of a file manager it has a specific
 meaning. In this methaphor every directory on the disk is considered
 an "object", and the representation of that object is a file manager
 window. To the user the window and the directory are the same, or at
 most different aspects of the same thing. Each directory object has a
 separate window, and all the properties of the window (size,
 position, type of view,  etc) are properties of the directory
 object. In this model, the idea of the file manager as an application
 is strongly suppressed.  

* Navigation Methaphor

 In the navigation model things are different. The file manager is
 more of an application, a shell that can contain views of different
 locations of the filesystem. Navigation between directories is done
 by changing the "current location" shown in the shell. Each instance
 of the file manager shell is unique, and the properties of the	
 windows are separate from the location they are showing. Several
 windows can even show the same location, using the same or different
 types of views. In this model the concept of directory is not
 directly represented as a graphical element in the ui, but it's
 rather an abstract term for a location.

People have argued (and I'm inclined to agree) that the object
oriented methaphor (hereafter called oo), is easier to understand for
new users. The argument is that the direct graphical representation
and manipulation makes it easier for people to understand the concept of
directories. Or even that you don't even need to understand the
concepts of the filesystem. See e.g. the discussion about the (known
by very few) path separator in MacOS. 


Nautilus as it currently stands is clearly implementing the navigation
methaphor. At the core this means that two windows can view the same
location. We do however have some preferences that allow you to change
the behaviour of Nautilus to somewhat better match the way you work in
an oo model. These preferences include open files in new window and
disable location bar/side bar.


If we're considering changing Nautilus to a pure oo model quite a few
changes are required. Here are some of them: 

Navigation inside a window isn't allowed. This means that back and
forward in the toolbar must be removed. The other toolbar navigation
items home and up both need to open new windows (unless the
directories they represent are already open, then they just move them
to top). The location bar also has to be removed, and the zoom and
view-picker moved to the toolbar. Any trace of "open in same window"
need to go.

Both history and bookmarks are typical navigation concepts, so they
need to be removed.

The tree and history sidebars doesn't fit the model, so they have to
be removed. 

The sidebar as such can stay, but it should probaby default to being
hidden in order to miminize the size of normal windows. (Since you
need a lot of windows in the oo model.)

The status bar makes the window feel a bit like an application, so it
should probably at least be disabled by default.

Some other concepts that may be difficult to have are home-as-desktop
and treeview-in-window. Home as desktop breaks the user model unless
you make it impossible to open the homedir in a normal filemanager
window. While it is possible to navigate to ~/.gnome-desktop this
doesn't break the user model as badly as for the home dir, as the home
dir is a very common place to manage files in. Having a tree in a
window also breaks the users model, since you can see the contents of
other windows in a window, and even see the same directory in
different windows.

Another victim in the object oriented world is embedding viewers for
files in the nautilus window. Different directory views such as listview
and iconview make sense, but since opening a file have to open a new
window it makes much more sense to open the actual application
editing or viewing that type of file. You don't want to click on
e.g. a postscript file and get a postscript view in a worthless
filemanager frame that can't do anything else than go "up" to pop up
the previous window. You would much rather have a postscript viewer

Now, these are mostly features from the current nautilus ui that
doesn't fit in the oo model. In order to have a reasonable experience
in an oo nautilus you probably need to add some new features to make
up for these. One example is springloaded folder, but no doubt there
are other important ones that will be discovered in time.


Getting a user model that is easier to understand is a pretty big step
forward, but there are also various uncertainties and drawbacks:

* A lot of the current code is targeted towards navigation. We would
  have to throw away lots of code, rewrite some and write a fair
  amount of new code.
* The current code is way to heavy for an oo model. Opening windows is
  far to slow. This is partly I think due to the fact that the code is
  written with navigation in mind, and in navigation a window is a
  more persistent object that you can spend more time on constructing.

* I'm not entierly sure the object oriented model works well with
  remote filesystems. These are less structured than local ones and
  that may be confusing. There is also the question of how you browse
  to e.g. a ftp site.

* Keyboard navigation of the filesystem may be painful. The current
  alt-up/down/left/back is pretty efficient. In the oo model you
  always get new windows, which is slow and have a high risk of
  messing up keyboard navigation due to focus issues.

* This is a large change, and it will irritate and confuse some of our
  current users.

* While the oo model somewhat hides the unix filesystem model users
  are gonna be exposed to it anyway (in other apps, fileselectors,
  etc). This means there will always be two different models of the
  filesystem. It is possible that we can limit the exposure to the
  unix filesystem model more in the future, but I don't think we can
  fully hide it.

* I have concerns that the oo model is not as efficient to use as the
  navigation model. Especially traversing deep hierarchies can be painful.

* There seems to be a lot of work that needs to be done to go to an oo
  model. Time we could instead spend on making nautilus faster and
  have more features.

I'm really not sure what is the right path here. But I don't think
that we should apply any patches concerning this until we have decided
fully where we want to go. I also think that if we decide to keep the
navigation model we should not be changing the defaults to be oo-like. I
think that would be doing our users a disservice.

 Alexander Larsson                                            Red Hat, Inc 
                   alexl redhat com    alla lysator liu se 
He's a fast talking pirate paranormal investigator in a wheelchair. She's a 
scantily clad winged advertising executive married to the Mob. They fight 

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