Re: [Usability] The new file chooser

[<john erling blad aftenposten no>]

>> 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.

Sure, but I am one of those that never ever consider to use a user
interface that isn't point and click.. :p

> 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.

On a plain desktop system without any data it is not a common situation.
but when you start to use your desktop system it will pop up fairly
fast.
like on my CD collection.

> 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.)

Yeah, I have some specific applications for some very specific use. This
does *not* imply that the general case shouldn't be solved.

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

A 90% solution is really feasible with simple enumeration of file names
and catalog structures. You don't need a fancy search framework, just
plain enumeration and a check for existence of the resulting
catalog-file structure.

> 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.

These are a few *examples*. If I can find examples that easily there
will
be a lot of other examples.

> 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.

I think it is rather unusual to have a catalog with only one filetype
but
I don't know. Without a finer grained selection mechanism it would be
easy
to dump incompatible filetypes into an application.

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

Well, I don't think it is very common to implement for serialized tasks!
:)


John