UX: Removing thread-pane "snap to last page" behavior

Andrew J. Buehler wanderer at fastmail.fm
Fri Jan 17 15:23:16 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

When moving among messages using the 'f', 'b', or 'n' shortcuts in any
part of the thread pane except the "last page" area, Thunderbird scrolls
only as far as necessary to show the newly selected message (with any
applicable padding). When the newly selected message is in that "last
page" area, however - that is, when scrolling to show the bottommost
message will leave the newly-selected message visible - it scrolls to
show the bottommost message in the thread pane.

Per bug 950455, I would like to be able to avoid this latter behavior,
so that it will scroll only as far as necessary in all cases.

I originally proposed a pref to make this "snap to last page" behavior
optional, but that was rejected in favor of removing the behavior
entirely. However, this is a UX change that needs consideration. I have
been requested to post here looking for feedback and discussion on that
point.

(That's the TL;DR, and should suffice as a summary. The below mostly
just provides context and justifications for the change.)


The behavior I want was present, apparently as the only behavior
available, in Thunderbird 2. A later version - I believe Thunderbird 3,
though the VCS history doesn't appear to go back that far - removed it
and added the "snap to last page" behavior.

It is entirely possible that in the interim, some users have come to
expect and rely on the "snap to last page" behavior, and would not be
pleased to see it removed - just as I had earlier come to rely on the
absence of that behavior, and was not pleased to see it added. This is
why I originally proposed to simply make that behavior optional.


I feel that having this different scrolling behavior in this one special
case violates the principle of least surprise; if I've been reading
through messages with 'f' or 'n' and seeing the thread pane scroll along
one message at a time, I would not expect (and do not want) for the same
keypress to suddenly scroll an entire page of messages at once, just
because I've gotten near the bottom of the list of available messages.

Further, if the newly selected message is at the root of a large-enough
otherwise-unread thread, then selecting the first reply in that thread
by using 'n' (and thereby expanding the thread) will result in both
messages no longer being within the "last page" of the thread pane. This
can lead to jumping back and forth between the two scrolling behaviors,
in a not entirely intuitive fashion.

This behavior also interferes with the relatively obscure use case (on
which I nonetheless rely in some contexts) of reading large archives of
unread messages in groups of X at a time, as described under bug 920510.


The options, as far as I can tell, are:

* Retain the status quo, i.e., keep the "snap to last page" behavior and
WONTFIX the bug.

* Remove the "snap to last page" behavior, and return to the Thunderbird
2 behavior of scrolling only as far as necessary, regardless of where in
the thread pane we are.

* Provide both behaviors, depending on a pref. This has been rejected.

In either of the first two cases, it should be possible to implement an
add-on to provide the alternate behavior. However, doing so would
require the add-on to duplicate folderDisplay.js::ensureRowIsVisible()
wholesale, in order to change one small part of it; I think this is an
inappropriate and undesirable use of monkeypatching (due to the need to
maintain the add-on's version of the function against any changes to the
core application's version of the same), and not something we should
consider as an acceptable alternative.


Opinions?

- --
  Andrew J. Buehler

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJS2UrkAAoJEASpNY00KDJr4T0P+QGZ877zVwmN5EtYQuJ9aQtL
mdgemBQJ7Vz96JKZU3YjIycZPThutwAYYWukcoqhuzqcnNQqbGady9dmDS434W1Q
j1pyUuMFCVXXEqMImGBUrKp3+yvtxPmNfTQr9WD0ky634qLI2AKpH2LPAQb4VZTe
blwS41nOD3KztfUv5dYS8TiY3+jlEgMqtLsEY8dZjii+x2nJmP+waLMgYPSMI3Ey
qKapMqRepX1UMcYQoIFvq9gKl1F4VLkCxIzt1/MgjCV1z1AzVfoPwFvr9U2jB/3e
j0CNFWj9PMHIWxHy67spabXr6wkVM+HTf6nx1DZFwBexO35hK76V3Xow3ltCec+g
L1Qg9MFPaq4kTnkljV/SnN/QqMDErnGPYfXPjRTdLKsJ1jnGvwQjNcTZ2jZXpAc8
2YL9Vd3OGNY5vi7xRrGq52SIsfg1cLpkDtxWLUxIa5DmR0FJAbYurO/IEnfkiWzU
ItnEQaXMWDSPr2qkzuGGAl55igJvip8mRDEkwD5bnbxguVXFus4Fn+rJWvOY+QOO
+WLoj9JyXd/MFk6+d9cAvRqRq/gXcTIoBAqLrrWF6XhOZ7FdnEXWNuexz7eqY4SB
+i5To72YL1/U3eucmdOkl4BzBJGShSXLNghd1u5kB/sf06tFh3RhtOBZQErFHi6r
jSh9ImpYaCUfsbO4UGD4
=pmOF
-----END PGP SIGNATURE-----



More information about the tb-planning mailing list