I agree with the sentiment on the thread that removing http:// is a UX bug. Copy & Paste in this case is paramount over UI simplification. Keep it simple... do not make it a configurable option and do not remove http://.
... They especially have no idea what its absence means.
Oh, I wholly agree, this makes sense for the average user. It's just wasted space to most people. They've already dimmed everything but the domain name (a brilliant idea in every single way), making the prefix' "cognitive impact" rather minimal already. To that end, I don't personally see that removing it is necessary, nor helpful. So at best it maintains the status-quo, and arguably lowers it slightly.
But, since these decisions are largely made for the majorities, it does make sense that they're going that route; I'm not really annoyed, I'm just mildly disagreeing with the decision.
As to the white non-secure flag, I'd tint it slightly yellow so it raises an eyebrow for people interested in their own privacy; white is too ignorable, and much harder to see at a glance. On the whole, it's an interesting idea, as it'd effectively turn the whole http/https battle into a slight-but-real push to move to https entirely.
> As to the white non-secure flag, I'd tint it slightly yellow so it raises an eyebrow at people interested in their own privacy; white is too ignorable, and much harder to see at a glance. On the whole, it's an interesting idea, as it'd effectively turn the whole http/https battle into a slight-but-real push to move to https entirely.
Exactly what I'm thinking. Just raise it as info, then change it to a warning progressively over time, with some advance warning to web developers.
This is clearly how hiding http:// should be done (if at all). Playing tricks with the clipboard is going to be confusing and frustrating to use. It is also suggested in other comments here; I hope the Chrome devs pick this up.
There's another use case, maybe it's just me, but at least once a week I need to insert a single "s" into the URL to go from the non-SSL to the SSL version of a page.
My proposed solution: go ahead and hide the http://, but when you click onto the address bar (and therefore want to edit the URL), show the http:// at that time.
This solves copy-paste issues, changing protocol issues, and probably others.
But I'm not sure where to make that suggestion on the Chromium issue tracker.
Considering how often adding an s to http is done (for example, I've only done this once, in gmail, before I saw the 'always use https' setting), I think that this is OK.
Still don't think it should be removed, though, just sayin' :)
If you want to discuss the http issue the place is chromium-discuss@chromium.org
Personally I don't see what purpose there could possibly be in removing it. The worst part is that it causes ambiguity about what will be copied (if the user was confused before about http they will be doubly confused when it magically appears after copying it).
Because have you ever ridden a bicycle with a flat tire? I hardly think the two use cases compare.
Anyway Comment #24 makes a lot of sense http://code.google.com/p/chromium/issues/detail?id=40865#c24 I see the enhancement for the end users who have NFI what http is but leaving it there provides more advantages as a whole than removing it.
I think the idea is to keep it simple for most users, not the techies.
I don't think many non-techies have any clue why the http is there, and they (rightly) don't care.
As for "adding an 's' for the secure site", once again, how many non-techies do you know actually do this? I'm not saying that's a good thing, but most casual computer users don't know about that. Hopefully they know about the lock icon on most browsers, but I actually kinda doubt that too.
The prefix is only removed from the "steady-state" display. It will still be there if you copy the URI from the address bar.
EDIT: Verified that copying works in the current nightly build, although there are some quirks pasting into rich text controls in some apps (like Pidgin).
Yeah, Chrome is actually reasonably good about making copied URLs be valid URLs, backing out any display that was done to them in the URL-bar. Better than Firefox on this: for example, in the URL bar, both Chrome and Firefox display '%7c' as '|', which makes the URL invalid. But when you copy it out of the URL bar, Chrome turns it back into %7c, whereas FF doesn't.
The main odd UX issue is that you usually expect copying text to give you that same text in the clipboard, whereas in Chrome you get something magically changed.
I'm glad that got wontfixed. It's not the convention at all in Windows or OS X. I can't stand applications that unexpectedly mess with my clipboard. Lotus Notes does this all the time and it drives me nuts. I make an attachment, and bam, my copied text is gone.
But fixing this wouldn't affect Windows or OS X, and middle-click pasting is the convention in Linux. I hate when I use Windows and inevitably realize yet again I can't do it. (Also, highlighted text sends to a different clipboard than ctrl+c.)
I don't think anybody's ever got this quite right. It's especially frustrating working with Firefox and GNOME terminal. Firefox copies into both clipboards, GNOME terminal replaces the selection clipboard when I Visually select something in vim, then when I paste from what should've been in the selection clipboard, I get what I just deleted in vim. It seems the behavior wrt selection vs copy clipboard is inconsistent from desktop to desktop and version to version.
How about removing it, but modifying the functionality of the copy action, so it appends the clipboard with http:// if the user has selected/copied the entire URL?
Personally, I have no qualms with http://, I just think this suits the best of both worlds: the future and the past.
I wonder how this will effect spdy://, Google's potential replacement for HTTP. Maybe it will be good; you can hide spdy:// too and make the difference transparent to the user.
Not only the http:// prefix but the whole idea of URL is a notion that should not be user-facing in an ideal world. Even the pretty REST ones are the internet equivalent of the command line voodoo many non-technical users just don't get and type in or copy paste without knowing what it means. If the URL is too long only geeks understand its components, let alone edit it in place to go somewhere else.
It's debugging info for sure, but for most newbies is wasted vertical screen estate.
Bookmarks and web navigation via links are already hiding the fact that 'you go to URLs' now, entering a URL in the bar is the corner case because not everything is easily accessible from everywhere else in very few steps.
In the future the internet will be distributed and content addressable and not have a certain thing only available at a certain URL you have to remember, and then the URL will really go away. HTTP is client server, IP networks are peer to peer by nature.
In an ideal world, users would look at something they don't understand and figure it out. Not to a level of mastering all the underlying concepts, but to the level of becoming functional with it. In an ideal world, we don't feel the urge to hide something we think the user will not understand. Instead, in an ideal world, we teach the user. Be it by presenting the subject in ways the underlying concepts become clear and obvious, be it in showing them progressive levels of functionality and abstraction. In an ideal world, users are intelligent, curious and do not feel the urge to run away from things, they feel, are too complex for them.
It's disturbing when someone advocates the idea of dumbing down what is a powerful idea in order not to upset those who think they would be upset, preventing them from learning something useful.
I use URLs for many things, from describing database connections to navigating hierarchical datasets in data-driven visualization tools. There is a lot to it beyond HTTP.
The Internet is not a blue "e". It's not a place of consumption, but one of sharing.
And when it becomes distributed, like you say, URLs could really serve us well, not by mapping to server:port/folder/document.html but to content and letting the underlying, non-http protocols, work out what's the best place to get the resource you need. You say "in the future" but p2p file-sharing networks use URLs in the form of network://hash-to-what-you-want.
If you assume your users are stupid, not only will you limit you product to those who know little, but you will rob them the possibility of learning something.
By ideal world I meant 'a better internet user experience within the next a decade or two' not 'all people are intelligent' as you meant. In the latter we would not be crouching over a browser anyway but do more evolved stuff :)
We do not teach users what an URL is when all she wants is to read her emails, just as you do not teach them how that browser is written or how the data travels to and from destination. I share your wish that people would be more inquisitive and learn but some people are just not like that for various reasons or do not have time for that and trying to teach them stuff they do not care about flies in the face of good user experience.
You use URL for many things including DB connections, this makes you a technical person. One of the reasons user experience is still shit in many applications is that many techies are convinced the user should be exposed to all the wonders of the underlying technology and consider this the noble quest of teaching them.
Yes - network://hash-of-what-you-want is the content addressability I mentioned. So the 'locator' in URL is not going to be meaningful. You do not locate a resource, you get some stuff wherever it may be located - assuming it is in one single place and not built from bits located in various parts. Anyway it was a tangent to the main topic - even if we denote the content someway it should not be exposed to your users.
Try asking around your non-tech relatives and see if they understand what the components of simple web url-s are.
My mom sure does not, and I have no intention of teahcing her that .com is some silly legacy from when it was thought that if you are a company that is what your webpage address, will be named like or what is with the slashes or even worse the ampersands.
I do not assume users are stupid, they just don't give a shit about stuff that is cruft and that has little bearing on what they actually do on the web.
The fact that tiny URLs are such widespread also underlines the fact that URL is a necessary evil by which you send someone to a resource and not something to inspect by people. There are complaints about them being opaque but much less then you'd expect given their massive use.
So do not try to teach people who do not care about learning because they will not learn and you'll have wasted your time on them.
> trying to teach them stuff they do not care about flies in the face of good user experience
The worry about "user experience" is the cholesterol-rich fast-food of design. It's terrible, dumbs users down, but, somehow, it's addictive. Imagine a world of immediate gratification and zero frustration. That's what many people are tying to build.
> they just don't give a shit about stuff that is cruft
Not everything you don't grasp, or that was decided before you were born, is cruft.
> The fact that tiny URLs are such widespread
Tiny URLs are a reaction against poorly-designed, overly complex URLs that convey little or no meaning. Nobody needs Bit.ly to go to http://www.google.com. I'm all in for not failing when a user fails to type http://, but I am completely against hiding it under a magical hood that will protect users from the dangerous unknown techniques under it.
Knowledge is power and, therefore, it belongs to the people. The better it's distributed, the better.
It seems to me that this comment was the driver for this Chrome "feature."
The problem as I see it is that the Chrome devs are fixing it at the wrong place. Changing one user app, when the standards state it's necessary to include just breaks things.
They need to change the standard, not the app. Until then, they've just got a broken implementation.
I am still unsure as to whether or not I like this.
One of the first things I do when I get to a page that requires my credit card information or any kind of username/password login information that can lead to a compromise of accounts that hold personal information is look at the address bar for the https:// in the URL.
EV certificates don't solve anything besides the fact that now the cert companies get to charge more for an SSL cert.
Checking for https://<name of company> means I don't have to go hunting for where the EV cert sign is posted these days, the URL bar is still in a uniform location.
I have been running the 5.0 dev channel builds for a while and I didn't even notice this change until I read about it now. I think it's OK. It has been done in such a way that it never bothers the user.
Favicons only in the tab bar. If you have too many tabs for the window's width, they stop getting displayed first on the selected tab (making the progress indicator invisible too) and eventually none of the tabs will have favicons as they get narrower.
The stupid globe icon they added opens a useless focus-stealing "Page Info" popup window that's missing most of what should actually be shown in it (like cookies). They moved the bookmarks star to the right of the address bar to make room for it.
Is this really true? Because I have wondered quite a few times. Is www.foo.bar just a subdomain like irc.foo.bar or mail.foo.bar? Is the default www.somesite.com basically just convention?
I am unsure if this is intrinsically stupid, but in our university, we have subdomains of the form www.faculty.university.de, mail.faculty.university.de, ssh-gate.faculty.university.de, mayflower.servers.faculty.university.de and so on. At least the ssh-gate is different from the www-server, and it appears the www-server is equal to the mail-server. Stripping the www here would be a world of hurt.
Long story short: the www is not necessarily stupid, especially if you use it to designate a web server from different servers.
So let it be the browser's responsibility to try both with and without it. They'll either be the same, or one will be nonexistent or a not-found page; it's not like people put one site at www.x and another at x.
You can't have a CNAME record for something that also has another type of record.... I think that includes SOA records or NS records. That may be where the confusion comes from.
There is also confusion regarding how they are resolved.
If an A record is requested, but a CNAME is encountered, the resolver will then look up A record for the resource indicated by the CNAME.
If the CNAME is specifically requested, it will return itself as expected.
Couple this with different implementations of mail servers (and other stuff) not strictly following RFCs...... that led to a general consensus among many greying sysadmins now to try to avoid using CNAME records wherever possible, as they were more trouble than they were worth.
