This reminds me of what happened when Microsoft decided to trim known suffixes off displayed filenames. Has everybody forgotten the hot-babe.jpg.exe viruses? With unicode allowed in domain names, it's only a matter of time before someone registers http：／／gmail.com.
An important difference is that you can still change the extension. Suppose you have a file called "foo.zip" and wish to change it to "foo.cbz"
On Windows, renaming the file makes appears to work, and the interface will indeed show "foo.cbz". But what it actually does is rename the file "foo.cbz.zip". The actual extension remains entirely hidden and untouchable as long as the global option to hide extensions is turned on.
On the Mac, changing the name to "foo.cbz" will prompt a warning that you might cause the file to open in a different application, and IIRC presents the options of naming it "foo.cbz.zip" or "foo.cbz".
Neither approach is perfect, but I think what this illustrates is the difference between walling off complexity and just hiding it. We see the same difference with Chrome, as hiding http:// is just visual, but the altered way of copying URLs to the clipboard is actually blocking the user's access to that complexity.
And worse, I have never figured out how the hell to disable that "feature" on OS X, I'm sure there is a way, but I wasted enough time pocking around the configuration options.
Jeez. I really don't get the fuss about this. 99% of web users probably won't even notice, except they might be pleased with the removal of the incomprehensible (and, for years now, unnecessary for input) code in front of the part of the website address they recognise and understand.
And for everybody else, what exactly is the problem? Copy/paste? I'm sure that can be fixed, even if it means the user setting "show http:// in my address bar" as a preference.
I read a lot on this and other websites about opinionated design. This is one of those things. The chrome team think this is a good idea. Some people disagree. As anyone who has ever run any kind of open source project can tell you, you can't just react to objections with "Okay then let's switch it back". At some point you have to actually make your own decision, weighing up the benefits against the costs, taking into account the number of people experiencing each.
In this case, it seems like a massive improvement for simplicity for most web users, and a trivial, surely quite easily fixed bug for an unknown percentage of the small percentage of users who would ever need or want the 'http:// there.
Just my opinion. I would be interested to hear what other people think.
- it makes the system second-guess in more places. Means more complexity - understandingly some bugs to fix (tinyurl.com/http-strip)
- the users will alter their behavior when mentioning the URLs (as I did just above). And will wonder why they are not linkable.
Now either the site owners have to jump through the hoops to replicate the second-guessing logic to their sites, or everyone who views the URL, will have to copy/paste manually.
Another couple of questions I will start asking as a user: why does the ftp:// thing pops up in front of the URL if I use it ? And, what is https:// and why is it suddenly there when I only want to go to gmail.com ?
This change noticeably increases the number of places which violate the principle of least surprise. But maybe I am a corner-case :-)
EDIT:
And, if we look at the whole "address bar" under the same UI angle - the path and the query string is equally a useless technobabble for anyone non-geek. So, I think we would go further and just show the host name, while we are at it.
It's a bit late in the game, but maybe we could adopt a new one-character standard to replace http:// with something shorter, but still easy to parse, like the @name system being made popular by twitter, etc. Some ideas:
I have to wonder how it is a "massive improvement for simplicity for most web users". Here's a question: What problem does this solve for most users? Was the existence of "http:// at the beginning of a url actually a problem for most users? If it's to emphasize the domain, Google Chrome 5.0 beta on OS X and IE8 both have domain highlighting, without breaking copy/paste.
I would also dispute the idea that only a "small percentage of users who would ever need or want the 'http:// there." Facebook and Twitter can drive as much traffic to some sites as Google. Breaking copy/paste doesn't help in sharing links.
Copy/paste seems to be working perfectly well on Chrome for me. And if there are other buggy cases, why are you assuming they cannot be fixed? Facebook and twitter will work just fine.
The problem it solves is one of simplicity. http doesn't mean anything to many people. I happen to like it gone - it's a redundant piece of information removed from my UI. I appreciate that.
When I said "what problem does it solve" I was thinking of usability problems as opposed to disagreements over aesthetics. Did the presence of "http" confuse users? Did it prevent them from completing tasks they wanted to accomplish with their browser? How does its removal help the user?
Anything that is not understood by a user is potentially a source of confusion and error.
The http prefix did nothing when navigating. You could type 'www.google.com' and get exactly the same result as 'http://www.google.com. It is redundant, unnecessary, wasteful. It can be removed, because it does nothing.
This is a usability problem. You just don't experience it.
When I type "www.google.com" into the search string of my search engine and hit "I feel lucky" then it gives exactly the same result (and that's how I saw a few people navigate to sites).
So if we go with the path of UI simplification, we could as well get rid of the URL (what does this TLA mean for a user, anyway?) and just leave a single input-only field.
Wait, that's exactly what is there today after you click on the icon with the house on it... So, maybe just make a checkbox "hide the URL input" and "show search engine homepage on new tab" ?
The article listed bugs. Facebook and Twitter will work fine, it would just be more inconvenient because of the bugs introduced by the new scheme.
It's not redundant information, it is information on what protocol is being used. That is important information. And this information is still being displayed, the only difference is it is displayed in an alternate form of an icon. An icon representation introduced by Chromium and unfamiliar to the majority of internet users. Now the Chromium developers have to decide how to display alternate protocols, will https be represented as text or as an icon? Will other browsers use the same icon representation? Are we assuming Chromium users will only use Chromium, will this confuse users who regularly use other browsers?
To say that other bugs will just be fixed ignores the bugs caused by the unnecessarily introduced complexity.
You say the protocol being used is important. Is it? Why? I think it is not. I think the important things for 99.9% of people are: (i) this is a website, (ii) this is a secure website. The actual protocol being used is a technical issue that the user does not need to know. The user just needs to know if it is secure or not.
You take issue with the icon. For years browsers have added a padlock to the UI when https:// is being used. Do we therefore need the 'https:// part? Do you think there should be no such icon?
In fact, I would argue that displaying a globe icon for most websites, and a padlock icon for secure websites, is an enormous boon for web security. Consider the previous situation, without icons: you are asking the user to spot the difference between 'http:// and 'https://. This is not something everyone will manage.
You don't like the abstraction because you are comfortable with what is being abstracted away. This does not mean the abstraction is not valuable. It means it is not valuable to you.
I don't take issue with icons in and of themselves, it's the replacement of the text representation with an icon. it's the break in conventions. The http/https part has always been visible on any browser. Having http:// at the beginning of URLs certainly isn't my idea of perfection, but to some extent we're stuck with it. It's much like the floppy disk icon for "Save". Why use that? There are kids today who have never even seen a floppy disk. But that doesn't mean that the floppy disk icon should just be up and removed from toolbars. A lot of thought should be put into a change like that.
It's not really like the save icon. The padlock for https is like the save icon, because it is a metaphor for a certain interesting state. Http, on the other hand, doesn't tell you anything except that you're not on https (or ftp, etc). So you don't need to be told about it.
Suppose the icon for your email program has a badge on it with an unread count. I'm suggesting that 'http:// is kind of like keeping that badge there with a zero when you have no emails.
"www" is only superfluous at some sites, and there is no way they can tell which. Even doing a name lookup on both and checking if the IP is the same is not sufficient, because they could be different virtual hosts on the same IP.
I did and it doesn't. On OSX. When pasting into adium.
It seems to work when pasting into a terminal. Haven't tried other apps, yet.
And yes, that's a big problem. I don't want to double-check my urls when pasting them into various messengers, skype or whatever. Here's a tip google: If you can't implement it 200% reliable then don't f-ck with something as essential as URL copy/paste. People will not be amused at all.
EDIT: I am intentionally not including the "http:// since:
* after looking at it in the omnibox, I decide I like it better this way indeed, and 6 less keystrokes. The others will have to copypaste or the webapp writers will have to figure a way to highlight it :-)
* the copypaste is not working in the linux case either, but that's one of the logged bugs.
It's really the first point that I am trying to say is the biggest impact that this change will have. "If it works in Chrome, it has to work everywhere".
> EDIT: I am intentionally not including the "http:// since:
And I am intentionally not clicking the link because ... it's not a link. I have a greasemonkey script that automatically turns plain text URLs into clickable links. But the text in your post is not a URL. It's a domain and a path, but with no scheme it is not a URL.
Adium's text entry is rich text, it'll accept actual hyperlinks. Paste a URL from Chrome in and right click > 'Edit Link', it should show the correct URL, with the link text as the URL minus http://.
