Re: FileChooser's path bar and re-rooting
- From: Ross McFarland <rwmcfa1 neces com>
- To: Seth Nickell <snickell redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: FileChooser's path bar and re-rooting
- Date: Mon, 15 Mar 2004 19:49:38 -0500
On Mon, 2004-03-15 at 18:38, Seth Nickell wrote:
> Rerooting *is* a violation of the conceptual purity of the path bar. Why
> do it then?
>
> In interface design the first goal is to deal with the most common use
> case well, then branch out to handle the other cases with as little
> impact on the common case as possible (this differs substantially from
> code design / architecture where "edge cases" often become central to
> the design).
>
> Here are two broad use categories guiding the design of the file
> chooser:
>
> 1) Corporate desktop users working with documents
> 2) Traditional *nix developers
>
> (1) is the primary use case. It involves relatively shallow use of
> heirarchy, almost always constrained to the home directory.
personally i think hiding the location of the home directory on a unix
system is a bad idea. the home directory is a central enough
location/concept that on unix a user needs to know where it is. if they
want something from a co-worker's home directory and they know where
their home directory is located they'll have a pretty good shot at
guessing where to find the other.
> For Category (1) users:
> - Items in the list on the left represent folders of particular
> interest: current projects, a shared workgroup folder, etc. When they
> want to use this folder, they want the "Henderson Project" folder, not
> "/home/jferguson/Desktop/Documents/Henderson Project". That is, by
> virtue of being a named object of primary interest, its place in the
> heirarchy is not a relevant cognitive factor in referencing the object.
> The object is effectively promoted to define its own context (and
> becomes the context of any files and folders it contains: "the tax
> spreadsheet in the henderson project folder").
and for much the same reasons completely hiding the true location of
that folder may end up hurting the user in the long run. if nothing else
it doesn't encourage/support them in becoming more than a mindless user.
what if they want to run a shell command on a file in the "Henderson
Project" they'd have no clue where it was if it's location was always
hidden. for that matter what if they use an older version of an app, one
that doesn't use the new file chooser, they won't have a clue were to
look for the project folder and they'd be lost.
of course, only my opinions.
-rm
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]