Re: [Usability] The new file chooser



On Mon, 2004-09-20 at 20:38 +0200, john erling blad aftenposten no
wrote:
> > Samuel Abels Says
> > I do not know whether and where such a discussion might have taken
> > place, but when it comes to ask the question whether or not there
> should
> > be a new widget, I think we should always try and ask the question why
> > we need it rather then why we don't. More widgets = more clutter. This
> > is not to say that sometimes a bit more clutter is required.
> 
> I have no idea how much more cluttered thing might be (mumble) but there
> Times when a filename clearly *is* necessary.

And at those times, ctrl-L *is* available.

> 
> >> in fact, serialized filenames are not a uncommon thing. on the office
> >> desktop. in print production, in audio production, in allmost
> anything
> 
> > Please be more specific.
> 
> On one specific server there are catalog structures consisting of
> something
> like /publisher/year/month/day/page/article.type
> To traverse such a structure plainly though point and click is tiresome.
> 
> Now, this kind of structure is *very* common on servers storing data in
> hierarchies. You use the catalog structure as a basic look up into a
> more
> complete description of some kind. This could be embedded as tags in a
> mp3 file or a xml file.
> 
> Note that the existence of the tags aren't interesting here, it is the
> existence of a catalog structure to support this structure.
> 
> Now, such structures could contain hundreds or even thousands of
> entries.
> XFS for example is very efficient when the number of entries in a
> catalog is very large.

And these situations are very uncommon on Desktop systems.  I don't
doubt that a dialog optimal for the desktop is unoptimal for traversing
server data hierarchies.  

Which application(s) are you using with these hierarchies?  Is it
something specific to the server app?  If so, perhaps it should use the
right tool for the job and not use the file selector, but instead use a
custom UI designed explicitly for the hierarchy in question.  (Select a
date and article type, for example.)

> 
> So what you (I.. :) would like is something where you could write a more
> or less specific query. Lets say you write a date specification inside a
> catalog, then the file chooser would attempt to rewrite this to match
> other
> dates used in this catalog. But clearly, a file chooser have to be a lot
> more intelligent than this. Which leads to some sort of search
> capabilities.

i.e., a file system with rich meta-data capabilities and a good search
system.  See Storage, WinFS, etc.

> 
> Now, if you open a file in serialized fashion, then you want *one*
> application opening one by one of a number of files. Often this is
> because you want to do a few small steps with the file and then store it
> back. In other words, if you want to serialize you will also need some
> sort of macro scripting facility. Still, this is often the case but not
> always.
> 
> Serialization is a well known technique in control and command types of
> applications. It is also well known from archive retrieval applications
> where you set some parameters and traverse through a set of hits.

These apps really then shouldn't be using the file chooser.  The file
chooser is, specifically, for choosing a single file somewhere,
primarily designed for desktop usage.

One tool _cannot_ fit all requirements ideally.

For example, with a folder that contains a number of files in some kind
of special order, in which you know the operation in question is going
to involve touching a lot of those files, it is really dumb to make the
user pick each file.  Instead, let the user pick the folder, and provide
Next/Prev operations to cycle through the files, and a search bar/entry
for finding a particular file.  Instead of modeling the UI in such a way
that exposes how the data is stored (a folder full of files), model the
UI around the fact that you have (in essence) a database with many
entries.

Modifying the file chooser isn't going to get around incompetent
application design, unfortunately.

In the case of using a generic application with some specific "many
serial files in a folder" type of situation, just use the power of your
file manager.  Double click.  Edit.  Close.  Double click.  Edit.
Close.  Each open operation _should_ be very fast after the first, as
the application is already in cache.  You really don't ever at all even
need to _use_ the file chooser to open files when you realize that's
_exactly_ what the file manager already does (in addition to, of course,
managing the files).

> 
> John
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
> 
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]