WebAPI/WebActivities/LessonsLearned

Lessons Learned

Based on internal experience, as well as experience talking with other partners like Google and Pocket, we have learned a lot about how to design the next iteration of WebActivities.

To simplify the discussion, here's two standard flows when using WebActivities

Using an activity that returns a value

1. User launches facebook
2. User clicks "attach a picture"
3. Facebook launches the "pick" WebActivity
4. The activity picker comes up.
5. User chooses to use the camera app as activity handler
6. Camera app is launched
7. User takes a picture
8. Camera app returns the picture as result of the activity
9. Camera app is closed and user is back in facebook app.

Using an activity that does not return a value

1. User goes to news website and finds an interesting article
2. User clicks "share" button
3. News website lauches the "share" WebActivity
4. The activity picker comes up.
5. User chooses to use the twitter app as activity handler
6. Twitter app is launched
7. Twitter app prefills URL of news article as tweet content
8. User writes short message to go along with the URL and submits the tweet

UX issues with activities that return a value

In FirefoxOS, if the user in step 7 of the returns a value flow temporarily switches app, for example to look something up, or to answer an incoming phone call, then the activity is aborted and facebook receives an error message. We were forced to do this in order to deal with the situation when the user might switch back to the facebook app, in which case we didn't want to force facebook to deal with having to implement a sensible UI while the activity was still in progress. However aborting the activity just because the user looked something up is obviously bad.

In Chrome's Web Intents, step 6 of returns a value flow launches the camera app in a separate tab in the browser. That creates an awkward relationship between the tab with the facebook app and the tab with camera app. In particular, if the user closes the facebook tab, then when the picture is taken, it's dropped on the floor since there is no facebook app to receive it.

Recommended solutions For activities that return a value, the activity handler should be overlayed on top of the initiating app. I.e. in the example above the camera app should be rendered on top of the facebook app.

In a small-screen device this means that when the application switcher shouldn't display facebook and the camera as two separate apps currently running. Instead only the facebook app should be listed, though possibly the UI could somehow indicate that the facebook app is currently using the camera app or some such. Switching to the facebook app should render the camera app on top of it.

On a large-screen device with a traditional tabbed browser UI, the camera app should be rendered in the same tab as the facebook app. I.e. the camera app would be on top of the facebook app.

UX issues with opening in activities in a new app/tab

In FirefoxOS a webactivity always launches a new fullpage app. This makes activities always have a fairly heavy flow since it involves two app switches, one to the activity handler, and one to switch back to the original app.

Activity handlers that want to implement things like "save this for later" or "share on my photo stream" only needs to display minimal UI that doesn't take the user out of the current app.

Recommended solutions We should implement a "disposition: 'inline'" like what Web Intents has. This is already specified for WebActivities but was never implemented. An inline handler would be rendered like a "dialog" on top of the current app.

On large-screen devices this likely means that it sizes to content. On small-screen devices this might simply mean that it doesn't take up the full screen.

We'll likely need the ability for an inline activity handler to defer to a full-page handler in response to user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a fullpage UI if the user wants to configure security settings or add complex data to the post.

Pocket also has dome some really great research here.

This research proposes even allowing overlays that render directly on top of the initiating app. This provides for some pretty awesome UI, but also exposes issues like clickjacking. Ideally disposition:inline can bring most of the benefits of this proposal, while still not exposing clickjacking risks.

UX issues if the handler app is already running when the activity is launched

In FirefoxOS's implementation of WebActivities, if the twitter app was already running in the background when the does not return a value flow happens, we switch to the twitter app and send a message to it and ask it to handle the activity. However this means that the app has to leave it's current state in order to do so. So if the user was in the middle of some other task within the twitter app, that is now lost.

Recommended solutions If we follow the recommendation above for UX issues with activities that return a value that actually solves the problem for activities that return a value. A new page will always be opened and rendered on top of the app that initiated the activity.

Likewise disposition:inline activities will also not suffer this problem since they open a new page inside the inline UI on top of the page that initiated the activity.

For other activity handlers a good solution might be to fire an event in the handlers ServiceWorker and let the worker decide if a new page should be opened, or if an existing page could be used.

Lack of ability to save intermediate results

Consider a "Google Drive" page that uses an "edit" activity to launch a "photoshop" page in order to edit a picture file. Once the user is done editing the picture the photoshop page could return the edited picture to the Google Drive page and Google Drive could save the edited picture using application specific logic.

There are a couple of issues with this flow though. First off given that a return

One flow that is currently not supported by neither WebActivities or Web Intents is the ability for a

Should activity launcher have a say in disposition of the handler?

For activities that does not return a value, the initiating page might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".