Confirmed users
716
edits
WebAPI/WebActivities/LessonsLearned: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
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. | 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 | To simplify the discussion, here's two standard flows when using WebActivities | ||
| Line 41: | Line 43: | ||
== UX issues with opening in activities in a new app/tab == | == UX issues with opening in activities in a new app/tab == | ||
In FirefoxOS a webactivity always launches a new | In FirefoxOS a webactivity always launches a new 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. | 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. | ||
| Line 67: | Line 69: | ||
For other activity handlers a good default is likely to always open a new tab to handle the activity. | For other activity handlers a good default is likely to always open a new tab to handle the activity. | ||
But we could also enable handing an activity using an existing page by allowing using a ServiceWorker as activity handler, and then allow the service worker to delegate to an already open page. Possibly we could even allow the ServiceWorker to open a disposition:inline activity. | |||
== Lack of ability to save intermediate results == | == Lack of ability to save intermediate results == | ||
Consider a "Google Drive" | Consider a "Google Drive" app that uses an "edit" activity to launch a "photoshop" 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 | 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 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. | 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 | A bigger problem is that photoshop would not be able to save intermediate drafts to the Google Drive app. It would either not save them at all, which means risking more dataloss in case of a crash or accidentally closing the app, 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. | 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. | ||
| Line 89: | Line 91: | ||
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. | 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- | == Ability to switch from inline to full-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. | 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- | This gets especially tricky for activity handlers that return a value. In this case the full-window handler would need to be rendered on top of the current app, 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''' | '''Recommended solutions''' | ||
| Line 99: | Line 101: | ||
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. | 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. | ||
What might help is to force this scenario to be handled by allowing a ServiceWorker to handle the activity and then allowing the ServiceWorker to open inline or full-window handlers on top of the initiating app. | |||
Activity handlers that don't return a value can always open new pages using target=_blank links or window.open calls. | |||
== Should activity launcher have a say in the disposition of the handler? == | == Should activity launcher have a say in the disposition of the handler? == | ||
| Line 105: | Line 109: | ||
''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.'' | ''This is mostly based on notes from a WebActivities/Web Intents discussion. I sadly don't remember all the details here.'' | ||
For activities that | For activities that do not return a value, the initiating 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 | 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 app, or if opening Photoshop should be treated like opening a <tt><a target="_blank"></tt> link. | ||
'''Recommended solutions''' | '''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. | 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? | 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? | ||