Re: Killing Views Part 2 - The return of the Usabilty study

[Ryan McDougall <ryan mcdougall telusplanet net>]

On Tue, 2003-06-03 at 03:05, Roberto Rosselli Del Turco wrote:
> Alexander Larsson wrote:
> > On Mon, 2003-06-02 at 13:01, Mark Finlay wrote:
> > 
> >>>There are many opinions on this. Some people like it, some don't. I
> >>>personally like viewers for filetypes that are predominantly consumed,
> >>>as opposed to created/edited. This means things like html, images, text,
> >>>pdf documents, etc. However, some people like to open an editor to read
> >>>READMEs. That should of course be possible for the user to configure,
> >>>and it is (although the UI for this sucks ass).
> >>
> >>Agreed - it would nice to be able to change between internal and
> >>external viewers with a single preference instead of LOADS of
> >>mine-types. But at the same time we should aim for a reasonable default
> >>that will not cause usability problems.
> > 
> > 
> > But a change of default behaviour will instead cause "usability
> > problems" for the people who like the current setup. The sun test shows
> 
> You can get used to lot of things eventually, which doesn't mean that 
> you should preserve the status quo indefinitely. Otherwise we'd still be 
> stuck with Windows 3.1 ...
> 
> > only that some people can be confused by the current way, not that
> > nobody will be confused or work more efficiently with another way.
> > Replies in this thread confirm that there are also people more
> > comfortable with the current design.
> 
> There sure are, but I wouldn't consider these replies as valuable as a 
> proper usability study.
> 
> >>* When you use an internal viewer your file view is replaced. This means
> >>that you have to go back to the file view to get to another file. Very
> >>unforgiving/iritating if you want to keep that file open and keep
> >>browsing files. To me this fits into the "unexpected behavior" catagory.
> >>People are much more at home with different things being shown in
> >>different apps. Would possibly be less iritating if files were opened in
> >>a new window by default.
> > 
> > 
> > The other way always pops up new windows for each item, placing them
> > semingly randomly on screen having you micro-managing their position and
> > size, etc. That could also be seen as irritating and unexpected.
> 
> Is it? IMHO even unexperienced users expect a window to pop up when they 
> click on an icon.
> 
> >>* It is not immediately obvious that files are read only and that to
> >>edit them they need to be opened in an editor. Especailly the case with
> >>text files. I see very little benefit to using the text view instead of
> >>gedit. As for images and pdf, I think a universal previewer is better...
> > 
> > 
> > I don't see how you can be for a universal previewer when Nautilus is
> > designed to be that and you want to remove it. It would have all the
> > issues you bring up in yor mail. I do also think we can design the text
> > view so that its more obvious that it is a view. 
> 
> The problem with Nautilus as an universal previewer is that internal 
> views interfere with Nautilus as a file manager, I fully subscribe to 
> what Mark is stating in the following paragraphs:
> 
> >>" "Every application should do one thing and do it well" - we already
> >>have file viewers for a lot of different file types. Would it not be a
> >>lot better to have the "universal preview" app that functions really
> >>well as a file previewer and and a file manager that functions really
> >>well as a file manager? I think that there are a lot of features that we
> >>could have in a universal viewer app that we will never have in
> >>nautilus. UI that is specific to it's task makes a lot more sense to me.
> >>
> >>* To do internal viewers properly you need to change the menus and
> >>toolbar of nautilus for each viewer. UI changing within the same window
> >>is really confusing to the user and makes it really hard learn to use
> >>the app. 2 sepporate apps with 2 unique uis is a lot easier to learn
> >>than a single ui with a ui that changes.
> > 
> > 
> > Normally not that much changes when viewing the types of file I'm
> > talking about, so most of the UI is shared. But sure, we shouldn't be
> > totally rearranging everything.
> > 
> > Actually we should probably try to make application UIs similar anyway,
> > to make them easier to learn, so the apps would have unique but similar
> > UIs already.
> 
> The problem is not simply related to UI consistency, but is mainly the 
> fact that when you preview a file in the same window where you were 
> shown its content, icons pointing to files and directories, you break 
> the desktop metaphor, forcing the user to switch from file 
> browsing/management to file (pre)viewing and vice versa.
> 
> Add to it the facts that a) you have the UI consistency problems 
> mentioned above; b) you can have one (or more, according to file types) 
> file previewers doing file viewing in a much more confortable way than 
> current implementation allows; c) you can continue file management 
> activities while (pre)viewing files; and you will see why many people 
> would like to have such a previewer opening files in a different window.
> 
> Ciao
> 

