Some qns:

• When a list, for a example: Wiki Loves monuments - has 500 items, we can load a 10 in the beginning and show them collapsed. How do you load the next 10 of that particular list?
• The trigger to refresh shown in design - is it for all the lists or will it be for individual lists(when they have more items)? This is important since that action need to avoid my favorite list refresh(am I right?). Or what happens if the favorite list has 200 items(just imagine)

• When a list, for a example: Wiki Loves monuments - has 500 items, we can load a 10 in the beginning and show them collapsed. How do you load the next 10 of that particular list?

If a list is shown as part of the suggestions, only 2 items will be initially visible for that list ("Curiosity" and "pillars of creation" in the example). The page will be calculated counting those 2 items but not the rest of items in the list. Initially you'll see a total of 10 individual suggested articles (in the mockup above the page size would be 6). Once a list is expanded, it will show all their elements (because the user is interested in exploring them).

For long lists we can either set a max-height and have internal scrollbars or just expand them as they need and rely on the page scrollbars. I'd start with the later since it is the simpler solution and we avoid double scrollbars.

• The trigger to refresh shown in design - is it for all the lists or will it be for individual lists(when they have more items)? This is important since that action need to avoid my favorite list refresh(am I right?). Or what happens if the favourite list has 200 items(just imagine)

The refresh only affects suggestions (suggested items or suggested lists) but it should not affect anything that the user made an explicit choice of keeping. Thus, it should not affect items in the "For later" or user lists (including those created by the user, those created by others that the user added to their collections).

The general idea is that we have the following sections:

• For later. Items I marked to keep visible for when I have time to work on.
• My collections. Includes lists that I created and campaigns that I joined. This section includes multiple lists as shown in T96147.
• Suggestions. An infinite list of suggestions, shown page by page and provided by the system with items that I can add to the sections above. The suggestions can be individual articles or campaigns (i.e., lists) for the user to join (i.e., add to my collections).

just expand them as they need and rely on the page scrollbars

A bit confusing. "As they need" means manual trigger(like "see more" button) ?

If not,

If you rely on page scrollbar, for which list you will load the remaining items? Suppose I have 3 big lists initially collapsed and I expanded first one. I scrolled, scroll bottom reached, I can trigger load more items, but for which list? for all other lists also scroll bottom reached. We can check if that is expanded or not, But then also, if there are two expanded list, more items will be loaded for both of them. Is that ok?

A bit confusing. "As they need" means manual trigger(like "see more" button) ?

Yes, the "view all" button would be used to show all the items to expand the "Wiki loves science" list. As a result, instead of showing just 2 items, all the items belonging to the list will be shown (and the "view all" button will become "View less").

In addition, clicking on the list name can also be used to expand/collapse it.

My reference to scrolling was about what to do once you have expanded a list (especially thinking on long lists). The options would be to (a) limit the height of the expanded "Wiki loves science" to have 100 items visible in a scrollable panel, or (b) let the list grow without limits (and rely on the general page scroll. The later requires moe scroll to reach the top/bottom of the list to collapse it again, but seems a simpler step to get started.

but seems a simpler step to get started.

IMO, that is not simpler :) and it has problems.

• More than one list listening for single scrollbar(page scrollbar) makes it non-simple. You should be very carefull to expand the list that is in the current view port. If this fails, your scrolling position can jump unexpectedly(a list on top expands and push the current list you view ). I am a bit hesitant to do view port calculation on scroll events since they are expensive for browser- resulting non-smooth scroll.
• I you have 4 big lists, and you are reading 3rd one, if that list expand as you scroll down, to collapse it and read, you either need to scroll all the way up to the beginning of 3rd list or chase the end of 3rd list till _ALL_ items in that list get loaded.
• Loading a whole lot of suggestions is not the user indent on scroll IMO. If that happens, users attension span is getting bigger and bigger - resuling less focus on given suggestion and decide.(You had noted this behavior is some other ticket as far as I remember)

On the other hand internal scrollbars also does not look nice to me.
How about this on request loading:

• 2 Items+View more
• Click on View more
• 10 items+ view more
• click on View more
• 10+10 items+view more(from API)
• click on View more
• 10+10 + 8 items+view less(since we sae list has no more items from API output)
• Click on View less
• 2 items+View more

IMO, that is not simpler :) and it has problems.

The list does not expand on scroll. The lists expands when you click on "view all" (or the list title). Since you have to click that button from the current list to expand it, the list will be in your current viewport.

When there are more than one list, we want to make sure that only one is expanded at a time. so expanding one means collapsing the rest (if they were previously expanded). That requires viewport adjustments, but those will happen when clicking on "view all", never on scroll.

Change 247261 had a related patch set uploaded (by Santhosh):
Suggestions: Public task lists based on category and their paging

https://gerrit.wikimedia.org/r/247261

Screenshot as per patch

Change 247261 merged by jenkins-bot:
Suggestions: Public task lists based on category and their paging

https://gerrit.wikimedia.org/r/247261

Immediate follow-ups identified in code review:

• Duplicate items are loaded, since seed is only stable for same query, but the first query is different than the rest of the queries that load items only for each individual list.
• When view more of a category list is open, you cannot scroll to anything below that list easily until all items from the category list have been loaded.

When view more of a category list is open, you cannot scroll to anything below that list easily until all items from the category list have been loaded.

For this, going up and clicking on header will help. See above discussion between me and @Pginer-WMF

Related to T111028, we discussed that every time the user refreshes the suggestions, a different article can be used as a suggestion seed. This article will be based on the translations the user selected in the past (in-progress, completed, and previous favourited suggestions can be used for this).

Verified that its working as per expected listed outcomes and earlier discussions. However, the problem with long lists highlighted by @Nikerabbit and @santhosh is quite jarring. I had one very long category listed and it kept on scrolling, thus preventing me from going to an item below the lists that I had earlier spotted. Instead of going to that item I had chosen to take a quick look at the listed (long) category and then got stuck in scrolling match with my browser, in both directions. Personally, as a user I would have preferred the solution suggested by Santhosh about on request loading. Any thoughts around that @Pginer-WMF?

Any thoughts around that @Pginer-WMF?

In order to help dealing with longer lists, we were considering to make the list header to become sticky (and adjust the icon to communicate the expanded/collapsed status). In that way users will have always access to a way to collapse the list again no matter how long it is.

You can try it in this prototype. I captured what happens when you expand the "Wiki Loves Nature" campaign and start scrolling.

I was trying to avoid an explicit request for more content since it adds friction for exploring a collection for which the user already expressed interest by expanding it.

In T115008#1835118, @Pginer-WMF wrote:

Any thoughts around that @Pginer-WMF?

In order to help dealing with longer lists, we were considering to make the list header to become sticky (and adjust the icon to communicate the expanded/collapsed status). In that way users will have always access to a way to collapse the list again no matter how long it is.

+1, this is very very convenient. Should we consider implementing this as well before pushing this out?

Change 256204 had a related patch set uploaded (by Santhosh):
Suggestions: Show only to category based lists at any time

https://gerrit.wikimedia.org/r/256204

Change 256204 merged by jenkins-bot:
Suggestions: Show only two category based lists at any time

https://gerrit.wikimedia.org/r/256204