3 ms·

> They don't see the positives because they're technically advanced enough and don't benefit from simplification (or so they think). I'm noticing despite the i

> They don't see the positives because they're technically advanced enough and don't benefit from simplification (or so they think). 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?

abalone 8y ago
> 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. 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.
- wwweston 8y ago
  > I literally began my comment by citing this: 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.

abalone 8y ago

> 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. 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.

wwweston 8y ago
> I literally began my comment by citing this: 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.