Excuse me for jumping in the middle of this thread ( and possibly
missing some previous comments ), since I just joined, but I have been
thinking about this very problem recently.

It seems to me that we have uncovered an inherent duality in the Browser
metaphor, where sometime we/users want to preview a file, and times when
we want to Launch the MIME application associated with the file. I think
both options should be possible, because the overriding question should
always be about whether this behavior actually improves my life, and its
clear that both behaviors are helpful under different circumstances.

Aside: I think file management as we know it will be dead in a few
years, in the same way that bookmark management is a dying hobby thanks
to google and browse histories ( a la Epiphany ). Sure people will
always need to create new directories and copy files, but nothing that
needs the power of Nautilus.

The question of how to correctly and neatly accomodate both styles: 

My preference is to have a behavior where left clicking on the file
launches the associated MIME app, if there is only one associate app, or
launches a context sensitive menu ask what the use would like to DO with
the file. In the case of an image file, it might ask a more sophisticaed
version of "Would you like to See Slideshow (gqview), Edit (gimp), ...".

When the user only wants a preview:

1. I will take mouse-over on mp3 files as an example of current behavior
extended to other data types. I think mouse-over should cause Nautilus
to "Zoom in" on the data file. If the user leaves his focus on the file
for some time, it may be appropriate to assume shes interested in that
data, and wants to quickly know more about it -- so we should
unobtrusivly offer a preview. For sound files, the Zooming behavior is
to offer a sample of the sound for as long as the mouse is over the
file, when the mouse leaves, the sample stops. The same behavior can be
extended to images and movies. Nautilus already unobtrusivly generates
thumbnail size "Zoom-ins" for pictures-as-icons, but lets say thats not
enough for me, I want to know more. Mouseover should open a new window
containing a larger ( but not full size ) version of the image, only so
long as I am "moused-over". To avoid confusing the user, the windows
that opens should clearly point out graphically that the Zoom-in
corresponds to the file there mouse was over. Also to avoid a jarring
experience where the user sees something quicly flashed before their
eyes but have no idea where it came from, there should be a time delay
on the Zoom-in of a couple seconds. Once again, the preview should be
unobtrusive to the file browsing, so the user should never need to close
down the preview manually. For text files, this elimnate the desire to
edit the text, since once the mouse leaves the file to go edit the text,
the window will close the preview back down.

2. A context sensitive right menu could offer to generate a preview in
view-pane. I dont think that stealing the view-pane for playing movies,
or displaying images interferes with the UI consistency of the manager.
However, when viewing Text, I think the text should be editable if they
have write permissions, this is the expected behavior, so it should be
allowed. One thing Id like to stress, is that the views shouldnt add
complexity to Nautilus itself, Nautilus should always use external
components to view the data, like Konqueror ( which is a *technically*
very nice program ). Excuse me if this is always the case, Im not a
Nautilus dev.

In closing, I dont think that Nautilus should be a "universal previewer"
or "plain file manager" only, but we should clearly be asking ourselves
how we can create a program that will improve somebody's quality of
life. IMO Nautilus is a "GUI Shell using File Browser Metaphor", and
should offer a feature set that includes bother previewing, and regular
file management --  the question is not if, but how. Like a web browser
is a window into the Web, a file browser is a window on a world made of
files ( Unix ). People are biologically able to see that worldaround us
at different depths and clarities, and I think this is a very consistent
metaphor to integrate previewing and launching together.

Please let me know what this distinguished group thinks of my ramblings!

Cheers,
Ryan