Page MenuHomePhabricator

Add a share button to the mobile site (starting by enabling in beta)
Open, NormalPublic

Description

The new WebShare API allows us to encourage users to share our content via social networks and chats from Android devices (and hopefully in future iOS).

We should show a button that allows sharing from the mobile site to encourage distribution of our content.

We can track number of shares by suffixing a parameter to all URLs e.g. ?mobileshare=1 to get a sense of how widely used it is.

Engineering effort involved is minimal - maybe 1 or 2 points.
This button has already been prototyped on https://trending.wmflabs.org
and is surfaced in the mobile web beta channel for testing and to gather feedback on whether it is useful/wanted.

  1. Motivations
  2. adding modern functionality
  3. helping people share more easily
  4. encourage dissemination of knowledge
  5. rid the world of Facebook like buttons by making people more aware of an open alternative
  6. closely lines up with our values (embracing web standards, decentralising web from big companies such as facebook)

Measurement

We can count share button clicks via statsv cheaply

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 22 2017, 8:47 PM
MigDinny added a subscriber: MigDinny.
MigDinny removed MigDinny as the assignee of this task.Nov 22 2017, 10:54 PM
MigDinny removed a subscriber: MigDinny.

@Jdlrobson - yes! let's do this. I looked through the prototype but couldn't find the button - is it within each article?

ovasileva triaged this task as Normal priority.Nov 23 2017, 10:48 AM

The new WebShare API allows us to encourage users to share our content via social networks and chats from Android devices (and hopefully in future iOS)

https://caniuse.com/#feat=web-share says it's only Chrome for Android, with limited support for Chrome. This is only a clarification mind, as the "download" button is also limited to Chrome on Android.

Yep the prototype will only work on android chrome and yes is limited to latest chrome.

That said it's a web standard. Adoption from a big player such as Wikipedia puts pressure on other browser vendors to implement, which is a good thing.

That said it's a web standard.

AFAICT Web Share isn't a web standard but a draft report published by the Web Incubator Community Group. Quoting the Web Share API draft report (emphasis my own):

 Status of This Document

This specification was published by the Web Incubator Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.

Don't get me wrong, I think the Web Share API sounds great and I hope it's considered for implementation by the WebKit folk soon!

Including share buttons is a heavily rejected perennial proposal. See https://en.wikipedia.org/wiki/Wikipedia:Perennial_proposals#Share_pages_on_Facebook,_Twitter_etc. .

I would strongly advise getting consensus for this in advance.

Jdlrobson added a subscriber: brion.Sep 4 2018, 5:44 PM

@Yair_rand thanks for the heads up!

Reading through the RFC the grievances with a "share" button seem to be around these kind of interfaces which work against a decentralised web and heavily focus on well established social networking sites:

The share API provided by web browsers is completely different IMO in that it only shows services that are installed on a user's phone and that "share" encompasses more than putting a link on social networking. Sharing can be to text message, email, personal note application apps. The current use case is sharing a PDF copy of a page (something many people in many of our growing communities are already doing).

Thanks for the food for thought, will bear this in mind. There is likely a lot of prototyping that needs to be done first. It seems like I'd have to be careful with the usage of the word "share" given the historical context.

@Yair_rand @TheDJ @brion (I know we've conversed about this sort of thing) do you have any further thoughts on how to approach this? I feel like this is a great low cost way for Wikimedia movement to support decentralised web efforts (https://decentralizedweb.net/) and it would be a shame if such a thing got shot down via RFC through a misunderstanding so I'd want to be careful in how it was positioned.

Change 461008 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] PoC: add share icon

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

I made a proof of concept so we can see how this looks like in real life. The share feature is disabled, by default, will be visible only to beta users on mobile site. Also, there is a config variable that allows us to enable/disable the feature.

Jdlrobson updated the task description. (Show Details)Sep 27 2018, 4:34 PM

Change 461008 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Add share icon as mobile web beta feature

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

