@Jdlrobson Yes we can skip wikidata description for now. I'll update mocks and fill additional criteria by tomorrow!

@KHammerstein any reason we can't just use existing Gather design?

@Jdlrobson Great point, the designs should be consistent. The design team has been standardizing on a card style that is a bit different from the gather design now - for example the titles aren't overlayed over the image. Would it be possible to update gather so that we can use the same design here?

Sharing the card design between our projects should definitely be an (engineering) goal of this project.

FYI, we may want to swap out the Gather design for something akin to the search results PageList design in future. If we do this, the same problem applies - the PageList lives in MobileFrontend not RelatedArticles and needs to be shared somehow. Please bear this in mind when implementing so we can easily swap it out cc @KHammerstein @JKatzWMF

Created T114393 to split card creation out as a subtask. After discussion with @phuedx, we came to the conclusion of using a new extension for generating cards with default styling. This will pull code from Gather's card generation.

Articles shown using same backend as apps "Read more"

AFAICT, the Android app uses Elasticsearch's morelike search feature in order to get suggestions. This is something that the fine, upstanding folk that worked on the GettingStarted extension did too, so there might be an opportunity to break this out too.

FYI mock in T113768

Thanks @Jdlrobson!

So I think PageList and the Gather cards (CollectionItem) should probably be the same thing but different variations of each other. I think a Card extension/composer/npm module library will thus help here :)

I didn't really clock this yesterday, but the mock in T113768 is counter to the requirements at the top:

Cards are identical to those in Gather and show:

• page image
• text extract (first 3 lines of text from article)
• No arrow at bottom of card

In fact, the mock looks like the PageList component/thing.

Change 244149 had a related patch set uploaded (by Phuedx):
[WIP] Add Related Articles section to MobileFrontend

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

Did you see https://phabricator.wikimedia.org/T113635#1687199 ?

Yes. AFAIK @jhobs is still working on T114393. I figured I'd wire up the RelatedArticles extension to the WatchstarPageList class to see what was required, which, as it happens, isn't a whole bunch.

@Jdlrobson, @KHammerstein: Where's the mock for the desktop version?

The feature should show up in desktop and should be usable. It does not need to look great (we will work on desktop and the beta feature in the next sprint).

Shall we move this to a follow-on task?

@Jdlrobson @phuedx
Doesn't seem to be a good way to transfer the list style to desktop, even though @JKatzWMF wanted to start with a version close to Read More on apps. And I would really prefer to start using the gather style cards.

Here are 2 versions
1 At bottom of main content area
Uses a gather-style card minus the text extract. The background and border match article table styling.

2 After content area, in footer
Background and border would match gather styling. I prefer this version

Are these technically possible?

Version that is exactly like mobile:

244149 currently covers all of the AC. However, I'm not happy about the number of requests that it's making (3). I've proposed a shortcut for removing one on the patch.

The WatchstarPageList class makes an additional request to the API to get the watched status of all of the pages by ID. If we could inject our own WatchstarApi-like object at construction time, then we could provide our own stub API, complete with stubbed #load and #isWatchedPage methods, i.e. we could remove the additional request.

244149 currently covers all of the AC. However, I'm not happy about the number of requests that it's making (3). I've proposed a shortcut for removing one on the patch.

244149 covers all but the Articles shown using same backend as apps "Read more" AC as that's blocked – sorta – by T114916.

The WatchstarPageList class makes an additional request to the API to get the watched status of all of the pages by ID. If we could inject our own WatchstarApi-like object at construction time, then we could provide our own stub API, complete with stubbed #load and #isWatchedPage methods, i.e. we could remove the additional request.

Done in 246463.

I'd appreciate feedback from a couple of keen-eyed reviewers.

There's a lot of crossover between 244149 and @bmansurov's 246137, which is to be expected.

@jhobs / @bmansurov can you take a look at this and try to get to the bottom of what's not working?

Change 244149 merged by jenkins-bot:
Add Related Articles section to Minerva

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

Some follow ups needed but this is mostly done:
See https://gerrit.wikimedia.org/r/249035

Would appreciate a reply to:
https://gerrit.wikimedia.org/r/#/c/244149/13/resources/ext.relatedArticles.readMore.minerva/index.js L37

Will sign off sometime tomorrow!
Should be possible to test on http://en.m.wikipedia.beta.wmflabs.org/wiki/Related_test