I was trying to search for the word "aquarium" but chrome kept filling in "https://aquarium.org", I would delete the ".org" and only the word "aquarium" was shown in the search bar, which was the word I was trying to search.
Of couse "https://" was hidden, so I was actually submitting "https://aquarium" which was not a valid domain and it took many frustrated clicks and enters to actually google the word that was shown. Absolutely infuriating as the true state of the search bar was hidden.
The URL bar is a disaster for end users. It's full of random junk that users can't read so they stop trying, which means they can then be tricked by phishing websites hosted on any domain at all. Research shows about 25% of users don't look at the URL bar at all even when typing in passwords, they navigate purely by sight, so it's impossible to stop them being phished. The human cost of the resulting hacking is significant.
The fact that the software industry has routinely prioritised historical inertia, the needs of web developers, and all kinds of other trivialities over the security of billions of people is embarrassing. I'm glad to see the Chrome team finally get a grip on this and make the URL bar actually useful for people.
"Side view mirrors are a disaster for drivers. 25% of drivers don't even check them before making a turn." [I'll stop the metaphor here, as I think my point was clear]
This change does exactly nothing to improve security. As for usability, it just puts one more layer of paint over the underlying "complexity" - and we've seen before how well that works (see basically every part of Windows 10 for examples).
Your side view mirror metaphor is unfortunately not clear at all. The side view mirror is simple and performs its function correctly as designed. It can't really be improved without totally replacing it with something else like a camera. Now of course not everyone will use the URL bar even if it's redesigned to work correctly. But right now the bar is practically designed to look as intimidating and useless as possible.
Perhaps you're so used to parsing URLs in your head you don't realise it, but URLs are a baroque and absurd design that nobody without training could properly figure out. It's basically random bits of webapp memory and protocols splatted onto the screen in a large variety of different encodings. In a desktop app dumping RAM straight onto the screen would be considered a severe bug. On the web it's tolerated for no good reason beyond history.
To give just one example that has regularly confused people in the past: URLs are read left to right except for the domain name (the important part) which is read right to left. You don't stop reading a domain name at .com, you stop reading it at the third slash or possibly a colon, but that form is rare.
The way I used to teach was very simple and very effective: there are 3 parts to a URL - the first part tells you if the connection is secure, the second part tells you who you're connected to and the third part tells you where on that site you are. The first part needs to be httpS, the second part needs to be the site you're expecting and the third you can ignore. They're even shaded differently to make it easier to read. "If you're going to Google and the black part ends with anything but google.com, call IT" made sense to even the oldest and most reluctant people I've had to deal with. The problem was actually getting them to check every time and not forget.
It seems to me that this change will not help people without training, change nothing for people with training, and make sharing links even more confusing for everyone.
Are you saying someone is less likely to get phished on "supershop.co.hk" than on "http://supershop.co.hk/account_login.php", even where the http:// part is replaced with a red padlock and /... is grayed out?
I see only one real solution to phishing: don't let users type passwords manually. WebAuthN and password managers both automatically read the domain and won't try to authenticate on a domain that isn't a perfect match. I've had more success with that than any other anti-phishing measure I've tried deploying (history-based domain trust, explicit trust on first use popup, detecting unicode gaps and domains in credential fields...).
The greying out and replacement of padlocks etc, the anti-phishing training, it's all just working around a historical design problem in browsers. There's no need for it to exist. Notably, mobile apps don't have this problem.
google could make an amp-only web experience without dissent.
hide the URL bar
javascript -> webasm
hiding all this benefits data collection and advertising. Seems obvious to me.
Yes, we are.
Funny enough, Firefox has a 'Developer edition', but that's just the Beta build, with some features turned-on by default.
Due to slow loading, I'm considering whatever they call the Microsoft browser today.
I am honestly surprised Firefox on Windows is slow for you. I don't personally use Windows, but many on here say it works well there since v57.
Maybe I don't know what to Google.
That combined with both FF and especially Safari being way behind in terms of standards adoption/development really sucks at the moment. Chrome desperately needs competition.
The standards are meant to be agreed upon by several parties, including both Google and Mozilla. Google implements new features in order to control the way they work, instead of allowing input by all the parties involved. It's always faster for one company to just do whatever they want than for a group of organizations to come to an agreement on what to do. The slower way results in better and more equitable implementation for everyone though.
But if a whole subset of users exclude themselves from that tool, they're going to get the UX that's only as good as the other tools in the toolbox are capable of building.
But telemetry gives web developers an extremely simple and convenient tool to know what users are actually doing without even inconveniencing the users with explicit questions. I've done web development with a good telemetry set built into a page, and it is extremely informative regarding how users actually use the tool, as opposed to how the UX designers have predicted flow through the tool will be.
To give a concrete example, a user might tell you that configuring permissions is "hard," and sitting with them during over the shoulder testing (which is expensive) might tell you a little bit about why. But without even asking the user, page telemetry can tell you that they are making a transition jump from the permissions configuration page to the page listing all of the resource names, because that's what's slowing them down---the UI didn't give them enough information to configure the resources because we assumed they knew what the resources were named.
For a browser, anonymized usage stats can tell you whether most users keep all their bookmarks flat at the top of the bookmark bar or deeply nested in multiple subfolders, and that's usually valuable for deciding whether you want to emphasize a flat bar or folder management in the design.
If most power users disable automatic anonymous telemetry and also use deeply-listed folders, no one should be surprised if deeply nested folders doesn't get better.
People who don't show up to vote also "deserve" a good government by virtue of being people who have to live in a governed society. It's harder to make one for them if the system for selecting leaders is missing their input, regardless of what they deserve.
Popping out of the government analogy and back to software, power users are also in a position where they are more capable of adjusting their experience to suit their needs. All things being equal, a company with finite resources to develop software should dedicate those resources to assisting the non-power users more often than power users.
b) for being "not a good idea", it's pretty much industry standard now for everything from business software to video games.
So you're claiming that it is typical for software with telemetry support to ignore your choice and still send telemetry about you turning off telemetry? That sounds wrong, but I cannot say I investigated this deeply.
> b) for being "not a good idea", it's pretty much industry standard now for everything from business software to video games.
As I understood the discussion, we were in fact discussing whether this is a good idea and whether it makes sense, so I think it's fair game to comment on it. As for it being an industry standard, that sounds like an overgeneralization. It is certainly not typical of software I use.
No; I'm saying missing data leaves holes that can be measured. They know, for example, how many people have downloaded Chrome and how many daily Chrome users they get at google.com (because Chrome will still send a valid UA string if it has telemetry turned off). They can estimate how many users have telemetry turned off from those signals to a pretty decent degree of accuracy; certainly enough to know whether telemetry is telling them about 90% of users of 30%.
For (b), I'm curious what software you use. It's pretty standard in games, online apps, and business software. It's absent in a lot of open-source (mostly because a lot of open-source lacks a centralized vendor who would be willing to pay the cost to collect and interpret that data to improve the software).
I avoid online apps, I don't play a lot of games (and if I do, they're not big titles which are likely to have telemetry) and yes, I primarily use FOSS.
> (mostly because a lot of open-source lacks a centralized vendor who would be willing to pay the cost to collect and interpret that data to improve the software).
This is almost surely an element of it, but I think a respect for privacy and a general distaste for telemetry among FOSS users are more important.
* Apple Watch battery cycle count (not viewable in any UI but is viewable in telemetry logs)
* Clues about why a particular app recently crashed
Can anyone reproduce this?
You cannot compile Chrome. I've heard that Chromium can be compiled and run, but I've never actually seen it, or hear of anyone using that professionally.
There are other factors at play which mitigate the preferential treatment, but it's definitely there in Firefox as well.
At this point ie becomes more useful.
The goal of most web developers is to make pages users can use, not get mired down in the never-ending browser wars.
As the smaller vendor, it's incumbent upon Mozilla to break it. Expecting individual devs to do it collectively when it really isn't in their selfish interests is waiting for a unicorn to appear.
That's kind of impossible to do for a smaller vendor without wider developer cooperation.
I remember Mozilla only started to breach IE's dominance once devs were so sick of IE that they installed Firefox on their mom's computer despite tons of sites being made for IE.
It's possible for something like it to happen again with Chrome, but less likely since Google's a lot smarter and not too lazy to implement latest tech, so it will sure take longer without some activism and evangelism from web devs.
> expecting individual devs to do it collectively when it really isn't in their selfish interests is waiting for a unicorn to appear
Selfishness is a lot more complicated thing than people give it credit for. A lot of 'selfless' acts could be alternatively described as selfish in that it makes one feel good. Free software developers already do a lot of work for the wider community, where probably it would be a lot easier to just use the proprietary, already feature-rich, counterpart than trying to develop a libre alternative. But the movement understands that long-term, having as much free software as possible is what will in the end help preserve general-purpose computing in the sea of silos. It takes some discipline, sure, but long-term it's actually in one's selfish self-interest.
Short-term, sure. Long-term it opens devs to Google's whims and makes the "open" web barely more open than Apple's AppStore.
But that's short-term vs long-term thinking and I can't deny most would prioritize the short-term. Here's hoping there's still enough idealists, even among web devs to avoid that fate and bring about for the web what GNU did for UNIX in the 80/90s.
The only space I can name off the top of my head where my open-source architectures have outstripped Windows and Mac in UX is virtual desktops.
Of course proprietary software has more funding to hire designers and such, but in terms of actual functionality, I'd contest your claim.
If you're talking developer user experience, it's not even a race. The FLOSS ecosystem has a landslide lead here. In fact the whole point of WSL is to try to keep devs on the Windows platform by bringing that experience to Windows more directly.
Customizability is orthogonal with out-of-the box UX, the original axis of comparison here. In fact, the two are often at odds.
The history of biological evolution shows that monocultures invariably fail catastrophically. Diversity is the main way to guard against unpredictable events of the future. Software is not exempt from these general rules I'd presume.
I've looked into switching back to Firefox, but what I've found is that they don't allow me to use my own extensions. I would have to use a beta version of Firefox or submit all of my extensions that only I use for approval to Mozilla or have to reinstall my extensions every time I close Firefox. None of these seem good options to me.
Grand-parents/friends/org users not being sure to be on the right site after a redesign, not seeing amazon in the right language, etc. There’s countless of questions that can be solved faster by looking at the URL.
Understanding that users have more important things to do than spend time on bug reports is an important lesson to learn. If you can gather data without relying on someone whose job is to worry about other things then you will make everyone's life easier.
Not to mention all possible problems with misconfigured servers when www and www-less domains lead to same website, but some script refuses to work on one of those. While it was easy to spot with just a glance at URL bar, now one has to do additional clicking or opening devtools.
Probably we are at the crossroads where developers need separate, not dumbed-down version of browser.