User talk:DBrant (WMF)/Gather on Android

Can you better explain the benefits you see in using the Gather API instead of creating one tailored to this use case? --Tgr (WMF) (talk) 21:30, 19 January 2016 (UTC)

Or rather, can you explain what the use case is? You want to be able to query a set of pages (not necessarily on the same wiki) with their revisions in a single request; I get that much from the page. What else? Can they be from multiple projects? Can they include non-WMF wikis? Do they need to include any information about the articles (e.g. the current revision, or the fact that the article does not exist)? If so, what are the acceptable caching characteristics? Is there any future need to involve Wikidata / interwiki equivalency? Is there a need to "version" page sets stored by the API (e.g. learn in a single request about all page sets that have been recently updated from another device)? Can users share page sets? Do you need Gather's feature set of user-editable titles/lead images? Do you need watchlist-like functionality? Do you need (traditional) watchlists to be involved in any way? --Tgr (WMF) (talk) 21:39, 19 January 2016 (UTC)

The ultimate goal is the original use case of Gather: to enable our users to create collections of Wikipedia articles about subjects that are of interest to them, and to share their collections with other users (additional features might include comments/suggestions for additions to collections, upvotes/downvotes, and popular or trending collections). Relating to watchlists: I see Collections as a generalization of watchlists. A user should be able to create a collection, and optionally mark it as a watchlist (i.e. receive notifications about changes to any article in the collection). This would go towards fulfilling the community request for multiple watchlists, and if we support interwiki links inside collections, it would take care of the community request for interwiki watchlists (#4 on the community wishlist). Anyway, before we get ahead of ourselves, we basically want everything that Gather does today, with two modifications: 1) that collections be stored in a centralized place (instead of per-wiki), and 2) that collections allow interwiki items. DBrant (WMF) (talk) 04:52, 21 January 2016 (UTC)

Hidden user preference?

You can store arbitrary per-user perferences using the userjs- prefix (or stick the preference in the MobileApp extension), why not seralize a list of articles into that instead of trying to use an extension that shouldn't exist? Legoktm (talk) 22:58, 19 January 2016 (UTC)

An interesting option indeed. But userjs options are also per-wiki, correct? DBrant (WMF) (talk) 16:37, 20 January 2016 (UTC)

Yes, so just pick a wiki and use it? Legoktm (talk) 05:55, 1 February 2016 (UTC)

Those are interesting options, although would you please explain the notion of "an extension that shouldn't exist"? --ABaso (WMF) (talk) 13:01, 20 January 2016 (UTC)

I can't say for sure what Lego meant, but he might be referring to how when Gather was being designed it was suggested that a more useful approach would be to implement the long-standing community requests for multiple watchlists per user, and that that should be done in core rather than in an extension. Then UI could be built on top of that. This feedback was ignored, with the reasoning that Gather was some sort of UI prototype. And so we have Gather: an extension that makes lists of pages for no well-defined use case (i.e. Extension:Gather describes what it might possibly do in a vague future rather than what it actually is for) that doesn't seem to interact well with the existing watchlist functionalities or other pieces of MediaWiki, but at least its special page looks pretty. Anomie (talk) 15:22, 20 January 2016 (UTC)

Well, yeah, basically that. The Collection extension should've been improved, or fix core's watchlists. But now we're stuck with a separate extension that is yet again in maintenance mode, has no future, duplicates existing functionality, but in a slightly different way, and provides no actual benefit to keep around. Legoktm (talk) 05:55, 1 February 2016 (UTC)

We have discussed this elsewhere, but just to have a public trail: Android lists are expected to have lots of data (megabytes, possibly) and user prefs are not a good choice to that (added to page HTML, loaded into memory, only queryable all at once). --Tgr (WMF) (talk) 18:10, 11 February 2016 (UTC)