Confirm
716
edits
Changes
no edit summary
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.
Below I'll use the term 'app' not to refer to a Android/iOS installed app, but rather to the generic concept of a webapp.
To simplify the discussion, here's two standard flows when using WebActivities
== UX issues with opening in activities in a new app/tab ==
In FirefoxOS a webactivity always launches a new fullpage fullscreen 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.
For other activity handlers a good default is likely to always open a new tab to handle the activity.
== Lack of ability to save intermediate results ==
Consider a "Google Drive" page app that uses an "edit" activity to launch a "photoshop" page app in order to edit a picture file.
In the current WebActivities and Web Intents implementations, the only way to accomplish this would be to have the photoshop "edit" activity handler return the edited image once the user was done editing, and then have the Google Drive page app save the resulting file.
There are a couple of issues with this flow though. First off given that the activity would be one returning a value, the photoshop app would have to be opened on top of Google Drive. This isn't always desirable.
A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive pageapp. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the pageapp, or it would have to save them somewhere in photoshop's storage area. In case of crash it would be awkward to get the edited data back into Google drive. The user would have to relaunch the edit activity and select photoshop again, and then photoshop would have to detect that the same file was being edited and offer to reuse the previously saved draft.
A desired flow here is instead to enable Google Drive to launch the "edit" activity such that Photoshop could be opened in a new window. But also enable Photoshop to have an open communication channel back to Google Drive. However the user should be able to close the Google Drive tab while still enabling Photoshop to send data to Google Drive in order to save intermediate drafts.
The app initiating the activity would also need to provide some arbitrary data which is passed back any time messages are sent from the activity handler and which can't be altered by the activity handler. In the example above the Google Drive app could provide the filename of the file being edited.
== Ability to switch from inline to full-page window handler ==
A disposition:inline handler might need to defer to a more complex UI depending on user actions. For example a facebook "share" handler might start as an inline handler, but need to switch to a more complex UI if the user wants to configure security settings or add complex data to the post.
This gets especially tricky for activity handlers that return a value. In this case the full-page window handler would need to be rendered on top of the current pageapp, I.e. it couldn't be handled like a normal window.open with target=_blank. Additionally the new page needs to take over the responsibility of returning a value.
'''Recommended solutions'''
Sadly I don't have any recommendations here. Possibly simply not supporting this scenario is the right solution for now. Instead we can allow a display:inline handler to resize itself to handle the more complex UI.
== Should activity launcher have a say in the disposition of the handler? ==
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.''
For activities that does do not return a value, the initiating page app might want to treat launching the activity handler as either a "navigation" or as a "open in new tab".
In the Google Drive/Photoshop example above, it seems like it should be the decision of the Google Drive app if Photoshop should replace the Google Drive pageapp, or if opening Photoshop should be treated like opening a <tt><a target="_blank"></tt> link.
'''Recommended solutions'''
We could support a ''target'' attribute when initiating an activity. The target would be ignored for activities that return a value, and possibly also for disposition:inline activities. However I don't know of use cases which involve targeting named windows, so possibly a ''target'' attribute is too generic.
Another question is if it should be possible to target _self if the current page is open in an iframe. I.e. should activity handlers need to worry about possibly being opened in a subframe?
