search

w3c / web-share-target

Web API proposal for receiving shared data
https://w3c.github.io/web-share-target/
Other
191 stars 20 forks source link

Approach 1 does not support a no-interruption UX flow #39

Closed bard closed 6 years ago

bard commented 6 years ago

The currently implemented approach ("Approach 1" in the explainer document) doesn't serve well applications that are meant to receive frequent shares without interrupting user flow, such as bookmarking or web-clipping applications. Ideally these applications would receive and handle a share without needing a UI switch and extra interactions, showing at most an overlay notification to confirm a successful operation. Google Keep works like that, in fact.

With Approach 1, the UX involves a UI switch and two extra taps:

  1. user shares from browser
  2. UI of PWA opens (UI switch)
  3. pre-filled form is shown to the user based on query parameters of the share_target URL
  4. user must hit a "submit" button (extra tap nr. 1)
  5. confirmation is shown
  6. user must hit the back button to return to browser (extra tap nr. 2)

Please consider implementing Approach 2 as that would allow building a more appropriate UX.

mgiuca commented 6 years ago

We now have a fairly comprehensive plan for this type of experience, which is to combine Approach 1 with the proposed launch event. (Web Share Target is explicitly mentioned in that explainer doc.)

This allows you to use URL-based share targets rather than the more complex SW-event-based, but in the rare cases where a SW event is desired (and no UI should be shown), you can hook into the navigation, intercept it, cancel the window from being shown, display a notification instead, and do back-end processing.

Let me know if you think this solves your use case.

bard commented 6 years ago

Indeed looks like it does. Is this in Chrome Canary or elsewhere already?

ewilligers commented 6 years ago

Is this in Chrome Canary or elsewhere already?

No, the launch event design is still being refined.