suggest in standard calling website->webapp process unified "add to home screen" or such in all browsers (not install) #1096
Comments
|
Summing up main points:
We still have to fight for things and I think we should step back, regroup and fight for these key points. Now apple couples sites and apps with add to home screen, chromium calls it install. There is no simple unified way to make an app from a site/domain. People confuse apps with sites, web apps with web site shortcuts. Point 4 is extremely cool, a marathon well run. Some other thoughts:
So what I find crucial is to (my suggestions above):
I do think we have to first clear the way for this very simple definition of web app, and then if users start to use some from the home screen, standalone and it will be clear what is a site and what is an app (apple clearing sites but not apps may even help) then with time we will see very powerful apps from the web that utilize the efforts of a lot of people working on point 4. |
|
Thanks for your detailed thoughts. I think we need to slow down and take a step back here.
You raise a lot of valid points and many of the things you say here are things we've discussed for years (e.g. the confusion between creating a "shortcut" and "installing an app", and what that means to the user; whether we should call it "add to home screen" versus "create shortcut" versus "install app"). These are things that have been debated to great length both here and within the walls of individual browser vendors (in my experience: at Google, but presumably at Apple and elsewhere) throughout the whole time we've worked on the PWA platform and the manifest spec. That doesn't mean we have all the answers, but you are entering into a conversation that has been going on for over a decade, so it would help if you started by understanding the domain of the spec (i.e. what a spec can and can't mandate), and making some small concrete suggestions to improve the spec, rather than coming in with an essay about how we need to rethink how everything works. Most of the things you say here are not things we can (or should) mandate in the spec. We purposely leave matters related to UI, branding, and explaining concepts to the user, up to the user agent, so we do not create inflexible rules and user agents are able to experiment and change. For example, the idea of a "shortcut" means different things on different operating systems, and it's something that browsers and OSes can figure out, not something we can or should mandate in the spec. I would suggest that you refrain from statements like "this standard does a lot of unnecessary things" - just because you don't see certain features as core or important doesn't mean we didn't have a reason to put them here. Every feature in this spec was considered a valuable addition over the past decade (in fact, we took a lot of things out because only one vendor wanted them -- what remains has support of multiple browser vendors). I would also suggest that you avoid making statements about "legal requirements" unless you are a lawyer (and if so, GitHub is likely not the place to have those discussions). On your concrete request to rename "install" to "add to home screen" -- what we call it in the spec is fairly moot. The terminology "install" as defined in the spec does not force browsers to use that word, and again, we can't force browser manufacturers to label it any particular thing in their UI. They can (and do) use other terms like "Add to home screen", etc. It's just the label we give that concept in the spec, and it doesn't really matter what we call it. However, I think "install" is the best term for this as it's general across all platforms (your suggestion of "add to home screen" is extremely mobile-centric, as desktop platforms typically don't have what would be called a "home screen"). I get that you're saying "install" doesn't actually copy assets to the user's device, but the copying of data is really an implementation detail. From the user's perspective, "install" is when you commit to having an app icon on your device that you can open again. If you want to change the terminology used by actual browsers when presenting the "install UI" to users, this isn't the right place to do it. You should be discussing it with browser vendors. But note that on that side of the fence, browser vendors have also had long discussions about how to best present this UI (i.e.: we've landed on the terminology "install" after years of calling it other things, because we actually want users to think of this as installing an app just as they would install a native app). |
|
I'm going to close this as I don't think it's actionable. (The only concrete thing we can do here would be to rename the spec-level concept of "install" to "add to home screen", but as I said I don't think that really helps and we're unlikely to do it.) |
|
Thanks for the detailed answer. I think on another day I will read the spec fully and come up with more concrete suggestions. I simply dont have the energy now. Some quick observations until then: Web app is not defined. I am not sure it is clear from the spec what a web app is. It states that a web app exists before "install" (so web sites can be web apps) and web apps (sites?) can be installed. I think it would be more clear that there are websites inside the browser and then they become web apps when:
I dont think the spec is bad at telling us things, but it is not clear/optimal what the spec really wants. It really boils down to definitions etc. Website, web app, is it even possible to have a web app inside a browser? I think not, it appears to be a very nice differentiating line: website inside, app on os level like all apps. I am not sure I am very much interested in what a spec can force or not, what I meant is
There are already guiding notes in the spec, and for example I see on all platforms that this guiding note is nicely followed: User agents SHOULD provide a mechanism for the user to remove an installed web application application. Since the spec is not a standard and the real life web app thing is far from being optimal, there should be an openness to even a big rethink. But if I have time, I will read the specs, get a feel of it and write some concrete suggestions. |
|
I will definitely come back after reading the spec, but until then I would suggest to take a step back and think about basic questions like: What is a website, what is a web app, do we have a supported definition (by most people at Apple, Google, Microsoft, Linux, Chrome, Safari, Firefox, Brave etc. who care about web applications)? I mean the main process that happens is called in this spec web app -> installed web app, still Apple is refusing to use this word and interestingely, I am with them in this one. It is very bad that the very things the standard describes is refused by a big player, and even chat-gpt says it is confusing since no installation happens :) It may seem a big thing or a big re-write but actually one could do this on a weekend. Of course with discussions some weeks/months. It is a very basic, fundamental thing this distiction of websites and web apps (or currently web apps and installed web apps but I really find it confusing on many levels). I mean Apple wipes website storage, all of it, without user consent, after some 7 day rule. Not by web apps (or installed web apps or after added to home screen). There are big legal disputes, even Tim Cook says there is no problem, web apps can do anything on Apple platforms like native apps. And what is the legal source, what can be the legal source of the definition of a web app? This standard. Big responsibility. Very important. It is worth thinking about basic things over and over when something is that important. |
|
And I dont want to be rude, you can tell me there were a lot of discussions etc, I will not read them and I dont see them, what I see is the spec and it is not clear in these definitions, it uses installation 61 times, chromium uses install, safari uses add to home screen, the spec simply fails to be clear, have a unifying power. I see people fearing "installing" things from the web, they dont understand why should they do this, what they gain (but they know they fear viruses and stuff). It may be clear to us what happens, that it is not really installing anything and it is a reference to something when native apps are installed but it is just not right, I am 100% sure. Really sorry to say this but there is much more potential in this spec and it has a big responsibility. |
|
@prime2358 thanks for continued interest in this. I think you've got one thing totally right: the term "Web App[lication]" appears 125 times in the spec that is all about these things, but never actually defines the term. I have opened #1097 to action this. Later I could take a stab at a definition. With regards to the "not calling it installation", I would reiterate, we deliberately choose that word, because adding a web app to your system should be thought of as installation by the user. Yes, there are fundamental differences, but those are not key differences in the user's mental model. As I see it, the two major differences between what this spec calls "installation" and the act of installing a native app (e.g. via an .MSI file on Windows or via the Play Store on Android) are:
What I think are far more important considerations, for the user's mental model, are the other similarities that web app installation has in common with native app installation:
Whether we can do this depends on the platform, but the ideal, and the direction we have been moving in for many years, is trying to make "installed web apps" behave more and more like their native app counterparts. For example, on Android now these apps are not just icons on your home screen. If you go into your "Apps" inside Settings, you can see your installed web apps and uninstall them from there. From the user's perspective, these are apps and they are installed. In the ideal long-term world, users will not really have to think of these as "web" at all, but just "apps" similar to the ones they got from an app store. Thus, regardless of the implementation detail, "installed" is absolutely the correct term for these. Either way, as I said above, it is not relevant what the spec calls it, it matters how the UI explains it to the user, and that is not something we govern in the spec.
Not at all. Apple does not need to use the word "install", the spec does not require UIs to use that word or require an agreement at the UI level of what to call these things. I think that is healthy and allows browsers to experiment with different ways to message this concept. This is not the issue that you are making it out to be. (And I have no desire to make changes to the spec based on what ChatGPT says...)
I think this is a legitimate concern, and gets to the core of the UI debates around this (do users avoid clicking "install" because they think it will add a virus, etc). As I said, it's something that we've discussed for years inside Google and I'm sure other vendors have too, which is why you see different UI treatments over time. I know on Chrome at various points there have been different strings including "Create Shortcut", "Install" and "Add to Home Screen". Again, this isn't something to solve at the spec level. Debating with the spec authors what to call it is pointless, because the users will never see the spec, and the browsers can message it however they want. (The fact that this concept is not enforced by the spec is a very good thing, because it means if you want to rename it, you don't have to convince the spec editors and all browser vendors to agree on the name change, it can be done in each individual browser.) |
I think the wording install is so bad that I have to use a German word for it: furchtbar.
A web app will be added to home screen (even on desktop), integrated to the os and hopefully launched full screen by a headless browser.
Just like a java program runs on a jvm, a web app runs on the browser. But both the browser and the app is already there when site->app happens.
Nothing will be really installed.
Not even a service worker or offline usage is needed anymore.
If a web app is somewhat "installed", it has already happened via service worker caching before(!) adding to home screen, silently.
People hate installing things and fear it, especially from the web.
They do not understand anything what really happens so why making them fear installation when it does not even happen?
I know exactly 0% of normal people who is ready to "install" something from the web (something wicked this way comes, they all feel).
I think this "manifest" standard is what actually drives adding to home screen (or "install").
Here is defined the home screen icon file and the web app name that is shown on the home screen.
I think the real responsibility of this standard would be to guide the implementation. Icon and name may even be a one liner in a html standard (like favicon, just called appicon with a name...)
It is a very big responsibility since web apps are the future (EU law DMA will help a lot to push Apple, while Google, Microsoft are pushing web apps already).
I am following web apps since 2015 and I think the core property around which a web app should be built up and can be understood is home screen presence and full screen.
Not offline usage (developer and user decides whether to implement or whether to add/keep the web app if shitty) or os integration (the user will learn implicitly that this happens or it is needed to stop apple clearing the browser after some time without user consent) or installation (which is very bad because 1. it does not really happen 2. user fear installation and do not want to cause harm to themselves vs. harmless adding to home screen).
Also, web apps can and should be decoupled from website shortcuts.
web site shortcut:
web app button:
I think we really have to think about actions and names that implicitly help understanding.
I am not even sure we really need words outside of developer discussions like pwa, web app or so. A web domain added to home screen which launches a full screen app like experience.
A user will learn that if it wants outlook.com or teams.com full screen from the home screen or on desktop from the place where other apps are like the old email client or so, all it needs to do is hold the outlook.com domain and the os will show the app icon that the can drop wherever he wants to.
No need to call it anything else than drag the domain and add to home screen to get what you want.
The problem is people do not want web apps and do not explicitly understand them. They want a button and they want full screen.
I do not want to convince people to get my web app. Service worker and offline works silently and in the browser. What I want (if they want) for them to use my web domain from the home screen in full screen mode without browser UX. Because they can and it is better UX. If they want this, they implicitly want my web domain service as an app, but we do not have to make them explicitly want my web domain service as a web app... it will be clear with time implicitly what a web app is (like exta things that integarated to os and apple will not clear local database without user consent...). And people will understand that an app button and full screen usage is coupled to these properties.
The important thing is that it should be as simple as possible and not confusing.
I want a shortcut to this website in the browser: I go to the browser and use the bookmarking / favorites / shortcut system or whatever.
I want to use this website full screen and from the home screen or from other familiar (app) launcher, I drag the site and magically drop a beautiful icon on my device.
I am not sure this standard can force anything like that or if there anywhere exists an authority to force things like that.
But it would be great if we discussed somewhere how things would be best called or what logic is actually desirable to have.
A web standard is actually a must for web browsers and can be pointed to by legal authorities. Naming and unification is very important for success.
There should be very strong suggestions in this standard how to call and invoke things.
A user should have the right to add a web domain in a standardized easy way(!) to the home screen with an app icon and app name given in the "manifest" json.
Where else should something like this standardized?
I would really love to go full speed on this so that in a year or two we have a standard that can be forced with EU DMA.
Or at least when we have chromium on ios and ipados which follows from DMA, at least chromium would be perfect.
Now chromium calls "web site->web app" process "install", which is terrible/horrible/awful and logically incorrect.
You cannot nicely drag the domain name and drop an icon which is quite a good idea and could be the standard in each browser.
And there is confusion about shortcuts and co. vs add to home screen.
In this regard my suggested solution would be to make it the core requirement (and right) of web apps to run full screen like native apps. A native app does not necessarily need offline capabilities but always runs full screen.
Whereas, a web app will never run independent from the browser engine (and security) just as java needs the jvm. So it will not be installed as a native app (which suggests that it gets out of the browser and may do things that a web domain cannot: bad, bad things).
My current feeling is that this standard does a lot of unnecessary things (only icon and name are important) and most of them could be ignored or done in the service worker. But the standard does nothing about suggesting or enforcing very important things like logically correct names, guiding the icon and name to the home screen, I am not even sure there is a consensus what a web app is...
All this should be discussed, as broadly as possible, find the core properties and the path to success. My starting suggestions are above. A web app is a web domain with an icon and name added to the home screen of a operating system (without extra arrows like on linux) which is handled and integrated like native apps and run by a totally headless browser, having a responsibility for full screen navigation without browser UX. A good web app uses services workers for cashing and implements offline capabilities.
After an agreed definition this might be the right standard to layy down the suggestions for browser/os implementors to bring web apps to a successful life for the next hundreds of years...
The text was updated successfully, but these errors were encountered: