Re: [PATCH] Change list-view rename-behaviour
- From: Roberto Rosselli Del Turco <rosselli ling unipi it>
- To: Dave Bordoley <bordoley msu edu>, Nautilus <nautilus-list gnome org>
- Subject: Re: [PATCH] Change list-view rename-behaviour
- Date: Tue, 14 Jan 2003 09:35:10 +0100
Dave Bordoley wrote:
> On Sun, 2003-01-12 at 12:24, Roberto Rosselli Del Turco wrote:
>
>>I would have patched it the other way round: what's more intuitive than
>>clicking and changing an icon's name? If you click on the *icon* you
>>won't be annoyed by the rename option.
>>
>>Ciao
>>
>
>
> Well direct manipulation is good, however I believe that real world
> experience generally has proven that click to rename causes more
> problems than it is worth. Particularly in the list view, the file name
> is the most obvious target for users to click on in order to launch the
> file (mostly due to the fact that it is the defining attribute of the
> file). In the icon view click to rename has the disadvantage that we
> create different specialized behavior depending on where you click an
> object, basically reducing the target size a user has for
> opening/launching a file. This leads users to erroneously enter rename
> mode, which is potentially dangerous and can cause data loss in the
> worst case. Renaming isn't all that common of an operation so requiring
> a user to use keyboard shortcut or context menu entry seems reasonable
> to me at least.
Well, it seems that general consensus is clearly leaning in the "axe it"
direction :) I will raise some general points, however, as they are
related to other, more general issues.
1. Is the concept flawed, or just its implementation?
In his original message, Marten described the icon renaming feature in
list view as "very irritating" (BTW, I find it telling that he expressed
as such and didn't quote the bug 83552 "good arguments" from the start:
see later on). I must say that I agree with him: icon renaming in list
view can get in your way, which is why I suggested to click on icons.
The truth is, though, that it *doesn't* have to be that way. I never
thought of it as irritating under Windows: why? Because under GNOME 2
the renaming starts almost as soon as you click on the icon name, while
under Windows you can safely click on both the icon and its name, to
rename the icon you have to "insist" a little longer on the name. If
GNOME behaviour could be changed to be more similar to Windows, chances
are that icon renaming would be less "irritating" for the user.
2. Is renaming a "somewhat dangerous operation"?
Of all the arguments kindly posted by Marten, I think this is the most
bizarre: is it really "dangerous" to let users rename files? What about
*deleting* them, then? And how comes there's no "undo" feature, can't
you just rename it as it was? Consider, furthermore, that under Linux
you can only rename files you own: have Windows users managed to screw
up their installation by renaming system files in weird ways? does it
really happen? (See below)
As regards the other points, only n. 3 sounds true to me (n. 1 concerns
the implementation, as hinted above, and n. 4 is moot if you change icon
behaviour in either way for icon and list view). We can a) live with
this inconsistency (in the unlikely event that direct icon renaming
won't be killed, that is ;) or b) change it in such a way to make it
consistent, perhaps adding a modifier key to hold while clicking on the
icon to rename it, both in icon and list view.
As concerns a), consider that single clicking introduces another, much
"heavier", inconsistency, namely that you can't select an icon without
holding a modifier key. If we can live with this one, the other one
seems a direct consequence of the first we can surely bear. And perhaps
the implementation could be tweaked in a way to get rid of it:
* single click (click and release mouse): open file
* "longer" single click (click on icon name, wait until you can't rename
the icon, release mouse): rename file
3. How do we know that direct icon renaming is "bad" for the user?
This feature, in particular as it is available under Windows, has been
criticised for being "dangerous", just plain "wrong", "more
problems than it is worth" and susceptible of causing "stress/emotional
scarring" (ok, that was a joke, but you get the point ;) My humble
question is: how do we know? Has it been criticised in some Hall of
shame? is it being advised against in some GUI design textbook? are
there any studies on the subject? Because I'm under the impression that
we're acting because of the "irritating" factor and/or under the
perception of the feature being wrong, presuming that all Windows users
are ill at ease with it. But is this really true? since we're talking
about personal or anecdotal experiences, I could as well throw in mine:
a) I use this feature all the time under Windows, never found it to get
in the way and actually miss it under GNOME (as a pointed in one of my
first posts on this list) in icon view;
b) of all the reasons Windows users may have to complain about it, this
"problem" was never mentioned to me as a GUI hinderance or design flaw:
people can't easily find items, are disconcerted by many
inconsistencies, but AFAIK have always managed to rename their icons
without losing too many heartbeats (for what is worth, I've helped lots
of people with Windows, the common curse of many Linux users...).
So, how do we know this is a "problem" under Windows? The obvious
inference being that, if it isn't one for 90% of desktop users in the
world, it shouldn't be for GNOME users as well...
Point n. 3 is directly related to what, again in my very humble opinion,
is the weak spot in the GNOME usability decision making: lack of user
testing and other usability studies. How long has passed since Sun's
study? Are any similar projects in the works? has the 2.1.x interface
been proposed to select group of users for testing before feature
freezing? I only remember some user input brought up by Calum, and
that's it (I could be wrong, of course). We lack "real users" input.
Don't get me wrong: I really like the direction GNOME is heading to, and
the general philosophy underlying it. But in some way we're still tied
to the old "developers designing GUIs for users" strategy that has
proved a major flaw of free software production. As the foundation (the
HIG) and the discussion group are already there, IMHO we[*] should
recruit "GNOME usability testers" and perform user tests on a regular
basis, so to have some grounding for our assumptions. Items that should
be re-thought and put to test abound: the whole MIME/default viewer
stuff, the open/save file dialog, side bar concepts in Nautilus and
other apps, etc.
Ok, if I only could remember where I put that asbesto suit ... ;)
[*] Note that "we" really means "the GNOME 2 usability group and what
little contribute I could bring in" ...
Ciao
--
Roberto Rosselli Del Turco e-mail: rosselli cisi unito it
Dipartimento di Scienze rosselli ling unipi it
del Linguaggio Then spoke the thunder DA
Universita' di Torino Datta: what have we given? (TSE)
Hige sceal the heardra, heorte the cenre,
mod sceal the mare, the ure maegen litlath. (Maldon 312-3)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]