32265 - Jump-scroll should indicate already-seen area

Status: RESOLVED WONTFIX

(Core :: XUL, enhancement, P3)

Description

[cmiller]

It's happened to you, if you use the keyboard to scroll through long texts:

You're reading along in some long page, using page-down to jump down a
screen-full occasionally.  The problem is, when you jump, it's not like turning
a page in a book, where there's a definite point at which you should pick up
after the page-turn -- the top line.

Instead, you must vgrep through the top few lines of the new page, looking for
the last part that sounds familliar, and the first part that doesn't, and you
finally find it, and continue trying to parse the rest of the sentence into your
little noggin, but, damn! -- what was that sentence again?

The interface got in the way, and you dropped all the eggs you were juggling.

I propose an indicator that would illustrate the bottom of the window before a
large (>50% of screen) scroll, e.g..  In the more general case, for an event
that moves the viewable space a large amount (but not enough to leave all of
this screen), shade the current rendered screen, move the view-area, wait, and
unshade any shaded area a moment later.

This should be optional, and maybe even off by default.

(If this should be attached to another component, please reassign it.  Sorry.)

Comment 1

[troy]

Reassigning to Eric

Comment 2

[Sean Richardson]

Agreed 100%; given that this causes disorientation on *every* page longer
than one screenful, except where, by chance, there is no partial screenful 
after the last exact screenful, some sort of enhancement would be great.
Sometimes the disorientation is particularly annoying when the last line of 
the previous screenful is only a short distance from where it would be expected.

The enhancement proposed by [e-mail] would assuredly help,
but perhaps a more natural way to handle this would be to display the last,
partial screenful the same way that a document that is less than a screenful
in the first place is displayed: padded out to a full screenful with the body
background and/or bgcolor. Of course this padding would need to be recalculated
each time it was needed, since the user might have scrolled by a partial 
screenful somehwhere in the middle of the document in the meantime. This
could also mean that the top of the document could appear partway down the
topmost screenful, in the same circumstance, which some might object to.

Exactly how the already-seen portion is handled, on a jump-scroll to an end of
a document that will not fill out a screenful, is less important, though, than
preventing disorientation.

Updating QA contact and Component to match bug 11751, "Page down scrolls too 
far", which is about getting jump-scrolling right in the middle part of a
document at least two screenfuls long.

Comment 3

[Eric Vaughan]

Very creative. This sounds like something that should be discussed in the news 
group. But lets worry about it after beta2.

Comment 4

[Peter Trudelle]

Mass move of all M20 bugs to M30.

Comment 5

[Peter Trudelle]

Mass move of M20 bugs to M30

Comment 6

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 7

[Simon Fraser [no longer active]]

Isn't it enough to simply repeat the last line of text, which most applications 
(on Mac at least) do currently? See also bug 11751.

Comment 8

[Blake Ross]

I agree that this is a major problem, and it makes scrolling using page dn/up 
nearly impossible because you keep getting disoriented.  -> UI Design

Comment 9

[Sean Richardson]

  > Isn't it enough to simply repeat the last line of text, which most 
  > applications (on Mac at least) do currently? [Windows, too]
Enough, maybe, but this is an enhancement request, looking for better, not
nominal, usability. 

To get the sense of it, imagine a text-heavy webpage that by chance displays 
as 6 and 3/4 viewport "pages" at window and lineheight sizes currently in 
effect, rather than 7 "pages" even. After paging down 5 times and finding
the next line to read in the same place each time, on the last pagedown it
will appear one or two lines below the position the eye will move to 
automatically. Literal momentary disorientation results. 

Anyone who has used a document window interface in a WIMP GUI has learned to 
reorient in such a case, and sized scrollbar sliders usually give some clue 
that the reorientation will be needed, but the momentary extra strain on the
user is always there. Usually it's subliminal, but when it isn't, the user
will already have been frustrated and/or strained, and this losing-one's-place
disorientation will be particularly unwelcome. 

With its ground-up XP GUI rebuild, Mozilla /could/ take that strain away,
where apps using OS-dependent toolkits cannot, unless the OS were to enable it.

Comment 10

[Jesse Ruderman]

See also bug 33966, "smooth scrolling would be nice", and bug 68402, "highlight 
target of named anchor (after jumping to anchor)".