I merged the above patch but its limited to beta so we can attempt to get feedback on whether this is useful or not (and whether it's in violation of project policies). No plans to push to production any time soon and will definitely need to pitch it to community before even considering it. It's been written in a way that it can also be disabled on wikis if needed.

Jdlrobson renamed this task from Add a share button to the mobile site to Add a share button to the mobile site (currently in beta).Oct 12 2018, 9:08 PM
Jdlrobson updated the task description. (Show Details)

Change 467424 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Disable share button

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

The https://gerrit.wikimedia.org/r/467424 patch disables the share feature for now. First we need to test that feature on beta cluster. Pulling it into the board so the work is visible for the rest of the team.

We decided to disable this feature everywhere for the time being so that it can go through design review and QA prior to exposing in beta mode.

Change 467424 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Disable share button

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

Change 467437 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[operations/mediawiki-config@master] Beta: Show share button on mobile web for beta user

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

Change 467437 merged by jenkins-bot:
[operations/mediawiki-config@master] Beta: Show share button on mobile web for beta user

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

pmiazga added a subscriber: alexhollender.

Feature is disabled for production build, enabled for beta users on beta cluster. /cc @ovasileva @alexhollender @phuedx @Jdlrobson

Moving to design review first to identify any changes needed before QA.

pmiazga renamed this task from Add a share button to the mobile site (currently in beta) to Add a share button to the mobile site (currently in beta on beta).Oct 23 2018, 5:09 PM

@alexhollender given this task has been lingering in design review ... and our 2 week rule..., can I suggest we resolve this task and create a new task "Enable share button on mobile web beta" and put it in the design backlog?

Per standup this morning we've moved this to design to persue at your leisure rather than track in the sprint board.

Jdlrobson renamed this task from Add a share button to the mobile site (currently in beta on beta) to Add a share button to the mobile site (starting by enabling in beta).Nov 8 2018, 6:15 PM

This is rad. In terms of UX it works great, as I would expect.

A few notes:

  1. I think we'll need a different icon, since the current one is too close to the download icon. I think the icon Facebook uses could work (also used by NY Times, .

  1. In Safari and Chrome browsers on iOS the share function is easily accessible as part of the browser chrome. Wondering if it makes sense to double-up, or limit the feature only to Android

  1. Part of me is wondering if there's somewhere other than the toolbar to put this button — it seems like the obvious place, but also for some reason I can't quite identify yet it feels out of place. If we do keep it in the toolbar I think it might be worth evenly distributing the icons horizontally.
  1. I would like to do a small audit of a few other content sites and see if there is anything else to consider.

I will bring this feature to the upcoming design review on Wednesday 11/21 to gather more feedback.

phuedx added a comment.EditedNov 19 2018, 2:41 PM
  1. Part of me is wondering if there's somewhere other than the toolbar to put this button — it seems like the obvious place, but also for some reason I can't quite identify yet it feels out of place. If we do keep it in the toolbar I think it might be worth evenly distributing the icons horizontally.

We'd also skew any measurement of popularity of the feature by putting it in one of the most widely seen parts of the page.

Edit

A warning, not a criticism.

Jdlrobson added a comment.EditedNov 20 2018, 6:42 PM

FWIW i think the print button and share button should be accessed the same way. As I pointed out in
https://phabricator.wikimedia.org/T201954#4591492 i think these features could/should be packaged together. They both involve "moving" the entity elsewhere whether it be to a social media site; an app or a pdf..

  1. I think we'll need a different icon, since the current one is too close to the download icon. I think the icon Facebook uses could work (also used by NY Times, .

Changing Icon is pretty easy, please provide a different icon and I'll replace it

  1. In Safari and Chrome browsers on iOS the share function is easily accessible as part of the browser chrome. Wondering if it makes sense to double-up, or limit the feature only to Android

I'd like to keep the toolbar consistent across all browsers. The URL bar is not always visible, if we decide to make our toolbar sticky (advanced contributions) then user will have access to tools all the time. Also, the share feature in Safari browser is pretty new feature and I think it might change.

  1. Part of me is wondering if there's somewhere other than the toolbar to put this button — it seems like the obvious place, but also for some reason I can't quite identify yet it feels out of place. If we do keep it in the toolbar I think it might be worth evenly distributing the icons horizontally.

We can A/B test that, do different views and count user actions

  1. I would like to do a small audit of a few other content sites and see if there is anything else to consider.

Just let me know if you need any help with that.

I will bring this feature to the upcoming design review on Wednesday 11/21 to gather more feedback.

Thats great!.

Some notes based on the discussion in design review on 11/21:

General

  • While the share functionality is built into most browsers, it could be a benefit to have it present within our own UI so it's more top-of-mind for users
  • How can we add value here beyond what the browser's Share button offers? The apps have a cool "share a fact" feature that creates a nice little card with a quote/snippet from the article. Maybe we can do something more simple around allowing users to share a link to a specific section? See sketch below. Another idea was to provide a short version of the URL as a small benefit to users (Pau mentioned that Hindi does this).

Icon

  • two options were proposed: (1) the share arrow that is used by facebook and NYTimes, (2) the android share icon
  • both options are shown below

Instrumentation

  • can we instrument it in a way so that we can find out if they followed-through with sharing a the link? Olga mentioned that we solved a similar issue for instrumentation of PDF download, so it might be okay just to instrument the tapping of the button

Beta process

  • the rough draft I'm working on for Beta process is still in the works, however I think it'd be great if y'all could write up a minimal Beta feature plan for this. Here is a proposed outline for what that plan might include:
    • statement of intention / what we want to learn ("releasing this feature to Beta will allow us to learn...")
    • success/failure criteria ("we will know this feature is successful/unsuccessful if...")
    • duration of time feature will be in Beta ("we will put the feature up for X days/months so that we can...")
    • some sort've project page where people can learn more about the feature, give feedback, collaborate, etc.
    • identifying a point person who will be responsible for responding to questions or ideas, and stewarding the process
    • list of known issues & bugs (if any)
    • proposed follow up plan for what needs to be done to make the feature ready for production if the Beta test succeeds

can we instrument it in a way so that we can find out if they followed-through with sharing a the link?

yes, that's possible, we need to add some argument to the shared url, something like ....?share_btn, then we will be able to verify how many users are visiting Wikipedia via share links.

so it might be okay just to instrument the tapping of the button

we can (and I think we should) do that.

Also, as there are two icons, we can implement both, and instrument the tapping of the button to send which version of the icon is visible to the user.

Have we reviewed the designs of the share buttons in the Android and iOS apps? (Those are separate from the "Share A Fact" feature mentioned above, which is accessed by first marking some text.)

E.g. the Android app uses a version of https://en.wikipedia.org/wiki/Share_icon#Share_Icon .

alexhollender added a comment.EditedFeb 25 2019, 6:50 PM

@pmiazga here is a first stab at filling out the Beta feature "template". We can discuss and iterate when we meet.

  1. Feature rationale: we believe that by adding a share button to the article page on mobile web people will share Wikipedia articles more often, ultimately leading to more knowledge being spread and consumed.
  2. What we want to learn: we want to learn if people will discover and use this feature. We know that there is a share functionality built into most browsers, however our hypothesis is that since our share button will be more front-and-center, it will help make sharing top of mind for users, as well as facilitate an easier sharing process.
  3. Instrumentation: [TBD] T207280
  4. Success/failure criteria: we will be tracking the number of taps to the share button. We will control for experimental/exploratory taps. If the number of taps is above __ we will consider the feature successful.
  5. Duration: we think that four months worth of data will give us a sufficient understanding of how the feature is being used.
  6. Project page: [TBD]
  7. Point person: @pmiazga will be responsible for responding to questions or ideas, and stewarding the process
  8. Known issues/bugs/concerns: [TBD]
  9. Success plan: if the beta test is considered successful we will release the feature in production (on all Wikis?). Before releasing on production we will do QA, as well as another general team review (?).
  10. Additional notes: is there a way for us to add value here beyond what the browser's Share button offers, e.g. allowing users to share a link to a specific section (example here).

can we instrument it in a way so that we can find out if they followed-through with sharing a the link?

yes, that's possible, we need to add some argument to the shared url, something like ....?share_btn, then we will be able to verify how many users are visiting Wikipedia via share links.

But sharing the link and clicking on the shared link are two different actions, taken by (usually) two different users.

I guess Olga was rather referring to the distinction we had made in context of the Print schema between the user hitting the Print to PDF button and then actually printing/saving the PDF in the resulting preview modal (cf. your own research in T181297#3794313).

Would it be possible to similarly instrument the next step in the sharing funnel here, when the user selects an app to share the link with (e.g. clipboard, Twitter, Skype) and the browser passes it to that app?

so it might be okay just to instrument the tapping of the button

we can (and I think we should) do that.

@pmiazga here is a first stab at filling out the Beta feature "template". We can discuss and iterate when we meet.

  1. Feature rationale: we believe that by adding a share button to the article page on mobile web people will share Wikipedia articles more often, ultimately leading to more knowledge being spread and consumed.
  2. What we want to learn: we want to learn if people will discover and use this feature. We know that there is a share functionality built into most browsers, however our hypothesis is that since our share button will be more front-and-center, it will help make sharing top of mind for users, as well as facilitate an easier sharing process.
  3. Instrumentation: [TBD] T207280
  4. Success/failure criteria: we will be tracking the number of taps to the share button. We will control for experimental/exploratory taps.

This seems a good idea but might be a bit of a challenge regarding the instrumentation (see above).

If the number of taps is above __ we will consider the feature successful.

I guess this means the number of taps per pageview? And what might be a good way to get a baseline/benchmark (to fill in the __)?

  1. Duration: we think that four months worth of data will give us a sufficient understanding of how the feature is being used.

How did we arrive at that number?

Tbayer added a comment.EditedMar 2 2019, 1:30 AM

It seems that the Web Share API also supports a "text" field to accompany the shared link. Do we want to make use of this or just pass the naked link (plus maybe page title) for now?
See also T56829 and various other tasks linked there.

We can instrument clicks when share action was triggered, the browser will notify us when a user completed a share action). For example, on Chrome for Android, the returned Promise will resolve after the user chooses an application to share to. Sadly we cannot detect if the article was shared, because this action happens in a different application.

Real life scenarios:
a) User clicks the share button, the device presents share options (email/text message/etc) and the user decides to cancel -> we will not count this as a successful share
b) User clicks the share button, the device presents share options, the user selects email, email editor opens but user decides to delete the draft and not to share -> we will count that as a share action
c) User clicks the share button, selects the email, sends it -> we count this as a share action

