Web Share Origin Trial results so far (M56)
Matt Giuca
Summary
The Web Share origin trial started in Chrome 55. Chrome 57 is the last release it is intended to be available as an Origin Trial. We have now collected various feedback and are sharing it according to the Origin Trials process.
Note we’re publishing feedback before the end of the trial in order to provide time to land code, enable or disable the feature etc in the first release after the trial ends.
Intent to experiment: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zuqQaLp3js8
Contact email
Spec and chromestatus.com entry
https://github.com/WICG/web-share/blob/master/docs/interface.md
https://www.chromestatus.com/feature/5668769141620736
Developer interest
As of 2017-03-23, 208 origins have registered for access to the origin trial. Of those origins, 52 had tokens renewed at least once for this feature.
For example, https://santatracker.google.com used Web Share to implement a share button to share the URL of the current page.
Developer feedback
This feedback is based on the Origin Trial survey sent to developers who signed up for a trial key, and the bug reports on https://github.com/WICG/web-share/issues.
We received the following positive feedback (number indicates the number of responses that echoed that sentiment):
Easy for developers to use (22)
Being able to share to native apps (10)
Generic “works like a native app” (10)
Better user experience (5)
Fills a gap in the Web platform (4)
Size / performance compared to third-party share plugins (3)
More share targets than an existing targets available on the Web (3)
User choice of share target (3)
Being able to show native / system UI for picking a target (2)
Works on Android (2)
Can be used as a progressive enhancement (feature detection) (2)
Removes need to use third-party share plugins (1)
Allows for a more minimal UI on web pages (1)
High click-through rate once share dialog is open (1)
The following requests came for improvements to the feature:
Performance of triggering the intent (2)
Unclear / open to interpretation what the fields mean (1)
“e.g. share to Inbox results in domain for subject, then description and target on one line.”
Useless options appear in the share list (1)
One response cites “Dropbox” as a useless target (makes sense if you are sharing a URL).
Perhaps this means we need better filtering controls.
Bug (outstanding): navigator.share does not reject promise when user cancels picker (1)
Support from other browsers (1)
Safari specifically mentioned.
Add text language / direction attributes (1)
Requests for things we already plan to add in the future:
Web Share Target (ability for websites to receive shares) (11)
Improved documentation (6)
Support for sharing other media types (images, MediaElement, etc) (4)
Desktop support (2)
iOS support (1)
More intent types (1)
Request for a separate “save” intent.
Things we don’t plan to do
Web page being able to see or filter what targets are available (4)
We don’t allow this for security reasons. However, we may be able to add some declarative filtering options.
Better fallback support (not really clear what these people want) (3)
Fallback to a pure web share should be implemented by the site, after feature detection (as documented).
Response from the share target back to the sender (1)
An “edit” scenario would support this, but sharing is one-way by design.
Remove/weaken the user gesture restriction (1)
Developer wants to have a user gesture trigger a URL fetch, and in the response to the fetch, trigger a web share. Possibly some way to do this but possibly can be worked around by pre-fetching data.
Users might not understand what it’s for before they trigger it (1)
Can’t solve this by changing the API. The site should make it clear, e.g., using tooltips.
Add a way to inject metrics into the shared URL (1)
Better define success / failure (1)
Lessons learned from our goals for experimentation
Does it make sense to do this as an imperative API, or do developers prefer just a special URL scheme?
No developers requested a URL scheme to share to. By far the highest positive response (nearly half of all responses) said the API was easy to use.
What fields do developers want to put in the share object?
Images (most common)
Sounds
HTMLMediaElement (audio, video)
Timeline
First stable release enabled: Chrome 55: 2016-12-06
First stable release with feature disabled: Chrome 58: 2017-04-24 (approx)
Usage data (UMA)
The following metrics come from UMA and are not adjusted for UMA opt in rates.
Note: We only consider two metrics: WebShare.ApiCount.Share and WebShare.ShareOutcome.Success. All the other WebShare metrics are currently broken (explained below).
Total shares per day (WebShare.ApiCount.Share):
For most of the trial period (starting 2016-12-06), navigator.share was called between 10 and 40 times per day. However, there have been some spikes.
Huge spike on 2016-12-24 (presumed to be Google Santa Tracker); 13.7k shares on that day.
2.3k shares on 2017-02-02 (unknown attribution).
Slow ramp up starting on 2017-03-08 for about four days (unknown attribution). Since then (for about two weeks), have been getting 200-400 shares per day.
Dialog acceptance rate (WebShare.ShareOutcome.Success / WebShare.ApiCount.Share):
During the 2016-12-24 spike, only 27% of dialogs were accepted.
During the 2017-02-02 spike, only 14% of dialogs were accepted.
During the last two weeks of relatively high activity, about 40--60% of dialogs are accepted.
It’s interesting how low the acceptance rate is on the first two spikes. Hard to explain without context, but my guess is that a) users are clicking a share button without knowing what it is, then backing out, and/or b) users are clicking the share button, cancelling, then sharing again. (We don’t have data on shares-per-page-view yet.)
Notes on bad metrics:
We would like to use Blink.UseCounter.Features.WebShareShare (the general Blink use counter) to know how many shares there are, de-duplicating multiple shares per page view. However, this new metric only rolls out in M57 and we don’t have much stable data from this yet. (The old version of this metric, WebCore.FeatureObserver.WebShareShare, is showing 4--7 times more than the WebShare.ApiCount.Share, implying people are doing 4--7 shares per page view, which seems absurd; this metric is horribly broken due to https://crbug.com/676837).
Due to a broken API on Android, we are unable to detect dialog cancellation (https://crbug.com/636274). Therefore, WebShare.ShareOutcome.Canceled is under-reported, so we ignore it and just compare Success against the total Share count.