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-----
Hash: SHA256

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
message.

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/

iQIcBAEBCAAGBQJS2WhbAAoJEASpNY00KDJrlKoP/04sbCcQgoDN62ed2c6JUKQH
6mjedNORuBK1eaLdFVep4Gkr6A+NoRHKo8sxHFXU/sT41rl7Dd+V8tlbXRg+twKQ
GuPMEvQuOflxvWSEf2PWKEzkhQC1yxT6xBq+wZvCrEPS/ZYMewztgNCDKOaTRRPD
JSqp/Fv0D/u3OkX2lyGmkLIULSi6lT+Y+EstR6RLN75cjnGorQ2sS06eyCtRx8rx
4yXQ+CUg7tJUlyff01teuBBKcS9m9Js2LkaQe3in93NG7OJXkPF9IuGhyIr+R+WQ
n1UEI3NDwZHDdf873kecN3R75ShnTs+ul/Ng+auQi2o0BM828rp2PGP7v0jFA0aw
F78fN2gilr+S/lQZLscGiRHTXDsXJ9cl2y+jKlVu+7Nms5IhkxTTnY6rD4Z7vozI
u3v8MAIM9Nsq+8UHVFyGnkTk4Z7LSm1T0KAY9IG4nIYA6Iy+stp3bvTCQBKA6Kbh
3w530SxyOruPmAy6YyKYrJjMEFE9XT+l5LYvOOYTvO0J5g0VO0+BMge9aVhZy7ul
F5FTh+3fLDBizXC7YQvXCh8CR0CgFsP7Bb4+kW2mFdQrgi1Jl8CvRiN3wTUfBz47
YR+ibrFO7RkmhZu0z1thikFh16IRAMKy0bO+X1pv9coskorRAJrOqCNC8jNdXd5i
UuEy/uXpRRDZEePfG2Yi
=vX4V
-----END PGP SIGNATURE-----



More information about the tb-planning mailing list