[The web app "discovery problem"](https://remysharp.com/2016/04/11/the-webapp-discovery-problem "Permanent Link: The web app \"discovery problem\"")

Quoting from the article that prompted this blog post:

This is true. However, the same is also true today with app stores. Here’s the Google Play store searching for a calculator:


And equally from the Apple store:


The choice is vast (and goes on). The reviews are fairly similar (though Apple showing the number of reviews is certainly useful), and if I’m honest, out of all the averagely good ones, I’ll pick the one with the nicest icon, and hope for the best.

These app stores are only successful in the simple fact that users don’t have any other choice in how they can find and install apps.

The web does have web app stores already, [Mozilla’s marketplace](https://marketplace.firefox.com/) is once such example. The "problem" is that it’s not ubiquitous.

There is no single store for web apps.

Actually, this is huge: There is no single store for web apps. This means we can have carefully curated app stores that suit our needs perfectly.

Web app stores with curated apps specifically for designers, or specifically for new parents, or specifically for kids under the age of 6, or specifically for cat lovers, or specifically for paid-for apps, or specifically free apps, or specifically by Google, or Microsoft, or Apple…the list goes on. The opportunities are limitless.

None the less, apps that rely on installation via the browse method are always competing in an already extremely saturated market. I believe (though without any research to back up this claim), that marketing and word of mouth is what drives successful conversions to installation. That process isn’t solved using the browse method, but specifically users knowing what they’re looking for, using the find and get methods.

This is where the notion of discovery being a problem for progressive web apps just falls apart.

For context, here’s what we’re dealing with with respect to native apps today. I listen to the radio in the car. At least once a week I hear the radio station announce:

The directions are clear: visit a URL to get their app (to listen to the radio station that I’m already listening too…). Except, in truth, I know this will involve a number of extra steps:


Let’s compare that to a progressive web app:

I didn’t have to negotiate the user’s operating system to send them to the right store, I didn’t have to build the same working music app in Java and Swift (or Objective-C or what-have-you-I-lose-track), and if the user doesn’t have a compatible browser with progressive web app technology (like Service Workers), it still works.

Progressive web apps allow users to truly "visit our URL to install our app".

It’s on us, [as I realised recently](https://remysharp.com/2016/03/18/progressive-web-apps-the-long-game#magical-moment-2-the-long-game), to make sure that we create a trustworthy experience. The discovery will solve itself: in fact, it’s most of the way there already.

Published 11-Apr 2016 under #web. [Edit this post](https://github.com/remy/remysharp.com/blob/main/public/blog/the-webapp-discovery-problem.md)

Lock Thread

Login

Add Comment[M ↓   Markdown]()

[Upvotes]()[Newest]()[Oldest]()


Benjamin Knight

0 points

7 years ago

But re: the "Find & Get" method, native apps are still easier to share & market via word of mouth because they often have memorable singular names, and you already know what store you have to go to to find it. I don’t remember URLs, even when they’re short and simple. More often than not I Google the name of the site I’m looking for versus typing its URL.


rem

0 points

7 years ago

You’ve said that you don’t remember URLs - it’s a fair comment. I expect instead of "you already know what store you have to go to to find it" you mean "I already know the store to find it".

Personally, I find that I even if I do know the name of the app, it doesn’t always appear in the Google Play Store and there’s significant distraction enticing me to look at other apps. But that’s me.


Joe Shelby

0 points

7 years ago

The main thing I want from Progressive Apps?

If i set in the manifest to not show the address bar and native/browser navigation (tab controls, etc), I would like that to apply immediately.

Now, at least with Chromium-based browsers (Firefox is working on this, but it was side-tracked by their own proprietary app-format that they’ve deprecated and removed - btw, that includes removing the Marketplace from having any use at all, as it only works for FirefoxOS approved/tested apps), when i open off the desktop, it will just be its own thing.

I want it to be that way up front. The browser reads my manifest, sees that I won’t want the native chrome wrappers, and immediately shows it full screen without them.

So no, we’re not quite there yet: it is still a multi-phase process.

That really is why the native and/or phonegap app process caught on. On a desktop, nobody minds a web app running in a browser because we’ve lived with browsers for 2 decades now. We’re used to them, and the frame wrappers aren’t that big compared to the screen.

On a phone, that 100-150 pixel space yanked out at the top is HUGE, and immediately makes my web site ugly (it always clashes) and less useful than it could be. When the browsers immediately get rid of that chrome wrapper as soon as my app starts, THAT is what we really want. Even background service-worker stuff is secondary to the visual experience of not showing the damn address bar when my app is running.


rem

0 points

7 years ago

You appreciate that instantly hiding the URL from the user, without their permission is a pretty huge security risk, right?

i.e. you get linked to a site from a short url, it loads and looks like twitter, but it’s asking you to sign in - but you’ve used your manifest technique to hide the URL bar. The user’s sign-in details are stolen.

I think, personally, if you’re worried about 100-150 pixel and it being huge, it feels like the design and UX needs a little (or a lot) more work. But that’s me. I see the web and browsers as a leader in security, not native apps (i.e. see how iOS would allow any app upload all your contact details without asking permission - iOS8 I think, or the one before).


Joe Shelby

0 points

7 years ago

i’ll accept your security argument, but again, that’s asking for some kind of middle ground.

My app is a music player. With the browser frame around it, it will NEVER look as good or be as good an experience as something that doesn’t have the addressbar stuff taking up the space. That is the nature of media apps: inside a browser on a phone, they are ugly as hell compared to the full screen experience that users EXPECT. You can not convince me otherwise.

So yeah, I’m still looking for a middle ground. Address your security concerns, but at the same time, respecting that some apps, especially media, will never look good in a phone’s browser, and finally, respecting that people HATE having the popup or header that says "install this…​"

My facebook feed often has my friends complaining about news and weather mobile pages that constantly try to shove the app version down their throats. It is a slap in the face to a user just as much as the "enter your email to subscribe if you like this" popups (before you’ve even read the article) that have taken over the web in the last 2 years.


rem

0 points

7 years ago

Unrelated to progressive web apps, why not use the fullscreen API?


Joe Shelby

0 points

7 years ago

non-standard implementations, and in Firefox-Android I couldn’t really get it to work (just like right now Firefox-Android is still ignoring the manifest for safe-to-homepage’s fullscreen setting). Maybe things have changed in the last 2 years, but when I first argued with it, it ceased to be an argument worth pursuing at the time.

And I don’t necessarily see it as unrelated. Any API standard that contributes to web/html5 apps (not packaged via phonegap/cordova) acting closer to native from the user’s perspective is part of the progressive app system. Full-screen, however it happens, is part of that experience.


Joe Shelby

0 points

7 years ago

Failing that, how should you tell the user that if they add to homepage, they’ll get the better experience? without the popup or the header that just annoys them?


Joe Shelby

0 points

7 years ago

Mind you, Android kinda caused the problem of having to show the chrome to get to the browser options menu (which are then necessary to show the add-to-homepage button) because they got rid of the hardware-driven menu button in 4.x (though Amazon’s Fire platform keeps it around, partly for parity with the Fire TV).

That could be countered by having a webapp call that would trigger the menu so we could restore it, but for now, we have something of a necessary evil in having the address bar, tab controls, and browser menu.

It may be necessary, but it is still evil. The Evil is that the user doesn’t know that by adding to home page, they can get rid of that, experience the app as if it was native, and have a more positive response from it.

Somewhere there’s a middle ground, and it needs to be found.


Shaomeng Zhang

0 points

7 years ago

Native app stores have its problems doesn’t mean we should seat and call it a day. I think there are still huge room for improvement. Here are a few: 1. one tap→confirm and install to Home Page (could be an open api or standard). 2. Consolidated web app store (could be a category inside Play Store or App Store). 3. crowd sources app rating, ranking, and reviewing platform (could be part of 2).


David Kiv

0 points

7 years ago

great article. Just wondering about the idea of prompting user to add the web app to their home screen on their first visit to the site and then adding it for them from within the web app if they select YES. A) is it possible and b) is it a good idea!? I know a lot of users I speak to still don’t realise they can even do this or how to do it manually.


rem

0 points

7 years ago

On first visit - a) isn’t possible, and b) isn’t a good idea. Have a read of my recent post "the long game": [https://remysharp.com/2016/…​;](https://remysharp.com/2016/03/18/progressive-web-apps-the-long-game#magical-moment-2-the-long-game) as to why.

The importance is for us, the web development community, to do this right, to infuse trust!


David Kiv

0 points

7 years ago

Thanks for the link, ya totally agree. Will hopefully see some improvements in making the "add to homescreen" idea more accessible for all in coming years - even if that means getting rid of that concept altogehter and coming up with a different way of doing things on mobile!


James Catt

0 points

7 years ago

I have a hunch that the whole "Add to homescreen" terminology is going to prove to be a big barrier. If I wasn’t a developer and didn’t have a clue what Service Worker is, I would assume that "Add to homescreen" just means adding a bookmark to a website, like adding a shortcut on my PC’s desktop.

I worry that people who don’t live and breathe this stuff (read: not us) are going to have a really hard time getting their heads around the concept of an installable web app. ("It’s a website—what do you mean, install it?")


rem

0 points

7 years ago

Regarding your point about "it’s a web site, what do you mean install" - I agree, I think this is the important bridge to pass. I think the right kind of marketing is key.

That said, I’ve been told about stats in India that has an incredibly high adoption rate for the tech and the (web app) installation rates (i.e. much, much higher than US + Europe).


rem

0 points

7 years ago

Hey James, you’re right if the add to homescreen is abused, but that’s why there’s barriers to entry in place. See this recent post: [https://remysharp.com/2016/…​;](https://remysharp.com/2016/03/18/progressive-web-apps-the-long-game#magical-moment-2-the-long-game)

It’s a long game. This isn’t the same as adding a bookmark, because you can’t "just add to the homescreen". The service worker et al requirements are for developers, not users. But this enforces the technology to back up the idea that what the user will do is install a web app on their phone, not just a bookmark.


iamvdo

0 points

7 years ago

Regarding "It’s a website—what do you mean, install it?", I’m totally agree with that. But, why the terminology "Add to homescreen" has been chosen ?

Why not just use "Install app", cause the website IS the app now ? And users have to understand that.

I find the "Add to homescreen" option is giving more confusion than clarification.

Am I the only one ?

[Commento](https://commento.io)