Intent to Migrate Web Share API about web-share

[edent]

Is there any user research on how people use this? Do users recognise that it is their device's native sharing dialogue, for example?

[edent]

I don't see how this can continue without any user research.

Is there evidence that actual users want this? If not, how can we know if this is a useful feature?

[raymeskhoury]

Is there evidence that actual users want this? If not, how can we know if this is a useful feature?

There are close to 1,000,000 navigator.share calls each day from Chrome on Android browsers, which is significant evidence.

[grorg]

What results do you expect out of the user study? Since this API triggers the native UI, wouldn't the results be very dependent on the platform?

Also, while users are obviously the most important, the API was designed for developers. The goal is to give them an alternative to embedding endless share options in their content. How would you ask end users whether or not that goal was achieved?

[ewilligers]

Blink is preparing to ship Level 2 (file sharing): chromestatus.
Some of the questions may have been addressed in the Intent To Ship.
Usage has been low. We are anticipating an increase when Level 2 ships.

[marcoscaceres]

@ericwilligers, ok cool. Have you reached out to anyone on the Safari/WebKit team to gauge their interest? I've not had a chance to look at the L2 stuff yet from a Mozilla perspective.

[ewilligers]

We have kept the Safari team (@hortont424 @hober) updated about out plans, but haven't heard if there is Apple interest in the Level 2 functionality.

[hober]

We have kept the Safari team (@hortont424 @hober) updated about out plans, but haven't heard if there is Apple interest in the Level 2 functionality.

I'm sorry if I've missed something; did you CC us on a GitHub issue or something? Odds are very good that I won't see something if it's lost in the firehose of GitHub notifications.

[ewilligers]

did you CC us on a GitHub issue or something?

Not GitHub. I'm referring the "Web Share API future directions" emails from Matt, Tim in October and from myself in April.

[ewilligers]

I don't think there has been any user research.

[philnash]

Do you also record how many of those navigator.share calls result in a successful share? I'm a fan of this as a developer, but the success rate might well show more what users are experiencing.

[ewilligers]

Here are some early estimates from https://www.chromestatus.com/metrics/feature/popularity

About 0.0069% of pages are calling share().

About 0.0050% of pages are experiencing a successful share() that involves files.
About 0.0036% of pages are experiencing a successful share() that does not involve files.
About 0.0012% of pages are experiencing an unsuccessful share().

Here, success means that the user selected a share target, and so the promise resolved.

Pages may call share() more than once. We don't directly record the percentage of share() calls that result in a successful share.

[edent]

OK, that's a good start. Has there been any direct user research? That is, conversations with end users to see what their intention is? Whether they like the experience? If it meets their needs?

[GirlyGeekdom]

I'd be fascinated to understand your user scenarios. Do you see this being for anything or for specific scenarios. Public or private sharing? These are fundamentally different things and from a user perspective they are really important.

Consider this scenario. Social media content sharing. This could be done in the way you described in your outline however beyond the endpoint, content and source there are some other parameters that also get shared such as location, cookie tracking data, shared via app name etc.

If you consider it in terms of I want to share an image with my friend... I may wish to also share my location, my availability and my mobile number.

But if I were to share the same information with a stranger I wouldn't want them to have any of the extra information. But I may want to know more about who they are and why they want my data.

The concept appears on the surface as simple but in reality if this is going to be useful and for the benefit of the users then it needs a user centric approach.

[marcoscaceres]

@GirlyGeekdom wrote:

I'd be fascinated to understand your user scenarios. Do you see this being for anything or for specific scenarios. Public or private sharing? These are fundamentally different things and from a user perspective they are really important.

We are incrementally building this up on the most simple share types... so, starting with just some text and URLs.

Consider this scenario. Social media content sharing. This could be done in the way you described in your outline however beyond the endpoint, content and source there are some other parameters that also get shared such as location, cookie tracking data, shared via app name etc.

Good point. For privacy reasons, we want to limit things like that above as much as possible (specially tracking cookies... thought tracking identifiers could be shared by the URL, like those pesky utm_* search params).

If you consider it in terms of I want to share an image with my friend... I may wish to also share my location, my availability and my mobile number.
But if I were to share the same information with a stranger I wouldn't want them to have any of the extra information. But I may want to know more about who they are and why they want my data.

Sure... the share dialog could give you control over that (if we eventually add support for sharing location in the future).

