On Mon, Nov 24, 2014 at 8:29 AM, Pau Giner <pginer(a)wikimedia.org> wrote:
I illustrated some details in a document
<https://docs.google.com/presentation/d/1ktB152TDOfMFOi98DsqKGLuls7Xw3-vZ0q0IJYN98t8/edit?usp=sharing>
...
Wau Pow , how do you make those animated GIFs :)
- I think that the issue of moving beyond a gap can be addressed by
deciding which side of the gap to fill based on the user position (more
detail in the document linked above).
I think your "When the gap is in the top 66%/bottom 33% of the viewport"
works when the loading indicator in the gap is visible to the user. But
we're trying to preload topics before the gap is visible.[*] I think your
model still works if we extend the regions off-screen, thus: "When the gap
in the range two topics above off-screen to the top 66% of the viewport
then topics are loaded below the gap", then we trigger load above and "When
the gap is in the range bottom 33% of the viewport to 4 topics below then
topics are loaded above the gap"
With the addition of the TOC users can no longer collapse topics, so maybe
Flow should switch to a window-oriented decision to load more instead of by
number of topics, thus "When the gap is in the range 3 windows above
current viewport to the top 66% of the viewport..." That way if the topic
above or below the viewport has 142 posts, Flow won't bother requesting
extra topics that the user is unlikely to scroll to.
As the user scrolls around the gap can be in one side and then in another.
Should this trigger both loads or abort the first?
[*] Or maybe we aren't? Shahyar later replied "Any load-more buttons above
the viewport should not get triggered until they have been scrolled into
view." Doing so avoids requesting topics that might never be shown, but
it's bad for the user illusion of scrolling around a complete board.
--
=S Page Features engineer