Open file dialogs (was Re: UI Rantings)

[Matthew Berg <wdomburg pce net>]

Jesse D. Sightler wrote:
> 
> Matthew Berg wrote:
> > Am I missing something here?  Seems like that shortcut has at least as
> > many steps, sometimes more than what you're complaining about.
> >
> > <click on file manager> -> <browse> -> <click on print>
> >
> > <hit open accelerator> -> <browse> -> <click on print>
> >
> > <click on file menu> -> <choose open> -> <browse> -> <click on print>
> >
> > Not to mention that shortcuts should not be thrown in where they don't
> > make any sense.  It's like having a combination ginzu knife/marital aid;
> > sure, it may be convienent, but it's messy.
> 
> No, it is fewer steps my way.  :)  Your way would actually require
> clicking the wharf/start menu to open file manager, then clicking
> several folders to browse to the file that I want, then right clicking
> the file to print.

But you would have to browse to the file you want anyways.  
 
> Next you will question, but why would you browse in file manager,
> shouldn't you have to do that anyway?  Well, that is exactly the heart
> of  one of the two primary reasons why I believe that file open dialogs
> should give the option to print.  :)
>
> The File open dialogs in Word includes a preview pane for viewing
> documents that you may wish to open.  Unfortunately, it will always be
> too small and clumsy to really examine the contents of a document.
> Frequently, I wish to have a more extensive preview of documents that
> may be related to my current work than the pane allows.  Being able to
> print from here makes this task somewhat easier.

Hrmmm, I've never examined a document by printing it; I open them and
then decide if I want to print it.  But 'tis not my place to suggest to
others how they do their work.

Though this does bring up an interesting point.  There are often times
when I set out on the momentus task of cleaning my home directory, and a
preview plane would come in highly useful. 

Adding file management functionality to the open dialog, I suppose, is
one way around this; though still a inelegant solution in my opinion.

Another approach that I think would be a fairly clean solution is to
allow a preview mode for GMC.

One of the things that has always attracted me to know is the idea of
"application objects" implemented in CORBA.  I know that the framework
is there, but how much this is used in applications is beyond my
knowledge.  
 
> Second reason (and this is by FAR my strongest), I am a holdover from
> the days of the Workplace Shell, and while it did have it's flaws, one
> thing that it got right was the concept of an object oriented desktop.
> Under that system, every file should be thought of as an object, and
> should have the properties of an object.  Within the file manager, this
> meant that one could right-click on a file and access many useful
> features such as opening with any of the associated applications (and
> OS/2 did support multiple association, BTW), or printing, or any other
> file related function.  Of course, all of this was in the file manager.

I can see your point on this.  I didn't 100% understand that you wanted
this capability implemented as a context menu; I envisioned controls on
the dialog itself, more like windows.

Though I would still argue that there needs to be a balance between the
context of the object and the context of the action.

> But wait, under today's file dialogs, Files are represented in virtually
> the same way.  Indeed, they have all of the same attributes when viewed
> from an open dialog as they do when viewed from the file manager.  So my
> question is, why exactly should a File Object exhibit different
> behaviours under these circumstances than under the FM?

Because in the context of that situation certain operations are
logically consistant. 

Say you have a Girlfriend Object - in the context of the bedroom, you
may invoke the arousal method; but in the context of her parents living
room, that would be inappropriate.  

(Note - above example was not meant to be a misogynist attack on women
or belittling their personhood. :)

> > Right-clicking for a context menu is a consistent action, which brings
> > up options that are actually /in context/.  Printing with an open file
> > dialog does not fall into this category.
> 
> Ok, then our disagreement is in one area alone.  The context.  :)  Your
> belief is that right clicking from within an open file dialog is always
> a case of right-clicking within the context of a file open dialog.  My
> belief is that right clicking a file should ALWAYS be right-clicking a
> file, regardless of what else is going on.  With extremely few
> exceptions, files have exactly the same attributes when viewed under a
> file open dialog as anywhere else, and right clicking the file should
> bring up a list of file related things (print, rename, delete, etc).  It
> should NEVER bring up open dialog related things, because you right
> clicked on a file, not the dialog.

*nods* It does seem to be an essential difference in design philosophy. 
 
> In other words, I completely agree that it would be terrible if clicking
> anything in the file dialog, files or otherwise, would bring up a list
> of options like "Copy, Print, Rename, Use Preview Pane, Display Small
> Icons, Delete, Display Details".  :)  Consistency is important, I just
> think that it should be implemented at the file level in this case,
> rather than the dialog level.

Yes, but in a file manager, that set of options may make sense.  As I
mentioned above, I think options like an optional preview would be
useful in a file manager.  

> > And the answer to this is that you shouldn't be doing any of that within
> > those dialogs.  This is an even stronger argument against making open
> > and save dialogs mini file managers, as it necessitates making the
> > cancel funciton counter-intuitive.
> 
> But I have NEVER found the cancel button counter-intuitive.  In fact, on
> occasion, after doing all of those file related things, I'll hit cancel
> just 'cause I realized that I no longer need a to open anything.  :)

But part of the reason for that is that there is no environment I can
think of where the cancel label on a button had a consistant meaning. 
Part of familarity with computers is learning that you can't expect
something to do what it says in plain english.

For people who have gotten used to this, it doesn't seem confusing.  
But consider a new time computer user who has done something by accident
in a dialog and wants to back out of that change;  wouldn't the word
"cancel" seem to imply that action?  

In many cases, I think dismiss buttons should be included on dialogs. 
And in others they should replace the Okay or Cancel buttons.

And I still argue that if you are doing such complex changes inside a
dialog that it would be either difficult or inconvient to have cancel
back out on everything, that interface should be rethought.

Matthew Berg