3 ms·

I'm not sure exactly what you mean by each of these, but at least in Android apps can register to open URLs. So you can search for and share, say, a Facebook li

I'm not sure exactly what you mean by each of these, but at least in Android apps can register to open URLs. So you can search for and share, say, a Facebook link. Tap it, and it opens in the Facebook app (or the browser, or any other app registered to handle the URL, your choice!).

Sylos 10y ago
I think these are the definitions that he/she goes by: Searchable: It being possible to find contents on the service via web search engines (Google, Bing, Yahoo!, DuckDuckGo etc.). Deep linkable: It being possible to link to specific content on the service (and not just to the service as a whole). Shareable: It being likely that your service as a whole is linked to. While you can share with someone that an app exists, it's far less likely that users will do so, because of the install-barrier. And what you mentioned requires the service to maintain both an app and a webpage, so that doesn't work when we're talking about dropping the webpage...
- jdmichal 10y ago
  So the criticism is that apps alone, without a web presence, cannot be "searchable" and "sharable". "Deep-linkable" is still possible; your app can handle and resolve URLs that another app could not. And I'm going to assume that it's the content of the app we're discussing, and not the app itself, since that's kind of trivial. So, the question is, without a web presence or API of some type, how exactly is data expected to be searched and shared by third-party participants? If the argument is that apps don't solve the problem of having a universal ontology, then I think the GP is not quite understanding just how intractable a problem that has been in computer science for a very long time.
tootie 10y ago
They're achievable, but not native. You can't make your content crawlable unless it's on the web. You can deep link and share, but only if you explicitly build all of that while it's native to the web. And another one that always annoys the hell out of me is that I can't search text on an app screen. Again, you could build it yourself, but very few apps actually do.

Sylos 10y ago

I think these are the definitions that he/she goes by: Searchable: It being possible to find contents on the service via web search engines (Google, Bing, Yahoo!, DuckDuckGo etc.). Deep linkable: It being possible to link to specific content on the service (and not just to the service as a whole). Shareable: It being likely that your service as a whole is linked to. While you can share with someone that an app exists, it's far less likely that users will do so, because of the install-barrier. And what you mentioned requires the service to maintain both an app and a webpage, so that doesn't work when we're talking about dropping the webpage...

jdmichal 10y ago
So the criticism is that apps alone, without a web presence, cannot be "searchable" and "sharable". "Deep-linkable" is still possible; your app can handle and resolve URLs that another app could not. And I'm going to assume that it's the content of the app we're discussing, and not the app itself, since that's kind of trivial. So, the question is, without a web presence or API of some type, how exactly is data expected to be searched and shared by third-party participants? If the argument is that apps don't solve the problem of having a universal ontology, then I think the GP is not quite understanding just how intractable a problem that has been in computer science for a very long time.

tootie 10y ago

They're achievable, but not native. You can't make your content crawlable unless it's on the web. You can deep link and share, but only if you explicitly build all of that while it's native to the web. And another one that always annoys the hell out of me is that I can't search text on an app screen. Again, you could build it yourself, but very few apps actually do.