Comment 11

[Karl Ove Hufthammer]

Smooth (and slow) scrolling would certainly help.

Comment 12

[Matthew T (active 1999-2002)]

I think this would be largely fixed by bug 33966, and much more naturally than 
the various other solutions proposed in this bug. Your eyes would establish a 
visual anchor point at the bottom of the page, and (unlike with jump-scrolling) 
they could then follow that anchor as the page smoothly scrolled upwards.

Padding out the end of the page in particular would look like a bug, especially 
since the apparent length of the page would differ depending on how far away 
from it you were before you jumped into the last screenful. Hixie, would it 
also affect CSS fu which calculated/required particular canvas heights?

Comment 13

[Sean Richardson]

> I think this would be largely fixed by bug 33966 [Smooth Scrolling]

I think you are right, if-and-only-if smooth scrolling can be implemented:
 1. such that it is actually smooth and steady (no stuttering or shuddering) 
    on any machine it is reasonable to run Mozilla on in the first place
 2. at the same speed regardless of the video card (i.e., in such a away that
    no video optimization can make the scroll go faster than intended)
 3. at the same speed regardless of the processing speed of the processor,
    chipset, memory, etc
 4. slow enough for 99% of the userbase to keep a visual lock on a visual
    "anchor" no more distinctive than any line in a long sequence of plain text
    as it scrolls
 5. while fast enough to not seem interminable to more than 1% of the userbase
 6. which may require user-configurable smooth-scrolling speed
 7. and, the same behaviour (and speed) cross-platform

I've yet to see an implementation that satisfies conditions 1 through 4, let 
alone the rest, though. For example, even on a P75 with a 6-year-old video card 
running WinNT, IE5's smooth scrolling is too fast for me to keep a lock on
a line as it scrolls, unless it is somewhat distinctive. On a P300 with a 
2-year-old video card, IE5's "smooth scrolling" can only be distinguished
from Mozilla's jump scrolling by A/B testing. (And yes, the relevant option 
*is* turned on.)  

Unless it's slow enough (for each user to keep a visual lock; this will vary
from user to user and also with alertness), smooth scrolling is no help for the 
problem this RFE was opened to address.

I'm guessing, but I'd bet on it: on Mac's, smooth scrolling is Done Right.
Matthew, can you point to a reference implementation good enough that, should 
Mozilla's implementation be comparable, the latter would satisfy this RFE?

Comment 14

[Sean Richardson]

After all this talk about smooth scrolling, a reminder: this RFE was opened to
enhance jump-scrolling, not to outlaw it. The user, for any number of reasons, 
may want to turn a smooth-scrolling feature off.

I would suggest that the meaning of this RFE bug remain what 
[e-mail] defined it as; no matter how good its 
implementation may be, smooth-scrolling can't address the problem 
if it isn't on, and even with it on, even momentary inattention could result
in losing one's place -- something cmiller's shading idea would help prevent.

(I'll take my padding-out suggestion away and file a new RFE, after seeing
what n.p.m.ui has to say; it is no longer part of this bug. Mea culpa
(one bug per bug) mea culpa.)

Comment 15

[Matthew T (active 1999-2002)]

I'm going to leave this until bug 11751, bug 33966, and Sean's padding-out RFE 
(Sean, please mark it as a dependency here) are resolved in one way or another. 
I believe that those bugs, or a subset of them, may well solve this problem 
without us having to do add any more visual complexity to the UI. Once those 
bugs are resolved, we'll see whether or not this is the case.

Comment 16

[Hixie (not reading bugmail)]

The padding out problem (i.e., increasing the area of the canvas that can be
accessed using the scrollbars) can be perfectly within the rules of CSS.
Call me if you are thinking of getting that implemented, I'll need to spec out
how it should work to stay within CSS.

Comment 17

[Doug Halamay]

Any updates to this?

Adding myself to CC list.

Comment 18

[Neil Cronin]

FYI: there is a patch for bug 33966 that implements smooth scrolling that needs
testing/feedback.

Comment 19

[Jonas Jørgensen]

.

Comment 20

[John Morrison]

.

Comment 21

[Wolfram Esser]

Attachment: DEMO: GIF-Animation of "Masked Scrolling" [200 KB]

