h a l f b a k e r yThis is what happens when one confuses "random" with "profound."
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
A common problem with mouse-based user interfaces is a need to click on an object and move or change it by an amount which exceeds the available screen real estate. Some programs will try to auto-scroll a window when the mouse pointer hits the edge, but the result is typically a frustrating battle of
trying to make the window scroll the right amount and then trying to get the mouse pointer to the proper place within the scrolled window.
A better approach would be to allow an object, when clicked, to specify a rectangle within which the mouse would be "pinned", but to count the amount of attempted movement beyond the range. If the user would have moved the mouse 60 pixels past the right edge of a scrolling region, peg the mouse on the edge and notify the application to scroll 60 pixels left. If the user moves the mouse another 20 pixels, scroll another 20 pixels. If the user then moves the mouse left 30 pixels, have the mouse move that distance, thus reaching a spot 50 pixels past the original edge of the scrolling region.
I've seen a few applications that kinda-sorta attempt something like this, with varying degrees of success, but the lack of standardized support makes it problematical.
As an adjuct, pop-up menus and hand-style scroll tools would leave the mouse position unchanged when they're used. In the latter case, the tool cursor would remain motionless as the screen scrolled. In the former case, a marker would show the location of the cursor when the pop-up menu was clicked, with a drag-line connecting it to a second cursor which would be used while the mouse button was held. If the original mouse cursor is close to a screen edge, the second cursor could start somewhat toward the middle. In any case, releasing the mouse would leave the mouse cursor at the spot where it was clicked.
Please log in.
If you're not logged in,
you can see what this page
looks like, but you will
not be able to add anything.
Annotation:
|
| |
One could increase available screen real estate using the Star Wars technique and stretching rectangle forward into starry sky in 3D. |
|
| |
"A common problem with mouse-based user interfaces is a need to click on an object and move or change it by an amount which exceeds the available screen real estate."
Can you give an example? |
|
| |
phoenix: Common example: Using a "drawing" program (whether for graphics, schematics, PC board layout, etc.), it's sometimes necessary to move an object from one location to another somewhat-distant location. While it may be possible to zoom out sufficiently to allow both locations to be visible on screen, such a zoomed-out view may allow the object to be selected or placed accurately. |
|
| |
As noted, many programs handle this by attempting to auto-scroll if the mouse pointer moves beyond the edge of the window, but such scrolling is almost always either too fast or too slow, and once the scrolling is done one has to visually process where the screen has scrolled to and navigate the object to the correct place. |
|
| |
Under my proposed solution, if the object is supposed to move right twenty inches, one would hold the button while moving the mouse rightward by twenty "inches" (i.e. by an amount equivalent to twenty inches of pointer motion). Moving the mouse that far would move the object that far, regardless of the relationship between object positions and window positions, and regardless of whether the motion was performed quickly or slowly (mouse acceleration would have the same effect as in any other context). If one wanted to see a little more context of where one was dropping the object, one could move the mouse right by twenty-two "inches" and then left two "inches". |
|
| |
"phoenix: Common example: Using a "drawing" program...to move an object from one location to another somewhat-distant location."
How about "holding" the object to be moved with the left mouse button using the right mouse button to move (drag) the surface underneath? |
|
| |
[i]How about "holding" the object to be moved with the left mouse button using the right mouse button to move (drag) the surface underneath?[/i] |
|
| |
There are a number of ways things could work, but the key point would be that while the mouse is clicked and held within a window, all mouse motion would be relative to the logical content of that window rather than the physical screen. That would only really work, though, if material could be scrolled beyond the normal scroll limits (otherwise if the mouse is in the middle of a 6" window, one would hit a "wall" about 3" before the end of the document). |
|
| |
Wouldn't it be easier to just cut the object from the first location, then scroll, then re-paste it? |
|
| |
//Wouldn't it be easier to just cut the object from the first location, then scroll, then re-paste it//
Not when the sort of applications that we are talking about generally have dynamic links to other objects (e.g. Circuit diagrams or control logic workflow sheets). It is very uncommon for there to be a 'Move' function on the same workspace/sheet.
Like feel the need for the idea, plenty of ways to skin this cat.... |
|
| |
I wonder if I'm alone in wishing supercat would email me! damned elusive supercat... |
|
| |
are those mouses with the scroll-sphere not able to do this? (With Inkscape and a scroll-wheel mouse it works, so i guess the xy version would work too) |
|
| |
An advantage of this approach over a scroll sphere (do such things exist? I've just seen wheels) would be that mouse distances would be preserved. A mouse motion that would move the pointer 5" to the right in an open screen would move an object 5" to the right within a window, regardless of the latter's scroll position. Any other approach I've seen would require the user to scroll first and then visually reacquire the target. |
|
| |
i am not sure i can follow your argument: say you zoomed in on a page, the whole window covers the 5x5cm on the lowest left of the 20x20cm page. you pick an object you see (right upper corner of window/screen), click on it, and then try to move it to the right upper corner of the page - your pointer would stay on the object, you move your mouse up-and-right, and the objects is dragged there. But this is the same behaviour you get with a scroll wheel (xy scroll-balls exist) - the pointer stays on the object, the object stays on the same position on-screen, but is moved on-page. The argument about 'real' distances is somewhat flawed, as mouses often have non-linear behaviour depending on the drag-velocity (eg., 2cm, fast movement is same as 5cm slow movement) |
|
| |
Even if one had a scroll wheel which could be maneuvered with the same precision as one would move a normal mouse, one could only use it in the fashion I described if one were allowed to scroll onto the screen areas past the edge of the document. Otherwise if the pointer starts 3" from the edge of the window and one is trying to move something 1" from the edge of the document, the window would stop scrolling when the pointer was still 2" from its proper destination. |
|
| |
Further, it seems that designing a scroll wheel which could be maneuvered as effectively as the mouse would be difficult; better to simply have the pointer move around the document with precisely the same precision as it would move around the screen. |
|
| |