Hacker News Reader

Comment by untog | Hacker News Reader

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.

View on HN

> Then you're out of step with what users want these days.

We hear this pretty often without any evidence. He is a user, you are a user, that makes two opinions.

I think the reality that companies set the rules and people just swallow what they get because alternatives require huge efforts.

We also heard that users want large tiles that are all over their desktop with zero functionality.

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.

Pretty sure that exists in Firefox

> fork?

Because it runs contrary to maintainer’s interests?

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.

How are feature requests from web developers to browser vendors evidence that browser vendors are paying attention to the desires of end users?

The evidence is that the end users use these things when they're implemented in browsers and web developers adopt them in their apps.

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.

This is how notifications work in Firefox and Chrome today. The site prompts you to allow notifications. If you do nothing, they are not enabled.

By default, the user gets notified that the site wants to send notifications.

> They're all very receptive to feature requests.

I think that's part of the problem.

Voted most insightful comment.

Being receptive to hearing them is very different to actually implementing them.

Exactly. Default browser settings ≠ user preference.

Default browser settings = what the browser developer believes will best server the browser developer's interests.

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.

Here's some stats: https://www.businessofapps.com/marketplace/push-notification...

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

Why is that?

I guess we all know the answer

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?

That's what email, phone or support tickets are for...

My experience with this kind of services has always been lame and I strongly believe only bad businesses use them

For example the two larger e-commerce sites in the world,Amazon and Alibaba don't use them

If they were a major improvement, they would.

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.

> If you try the same thing with a B2B or other high-touch service, it's not going to end well for you.

In my experience B2B businesses call you, they want to talk to someone, not to a chat bot.

My biggest complain is in fact that I have to take phone calls because clients refuse to use other means of communication.

> 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.

I guess you're trying to be sarcastic, but it's not working

Actually I am not trying to be sarcastic.

Then I'm sorry and I mostly agree.

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.

In whhat way a web app is better in this regards?

Most app that need to push updates to the client do it by having a background service talking to the update server or polling for updates

You can even do it via HTTP(S) if every other protocol is blocked by a firewall or a corporate proxy

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.

> Web apps are better because they are as much device-independent as apps can get nowadays

They are actually not really.

If you can't run a modern browser on your platform, you're out of luck.

I think the real "as much device-independent as it can get nowadays" is just Firefox

On the major platforms Java is as much as device independent as the web

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.

> What do you mean by 'just Firefox'? Firefox, Chrome, Edge, Safari all support Progressive Web Apps in general.

Chrome runs only on Windows/Mac/Android (Linux if you allow proprietary software on your distro)

Safari is only Windows/Mac/iOS

Firefox runs on many more platforms, but unfortunately its market share is low

> Any website I visit from mobile wants the permission to notify me

Strange, I don’t think I’ve ever seen a permission prompt on mobile. Chrome, iOS

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.

You only need to rely on one application to make push notifications worthwhile.

I get browser push notifications from gmail and facebook. I block everything else, but I'd be pissed if I didn't get those notifications.

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.)

Much better than directly copying the URL.

Or you could just trim the URL yourself.

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.

Even worse is chrome on android now. You have to copy the url, re-paste it and then edit. You don't have immediate access to the url you are on.

Which is a behaviour I observed in most power users, but none in the non-power user group.

I don't think most non-power user even want to try to trim that stuff, because they don't know what can be trimmed and what can't.

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:

file:///C:/Users/blabla/something.pdf

httpx://who.int/something?fbclid=<200-hundred-chars>

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...

> Almost better, as it is so limited.

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...

> Is this a thing that happens often? Used to, your phone number was in a publicly available book.

When you could only call that number. Messaging is pretty different.

And sure it happens! Phone numbers are (nearly) immutable. It's a valuable piece of personal information. Your web push ID is... not.

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.

I’ve gotten plenty, just for a counter-anecdote. In fact I received one today!

From who? This is literally against the law in the states. You reply stop, and if they don't, you can report them.

> I prefer copying the link to the page I'm on to share. No popups, native or otherwise.

I tend to agree, but this puts us both in the 5% of internet users who know how to do that. (And no, I'm not celebrating that low number.)

Sadly, agreed. Shame that it is moving this way.

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.

https://docs.microsoft.com/en-us/archive/blogs/jensenh/no-di...

You and I use Ctrl-V, but the vast majority of users want something a lot more visual.

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.

Everything in Office can be navigated using the keyboard...

Not far enough, why can't websites notify me via semaphore, or signal fires!?

"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" is reasonable.

"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.)

It wouldn't surprise me if user control is the problem most services have with RSS

This is such an important realization.

I, too, personally wish most of those features didn't exist. But I acknowledge that I am in the minority.

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.

Look up Chrome Feature Policies.

I'd be shocked if typical users understood what push notifications are, or even what those social network links for sharing things do.

Sometimes there are counters on those sharing links, and a tiny portion of visitors seem to click them.

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.

> But to take an example, when I hit a share button on a page..

You have already lost me, I do not believe I have ever done this, or wanted to do it

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.

No, it works on Chrome on Android too, so that’s the vast majority of mobile uses covered.

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.

So that's one good use case for Push Notifications. It would take about 10 minutes of browsing to find 10 bad ones.

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 find the browser notifications useful for discourse forums. There are some stuffs that I would like to be notified but not by email.

Is it not standard practice for browsers to prompt about push notifications? When I see the prompt I choose no, and don't ever see notifications.

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.

>when I hit a share button on a page

Why would the share button be on a page? Surely this should be a native browser/OS function (as implemented km android, for instance)

And because of that only megacorp is capable of developing web browser for "free".

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.

I think the point is that these features are masked from the user (especially on mobile) when performed in a native app vs a website.

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.

Just like native mobile browsers.

Regular users aren't plugging their devices into a host computer to access dev tools into their mobile browser.

Also no ctrl+f find.

One of the many reasons I use Amazon via browser and not app. Also open link in new window so you don't lose state, compare easily and much much more.

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.

Sorry, for a minute I though you were describing mobile browsers.

Mobile browsers are neutered but still way ahead of native apps on this spectrum.

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.

The problem with the modern web is it is becoming only the platform Google chooses...

Native apps can siphon out much more info off your mobile than websites can.

If they were OSes they would have a kernel and user land

You would have ring0 and ring3

You could decide what to install or what remove

In the browser everything is exposed to everyone by default

More than an OS is a disaster waiting to happen

> In the browser everything is exposed to everyone by default

Several critical or potential annoying functions have opt-in prompts by default, unlike your typical desktop OS.

It makes no difference whatsoever

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?

kernel = browser, user land = web apps

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.

False.

For starters, browsers can only implement sandboxing thanks to the OS facilities, otherwise it would be impossible.

And that is modern ones. 5 years ago some browsers were still a security nightmare with not even multiprocess separation.

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.

This is a classic false sense of security

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)

That's the real danger

The difference is that nobody runs untrusted binary apps.

If we wanted to do so, then the "run" operation on an executable would be different.

There is no difference, and in fact, OS have more features and capabilities to make running untrusted code safe.

Five years ago was 2015. Chrome has had multiprocess and sandboxing for a lot longer than that.

And if you had read carefully I said some browsers.

In 2015 Firefox still did not have multiprocessing. IE did not either, and it was massively used back then.

Despite the idiotic downvotes, you are absolutely right.

Browsers are terrible. No other applications or OS components are so monolithic expose the same attack surface.

What? Running a native desktop app exposes a much larger attack surface than opening a webpage.

> 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.

what about the software that opens that web page?

Reply on news.ycombinator.com