I'm not sure why having a screenshot is required but a description is optional. I would think you should be able to set either and that would enable the richer UI.
Screenshots upon installation is kinda how millions of people experience installing apps these days.
iOS store
macOS store
Windows store
Steam
Epic
Play store
Discover
(Gnome) Software
All these support screenshots. It's pretty reasonable that after a decade of millions of people installing apps this way they would want to see what they're getting into.
Yeah something generic would help, but manifest should still absolutely support the idea of screenshots.
It doesn't make sense because the barrier to "apphood" in whatever Chrome defines to be an app is scarcely more than making a manifest. The distinction between a chrome app and a webpage is very minimal. What user problem is being solved by this? Why do I need a screenshot of the "app" (i.e. webpage) I am already using?
Sadly, Firefox has abysmal support for PWAs on both mobile and desktop. I love Mozilla and Firefox -- and I still use it as my primary development browser -- but at this point Firefox is functionally worse than Chrome, Edge, and Safari on most axes.
To be real, only Safari actually matters as alternative to Chrome.
Firefox is also my main browser, but that doesn't change the fact that its 3% market share has made it optional for project delivery acceptance testing.
For me it's sad how I have to use Edge (because it's already included in Windows) due to many pages don't suporting Firefox. Google has made all they could to make both people and developers to use Chrome and Chrome-based browsers.
Yup. Those are words that the person you're responding to said. Quoting them here, though, doesn't make your off-base tangent about Electron any more appropriate as a response to a question about Chrome displaying a screenshot in a browser-controlled popup.
The installability of said Web apps was a thing prior to Chrome's announcement of the introduction of the "screenshots" property to the installation manifest. You are not answering the question that the person you responded to actually asked.
You're on a Web site. It has an "Install" button that you can click. Following the change announced in this post, the popup that overlays the page content can now contain a screenshot of the site operator's choosing when Chrome prompts you to confirm installation—a screenshot that could just as easily appear on the page—i.e. the one that you are already on and that contains the install button you just clicked. The question, then, is: ignoring all the puffery and filler the blog post, what _actual_ problem does this (the "screenshots" property—and not a PWA in general) actually solve?
(Alternatively, you can say something like how you were so excited when it seemed like there was an opportunity to post a vaguely cynical and nearly zero-effort quip related to installable Web apps vs Electron that you came in firing from the hip which resulted in what, as it turns out, was a response to a different question that nobody here was actually asking. It's as simple as saying, "Oops. I was mixed up, and I don't have such a big ego that I can't admit this nor one that requires me to pretend that this is what I meant by my original comment in this thread all along.")
The screenshot of the "app" is useful because the actual webpage you're looking at probably has a newsletter signup modal, misleading cookie banner, and a couple of ads on it.
One of the biggest problems is that users often neglect to use bookmarks. Consequently, as soon as they close your web app, it disappears. By using the "Install" feature, a bookmark is kept in a visible location, significantly improving the chances that users will launch your app again.
This is one of the primary reasons why many developers still prefer to publish in App Stores, despite the various obstacles and risks involved.
Mobile Safari also treats websites differently if users add them to their home screen. It doesn't aggressively remove local storage in these cases. However, I am not certain about Chrome's behavior in this regard.
You have misunderstood the question. Chrome already allows you to "install" these things today. This post is about a change to Chrome's installation UI. Chrome's installation UI will support the "screenshots" property in the installation manifest now.
When the person you are responding to writes, "What user problem is being solved by this?" they are not being asked to have the value proposition of "installable" Web apps explained to them. They are asking about exactly what they say they are: "Why do I need a screenshot of the "app" (i.e. webpage) I am already using?"
"The distinction between a chrome app and a webpage is very minimal"
It can be minimal, it can be significant difference, all depends on the PWA implementation.
Installed app has a shortcut/desktop icon, which is good for return engagement. A flash screen ratehr than the blunt loading of a web page. The UI can be instantly there as well as some content using offline tactics. A PWA isn't compromised by all kinds of browser real estate.
A proper PWA can definitely be better or approach a proper desktop app, but it's true that few implement them in that rich way.
I'd love to install we apps & make navigating there much faster. Giving them more permissions make sense.
But I absolutely positively do not want an "app" like experience. I want it to open in the browser chromez where I have tabs, where I have forward & back, where I have an address bar. Native apps are awfulz, useless limited half-shells, and I want everything to be web. The fucked up conflict is that PWAs attempt to appeal to native app enthusiasts, give developers power to make it looks like a native app, but God damn native apps are shit & the web is 300x more reasonable fair & useful.
I'd love to install some up jumped bookmarks. But wow native apps are just so limited, such a worse model to emulate, with so much less power. PWAs need a realignment where they can respect the web more. As is, they're more like retrogressive quasi-native apps. Yulou have a strictly downgraded experience for clicking the install, loose tons of thr basic web capabilities. Native sucks.
I personally am pretty happy with the speed sites can have.
Whether or not folks apply good practices is very much up in the air, & honestly, we have a lot to learn & relearn. Eventually I think we'll see more integrative front-end & end-to-end architectures that steer better towards success, that bake in more smart choices. Ideally atop more sensible & aware data-store systems/caches.
Somewhat different outlook on the web myself, but in general we're still speaking the same language here & I appreciate & support this post.
I'm almost the exact opposite opinion. One of my biggest gripes with web apps, especially on compact laptops and other mobile devices, is the constant presence of screen-space-hungry browser chrome. On Macs this is sometimes compounded by the addition of a redundant, in-app menubar since web apps in browsers (and for now, even PWAs) can't use the macOS global menubar.
Back/forward/history can be nice in some circumstances, but to me if I find them needed to make a web app usable, it's an indictment of terrible navigation UI/UX design on the part of the app. It's not that difficult to design an app to not need to lean on browser controls, but it does require a bit of a more holistic approach to UI/UX design than is commonly found in web apps (where instead, everything tends to be diced up into heavily silo'd screens).
The other gripe is that these apps are making my tab clutter problems worse than they need to be. With a PWA I can make use of OS window/app management functions to help keep things sorted a bit better and make my tabs almost entirely transient rather than constant presences, easing tab management.
I think it depends, looking at how many people are willing to go through the effort to run AltStore on their iPhones I'm sure there's a market for this stuff.
It's impossible to find the button to do this, though. Last time I tried to install a self hosted web app as a desktop app, I spent at least a minute searching through the menu options to find the right install button, and I knew it was there. If Chrome wants this feature to succeed, they need to make the UI much more accessible.
I'd say the same for Firefox but Firefox dropped installing PWAs on desktop all together. The mobile version still works (though you have no idea if you're creating a shortcut it installing a PWA until you open the link afterwards) but it's clear Mozilla isn't putting much effort towards web applications.
I'm running Chromium on my devices specifically because of the PWA issue on desktop, which really sucks. I wish I didn't have to but I guess I'm not Mozilla's target audience.
I am not trying to be snide, but AltStore has 300,000 monthly active users, among a total iPhone userbase of 1.36 billion meaning 0.02% of iPhone users have AltStore.
I think that there's JavaScript API for that. So for Chrome you'll just draw "Install me" button yourself and after user clicks on it, you call the API and Chrome will ask for confirmation.
I've noticed a lot of IT departments want to have an internal appstore from which users can install webapps. So it's not necessarily for the end users but the device managers, where those are different entities.
Business users will replicate any product in excel and use an email attachment from 3 years ago in the deleted items folder as the point of reference if we don't make it super easy to find them.
IMO a big reason why is that web apps don't have the idioms and affordances of desktop applications, so in the end, the ux feels wrong to users unless do you a boatload of extra work implementing and maintaining the multiple versions of the experiences your app provides. In many cases it was easier to just rewrite the whole thing in a desktop framework, where the desktop idioms and affordances are the default behavior, instead of trying to implement them in a cross platform framework. This problem only got worse when the OS updated its look and feel, your cross platform app wouldn't look new, like it would if you used the built in frameworks provided by the OS.
Then again, maybe I didn't read very closely at what this is announcing... This is just talking about a new better install experience, but I think what I said is still true. They are putting OS affordances in the installer, but when you get to the app, its different. Yuck.
Another thing that really sucked is when MSFT deprecated "click once" installers. Suddenly this "easy" way to make an installer became a huge headache. For some stable, legacy applications you can't even build them anymore without either installing an ancient IDE, or writing a new installer. When google deprecates these installers, these apps are going to be in a similar boat. Honestly I'd expect it to be even more painful, because the underlying web part of the web app is a moving target, too.
Correction: Chrome deprecated Chrome Apps. Chrome Apps are not the same thing as Progressive Web Apps.
Chrome Apps were a proprietary Chrome-specific thing — a special type of Chrome Extension, created and managed through the Chrome Web Store.
Progressive Web Apps, meanwhile, are a set of open web standards, requiring no registration with any central authority; and have support in multiple browsers (e.g. when you "add an app to your Home Screen" from iOS Safari, that's also the PWA standards at work.)
Chrome Apps were effectively obsoleted by the Progressive Web App standards.
...although, as it happens, Chrome reused a lot of the Chrome Apps business logic to implement its support of Progressive Web Apps. If you install e.g. this PWA demo app (https://www.khmyznikov.com/pwa-install/), you'll see that Chrome opens up its old "Chrome Apps" directory to dump a shortcut icon for the PWA in there.
Still a much better solution than installing an additional browser runtime with each "native" app. And Firefox should finally give in and implement "add to desktop", as it is much more useful, when your main browser supports it. Also, useful for business where launching your database application as separate task and having browser things in browser makes it easier to work. Especially for workers with lots of tabs.
I am using this to elevate a couple high use “tabs” out of the browser so I can more easily toggle to them with CMD+tab. It’s better than pinning the tabs all the way to the left of 100 other open tabs ¯\_(ツ)_/¯
Other than that not getting much utility out of it but that’s fine
52 comments
[ 2.9 ms ] story [ 118 ms ] threadiOS store
macOS store
Windows store
Steam
Epic
Play store
Discover
(Gnome) Software
All these support screenshots. It's pretty reasonable that after a decade of millions of people installing apps this way they would want to see what they're getting into.
Yeah something generic would help, but manifest should still absolutely support the idea of screenshots.
Secondly, not having Electron all over the place.
Firefox is also my main browser, but that doesn't change the fact that its 3% market share has made it optional for project delivery acceptance testing.
I hardly see it in any browser matrix nowadays.
"Why do I need a screenshot of the "app" (i.e. webpage) I am already using?"
Said pop-up is related to increasing Web apps adoption.
You're on a Web site. It has an "Install" button that you can click. Following the change announced in this post, the popup that overlays the page content can now contain a screenshot of the site operator's choosing when Chrome prompts you to confirm installation—a screenshot that could just as easily appear on the page—i.e. the one that you are already on and that contains the install button you just clicked. The question, then, is: ignoring all the puffery and filler the blog post, what _actual_ problem does this (the "screenshots" property—and not a PWA in general) actually solve?
(Alternatively, you can say something like how you were so excited when it seemed like there was an opportunity to post a vaguely cynical and nearly zero-effort quip related to installable Web apps vs Electron that you came in firing from the hip which resulted in what, as it turns out, was a response to a different question that nobody here was actually asking. It's as simple as saying, "Oops. I was mixed up, and I don't have such a big ego that I can't admit this nor one that requires me to pretend that this is what I meant by my original comment in this thread all along.")
This is one of the primary reasons why many developers still prefer to publish in App Stores, despite the various obstacles and risks involved.
Mobile Safari also treats websites differently if users add them to their home screen. It doesn't aggressively remove local storage in these cases. However, I am not certain about Chrome's behavior in this regard.
When the person you are responding to writes, "What user problem is being solved by this?" they are not being asked to have the value proposition of "installable" Web apps explained to them. They are asking about exactly what they say they are: "Why do I need a screenshot of the "app" (i.e. webpage) I am already using?"
It can be minimal, it can be significant difference, all depends on the PWA implementation.
Installed app has a shortcut/desktop icon, which is good for return engagement. A flash screen ratehr than the blunt loading of a web page. The UI can be instantly there as well as some content using offline tactics. A PWA isn't compromised by all kinds of browser real estate.
A proper PWA can definitely be better or approach a proper desktop app, but it's true that few implement them in that rich way.
But I think that most users don't care and don't want to "install" webapp in their desktops.
But I absolutely positively do not want an "app" like experience. I want it to open in the browser chromez where I have tabs, where I have forward & back, where I have an address bar. Native apps are awfulz, useless limited half-shells, and I want everything to be web. The fucked up conflict is that PWAs attempt to appeal to native app enthusiasts, give developers power to make it looks like a native app, but God damn native apps are shit & the web is 300x more reasonable fair & useful.
I'd love to install some up jumped bookmarks. But wow native apps are just so limited, such a worse model to emulate, with so much less power. PWAs need a realignment where they can respect the web more. As is, they're more like retrogressive quasi-native apps. Yulou have a strictly downgraded experience for clicking the install, loose tons of thr basic web capabilities. Native sucks.
Tabbing, history, bookmarking, seamless syncing across devices.. the web is great, but scrolling shows how slow it can be.
Whether or not folks apply good practices is very much up in the air, & honestly, we have a lot to learn & relearn. Eventually I think we'll see more integrative front-end & end-to-end architectures that steer better towards success, that bake in more smart choices. Ideally atop more sensible & aware data-store systems/caches.
Somewhat different outlook on the web myself, but in general we're still speaking the same language here & I appreciate & support this post.
Back/forward/history can be nice in some circumstances, but to me if I find them needed to make a web app usable, it's an indictment of terrible navigation UI/UX design on the part of the app. It's not that difficult to design an app to not need to lean on browser controls, but it does require a bit of a more holistic approach to UI/UX design than is commonly found in web apps (where instead, everything tends to be diced up into heavily silo'd screens).
The other gripe is that these apps are making my tab clutter problems worse than they need to be. With a PWA I can make use of OS window/app management functions to help keep things sorted a bit better and make my tabs almost entirely transient rather than constant presences, easing tab management.
It's impossible to find the button to do this, though. Last time I tried to install a self hosted web app as a desktop app, I spent at least a minute searching through the menu options to find the right install button, and I knew it was there. If Chrome wants this feature to succeed, they need to make the UI much more accessible.
I'd say the same for Firefox but Firefox dropped installing PWAs on desktop all together. The mobile version still works (though you have no idea if you're creating a shortcut it installing a PWA until you open the link afterwards) but it's clear Mozilla isn't putting much effort towards web applications.
I'm running Chromium on my devices specifically because of the PWA issue on desktop, which really sucks. I wish I didn't have to but I guess I'm not Mozilla's target audience.
Then again, maybe I didn't read very closely at what this is announcing... This is just talking about a new better install experience, but I think what I said is still true. They are putting OS affordances in the installer, but when you get to the app, its different. Yuck.
Another thing that really sucked is when MSFT deprecated "click once" installers. Suddenly this "easy" way to make an installer became a huge headache. For some stable, legacy applications you can't even build them anymore without either installing an ancient IDE, or writing a new installer. When google deprecates these installers, these apps are going to be in a similar boat. Honestly I'd expect it to be even more painful, because the underlying web part of the web app is a moving target, too.
Chrome Apps were a proprietary Chrome-specific thing — a special type of Chrome Extension, created and managed through the Chrome Web Store.
Progressive Web Apps, meanwhile, are a set of open web standards, requiring no registration with any central authority; and have support in multiple browsers (e.g. when you "add an app to your Home Screen" from iOS Safari, that's also the PWA standards at work.)
Chrome Apps were effectively obsoleted by the Progressive Web App standards.
...although, as it happens, Chrome reused a lot of the Chrome Apps business logic to implement its support of Progressive Web Apps. If you install e.g. this PWA demo app (https://www.khmyznikov.com/pwa-install/), you'll see that Chrome opens up its old "Chrome Apps" directory to dump a shortcut icon for the PWA in there.
Other than that not getting much utility out of it but that’s fine