Chrome just had to go and break things.



  • So in the latest builds of Chrome, there's this odd 'feature' I'm not seeing:
    http://

    So apparently, to make things more "user friendly", they've offed showing http:// at the beginning of URLs.

    lets try that again

    to make things more user friendly they're not showing http:// at the beginning of URLs.

    WHAT THE HELL ARE YOU THINKING GOOGLE?



  • As I recall, Tim Berners-Lee never intended humans to see either http:// or www. That was merely the conventions to be used behind the scenes. Crazy how it eventually ended up in public view.



  •  What's wrong with hiding http://? Is there something particularly userfriendly about it?

     Me: "Okay, just go to ehch tee tee pee colon slash slash google dot com"

    Dad: "It's saying something about an error."

    Me: "Did you put forward slashes?"

    Dad: "Which ones are those?"

    Me: "The ones tilting to the right."

    Dad: "Oh, no. Do I need to?"

    Etc, etc.

    Also, www was the typical name of the particular server listening on port 80. Alas, it caught on.



  • In version 5.0.375.126 (which I downloaded yesterday), I see http:// just fine, only greyed instead of the default windows font color. Works for me.

    What didn't work was when I selected "application/octet-stream" and wanted to google it; it assumed that it was a link instead of a possible search term.



  •  By "latest" I mean "20 minutes old builds of Chromium" ( the ones at http://build.chromium.org/buildbot/continuous/LATEST/ ) -- this has made users irate: http://code.google.com/p/chromium/issues/detail?id=41467

    I know its old, but it crept into the official "beta" channel too, which irritated the crap out of me.



  • But if you copy the url it will add the http:// back in the copied url, and it still shows it for https://



  • @pkmnfrk said:

     Me: "Okay, just go to ehch tee tee pee colon slash slash google dot com"
     

    Why did you tell him to add http:// manually? All browsers add it automatically.



  • @Indrora said:

    to make things more user friendly they're not showing http:// at the beginning of URLs.

    WHAT THE HELL ARE YOU THINKING GOOGLE?

     

    Who cares?

    It's not information. It's noise.



  • @dhromed said:

    Why did you tell him to add http:// manually? All browsers add it automatically.
    There are times the user needs to see this. For example, if the user wants to visit a site that only listens on HTTPS like this:
    https://mysafesite.com/
    If they type in the URL without the "https://" it will not work. Unless the user is used to seeing "http://" and "https://" they will not realise that they have to put the protocol in there, and they will not understand why it fails.

    Then there's this other case:
    http://localserver:1234/
    If you type that without the protocol, the browser should try using the "localserver:" protocol, which it does not understand, so it may even try to lookup a system handler for that protocol. There are of course more painful cases that can happen when you have local servers using non-default ports on your intranet, like http://javascript:8080/



  • @TarquinWJ said:

    If they type in the URL without the "https://" it will not work.
     

    Agreed, though the anecdote given was for http://.

    This can nonetheless be handled intelligently by the browser. Additionally, I feel that applications that rely on https should always redirect from an initial http state. For example, my banking's url is a normal http and auto-redirects to https. This takes the responsibility of remembering the S away from the user. Urls are hard. Having the browser tell you the site is secure is easy.

    @TarquinWJ said:

    If you type that without the protocol, the browser should try using the "localserver:" protocol,

    A sane browser will not attempt the localhost: "protocol", but will first try http://localhost:80/

    IE (8) is the  only one that fails to handle this sanely.

     

    As for indication of a secure connection vs normal http:, the browser should indicate that in a more overt manner. All browsers do that by employing blinkenden lightz in various states of subtlety. Safari fails that utterly by displaying a teeny tiny lock icon at the far end of the location bar where it's quite adequately hidden from a user's malicious, sauronian searching eye.


    Can we come up with other situations and use cases where displaying the protocol is better than hiding it?



  •  As a matter of general principle, I don't like to have technical details hidden from me, the way Windows does with its stupid default behavior of hiding file extensions (much loved by malware authors who use files with double extensions like .gif.exe).



  • @dhromed said:

    @TarquinWJ said:

    If you type that without the protocol, the browser should try using the "localserver:" protocol,

    A sane browser will not attempt the localhost: "protocol", but will first try http://localhost:80/

    IE (8) is the  only one that fails to handle this sanely.

     

    Why is it "sane" to deliberately break the spec because two developers think "no one will use that feature anyway"?

    We had that exact same situation with IE's content type sniffing a year ago already. Look at the havoc that one caused. And content type sniffing at least had a halfway understandeable justification, in contrast to "making things more userfriendly" by removing six characters that everyone has gotten used to already anyway.

    Of course "localhost" is not the only "dotless" domain name that is possible. If you have a custom DNS server running and want to make your LAN more userfriendly, you can choose any DNS name you like. Basically, to avoid conflicts, you had to produce and hard-code a list of all official (easy) and unofficial (hard) URL specs currently in widespread use. And god beware if those should ever change...

     



  • For the record, Mobile Safari does this; it's not necessary with today's browsers. I imagine it's in the name of space constraints instead of ergonomics though.



  • @dtobias said:

     As a matter of general principle, I don't like to have technical details hidden from me, the way Windows does with its stupid default behavior of hiding file extensions (much loved by malware authors who use files with double extensions like .gif.exe).

     

    Forward your tape to 2010. Windows doesn't do that anymore since Vista.



  • @dtobias said:

     As a matter of general principle, I don't like to have technical details hidden from me, the way Windows does with its stupid default behavior of hiding file extensions (much loved by malware authors who use files with double extensions like .gif.exe).

    I'm totally with you on the stupid Windows behavior there, but for http://? It's not like there's a potentially infinite (okay, not technically infinite, but you know) number of schemas that a URL could be using. It's pretty much http, https, ftp, file...maybe a couple of others now and then. http is by far the most common case; I see no problem with hiding it, as it's basically just useless rigamarole that people got used to because their user agents chose to display them. You'll know if the schema you're using is http or something else by checking if there's no schema (http) or some other schema (something else).



  • @PSWorx said:

    Why is it "sane" to deliberately break the spec because two developers think "no one will use that feature anyway"?

    We had that exact same situation with IE's content type sniffing a year ago already. Look at the havoc that one caused. And content type sniffing at least had a halfway understandeable justification, in contrast to "making things more userfriendly" by removing six characters that everyone has gotten used to already anyway.

    Of course "localhost" is not the only "dotless" domain name that is possible. If you have a custom DNS server running and want to make your LAN more userfriendly, you can choose any DNS name you like. Basically, to avoid conflicts, you had to produce and hard-code a list of all official (easy) and unofficial (hard) URL specs currently in widespread use. And god beware if those should ever change...


    It's something easily avoidable too, the browser only has a limited number of handlers it can use (file, http, https, ftps, dav, etc...) and the system provides more (and a database to find out what's available), Not only that but checking http:80 (as in http is actually a hostname that will resolve) vs http:// is pretty damn easy.



  •  @dhromed said:

    @pkmnfrk said:

     Me: "Okay, just go to ehch tee tee pee colon slash slash google dot com"
     

    Why did you tell him to add http:// manually? All browsers add it automatically.

    Firefox doesn't. Try to get to http://ftp.resource.org without the http:// and see what happens.

     



  • @toth said:

    You'll know if the schema you're using is http or something else by checking if there's no schema (http) or some other schema (something else).
     

    You're advocating that the most common case be handled in an exceptional way: "always show protocol, unless it's http."  That's a bad idea from the standpoint of interface consistency, and thus from the standpoint of interface as a whole.


  • Discourse touched me in a no-no place

    @badcaseofspace said:

    @dtobias said:

     As a matter of general principle, I don't like to have technical details hidden from me, the way Windows does with its stupid default behavior of hiding file extensions (much loved by malware authors who use files with double extensions like .gif.exe).

     

    Forward your tape to 2010. Windows doesn't do that anymore since Vista.

    I watched someone turn on file extensions in Windows 7 not 2 days ago. Default behavior is to hide them for "known" (aka registered) filetypes, but not for ALL filetypes.

    I just checked by opening Folder Options and clicking restore defaults. Perhaps you're using some sort of preinstalled OS from a benovolent vendor that actually doesn't think of its users as complete idiots?



  • @Schlagwerk said:

    For the record, Mobile Safari does this; it's not necessary with today's browsers. I imagine it's in the name of space constraints instead of ergonomics though.

    Here's the difference: Mobile Safari shows it when you select the URI-Bar. Chrome just forever hides it in betas.

    They seem to have gotten quite a bit of backlash in bug reports though, and especially across the interwebs for this one, basically summed up somewhere along the lines of

    ... Something like that

    People are not able to recognize insults and poorly written URLs, like so:

    For the record, I just typed in "the internet. Please kill yourself now.".



  • @Weng said:

    I just checked by opening Folder Options and clicking restore defaults. Perhaps you're using some sort of preinstalled OS from a benovolent vendor that actually doesn't think of its users as complete idiots?

    Meh, I consider Dell to be one of the more benevolent players (compared to Sony and HP), but I'm not sure if they earn the credit for this one. Might be policies.

    The hiding of file extensions shouldn't be an issue in corporate environments. The rest shouln't be using Windows a computer anyway.

    On topic: the browser's address bar is supposed to show the URL. The protocol is very much part of the URL. Without it, it's not a URL. What, they're going to leave parameters out as well?



  • @dhromed said:

    Why did you tell him to add http:// manually? All browsers add it automatically.

    No, my browser doesn't. If the protocol is not entered, it will treat it as a relative URL (unless a colon is entered at the beginning, in which case it treats it as a bookmark with a parameter).



  • @Indrora said:

     By "latest" I mean "20 minutes old builds of Chromium" ( the ones at http://build.chromium.org/buildbot/continuous/LATEST/ ) -- this has made users irate: http://code.google.com/p/chromium/issues/detail?id=41467

    I know its old, but it crept into the official "beta" channel too, which irritated the crap out of me.

    Why? This move makes perfect sense, and is long overdue.



  • @Rootbeer said:

    @toth said:

    You'll know if the schema you're using is http or something else by checking if there's no schema (http) or some other schema (something else).
     

    You're advocating that the most common case be handled in an exceptional way: "always show protocol, unless it's http."  That's a bad idea from the standpoint of interface consistency, and thus from the standpoint of interface as a whole.

    Here's the thing: I assume (perhaps incorrectly) that Google has usability people evaluating changes to Chrome. I assume that these usability people studied this change, tested it with actual users, and signed off on it.

    I *know* the people whining in the forums have no usability testing backing them up, no experience in usability, and are most like just part of the whining masses who get upset and cry over *any* change no matter how good it is.

    To quote one of the most legendary Fark threads ever: you'll get over it.

    Or is this blocking you from buying furry porn by the pound somehow?



  • @Weng said:

    I watched someone turn on file extensions in Windows 7 not 2 days ago. Default behavior is to hide them for "known" (aka registered) filetypes, but not for ALL filetypes.
    This is unchanged since Windows 95 (and still the default in Vista and 7).



  • Assumption is the... Well, you know how it goes.

    For that matter, Google is really making Youtube look like a testbed for all kinds of random changes in the UI. Every time I visit YT lately it's a complete surprise what kind of video strip/gadget/favorites collection is going to pop up, and where.

    Your point is valid, for cases where "Testing it with actual users" just means ignoring the opinion of the other half.



  • @badcaseofspace said:

    Assumption is the... Well, you know how it goes.

    How about this. If my assumption is wrong, we have this:

    Google asserts it's better vs. random people assert it's better

    Without any evidence either way, Google has a 50% chance of being right, even in this worst-case scenario.

    @badcaseofspace said:

    Your point is valid, for cases where "Testing it with actual users" just means ignoring the opinion of the other half.

    If the "other half" is screaming like baboons because it's not identical to the URL bar from 1998, then yes they should be ignored. The problem with changing anything is that there is a subset of the population who complains no matter what you change, or how much you improve it. The whole point (well, much of the point) of usability testing is to filter those baboons out.

    In any case, even if you were a reactionary baboon, I still don't see any plausible argument for how this change hurts you in any way. What are you losing, actually losing, by not seeing "http://" in that particular text field? Give me an actual reason to keep it.



  • <Melvin>If the judgment of a random sample of people is Google's truth, then that's it, isn't it?</Melvin>

    Google vs. Random people doesn't even play, because in the end just a small set of people choose to interpret the research results the way they want to. If the feedback concludes that 70% didn't complain, do you move the change forward?

    Added features are most famous for being good improvements. Changing UI elements just cuz' or displaying things differently than all other programs in its class is arguably not, unless you need them to implement said feature. Then what feature is this change trying to implement? Is this somehow going to give a competitive edge, or reduce support calls, increase security, or the infinite satisfaction of 5 extra characters on the address bar, what?

    To be honest, at this exact instant, I couldn't care less about the
    address bar in Chrome because I never use it and they never asked me.
    But if it were to become common practice then I'd say that information
    was taken away that was previously there. Public knowledge that http has
    something to do with the internet isn't bad, even though their user
    base obviously doesn't care.

    The address bar like it was in 1998 is still like it is today because nothing else has changed. Everything that happens between the URL and the actual bits zipping through the tubes is essentially still the same. It's not necessarily conservative or primal to keep things the way they were when they work, and I especially don't get the obsession with layout redesign in things that have a specific purpose for other things than being eye-candy. If a major revolution happens that makes URLs or protocols obsolete to the end user, I say get rid of 'em. Until then, it's just part of navigation. Is that old-fashioned?



  • @blakeyrat said:

    @Rootbeer said:

    @toth said:

    You'll know if the schema you're using is http or something else by checking if there's no schema (http) or some other schema (something else).
     

    You're advocating that the most common case be handled in an exceptional way: "always show protocol, unless it's http."  That's a bad idea from the standpoint of interface consistency, and thus from the standpoint of interface as a whole.

    Here's the thing: I assume (perhaps incorrectly) that Google has usability people evaluating changes to Chrome. I assume that these usability people studied this change, tested it with actual users, and signed off on it.

    I *know* the people whining in the forums have no usability testing backing them up, no experience in usability, and are most like just part of the whining masses who get upset and cry over *any* change no matter how good it is.

    To quote one of the most legendary Fark threads ever: you'll get over it.

    Or is this blocking you from buying furry porn by the pound somehow?

     

    Yeah, I'm sorry I have no usabillity testing division backing me up. I'm just a, you know, user.



  • @blakeyrat said:

    In any case, even if you were a reactionary baboon, I still don't see any plausible argument for how this change hurts you in any way. What are you losing, actually losing, by not seeing "http://" in that particular text field? Give me an actual reason to keep it.

     

    The actual reason is UI consistency, which, ironically is a usabillity paradigm. As unbelieveable as it may sound, there are other URL schemes in widespread use, like the afromentioned https, ftp, bittorrent, etc. And should this convention really find widespread use, dealing with any kind of non-http URL will become much more complicated: Today, you can pass around those URLs like any other, it's just some other meaningless piece of text at the beginning. But once everyone has gotten used to URLs starting with "foo.com", they'll get horribly confused when they have to enter a non-http URL and find it looking completely different. Good luck explaining your users for the umpteenth time that your FTP URL really starts with weird colons and slashes.

    I agree that any sane browser should be able to automatically add the http if you didn't bother to write it. I have nothing against graying out either. But there is a difference between being convenient and pretending someting isn't there. Or put differently, there is a difference between optimizing for the main use case and throwing all other use cases out of the window.



  • @PSWorx said:

    The actual reason is UI consistency, which, ironically is a usabillity paradigm.

    Consistancy is good, until it becomes stagnation and then it isn't. I mean, if consistency was the only usability paradigm, then we'd still be using Mac OS 6...

    @PSWorx said:

    As unbelieveable as it may sound, there are other URL schemes in widespread use, like the afromentioned https, ftp, bittorrent, etc. And should this convention really find widespread use, dealing with any kind of non-http URL will become much more complicated:

    Ok...?

    @PSWorx said:

    Today, you can pass around those URLs like any other, it's just some other meaningless piece of text at the beginning. But once everyone has gotten used to URLs starting with "foo.com", they'll get horribly confused when they have to enter a non-http URL and find it looking completely different. Good luck explaining your users for the umpteenth time that your FTP URL really starts with weird colons and slashes.

    Well, first of all, you're making an assumption here which is that just because Chome doesn't show the "http://" it also doesn't keep track of it internally or copy it to the clipboard. That's goofy. Remember, we're talking about hiding it in the UI, nothing else. There's no reason to believe that you'd be passed any more URLs lacking protocols than you are now.

    Secondly, are you honestly telling me that if someone sent you a URL like "funnysitelol.com" you'd first try to use a bittorrent client to connect to it? That's ridiculous... UIs are designed for normal human beings, no normal human being would assume that was a bittorrent site.

    Entering a non-HTTP URL into a web browser is something that is, by and large, never done by normal human beings. I'm a geek, and I don't think I've ever done it myself. (Maybe a FTP link back in 1998 or something.)

    And, hell, we're talking about Chrome. Chrome doesn't even *support* any protocols other than HTTP and HTTPS. It can't even deal with fucking RSS correctly, and that's actually a web protocol.

    And why would you ever have to explain this to users? Nobody cares that URLs start with "weird colons and slashes" because you *already* don't need that bit of them. You just type "funnysitelol.com" into the browser and you end up in the right place. That the browser used HTTP to request the page is an *implementation detail*, and (in general) implementation details should be hidden from the user as they are not relevant to the user's task.

    @PSWorx said:

    Or put differently, there is a difference between optimizing for the main use case and throwing all other use cases out of the window.

    All other use cases are already out the window, that's the bit you're missing. People don't put non-HTTP links into browsers. Chrome (the browser in question) doesn't even fucking handle non-HTTP links even if you do paste them in. This is already reality.

    Chrome removing a piece of confusing implementation-detail text, text that was intended to be presented to users in the first place, that's not a bad thing.

    Look, let's talk about the elephant in the room: You, and Mr. Furry Porn, are afraid of change. You're terrified of change. "OMG! It changed!!!!" That's what you're *really* complaining about here.



  • @blakeyrat said:

    And, hell, we're talking about Chrome. Chrome doesn't even support any protocols other than HTTP and HTTPS. It can't even deal with fucking RSS correctly, and that's actually a web protocol.

    @blakeyrat said:
    Chrome (the browser in question) doesn't even fucking handle non-HTTP links even if you do paste them in.

    Chrome 5.0.375.126 handles FTP just fine. Did they remove the FTP-support also in the last beta?


    @blakeyrat said:
    Look, let's talk about the elephant in the room: You, and Mr. Furry Porn, are afraid of change. You're terrified of change. "OMG! It changed!!!!" That's what you're really complaining about here.

    People who are afraid of change wouldn't be using Chrome in the first place. They'd be happy with their IE6.



  • @blakeyrat said:

    Chrome doesn't even support any protocols other than HTTP and HTTPS. It can't even deal with fucking RSS correctly, and that's actually a web protocol.

    RSS is a format, not a protocol. It's a bit weird though that Chrome doesn't spport it though.



  • @julmu said:

    @blakeyrat said:
    And, hell, we're talking about Chrome. Chrome doesn't even support any protocols other than HTTP and HTTPS. It can't even deal with fucking RSS correctly, and that's actually a web protocol.

    @blakeyrat said:
    Chrome (the browser in question) doesn't even fucking handle non-HTTP links even if you do paste them in.

    Chrome 5.0.375.126 handles FTP just fine. Did they remove the FTP-support also in the last beta?

    Huh. Ok I tried 3 FTP sites I know, 2 didn't work, 1 did. Maybe it just doesn't support anonymous FTP? Something's funky with its FTP support, to the extent I just assumed it didn't work.

    @julmu said:

    @blakeyrat said:
    Look, let's talk about the elephant in the room: You, and Mr. Furry Porn, are afraid of change. You're terrified of change. "OMG! It changed!!!!" That's what you're really complaining about here.

    People who are afraid of change wouldn't be using Chrome in the first place. They'd be happy with their IE6.

    You'd think so, but then read some of the knee-jerks about this extremely minor improvement.

    @b-redeker said:

    RSS is a format, not a protocol. It's a bit weird though that Chrome doesn't spport it though.

    Fuck, whatever. Look, I'm sorry I don't type like a fucking robot. You know what I meant.

    It's not that Chrome doesn't support it, it's that it doesn't support it in such a retarded way. If it knows it can't handle RSS, how about maybe asking my OS default RSS feed handler to do it, eh? Instead of showing gibberish on my screen? It's so retarded to have to switch browsers *just* to subscribe to a RSS feed, even IE7 (the oldest browser on my computer) handles this flawlessly.



  • @blakeyrat said:

    It's not that Chrome doesn't support it, it's that it doesn't support it in such a retarded way.

    Technically what it seems to do is: hey, I see not HTML tag, so I'll just handle it as a text file. Which is is, only with Gibberish (TM) in it (some people would call this XML, same difference). As far as user experience is concerned, anyone who can't see through the XML tags (ie 98% of users) will say: oops, this is broken, so the technical view is basically useless.

    I can just imagine someone trying to explain this to the development team.

    The good news is that Chrome now supports plugins, so all you have to do is write a plugin to handle the RSS.



  • @b-redeker said:

    @blakeyrat said:
    It's not that Chrome doesn't support it, it's that it doesn't support it in such a retarded way.

    Technically what it seems to do is: hey, I see not HTML tag, so I'll just handle it as a text file. Which is is, only with Gibberish (TM) in it (some people would call this XML, same difference). As far as user experience is concerned, anyone who can't see through the XML tags (ie 98% of users) will say: oops, this is broken, so the technical view is basically useless.

    I can just imagine someone trying to explain this to the development team.

    The good news is that Chrome now supports plugins, so all you have to do is write a plugin to handle the RSS.

    To expand on that, this plugin: https://chrome.google.com/extensions/detail/ehojfdcmnajoklleckniaifaijfnkpbi appears to be doing what the browser should be doing out-of-the-box. There's another one that only works with Google Reader, but that one actually correctly uses your OS-default RSS reader.

    Now if Google were smart, they'd take that plug-in and paste its code into their repository. Then pay the dude a couple thousand bucks.



  • @blakeyrat said:

    Consistancy is good, until it becomes stagnation and then it isn't. I
    mean, if consistency was the only usability paradigm, then we'd still be
    using Mac OS 6...

    If it was the only paradigm, yes. Good luck it isn't and I never said it should be. However, if you ignore it, you end up with SSDS.

    @blakeyrat said:

    Well, first of all, you're making an assumption here which is that just because Chome doesn't show the "http://" it also doesn't keep track of it internally or copy it to the clipboard. That's goofy. Remember, we're talking about hiding it in the UI, nothing else. There's no reason to believe that you'd be passed any more URLs lacking protocols than you are now.

    This is true, mostly (even though they still fight through a slew of bugs to get all the heuristics right. Currently they have special behavior for host names that start with "ftp"...)

    @blakeyrat said:

    Secondly, are you honestly telling me that if someone sent you a URL like "funnysitelol.com" you'd first try to use a bittorrent client to connect to it? That's ridiculous... UIs are designed for normal human beings, no normal human being would assume that was a bittorrent site.

    You're missing my point here. I'm not talking about people "understanding" URL schemes or trying them out one after another. I'm talking about that as long as schemes are in common use, you can simple pass them along as an opaque string and the browser will know which program to open. If I want to pass an URL to my grandma, it makes not much difference if it starts with http, https or ftp, she will just write it down and don't care about it, because she is used to URLs starting with meaningless glibberish. However, if she expects all URLs to start with something halfway meaningful (like a host name), she'll get confused when other URLs suddenly look completely different.

    @blakeyrat said:

    Entering a non-HTTP URL into a web browser is something that is, by and large, never done by normal human beings. I'm a geek, and I don't think I've ever done it myself. (Maybe a FTP link back in 1998 or something.)

    Um, https again? Also I guess my university's FTP server must still be running in 1998 then.

    @blakeyrat said:

    That the browser used HTTP to request the page is an *implementation detail*, and (in general) implementation details should be hidden from the user as they are not relevant to the user's task.

    Unfortunately it's only not relevant in, say, 80% of all cases. It's an implementation detail the same way the area/country codes are implementation details of the phone system. It makes sense to default the country code to the country you're currently in. However, based on the percentage of phone users per country, you could also just make "China" the default everywhere in the world. But I don't think many people would find that very reasoneable.

    @blakeyrat said:

    And, hell, we're talking about Chrome. Chrome doesn't even *support* any protocols other than HTTP and HTTPS. It can't even deal with fucking RSS correctly, and that's actually a web protocol.

    Actually, I have no problem with Chrome doing that. The main design goals of Chrome were to give the Google services a better client side environment. (And it does that job really well with some really awesome UI innovations). Obviously it doesn't need to implement technologies that Google doesn't need for their services.

    My pet peeve is that Chrome is currently seen as the pinnacle of modern technology and that all other browsers (yes, even IE) are using it as the gold standard. As soon as this goes into Stable, Firefox will follow suit, then IE and then probably everyone else. And no one will be bothered by this, except a the web developers who will notice that this makes a number of things much more complicated for them.


  • @PSWorx said:

    The main design goals of Chrome were to give the Google services a better client side environment. It doesn't need to implement technologies that Google doesn't need for their services.
     

    Chrome is very explicitly marketed as an all-round, simpler, more secure browser for the common man. There are posters at bus stops and full page ads in papers.

    If it is, as you say, meant to be a niche browser with specific design goals for a specific portion of users with special needs, I'm curious where you read that.

    @PSWorx said:

    However, if she expects all URLs to start with something halfway meaningful (like a host name), she'll get confused when other URLs suddenly look completely different.

    Well, they are different.

    My take right now is that it's ok to remove it because it's noise and I don't see any real problems with it, there are currently no worse problems with showing it. So why bother designing that feature and writing code for it?

     



  •  The "Be liberal in what you accept and conservative in what you put out" principle implies that, while the URL bar should make an effort to interpret all sorts of incomplete and nonstandard URL formats in a reasonable way (e.g., bare hostnames with no protocol), it should actually display the URL of the site it has just accessed in its fully-qualified RFC-compliant way with no shortcuts.

     

    If, as some have stated, the new Chrome displays URLs with the protocol invisible, but includes that part in the copy buffer when you copy/cut from it, then that's itself a usability issue; people wouldn't expect what winds up in the copy buffer to differ from what they highlighted on the screen.



  • @dtobias said:

    If, as some have stated, the new Chrome displays URLs with the protocol invisible, but includes that part in the copy buffer when you copy/cut from it, then that's itself a usability issue; people wouldn't expect what winds up in the copy buffer to differ from what they highlighted on the screen.

     

    I agree in theory, but I doubt it's a practical problem.

    Try copying a bookmark from Firefox, and pasting in a text editor.



  • @PSWorx said:

    @blakeyrat said:

    Consistancy is good, until it becomes stagnation and then it isn't. I
    mean, if consistency was the only usability paradigm, then we'd still be
    using Mac OS 6...

    If it was the only paradigm, yes. Good luck it isn't and I never said it should be. However, if you ignore it, you end up with SSDS.

    You know, some of us haven't been here forever. I only know SSDS by reputation-- would replacing that by Lotus Notes convey the point you're trying to convey?

    @PSWorx said:

    @blakeyrat said:

    Secondly, are you honestly telling me that if someone sent you a URL like "funnysitelol.com" you'd first try to use a bittorrent client to connect to it? That's ridiculous... UIs are designed for normal human beings, no normal human being would assume that was a bittorrent site.

    You're missing my point here. I'm not talking about people "understanding" URL schemes or trying them out one after another. I'm talking about that as long as schemes are in common use, you can simple pass them along as an opaque string and the browser will know which program to open. If I want to pass an URL to my grandma, it makes not much difference if it starts with http, https or ftp, she will just write it down and don't care about it, because she is used to URLs starting with meaningless glibberish. However, if she expects all URLs to start with something halfway meaningful (like a host name), she'll get confused when other URLs suddenly look completely different.

    Ok, but you can still do that. You can still give your grandma the piece of paper with the "http://" in front, and it'll work fine in Chrome or any other browser... so I really, really don't understand your complaint here.

    @PSWorx said:

    @blakeyrat said:

    Entering a non-HTTP URL into a web browser is something that is, by and large, never done by normal human beings. I'm a geek, and I don't think I've ever done it myself. (Maybe a FTP link back in 1998 or something.)

    Um, https again? Also I guess my university's FTP server must still be running in 1998 then.

    When's the last time you actually typed a HTTPS URL into your browser? In 99.9% of cases, it's entirely unnecessary-- the site will automatically redirect you to the secure version the site has private information on it. In the other 0.1% of cases, it's completely optional-- like if you're completely paranoid, you can run Twitter over HTTPS, but it's harmless if you don't.

    How often do you use your web browser to view a FTP site? Even if you don't have a FTP client (what a quaint notion), every OS on Earth natively supports FTP anyway... I just don't see the point to using FTP in a web browser.

    @PSWorx said:

    @blakeyrat said:

    That the browser used HTTP to request the page is an *implementation detail*, and (in general) implementation details should be hidden from the user as they are not relevant to the user's task.

    Unfortunately it's only not relevant in, say, 80% of all cases. It's an implementation detail the same way the area/country codes are implementation details of the phone system.

    Country/area codes are not an implementation detail. You said why in your own post-- without that portion, the phone system doesn't know how to route the call. So I don't know why you bothered writing this idiocy when you know it's a terrible inaccurate example.

    However, without the "http://", the browser *does* know how to retrieve the website.

    But most importantly: AND I'M SAYING IT ONCE MORE EVEN THOUGH IT'S BEEN SAID 20 TIMES IN THIS THREAD*: hiding "http://" in the UI is not the same as it not existing! It's still there, it still identifies the page as a web page accessed through the HTTP protocol, it's just hidden in the UI.

    So please, please stop posting points that ignore the difference between "hidden in the UI" and "not used at all". If you have genuine points, by all means make them. But please stop misconstruing what this change is to make it seem worse than what is a trivially-unimportant UI tweak.

    *) Pedants: please count how many times that point has been brought up in this thread and chide me if it's not equal to exactly 20.

    @PSWorx said:

    @blakeyrat said:

    And, hell, we're talking about Chrome. Chrome doesn't even support
    any protocols other than HTTP and HTTPS. It can't even deal with fucking
    RSS correctly, and that's actually a web protocol.

    Actually, I have no problem with Chrome doing that. The main design goals of Chrome were to give the Google services a better client side environment.

    News to me. Where did you get this from?

    Everything I've read tells me that Chrome is designed to be a general-purpose browser... if it was designed specifically to give Google services a better client-side environment, you'd think they'd add in some obvious and easy fixes to, you know, give Google services a better client-side environment. Like drag&drop file attachments in Gmail, for example. Or better video options in YouTube, like being able to choose a size in-between "postage stamp" and "fills your entire HUGE monitor and clicking to the other monitor minimizes it again." There's actually a billion improvements you could make if web services colluded with browsers, but Chrome does... approximately zero of those things.

    Or, in shorter form: if Chrome is designed specifically to give Google services a better client-side environment, it's doing a piss-poor job of it!

    @PSWorx said:

    (And it does that job really well with some really awesome UI innovations).

    Yes, like putting the "New Window" command under an icon of a wrench. (Oh wait, I can't gripe about this or it would combat my own previous post about Google usability testing the product! Oops!)

    @PSWorx said:

    My pet peeve is that Chrome is currently seen as the pinnacle of modern technology and that all other browsers (yes, even IE) are using it as the gold standard.

    First of all, Chrome stole many of their UI ideas from IE7, which came out almost a full 2 years before the first version of Chrome. The only change Chrome made (initially) to the IE7 general design is moving the toolbars inside the tab set. So... I think you're really, really reaching here.

    So, anyway, as far as UI innovation goes, IE7 is actually the first browser to use the design that all other browsers have adopted since then-- including Chrome and the next version of Firefox. As far as web standards, Chrome has been pretty cutting-edge (except for the perplexing lack of RSS), and has developed very rapidly. IE is doing the best they can to dig out of the web standards hole they dug for themselves, and Firefox mostly just pretends to be more standards-complaint than the competition, while having extremely obvious bugs that any real reader of the standards docs would have caught and fixed years ago.

    (Interestingly, the real reason Firefox has been standard-complaint is because the W3C's attitude for the last decade or so has been "standardize whatever the hell Mozilla is doing, and ignore IE completely." So they basically lucked into it. To the extent of going out of their way to rejecting entirely sane and useful IE properties in favor of poorly-named-but-otherwise-identical Firefox ones that ripped-off IE. And utterly ignoring document.readyState which would make my life SO MUCH EASIER if more browsers than IE supported!)

    @PSWorx said:

    As soon as this goes into Stable, Firefox will follow suit, then IE and then probably everyone else. And no one will be bothered by this,

    And yet we still have to hear the griping.

    @PSWorx said:

    except a the web developers who will notice that this makes a number of things much more complicated for them.

    You still haven't explained to me how this makes your life more complicated, other than your localhost example which is frankly idiotic-- just add an entry to your Hosts file if you're so upset about it, or get a real QA server like the rest of the world.



  • Damn crazy developers, you. Try a job in system administration and find out how many times you need to prefix the url with http:// or https:// because the mgmt webinterface runs on some other port than 80/443. It will not guess the protocol, you must specify it.

    Integrated Lights Out? https://127.0.0.1:2381

    ASSP? http://x.x.x.x:55555

    I'd get pretty pissed off when it doesn't show what protocol I'm connected with. Typing the address as it's shown in the address bar won't work. I don't care if you can copy and paste it correctly, I don't care what you change-obsessive lot think, get your own Internet and go develop browsers there.



  • I noticed this when it happened, but it doesn't do anything really surprising. Even highlighting and middle clicking injects the protocol into the pasted text. I wouldn't call this a huge usability win, but only because it's very trivial, and I can't see this being a big deal either way, except that it makes https a bit more obvious (since it always shows up), which may have been part of the goal.

    Sounds like a corollary Sayre's law: The bug reports are so vicious precisely because the stakes are so small.



  • I am so confused.  I am so confused as to what the problem here is.  I've tried to read every single post in this thread in their entirety, but I swear we're all from different planets or something.

    I'm glad you guys weren't around when browsers decided to hide the default ports.  Why is it so terrible to hide the default protocol?

    What is wrong with displaying "x.x.x.x:55555" (assuming the browser hides the default protocol when the URL uses a non-default port)? And wtf wouldn't typing "x.x.x.x:55555" into the address bar take you to http://x.x.x.x:55555?  I just tried it and it works perfectly fine in Firefox.

    What's this big deal about UI consistency when it's already well accepted to sometimes show the port number and sometimes not?

    If it was up to you bunch, we'd all have to type in "http://www.thedailywtf.com:80" every time we wanted to go to thedailywtf.com.   Geez.



  • @badcaseofspace said:

    I'd get pretty pissed off when it doesn't show what protocol I'm connected with.

    But it shows every protocol except "http://". "https://" is already extremely obvious, via a lock icon and yellow URL bar. "ftp://" has special handling, as someone mentioned above in the thread.

    Are you saying that you really can't manage to use process of elimination to figure out what protocol was used?

    I swear to God you people are misconstruing this change *on purpose* to give yourself a reason to hate it.

    @badcaseofspace said:

    Typing the address as it's shown in the address bar won't work.

    Why not? You forgot to explain this bit. I'm not going to take it as gospel until you tell me why it won't work.

    I mean, I just tried it... pasting in "10.14.40.70:8080" into the URL bar. It works fine on the current version of Chrome. Are you saying there's some regression that would make this not work on the new version? If so:
    1) Why do you assume that regression exists? Do you know it exists, or are you just making up reasons to hate this change?
    2) Why do you assume it has anything at all to do with hiding "http://" in the UI?

    "Man, I really hate the next version of Firefox. If you add a bookmark to google.com, it murders 12 kittens!"



  • @badcaseofspace said:

    I'd get pretty pissed off when it doesn't show what protocol I'm connected with.
     

    If your problems are limited to the http vs https, then https: is more effectively indicated by blinkenden lightz.



  • Yep, FF does by guessing http for non-default ports, but IE 6/7/8 will not make that assumption. FF is more graceful, IE is more accurate. I'm not saying which one is better.

    But let's say someone is doing a manual for this app or making some screenshots with Chrome, and happily writes in his manual that you can enter ipaddress:7000 to open the Web Interface You've Always Wanted. The guy doesn't know any better, right? And then why doesn't his manual work when you happen to use IE?

    Maybe it'll work when IE's behaviour changes, maybe if the user knows to prepend http://, maybe if you can write universal documentation remembering all those quirks browsers have. Until then, I stand by my opinion that as long as application publisher's can't agree on one or the other that the more relevant information we have, the better. Am I the only one who thinks that it's relevant information? Or information at all?



  • @badcaseofspace said:

    But let's say someone is doing a manual for this app or making some screenshots with Chrome, and happily writes in his manual that you can enter ipaddress:7000 to open the Web Interface You've Always Wanted. The guy doesn't know any better, right? And then why doesn't his manual work when you happen to use IE?

    You're going to strain yourself reaching that far.

    Seriously. Just admit you don't like change (both to yourself, and to us.), and we can all move on. People respect honesty.

    @badcaseofspace said:

    Am I the only one who thinks that it's relevant information? Or information at all?

    People "think" a lot of things that aren't true.



  • @blakeyrat said:

    You're going to strain yourself reaching that far.
    Yah, must be a real disappointment visiting TDWTF and reading a far-fetched story. Boo hoo.

    Now, I haven't heard you making the point of why this change is long overdue, other than pointing out that everybody who thinks otherwise is a retarded baboon.

    At least I'm not speaking for everybody else.



  • @pkmnfrk said:

     What's wrong with hiding http://? Is there something particularly userfriendly about it?

     Me: "Okay, just go to ehch tee tee pee colon slash slash google dot com"

    Dad: "It's saying something about an error."

    Me: "Did you put forward slashes?"

    Dad: "Which ones are those?"

    Me: "The ones tilting to the right."

    Dad: "Oh, no. Do I need to?"

    Etc, etc.

    Also, www was the typical name of the particular server listening on port 80. Alas, it caught on.

     

    I always wondered how to phonetically spell "H". Thanks!


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.