Hi @Mholloway!

I just had a few questions about the scope and feature set for the extension:

• Will users log into the Wikipedia account via the extension itself or through their Wiki?
• Is the expectation that users will be able to view their reading lists in their web browser (eg through the extension or webpage)? or will the extension simply enable users to add articles to their reading lists, which are then visible only through the apps?
• Is the plan to support the creation of new reading lists through the extension?
• How will the extension communicate to users that they've surpassed their article limit on an individual reading list?
• Currently Android and iOS both have default lists, is the plan for the extension to save articles into this list exclusively? or will the extension require users to select a list to save into? Or can users tap once to save into default with the option of moving or adding the article to a user created reading list

Thanks!

Hey @cmadeo,

For now, given time constraints, we're looking at providing an extremely simple means for users to get an article into the default list from the browser.

In T191221#4110330, @cmadeo wrote:

• Will users log into the Wikipedia account via the extension itself or through their Wiki?

It will depend on the user being logged in through the wiki itself. Login integration may come in later, but it's not likely to be in place in time for launch.

• Is the expectation that users will be able to view their reading lists in their web browser (eg through the extension or webpage)? or will the extension simply enable users to add articles to their reading lists, which are then visible only through the apps?

The latter—the extension will simply allow users to quickly add a page to the default list. Any further list management will be in-app.

• Is the plan to support the creation of new reading lists through the extension?

Not at this point.

• How will the extension communicate to users that they've surpassed their article limit on an individual reading list?

I'm writing the extension popup to display error messages from the server in the event of an error, e.g., "List X cannot have more than Y entries."

• Currently Android and iOS both have default lists, is the plan for the extension to save articles into this list exclusively? or will the extension require users to select a list to save into? Or can users tap once to save into default with the option of moving or adding the article to a user created reading list

As of now the plan is for the extension to interact exclusively with the user's default list.

Hey @Mholloway - just added related tasks from Android (T169314) and iOS (T145876).
Actually a quick question – the first part of those tasks is about adding an option on the Share sheet to "Add to reading list" when users have the app installed. Would any of the work being done here be relevant to enabling share actions on Android or share extensions on iOS mobile web browsers?

Hi @RHo, thanks for linking the relevant Android and iOS tasks.

In technical terms this is a separate task from what I think you're describing: having the "share" action from a mobile browser add the article to a user's reading list in the app. That would be accomplished strictly on the app side via an intent filter on Android, and I imagine some analogous mechanism on iOS. Actually, it looks like the Android app already has an intent filter set up to open articles "shared" to it for reading; that intent filter could be updated to instead invoke the "add to reading list" dialog. (As far as I know there's no way to offer the option to do one or the other directly from the share sheet, at least on Android, though a dedicated share handler could be added to the app to offer the user a choice to either read or save to a list once the app is opened.)

This browser extension is mostly for the benefit of users in a desktop/laptop situation, where browsers don't have a "share" option.

@Mholloway Thanks for your responses to my earlier questions. Sounds reasonable to keep things simple and only allow users to add to their default list on both platforms from the extension for now.

Let me know if you need any assets other than the store assets for the extension, or any other design support.

@cmadeo You're welcome! I think the store/browser toolbar assets are the most important thing for now. We might want to touch base on styling for the popup in various scenarios (success, login required, error) at next week's meeting but the extension needs a bit more work on my end before it's ready to demo.

Note on the possible Safari extension:

It looks like as of Safari 10.0, Safari extensions are distributed within iOS apps.

https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/SafariAppExtension_PG/CreatingandTestingYourFirstSafariAppExtension.html#//apple_ref/doc/uid/TP40017319-CH11-SW1
(Add'l background: https://developer.apple.com/library/content/documentation/Tools/Conceptual/SafariExtensionGuide/Introduction/Introduction.html)

It looks like I would need the WMF's Apple Developer credentials at least to register the new Safari Extension target.

According to the documentation, Safari extensions do permit the creation of popovers, so we need not create a Javascript banner in the page window instead (unless we want to).

While working on the Firefox version yesterday I found that Mozilla provides a polyfill script that will allow us to use the same code for both Firefox and Chrome despite their slightly different APIs.

I initialized an org repo for the Chrome/FF cross-browser WebExtension (https://github.com/wikimedia/webextension-readinglists) and added a PR for code review.

Hey @LGoto, do we have official Wikimedia Foundation credentials for the Chrome and Firefox extension stores yet, or is that still in progress?

Hi @Mholloway we're still waiting on legal, but their review is currently underway. I'll be sure to update you when that's complete.

@LGoto Okay, thanks! Just trying to get as much set up as possible for @bearND before I head out on vacation.

hi @Mholloway - just wondering how easy/hard it is to add a tooltip for the extension when a user tries to use it on a non-supported website? Might be good to show this so users do not mistakenly think the extension is broken
Eg. from the Last.fm webscrobbler:

Tooltip on hover:

Message on click:

@RHo Tooltip: very easy.

To add a popup for the disabled state is, well, not exactly difficult, but as far as I can see it would require updating the code to make this a universally enabled browser action (rather than a page action) and manually manage "enabled"/"disabled" state on a per-page basis, which is what I assume Last.fm is doing here (as the API doesn't appear to provide any means for designating a popup for a disabled page action). We'd be fighting the API to a certain extent and enabled/disabled state would accordingly probably be a little more bug-prone. How high of a priority is the popup?

On the other hand, we're kind of doing this kind of manual state management already anyway due to the way this had to be written to support both browsers with the same code.

Depending on how much more time we want to spend on this (which I guess is mostly a question for @Fjalapeno) it might make things saner overall to split out the core business logic into a shared library and have separate code repos for Chrome/FF to deal with enabled/disabled state on a per-browser basis.

That's probably more implementation detail than you wanted but I just thought I'd get my thoughts out in writing here while they're top of mind. :)

hey @Mholloway – I wouldn't prioritize it that high to have the pop-up at the risk of delaying having this out, since at the moment the icon is shown disabled when on an unsupported site anyways. Perhaps just the tooltip is good enough for now since that is easy, and we can re-evaluate if there's feedback from a lot of people not understanding it is only for Wiki sites.

@RHo Cool. As for the tooltip text, how is "<Name of extension> does not support this page"? I recommend saying "page" rather than "website" as in the above examples because I've included checks even on valid sites that the page the user is on is a savable page (and not, say, a JSON API response).

thanks @Mholloway - "page" SGTM!

Change 432386 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[mediawiki/extensions/ReadingLists@master] More string resources for the browser extension

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

Change 432386 merged by jenkins-bot:
[mediawiki/extensions/ReadingLists@master] More string resources for the browser extension

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