Re: [PATCH] Change list-view rename-behaviour

[Roberto Rosselli Del Turco <rosselli ling unipi it>]

Dave Bordoley wrote:
> On Tue, 2003-01-14 at 03:35, Roberto Rosselli Del Turco wrote:
>
>>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.
>>
>
>
> That kind of a time delay is a potential accessibility issue. A user
> sets his/her double click delay and all apps should follow it.
> Furthermore this "special" behavior dose tend to cause users to
> accidentally enter rename mode, which after being a window user since
> windows 3.1, I can attest is really annoying.

Again, you (and some other people on the list) think it's annoying, I
(and at least one other person on the list) don't. And that doesn't
answer my question: is this feature a bad idea in itself or not? why?
where can I read something (HIG studies, user testing) about it? how
could Windows users survive with it for all these years?

As concerns the accessibility issue, I just can't see it (which doesn't
mean that it couldn't happen, of course :). Again, if it's the case, you
can solve it in the implementation, making the click delay even longer 
than in Windows, so that only people who know about the feature (and 
therefore have the skill to use it) will manage to activate it.

>>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?
>
>
> yes it is dangerous to let a user rename a file when they have not
> explicitly requested to do so (and mouse clicking gestures are far too
> vague to be used as method of determining user intent imo)

Dave, those were rhetorical questions, I just wanted to point out that
if you allow users to delete (and move, and overwrite by copying...)
their files, file renaming dangers shouldn't be over-exaggerated.

But anyway, even under Windows you *can't* rename a file simply clicking
and entering in the icon's name text field, unless your cat decides this
is just the perfect time to have a stroll on your keyboard (as I have 11
cats, I'm somewhat at risk then ;)

>>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.
>
>
> You start running into lots and lots of issues once you try to use
> modifier keys while clicking, in particularly in fighting with the wm
> for modifiers, although i'm not against such an idea (since I think it
> is an action that is likely to be performed only by a user who knows
> about the click+modifier behavior).

You're right about this one, but it was just an idea, I don't like
modifier keys for this stuff either.

>>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
>>
>
>
> Such behavior would most likely be an accessibility concern. Calum or
> bill would know better to comment on that though.

See above.

>>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.
>
>
> Well seth (GUP leader) frequently does put together little usability
> tests, but to be honest from everyone I've talked to, usability tests
> should really be referred to as learnability tests. Really the best way
> to design guis seems to be using common sense, basic design an
> interaction guidelines, and choosing an audience.

Call them "learnability tests", "usability tests" or even "dumb user
test time", labels are not important. What's important, IMHO, is that
you also keep track with your chosen audience. I agree 100% about all
the rest (common sense, basic design, etc.).

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)