[HIG] Re: Viewports or equivalent

This isn't a big issue.  Let's not waste too much time on it.

Rui Miguel Seabra wrote:

The way the gnome2 pager retains coordinates has nothing to do with the workspace/viewport change -- it works that way because Havoc thinks it's a usability improvement. I happen to agree. It really is a lot easier to move windows between workspaces now. You don't have to be nearly as precise with that drag as you used to.

The pager is usually big enough for one to detect an empty space and
it's way nicer that you can drag it to a near location.

The way the gnome pager vectorizes windows implies that if you move it
to another workspace, and the close coordinates are somewhat crowded,
than you will have extra work to get to the window when you go there.

It's less natural and less intuitive, so how can it be an usability
improvement? It _was_ easier to move windows between virtual desktops
(well, viewports) previously, since you not only had immediate feedback
but also you could put the windows nearer to where you want them.

To maintain coordinates, there was a sawfish move window to workspace N

The main problem is that it's too hard to aim window-placement using the tiny pager.
   A) The resolution is too coarse to place windows precisely.
B) The pager is too small to tell if you put the window exactly where you want it by looking at the pager (ie. if you want to put a window flush against the screen's or another window's border). C) Mice are generally too sensitive to do pixel-level adjustments. You have to have used them for years to be able to do so, and even then it is really hard and annoying.

This means that you usually have to re-adjust the window by hand in the main screen after moving it to an approximate location with the pager. If you're going to re-adjust it by hand anyway, then what's the point of moving it to an approximate location with the pager in the first place? It will actually be SLOWER to move it to the approximate location in the pager than in the main screen, since it's hard to move windows precisely around the pager, which means that you'll LOSE time with fine-grained pager control.

This leads to the second big point, which is that it's a good default to place windows in the same coordinates that they used to be in. A) Short-term spatial memory makes it easy to find the window in the new workspace because it's at the same offset from the screen. B) People generally like having various windows in certain positions. I put gaim in the upper left, xmms on the left, my mail reader centered on the right, xemacs vert-max'd on the right, terminals vert-max'd on the right or the left, etc. In particular, if I've got a vert-max'd window, it's really easy to drag it from the right to the left or vice versa if it overlaps with something else using the main screen, since it locks itself vertically and snaps to the screen's edge -- thus putting it at the original coordinates gets things half right. C) A common use of the pager is to move all windows in a workspace to another workspace. If the windows retain their coordinates in the move, then the user doesn't have to place them precisely at all -- they automatically arrange themselves properly!

In fact, it really isn't any harder to allow fine-grained window-movement via the pager when using workspaces than it was using viewports.

It is harder since now you don't move, but drag it to another workspace
(maintaining coordinates).

I was talking about the implementation of fine-grained window-movement. It is pretty straightforward to implement fine-grained window-movement in the workspace-switcher even though it uses workspaces.

I think the real loss with the current way of doing things isn't that it makes you unable to move windows to pixel coordinates via the pager but that you don't get the immediate on-screen feedback when moving a window.

The pager never allowed the pixel resolution (AFAICT). That would be
extremely hard to use. It used a somewhat lower resolution that allowed
you to move the window to the surroundings of a certain area close to
where you wanted.

Sorry, I didn't mean single-pixel resolution, but n-pixel resolution.

The apparent loss of feedback is due to a certain language problem that
people keep faling onto precisely because the new way is _NOT_ user
friendly: you're not moving (which implies a gradual change of position)
anymore BUT taking the window from this workspace and putting into that
one (where drag'n'drop applies properly). Even though pick up here and
drop there may seem the natural action in a 3D environment (a real desktop)
moving is more natural because you're talking about something on a 2D

I don't think this is true. Metaphor-wise, drag-and-drop is the same as moving. People drag-and-drop things on 2D screens all the time. Plus, metaphors have nothing to do with this feature. The question isn't whether windows get d-a-d'd or get moved, but whether A) they can be placed on n-pixel coordinates or not, and B) their on-screen displayed positions are updated simultaneously with their displayed positions on the pager. One argues over metaphors when trying hard to explain a concept to a user-community that doesn't understand it. I don't think that the dnd or move metaphors are different enough for an appreciable benefit to exist here.

Of course that on a workspace environment where you can't drag a window
from one to the other, it may seem logic not to move the window but put
it in the other place. However, that's thinking small.

The continuos misunderstanding of the behaviour of the gnome pager, is
good enough proof on how user friendly it is not.

What continuous misunderstandings?  I don't see any.
Are you saying that the old pager was easier to understand?

I guess I wasted too much time on this issue... :(


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