See posting news://news.mozilla.org:119/as64vc$[e-mail]
Newsgroups: netscape.public.mozilla.wishlist
Subject: New Killerfeature: 'Masked Scrolling'
Date: Thu, 28 Nov 2002 23:29:23 +0100
Message-ID: <as64vc$[e-mail]>

Comment 22

[R.K.Aa.]

*** Bug 185418 has been marked as a duplicate of this bug. ***

Comment 23

[Dennis Haney]

*** Bug 168214 has been marked as a duplicate of this bug. ***

Comment 24

[Dennis Haney]

gv (installed on most linux systems) does something similar, you might want to
chech that out.

Comment 25

[Richard Neill]

What I'd like is for the next line to be highlighted in yellow for 1 second, IFF
it isn't where I'd expect it to be. Or bolded.

Comment 26

[Aleksander Slominski]

i do not care if it is implemented using cool page masking, 
or just by drawing a line like gv, or marker set on page margin
but could somebody just get this *something* checked into Mozilla/Firebird 
as optional extension- it would greatly improve experience of reading those 
pages that are like 150% size of my screen ..

smooth scrolling even when enabled in Firebird does not work too
well and moreover i think it is orthogonal to this feature.

so what is the status of of this RFE in Mozilla 1.5 and Firebird?
it seems that this RFE was last pdated in Decemper 2002?!
or is it alredy there but not dicumented?!

Comment 27

[johncallahan]

I'm a Firebird user, and I strongly concur that this would be a great feature.
Note that the "padding out" idea is the same tactic used by Microsoft Word in
long documents when using the "normal" page view. Word just cranks the unread
space all the way up to the top of the page, and appends white space to fill out
the bottom.

But whether the developers take that approach or use a visual marker of some
kind, I think this would be a tremendous boon to usability.

Comment 28

[Richard Neill]

Here's how I'd do it:

When you press space, the browser remembers the last line you were reading. It
then jumps by nearly a screenfull. That line is then highlighted (eg a yellow
background) for 3 seconds.


This sort of highlight would also be useful where the target of a link is on the
same page, and both the link and the target are on the bottom of the page. What
currently happens when you click such a link is precisely...nothing. 

Comment 29

[R.K.Aa.]

*** Bug 250729 has been marked as a duplicate of this bug. ***

Comment 30

[Aleksander Slominski]

and I hoped this will be fixed by final verssion of FireFox ...

Comment 31

[Adam Guthrie]

*** Bug 299860 has been marked as a duplicate of this bug. ***

Comment 32

[Elliotte Rusty Harold]

A marker seems like an ugly hack. It's much smoother to simply always scroll by the same amount so the last line of the old page becomes the first line of the new page.

Comment 33

[Richard Neill]

Re #32, I think a marker would actually be very useful - it is a helpful visual cue, even if the user expects to know where to look. However, you missed the point: what should happen when a document is, say 1.7 pages long, and the user presses page down?  The document can't scroll as you'd wish.

Comment 34

[Elliotte Rusty Harold]

I think I understand what you're saying, and I didn't miss it. That is exactly the case I was referring to. When the document is 1.7 screens long and the user hits page down,. the document should scroll a full page minus a line or two (as it does when the document is 2.7 pages long) leaving extra blank space at the bottom as necessary. It should not only scroll .7 pages. 

This is, for example, how Microsoft Word works when faced with this exact situation; and it works much more naturally than how Firefox currently behaves. I suspect is this is how Firefox/Mozilla had always worked like this noone would even be asking for a marker because it wouldn't have occurred to anyone to ask. They would have read the pages and not thought twice about it.

Comment 35

[Aleksander Slominski]

It is now over 3 years since I have posted my ideas 
https://bugzilla.mozilla.org/show_bug.cgi?id=32265#c26
and over 6 years since this RFE was created.

How hard it can be to add a new about:config property
to have both marker showing and "gray area"? really?

Shame on you Mozilla Firefox developers!
I could care less about SQLLite or RDF - bugs/RFE like
that should be an occasion for open source to shine.
If I remember my C++ better I would submit patch 
(or create an extension if it was not be accepted) alas ...

Maybe we get that feature on 10th anniversay - 2010 is almost around ...

Comment 37

[Sylvestre Ledru [:Sylvestre]]

XUL + no activity for a while. Closing.