1. The solution is to implement "middle" topic loading, so you can load
topic X and N topics around it, as opposed to the current options of "fwd"
and "rev" which only load topics before and after a given X. That way, when
the content is rendered, you can jump to "ID" and no content will need to
be loaded before it, even if it's at the bottom, because the viewport will
be filled up.
There's no performance win for asking ONLY topic X. It's done like this
for testing purposes. There's a Trello card (L110) to fix this stuff.
2. Stopping the user's scrolling is not a good user experience. It's
been discussed several times now. Beyond obvious UX issues, it's an
accessibility nightmare. (On a related note, the ability to turn off
infinite scrolling on a per-user basis should be implemented.)
3. It already does, kind of. Whatever topic is listed in the affixed nav
bar, is where you will remain. However, this is iffy because: if you are
actually reading X, but scroll up a tiny bit, between A and X is a hidden
"load more", but because A is very slightly in view, it is now the
being read". This logic can be changed to "what is the topic in the middle
of the viewport" instead of "what is the topic at the top of the
4. This can be solved by moving the load-more buttons INTO the
individual topics, so that they are always affixed to the correct location.
Otherwise, what the code does is: sees 1 2 3 [loadmore 4 5 6], does 1 2 3
-insert 10 11 12- [loadmore 4 5 6]. If that loadmore is in the container
for topic 3, it won't move.
5. Sounds like a bug. jumpTo a topic should not trigger loadMore except
for below-the-fold. Any load-more buttons above the viewport should not get
triggered until they have been scrolled into view.
On Fri, Nov 21, 2014 at 3:57 PM, S Page <spage(a)wikimedia.org> wrote:
It's great Shahyar has got the TOC in a state
where we can see jumping
down working. Try it at http://flow-tests.wmflabs.org/wiki/Talk:Sandbox
(please don't add or hide/delete topics to this, it's crafted specially to
test TOC. You can experiment on Talk:Flow_QA or your own user_talk page.)
If you click on e.g. topic 73 it works strangely (try it and see). We
think Flow is trying to load topic 73 but it's at the bottom of the page
which triggers loading topics 11-20, and then the view jumps around as
topics show up.
We knew this would be hard to get right. Danny and I explored some use
1. You click on topic 73 and there's a gap above it.
* TOC requests that topic and some topics around it (e.g. N-3 through N+7)
* TOC disappears
* Flow shows a Loading more animation at the bottom of the page and
positions the view at it.
* When the topics show up, Flow positions topic 73 just below the fixed
header as usual.
While this is in progress, we need to disable the usual bottom of page
Load more behavior -- don't try to load 11-20. There should only be one
load going on at the very bottom of the page.
(Note ErikB doesn't think there's a performance win in asking for only
topic 73 then making separate API requests for topics 69-72, etc. Nor is it
easy to provide a variable response "Give me enough topics to fill four
[PageUp] operations from topic 73")
When Flow adds topics 70-77 to the page I think we need a "gap indicator"
at the top of them to indicate there is a gap but Flow isn't yet trying to
load stuff to fill it. On a fast computer and connection the user might
never see this.
2. You scroll up from topic 73
Because Flow has loaded some topics above 73, you can scroll up into
content above, preserving the illusion of perfect scroll. As you get closer
to the gap (topics 11-69), Flow tries to fill in the gap to preserve the
illusion of a complete page. When scrolling up into a gap Flow should
always load bottom-up, i.e. it requests topics 60-69. The dormant "gap
indicator" turns into the active Loading more animation
The problem is, while this is going on the user can scroll around past the
gap indicator/Loading more animation. Quiddity and I think that's fine and
Flow should let the user freely move around in the browser window; Danny
would like to stop the user scrolling past the gap -- "You wanted to scroll
up to some topics above, Flow is loading them, sit tight."
3. You scroll away from a loading more gap.
In either 1 or 2, you can scroll away from the gap in at least one
direction, or you can open the TOC and jump somewhere else altogether. When
the API request returns the topics intended for the gap, Flow inserts them.
Question: do we reposition the view? Yes for the click in the TOC, but
unclear for scrolling around. I'm not sure what the default browser
behavior is if you insert a bunch of content in the DOM above what the user
4. You scroll back into the gap
After loading topic 73 and scrolling up a bit, say you jump to top of
page, then scroll back down towards topic 10. Flow is still filling the
11-69 gap with topics 60-69. Now you're scrolling down into the gap, you
probably want the usual Load more behavior, so Flow should request topics
* Should there be two loading indicators in the gap? I think so, a gap may
be being filled from the bottom and from the top at once.
Furthermore, you aren't near the bottom of the view because topics 70-77
are there, so if you're holding down the space bar or scrolling in order to
force loading more topics, it won't work. You'll scroll right past the gap
and into the topics lower down. I think this is OK, you're probably back on
a quest to get to the "end" of the board.
5. Now you bring up the TOC and click topic 49
Like step 1 above so
* TOC requests that topic and some topics around it (e.g. 46 through 56)
* TOC disappears
* Flow shows a Loading more animation ...
where? The one gap is loading topics 60-69 from step 2 and 11-20 from step
4, now it's loading a third group!
I'm sure there are further use cases and challenges. Next step is probably
for Matt, Shahyar, Pau, Danny, to explore this with other interested
Some design approaches we aren't pursuing:
* Detailed "68 missing topics", "load/loading 10 above" messages or
controls -- Flow only shows the Loading more animation in the gap.
* Flow knows the topic titles in the gaps from the TOC, but it doesn't
show them -- Flow only shows the Loading more animation.
* Flow doesn't communicate the size of the gap. unlike e.g. a PDF viewer
it doesn't know how tall topics are. It just places a Loading more
animation in the gap.
=S Page Features engineer
EE mailing list