Re: [Usability] Copy/double click feedback



The question is really how much we want to improve the icon activate function. I mean, to be honest, we could do this a number of ways, but some of them are a little harder to adjust to having to do, and would drive you insane if you do cross-desktop... anything.

So, the solution I would propose is that we just pretend double click was never implemented in a user interface. We just ignore that. Instead, we would use the left mouse button, single click, to launch programs, etc. To provide visual feedback to the user that the computer is going to behave that way, we would change the icon from pointer to hand-pointer, like clicking on a link. I saw this implemented in Knoppix 3.3 with KDE, which was, admittedly, my first GNU/Linux distribution, and I quite miss that, to be honest. I'm used to double-click now, but single click really made more sense.

Of course, there would be people who are trying to select things, and they would accidentally launch the program instead of, for example, moving the icon. In order to make this less likely, we could use the right mouse button, single click, to select items. To do a menu of options, you could use the scroll-button (middle mouse button) or scroll emulation.

This would be a lot easier to discover, because it's just one push to do something. An option to switch between this and the legacy method would be nice for people who *hate* that idea.

As for copying, I seem to be in agreement with everyone else on that one. When will this be implemented?

Peace
- Kevin Carlson

On 9/24/07, caleb marcus gmail com < caleb marcus gmail com> wrote:
I'm not entirely sure about this, but I think that either Desktop Data Manager or Glipper may already implement this.

-----Original Message-----

From:  lorenzo <l bolzani gmail com>
Subj:  Re: [Usability] Copy/double click feedback
Date:  Mon Sep 24, 2007 2:13 pm
Size:  1K
To:  usability gnome org

2007/9/24, Calum Benson <Calum Benson sun com>:
> On Sun, 2007-09-23 at 20:19 +0200, lorenzo wrote:
>
> Neat idea, but many apps would probably have to implement custom visual
> feedback mechanisms of their own to deal with anything but the simplest
> types of copy-able object, which would mean extra work for developers
> and would probably result in inconsistencies between apps.

I think a simple "prototype" could be build working on selection or a
global indicator.
To copy something you always have to select it so the selection stuff
is already there. So you can blink the selection a couple of times, or
change the color for one second, ecc.
This requires a lightweight scheduling system to handle the
"animation" but I suppose it's already present. Otherwise you can
handle a very short animation syncronoulsy in the event handler
thread.

Otherwise, considering clipboard is a global/desktop level feature,
one global "sign" could be given, like a clipboard icon appearing in a
corner of the screen for one second or in the corner of the active
window or over the selected item (drawing at topmost/"glass" level so
you do not need to change each app) . But I'm not an expert of GTK
rendering...

If the Mac solution is not too much annoying this also shouldn't be :)

Text field and text area can be fixed all at GTK level I suppose.

> Yes, this is a long-standing concern for all desktops really.  I don't
> really have any idea what a workable solution might be; better brains
> than ours[1] haven't really come up with anything in the past 20 years
> or more that WIMP desktops have been pervasive.

Yes, you are right. It's not easy to find a solution that works well
for big desktop icons and small file manager icons as well. Anyway I
think we could try to think something about this thing also, maybe in
another thread.

Bye

Lorenzo
_______________________________________________
Usability mailing list
Usability gnome org
http://mail.gnome.org/mailman/listinfo/usability


_______________________________________________
Usability mailing list
Usability gnome org
http://mail.gnome.org/mailman/listinfo/usability



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]