Re: Nautilus design choices redux

[textshell neutronstar dyndns org]

On Mon, Jul 08, 2002 at 04:19:01PM -0500, Gregory Merchan wrote:
Ok let's see if i can get productive

> Here again are the questions:
> 
> Inline vs. External Views
> -------------------------
> These two questions pertain to views of data which do not naturally fit a
> labelled icon presentation - for example an PDF view. The content of a
> tarball naturally fits a labelled icon presentation because it is just files
> and folders, so such a view is excluded from the views in question.
> 
> What are the advantages of inline views over external views?
> 
 - No new Windows that can clutter the desktop.
 - Easier for looking through a lot of files, because you don't need to reajust
   your eyes to new windows (but only if it's fast...). It's a bit like midnight
   comanders F3 view option fast and neat for browsing lots of files.


> What are the advantages of external views over inline views?
 - you don't 'loose' the directory view, so it's easier to open more than one
   file from a directory at once.
 - The user gets to know what application does the work. This way the system
   might be a bit more transparent for users not into bonobo thinking.
   (Applications will behave a bit different anyway, it might be easier if the
   user sees different applications)
 - much easier UI, no menu merging and other intransparent stuff no confusion
   about what e.g. edit/preferences does(preference merging? Uah).

Choose one side:
 - With full editing this in the long term implies that we move away from
   applications as self managed parts of the system to bonobo controls to edit a
   file that just go into an universal container. 


Wrap up:
I personally like external views more, but this is certainly influenced by me
being used to it. I often open more than one file from a directory this is not
easy in the internal views model (in konquerer which uses the model i mostly
open stuff with the middle mouse button that is in an external view, but i use
mbutton in galeon almost all the time too). But for people that get confused
with many windows on screen and shallow directory hierachies the internal views
might be more confortable.

> 
> 
> Browser-style vs. Spatial Navigation
> ------------------------------------

Sorry i'm not sure what this means exactly. I assume browser-style is reusing
the same window and replaceing the view of the previous directory with a view of
the new one. Spatial (i assume) is displaying the new directoy in a new window
and not closing the view of the previous directory. I'm not 100% sure about the
not closing thing and mark advantages the depend on that assumsation with (*).

> What are the advantages of opening subfolders in place over opening them
> in a new window?
 - same points as above i.e. (*)less windows, faster scanning and looking
 - (*)much more practical with deep directory hierachies, because you don't have to
   close the windows of directories you don't need

> 
> What are the advantages of opening subfolders in a new window over opening
> them in place?

 - The windows can be open with settings (size/position/layout) that are
   specific to the directory (e.g. autosaved or manually choosen)
 - each directory has a well known (to the user) size and layout. This could be
   helpful in fast finding things in directories with only few items.
 - (*)same points as above i.e. you can open views(windows) of sibling folder or
   parent and child folder easier. This is nice for drag and drop.
 - 

Wrap up:
(*) really depends on usage pattern and user. Supporting both might be the best
way. Let the user or usiblity guys choose a good default and have some modifiers
to override in specific cases (ctrl+click and mbutton-click).

For directories with few items it might be useful to have the view appear in the
same way every time, but this depends on usage patterns as well.


Hope this can help,

Martin H.
_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers