Website mistakes that are easily fixed | Hacker News Reader

Website mistakes that are easily fixed

hanselman.com

79 pointslauriswtf68 comments

I particularly hate when someone does things like (1)

  <a href="navigateToFoo()">

when it should be

  <a href="foo.htm">

so I can't middle click it or Ctrl-click it to open in a new tab. Even worse if there's (2)

  href="#"

added, which upon middle click will happily load the page I'm currently on inside the new tab.

I have an extension in Firefox which changes the mouse cursor for (1) from pointer (hand), so I can easily distinguish that case, I hope this became a W3C standard somehow (though the standard way for executing JS are buttons, not anchors, so probably it won't ever become standardized).

*should have been

  <a onclick="navigateToFoo()">

I'm surprised that no browser has done the obvious yet: treat middle-clicking a DOM element with a bound onclick handler the same as left-clicking that DOM element, but override window.open and window.location.redirect within the context of that handler call to open links in a new tab instead.

> There can be a whole list of languages in the Accept-Language header, in the order the user prefers them! Use that data, it's there for you to use.

Yet it takes only jumping a plane for a few hours to get Google to think I can and want to read Georgian. Google's i18n for anonymous users (I'm not logged in on my phone's browser) is the most ridiculous I've experienced, every border I cross I get a different language.

I think that's the point. They're using IP geolocation when the article suggests that the Accept-Language header would be a better choice.

I don't know whether this is generally true, but it sounds like it would probably help your situation.

> I think that's the point. They're using IP geolocation when the article suggests that the Accept-Language header would be a better choice.

That was my point :) If I set up us-en everywhere, don't try to be smarter and just show me everything in English.

From my experience, Chrome installs default to en-US without trying to pick up language settings from your computer. (I'm probably doing it wrong)

Not an excuse, but it sounds like they don't trust accept-language to be correct.

Chrome is atrocious. It uses your IP to determine language, even if your OS is another. You can't completely undo it after install; the default search engine is still the country/language you downloaded Chrome from.

Even funnier is when you get Chrome working in the right language, then do a Google search, the results come up in whatever language Google thinks based of IP, then Chrome offers to translate it.

It's so idiotic.

The Play Store is even worse. Some idiot at Google decided that apps with country restrictions should just 404 when you try to access them. So I downloaded an app for my bank. Go travelling. Get security alert update. Try to update? Nope, app not found. Even though it's running on my phone, I can't get to it via Play. Go to the Play website via a proxy and install it? Sure, that works.

I bet if the responsible people were forced to travel or be expats for a bit, this would get coherent quickly.

Try looking at it from the point of view of a Thai guy, who lives in Thailand like most Thai folks do, and who has to put up with all the websites written in English, because webdevs like to assume only Americans access the Internet. Like everyone else, his OS language is set to en-US because nobody likes to mess with system defaults.

Chrome does this guy a huge service by translating a lot of websites to something he can read. So what if it pisses off a few travellers? There are a lot more native Thais in Thailand than there are foreigners.

> Like everyone else, his OS language is set to en-US because nobody likes to mess with system defaults.

You mean pirated Windows system defaults? Because legally you buy localized copies, and when you install any popular Linux distro choosing the language is one of first steps if not the first.

It's the same with proper windows. You install and you pick your location and keyboard set up. There will be very very few people in the UK, for example, with en-US windows because the keyboard set up is different (mac's that's another story)

IMO, browsers should pick up your OS language settings by default OR make it very simple to both see what your browser default is and to change it. (without an add on)

I live in the UK, but I'm a US ex-pat so I get snared with i18n problems quite a bit when it comes to addresses on my US accounts.

It gets worse because I forget to change my browser to en-GB, and I come across US run .co.uk sites that rely on accept-languages to assume the format of my postcode. sigh...

Why is the Thai guy running Windows/Linux in English?

Why is he on the English website for Chrome in the first place?

I'm in Central America often. When downloading Chrome, I get redirected to the Spanish site. OK, so I explicitly find the English page. Download. So far, everything in English. Then Chrome itself inside the downloader overrides all that and installs in Spanish. The only way to override is to ensure I'm on a proxy.

I'd love to know the statistics of people overriding Google's localized site (forcing google.com in English versus local Google site), overriding the Chrome page (change the URL to have "en" wherever needed), running an OS in English (with no alternative keyboards), that still want it in the language of whatever country they're in.

Not to mention, this falls flat in multilingual countries.

Not just anonymous users. Even as a logged-in user with set preferences Google constantly knows better than you which language you want.

"Oh, so you did a local search for hardware stores in insert-country-here? Well, than let's change your default settings to insert-language-here, regardless of what you told us you wanted."

This nightmare grows exponentially if you're in a multilingual country.

Go to http://www.google.com/ncr and it will forward you to the main US version of Google (it will also set your language preference which helps if you find yourself being redirected to the local countries Google domain later).

That doesn't override Chrome's idiotic installer which has the language logic built into the installer itself, so it grabs a localized version off your IP when the downloader runs, regardless of every possible hint to the contrary.

Yeah, I hate this. Can we all agree on just notifying the user of the existence of the localized version of the page in these cases, without explicitly and automatically forcing the localized version on them? I'm pretty sure this can be done elegantly from an UX point of view, and Internet would be a much better place if everyone did this.

I'm really annoyed by those sites that insist on having a non-removable top bar overlaying the text. Because they break the page-down key. You page down, but part of the unread text scoots under the top bar. Arrrg.

Bootstrap helped popularize this pattern, and I don't think it's been good for the web. It also steals valuable screen real estate for tiny laptops, like the 11" Air.

When you connect this with the usage of Zoom Text Only option in Firefox, due to zoom (bigger text) + an overflow (if divs do not fit any longer within the parent width) the top bar can take substantial part of the screen on desktop also. Quite annoying indeed.

When websites do it well I love it! They can pick the most important links for me and put them in the nav so they're always available without me having to scroll around.

If you use Firefox, since about version 17 or 18 it adjusts the amount that Page Down/Page Up/Space/Shift+Space scroll by if it detects a fixed header. It doesn't always work (non-full-width headers it doesn't typically catch) but it's absolutely marvellous to have.

It's the funny thing about floating navigation; usability testing and A/B testing show that it's good for conversion/engagement/whatnot, but until Firefox fixed it I absolutely hated the pattern for this very reason.

Here's one he missed: your "country" dropdown has a list of every country in existence, alphabetically. So for the US you have to scroll down to near the end of the list past hundreds of other countries.

Instead, put your audience up top (Canada, US, GB maybe) and then alphabetically list the rest.

You can press U to skip to the Us.

I love that trick. I often try to type more, but since "USA", "U.S.A." and "United States" are all different it often ends up backfiring. It's eally minor in the grand-scheme of things, but it often makes me feel unlucky for guessing incorrectly!

I've also found it helps to use a divider to separate your audience section from the rest. If you just lump them together with US at the top you're more likely to get grumblings about "US-centric" this or that, but the divider helps communicate "this is our expected audience and we're making it easier for them, but we're inclusive of everyone else below as well".

Actually the solution you're suggesting is one of my pet hates. An alphabetical list of countries should be alphabetical! If you put some countries out of order you just make it more difficult for people to find their country if theirs isn't the one pre-selected.

If your audience is mainly US, then by all means pre-select the US, but keep the list alphabetical. If your audience isn't mainly in one country, either don't select anything, or for extra bonus points, do a Geo IP lookup and pre-select the country they're in.

I think one of the worst things I've seen is the State/Province version of this. I try to scroll down to "B" for "British Columbia" but lo and behold, there's nothing listed between Arkansas and California. I double-check the country dropdown... still says Canada. Yeah, the genius web developer decided to list all 50 US states before the Canadian provinces, regardless of what country was selected.

I've gotten good use out of this script: http://baymard.com/labs/country-selector

Populate it with the data on names and alternates and priority, and it knows gets you to a short list with "un" (with "United States" first), while also offering Germany for "deu" or the United Kingdom for "bri".

It solved so many hassles for a client's internal online ordering system. Beautiful work, really.

Asking for city, state and zip code is my favorite on the list. Plus the country should be asked for first then if US only get the street and zip code.

There was a link on HN sometime ago that showed that people trusted the form/page more when complete address information was requested (I believe the conclusion was that people were used to doing it that way) so maybe there is a downside to the shorter version.

I always find it jarring when a site does this inference since it's so uncommon and really doesn't save much time or mental capacity.

Yep it is one of those things that is deeply ingrained. It doesn't save much time but I believe if you don't need to ask for it, then don't. Asking for it only increases the chance of users entering something incorrectly.

As a webmaster you should also know your audience too. It may be cool for you to do this if your target traffic is hacker news, but for non tech savvy people it will only confuse them more.

Some people are also mistrusting of tech magic as well. I say this because one of our site deals with eBay sellers and I remember this duffer person complain that we were somehow hacking his ebay account getting information he never gave us (the title, description of his auctions when all we knew was his id)

Funny. This is the one to which I had the most negative response. Zipcodes are terrible for inferring anything geographically interesting. A single zipcode is just a collection of USPS postal routes; nothing more, nothing less. They don't have to be contained within a single city, or even a single state, nor do they have to be contiguous, and they can overlap with one another. New ones are also added all the time, and no publicly available databases of them handle any of these problems well. Most applications that try to use them for anything end up running across edge cases that show users incorrect data, often without ever realizing it. It's especially unfortunate because so many startup-y people live in urban areas where zipcodes cover small, regular geographic areas, and have no idea they're potentially creating terrible user experiences for people who live elsewhere.

For a particular case study of sorts, see: http://sunlightfoundation.com/blog/2012/01/19/dont-use-zipco...

ZIPs are almost always fine at a state granularity, and pretty good for cities. If the form is street/city/state/zip, you can autofill State correctly from ZIP 99.9% of the time.

Do you have data supporting the 99.9%? I suspect that's high; there are buildings within five blocks of where I'm sitting that have a zipcode that crosses a state line, and I don't think it's the only state-crossing zip in my area (Washington, DC, for what it's worth). In any event, even if it's accurate, it doesn't take that much traffic for a .1% error rate to start to add up to non-trivial number of users, especially because that .1% is going to have a noticeably-jarring experience, as opposed to the alternative (collecting all fields) which everyone is already completely accustomed to.

Well, this list shows 293 ZIPs that cross state lines [0], this FAQ says there are ~43,000 ZIPs in use [1] so that puts it closer to 99.3%.

But think about it, if you're taking an address to ship something, getting the ZIP right is what matters. If your package has 45201 on it, it doesn't matter if it says Cincinnati, OH or Cincinnati, KY.

[0] http://web.archive.org/web/20110112211559/http://maps.huge.i...

[1] http://www.carrierroutes.com/ZIPCodes.html

But if you're collecting a billing address (probably more common, since many places bill but don't ship, e.g., for digital goods, but not that many ship without billing), and are trying to expedite filling out the form by guessing the city and state from the zip, I doubt the payment processing would succeed if you got the city or state wrong. All depends on the situation, I guess.

Actually, should work as long as the zip code is right.

AVS[1] doesn't even look at the city/state. It only checks the ZIP (5 or 9 digit) and the numbers in the street address.

[1] http://en.wikipedia.org/wiki/Address_Verification_System

Google Maps has my postal code wrong for 2/3 places I've lived.

I did a form that worked wonderfully... you entered a zip/postcode (first, before country and such).

The form would look it up in a background ajax call. It wouldn't tell you this or block your actions. If it found a match in our DB, it would populate the city, country fields, not make a mess, and leave you free to edit the form if it was wrong. Your flow would be the same either way.

I think not interrupting the users flow was a big part of it.. it didn't make people go "What? How do I change that? What happened? That's not right".. you just kept filling it out like normal... with some fields pre-filled if you were lucky.

The UK postcode system is accurate enough that a lot of online retailers will ask you first for the postcode (5 - 7 character) and then they'll offer the short selection list of valid addresses (mostly just house numbers) for that code. It's great.

godamn credit card forms! those get me the most because we're at the moment where i'm trying to give you money, and they pull some passive-aggressive bullshit like limiting the field length to 16 characters.

i can almost type in my whole card number, but then i can go no further and i have to manually go back and remove all the spaces and then go to the end of the number and enter the last digit. class act.

> like limiting the field length to 16 characters

Or worse: requiring the spaces. Or maybe they want dashes.

> <input type="radio" name="fruit" id="banana" /><label for="banana">Banana</label>

Slightly pedantic, but it's even easier than that if you don't have any elements separating them - you don't even need the id:

> <label><input type="radio" name="fruit" /> Banana</label>

This adds convenience on desktop, but it's really annoying not to have it on smaller mobile screens.

It's also compatible with assistive technology (though be sure to note the edge cases): http://www.html5accessibility.com/tests/form-labels.html

