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.[*]
Yes, preloading the topics early enough before the gap is visible should be
our main goal. However, we need to decide what to do for users which scroll
fast or suffer from a slow connection. The 66-33% approach helps making it
consistent with the regular infinite-loading behaviour. Just as if there is
a gap at the end of the current list.
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?
I'm not sure on what is more effective. The initial load has some time cost
for no immediate benefit, but loaded topics will be there if the user
scrolls later (which may save time later). I think the answer depends how
much such delay is.
maybe Flow should switch to a window-oriented decision
That sounds good, loading based on number of topics is just an estimation
to get enough loaded content above/below the current viewport. Using a
strategy that actually takes into account the scrolling distance may have
some benefits (being less affected by topic length), but may add some
complexity. A technical evaluation may be needed to identify the pros and
cons of each approach.
*#1. Making the Jump behavior work properly*
Yes. I'm experiencing the same: clicking on a topi from the ToC and not
getting there.
*#3. Can we have two in-progress loads at the same time?*
We need to take into account that the critical point is when the gap is
visible, and with the viewport adjustments as soon as new content is loaded
the gap gets quickly out of the viewport. If the user is moving around a
gap,we can decide to cancel requests or let them get completed and just
trigger new ones (as mentioned above, I'm not sure hat is more effective in
terms of time/benefit).
If the user gets jumping around different topics, that could generate many
gaps. We can decide to close some gaps when there are few topics remaining
in order to avoid too much fragmentation. That is, we can normally load 10
topics around the current one, but decide to load 5 more if that closes
completely a gap.
Pau
On Tue, Nov 25, 2014 at 1:04 AM, Danny Horn <dhorn(a)wikimedia.org> wrote:
Between Shahyar, Pau and S, this is getting into good
shape for Matt to
work from. There are still a few questions that we need to figure out:
*#1. Making the Jump behavior work properly*
In the current version on flow-tests, jumping from the top of the page to
topic #47 doesn't work properly. The header gets stuck at #10, and then you
see a lot of topics jumping around as they get loaded. You never end up at
#47. :) We need to get this part working before we tackle filling in the
gap.
*#2. What are we loading when the user jumps?*
When the user jumps from the top to #47, are we loading #41-50, or #45-54,
or something else?
Any option is fine, but we've mentioned several versions and I don't think
there's a clear consensus on which one is correct.
*#3. Can we have two in-progress loads at the same time?*Pau's model
<https://docs.google.com/a/wikimedia.org/presentation/d/1ktB152TDOfMFOi98DsqKGLuls7Xw3-vZ0q0IJYN98t8/edit#slide=id.g43bf42657_055>
for how to anchor the user view makes a lot of sense. The behavior when you
get to the loading indicator and then stop is very clear.
But what happens when the user scrolls past the loading indicator? There's
already one load currently in progress. Can you have two going on at the
same time?
For example:
User opens the page.
-- #1-10 are loaded.
User opens the ToC, and jumps to #47.
-- #45-50 loads, user is positioned at #47.
User scrolls up and sees the loading indicator.
-- #36-44 load begins processing as the user is scrolling up.
User scrolls past the loading indicator to topic #9.
-- Does #36-44 finish loading, or is that cancelled?
User scrolls back down to the bottom of topic #10.
-- Start another process to load #11-20? Can we have both #11-20
and #36-44 in progress at the same time?
This can continue getting more complex if the user then scrolls quickly to
the bottom of the page (triggering the next infinite scroll) or uses the
ToC to jump to #27, in the middle of a gap.
The question is: Do we allow two in-progress loads at the same time, or do
we cancel one if the user behavior triggers a second?
On Mon, Nov 24, 2014 at 12:48 PM, S Page <spage(a)wikimedia.org> wrote:
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
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee
_______________________________________________
EE mailing list
EE(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee
--
Pau Giner
Interaction Designer
Wikimedia Foundation