Re: [Usability] The eternal fileselector dilemma :)

[Alan Horkan <horkana maths tcd ie>]

On Mon, 27 Sep 2004, Lemmit Kaplinski wrote:

> Date: Mon, 27 Sep 2004 11:52:07 +0300
> From: Lemmit Kaplinski <lemmit kaplinski com>
> To: usability gnome org
> Subject: Re: [Usability] The eternal fileselector dilemma :)
>
> Hi,
>
> Alan Horkan wrote:
>
> >It is a little annoying when people post external links and dont include
> >at least a preface or outline of their suggestions inline as it makes it
> >much more awkward to respond to the points raised.

> Sorry :)

No worries.

> >The way I see this working would be that Save In Folder would become much
> >more like the Bookmarks in Mozilla (call it Shortcuts/Locations if you
> >prefer)
> >
> >
> This much we definitely agree on. The question is - I am not very
> familiar with how the Gnome project works and I can do zero coding. How
> should I go on about trying to push this idea and get it done. Does it
> have something to do with writing a GOP/GEP/GIP(?!).

Detailed mockups seem to be an effective way to persuade developers.
If you can go beyond mockups as graphics and also provide mockups in Glade
formats that seems to help convince people.

The most important thing to do if you want to get your suggestions
implmented but lack the specific knowledge to implement it yourself is to
be patient and be willing to make yourself available to the developers to
explain as clearly as possible exactly how you think things should work.

Incremental changes to existing solutions are always easier to get done
than radical overhauls.


> >The Sidebar could be removed entirely, or collapsed by default with a

> I am against duplication. There are many other things that need that
> space as bad. But if it must be there, the possibility to hide will come
> in handy.


> >Breadcrumbs.
> >Interesting idea but it I dont think it is anything special.
> >I'd much prefer to have the Location bar back (and perhaps a small "Up"
> >button somewhere nearby if the developers were feeling generous).
> >
> >
> Speaking about the Save dialog, you can use the filename part as the
> location field, it does autocompletion and all :) I'd have to think
> about Open though. But please - do some mock-uping and I can criticize :)

I thought about it more and made a mockup and I realise it is not as good
an idea as I previously thought it was.

very rough mockup of file chooser
http://www.maths.tcd.ie/~horkana/testing/file-chooser-opener-mockup.png

i've also rearranged the bookmark sidebar so that it is a proper side bar
and could more easily be made collapsable (i have a Layered version of the
image file, mockup.xcf at the same location if anyone wants it so that I
can make comparisions).

Having thought about it I want the name entry box to be shown on the Open
Dialog again so that the filechooser is more consistant with itself in the
both the open and save states.

I was thinking that the name/location entry would include a dropdown
that could contain recently visited locations (not just the locations
users have explicitly bookmarked) and that it would also provide
access an easy way to go up.  I haven't got the idea clearly worked out
though and I'm probably trying to overload it and put too much in the
dropdown.

Name [filename              [V]
      /path/path/filename
      /path/path/
      /path/
      /
      ---------------
      /been/there/
      /home/usersname
      /monkey/
      /foo/bar

The Mac simplified the file opener in a different way, leaving only the
name/location entry by default and hiding everything else.  If I recally
correctly the Mac OS X file chooser looks like this by default (and
expands to a more complicated multicolumn layout if you choose browse)

Filename [                 ] [ Browse ]

Gnome does almost the opposite and hides the name/location, and shows the
more complicated point and click file chooser by default.  If we are are
really trying to discourage oridinary users from from using the file
chooser in favour of the file manager and drag and drop, it seems to make
more sense to do as Mac OS has done and provide the the name/location text
entry because it is the fallback for those who do not or cannot use the
file manager/drag and drop way.

> >Save As
> >I dont think Character Coding belongs in the Save Menu I really dont.

there should probably be a menu item in the application for setting the
character encoding.

> >Gnome developers have always given in to the temptation to add extra bits
> >to the file chooser when they really shouldn't.

> I don't agree with you here.  I'd hate to see several popups in
> succession (Iäd phrase this as "One action, one window" rule, but I have
> to think about it more).

i can agree with that, but was more thinking of the need to stop
developers from overloading the file chooser.  ideally there would be no
additional popups (users dont want or need to change these things every
time they save) only a single Options button leading users to a
import/export preferences dialog.

> What is the Beagle Search tool? Just send a link and lets keep the
> thread to the topic.

Beagle is part of Dashboard
http://www.gnome.org/projects/beagle/

I saw a proposal recently about modifying the file chooser (which is why
this is vaguely relevant) to include a search widget (i think it was
Beagle releated and I probably read it on Planet Gnome but I forget who
wrote it and cannot find a relevant link).

I figure if the open Dialog were changed to included a Name/Location entry
like so

Name [               ] [ Browse ]

those that want search could easily be overload it to be

Name [               ] [ Find ]

which would lauch a more eleborate search tool instead of the current
point and click on the icons.  (I see many mockups in required in near my
future ...)

> >more messing with the File Chooser will happen so it is necessary to try
> >and figure out a way to get applications to at least make their changes in
> >a consistant way.

> I agee here- While you dont like applications changing the chooser and I
> do, we have to face the fact that they will continue doing so.

While I would rather applications did not change the file chooser i accept
the inevitability of it and hope for a file chooser design that
descourages the overloaded modifications and busy designs we have seen
coming out as a result of the Gtk2.4 file chooser

like the one you pointed out
http://lemmit.kaplinski.com/home/green/Gnome/images/saveas2_detail.png
or even more complicated like this huge File Chooser
http://netart.eu.org/data/pic/e16-gimp214-s.jpeg

> >What I have been wondering most of all is that now that we have a good
> >clean File Chooser API shouldn't it be possible for those of use who want
> >more than the current file chooser provides to create our own File Chooser
> >and wholesale replace it across our entire desktop without needing to
> >recompile each individual application?

> Doesn't the current one allow that. I understood that is nice and
> modular and all?

I think it does but I dont know how to do it, with a more information and
enough time I could probably produce a working and more easily modifyable
design (instead of just mockups) using Python (and glade).

> The best,
>
> L.

Sincerely

Alan Horkan

http://advogato.org/person/AlanHorkan/
Inkscape, Draw Freely http://inkscape.org
Free SVG Clip Art http://OpenClipArt.org