Then you're out of step with what users want these days.
Nothing wrong with that! But to take an example, when I hit a share button on a page I want to see the native share box, not some hideous iframed monstrosity that only works with Facebook. So I want Web Share. And I don't want to download an entire native app just so that I can receive a push alert when my food order is on the way, a web site works much better for that. So I'm happy that Web Push exists.
I get the nostalgia for the "simpler days", but web browers are essentially a universal OS these days. As both a user and a developer I'm quite happy with this.
In terms of development effort, maintaining a browser fork that merely disables these features seems pretty easy. If you think users would prefer that, why not make one?
I personally don't think it would take off, because I think most user attitudes range from "want these features" to "ambivalence". But if you're so certain, why not try?
Why does it require a fork? Having an advanced settings page with checkboxes for each of these web features seems straightforward and not overly confusing to normal users.
This, I have Safari Debug Mode on purely to disable all the annoyance. And with the current state of things there will likely never be an extension to do that.
Maintaining a fork that does that isn’t trivial, but it’s certainly doable by any one engineer.
However, maintaining such a fork is not the only prerequisite for it “taking off”. It may well be that my great uncle would love that feature - but how are you going to get his attention when several vendors are already spending millions of dollars in marketing/design/etc to influence which browser he uses?
> Then you're out of step with what users want these days.
Two things:
1. The person you respond to is also a user, no reason to dismiss their point of view
2. I don’t think browsers asked users for what they want! It’s a bit disingenuous to say “that’s what users want” when the communication is one way only.
Try talking to some developer relations people from the Google Web team, Mozzila, Microsoft etc. They're all very receptive to feature requests. It absolutely isn't a one way street.
I promise that I have never asked for a notification or a pop-up. They 'work' from the point of view of web sites and browser vendors, maybe more so than from the perspective of users.
I promise that I have never asked for a notification or a pop-up.
Very few people ask for a specific implementation of a feature unless they want you to clone something they've seen elsewhere. People don't do that.
In user focus groups I've been in though users have told me that they find it hard to know when they need to pay attention to something, or when they've been tagged in to something, or to know when a server side task has completed, or when a long-running webworker process has completed. All of those things are obvious use cases for some sort of notification, and when the feature has been implemented users both enable them and click on them.
Heck, I got a Google Calendar notification pop-up while I was writing this comment.
The problem is that you don't want notifications so you want them to be removed from browsers and then no one gets notifications even if they want them. That's not reasonable. The answer is that you need to be able to block them easily; to turn that feature off for yourself. This exists (in Chrome) - chrome://settings/content/notifications You can disable them for all sites. And yet you'd rather complain that they exist instead.
Turn off notifications by default so that people who need/want them (the minority) can get them from the relevant sites (the exceptions).
After that turn off stickies, floaters, modals, etc by default & those who wish to have their browsing experience assaulted into a 1 inch box can opt in.
Share API isn't needed for sharing content, copy and paste worked better than share api and it was around decades ago.
About what percent of push notification requests do you accept? I think my percentage is 0, and the number of requests is high tens if not hundreds. I don't trust browser notifications at all.
Opt-in rates are around 65%, open rate is between 1 and 10%, I suspect some percentage of those opt-in rates were unintentional or coerced and some percentage of those opens were click bate or accident. so <2.5% of notifications were desired.
I think it's safe to assume a significant portion of the opt-ins and notifications were desired-not.
Based on this information, I would consider notifications undesirable.
You consider them undesirable, but they are a critical feature for many applications.
Specifically, chat. More specifically... support agents providing live chat support. (And for that matter, end users interacting via chat appreciate push notifications on reply)
Without browser push notifications, there really isn’t a good alternative.
The fact that opt in rates are close to 50% is probably a good thing! It means that browsers aren’t using dark patterns to trick people in to opting into things they don’t want.
I would 100% agree with you if opting out were difficult. But at least Chrome’s implementation makes it very easy to decide which sites I want push notifications from, I really can’t think of any downside given the easy opt out.
Chat is probably one of the only functionalities that are still better served by an ad-hoc app
If you need notifications, just use a native app (or even a web one wrapped in a native app)
Anyway, most of these "features" are used because they are already there, remove them from the base install of the browser, distribute them as a plugin and make the devs consider that the feature could not be present and they will stop nagging the users begging for their attention
Any website I visit from mobile wants the permission to notify me, 99% of them don't if I visit from desktop
Let's say you're using some random website and want to talk to their sales or support team. How well do you think "download this app to chat with us" is going to go over?
Amazon and Alibaba are pure consumer plays with a mass audience. They deliberately hide the contact forms to force you through self-service UIs.
If you try the same thing with a B2B or other high-touch service, it's not going to end well for you.
Personally I get a terrific amount of value from interacting with my B2B customers through chats, video calls, and screenshares. The customers love it.
> Chat is probably one of the only functionalities that are still better served by an ad-hoc app
Yes, actually, IRC works better for chat, I think. Actually, it is probably true of some other stuff too, such as many kind of multiplayer games; you could use a telnet (or SSH) session.
This is not just about chat. Ever tried to build a cross-device synchronization without being able to push updates to clients? It sucks.
The user doesn't know that another user changed something until he opens the app and then the app has to fetch and integrate all updates since the last interaction with the app and the user has to wait until his app is ready.
Web apps are better because they are as much device-independent as apps can get nowadays.
Service Workers are the background service for web apps, but since users don't want those services to drain the battery unnecessarily, you have to use the Push API to trigger those background jobs.
So yes, if the app is the active app, you can do polling, WebSockets and all the like and have no problem. Background services are (rightfully) limited for web apps, but not even providing the Push API kills a lot of valid use cases. Firefox and Chrome both provide that API.
What do you mean by 'just Firefox'? Firefox, Chrome, Edge, Safari all support Progressive Web Apps in general.
Older browsers, on the other hand, might not be able to use offline features, but at least you can use the app in the traditional always-on mode.
For your comparison with Java: It is true, Java is very device-independent, but the deployment procedures are much more complicated than simply entering a URL.
I've never used a chat app that asked to send notifications. If they did ask, I would reject the request. I (correctly) assume the permission would be used to bombard me with irrelevant notification spam.
> Share API isn't needed for sharing content, copy and paste worked better than share api and it was around decades ago.
Most big websites have different URLs for the same content. When you're sharing a link, you want the canonical URL, which is neutral and universal, not the URL you're currently on, which might have a session ID, user preferences, scroll anchors, etc appended to it. The share button in your browser uses the canonical URL of the site (if provided), which looks nicer and works better.
Canonical URLs are part of the HTTP spec. URLs with session ids or user preferences are faulty and should be removed. Scroll anchors are useful to share.
Share button certainly doesn't work better; I find it so undependable that I intentionally avoid it.
I prefer copying the link to the page I'm on to share. No popups, native or otherwise.
Similarly, I like not having an app running so that you could just send me a text. Sms is bad for security, but great see sending short notifications. Almost better, as it is so limited.
FYI on Chrome/Brave Android, when you use 'share' button -> copy URL, it uses link rel=canonical meta tag if available (which generally doesn't have all FB tracking crap in the URL etc.)
The problem on mobile devices is that URL bar is single-line and has like 30 characters length and , while query string crap is sometimes several hundreds characters long. It's not every ergonomic.
But yeah I often copy the URL to "notepad" app before sharing and trim manually.
Yep unfortunately true. I recently saw an official document from local CDC in my home country. There were two URLs "find more info at" in the document:
This is also why most non power users will have chrome browsers loaded with tons of add-ons and basically let every site start sending notifications...
Except that with web push the block button is two taps away. Once I’ve given away my phone number that’s it, it can be sent to anyone, I can receive messages from anywhere.
Is this a thing that happens often? Used to, your phone number was in a publicly available book. Pretty sure we use legislation to block abuse of that kind.
Similarly, used to, my browser was not a bloated application capable of sending me messages. Such that there have been times just launching chrome I get notifications I didn't know my family were going to accidentally enable...
I still get more robo calls on landlines than on my cell. Conveniently, my cell is in a different area code from where I live, so even easy to spot the bad ones. And I have never gotten an unsolicited text. That wasn't a wrong number.
The most used feature in Microsoft Office is the Paste button in the toolbar:
> What we didn't know until we analyzed the data was that even though so many people do use CTRL+V and do use "Paste" on the context menu, the toolbar button for Paste still gets clicked more than any other button. The command is so incredibly popular that even though there are more efficient ways of using it, many people do prefer to click the toolbar button.
As soon as you put so much in the toolbar, people have to use a mouse. That they are still taking the most naturally used action shouldn't be surprising.
"As a user, I don't want this" seems like a reasonable claim.
"Then you don't know what other people want" doesn't seem like a reasonable response.
People want a lot of things - but only use what they can access. Additionally, people will deliberately choose to use broken/painful systems if they have to, in order to accomplish a broader goal. Finally, the vast majority of systems used by users are built because they are profitable to build/operate. In many (most?) cases, they are not profitable to the user in the same way that they are to their builder/operator.
From those simple observations, it seems like quite stretch to claim that anything that has many users is something that people want, and that they enjoy using.
"As a user I don't want this therefore no one else should have it either." is a bit less reasonable, and implies that you don't know what other users want or care about what they need.
> Then you're out of step with what users want these days.
"Developers" or average Joe's? Most people I know don't know what push notifications are. RSS? "Some kind of gov agency?". Sharing? "Facebook button!". And, no, they aren't idiots, they just don't care and see any of that. ;)
> "Developers" or average Joe's? Most people I know don't know what push notifications are. RSS? "Some kind of gov agency?". Sharing? "Facebook button!". And, no, they aren't idiots, they just don't care and see any of that. ;)
I think this leaves out a middle ground. The people who design web pages love this stuff, either business decision-makers (because they think it improves metrics) or programmers (because it's a cool way to implement the area of their technological expertise)—but you can be a techie, know exactly what all these things are, and not want them.
(RSS is a funny one to see on the list. It's practically ancient, and most browsers seem to have given up on integrating it—which is a shame, because it's a low-flash solution to a real problem and is user-centered and -controlled.)
All these things are why I have a custom user.js. I know most people here are web devs that get a kick out of this stuff, but I personally don't want most of the things described here. Most of them just seem like anti-features and/or security holes.
Wishing isn't the point for me. A lot of us were taught a particular security model, and then that changed silently, and now we might make bad decisions because of it.
I wish I could at least control these things. I'd like to turn them all off and see what happens to the modern web, and at least understand what I'm allowing when I turn them back on.
I think browser product teams are out of step with what users want these days. It is easy to confuse the browser ecosystem with users. Or even claim that the browser ecosystem is good for users, and therefore doing things to improve the ecosystem _is_ doing things the user wants. In truth, the user just wants to see the web page and have the browser get out of the way. You know who does that well? Native. Identity and payments are now _solved_ there. The web is still trying to figure out this out and probably never will. Too busy working on things that don't matter. Then something like AMP shows up, which actually builds _on_ the ecosystem, in _favor_ of the user experience, and people blow up about it. The browser ecosystem is sort of in a sad state, leadership wise.
Slightly off-topic perhaps, because I think you're making a general point, but although you may want the native shared box it only works for Safari users - https://caniuse.com/#search=web%20share%20api - with apparently very little appetite for it from other browser vendors. Maybe its time will come, but I think there are lots of issues with implementation.
Ok, a lot of these features requires the site to ask the user for permission to use them. What is the percentage of users giving permission for the usage? In my experience not that great even when asking for something that will definitely improve the user experience in that context of the site they are on.
If users don't really give you permissions to use these things it implies to me that users don't really want them.
I would strongly advocate for browsers to strengthen the UI prompt for notifications so pages can’t do it on load. In fact, Google is doing exactly that with Chrome and I think Firefox already has.
So, no, v1 wasn’t great. But we can improve on things.
I never liked the idea until I started using a browser based pomodoro timer and I enabled the desktop notifications, it's been a useful feature. Now, I'm wondering if there are other benefits I've been missing out on since I have always disabled desktop notifications by default.
Implementing notifications for a timer clock should be included in the wikipedia article about feature creep.
Not minding them too much since I disable them, but at some point it is just not worth it for all the anti-user practices notifications already allowed in my opinion. It just inflates functionality.
In 20 years, if we have even more powerful devices, we will complain about browsers taking ages to load again.
I don't really see the issue, as long as there's a security popup when a website requests notification permissions, and a way to just block everything except for a whitelist.
> Try to realistically justify any of those use cases listed and you’ll realize what a shill you sound like.
Wat? What part of the examples I gave are not realistic? I guess I live a fantasy life! Good to know. Are you arguing that there is zero use for push notifications beyond things advertising companies want? Because that’s out of step with pretty much every phone user I know.
What's wrong with native app? You can delete it when you are done with it, just like you can close a browser tab when you are done with the "entire" web app you downloaded.
No uBlock, no dev console, no network tab. Completely opaque. An install step just to order a pizza. Shareable URLs/deeplinks.
It's a freak of luck that we have the web, an app environment with a built-in dev console and actual customization. Just think how much it contrasts with the black box of native apps and with what large companies actually want. I'm in no rush to throw it away.
No need for ublock, the dev console is called your memory, your network tab is now something the entire os can understand, and you can even opportunistically block specific network calls.
Obfuscated javascript running in the console is no better than random apps, and webasm is going to make that even more opaque.
You are talking about features that are only needed for websites and why an app doesnt have those features, when they were directly bolted on to deal with the huge amount of complexity we've already handled in the OS.
On mobile its somewhat more fair, but the dev tools, adblock, and other items on mobile are almost always super compromised and locked down by the device manufacturer.
Amazon's app, at least on Android, is anyway so bad it's almost surreal. Massive lags without any indication of progress or indication that the app even accepted the input.
Now that I think of it, it feels like a bad website shipped as an app. Which it probably is.
Yes, but why should you need such a complicated system at all just to order a pizza, whether it needs an install step or not? A simple form, telephone call, etc would do.
Simple systems work great and are easy to implement when you're working with limited requirements. But the second you start to add new features, the system breaks down. How would a simple form or telephone call work if I wanted to know the status of the pizza or delivery driver's location?
I'd prefer not to give my number to them because then they can send me unsolicited "offers" all the time (just look at email) but I don't want to block them either because I still like their pizza.
The problem with native apps is they only work on platforms the developer supports. Web apps occasionally have this problem too, but native apps always have that problem.
An OS doesn't protect you from outside, it protects the system from apps and users
Imagine if your OS asked you if you would like to allocate a block of memory at address X everytime it does
That's what to a regular user the prompt means
They just click 'Yes Forever' and are done with it
But that's still an application settings, it has nothing to do with being an OS, browsers are mostly a system for distributing malware in the easiest of ways
At the cost of being as complex as a full OS, without any of the benefits
Wanna bet that if vendors started distributing naked browsers and the extra functionality (of course approved by W3C as standards) were bundled in plugins, which is entirely possible, half of those would linger there with zero downloads?
I don't understand what you mean by "In the browser everything is exposed to everyone by default". Browsers have a much more robust security and privacy model than normal OSes.
There's a difference between what features OSes have and which ones they are effectively using.
If you ran untrusted native apps with the same level of consideration that people run untrusted web sites, your identity would be stolen every 30 seconds. That is solid empirical evidence of a better security model.
People identities are stolen constantly by web apps, they just don't know
An app like Excel could steal my data, yes, but it is my willingness to give away all my connections to Facebook and let them spy my interactions that gave away my identity and also the identity of people that do not use Facebook, but are mentioned by me or my other contacts (for example my parents)
> native desktop app exposes a much larger attack surface
If we're talking about code executed as a result of, say, buffer overflow attacks, then the impact is the same both for the native app and for the browser. The latter, however, has way much more places where that overflow could happen! And they still happen, security updates for the browsers get pushed all the time.
(And we're not even talking about the world of XSS/CSRF attacks here! Those are pretty much exclusive to the browsers, and widen the attack surface tremendously.)
Not to mention that native apps can be properly reviewed and vetted by Linux distributions.
And have a tiny codebase compared to a browser. And even tinier compared to a browser + all the potentially hostile javascript, css, html, sng, png out there.
And run in native sandboxes or external sandboxes like firejail.
Nothing wrong with that! But to take an example, when I hit a share button on a page I want to see the native share box, not some hideous iframed monstrosity that only works with Facebook. So I want Web Share. And I don't want to download an entire native app just so that I can receive a push alert when my food order is on the way, a web site works much better for that. So I'm happy that Web Push exists.
I get the nostalgia for the "simpler days", but web browers are essentially a universal OS these days. As both a user and a developer I'm quite happy with this.