Like, big companies run separate servers on the two domains.
That's besides the fact where if you have www.example.www.example.com, it rewrites to example.example.com.
user2 - it's fine, here is a screenshot of it working (while showing "beautified" https://www.citibank.com.sg)
how is that not confusing?
Can we even call them address bars anymore?
And blaming website owners for working within the bounds of published standards is ridiculous and you know it.
> Users expect www.example.com to equal example.com.
No, they don't. The expect that the address they write down works when they type it back in the address bar though.
> If a website isn't redirecting one to the other, they, are doing something that is incredibly anti-user and it is a good thing that google/apple are forcing them to do it different.
You keep claiming this with any sort of evidence or backing. This may be anecdotal, but I worked as tech support for a large org (300+ users) most of my career and have dealt with most types of users. I've only seen them interact with the address bar in one of two ways: explorer shortcuts on the desktop/browser bookmarks (few) or stick-it notes on the monitor or keyboard (many). I'd be willing to bet my next paycheck that not 5% of them are aware that google redirects to www.
At least for those users, none of them will benefit from chrome's mishandling of www. Many of them will suffer from it. I'd be willing to stand corrected with a proper study though.
Also, subdomains aren't only used to make http urls pretty, they are intended to be used to refer to actual physical hardware hosts that belong to a given domain. All published standards I know of are written with this in mind. None of them mandate that www be synonymous to the parent domain, not even those responsible for web technologies. Organizations that follow standards are not at fault for following standards.
If having two different hosts on www and the parent domain was truly "incredibly anti-user" (a dubious claim), let google introduce a rfc at relevant standards bodies and have it go through proper scrutiny first.
Which is why technical specifications aren't written or maintained by non-technical people.
It's the same with autocomplete earlier this year. One day Google decides to ignore autocomplete="off" and all hell breaks lose.
Interesting to note, they have reverted this change. Google now respects autocomplete="off" in some scenarios (i.e. when autofill is not triggered via name attribute).
Note: autocomplete !== autofill
There will always be tradeoffs in advancing usability. This is objectively a small one. The problem is the unstated lack of appreciation for the value of usability improvements, because it's usually a more technically sophisticated person criticizing it who's comfortable with the way things have been. If you care about usability, that is an immensely net positive gain.
m.tumblr.com IS NOT a mobile variant of tumblr.com
I kinda wished I had that blog now so I could put a proof of concept up to show why this is a very bad idea from a phishing perspective.
This is a tradeoff -- continuing to support already-confusing differences is not worth the loss of the ease-of-use gain referenced in the grandparent.
The golden age of the Internet is already dead, guys. We're unfortunately over the hump.
1. "m.tumblr.com " and "tumblr.com " are BOTH displayed as "tumblr.com" even though they're literally different sites.
2. "www.example.www.example.com" displays as "example.example.com" which means all "www" subdomains, whether leading or not are being stripped out.
3. In the extreme case, "www.m.www.m.example.com" shows up as "example.com" which is pretty misleading.
Usually, the Chrome team is very thoughtful about decisions that impact security. I'm surprised this was released in such a half-baked state. I hope this is not an indication of how Google's plan to "kill the URL" will work out.
1 is by design though. Remember that they are only partially hidden; when you focus on the address bar it reveals the true address.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=881410...
This isn't the first time it's happened.
Take the https-everywhere changes. If you explicitly type something like "http://example.com.:80/" but the browser knows about an SSL cert for the domain, it will attempt to shuttle you off to https, failing to do the SSL handshake because of course it's port 80. Adding the protocol and the port isn't enough of a hint that I know what I'm trying to do.
What's worse, this is a domain-wide setting. If you have say, local.example.com, the browser will try to protect you again.
You have to go to an obscure preference and make the browser forget about this on a domain-by-domain basis, which will reset the next time it gets a wildcard SSL cert for the domain.
This thing is of the same vain, it's the new Ctrl-Q of the browser world; a feature that, due to some dogmatic ideology, doesn't have a "knock off the bullshit" setting.
Somehow irreversibly child-proofing software by making it not do what you tell it and hide important details has become fashionable, it's nonsense and needs to stop.
Are you claiming an attitude of hiding important technical details and creating dysfunctional smart systems in the name of usability doesn't exist? Or that these are unrelated things and the narrative arc isn't there?
There's numerous other examples, such as the gtk3 file-chooser dialog which hid a number of important controls in the name of usability.
What about mobile vendors, to make their devices friendly, remove a number of android customizations such as the ability to disable ambient display?
What about sites like reddit who removed a number of features such as the ability to edit a comment on their mobile site as a UX improvement?
Or what about the laptop vendors who remove keys such as Escape?
It appears that all technologies are slowly tending towards an aspirational goal of being designed for illiterate toddlers.
Luckily I know where this comes from.
Illiterate toddlers, as it turns out, use lots of software on tablets and smartphones. Looking at usage metrics and presuming that everyone is a competent adult, efforts at user-error reduction tend towards humans with diapers and pacifiers as they make the most errors and any demographics statistics of those errors will false positive as their parents, since the infants don't have their own devices.
Why do you think bright colors have better click thru rates for ads or using cartoon mascots or smiling men and women of child-rearing age increase inbound traffic and are seen as an important branding strategy for user engagement? Could it be toddlers tapping?
Maybe that solves the problem of why these boosting effects only appear on mobile devices since 3-year olds can't operate a mouse.
These trends give rise to design rules and "insights" which have a contagion effect on all software, just like the soft keyboard on the iphone led to the removal of physical keyboards from effectively all smartphones. Until every complex tool is dumbed down enough to be mastered by those who haven't learned primary colors or geometric shapes yet, this insanity will continue.
Look at Youtube's recent redesign moves for example. They recommend the video you watched yesterday again and do so for weeks. The only people that want that are under the age of 6 who watch videos on loops. I'm confident they have strong empirical data mixed with the failure to properly segment users to back this decision up. Toddlers are controlling the direction of software and it needs to stop.
Quite simply the www subdomain is confusing and unnecessary. See comment from the ISP admin I cited re: user training.
> Maybe we should be hiding ".com" because that's trivial too? Better yet, why show "google" at all if from the page it's clear you're on Google?
Those aren't really serious counterexamples. ".com" is obviously not trivial; there are plenty of TLD variants in use. It is approximately 0.0000000001% as common to run separate HTTP servers on example.com and www.example.com. And clearly different domains can spoof one another's content so that's not a way to be "clear" you're on google.com, whereas this is not generally an issue with subdomains.
Again your reaction is just sort of knee-jerk exaggerated resistance to change, not actual real world problem cases.
Sometimes it's unnecessary. How is it confusing? Millions of non-sophisticated users became sophisticated users typing it, millions more type it every day. It doesn't seem prima facie more confusing than a pronoun or other oft-repeated article. Consider the beginning of my last sentence in this paragraph -- would you consider the "It" confusing, even though it's not strictly necessary?
> Again your reaction is just sort of knee-jerk exaggerated resistance to change
Perhaps your reaction is knee-jerk teleology of change as progress?
As a suggestion: maybe spend less time characterizing the approach of people that you disagree with on this topic, and more time articulating actual arguments ("the www subdomain is confusing and unnecessary" counts, even though it's arguably not particularly strong), unless you'd eventually prefer it when people make the discussion partly about the shortcomings of your approach, which are far more glaring than you've clearly spent time considering.
mail goes to mail.example.com
voip goes to voip.example.com
vpn goes to vpn.example.com
Why should www be any different?
I'm noticing despite the invocation of vague concepts of progress and usability... you haven't articulated any particular case for how this represents either. No model for why it's simpler or more usable.
"Safari does this too" or imprecise aspersions about the supposed "whining and griping from the more technically advanced folks" doesn't really cut it.
I could guess that what you mean is "oh, if you can omit something and yet it's implicitly understood, obviously that's a simplification," though that's obviously a guess. If I've misunderstood, well, there's counterexample #1, to get a little meta. If I've managed to guess correctly, the broad topic of language and notation is a fairly rich well as to the potential for ambiguity or outright miscommunicated meaning when things are moved from consistent and explicitly denoted syntax to implicit syntax. Or examples for when the implicitly understood isn't particularly burdensome to use or even require in some cases.
"the world didn't end" .... lots of bad ideas that make things marginally worse don't end the world.
"the principle of it all" Again, this is a pretty vague and imprecise charge. Do you understand what the particular principles people are registering their objection on? If so, why not name them and respond?
I literally began my comment by citing this:
‘As an ISP, we often have to go to great lengths to teach users that "www.domain.com" and "domain.com" are two different domains...’
It takes only a very small amount of thought and empathy with the average user to understand how the extraneous www prefix can be confusing. It can lead to failures like thinking you have to use it with every website. It enables fraud by making “wwwexample.com” look more normal. Etc.
Your comment is a textbook example of “the principle of it all” argumentation. You cite no concrete examples of problems caused by hiding www from the UI. Not that we should expect none, but the right conversation to have is whether the usability benefits outweigh them. Not technical pedantry or “vague and imprecise” warnings about what may come if we let this pass.
That comment seems to be a rebuttal to the point you're attempting to make. It'd seem more apt to say you brought it in to interrogate it, rather than to say you "cited" it, and beyond rhetorical frustration ("why would you do this?"), it's not clear to me that you engaged it at all.
> It takes only a very small amount of thought and empathy with the average user to understand how the extraneous www prefix can be confusing.
It takes only a very small amount of thought and empathy with the average speaker to understand how the article at the beginning of this sentence is functionally extraneous (and is even optional in informal speech), and yet isn't particularly burdensome to use.
Perhaps the thing you're claiming is prima facie obvious with "only a very small amount of thought and empathy" is instead an unexamined assumption on your part and reflects assumptions about the average user that you have no particular claim to over anyone else in this thread.
> It can lead to failures like thinking you have to use it with every website.
"Failure" is a curious term here. The overwhelmingly common "failure" of someone adding it is comparable to the "failure" of forgoing a contraction for its full expansion. Or the article example I used above.
It's technically possible, I suppose, that a www|m.domain.tld record will simply not exist. That's a reflection of the reality that www|m.domain.tld and domain.tld don't actually resolve to the same server, and pretending they do breaks DNS. And not only is it a good bet that the failure we're worried about is more common than the failure you're worried about, the sensible way to address the potential failure case you're concerned about would be to allow an implicit redirect reflected in the URL to take place only if the www record does not exist. That'd be the user agent being helpful instead of making assumptions that break DNS.
> It enables fraud by making “wwwexample.com” look more normal.
This is half a worthwhile point. But only half a point because unless one goes whole hog in eliminating subdomains entirely, you can't really take out example.com.internet2.ru, and even if you did, there's also example-internet2.com, so this is part of a class of problems prefix elimination can't solve, which is a sign that maybe it's not worth it if there are tradeoffs (and there are).
> Your comment is a textbook example of “the principle of it all” argumentation.
You keep using this phrase. It sounds like what you mean is "the people I disagree with don't really have reasons they're just attached to some convention that doesn't matter because reasons." If there's a more precise meaning, try rephrasing.
> You cite no concrete examples of problems caused by hiding www from the UI.
Since your comment didn't contain any clear criticisms of the recent state of things, it seemed best to see if I could elicit those first.
Also, the most prominent concrete problem examples of how this breaks DNS weren't exactly hiding if you read the linked issue.
On a deeper level, though -- and this is an answer to your interrogation of the comment you brought into the thread -- this also handicaps people's ability to actually learn by observation how domains and subdomains and others aspects of URLs work through observation. Presumably your natural response to this would be to appeal to the tastes of the average user and saying they don't care about such things and that's only a concern for technically advanced users and "don't make the user think." Spotting you the accuracy of that model of an average user (which I've yet to see a comprehensive case for), perhaps some of those things are true, and yet, as a combined package, the conclusions it leads to are often wrong. Why?
"Don't make me think" is a starting place for good UX. Not the end. The next principle for really great software might be best articulated as "make affordances for optionally advancing use." Learning how domains and subdomains work isn't required for anyone to use the web -- it never has been, because people have always been offered hyperlinks and search boxes from starting points. But the URL bar offers a real affordance for starting to unpack details of how URLS work (including domains and subdomains). An "average user" may never care to start with, but this isn't advanced tech, it's accessible to anyone who can learn how to parse the parts of a physical address, not by nerdy study but simply by incidental observation... all while not requiring people who may tune it out entirely to make any more effort than they might with the controversial change under discussion. Casting subdomain (or path) details of that language into an implicit and ambiguous new convention makes it less likely they'll pick it up. So even assuming this change can be made w/o breaking DNS -- which doesn't appear to have been addressed -- it's removing an affordance into a simple and relevant (if linguistic) tool for navigation/orientation.
So there's your harms to consider.
Cities and states superfluous from physically mailed addresses these days if all you want is for your letter to arrive. Sometimes it's convenient to even simply give zip codes in some exchanges of address info (or to collapse the whole thing into a bar code). Would you suggest that it's harmful or confusing to continue to have cities and states as an allowable convention in addresses? If some postal/shipping service mandated the convention of leaving out cities/states, could you see that there's a credible case for harm, though it's redundant information?
That's a comparable situation with www.
And beyond the marginal utility of space savings of ~3-4 character widths on a small screen, there's no argument I've seen for a benefit in removing it that stands up to scrutiny.
And your analogy betrays fundamentally confused thinking. Omitting "www." would be more comparable to omitting "1st floor" for one story building addresses than omitting the city or state. The only address this would "break" is a building with different tenants operating out of "123 ABC St, 1st floor" and "123 ABC St", which is a misconfigured building if you could even find an example of that.
As mentioned in the comment you're replying to here, at least half a dozen such claims with examples are in the comments on the issue/ticket that started this thread, the same one that you even pulled a quote from. They've also been invoked throughout the entire HN discussion. I'm not sure if you missed them, or if you're implying that examples such as singapore banks or m.tumblr.com are simply made up.
> Omitting "www." would be more comparable to omitting "1st floor" for one story building addresses than omitting the city or state.
A building/floor analogy has its own issues, but it deals in enough of the same concepts as city/state/zip that it's serviceable if you prefer it as an avenue.
"1st floor" would indeed be extraneous (though correct) on single floor buildings, so sure, many people might choose to omit it from an address scheme on buildings with single floors. Plausible and not a problem in that case. And of course, people can add it for multi-story buildings where it's not extraneous. Finally, they can even add it on single story buildings if for some reason they're in the habit of using the convention, or if they don't know whether a building has multiple floors but know they want the first, and it's still technically correct and locatable in either case. And that strikes me as a reasonably apt analogy for the state of things before the change under discussion. Not a bad state of affairs really, unless someone wants to make a case that adding "1st floor" when uncertain represents a burden.
Now suppose one or more of the postal/shipping services mandate that "1st floor" is a trivial expression, and will therefore be hidden on all envelopes. Does that seem like a good idea? When an address is displayed for buildings that actually have more than one floor, who will know whether the 1st floor is implied? How will they know the floor wasn't accidentally omitted instead? Does the existence of these questions -- vs the question of whether to add 1st floor or not in the previous state of things -- and and any answers there may be really constitute an experience improvement for readers/writers of addresses?
> Peering through the pseudo-intellectual smokescreen
You know, that might be the sort of thing a keen intellect that's cutting through mumbo-jumbo would say, or it might be the sort of thing that someone who's not confident that their engagement with / responses to the arguments in play speak for themselves. Seems like a bit of a gamble about how it'd come off.
> How will they know the floor wasn't accidentally omitted instead?
This is nonsensical. This www change does not hide subdomains that meaningfully differentiate among "floors". It only concerns the entirely redundant "www" ("'1st floor' for a one story building"). Accidental omission of "www" a total non-issue... in the real world, where we live.
The "worst" example? I don't think I turned in a ranking. You asked for concrete examples of a problem. It is one. It's part of an unknown but decidedly non-zero number of examples where the www subdomain meaningfully differentiates hosts in the real world, where we live.
If there's a specific reason this example or others aren't worth considering, that's a bit of goalpost motion, but a more clearly articulated case can be worth it.
> my comments are restricted to the "www" prefix.
I'm glad your comments are. The change under discussion does not appear to be. Per comment #16 under the ticket:
"the domain m.tumblr.com is shown as tumblr.com."
Apparently the policy of identifying some subdomains as "trivial" is not limited to www.
Sortof raises the question -- once a player like Google decides it can designate a subdomain as trivial over its common (but not universal!) redunancy, what keeps them from stopping with www?
> It only concerns the entirely redundant "www"
Commonly redundant is critically distinct from universally redundant.
And allowing domain holders the possibility of treating them as redundant is a distinct situation from unilaterally imposing it.
Yup, that's why most non-technical users and also system administrators prefer it! (Oh wait, that's Windows and Linux)
I am genuinely interested in knowing if this is a usability improvement. Citing "Apple does it too" is not convincing to me.
It seems to me if URLs are meaningless to you, hiding part of them is meaningless to you so why do it? It seems just as plausible that it's only unusual subdomains that confuse users ("Is foobaz.example.com the same entity as example.com?!"), so hiding common ones might only make uncommon ones more confusing.
What you see is not what you get seems counter-intuitive imho.
"As an ISP, we often have to go to great lengths to teach users that 'www.domain.com' and 'domain.com' are two different domains"
It takes only a little bit of thought and empathy with the common user to imagine how this could be confusing. Are you supposed to type in www with every site? Why did it not work when I typed it in? Etc... It's just confusing and unnecessary.
This is a false dichotomy. There are tons of ways to improve the implementation without just hacking parts of the URL out of the "omnibar."
You could split the omnibar and/or allow it to be resized so both pieces of information can be shown. You can use differential color highlighting and/or text formatting to convey which parts google considers "trusted." You could implement an "expert mode" button somewhere that turns all of these "improvements" off. You could add an extra field that shows security-critical information not just about the URL but about the resulting connection(s) to the host.
This is hardly exhaustive, which is also a good description for Google's effort on this one.
The cost/benefit doesn't work out. It's a usability improvement, but it comes with a huge cost, where many, many sites have the fundamental function of a URL -- that of an address/specifier across the internet -- basically broken. The person who implemented this change either didn't work out the cost, or decided they didn't care.
Everyone is hyperventilating over contrived "the principle of it all" examples.
How would you feel if primary keys in your database started to change their semantics? How would you feel if your phone started to change the telephone number it dialed? I guess we're kind of alright with the message app editing our messages as we type them. Now we're supposed to adapt to our tools, not the other way around, and insisting on tools doing what we say is "pedantry."
If they replaced the country code with a flag, that would be an improvement. If they replaced the carrier number with the logo of the company that's also not bad. These are UI changes and the one you proposed about the phone numbers are great :)
If I were to propose a change, it would be 1-to-1. What happened in Chrome 69 isn't one to one. It's a surjection, which broke lots of URLs. That's the difference between a great UI change and an inconsiderate, idiotic one.
m.tumblr.com IS NOT a mobile version of tumblr.com
If I tried, I could likely come up with a ton more, but so could you if you tried.
Already cited elsewhere.
It doesn't help to falsely equate hiding "www." with corrupting phone numbers.
It's a valid comparison. Both are specifiers. It's the same sort of shenanigans with poorly planned "abbreviated" phone extension dialing and outside number prefixes in my company's office causing wrong numbers and accidental 911 dialing.
>Like, who actually runs separate HTTP servers on example.com and www.example.com anyway?
My university doesn't work with example.com but does work with www.example.com. I see how someone could waste a lot of time trying to solve a nonexistent network issue because typing example.com doesn't work, but he had seen it working before.
I personally feel like any negative user experience should be addressed by the developers of the website, not the browser.
Meanwhile I'm sure there are people out there who want to maintain a distinction between www.x.y and just x.y.
The people who run the sites should do all they can to make the experience as hassle-free as possible. This means no www.domain.com and domain.com going to different places, 99% of users will expect to end up on the same site regardless of where you add the www or not, to them it's the same as adding the htttps or not, it should "just work" regardless what they put in the front on the URL. (of course there will always be some edges cases, but I feel it's worth it for a better end-user experience.
IDK, just my 2c.
I do. Over and over again. Having been doing that for 2 decades, and with a limited budget, I require things like SNI[1] to work. But of course, I could just triple the tech budget...
EDIT: And wrt "Time for a modicum of historical perspective." - please give it to me. I am keen to learn what I did wrong all the time.
However, Chrome should handle this intelligently like it does with localhosts vs. internet hosts. If you manually type in "http://" into the address bar (e.g "http://my-local-domain"), it will not search the usual DNS and will honor any locally configured domains you may have on your network.
This doesn't seem to be the case now with this 'www' concern, though. With slenk's example of http://www.pool.ntp.org and http://pool.ntp.org - the only way to access the second link properly is to click the link. Typing it in the address bar loads the same website as first link - so it appears Chrome is automatically adding 'www' or somehow making the request differently making the second link's page inaccessible via the address bar.
Realize that the majority (and I'm willing to say probably over 95%) of people today us the internet on their phone. They have a few "apps" which they switch through by swiping left or right (changing channels). The use Facebook, Amazon, their chosen politically aligned news site, Google search, and a few other things. Probably not much more than the 6 channels of TV I had as a kid.
And the Google searches are rarely if ever for anything beyond the first few links or the sponsored content. Really, page 2 and beyond might as well not exist. The users don't go there. Google could just return results from major organizations and users would be fine with it.
I lived through PC era, from start to finish. It took me a long time, but eventually I realized that 99% of the population was never going to understand how computers work. Just the concept of a file and a folder is beyond most people (that's why phones don't have them). Once I gave up on expecting people to learn about computers, computing became much easier. Phones, tablets, and so on, for the masses, the desktop for me. And now I didn't have to go fix peoples screwed up computers - they don't have them anymore.
The importance of a domain name, much less a sub-domain, is now irrelevant. A search result, of of the first few, is what matters. You will never get users to understand a URL.
At one time the internet might have been for us hackers, but that time has passed. It's now the domain of the masses.
https://www.google.com./ should become either https/com/google/www/ OR secure/com/google/www/ OR secure.com.google.www. Browsers can then just always bold the third word?
:lock:/com/GOOGLE/www/maps/hawaii
I am a strong proponent of the URL being part of the user interface. I should be able to manipulate what i request of a service by modifying the url. The text in the url should mean something.
That particular rendering choice would also have the downside of being the same for both https://www.google.com/maps/hawaii and https://google.com/www/maps/hawaii
https://com/google/www//maps/hawaii
And its not like the browser couldnt render it both ways, either on click or hover.
Most sites either redirect to it away from www when you visit them anyways.
People have always said to host your site at www and redirect to it, something I have never understood nor heard a convincing argument for.
I have my servers configured to redirect visitors away from www.
From a DNS point of view: you can't have CNAME's on your root (can be useful, especially in some DNS load balancing situations, or load balancing on third party providers)
From HTTP point of view: A no-www domain might not be the best solution if you ever want a 'Cookie-free Domain' (static.) for images etc. which speeds up your site. If you start with a no-www domain you have to setup a different domain (no subdomain) for it: like sstatic.net for SO, ytimg.com for YT and yimg.com for Yahoo.
When the browser makes a request for a static image and sends cookies together with the request, the server doesn't have any use for those cookies. So they only create network traffic for no good reason. You should make sure static components are requested with cookie-free requests. Create a subdomain and host all your static components there.
If your domain is www.example.org, you can host your static components on static.example.org. However, if you've already set cookies on the top-level domain example.org as opposed to www.example.org, then all the requests to static.example.org will include those cookies. In this case, you can buy a whole new domain, host your static components there, and keep this domain cookie-free. https://developer.yahoo.com/performance/rules.html#cookie_fr...
in my view having a www record (and no-www redirect) has more benefits that a no-www
It comes from the long-lost days when people actually ran their own servers, and would have [www,mail,ns1,ns2,intranet,chat].example.com servers. If you already have a lot of special-purpose domains, it seems weird to privilege "www" as the real example.com, so the recommendation was to redirect from it.
I suppose this change does get to this exact point since it obfuscates the page location so far as to be totally inaccurate, just as channel numbers obscure the frequencies and data transmission methods do on television.
Would we really design this system today?
Would we have the web if we would design it today?
What ISPs teach their users anymore these days? Why the heck do we want to go back to that?
Time for a modicum of historical perspective.
If you care about usability this is clearly an improvement. This is part of a long-running industry trend -- Safari does this too -- to improve the usability of the Internet and technology in general.
At EVERY STEP in that journey there has whining and griping from the more technically advanced folks (like all of us on this forum). They zero in on the negatives, the tradeoffs that come with simplification. They don't see the positives because they're technically advanced enough and don't benefit from simplification (or so they think).
Then after the griping whines (sic) down and they realize the world didn't end and the downsides really weren't that bad and we move forward towards a better, simpler, more usable web.
Like, who actually runs separate HTTP servers on example.com and www.example.com anyway? Everyone is hyperventilating over contrived "the principle of it all" examples. Bottom line, Apple & Google are putting usability above technical pedantry. That's the right priority for mass market technology products.