UX: Removing thread-pane "snap to last page" behavior
Andrew J. Buehler
wanderer at fastmail.fm
Fri Jan 17 17:28:59 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 01/17/2014 12:03 PM, Andrew Sutherland wrote:
> For discussion purposes, I think the rationale of the 'snap to the
> last page' was that it could be hard for the user to know when there
> were new messages when the sort order put new messages at the bottom
> of the list, so we would try to snap to the bottom of the list and
> leave a "lip" that was an empty row but which a new message would
> show up in. Without the snap, we were worried that the user might
> not realize new messages were showing up.
For what it's worth, I've always found the visual flagging of the folder
itself (in the left-hand "folder list" pane) to be enough to indicate
that new messages had arrived.
However, I'm not a typical user in a number of ways, so what works for
me in this regard may not work for everyone else.
> In the comment in the source I unfortunately left a half-finished
> sentence (now removed) that I believe meant to say that we wanted to
> have this 'snap' be permanent. So once we snapped, we'd stay
> snapped to the bottom until the user scrolled away from it. This
> would be much like at the top of the tree-view; when new messages
> come in, they come in at index 0 and the scroll position does not
> change (I believe), so you'd see all the new messages come in. But
> right now, at the bottom, no scrolling would occur, they just grow
> out of view, below the last visible message. While the scroll-thumb
> position might indicate something, in a folder with many many
> messages, the difference is unlikely to be obvious.
I remember that sentence (IIRC you couldn't remember what it had been
about, when I asked if I should remove it), and yes, that does make the
inclusion of "snap to last page" make more sense. It's of only limited
use when using message threading, but however unfortunate the fact may
be, the reality is that many, many people do not use that.
However, given that we've gone something like 4.5 years now with "snap
to last page" but without implementing this, A: are we likely to
actually do it? and B: is it really that important?
One downside to "stay snapped to last page as new messages come in"
would be that we would have to choose between scrolling to show new
messages as they arrive, and continuing to show the currently-selected
Also, an automatic scroll event not based on user input could lead to
undesirable results. For example, what if the user is about to click on
a message to select it, and then a new message arrives, resulting in a
scroll? I'm pretty sure the click would land on a different message,
rather than the one the user intended, producing an "I didn't tell it to
do that!" situation.
Also, how do you envision this working with expanding threads in the
last page, the scenario I described in the thread starter? Would the
"select new message with 'n'" action (which has the side effect of
expanding the thread, so that the bottom is no longer in view range from
the newly-selected message) count as "the user scrolling away from the
bottom", and thus be cause for breaking the 'snap'?
Andrew J. Buehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the tb-planning