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

[Paul Gear <gear gargoyle apana org au>]

"James M. Cape" wrote:
> 
> "Jesse D. Sightler" wrote:
> >
> > >You open a copy of the Open Dialog to print something. That is behavior
> > >you learned from Win9x, and because you've gotten into a bad habit of
> > >doing it, would like to be able to do in Gnome as well.
> >
> > 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.
> 
> So put an "Open This Folder in Gmc" button on the dialog. Simple,
> effective, and prevents us having to hack at the GUI because *you*
> started doing something in Windows that is 100% contrary to the way
> things *should* work. If Windows didn't do something dumb with the
> dialog, then it never would've crossed your mind to use the Open Dialog
> to print something -- This is because it's not intuitive to use the Open
> Dialog to print something.
> 
> This goes back to my original Rant. "In Windows 95, I can do this one
> kewl thing (which violates quite a few basic UI principles and should
> never have been included in the first place). In Gnome/X/whatever, I
> can't do that, so Gnome/X/whatever should change."
>
> Printing from an Open Dialog is exactly the kind of thing I was talking
> about here.

As a newcomer to this forum, i haven't seen everything that's gone
before, so please take this post for what it is meant: a counterpoint,
not a flame.

I've been following this thread for a while now, and i think there is a
question that needs to be asked here: what do (normal, dumb) end users
expect to find in file open/save dialogs?

I think you can guess my answer to this: end users expect to find basic
file management in their open/save dialogs.  If they want to browse
directory trees easily and quickly, or move lots of files around, they
know that the file manager is the right place to do it, but they expect
to see _basic_ things (like delete, print, copy, and move) everywhere
they see file icons.

Now, we all know that Windoze 95 is the cause of this expectation, and
that it is not necessarily a valid or correct expectation, but that
doesn't change the fact that the expectation is there.

This really relates to the purpose of the GNOME project: is it meant
primarily to make Unix accessible for end users, or is it meant to make
our lives as developers and administrators easier?  I know both are in
mind, but i think what everyone is hoping is that projects like GNOME
and KDE will make Unix usable by the masses.

> > >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.
> 
> Because it shouldn't be there! Open != Printing! Opening an Open Dialog
> to print a file is not the correct way to do it, because it promotes a
> bad habit (like putting spaces in created directories). Best to leave it
> out, so new users don't pick it up.

It's too late - they've already picked it up.  How many end users do you
know who learned computers by using Linux?  I know of none.  They all
started with Microsoft or Mac and picked up Linux when they wanted
something cheaper, faster, and more flexible.

I also think that we are talking about two different requirements here. 
One is "how can i print a file?", and the other is "what can i do in the
open dialog?".  In the first case, i think everyone agrees that the
right way to enable people to print a file is to let them open/print it
from the file manager.

In the latter case, it is not that someone thinks, "I need to print a
file - i'll go to the 'open' dialog."  It is that they are opening a
file, see another one, and think, "I need a printout of that file to
refer to while i'm working on this one."  So they pull up the file
context menu, print the file, then return to opening the other file.

What i am saying here is that we need to consider the possibility that
it is not necessarily counter-intuitive to put open and print in the
same dialog box.  If it conforms more closely to the way people work,
then it is not counter-intuitive.

I know when i am looking at my files, i often see another file that
needs to be copied, moved, or deleted, and before i know it, i moved two
files, deleted another, and renamed another.  This is the way my
(admittedly twisted) mind works: it goes to several levels of recursion
before returning to the task at hand.  I don't consider this
counter-intuitive - YMMV.  ;-)

> > >Copy and Move are grey areas, and I personally wouldn't object to them
> > >because they can be useful.
> > >
> > >Delete and Rename need to be there, IMO.
> >
> > Agreed, on both counts.  :)
> 
> Consider these superceeded by the "Open Directory in Gmc" button.
> ...
> Well, you shouldn't be using an Open dialog to manage files, because
> that's what the File Manager is for! Making the Cancel dialog cancel
> everything keeps people from using it as a mini-Gmc, which they
> shouldn't be doing in the first place.
> 
> The Open Dialog should open files. Period.
> 
> The File Manager should manage the files. Period.
> 
> Crossover is not a good thing.

Perhaps it would be worth considering tighter integration between GMC
and other applications.  I can envisage a scenario GMC could provide
some functions to do file open/save dialogs via the ORB.  Then the
application could worry about what was actually selected/typed to
open/save, and the GMC dialog could provide file management functions
without the application having to support them.

(BTW, under this scenario, i would think it best that the cancel button
would only cancel the open/save, not all the file operations - they
would be handled by a multi-level undo in the file manager.)


I think that there is an expectation in the user community that the line
between open dialogs and file managers should be becoming finer and
fainter.  People want to see little icons everywhere, and be able to do
(mostly) the same thing to those little icons everywhere.

This expectation is not at odds with modern principles of software
design.  In fact, it fits very closely with the OO paradigm: objects are
encapsulations of predefined data and methods, and we can plug these
objects together in any way, as long as we conform to their interface
definition.


In conclusion, i have another question: are we going to give users what
they want, or are we going to make them work the way we want them to
work?  I know what my answer is.

PDG
---------
John 3:30 - "He must become greater; i must become less."
Home page: <http://gear.apana.org.au/~paulgear>