Re: [manifest] A way to link to related applications (#326)

On March 7, 2015 at 2:18:21 AM, Ben Francis (notifications@github.com) wrote:
> >
> This sounds bad for the web as it risks further fragmenting the  
> web into multiple walled gardens of content. 

It's the reality, tho. Please go and check Alexa's top 100 on iOS (and probably on Android): the majority of web apps are door slamming. Also, pretending the web is good enough by not providing this capability, when the Web is clearly not right now, doesn't help end-users (and just leads to either proprietary solutions to address this problem, as is currently done by Microsoft and Apple, or developers themselves doing the doorslam - or a combination of both, which I've also seen). 

The only way to stop door-slams is to make a better Web platform (i.e., developers not bothering to make a native alternative because "the Web is that good") - but, we are nowhere near close to that yet (if ever!): thus, allowing developers to easily link to their native alternatives seems fine. It's not a "one or the other" thing. Web apps and native apps have always co-exsisted - hell, a browser is just another native app that makes use of a webview, after all. The ultimate goal here is making more powerful webviews and getting the browser chrome out of the way. 

Let's play nice with native apps. Let's show them the <3 they deserve because, today, they really do make phones, tablets, and computers really really awesome to use (much more than a lot of web apps can do ... heh, listen to me ... I'm such a sell out, but it's true :)). 

> Whether or not to  
> include this in the spec probably comes down to what is the lesser  
> of two evils:
> a) Putting up with the current slam-door approach of mobile web  
> sites which force

Few will "force" a user to download an app (I've only seen Pandora do this... probably Spotify does this too). Most provide a web interface alternative.  

> users to download a non-web app based on a UA  
> string by refusing to display, and the use of proprietary meta  
> tags.
> b) Adding something to the web manifest spec which is explicitly  
> not to do with web apps and is intended to draw users away from the  
> web.

In b, a user could choose in the UA: "never show me native alternatives". That seems like a good alternative to me. 

>  
>  
> I actually quite like Android's:
>  
> except that the href attribute points to a non-web "hypertext  
> reference" with a proprietary URL scheme.
>  

Linking to alternative schemes is fine, and works well bridging the Web/native divide. 

> If we wanted to add something similar to the manifest to link to  
> alternative apps, ideally the alternative app would have a web  
> URL and a Content Type:

Content types are discriminatory hints, they don't mean anything. In particular, how would iOS know which link to provide given these three have the same content type: 

> "type": "application/octet-stream",
> "href": "https://itunes.apple.com/gb/app/facebook/id284882215"  
> },
> {
> "type": "application/octet-stream",
> "href": "http://apps.microsoft.com/windows/en-gb/app/facebook/add3d66a-358d-4fe2-be68-8a3f934e9ea1"  
> {
> "type": "application/octet-stream",
> "href": "http://appworld.blackberry.com/webstore/content/680/"  
> }

The only way would be to sniff the "itunes.apple.com" part of the URL (hence the `type` serves no purpose). Keying off the os would be better. It would also make this much easier to use, rather than having to look up weird MIME type strings.   

> That's maybe a bit odd because the URL doesn't point to an alternate  
> app manifest or even the app itself, but a web page which describes  
> an alternate app. That's maybe the best we could do given that  
> non-web apps don't tend to have web URLs!

They are links to the store page - not to the app. You don't just install apps: you first check them out, see if it's the right one (or maybe check for cheaper/higher-rated alternatives), then install them.  

> Hopefully this example also illustrates how badly this scales.  

I think discriminating on os type might be fine. This scales badly no matter what, so the following would be fine too:

```JSON
{
   "related_applications": { 
      "ios": {...},
      "android": {...},
      "windows": { ... }
   }
}
```

It's just a sad acceptance of the current reality (with the problem that those OS and store links could easily break, and it's pretty sad for longevity). But whatever, it would get the job done and allow end-users to complete whatever task/thing they are trying to do with the best tool available to them (be it a web app or a native app).  

> Alternatively, implementers could add vendor-prefixed properties  
> to the manifest for this purpose, using whatever identifiers  
> they like.

If it was only one vendor wanting this, then absolutely this should be a prefixed thing. However, the feedback I've received is that there is enough overlap between vendor solutions - and enough vendor interest - that a standardized alternative makes sense. 







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