Comments (23)
Is there any user research on how people use this? Do users recognise that it is their device's native sharing dialogue, for example?
from web-share.
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?
from web-share.
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.
from web-share.
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?
from web-share.
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.
from web-share.
@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.
from web-share.
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.
from web-share.
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.
from web-share.
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.
from web-share.
I don't think there has been any user research.
from web-share.
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.
from web-share.
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.
from web-share.
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?
from web-share.
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.
from web-share.
@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.
from web-share.
@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).
from web-share.
@mgiuca, ping. WDYT? Ready for us to move this over?
from web-share.
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.
from web-share.
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.
from web-share.
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!
from web-share.
@siusin, as per above, could you please transfer this repository to the W3C org for us?
from web-share.
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.
from web-share.
Group notified:
https://lists.w3.org/Archives/Public/public-webapps/2019JulSep/0009.html
@siusin, or @mgiuca, could you also make admin on this repo?
from web-share.
Related Issues (20)
- Should sharing zero size files be allowed? HOT 10
- Discord on iOS doesn't return 'success' event HOT 2
- What's the reason to remove web intents from web share besides security concerns HOT 2
- Add example of permission policy use with iframe HOT 2
- Promises cannot be manipulated while "in parallel"
- Call for Consensus: Publish as Candidate Recommendation HOT 1
- Explain implementation status
- "current settings object's relevant global object" is not defined
- Call for consensus: publish as a Proposed Recommendation HOT 1
- Is implemented HOT 4
- Indicate explicitly the intent of the Web Share API regarding cross-origin HOT 1
- Support additional media types? HOT 3
- Base isn't needed in main branch of algorithm HOT 2
- Wrong explanation in example
- Suggesting preview for security should mention accessibility HOT 1
- No explicit acknowledgements? HOT 2
- What's the scope of "abort these steps"? HOT 4
- Make Security Considerations an explicitly named section? HOT 2
- ios web share save file to camera roll only works once HOT 3
- CFC to publish Web Share as a W3C Recommendation HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from web-share.