How is giving up on achieving something a win for users?
4,765 karma · joined August 17, 2012
How many IoT devices could have just used bluetooth for interactive with them, but instead they all phone home to some central cloud server because the user experience of just hitting a web page is better than installing some clunky native app.
Should we "just go ahead" and expose everything? Of course not. But there's room for thoughtful implementation of these features that users want. A super secure platform that nobody uses provides security to no one.
It's like taking a room, and refusing to add a back door for "security" when the front door already exists.
Your issue however also ties in to what the article said about how Apple does not auto update Safari. You're tied to Safari 12 partially because the upgrade flow is a huge disruptive process as you have to update your entire OS to a new major revision.
Who can say why those sites are breaking for your version of Safari. Web devs do love to just use the "latest and greatest" APIs just for fun, but it could also be that their changes have improved the experience for the rest of users on modern browsers, and that for them outweighs the loss of users still of Safari 12.
I'm not saying every use of new APIs is justified by web devs, the population of web devs is too large and varied to make any statement about the group as a whole. I am saying that the lack of modern features by Safari and Firefox _is_ a detriment to users and web devs, and it pushes developers to make native apps instead which I would argue are a worse experience for many users for certain use cases, and a worse experience for many developers as well.
If someone gave me a "simple" API for say networking. I would expect the API to be easy to use. But by your definition, I could give you an API such as "write(byte[])" which just puts bytes on the ethernet wire or into on the wifi radio. It's simple! It's not complex, there's only one API method with only one argument!
But in reality, I'm just shifting complexity to the user. I only consider things simple if they truly reduce complexity rather than if they just shift the complexity to someone else.
Mozilla considers the periodic sync API "harmful" because you could use it to track users IP and consumer resources when it's not clear they're interacting with the site
Their stated position:
> We're concerned that this feature would allow users to be tracked across networks (leaking private information about location and IP address and how they change over time), and that it would allow script execution and resource consumption when it isn't clear to the user that they're interacting with the site. We might reconsider this position given evidence that these concerns can be safely addressed, however, addressing them for periodic background sync appears substantially harder than doing so for one-off background sync.
But you could achieve very similar behaviour by using Web Push (which they _have_ implemented) and just sending periodic push message. So now as an honest web developer if I want nice background sync behaviour I have to implement some Rube Goldberg system of periodic push messages from a backend rather than just asking the system to wake me up every now and then.
Sure if seems sketch to access USB from the web, but as a user if I'm trying to achieve something and I can't do it on the web, I'll end up installing a native app which has way more access to my system.
As a developer I would much rather be able to just deploy cool things on the web instead of having to package up native apps for every platform just to do things like read/write NFC tags, or send notifications to users who want them.
I'm not targetting Lynx, Haiku, or 8 year old shitty phones. Nor are most web developers.
And the attitude that you must support those things is detrimental to the web. It makes people feel like they're doing it wrong of they don't spend all their time chasing those rare edge cases. Which if you're trying to start something new, can kill your productivity.
I'd rather have web developers target the common platforms only, than have those developers give up and switch to native apps.
How many breaking bugs have _NOT_ shipped due to the current processes. Your approach suggests that there is some perfect process manager out there who will let no bugs like this ship (whilst not dropping any other business priorities mind you) that they just haven't hired yet into this position.
This isn't as big of a bug as people on HN want it to be. A few months from few people will remember, and even fewer will care.
A forked project doesn't have the right to grant people licenses to code which they don't own.
If there are extra unconnected neurons, it would be trivial to just remove them, or flag them from anti-virus.
Even just saying "X sells stock Y before event Z" imples that X knew about event Z and that it would affect the stock price of Y. People will read headlines like this and walk away assuming there was insider trading, but that may not be the case. Nothing in that example headline has to be false in order for it to spread falsehoods.
It is simpler to design and analyze if it applies at every message. It's a design for the best case. No longer need to make judgement calls on if 1 week is enough, or maybe 2, or maybe some middle ground.
Privacy policies are just a waste of time anyways, bad actors are going to act bad regardless of any "policy" they have in place.
Not to mention the policy is not necessarily a contract.
It's one thing for the client to say "give me this resource in this format" its another for the server to say "oh you're coming from version X.Y of OS Z, I know what you really want."
Do the math, grab an investor and go get $100M.
"Just plant trees." Okay do the math on how many trees you need. Figure out how your going to build a program to get that many trees planted. What incentives, partnership, funding do you need. How will it scale to the amount needed. What will the full lifecycle look like.
"Just improve soil." Okay do the math on that. What's the timeframe for return on investment. What do the logistics look like for producing soil in huge quantities and deploying it where needed. How do we then use that soil to grow plants that sequester carbon.
90% of the comments in here are just the "middle-brow dismissal" of climate change of all things. As if we can "just do X" to solve it and everyone else is an idiot.
It's a hard problem, especially because part of the problem is determining how to actually implement and incentivize the population to do it. You can't just ignore that part, or just throw up your hands "people are stupid so we're fucked." Solving the incentive problem is actually part of the problem. Any solution that ends with "people just need to learn to do/value X" is dead in the water. You can start with "people just need to learn to do/value X" but you need to end with a plan on how you will bring about that change in mentality/incentive.
The "garbage" we don't want to serve mobile, is often also garbage for desktop, autoplay videos, too many tracking scripts, etc. If we force people to optimize their site for mobile and desktop then maybe we'll actually get good desktop sites.
Serving a slightly different web app from the same URI based upon other random metadata on the other hand. Makes caching all the more complicated.
Apple's primary business model is not search, so there could be some evidence that more people just prefer search over tags/folders/icons etc.
And as for Uber/Lyft, there's no doubt that they provide a much improved experience for the consumer.