Re: Some Ideas about Previewing and Multiple Media handling in Nautilus [was: Killing Views Part 2 ... ]

[Ryan McDougall <ryan mcdougall telusplanet net>]

Very nice mockup Josh, that might persuade some people, but as below I
have some concerns with your ideas in turn, as you had with mine. With
luck we can bash each others ideas against each other and come out with
a superior result. :)

What if I want a preview, then launch some apps, then preview again,
etc. I either have to constantly turn preview on and off, which I think
is *unnecessary* work, or I have to put up with the preview window
sticking around where ever it is placed. What if I like the "Preview
Behavior", and choose to have this behavior as default? If you read
below, I think my ideas can handle these possibilities, by considering
preview not to be a Tool, but instead a mode of behavior that can be
entered and left. In View Mode, as I will call it, mouse-over does the
preview thing, and in Regular Mode, mouse-over does NOT do the preview
thing!

Also I think the positioning of the View window is of critical
importance, if it gets stuck willy-nilly about the desktop it could
become a major annoyance for users. I think for usability and window
placement reasons, the window should be tethered by some graphical means
to the file in question.

I will work with some mockups to help illustrate my ideas more clearly.
Below is also my previous post, included because I think I had some
important ideas you mockup didnt address.

Thanks for your help with this idea Josh!

Cheers,
Ryan

-----Forwarded Message-----

From: Ryan McDougall <ryan mcdougall telusplanet net>
To: nautilus-list gnome org
Cc: Joshua Adam Ginsberg <joshg myrealbox com>
Subject: Some Ideas about Previewing and Multiple Media handling in Nautilus [was: Killing Views Part 2 ... ]
Date: 04 Jun 2003 12:24:17 -0600

On Tue, 2003-06-03 at 23:40, Joshua Adam Ginsberg wrote:
> Hi Ryan -
> 
> I very much like the idea of the preview on mouse over... perhaps though
> we can be a little more explicit... I propose a modified idea...
> 
> Single/double clicking will launch the default associated application...
> right clicking can bring up the context menu from which the user can
> select a different application... it would be helpful if the "Open
> with..." and its contents were renamed to be task based as you suggested
> (e.g. Open in slideshow; Edit; etc)...

The reason I said that the default behavior should be to ask the user
what they want to do with the data file, is that the default user will
benefit most from this kind of hand holding. But I can see how for an
advanced user this behavior would be very meddlesome, and annoying.
Instead of "Open With" I think the menu should read "Perform Task With"
or some such variation. The reason is that is what we want to present to
the user, they dont care about gqview vs gThumb, etc, they just want a
slideshow. In order to make sure the user knows that these tasks are
available, we might have a tool tip thats reminds users on mouse-over
that right clicking will avail to them "Perform Task With", and
"Preview", etc.

Aside: One thing I love about XP are all the unobtrusive ToolTip style
dialogue boxes. They dont steal the focus, and they automatically
disappear, so it is possible for a user to physically ignore unimportant
dialogues without becoming annoyed with them. Its like your best friend
telling you something: its casual and relaxed, you can safely listen or
ignore. Traditional dialogue boxes are like your wife speaking while
your watching TV: they constantly interrupt what you would rather be
doing, and you dont dare ignore them lest it cause you great trouble
later on. This mental difference allows the computer to converse with
you about more of what is going on with your system. "New update is
online, eh?", "The computer says it can crop that photo for me?", "The
computer thinks I should back up my documents again?", etc.

> 
> Then we add an item to the toolbar called "Preview" or something like
> that... it would turn the cursor into something like a magnifying glass
> furthermore a window would be spawned... when the user's mouse is not
> over an icon, this window prompts the user to do so... when the user
> hovers over an icon, on one part of this window, file information is
> displayed... on the other part of this window, a preview can be seen...
> so for images an image appears... for an mp3 an embedded mp3 player
> starts playing it... text files and word processing documents can be
> previewed... This window could in fact be a hack of the universal
> previewer...

The reason I thought previews should be a default behavior is because I
wanted the default user to benefit, but I can see how this would be
annoying to average user. We could have a ToolTip style dialogue on
mouse-over to let users know what they can do by right clicking. However
in my idea popping up a separate window isnt the exact behavior,
instead, when the preview mode is on, and the cursor is a magnifying
glass, mouse-over will launch a preview window specially suited for the
media type, and with a graphical clue to what file is being previewed.
The graphical clue might be some sort of arrow that attaches to the
window and points to the file, like a dialogue box in a comic book. This
kind of clue is easier to grasp because it is visual and spatial instead
of some odd file name. The window itself will be different for different
media: for mp3 it might be a small window that lists the meta-data such
as title and artist, but also has a slider bar to show how long the song
is and what part of the preview we are listening to; for an image it
might be a very large window with the image at say half its regular
size, and lists file name and size as meta-data. Note that the
mouse-over behavior guarentees that the window must be read only and,
for example, the slider cant be advanced or the image zoomed, because
the window will disappear a couple seconds after mouse is gone.

An interesting side affect, is that clicking on something will in
preview mode is totally open to new uses. Forexample, clicking on the
background should zoom in on the whole view-pane, and we can finally
make use of that old eazel feature via the mouse! Clicking on the file
while in preview mode will bring up a modified context menu that
includes "Preview This" and "Perform Tasks With".

> 
> Once the user clicks on the preview again, the window closes and the
> user returns to normal browsing... you get to kill views but nautilus
> retains its abilities to preview files as was originally intended...
> plus, you have no more user confusion about what happens when you
> single/double click on an icon...

Having not followed the debate on killing views, Im not convinced view
should be killed... I guess Ill have to read the archives when I have
time. But I am a big fan of what Plan9 did to these ideas: essentially
everything IS a file, REALLY: mouse is a file that contains button state
and x/y coordinates, the frame buffer is a file, printers, ethernet,
everything. And each device-file is managed by a file system that can be
mounted transparently on any machine. So if I have the priviledges, I
can mount a remote machines video display and write anything I want to
it. Cool stuff.

The way I would like to see Linux work, is that I shouldnt need
"smb://", I should simply "cd /mnt/smb/someshare", the file system
should automatically provide the right data to local read/write syscalls
to that file -- but alas that is beyond the scope of Nautilus I think.

> 
> Thoughts?
> 
> -jag

Very interesting thoughts Joshua, thanks!

Cheers,
Ryan

> 
> > 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

-- 
nautilus-list mailing list
nautilus-list gnome org
http://mail.gnome.org/mailman/listinfo/nautilus-list