[HIG] Re: Viewports or equivalent

[Michael Toomim <toomim OCF Berkeley EDU>]

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

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

-Michael