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



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

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

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

Thoughts?

-jag

> 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
-- 
---------------------------------------------------------
Joshua Adam Ginsberg           Cellphone: 970.749.8530
Rice University '02            Email: joshg myrealbox com
St. Mark's School of Texas '98
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
"All your code are belong to us." -The SCO Group
---------------------------------------------------------

Attachment: signature.asc
Description: This is a digitally signed message part



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