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

[Matthew Berg <wdomburg pce net>]

Jesse D. Sightler wrote:
> 
> Matthew Berg wrote:
> 
> > But you would have to browse to the file you want anyways.
> 
> But opening from the word processor almost always places me very close
> to the file that I wish to view, anyway.  After all, we do organize our
> documents to be all in basically one place, right?  :)

Usually I have my documents organized in a subdirectory directly under
~/, making them easy to get to from both file manager and dialogs.  

> > 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.
> 
> Er, since when did Microsoft apps have these things as controls on the
> dialog?  About the only apps that I have seen with "features" like copy
> file buttons under windows are Wordperfect types of apps.  Speaking of
> Wordperfect dialogs, Wordperfect 8 seems to be a perfect example of how
> NOT to make a dialog intuitive.  :)

As it has been some time since I have seriously used Windows (the
exception being work, where out mainframe access is standardized on
Rumba and mail on Outlook --ICK!--) I cannot remember any specific
examples.  Though I have seen them in several applications.
 
> But seriously, the Word dialogs offer folder creation, some dialog view
> related options, a show desktop button, and the (IMO, somewhat
> obnoxious) drop down folder list.  Actually, fewer file options than
> even the recent GTK+ dialogs as they offer delete as well.  :)

Folder creation IMHO does not belong in the open file dialog, though I
do agree it definitely belongs in the save dialog.  

The drop down folder list is a direct result of the abnoxious drive
letter scheme used by windows.  As such I can sort of see the need for
such a kludge.

Yes, the file dialog in GTK has the ability to show more options, but
these can be turned off on an open dialog, leaving you with OKAY and
CANCEL as the only buttons.

And don't forget, I have never said that all was right with the GTK file
dialogs. 
 
> > Though I would still argue that there needs to be a balance between the
> > context of the object and the context of the action.
> 
> Agreed.  And it is true that even Windows usually tries to do this.  For
> example the default option changes, as well as the associated
> application, and a few other things can change as well depending on the
> app.  Unfortunately, poorly written apps tend to end up with weird
> behaviour here. :)

*Nods*  Unfortunately, no matter how good an environment is, it can
never prevent application programmers from making bad design decisions.
 
> > Because in the context of that situation certain operations are
> > logically consistant.
> 
> Unfortunately, I think that most users will be annoyed if they are
> confronted with an icon view but no context menus.

*nods* I am sure that some people would be.  Hence the discussion lately
that these things should be swappable, be it through CORBA or the glib
plugin mechanism.

Personally, I would like to see it support both.  Make the basic
implementation use glib, with a module to interface with CORBA objects.

This solves the problem of different people working different way, and
allows for easier transition from another platform.  I personally think
it would great to be able to sit down e.g. a Mac user and present him
with an environment that he is truly comfortable with.

(Which brings up an question I had and never pursued - how to go about
exporting the menu bar to the top of the screen as Mac users are
accustomed to? Unless I'm mistaken, this could be done by having that X
window swallowed into a GtkSocket widget... Hrmm... how to notify the
Socket of changes in focus... ah well, I'll look into that later...)


> > 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 I think that a preview pane would be useful in open dialogs.  :)

I definetly agree with you there.  Much like the BROWSE option for
choosing a new icon for a launcher works.  Definitely makes sense.  
 
> > 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?
> 
> Certainly, and after thinking about it a bit I realized that I agree.
>:)  The reason that I don't expect Cancel to do meaninful and useful
> things with file dialogs is because I never expect so much anywhere else
> either.  After all, after applying changes under any dialog in Windows,
> they are almost always unreversible.  In general cancel under windows is
> only for changes which have not yet taken effect.  The implementation of
> this, however, is both clumsy and inconsistent.

*nods*  This is one area of usability that I think should be looked at
seriously.  I can't think of where they were, but I say a few spots
where DISMISS would have been the proper button label.
 
> > 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.
> 
> Maybe so.  Since most of my logic has been around Word
> Processor/Document centric applications, perhaps it may have something
> more to do with integrating file management into the application
> somehow.  Perhaps something like what StarOffice does with the workspace
> would be more appropriate than the traditional monolithic open/save
> dialogs after all?

*nods*  There are certain applications where it makes a lot of sense to
integrate basic file management.  

Or possibly even more intelligent -DOCUMENT- management tools.  I have
known people who use a combination of latex and cvs to manage large
documents specifically because neither file managers or word processors
provide support for the flexibility it gives them.

Adding support in applications for content management would simplify a
lot of issues considerably, not the least of which would be simplifying
file management by putting these things in their proper context.

I can think of a lot of possibilities for this sort of thing, like
attaching descriptions and version control to your word processor, etc,
etc.

Some of this functionality could possibly be encapsulated in CORBA
application applets, and used in place of document preview in file
management.  It seems like doc preview in some cases would be a weighty
way of finding out what FOO.DOC is (especially if it turns out that is
your 500K master's thesis :)

Matthew