Confirm
716
edits
Changes
Created page with "== 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 ne..."
== 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'''
# User launches facebook
# User clicks "attach a picture"
# Facebook launches the "pick" WebActivity
# The activity picker comes up.
# User chooses to use the camera app as activity handler
# Camera app is launched
# User takes a picture
# Camera app returns the picture as result of the activity
# Camera app is closed and user is back in facebook app.
'''Using an activity that does not return a value'''
# User goes to news website and finds an interesting article
# User clicks "share" button
# News website lauches the "share" WebActivity
# The activity picker comes up.
# User chooses to use the twitter app as activity handler
# Twitter app is launched
# Twitter app prefills URL of news article as tweet content
# 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 [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].
=== UX issues if the handler app is already running when the activity is launched ===
=== Lack of ability to save intermediate results ===
=== Ability to switch from inline to full-page handler ===
=== Should activity launcher have a say in disposition of the handler? ===
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'''
# User launches facebook
# User clicks "attach a picture"
# Facebook launches the "pick" WebActivity
# The activity picker comes up.
# User chooses to use the camera app as activity handler
# Camera app is launched
# User takes a picture
# Camera app returns the picture as result of the activity
# Camera app is closed and user is back in facebook app.
'''Using an activity that does not return a value'''
# User goes to news website and finds an interesting article
# User clicks "share" button
# News website lauches the "share" WebActivity
# The activity picker comes up.
# User chooses to use the twitter app as activity handler
# Twitter app is launched
# Twitter app prefills URL of news article as tweet content
# 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 [https://docs.google.com/a/readitlater.com/document/d/1S5TnrCMrtaYqPTSK3YUIE-6shWSvRONdEhm74rW7CrE/edit here].
=== UX issues if the handler app is already running when the activity is launched ===
=== Lack of ability to save intermediate results ===
=== Ability to switch from inline to full-page handler ===
=== Should activity launcher have a say in disposition of the handler? ===
