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

[Dave Bordoley <bordoley msu edu>]

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.


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

> What about
> *deleting* them, then? 

Deleting files is dangerous as well, this is why we 
a) by default move files to a virtual trash can so that they can be
restored.
b) Explicitly ask a user if they want files to be permanently deleted.

> And how comes there's no "undo" feature, can't
> you just rename it as it was? 

Well given good undo, I would be less against such a feature, but even
with it, i think the size of the target, and overiding what it means to
click on something with more than one operation is confusing...oh btw,
nautilus does have an undo implementation, but apparently its broken and
hence ifdefed out.

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

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


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

dave