As you see, we can only detect early exists (no app opened). Also, I'm afraid that this behavior might be different across different browsers (for now it's supported only in the latest Safari and Chrome).

can we instrument it in a way so that we can find out if they followed-through with sharing a the link?

yes, that's possible, we need to add some argument to the shared url, something like ....?share_btn, then we will be able to verify how many users are visiting Wikipedia via share links.

But sharing the link and clicking on the shared link are two different actions, taken by (usually) two different users.
I guess Olga was rather referring to the distinction we had made in context of the Print schema between the user hitting the Print to PDF button and then actually printing/saving the PDF in the resulting preview modal (cf. your own research in T181297#3794313).
Would it be possible to similarly instrument the next step in the sharing funnel here, when the user selects an app to share the link with (e.g. clipboard, Twitter, Skype) and the browser passes it to that app?

so it might be okay just to instrument the tapping of the button

we can (and I think we should) do that.

I have updated T207280 with more concrete proposals on instrumentation and metrics based on the above discussion.

@pmiazga here is a first stab at filling out the Beta feature "template". We can discuss and iterate when we meet.

...

  1. What we want to learn: we want to learn if people will discover and use this feature. We know that there is a share functionality built into most browsers, however our hypothesis is that since our share button will be more front-and-center, it will help make sharing top of mind for users, as well as facilitate an easier sharing process.

...

  1. Success/failure criteria: we will be tracking the number of taps to the share button. We will control for experimental/exploratory taps.

This seems a good idea but might be a bit of a challenge regarding the instrumentation (see above).

Per @pmiazga's explanation above we can at least track the first two steps of the funnel and the ratio of users (views) who complete the first but not the second seems a reasonable approximation to those "experimental taps" - I have added "abandonment rate" to T207280 in order to address this question.

If the number of taps is above __ we will consider the feature successful.

I guess this means the number of taps per pageview? And what might be a good way to get a baseline/benchmark (to fill in the __)?

I have added share button taps per pageview (i.e. the standard clickthrough ratio metric) to T207280; we could alternatively use the number of share attempts (i.e. "non-abandoned" share button taps) per pageview. One idea for a baseline might be the clickthrough ratio for the PDF download button.