The concept appears on the surface as simple but in reality if this is going to be useful and for the benefit of the users then it needs a user centric approach.

Agree... definitely something we will incrementally work towards over time.

[marcoscaceres]

@mgiuca, I'd like your ok before moving this to the Web Apps WG.

Some things that we will need address once we move this: the Level 2 features will need to be merged into L1, but as pull requests requiring multiple browser vendors to give implementation commitment (as per the WebApps Charter).

[marcoscaceres]

@mgiuca, ping. WDYT? Ready for us to move this over?

[mgiuca]

Yes, I'm ready to move this under the WebApps Charter.

Will this mean any changes for the spec organisation? I would imagine this moves the GitHub URL from WICG, but would it stay in its own spec for the time being?

I'm not sure why L2 needs to be merged into L1. We designed L2 not as a "version 2 of the spec" but rather as a second level of implementation support, with the idea that L1 is fairly straightforward to implement, whereas L2 is more complex and also might not make as much sense on some platforms (if they can't share binary data), so we made those features individually detectable. I think there's value in an implementation striving to support the L1 features first before hitting L2. If it simplifies things, though, we can combine them into one spec.

[marcoscaceres]

Will this mean any changes for the spec organisation?

No. It shouldn't. It will become an "ED", which we can then publish as a FPWD. But that's it.

I would imagine this moves the GitHub URL from WICG, but would it stay in its own spec for the time being?

Yes, it will stay as its own spec, and we can set up a redirect to keep the current URL... everything should work as it does today.

I'm not sure why L2 needs to be merged into L1. We designed L2 not as a "version 2 of the spec" but rather as a second level of implementation support, with the idea that L1 is fairly straightforward to implement, whereas L2 is more complex and also might not make as much sense on some platforms (if they can't share binary data), so we made those features individually detectable.

The technical challenges are somewhat independent of the standardization challenges: standardization for L2 is centered around getting other browser vendors to commit to implementing L2 features... in other words, we need to convince Mozilla and Apple to get behind aspects of L2.

We then have options: we can send things as Pull Requests to be part of L1 with the proviso that everyone agrees to implement in a timely manner. Or we can sit things in pull requests, until such time that implementers are willing to support whatever feature (the "WHATWG working mode"). Or we leave make a new "web-share-2" repo here, which allows for the continued incubation of Share L2, but with the ultimate aim of getting a second implementation.

Personally, I prefer the "WHATWG Working Mode" - which closely matches the requirements from the WebApps Charter and is enforced by the PULL_REQUEST_TEMPLATE associated with each WebAppsWG repository.

I think there's value in an implementation striving to support the L1 features first before hitting L2.

We are already there, no? With Chrome and Safari - and Firefox on the way. There are some interop issues/edge cases, but no show stoppers.

If it simplifies things, though, we can combine them into one spec.

It does in as far as it reflects "standardization" (i.e., two or more browsers willing to support a feature). It also forces us to be more rigorous with each proposals: two interoperable implementations, complete with a full test suite, for each new feature. By forcing 2+ implementation and testing, we end up with a much higher quality spec and we are able to catch many more bugs before anything lands in the spec.

Let me know if the above raises additional questions. If no, I can begin the process of transitioning this over.

[mgiuca]

We are already there, no? With Chrome and Safari - and Firefox on the way. There are some interop issues/edge cases, but no show stoppers.

Right, but that's exactly why the split is helpful, because we have L1 reasonably agreed and implemented, but L2 is a bit more shaky.

Seems like for now it's worth moving L1 into ED and then we can decide later whether to move things from L2 in there or create a second Level 2 document in the Apps WG. (We might decide on a case-by-case basis, for example canShare might move into the L1 while file sharing might remain as an optional feature.)

Let me know if the above raises additional questions. If no, I can begin the process of transitioning this over.

Go ahead and move it over. Thanks!

[marcoscaceres]

@siusin, as per above, could you please transfer this repository to the W3C org for us?

[siusin]

Thanks all. This repo has been transferred to the W3C org.

The WebApps-WG GitHub team members will have the write access to this repo (and the other webapps wg repos). Please let us know if you would like to be part of this team.

[marcoscaceres]

Group notified:
https://lists.w3.org/Archives/Public/public-webapps/2019JulSep/0009.html

@siusin, or @mgiuca, could you also make admin on this repo?