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

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

>> I don't quite see your point here.  Are you saying that the gmc "files
>> panel" should be a separate component (neither a part of GMC nor the File
>> Dialog)?  That seems like a pretty low-level implementation issue to me,
so
>> I'm not sure what the exact answer is, but my guess is that you are
probably
>> correct.  :)
>
>That's exactly what I'm saying. If the File Selection Widget (aka the
>files panel) is going to be used in more that one part of Gnome, than it
>should be part of Gnome-libs, not Gmc. The reason for this is simple --
>why load Gnome-libs *and* Gmc when all you want to do is open up a file
>in Gedit?

Remember what I said about "low-level implementation isssue[s]".  I think
that it applies here.  :)  Adding a separate library to gnome-libs or adding
a "libgmc" to Gmc are identical actions from a size/efficiency standpoint.
Where exactly they should go is more a matter of programmatic convenience
than one of efficiency.

In other words, just because it is a library doesn't mean that is MUST be in
gnome-libs.  Of course, gnome-libs must not be dependent upon the existence
of gmc in order to function.

>> Then we had better not do much.  :)  Seriously, "the most inexperienced"
>> users still have trouble with adequately controlling mice and
understanding
>> that there are such things as context sensitive menus.  I know people who
>> have used Word/Wordperfect for Windows for years without ever knowing
that
>> they could print a file without first opening the application and then
>> opening the document and then clicking print.  :)  We can't build the
user
>> interface completely to the lowest common denominator no matter what we
do.
>
>Why can't we? I'm not saying don't include anything new users can't
>understand. What I'm saying is that don't confuse new users with even
>more complexity if you don't need to.

And all I am saying is that I do need file open, print, delete, rename,
copy, and move functionality from open file dialogs.  Just make sure that it
doesn't waste screen real-estate or confuse new-users.  :)

>> And besides, right-double-clicking was not intended to replace any other
>> action, only add a convenient new way to do things.  Double left-clicking
is
>> already nothing more than a quick way to access the "Open" item on the
>> context sensitive menu, so why not allow double right clicking to "Print"
>> for example?
>
>Why throw more uncertainty into the mix. Users (*all* users, BTW) are
>used to the simple terminology of "click, middle click, right-click and
>double-click". Adding more to the mix is counterproductive.

Ah, so your argument is based on the terminology issue of double
right-clicking.  Probably a good point.  Actually, the more I think about
that idea, the less I really like it.

>> Er, ok, Carpel tunnel issues could be a problem.  It could also be a
problem
>> for users who aren't knowledgeable enough to know the difference between
>> right and left clicking.
>
>Which covers virtually every new user. Even Shaq couldn't browse the web
>because he didn't know to double-click. Why should he have to worry
>about Double Right Click too?


Well, to be fair, he wouldn't.  Context sensitive menus are never
"necessary" in a good UI design, and double-right clicking should certainly
never be required for anything.  You point about not using
double-right-click is a valid one, however.

L8r,

Jess