Re: UI Rantings [was: Re: gmc and file-selection mockups]

["Jesse D. Sightler" <jsight pair com>]

Matthew Berg wrote:
> > No, I just find it quicker than opening a file manager, browsing to the
> > file, and then right-clicking on it and clicking print.  :)  Using the open
> > dialog saves several steps.
> 
> 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.

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.

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.

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?

> 
> > >I completely,
> > >firmly, and undeniably disagree with this idea, because it is completely
> > >counter-intuitive, and new computer users (not just new Linux users)
> > >should never find anything that forms bad habits. Don't copy
> > >bad-habit-forming things from Windows just because they are there and
> > >you have made it a bad habit. Break your bad habit, don't spread it to
> > >others.
> >
> > Ok, so you think that using the context menu of a file is a bad habit for
> > printing?  Please explain to me what is bad about it.  Go into detail about
> > this, too, as I really don't see the problem here.
> 
> 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.

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.


> > >However: Cancel should undo *all* changes. Period. I don't care if
> > >Windows does it wrong, Cancel should *always* return *everything*
> > >(*including* the filesystem) to it's original state, as if the dialog
> > >had never been opened. I can't possibly stress this one single point
> > >enough.
> >
> > Remember here, though, that the problem is that what if after doing all of
> > my file-management related things I decide I didn't really want a doc opened
> > to begin with.  :)  Then I'm gonna really wish I had a "cancel only my last
> > action button".  In other words, cancel really is inconvenient in these
> > circumstances (er, cancel the print job, too?).
> 
> 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.  :)

----------------
Jesse D. Sightler
http://www3.pair.com/jsight/