A Proposal For The Complete Elimination Of Scrollbars From The GNOME Desktop
Bowie J. Poag
(The following article was posted to the GNOME gui & development mailing lists.
I'd appreciate any comments or criticisms about this idea.)
-------------------------------------------------------------------------------
A Proposal For The Complete Elimination Of Scrollbars From The Gnome Desktop
-------------------------------------------------------------------------------
Written By Bowie J. Poag 02/17/98
-------------------------------------------------------------------------------
Document Overview:
I. Introduction
II. Device Description
III. Device Behavior, Methodology and Usage
IV. Usage Examples
V. Conclusion
Appendix:
A. Chart, depicts behavior of the Scrollball in relation to user input
B. Chart, depicts placement of Scrollball within a window.
[ I. Introduction ]
What you're about to read is the result of about 4 months of careful
research and study into the way human beings interact with visual
interfaces. For the seven month period spanning from July 1997 until
late January 1998, I was involved in an OS development project called
InSight. Part of my role within the InSight development group was to study
pre-existing interface designs in an attempt to further understand which
aspects of contemporary interface designs would still be viable and useful
for users for the next 5 to 7 years.
Within that seven month span, we developed several improvements (and
outright replacements) for pre-existing interface devices. One of which
being the "scrollbar methodology", e.g. employing two sets of sliders to
represent horizontal and vertical axes of movement, in addition to up/down
and left/right directional arrows.
Early on in our research we attempted to determine how and why scrollbars
even existed in the first place; who came up with them, why do they look
and behave the way they do, etc..and the historical reasons for the
presence of scrollbars can be fairly easilly explained. There was a time
when the amount of text which needed to be visible to the user within a
windowed environment exceeded the physical dimensions of the window; As a
result, an interface device was built which would allow the user to alter
the contents of what a paticular window displayed--and so the first
scrollbar was created.
Soon after, the user's needs for data visibility increased, and with it,
another similar device had to be employed which allowed content movement
along two axes. A horizontal scrollbar was added at this point, with
short-jump directional arrows for each axis soon to follow.
In the end, we eventually had to guess that the reason why two individual
scrollbars were employed for this purpose was purely a logistical one.
Machines at that point time lacked sufficient processing horsepower and/or
memory resources to allow unidirectional movement along both axes
simultaneously; so as a result, the task of shifting the contents of a
window was broken down into two distinct functions. Independant Horizontal
scrolling, and Vertical scrolling devices.
And so, it has remained for nearly 30 years. The reason why scrollbars
exist in 1998, despite huge advances in both processing horsepower and
memory resources is largely a historical one. Operating systems have
scrollbars because the operating systems before them had scrollbars. Its
simply a mixture of historical tradition, and the unwillingness to create,
modify or devise a better tool for the job.
Rather than stick with the tried and trusted scrollbar methodology, we
chose early on to break with tradition and begin devising an alternative
to scrollbars. InSight was going to be an OS which featured radically
different methods and tools to empower the user, and to stick them
with an obsolete historical relic like "scrollbars" would be
completely against our design goals. After about 4 or 5 days of thinking
about the problem at hand, we came up with a solution.
The "scrollball" concept, as it became known, emerged during an late-night
core development session on September 27th, 1997.
The "scrollball" is meant as a COMPLETE and -TOTAL- replacement for
scrollbars. It is both more intuitive, easier to use, and more versatile
than traditional scrollbar methodology. The entire sum purpose of no less
than six individual window components (horizontal scrollbar, vertical
scrollbar, up arrow, down arrow, left arrow, right arrow) have been
encapsulated into one primary window component capable of bound or unbound
unidirectional scrolling of unlimited proportion.
[ II. Device Description ]
The scrollball is a simple, unassuming button which occupies a place on
a window's frame, and occupies no more space than any other button present
on the window. It is a square box with a small sphere within it, with a
four-direction arrow painted on its surface.
(See: Appendix B, http://www.insight.dyn.ml.org)
Since the scrollball is meant as a complete replacement (and improvement)
of the traditional scrollbar methodology, the need for scrollbars within a
window can be reduced or eliminated outright. A scrollball may also be
presented or employed as a secondary tool for scrolling, to allow the
user to express their individual choice and preference between the two
methodologies.
[ III. Device Behavior, Methodology and Usage ]
Part 1: Device Behavior
Overview: In terms of behavior, the act of using a scrollbar is similar to
that of viewing microfilm under an enlarger, or viewing
photographic negatives underneath a lens. Directional mouse
movements cause the contents of a window to be shifted in the
same direction. The scrollball itself changes color to denote
changes in status, such as availability, or boundary
restrictions.)
The scrollbar should behave as follows:
1) When a window first appears on the desktop, a scrollbar should be
present; even when the likelyhood of it ever being utilized is
relatively low.
2) When the content of a window exceeds its physical dimensions, the
scrollball should then become available to the user. This is signaled
with a simple color-change. (it lights up, or turns off according to
availability)
3) At this point, the user may wish to click on the scrollball. Doing so
with the left mousebutton will immediately cause the scrollball to
change colors (example: Green, for "Go") and translate mouse movement
into unidirectional scrolling of the window's contents; e.g. when you
move the mouse up, the window scrolls up. If you move the mouse left,
the window's contents scroll left. (Directional mouse movement, and
speed correspond directly to the direction to which the contents of
the window are scrolled, and to what degree.) (See: Appendix A)
4) If a boundary is encountered which restricts the user's ability to roll
the contents of the window, the scrollball should again alter its color
to denote a change in status. (example: red, for "Stop") Since the
physical limits of a scrollable area have been reached at this point,
movement is restricted in the direction of the boundary, but the user's
movements can continue in other directions which remain unbound.
5) When a user locates a paticular area of an image, or document, a simple
left-click of the mouse should release control of the scrollball and
return the user to free-state interaction with the program. A
scrollball is an object which is meant to be engadged, used, and
released; One click to activate, move your mouse around, another click
to drop it.
6) A right-click should result in a small pop-up menu of options which
can and should include the ability to designate a "locked axis" , for
strictly Horizontal or Vertical movement. Doing so mimics the behavior
of traditional scrollbars. Example: Right Click-->Lock Y-Axis--> ...
Left Click-->Move Mouse to Scroll-->Left Click to release.
Part 2: Methodology
Due to the scrollball's unique function and design, certain things are
only possible using scrollballs that are not possible with scroll*bars*.
For example; A window is presented to the user with a map of the Earth.
Since the Earth is round, the map has no physical edges; A window which
employs a scrollball provides the user with the ability to continuously
scroll around with complete freedom of mobility. However, if the same map
of Earth were presented to the user with traditional scrollbar
methodology in place, the user could only scroll so far left or right, and
only so far up or down, without hitting an edge. The scrollball is an
inherently superior tool for presenting visual data to the user,
especially in circumstances which warrant unbounded and unrestricted
visibility of a window's contents. The map example is one of many.
When viewing a text document with several discrete columns of text up
close, its often a chore to have to manage the independant placement of
two sets of horizontal and vertical placement. With a scrollball, the user
is enabled to move directly (in a somewhat diagonal fashion) to the area
of interest provided within the window, instead of aligning the text with
two separate axes of movement.
Regardless of a window's content, whether it be image or text, the
scrollball is a superior device to the traditional scrollbar methodology
both in terms of function, and in terms of versatility to the user.
Part 3: Usage
While these points may be worthy of some debate, my proposition is this:
o That scrollballs be a permanent fixture on all windows, regardless of
size or content. That is, a scrollball should always be there; in the
event that the size of the content of a window exceeds the physical
dimensions of the window, the scrollball should then become available
to the user. (See Part 1, Behavior)
o That scrollballs -completely- replace the presence of traditional
scrollbars. Don't even offer a choice between the old and the new;
Offer only the superior tool, and allow the user to grow accustomed
to its usage and function rather than allow them to simply retreat
back to the comfort and familliarity of traditional scrollbars.
o That the scrollball itself offer cues as to its status and usage.
This can either be done visually, or audibly in the case of boundary
obstruction or activation/deactivation.
[ IV. Usage Examples ]
Now that we're familliar with the design and behavior of the scrollball,
lets have a look at a few real-world examples of how scrollballs can be
used.
In an image viewer, the user is given the ability to zoom in. While still
zoomed in, the user is given the ability to interactively pan around the
image unidirectionally, instead of via exclusive horizontal and vertical
axis movement.
In a web browser, web content can be made wider as well as longer, since
the user's visual mobility within a window has increased to allow
diagonal movement.
In a text editor, wide-column layout is made more accessable to the user
who no longer has only the ability to scroll up or down, then arrow over
using the cursor keys. The area of interest can be immediately
located reached, and worked with in a timely manner.
In ANY enviornment, in which both Horizontal AND Vertical scrolling may be
required, its often tedious for the user to have to constantly "tweak" the
position of scrollbars to gain the greatest visibility of the media in
which they are interested; With scrollbars, the act of locating and
viewing the desired media within a window is several orders of magnitude
easier to accomplish, and far less time-consuming.
[ V. Conclusion ]
It was our conclusion within the InSight project that scrollbars were
basically made obsolete by this device.
After careful study, it seems apparent that the only reason why scrollbars
continue to exist in today's desktop implementations is largely due to
tradition; the historical reasons why movement of a window's content must
to be broken down into two distinct and separate axes of movement have
long since passed under the bridge--Today's machines, and future machines,
have the ability to address the issue of appropriate scrolling in a far
better manner than to simply stick with tradition and continue to use an
outmoded, and inferior device.
o Not only are scrollballs more flexible and versatile, they can also be
made to behave in exactly the same manner as traditional scrollbars,
if required.
o There are things which simply cannot be done with traditional scrollbar
methodology that are now possible using this new tool.
o One scrollball can effectively replace the entire combined usefulness of
SIX separate movement devices in a window.
I propose that the Gnome desktop not only -feature- this design innovation,
but figure it prominently in the general layout of each window as per the
reccomendations listed above.
---
Questions or comments?
Bowie J. Poag - b...@primenet.com University of Arizona, Comp. Sci.
ex-InSight Core Development Tucson, Arizona.
Tel: (520)/320-3853
Matthew J. Francis
That's a very interesting idea; sort of like the "Trackpoint" widget IBM
likes. (Apparently they've even made a mouse with one on, to navigate in
a manner much like you describe...)
However, scrollbars often have a use other than merely navigating: they
provide a visual clue to the extent of the viewed document. Can this be
done in an equally effective way with a "Scrollball"?
-Matt.
Chuck Bermingham
Printed the article, and will read it. But...
I did a quick search on the contents, and nowhere did I see the word
"keyboard" mentioned. I hope to Heaven the Gnome people are going
completely mouse-crazy; some of us don't get along with mice very well.
D. Richard Hipp
Bowie J. Poag wrote:
> A Proposal For The Complete Elimination Of Scrollbars From The Gnome Desktop
> Questions or comments?
Been there. Done that. Yes a "panner" button or widget of some kind is
much much easier to use than a scrollbar. I recommend having one. But
scrollbars are also useful as a visual indication of the overall size
and
your current position within the object being scrolled or panned. I
think
you need both.
Note that the default bindings for Tcl/Tk have allowed you to pan
in canvases and text widgets (using the middle mouse button)
for as long as I can remember. And I seem to remember a Panner widget
for Motif (or perhaps Xt) even before that. I've found a great
place to put a panner button is in the lower right corner of the screen,
right in that unused space where the horizontal and vertical scrollbars
meet.
Summary:
* A panner is not a new idea.
* But a panner is a Good Thing.
* Scrollbars are also nice.
Keep those ideas coming...
--
D. Richard Hipp -- d...@acm.org -- http://www.hwaci.com/drh/
Chris Waters
Bowie J. Poag <b...@primenet.com> writes:
> A Proposal For The Complete Elimination Of Scrollbars From The Gnome Desktop
The "scrollball" proposal sounds interesting, but I'd rather see it in
an experimental system. I'd rather have Gnome give users more or less
what they expect. It's going to be tricky enough arguing with KDE and
CDE boosters without introducing controversial new widgets. At the
very least it should be optional.
However, I thought I'd take this time to mention another alternative,
which I've seen and used and liked a lot. A scroll-surface! The
whole face of the window can be grabbed and slid around with the
mouse! MicroEMACS has this feature in the DOS and OS/2 versions
(which lack scrollbars), and in the Windows version (where the
scrollbars are optional). It actually works very well, once you get
past the initial surprise. And it doesn't waste *any* screen real
estate.
Just a thought.
alt.os.linux removed from newsgroups (I thought it was dead?), as was
cola (this is hardly advocacy), and colda added. Any colda people
interested in the original "scrollball" proposal are invited to hunt
it down in .misc.
cheers
--
Chris Waters | Bill Gates: "We need room to innovate!"
cwa...@systems.DHL.COM |
xt...@dsp.net (personal) | Me: "Well, that would certainly be a change."
www.dsp.net/xtifr/ (web) |
Derek B. Noonburg
Bowie J. Poag <b...@primenet.com> writes:
> [proposal for a new scrolling widget...]
This seems like an interesting idea. I agree that scrollbars are not
necessarily the best way of moving around a larger area, and I would
be happy to see some alternatives.
But I have a few comments / questions. (This is from reading your
proposal only; maybe using a scrollball would answer my questions.)
It sounds like there is no way with a scrollball to move *exactly* one
line or *exactly* one page up or down. This is a very common
operation, and it seems like a major lack of the scrollball.
Also, a scrollball requires press-release-move-press-release to do
even the smallest motion. With a scrollbar, I can perform the most
common motions (page up/down, line up/down) with a single press-
release (click).
One advantage to a "positional" type of movement widget, as opposed to
a "motion" type, is that it provides the concept of moving *to* a
specific position. E.g., if I remember that I saw something about one
page before the end of the document, or right in the middle of the
document, with a scrollbar, I can drag the slider right there.
(Analogy: I can do the same thing by flipping to, e.g., a few pages
from the end of a printed book.) You mention microfilm viewers -- I
have the same problem with them: I always overshoot where I'm trying
to go. Imagine trying to navigate a document with a trackball or
joystick instead of a mouse: yuck. (Ok, maybe I'd get used to it, but
the whole point of a human-computer interface is to make the computer
get used to me, not the other way around.)
> In a web browser, web content can be made wider as well as longer, since
> the user's visual mobility within a window has increased to allow
> diagonal movement.
Please don't encourage this. If I'm reading anything very long, I
much prefer to take my hands off the mouse. Document viewers (more,
less, netscape, ...) all provide nice simple keys to move one page
down (or up). If I had to move sideways as well as up/down, I'd be
really annoyed.
Chris Waters <cwa...@systems.dhl.com> writes:
> However, I thought I'd take this time to mention another alternative,
> which I've seen and used and liked a lot. A scroll-surface! The
> whole face of the window can be grabbed and slid around with the
> mouse! MicroEMACS has this feature in the DOS and OS/2 versions
> (which lack scrollbars), and in the Windows version (where the
> scrollbars are optional). It actually works very well, once you get
> past the initial surprise. And it doesn't waste *any* screen real
> estate.
The disadvantage to this is that it requires a lot of mouse motion to
move long distances (press, drag, release, move mouse to other side,
press, drag, release, ...).
But I wonder if you could combine this with some sort of page-up/down
mechanism?
- Derek
Tim Smith
Bowie J. Poag <b...@primenet.com> wrote:
>(The following article was posted to the GNOME gui & development mailing lists.
>I'd appreciate any comments or criticisms about this idea.)
(1) With a traditional scrollbar, it is very convenient to move down the
document a page at a time by simply putting the mouse in the paging area,
and then simply clicking when I want to move a page. It doesn't seem that
this would be nearly as convenient with a scrollball.
(2) The position of the slider in a scrollbar tells me where I am in the
document, and on systems where the size of the sider depends on the fraction
of the document that is visible, I am told how much of the document is
available to scroll to. Scrollballs seem less convenient in this respect.
(3) It's not clear to me that, aside from the ability to change color to
tell you when you have hit the end, scrollballs don't give you anything that
you don't get by allowing one to click on the document and drag it around
the window.
--Tim Smith
Alan Shutko
Posting to GNOME list because I didn't see the original.
>>>>> "B" == Bowie J Poag <b...@primenet.com> writes:
B> o That scrollballs -completely- replace the presence of traditional
B> scrollbars. Don't even offer a choice between the old and the new;
I notice one important feature of scrollbars which has been completely
neglected by your analysis. It's a feature that scrollballs cannot
do.
Scrollbars do not only provide translational motion. They also
provide a visible display of the proportion of displayed area to total
area. By looking at the scrollbar, I can see if the text displayed is
all of the text that there is, half of the text, or even just a very
small portion of it.
Additionally, the proportional display of a scrollbar allows you to do
exact placement of the scrollbar to given areas. For example, if I
want the second quarter of the document, I can put a scrollbar there
quickly, but it seems I would have to keep watching the text to do so
with a scrollball. That ignores stuff like the athena widget's
ability to middle click on a spot and go there immediately.
To use an analogy, it's as if you replaced a mouse on a computer with
an analog joystick. Better for some limited manipulations, but not
nearly the same thing.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
I've always considered statesmen to be more expendable than soldiers.
Axel Boldt
Bowie J. Poag <b...@primenet.com> said:
Bowie> The scrollbar should behave as follows:
Bowie> 1) When a window first appears on the desktop, a scrollbar should be
Bowie> present; even when the likelyhood of it ever being utilized is
Bowie> relatively low.
Bowie> 2) When the content of a window exceeds its physical dimensions, the
Bowie> scrollball should then become available to the user. This is signaled
Bowie> with a simple color-change. (it lights up, or turns off according to
Bowie> availability)
Bowie> 3) At this point, the user may wish to click on the scrollball.
Which sucks. The thing I find most annoying about scrollbars is that I
have to move the mouse pointer from where it is constantly needed (the
main part of the window) to the border, drag, and move it bag. Under
your proposal, I still have to move to the scrollball and back.
IMHO, scrolling should be done from within the window. Acrobat's pdf
reader has a feature where the cursor turns into a hand when you use
the middle button; you can then drag the window's contents
around. Tk's text widget has a similar functionality. MS's Internet
Explorer 4.0 has a slightly different new feature which also allows
scrolling without moving to the border, using the middle button. The
advantage of IE's approach is that you can actually have the page
scroll at a preset low speed without any further mouse interaction,
which is nice for reading long web pages; it is slightly less
intuitive than the hand approach though. All of the above are vastly
more user friendly than scrollbars or scrollballs. I hope GNOME
incorporates a similar solution. And no, I don't advocate scrapping
scrollbars altogether, because they give clues about the length of a
document and the relative position inside it.
Axel
James Youngman
>>>>> "Bowie" == Bowie J Poag <b...@primenet.com> writes:
Bowie> The "scrollball" concept, as it became known, emerged during
Bowie> an late-night core development session on September 27th,
Bowie> 1997.
Bowie> The "scrollball" is meant as a COMPLETE and -TOTAL-
Bowie> replacement for scrollbars. It is both more intuitive, easier
Bowie> to use, and more versatile than traditional scrollbar
Bowie> methodology. The entire sum purpose of no less than six
Bowie> individual window components (horizontal scrollbar, vertical
Bowie> scrollbar, up arrow, down arrow, left arrow, right arrow)
Bowie> have been encapsulated into one primary window component
Bowie> capable of bound or unbound unidirectional scrolling of
Bowie> unlimited proportion.
These items are also known as "navigation buttons".
Greg Hughes
You can use different colour queues to achieve this effect with a
scrollball. Some gind of colour gradient effect would also enhance the look
of the scrollball.
- Greg Hughes
Alan Shutko wrote in message ...
Conrad Sanderson
On 16 Feb 1998 11:07:00 -0700, Bowie J. Poag <b...@primenet.com> wrote:
>(The following article was posted to the GNOME gui & development mailing lists.
>I'd appreciate any comments or criticisms about this idea.)
>
> A Proposal For The Complete Elimination Of Scrollbars From The Gnome Desktop
>
< (...)
What about seeing _where_ the user is in the document which scrollbars provide
in an intuitive manner. Proportional scrollbars also show how much space
the current view takes in relation to the rest of the document. None of these
things can be done with the scrollball. The scrollball is an interesting idea
that should be used in addition to scrollbars, but by no means replace it.
Eugene O'Neil
In article <34E8EA1D...@acm.org>, "D. Richard Hipp" <d...@acm.org> wrote:
>Bowie J. Poag wrote:
>> A Proposal For The Complete Elimination Of Scrollbars From The Gnome Desktop
>> Questions or comments?
>
>Been there. Done that. Yes a "panner" button or widget of some kind is
>much much easier to use than a scrollbar. I recommend having one. But
>scrollbars are also useful as a visual indication of the overall size
>and
>your current position within the object being scrolled or panned. I
>think
>you need both.
Some X window managers come with virtual-desktop panners that I think give a
better "feel" for current position than scroll-bars. They look like a "box
within a box", where the outer box represents the viewable area (scaled to
fit the panner exactly), and the inner box represents the currently viewed
area (using the same scale). Thus, as you scroll around, you can watch the
little viewable area move and know exactly where you are.
Anyway, I agree that it isn't a new idea, but it is a good idea.
-Eugene
Alex Yung
Bowie J. Poag (b...@primenet.com) wrote:
: (The following article was posted to the GNOME gui & development mailing lists.
: I'd appreciate any comments or criticisms about this idea.)
: -------------------------------------------------------------------------------
: A Proposal For The Complete Elimination Of Scrollbars From The Gnome Desktop
[removed]
: Questions or comments?
I am not sure about the elimination of scrollbars. But this is how
I would like the operation of the scrollball. I would like to see 2
colored circles (one within the other). The outer circle is fixed and
the inner is the ratio which is proportional to the size of the content.
Once my mouse is inside the outer circle, the content should be moved
relative to my mouse movement. The user should be able to configure the
display ratio of the circles and the sensitivity of the relative movement
by 1 mouse click which brings up the preference menu.
I also would like to have 8 direction arrows such as north, south,
north-east etc... If the mouse is on any of the arrows, it should be in
auto-scroll mode so that this would work with text and graphics. The
user can set the scroll rate via the previous preference menu. There
should also have an option of scrolling by 1/2 or full page such that
the screen is clear before new display on text object or smooth scroll
for graphic.
It should not require any mouse click to activate the movement. It
should just start doing it as soon as the mouse is on the navigational
symbol for some specified interval such as the auto-raise option. Too
many types of mouse click is complicated. If the scrollball operates as
I have mentioned, I believe my 4 years old can use the mouse very
effectively.
Larry Daffner
An interesting proposal, however, there are a few issues which I have
with the proposal.
o) Scrollbars not only give me motion control, but visual cues as
well. I can tell by glancing at a scrollbar approximately how large
the item being viewed is, and approximately where I am in it. Your
scrollball would eliminate those visual cues, and probably require
additional bolted-on, and probably less intuitive indicators.
o) There's a reason why status quo tends to be retained, especially in
GUIs. People are familiar with the old controls. They know what
they do, they know how to use them, they feel comfortable with
them.
o) We generally view information across then down. When dealing with
text, scrolling diagonlly gains you nothing. In a graphic image,
granted, it may make sense. It just seems like it would be much
better to keep the old, obvious, familiar interface, and make the
new one available for application writers. As it becomes more
known and less foreign, then perhaps it can replace scrollbars in
applications where it makes sense.
-Larry
--
| Larry Daffner - Software Engineer | email: ldaf...@rsn.hp.com |
| Hewlett Packard STO | |
Technology is a way of organizing the universe so that man
doesn't have to experience it. --Max Frisch
Chris Waters
der...@aimnet.com (Derek B. Noonburg) writes:
[comments on the original "scrollball" proposal elided]
> Chris Waters <cwa...@systems.dhl.com> writes:
> > However, I thought I'd take this time to mention another alternative,
> > which I've seen and used and liked a lot. A scroll-surface! The
> > whole face of the window can be grabbed and slid around with the
> > mouse! MicroEMACS has this feature in the DOS and OS/2 versions
> > (which lack scrollbars), and in the Windows version (where the
> > scrollbars are optional). It actually works very well, once you get
> > past the initial surprise. And it doesn't waste *any* screen real
> > estate.
> The disadvantage to this is that it requires a lot of mouse motion to
> move long distances (press, drag, release, move mouse to other side,
> press, drag, release, ...).
No. I forgot to mention this -- in the MicroEMACS version, to scroll
long distances, you just drag to (or off) the edge of the frame and
you get continuous scrolling. Under X, it might require some
adjustments to the focus-follows-mouse mechanism, i.e. the window
doesn't release focus while you're in the middle of a scrolling
operation. Otherwise it would be really annoying. But if that can be
done, I think dragging the surface could be a very attractive option.
OC, you still want to have drag for marking a region. But that's
currently done with both mouse-1 and mouse-3 in X, which is a little
redundant. I think that mouse-3 could effectively be used for
surface-scrolling.
> But I wonder if you could combine this with some sort of page-up/down
> mechanism?
I wouldn't have it any other way! Or do you mean something beyond
keystrokes? I'm a definite believer in making all movement commands
available through the keyboard. Movement widgets can be handy, but I
hate when I *have* to use them.
Alan Shutko
>>>>> "E" == Eugene O'Neil <eug...@cs.umb.edu> writes:
E> Some X window managers come with virtual-desktop panners that I
E> think give a better "feel" for current position than
E> scroll-bars.
Right, but they are only used in a few sections where scrollbars are
applicable. For example, the panner for my 200 page LaTeX document
would be quite large indeed.
Basically, I think that some widgets are better than others for some
things. A scrollball would be great for some applications, but I
don't see it as viable to replace scrolbars or panners.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
You will be advanced socially, without any special effort on your part.
Alan Shutko
>>>>> "G" == Greg Hughes <Gr...@mgisoft.com> writes:
G> You can use different colour queues to achieve this effect with a
G> scrollball. Some gind of colour gradient effect would also enhance
G> the look of the scrollball.
Could you elaborate? I listed two different effects in my post:
1. Proportion of displayed to total area. I could see you might
somehow make the color of the ball reflect the amount. I don't think
it would make much sense, but I'd have to see it first. However, I
don't think there's a way to show _where_ in the total area the
current screen is located.
2. Quick placement to areas. I don't see how this is addressed by
color at all.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
How much does she love you? Less than you'll ever know.
Derek B. Noonburg
Chris Waters <cwa...@systems.dhl.com> writes:
> No. I forgot to mention this -- in the MicroEMACS version, to scroll
> long distances, you just drag to (or off) the edge of the frame and
> you get continuous scrolling.
But then you're back to the "motion-based" scrolling thing. I've
never seen a continuous scrolling system that I liked. They go too
fast, or they go too slowly, or they have some acceleration-after-a-
certain-period-of-time algorithm, which is even worse because it
always happens exactly when I don't want it to. Maybe this is just
me, I dunno.
> OC, you still want to have drag for marking a region. But that's
> currently done with both mouse-1 and mouse-3 in X, which is a little
> redundant. I think that mouse-3 could effectively be used for
> surface-scrolling.
Personally, I like having mouse-1 do select, mouse-2 do scroll,
mouse-3 do a popup menu.
But gnu emacs, at least, lets you bind the mouse buttons any way you
want, and I expect other decent editors are similarly flexible, so
this won't be a problem.
> > But I wonder if you could combine this with some sort of page-up/down
> > mechanism?
>
> I wouldn't have it any other way! Or do you mean something beyond
> keystrokes? I'm a definite believer in making all movement commands
> available through the keyboard. Movement widgets can be handy, but I
> hate when I *have* to use them.
Yes, definitely -- everything should be available on the keyboard (or
I likely won't use the software at all). But I like to be able to go
into "mouse mode" occasionally, and then I'll want to be able to
scroll one page at a time, etc., using the mouse. Scroll bars *are*
useful, even if they aren't optimal. I'd rather have them than
nothing.
How about this: if the mouse is dragged with the scroll button (2 or 3
- whichever) pressed, do the pan-scroll (including continuous scroll
when outside the window if you like - but I'll never use it :-)). So
far, this is just like your description of MicroEMACS. But if the
scroll button is *clicked* in the lower half of the window, scroll one
page down. If it's clicked in the upper half, scroll one page up.
(The drag/click distinction is already used, e.g., for selecting text
vs. following a link in netscape.) You could also divide the window
into four pieces to add left/right scrolling. And you might even be
able to add regions (the 10% nearest the top and bottom edges?) that
cause a single-line scroll. This also solves another problem with
scroll bars -- aiming the mouse into that little strip is a nuisance.
Aiming for the bottom/top half of the window is easy.
If I wasn't so lazy, I suppose I could write some elisp code to
implement this in gnu emacs.
Now we can stop wasting screen real estate on scroll bars/balls
entirely.
(Aside: where would a scroll ball be located in the window? Fitting
thin horizontal and vertical strips is easier than finding a place for
a square (or round) widget. And I've always wondered what to do with
that little leftover square in the lower corner between the
scrollbars.)
Oops, this whole scroll button idea violates my requirement of being
able to move to a specific position, e.g., "a little bit before the
end". Maybe ctrl-button-2 (substitute your favorite mouse button and
modifier key) could work similarly to normal-button-2, but with a
position-based range. That is, ctrl-clicking 10% from the top edge
would move to the position 10% from the top of the document.
Similarly, ctrl-dragging would pan across the entire document.
I'm always looking for ways to make PC and Mac users envious of my
extra mouse button(s)... :-)
- Derek
Bill Currie
Bowie J. Poag wrote:
[scrollball stuff]
> but figure it prominently in the general layout of each window as per the
> reccomendations listed above.
I think it's a cool concept. I'll certainly be immplementing
scrollballs in my own UIs (text and graphics (hmm, how to represent in
graphis mode). I've even got a project that can really benefit from
scrollballs (star map viewer).
Bill
--
Leave others their otherness
Patrick
re: visual cues ... very important.
Scroll Ellipse
I would suggest a Scroll Ellipse rather than a scroll ball (seeing as
you're assuming processor cycles to burn anyway :-).
The ellipse could 'morph' elongate/oblate to give a visual indication
of the proportional area of the window.
Patrick
__________
"It's better to have loved and lost than to never have seen Lost in Space"
-- Kelly Bundy quoting Chinese philosopher Unconcious
Eugene O'Neil
In article <m33ehic...@localhost.localdomain>, Alan Shutko <a...@acm.org> wrote:
>>>>>> "E" == Eugene O'Neil <eug...@cs.umb.edu> writes:
>
>E> Some X window managers come with virtual-desktop panners that I
>E> think give a better "feel" for current position than
>E> scroll-bars.
>
>Right, but they are only used in a few sections where scrollbars are
>applicable. For example, the panner for my 200 page LaTeX document
>would be quite large indeed.
No, the panner is always exactly the same size and shape: the total viewable
area of the document is scaled to fit. Then the area you can actually see,
scaled to the same dimensions, is highlighted in the panner. In a 200 page
document, the highlight would probably show up as a thin horizontal line
across the pager, at a vertical position that corrisponds to your actual
position in the document. Really it isn't much different from a
proportional scrollbar, especially if you make the pager tall and thin: the
biggest difference is that it shows both dimensions at once.
>Basically, I think that some widgets are better than others for some
>things. A scrollball would be great for some applications, but I
>don't see it as viable to replace scrolbars or panners.
I'm not sure about the scrollball as it was originally described here, but
certianly it is possible for SOMETHING to perform the same function as
scrollbars, and possibly even do a better job.
-Eugene
Chuck Bermingham
D. Richard Hipp <d...@acm.org> wrote in article
<34E8EA1D...@acm.org>...
> Bowie J. Poag wrote:
> > A Proposal For The Complete Elimination Of Scrollbars From The Gnome
Desktop
> > Questions or comments?
> scrollbars are also useful as a visual indication of the overall size
> and
> your current position within the object being scrolled or panned. I
[snip]
They're also useful as sliders with multiple increment capability; put a
vertical scrollbar over a counter, for example, and you have a slider. If
you click the top or bottom arrow, you get one-unit increments; if you
click and hold the slider, you have a "volume control" sorta thingy.
Clicking in the trough gets larger increments. I happen to like 'em better
than sliders, sometimes.
Another point: it seems to me that a panner should not engage immediately
you click on it; it should change the mouse pointer, then operate as a
panner when you drag the area being panned; then it shold turn off when you
click it again (assuming you *want* it to be a toggle. This is because the
panner might be in the lower-right corner of the physical screen, then how
do you pan downward and to the right? Personally, I like panners that let
me turn them on and off when the mouse is pointing straight at what I want
to move.
My $0.02.
Chuck Bermingham
>
> It should not require any mouse click to activate the movement. It
> should just start doing it as soon as the mouse is on the navigational
> symbol for some specified interval such as the auto-raise option. Too
> many types of mouse click is complicated. If the scrollball operates as
> I have mentioned, I believe my 4 years old can use the mouse very
> effectively.
>
Man--you were on a roll, then you BLEW IT! No WAY do I want to see
mouse-positioning activate ANYTHING by default! If you want that to
happen, it should be a user-configurable option that is *not* on by
default. You are locking out sight-impaired and other disabled people with
that approach.
I am 'way more in favor of a modal panner that only works when a mouse
button is down.
Chuck Bermingham
Patrick <patr...@autobahn.mb.ca> wrote in article
<34eaecb8...@news.autobahn.mb.ca>...
> re: visual cues ... very important.
>
> Scroll Ellipse
>
> I would suggest a Scroll Ellipse rather than a scroll ball (seeing as
> you're assuming processor cycles to burn anyway :-).
>
> The ellipse could 'morph' elongate/oblate to give a visual indication
> of the proportional area of the window.
>
depending on the amount of stuff to scroll. If it's an ellipse, then the
thingy can be a little circle. Then, if all the area is on-screen, there
are two circles; otherwise, there's a circle and an ellipse.
Alternatively, the outside is a square, and the inside is an ellipse. Then
(for instance) if the horizontal area is huge and the vertical area fits
within the window, the panner button had a skinny horizontal line in it.
Vertical hugeness gives a skinny vertical line. Both areas completely
visible gives a circle.
Christian Arlo Adamec
In comp.os.linux.misc Chuck Bermingham <berm...@concentric.net> wrote:
: I like the one with a little thingy in the middle that changes size
: depending on the amount of stuff to scroll. If it's an ellipse, then the
: thingy can be a little circle. Then, if all the area is on-screen, there
: are two circles; otherwise, there's a circle and an ellipse.
: Alternatively, the outside is a square, and the inside is an ellipse. Then
: (for instance) if the horizontal area is huge and the vertical area fits
: within the window, the panner button had a skinny horizontal line in it.
: Vertical hugeness gives a skinny vertical line. Both areas completely
: visible gives a circle.
The fact is, scrollbars are just more intuitive. People can see where they
are in a document and the proportion that the viewable area takes up
within the whole document. I agree with other posts that the Adobe Acrobat
sort of grab and move style is the way to go. Keep scrollbars for the
visual qeues they provide and allow grabbing of the document for easy
manipulation.
I don't think that thingys, circles, color gradients or ellipses are the
way to go at all; not at all intuitive. I don't think people want to learn
a whole new language of signs simply to navigate thier documents.
After all is said and done, it is good to see people are interested in
coming up with new ideas, maybe the answer is still out there.
--
===================================
Christian Adamec
University of Wisconsin - Milwuakee
ada...@uwm.edu
===================================
Chris Waters
der...@aimnet.com (Derek B. Noonburg) writes:
> Chris Waters <cwa...@systems.dhl.com> writes:
> > No. I forgot to mention this -- in the MicroEMACS version, to scroll
> > long distances, you just drag to (or off) the edge of the frame and
> > you get continuous scrolling.
> But then you're back to the "motion-based" scrolling thing. I've
> never seen a continuous scrolling system that I liked. They go too
> fast, or they go too slowly, or they have some acceleration-after-a-
> certain-period-of-time algorithm, which is even worse because it
> always happens exactly when I don't want it to. Maybe this is just
> me, I dunno.
These are all reasonable objections, as are the ones about the visual
cues which scrollbars provide. Which is presumably why MicroEMACS
provides (optional) scrollbars on those systems where scrollbar
widgets are available from the system.
Despite the original subject line (which I didn't write), I'm *not*
advocating the elimination of scrollbars. But do I think that making
them optional, and providing some alternatives is a decent idea.
> How about this: if the mouse is dragged with the scroll button (2 or 3
> - whichever) pressed, do the pan-scroll (including continuous scroll
> when outside the window if you like - but I'll never use it :-)). So
> far, this is just like your description of MicroEMACS. But if the
> scroll button is *clicked* in the lower half of the window, scroll one
> page down. If it's clicked in the upper half, scroll one page up.
> (The drag/click distinction is already used, e.g., for selecting text
> vs. following a link in netscape.) You could also divide the window
> into four pieces to add left/right scrolling. And you might even be
> able to add regions (the 10% nearest the top and bottom edges?) that
> cause a single-line scroll. This also solves another problem with
> scroll bars -- aiming the mouse into that little strip is a nuisance.
> Aiming for the bottom/top half of the window is easy.
Something like this sounds good. And yes, ease of aiming is one of
the things I really liked about the way MicroEMACS did this. It was
very addictive -- once you get used to it, you may find your
objections to continuous scrolling start to waver.
> Now we can stop wasting screen real estate on scroll bars/balls
> entirely.
They still provide important visual cues, and people are used to them
-- I think making them optional is best approach.
Now that the two of *us* are in basic agreement, the question becomes,
are we going to be able to convince anyone else? I've been hoping to
get involved in the Gnome project, but I've got a lot of stuff to
learn before I'll be of any use. Like gtk, and, for that matter, the
basic concepts of X programming. So, basically, I haven't got a whole
lot of leverage with the Gnome folks.
> (Aside: where would a scroll ball be located in the window?
Good question. And only one of many. I'm not sure I'm in favor of
the scroll ball idea. As I said before, it sounds like an interesting
concept for experimentation, but I'm not convinced it's ready for
prime-time yet. If ever.
> I'm always looking for ways to make PC and Mac users envious of my
> extra mouse button(s)... :-)
Absolutely! :-)
Alan Shutko
>>>>> "E" == Eugene O'Neil <eug...@cs.umb.edu> writes:
E> In article <m33ehic...@localhost.localdomain>, Alan Shutko
E> <a...@acm.org> wrote:
>>>>>>> "E" == Eugene O'Neil <eug...@cs.umb.edu> writes:
>>
E> Some X window managers come with virtual-desktop panners that I
E> think give a better "feel" for current position than scroll-bars.
>> Right, but they are only used in a few sections where scrollbars
>> are applicable. For example, the panner for my 200 page LaTeX
>> document would be quite large indeed.
E> No, the panner is always exactly the same size and shape: the total
E> viewable area of the document is scaled to fit.
Ouch. That would make it rather unusable. I can just see myself
trying to grab the tiny dot that is my current page so that it can
move.
The biggest thing about a panner is that the x and y have the same
aspect ratio as the document. For the whole my whole 200 page long
(but merely a page wide) document to show up in a panner, it becomes
long and thin if it keeps the same aspect ratio.
If you decide to make your panner tall and thin, you've suddnly lost
horizontal resolution which you wouldn't have lost with a dual
scrollbar setup, since dual scrollbars fit nicly around your document,
rather than requiring a large rectangular area for themselves.
E> I'm not sure about the scrollball as it was originally described
E> here, but certianly it is possible for SOMETHING to perform the
E> same function as scrollbars, and possibly even do a better job.
That's easier said than done. It's no problem to hypothesize the
existence of something better, but until it's been shown, that comment
is worthless.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
Idleness is the holiday of fools.
Paul Doherty
Alan Shutko wrote:
>
> >>>>> "G" == Greg Hughes <Gr...@mgisoft.com> writes:
>
> G> You can use different colour queues to achieve this effect with a
> G> scrollball. Some gind of colour gradient effect would also enhance
> G> the look of the scrollball.
>
> Could you elaborate? I listed two different effects in my post:
>
> 1. Proportion of displayed to total area. I could see you might
> somehow make the color of the ball reflect the amount. I don't think
> it would make much sense, but I'd have to see it first. However, I
> don't think there's a way to show _where_ in the total area the
> current screen is located.
How about use the mthod discussed earlier whereby the third mouse button
(or both mouse buttons on a 2-button mouse) are used to scroll the
document, with 2 colored-ball indicators at the right and at the bottom
(for example - one each at the top-right and bottom-right for the
vertical bar). Then these bars, upon intially opening a file, would
glow a certain color to indicate position in the file. For instance
when the file is first opened the top-right ball glows a solid red to
indicate you are at the top of the file, while the bottom-right ball
glows an intensity of green to indicate "how much" of the file is
below. Then as the scrolling takes place independent of the bars (using
the thrid mouse button) the balls glow changes through a range of red
and greens (with intermediate values being shades of orange). So in the
middle of the file you would be seeing two equal-intensity orange balls
on the vertical bar.
Dean Carpenter
In article <m3ra51x...@localhost.localdomain>, der...@aimnet.com (Derek B. Noonburg) wrote:
>Chris Waters <cwa...@systems.dhl.com> writes:
>
>> No. I forgot to mention this -- in the MicroEMACS version, to scroll
>> long distances, you just drag to (or off) the edge of the frame and
>> you get continuous scrolling.
>
>But then you're back to the "motion-based" scrolling thing. I've
>never seen a continuous scrolling system that I liked. They go too
>fast, or they go too slowly, or they have some acceleration-after-a-
>certain-period-of-time algorithm, which is even worse because it
>always happens exactly when I don't want it to. Maybe this is just
>me, I dunno.
The further the mouse is below the bottom of the window, the faster the
scroll. Keep the mouse right below the edge, and it just blips along one
line at a time. Move way down and it starts racing. There are a few
Winders95 apps that do it this way, and it works well.
--
Dean Carpenter de...@areyes.spam.com Remove the spam :)
94 TT :) Dean.Ca...@pharma.spam.com to reply.
Philo Vivero
On Mon, 16 Feb 1998, Tim Smith wrote:
>>(The following article was posted to the GNOME gui & development mailing lists.
>>I'd appreciate any comments or criticisms about this idea.)
>
>(1) With a traditional scrollbar, it is very convenient to move down the
>document a page at a time by simply putting the mouse in the paging area,
>and then simply clicking when I want to move a page. It doesn't seem that
>this would be nearly as convenient with a scrollball.
This is a good point. I can't think of any obvious paging mechanism with the
scrollball. All I can imagine is two buttons to either side of the scrollball
for paging or using right/left mouse clicks with no drag to do paging... Of
course, there are the pgUp/pgDn keys on most keyboards.
>(2) The position of the slider in a scrollbar tells me where I am in the
>document, and on systems where the size of the sider depends on the fraction
>of the document that is visible, I am told how much of the document is
>available to scroll to. Scrollballs seem less convenient in this respect.
Not an issue. Indicators can still be present.
>(3) It's not clear to me that, aside from the ability to change color to
>tell you when you have hit the end, scrollballs don't give you anything that
>you don't get by allowing one to click on the document and drag it around
>the window.
To me, this is the most important criticism of both scrollbars and any other
"window decoration" scrolling mechanism. There is no excuse for not allowing the
mouse to drag the document around, which is probably the single most intuitive
method of moving things around (And the fastest, in my experience).
Even on a MacIntosh single-button mouse, you could simply assign a keyboard key
to activate hand-slide mode. Multi-button mice could, of course, allow for the
buttons to toggle into hand-slide mode.
The most disappointing development in physical UI seems to me to be the mouse,
as it takes the hands away from the extremely important keyboard positions. What use
is a computer without keyboard entry? (I know, you envision a screen with many
checkboxes and radio buttons, but even then, keyboard entry is much faster)
I, for one, use the NUForm keyboard from Adesso, which has a Glidepoint touchpad
right below the spacebar, allowing me to move the mouse cursor and continue to
type almost simultaneously. A physical roller ball would probably be even
better.
If you're designing UI, keyboard control of the entire environment is important
not because some people don't have mice, but because it's both faster, and some
people prefer the non-mouse interface, which was where I was HOPING the original
poster was headed with his proposition.
-- Philo Vivero
KDE Desktop Environment (www.kde.org)
Derek B. Noonburg
dean.ca...@pharma.com.no-spamm (Dean Carpenter) writes:
I've used things like this too. The problem is that there's no way to
move exactly one page up or down. I'd argue that moving one page (or
window-ful) at a time is one of the most common operations. Note that
all reasonable implementations of scroll bars support this.
But that's ok -- it's easy to make both of us happy:
drag within window: pans the window
drag outside window: variable speed continuous scrolling
(just like you described)
click in top half of window: page up
click in bottom half of window: page down
(or divide the screen into four triangular quadrants for page
up/down/left/right)
click in top 10% of window: line up
click in bottom 10% of window: line down
(separating the line up/down from the page up/down may prove to be
too annoying - some experimentation will be needed here)
As I mentioned before, having different functions for click and drag
is common (e.g., selecting text vs. following a link), so all all of
this works on one mouse button - pick your favorite.
- Derek
Bryan Chan
Alan Shutko wrote:
> The biggest thing about a panner is that the x and y have the same
> aspect ratio as the document. For the whole my whole 200 page long
> (but merely a page wide) document to show up in a panner, it becomes
> long and thin if it keeps the same aspect ratio.
In the case of a document viewer/editor, where the document is many
hundreds of pages long, you use a different control for the
page-flipping. Imagine holding a 20-foot scroll of fax paper fresh from
your fax machine; it isn't very convenient, is it? The same holds true
with a document viewer/editor. IMHO using a scrollbar or a panning
system for the *entire* 200 pages is wrong; you should use a panner for
one single page, and use, for example, a curled-corner metaphor (like
the NeXTStep Notebook.app; see the following URL) for page-flipping.
There is a web page on Notebook.app:
http://www3.pair.com/mccarthy/nextstep/reviews/NoteBook/Review_of_NoteBook.htmld/
Bryan Chan______________________________________________________________
bryan...@utoronto.ca ch...@ecf.utoronto.ca
ch...@ugsparc0.eecg.utoronto.ca bg...@torfree.net
Dan Newcombe
On Thu, 19 Feb 1998 09:49:01 GMT, Paul Doherty <nu...@nospam.net> wrote:
>How about use the mthod discussed earlier whereby the third mouse button
>(or both mouse buttons on a 2-button mouse) are used to scroll the
Would really suck if you had an actual use for the third mouse button.
>document, with 2 colored-ball indicators at the right and at the bottom
>(for example - one each at the top-right and bottom-right for the
>below. Then as the scrolling takes place independent of the bars (using
>the thrid mouse button) the balls glow changes through a range of red
>and greens (with intermediate values being shades of orange). So in the
>middle of the file you would be seeing two equal-intensity orange balls
>on the vertical bar.
Hmm...Gee is that more redish and I'm only 45% through, or is it more greenish
and i'm 54% through? Also, this would bite in a big way on a greyscale
monitor.
--
Dan Newcombe |"Somewhere along the way we exchanged our dreams
newc...@mordor.clayton.edu | for selfish pride" -Fates Warning, The 11th Hour
Dan Newcombe
On 20 Feb 1998 15:42:02 GMT, Des Herriott <d...@corp.netcom.net.uk> wrote:
>In article <6ccbov$1nn$1...@goblin.uunet.ca>,
> "Greg Hughes" <Gr...@mgisoft.com> writes:
>> You can use different colour queues to achieve this effect with a
>> of the scrollball.
>I'd argue against using colour as an instrinsic part of a user-interface
>for two reasons:
>1) What about partially sighted and colour-blind people?
>2) What about when I'm using a monochrome display?
The idea of the scrollball sounds cool...but I agree that the color thing
has some serious drawbacks. However, what if the ball had a line to indicate
where it was in the file. As you scroll through, the line moves, as if the
ball was rotating it's pitch. Think of the level indicator on aircraft
controls - something like that. It could also be a colored ball so that
you can please both camps at once.
Alan Shutko
>>>>> "B" == Bryan Chan <bryan...@utoronto.ca> writes:
B> In the case of a document viewer/editor, where the document is many
B> hundreds of pages long, you use a different control for the
B> page-flipping.
Right, it's called a scrollbar.
B> IMHO using a scrollbar or
B> a panning system for the *entire* 200 pages is wrong; you should
B> use a panner for one single page, and use, for example, a
B> curled-corner metaphor (like the NeXTStep Notebook.app; see the
B> following URL) for page-flipping.
Sure, if I only want to flip page by page. What if I want to move to
a place around 25% from the end of the document? A scrollbar can do
this easily. What if I want to see about how large this document is?
A page-flipper isn't going to show me, but a scrollbar is.
The dual panner/page flipper is also only right if pages are defined
in a document. For example, my 200 pg LaTeX document consists of
18,000 lines of text. Where are the pages?
Pageless media are important because source code, email, and web pages
are all pageless.
Yes, there are other ways I have already of maneuvering... I can do
searches, I can choose the section of the document and move right
there, but often I know approximately where something is in the
document and can move directly. It's just like opening a book to the
approximate page of something instead of going to the TOC. It's a
useful thing which people seem to be ignoring.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
Man who sleep in beer keg wake up sticky.
Alan Shutko
>>>>> "D" == Dan Newcombe <newc...@mordor.clayton.edu> writes:
D> The idea of the scrollball sounds cool...but I agree that the color
D> thing has some serious drawbacks. However, what if the ball had a
D> line to indicate where it was in the file.
That's not very much resolution to show where you are and how much the
screen is displaying.
It also doesn't manage to cover the ability of a scroll-bar to place
the document (almost immediately) 1/4 of the way into a file.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
In case of atomic attack, all work rules will be temporarily suspended.
David E. Fox
In article <m367mau...@localhost.localdomain>, Alan Shutko wrote:
>this easily. What if I want to see about how large this document is?
>A page-flipper isn't going to show me, but a scrollbar is.
And I think scrollbars are too imprecise for this. If you're viewing
(or especially editing) said 200-page LaTeX document, often you already
have an idea where in the text to go, and you know that it might reside
"near the end" or whereever, but go ahead and use the scrollbar, and I'll
guarantee you'll end up too far ahead of where you want to go or too
far behind, and you'll have to pgup/pgdn at least a few times.
There is much niceness in going to absolute lines in vi or even better,
going to a particular phrase or what have you (/word in more/vi). And
somewhat frequently, you know whereabouts in the file you need to
go to edit or view.
>in a document. For example, my 200 pg LaTeX document consists of
>18,000 lines of text. Where are the pages?
The pages are there if you view the output with xdvi or gv. Of course,
they don't exist in the raw ASCII. So, type 16000G in vi. Much faster
than using a scrollbar.
>Alan Shutko <a...@acm.org> - By consent of the corrupted
>Man who sleep in beer keg wake up sticky.
--
------------------------------------------------------------------------
David E. Fox Tax Thanks for letting me
df...@belvdere.vip.best.com the change magnetic patterns
ro...@belvedere.sbay.org churches on your hard disk.
-----------------------------------------------------------------------
Alan Shutko
>>>>> "D" == David E Fox <df...@belvdere.vip.best.com> writes:
D> There is much niceness in going to absolute lines in vi or even
D> better, going to a particular phrase or what have you (/word in
D> more/vi). And somewhat frequently, you know whereabouts in the file
D> you need to go to edit or view.
The part of the post that you didn't quote explained I'm quite aware
of methods like that (and even better ones which aren't available in
vi). However, there are many times when I use the scrollbar since
it's good enough. There's no good reason to take that ability away.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
Perfect day for scrubbing the floor and other exciting things.
Paul Doherty
Dan Newcombe wrote:
>
> On Thu, 19 Feb 1998 09:49:01 GMT, Paul Doherty <nu...@nospam.net> wrote:
> >How about use the mthod discussed earlier whereby the third mouse button
> >(or both mouse buttons on a 2-button mouse) are used to scroll the
>
> Would really suck if you had an actual use for the third mouse button.
:-) (can also be emulated 3rd button for those with only 2)
> >document, with 2 colored-ball indicators at the right and at the bottom
> >(for example - one each at the top-right and bottom-right for the
> >below. Then as the scrolling takes place independent of the bars (using
> >the thrid mouse button) the balls glow changes through a range of red
> >and greens (with intermediate values being shades of orange). So in the
> >middle of the file you would be seeing two equal-intensity orange balls
> >on the vertical bar.
>
> Hmm...Gee is that more redish and I'm only 45% through, or is it more greenish
> and i'm 54% through? Also, this would bite in a big way on a greyscale
> monitor.
Why does it need to be that accurate? Are scroll bars (with changing
size scroll-grabbing item (whatever you call it :)) any more accurate
than this color-changing idea? The point is simply to give you a good
rough approximation of your location within the file, and I think my
version would work nicely (and look cool to boot!)...
Who uses greyscale anymore?
Alan Shutko
>>>>> "P" == Paul Doherty <nu...@nospam.net> writes:
P> Why does it need to be that accurate? Are scroll bars (with
P> changing size scroll-grabbing item (whatever you call it :)) any
P> more accurate than this color-changing idea?
Yes.
On at least two implementations of scrollbars, I can click on them and
know precisely which line will at the top or bottom of the screen.
Even taking the lowest common denominator, you have much more
accuracy, since people tend to be much better at judging proportional
distances than colors.
P> boot!)... Who uses greyscale anymore?
People with nice, cheap 21" monitors.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
The best laid plans of mice and men are held up in the legal department.
Scott Maxwell
Paul Doherty <nu...@nospam.net> writes:
> Who uses greyscale anymore?
Not everyone can see colors. IIRC, about 8% of men and 1% of women
are color-deficient or color-blind.
--
-------------------------+-----------------------------------------------------
R H L U Scott Maxwell: | ``What is the sound of Perl? Is it not the sound of
E A I X s-max@ | a wall that people have stopped banging their
D T N ! pacbell.net | heads against?'' -- Larry Wall
Mark Lehrer
df...@belvdere.vip.best.com (David E. Fox) writes:
>> in a document. For example, my 200 pg LaTeX document consists of
>> 18,000 lines of text. Where are the pages?
>
> The pages are there if you view the output with xdvi or gv. Of course,
> they don't exist in the raw ASCII. So, type 16000G in vi. Much faster
> than using a scrollbar.
I think for vertical scrolling, you must have both.
But what I hate in Unix is the lack of horizontal scrolling. If I am
looking at a text file that is 300 characters wide (database dump for
example) I prefer something that can scroll horizontally instead of
the annoying auto-wrapping in emacs.
Rob Collins
I personally am in favor of optional scroll bars, and user-definable mouse operations: options are a
large part of what makes linux great for me.
In the case where the scroll bars are not present, you still NEED visual cues. There are lots of
subsections which could falsely look unscrollable without -something-. An example is the Composition
window of Netscape (what I'm looking at now). The list of addresses to send to has a scroll bar, but
needn't. And the way it looks (to me, right now), it would be impossible to know that the area is
scrollable without the scroll bar (or some visual cue).
One (example) of a solution: You could have a small border, with a controlling corner-tab, wrap any
scrollable surface. If the mouse floats for some length of time over the control tab, a somewhat
larger control box pops-up. It is a small 4-arrowed movement control, with a central on/off button
for short vs. long scrolling.
Derek B. Noonburg wrote:
[snip!]
> drag within window: pans the window
> drag outside window: variable speed continuous scrolling
> (just like you described)
> click in top half of window: page up
> click in bottom half of window: page down
> (or divide the screen into four triangular quadrants for page
> up/down/left/right)
That sounds necessary, if you want to avoid requiring horizontal scroll bars.
> click in top 10% of window: line up
> click in bottom 10% of window: line down
> (separating the line up/down from the page up/down may prove to be
> too annoying - some experimentation will be needed here)
I think I see a conflict. The variable speed drag operations require dragging outside the window (an
excellent idea I really loved on the old NeXT boxes back at college, but there it was applied to the
scroll bars), which requires focus to stay with the window. I would expect clicking or long delays
to switch focus; I guess a possible alternative (which avoids my conflict) is to have focus switch by
mouse movement, but have mouse operations (the drag operation in particular) interrupt focus
checking.
It seems to me the line up/line down page up/page down clicks are better suited to an environment
where focus goes with the mouse. Because if focus doesn't go with the mouse, you'd be page-up'ing or
line-down'ing when you mean to shift focus. Or, if focus only switches after a long float, you must
float your mouse (just, say, for a half-second; if that doesn't sound long, try it) over the window
desired to be in focus -- which seems just as annoying to the end-user.
(Am I off my rocker?)
Alan Shutko
>>>>> "M" == Mark Lehrer <ed...@dux.raex.com> writes:
M> But what I hate in Unix is the lack of horizontal scrolling. If I
M> am looking at a text file that is 300 characters wide (database
M> dump for example) I prefer something that can scroll horizontally
M> instead of the annoying auto-wrapping in emacs.
Emacs can do that. XEmacs even has a horizontal scrollbar.
--
Alan Shutko <a...@acm.org> - By consent of the corrupted
Sin is a choice...not a genetic predisposition.
Martti Halminen
Mark Lehrer wrote:
>
> But what I hate in Unix is the lack of horizontal scrolling. If I am
> looking at a text file that is 300 characters wide (database dump for
> example) I prefer something that can scroll horizontally instead of
> the annoying auto-wrapping in emacs.
If you are running emacs, take a look at the Info nodes about
"Horizontal scrolling" and "Continuation lines"
--
________________________________________________________________
^. Martti Halminen
/ \`. Design Power Europe Oy
/ \ `. Tekniikantie 12, FIN-02150 Espoo, Finland
/\`. \ | Tel:+358 9 4354 2306, Fax:+358 9 455 8575
/__\|___\| Mailto:Martti....@dpe.fi http://www.dpe.fi
Derek B. Noonburg
Rob Collins <r...@NOSPAMintr.net> writes:
> I personally am in favor of optional scroll bars, and user-definable
> mouse operations: options are a large part of what makes linux great
> for me.
Agreed.
> In the case where the scroll bars are not present, you still NEED
> visual cues.
Several people have pointed this out. I completely missed it in my
original post. So yes, I agree that some sort of visual cue is very
helpful in places where scrollbars are currently used. One
possibility is using very narrow borders -- wide enough to be easily
visible, but not necessarily wide enough to be easy to click on. (I
think someone else has mentioned this, too.) On the other hand,
scroll bars really don't take up *that* much screen space and people
are used to them...
I still like my clicking idea (as an optional addition to scroll bars
and various key strokes).
> I think I see a conflict. The variable speed drag operations
> require dragging outside the window (an excellent idea I really
> loved on the old NeXT boxes back at college, but there it was
> applied to the scroll bars), which requires focus to stay with the
> window. I would expect clicking or long delays to switch focus; I
> guess a possible alternative (which avoids my conflict) is to have
> focus switch by mouse movement, but have mouse operations (the drag
> operation in particular) interrupt focus checking.
Um, I'm not sure I see the problem. I'm using fvwm at the moment, and
if you click in a window and keep the mouse button pressed, the window
keeps the focus no matter where the mouse is dragged. I assume other
window managers do the same. (Maybe this is what you meant by having
drag interrupt focus checking?)
> It seems to me the line up/line down page up/page down clicks are
> better suited to an environment where focus goes with the mouse.
> Because if focus doesn't go with the mouse, you'd be page-up'ing or
> line-down'ing when you mean to shift focus.
Again, I'm not sure what you mean. My suggestion was to use the
middle mouse button (but user-configurable, of course) for all of
these scrolling operations. If you use the left button for focus,
there's no problem. (Personally, I use pointer-in-window focus, not
click-to-focus.)
> Or, if focus only switches after a long float, you must float your
> mouse (just, say, for a half-second; if that doesn't sound long, try
> it) over the window desired to be in focus -- which seems just as
> annoying to the end-user. (Am I off my rocker?)
Yes, delay-based interfaces are evil and should be shot on sight.
(Try renaming a file in the Windows 95 Explorer without
double-clicking by mistake. Arrrgh.)
- Derek
Steve Mading
Mark Lehrer (ed...@dux.raex.com) wrote:
: df...@belvdere.vip.best.com (David E. Fox) writes:
: >> in a document. For example, my 200 pg LaTeX document consists of
: >> 18,000 lines of text. Where are the pages?
: >
: > The pages are there if you view the output with xdvi or gv. Of course,
: > they don't exist in the raw ASCII. So, type 16000G in vi. Much faster
: > than using a scrollbar.
: I think for vertical scrolling, you must have both.
: But what I hate in Unix is the lack of horizontal scrolling. If I am
: looking at a text file that is 300 characters wide (database dump for
: example) I prefer something that can scroll horizontally instead of
: the annoying auto-wrapping in emacs.
What the hell does that have to do with Unix?
Some apps scroll sideways, some wrap around. Emacs wraps.
--
Steve Mading: mad...@execpc.com http://www.execpc.com/~madings
Chris Waters
mad...@earth.execpc.com (Steve Mading) writes:
> Mark Lehrer (ed...@dux.raex.com) wrote:
> : But what I hate in Unix is the lack of horizontal scrolling. If I am
> : looking at a text file that is 300 characters wide (database dump for
> : example) I prefer something that can scroll horizontally instead of
> : the annoying auto-wrapping in emacs.
> What the hell does that have to do with Unix?
> Some apps scroll sideways, some wrap around. Emacs wraps.
What the hell does that have to do with Unix *or* Emacs? Some apps
scroll, some wrap, Emacs can do either.
John Ripley Culp
der...@aimnet.com (Derek B. Noonburg) writes:
> Um, I'm not sure I see the problem. I'm using fvwm at the moment, and
> if you click in a window and keep the mouse button pressed, the window
> keeps the focus no matter where the mouse is dragged. I assume other
> window managers do the same. (Maybe this is what you meant by having
> drag interrupt focus checking?)
>
This is not a window-manager issue. Under X when an application requests
button press and button release events for a certain window, the server
will automatically make an active grab on that window when a mouse button
is pressed. This means that at the moment you press a mouse button with
the pointer inside a window which has both event masks set, all the button
events will be sent only to that window untill a corresponding button
release happens. (note: this is over-simplified).
I've looked through some of my X books, and although I have not been able
to conferm this, I am pretty sure that during this automatic active grab,
no other applications recieve pointer events (motion, crossing, focus, etc.).
This would mean between the button press and release events no other
applications (including the window manager) know that the pointer has left
the current application window, so of course no foucs change would occur.
________________________
John R. Culp
gt7...@prism.gatech.edu
Rob Collins
I just want to apologize in advance for not using the correct words at all
the right places. "mouse action" is meant to mean some mouse interrupt.
and interrupt pairs are a set of two mouse actions, which are assumed in
this context to always send output to the same window.
Derek B. Noonburg wrote:
> Rob Collins <r...@NOSPAMintr.net> writes:
>
> > In the case where the scroll bars are not present, you still NEED
> > visual cues.
>
> Several people have pointed this out. I completely missed it in my
> original post. So yes, I agree that some sort of visual cue is very
> helpful in places where scrollbars are currently used. One
> possibility is using very narrow borders -- wide enough to be easily
> visible, but not necessarily wide enough to be easy to click on. (I
> think someone else has mentioned this, too.) On the other hand,
> scroll bars really don't take up *that* much screen space and people
> are used to them...
Having scroll bars or not, as relates to desktop real estate, is a fairly
small issue. The distinctiveness of the desktop is mostly at stake here.
But I'd also entertain the notion that the scrollbar-less version of the
windows is somehow more intuitive or embracing to the some users.
> > I think I see a conflict. The variable speed drag operations
> > require dragging outside the window (an excellent idea I really
> > loved on the old NeXT boxes back at college, but there it was
> > applied to the scroll bars), which requires focus to stay with the
> > window. I would expect clicking or long delays to switch focus; I
> > guess a possible alternative (which avoids my conflict) is to have
> > focus switch by mouse movement, but have mouse operations (the drag
> > operation in particular) interrupt focus checking.
>
> Um, I'm not sure I see the problem. I'm using fvwm at the moment, and
> if you click in a window and keep the mouse button pressed, the window
> keeps the focus no matter where the mouse is dragged. I assume other
> window managers do the same. (Maybe this is what you meant by having
> drag interrupt focus checking?)
That was what I was referring to. I believe I read in an earlier post
someone make reference to the X server needing to be altered to look for
mouse action pairs, so I assumed (always a bad thing to do). My
apologies, that was unnecssarily muddying the waters, I suppose.
> > It seems to me the line up/line down page up/page down clicks are
> > better suited to an environment where focus goes with the mouse.
> > Because if focus doesn't go with the mouse, you'd be page-up'ing or
> > line-down'ing when you mean to shift focus.
>
> Again, I'm not sure what you mean. My suggestion was to use the
> middle mouse button (but user-configurable, of course) for all of
> these scrolling operations. If you use the left button for focus,
> there's no problem. (Personally, I use pointer-in-window focus, not
> click-to-focus.)
Since focus follows the mouse (except in mouse action-mouse release paired
interupts), there really isn't a problem.
I was assuming this wasn't the case. In such a system, you would use
timing or clicking to change focus. This is a bad solution, though, since
clicking on the window will almost certainly shift its view. But, again,
I don't think it is an issue since the x server acts in exactly the
fashion I assumed it did not.