Re: [Usability]User Object Simplification?
- From: Seth Nickell <snickell stanford edu>
- To: Havoc Pennington <hp redhat com>
- Cc: Nils Pedersen <n p sun com>, desktop-devel-list gnome org
- Subject: Re: [Usability]User Object Simplification?
- Date: 06 Mar 2003 23:03:35 -0800
On Thu, 2003-03-06 at 22:14, Havoc Pennington wrote:
> Hi,
>
> We never talked much about how to translate this into code.
>
> It seems the basic idea is to abstract some of the functionality of a
> "container", i.e. make the panel more like a directory view and a
> nautilus directory view more like the panel.
Yes.
> Concrete steps here seem to include:
>
> - perhaps the panel contents should map to a filesystem directory,
> instead of a bunch of gconf settings?
Possibly as an implementation technique to ensure that the same
operations work the same way in both panel and nautilus.... but probably
not something that should be particularly user visible. Perhaps
~/.gnome2/panels or something like that. We also might consider
re-evaluating the name "panel". I'm not sure if its a standard "plain
English" concept for them... maybe it is, I'm just a little worried that
its jargon we're so steeped in we can't see it.
There's a lot of tricky issues in making Panel and Nautilus work the
same... but most of them we want to deal with anyway (since its silly to
make people learn two ways of doing things).
One issue here is going to be "double-click" vs. "single click". My take
on the issue is... if double click is really easy, we should use it for
the panel... If we have reservations about using double click for the
panel because we want it to be "fast", then we need to seriously
reconsider the use of double click to activate objects in Nautilus too.
Its worth noting that many older people (and some children below 7) have
some difficulty with double click.
We also need to come up with a single (smooth) solution for moving
"active" objects (i.e. non "nautilus icon" / "panel launcher" objects).
One other thing that might be worth considering is getting rid of
"buffered" drags. I'm not sure if/how this affects the implementation of
a shared library, but I can imagine it would. Currently the "move"
action isn't performed on objects until you "drop" the object. A virtual
representation of the object is carried with the cursor, but the "real"
object stays put until you release. Its a much nicer interface to
actually move the object as you drag it (makes positioning, among other
things, *much* easier, also provides a good physical distinction between
copy and move other than the rather invisible "+" addition to the
cursor).
- establishing an initial place to share code between panel and
> nautilus, a library that supports "things/icons" that can be
> contained - where things/icons have to be lightweight enough to be
> elements in a nautilus directory view.
Seems like a good idea.
-Seth
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]