New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 744712 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Jul 13
Cc:
dominickn@chromium.org
█ owe...@chromium.org
benwells@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

Investigate feasibility of instant-adding webapks/a2hs

Project Member Reported by yfried...@chromium.org, Jul 17 2017 
Rather than waiting for install to complete, I think we have all the information we need to launch a webapk from the already running page. We could conceivably use tab reparenting and change the UX to support this.

Hacked up demo (internal only, sorry): https://drive.google.com/open?id=0B9XX_6R5yUzKa3RTYVFvT2xWX0U
The one thing I didn't get to last week was changing the UX from app banner to something like snackbar or temporary notification which I think is more natural for something happening in the background.

There are some concerns with this. The biggest one I think is that if it fails late, it might be hard to explain/message to the user. We'd also need to teach some of the webapk code about a pending install vs assuming it's installed.

+some installability folk as this would definitely impact their work and may be more in their sphere of influence but I think this or something like it is important to hide webapk install latency.

Comment 1 by owe...@chromium.org, Jul 17 2017 

Very interesting, thanks for trying this out!

It's worth mentioning that in the pre-WebAPK world we explored UX where pressing the button took the user to their homescreen to see the new icon appear. We ended up moving away from that (Avni Shah though it was distracting), but since then we've not experimented with jumping the user straight into standalone mode etc.

Yaron - what are your thoughts about this experiment? Is it more of a misc thought / experiment or would you like to explore the feasibility of taking this forward in the next Q?

If so I think it'd be really good to do another round of work with UX on how the banner should work, what the add button should do (just add it vs add and open, vs add and take you to home screen) since I think there are various UX tradeoffs here to consider!

Comment 2 by owe...@chromium.org, Jul 17 2017

Labels: -M-62

Comment 3 by dominickn@chromium.org, Jul 18 2017 

This is a great way of hiding the installation latency, though like Owen mentioned, my main concern is working on whether jumping straight into a WebAPK standalone is smooth / expected / breaks user expectation.

We are currently in the process of converting the app banner to be a modal, so the UX would neatly dovetail there (we need to introduce some other way of telling the user that an installation is happening since keeping the modal on the screen is really bad).

Comment 4 by yfried...@chromium.org, Jul 18 2017 

#1: My thought is that our current UX is not good enough given android app install latency and we *must* do something. I mean at this point, on some connection types an Instant App may open quicker because they intentionally skirted the installation part. Given that, I thought it would be interesting to take you straight to the webapp in full-screen but I'm not married to that idea. I'd be totally fine if we have a modal and hide it quickly but IMHO, I think we should prioritize changing this (that's why I added 62 label - to get some attention :).

#3: modal would be fine if it takes longer to see my proposal through fruition or we're unsure of whether to launch the PWA right away. My prototype was to show that it's feasible

Comment 5 by yfried...@chromium.org, Jul 13

Status: WontFix (was: Untriaged)
We ended up doing an async install flow
►

Sign in to add a comment