(based on discussion 6 months ago: https://news.ycombinator.com/item?id=4890631)

The first version became popular because for by far too long, the IE's failed to properly handle the second, nested, version. The textual label would stubbornly refuse to click the input unless the id= and for= attributes were applied.

Accept-Language header is not reliable esp for non-English speaking countries. Many computers/browsers are by default EN, esp if the O/S doesn't support local language.

For example, Indonesians speak and read Bahasa all the time, but most browsers there report EN.

WRT language selection and availability, I developed a small Rack gem `i18n_best_langs` that could be useful to web devs.

https://github.com/gioele/rack-i18n_best_langs

It picks up clues from various HTTP pieces (headers, URI) and generates a list of locales in order of possible user preference. It is then up to the web application to make good use of this list of preferences.

It is alpha quality but I would love some criticism about it from HN readers.

I'm glad I'm not the only one who's anal about redirecting to the canonical host name. Now, let the bike-shedding begin: should the canonical host name be www.foo.com or foo.com?

www allows for the use of CNAMEs (which, as I understand it, is why the www convention was established in the first place).

The convention of using relatively-short service-based host portions of an FQDN pre-dates the WWW. It was common to use mail, gopher, irc, whatever for various servers from a functional point of view.

Whether it was an A record or a CNAME record was generally at the adminstrators preference. CNAMEs had their own hiccups and weirdness to deal with, and still do to a lesser degree.

It should be www., generally, unless you're a huge site and then you can do whatever you want (cf. Twitter)

The reason I say this is for smaller operators who may not be running multicast'ed servers in 3+ geographical areas, then you'll probably want most of your traffic pointing to a CNAME of a CDN or at least a cloud-hosted load balancer.

I say "www." needs to die in a fire. It's ugly and pointless, and doesn't stop you from using other subdomains if you want them.

"www." is a good indicator in other media that a web address is being presented when it might otherwise be not entirely obvious.

Not entirely pointless.

I'm a fan of web.foo.com, personally. Much easier to pronounce. ;)

At the end of the day, it's never about what we can do, it's what we can do within the budget and time that we think is appropriate for what we want to do.

One more thing that's been getting a lot of traction recently is CSS transitions. Some devs are using them for hell everything, because they can. When it's too much of it, it feels like old shiny GIFs whenever you change the zoom level of the text.

I've saved in bookmarks one page that made my eyes bleed due to it, but I don't have access to it right now. Stay tuned, I'll post it on Monday :)

I specially agree with the "Download the app now" messages. I hate those because I know how to look those up if I really want to, so just let me get to what I came to this site for.

Annoying, maybe, but I don't think it really fits with the theme of the rest of the list. Providing the user with a potentially helpful shortcut to an app doesn't really compare to breaking deep links for the mobile web.

I don't mind the flags thing, yes I sometimes roll my eyes when I have to hit the stars and stripes for "english", but I can spot it or a union jack out of a set of flag pictures faster than I can find the word "english".

You also have the case of foreign users on public computers who may be unable to fiddle with the language settings.

User are afraid to set any browser setting. It would be better for them to choose the language through web page.

You should also consider user may not be able to switch the language of a public computer. The setting may be locked, or the operating system is in another language, e.g. Chinese, user doesn't even know where the "setting" button is.

I didn't see it listed so far, but checkout forms that require you to select the type of credit card you have. Since the card (Mastercard, Visa, Discover, AMEX) can be determined by the first digit.

I don't see too many sites that require something like this anymore, but every now and then one pops up.

I absolutely hate it when I'm paying with Paypal and you make me enter my shipping address. It's not only a waste of time, but if I have to type in something over and over for every order, it's much more likely I'll make a mistake than if I only have to do it once through the Paypal site.

You can also address multiple languages with hreflang: http://googlewebmastercentral.blogspot.hk/2013/04/x-default-....

So true. It's frustrating to see people spend hundreds of hours to advance some "fringe" web technologies that don't really affect much in the end, while stuff that we use every day, everywhere continues to have the same (solvable) issues year after year.

Regarding the title of his article, as a someone who routinely uses TCP/IP for tasks other than transmitting HTML, I find his concept of "internet" to be rather myopic.

I find it difficult to believe that you are actually bothered by web developers referring to what they work on as "the internet."

Can we please suppress the burning need to find something "wrong" to nitpick in every headline? I know it's really satisfying to be the HN Superstar that points out a blatant error, but sometimes it just makes you look desperate.

Reply on news.ycombinator.com