Re: [manifest] Allow multiple application contexts per app (#294)

On January 12, 2015 at 11:05:44 PM, Ben Francis (notifications@github.com) wrote:
> > 6. As foo.com/app is in scope of an installed web app (Foo!), browser MAY indicate that  
> Foo! is already installed and the user can switch to Foo app:
>  
> I would actually go further than this and say that the user agent MAY just automatically  
> switch to the app and carry out the navigation there, rather than prompting the user.  
> Once an app is installed, it is registered as managing that part of the web, and should  
> always do so. But that should probably be left down to the implementation.

Agree. That's a UX decision. I personally wouldn't like this, as when I'm "surfing the web" I generally don't want to be taken out of that context. 

> > 9. foo.com/form.html detects that it's about to unload. Alerts users that they could  
> lose work.
>  
> If an app can only have one application context, this would be the only option. If an app  
> could have multiple application contexts, the user agent could instead create an additional  
> application context for the app to navigate to foo.com/app/whatever.html without  
> having to unload foo.com/form.html.

Again, this is something for UX people to play around with. IMO, it could become really confusing if multiple versions of an app were running at the same time: thinking of how confusing it is having multiple application windows in traditional desktop software and how easy it is to lose a window. 

> > Installed app (opening windows)
> ...
> > 4. Overlay browser is shown. bbc.co.uk/news/some_story is shown.
>  
> I think that by default this should open in a new browsing context in the browser, not an  
> overlay window on top of the app, because it is out of scope of the app.

Again, it's a UX thing to explore. For me, jumping to another app breaks user expectation - in that it yanks the user from one context into another context (thinking of how confusing Android is in this respect). The overlay model is, IMO, better because it doesn't take the user from one application context to another: through the appropriate visual queues, it's always clear which application you are in and what you are doing: user story - "I'm in twitter, I followed a link to a news story. I'm reading the story, following links within that story... and if I press here (X) I close this overlay window and return to twitter". 

> There may be cases  
> where the app author wants to opt-in to staying inside the app, for that I suggest something  
> like using a "dialog" feature of window.open().

We would need to look at individual cases. The only use case I can think of for leaving an app is to have another application do something as part of an action (or because the overlay is not able to render the page properly for whatever reason - and I need to open the page in a different browser). 

For general browsing, can you think of any reason why one would want to open a browser from within an application without using an overlay browsing context? 

> > Identity is still problematic. There can be a third app that can subsume Foo!'s scope  
> and start URL.
> Need to deal with that in a separate bug.
>  
> I think two apps shouldn't be allowed to have overlapping scope. This could be done by  
> either by the user agent refusing to install an app with a scope which overlaps that of  
> another installed app, or alternatively by using the "last registration wins" approach  
> taken by Service Worker scope.

I was thinking something similar - however, both approaches have really bad consequences, which directly affect users, rather than applications (which is why I think it's ok for service workers to have the "last reg. wins" model, but not ok for manifest). 

Anyway, let's handle that elsewhere. 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/294#issuecomment-69673720