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 "topic 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 viewport".

  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.

--Shahyar

On Fri, Nov 21, 2014 at 3:57 PM, S Page <spage@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 cases.

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 is viewing.

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 11-20.
* 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 parties.

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
EE@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/ee