Hacker News Reader

Comment by jstanley | Hacker News Reader

> You see, there’s more than one way that people expect type-to-search to work. In one pattern, you type the first letter of the thing you want, and the system finds the first item that starts with that letter. If that’s not the one you want, you press that same letter again, and the system finds the second item that starts with that letter. Keep pressing that same letter until you get to the item you want.

What! This is crazy! There can't be that many people who expect type-to-search to work that way.

View on HN

The primary situation where I find this behavior useful is on the web where I find Country drop-down lists. I am trying to find United States. It could be "United States", "USA", "U.S.A.", "United States of America", etc. All you have to do is keep pressing "U" until you find the match you want. It really helps when the desired match could be formatted several different ways.

That assumes, of course, that the website isn't using some ridiculous drop-down component that doesn't support keyboard interaction or tab handling. Sadly, that's about 50/50 these days.

Only if it's a shared beginning.

It's a little less useful when you're searching for Ireland, Republic of Ireland, or occasionally Éire.

Or if I'm not sure whether the box uses England, United Kingdom, UK, Great Britain, GB, United Kingdom of Great Britain and Northern Ireland (yes I've seen this spelled out once). Sigh.

You forgot "Britain". So it's unclear whether we should look for words starting with B, E, G or U.

And there's also the case of dropdowns putting some most frequent countries at the top, so you spend ages scrolling to find the correct spelling, when listed above "Afghanistan".

Also fun when you're given flag emojis to choose from, sorted by country name, and you don't know which of UK/GB/EN they have used to sort with, and whether you should look for St. George's cross or the Union Jack.

I have always used select dropdowns as a regular text input. I just type the thing I want until it appears on my cursor and I press enter. Never imagined repeated presses would toggle results.

These are frustrating.

I understand that it's too exceptionalist / nationalist to give the USA a special slot at the top, but ... If I'm on an English page registering for something run by an American company, there's really good odds that I'm in the USA.

Could we just do the top 3 by population, before switching to alphabetic? I'm willing to hit Down twice to get past India and China.

Use the IP address to guess and preselect the country, and let the user correct it. No need to privilege any country.

There is the accept-language key that the user can send in the header. The correlation of those and country of location should be quite good.

I think using geo IP is borderline spyware behaviour.

Becouse the databases are derived from some sort of spyware, right? Or are ip ranges public on country level? The city location has to be spyware derived?

Country from IP is usually based on public whois information about the IP range. No spyware involved.

For city-level it gets more complicated. Every provider of IP geo-localization has its own way of doing it. I guess google uses aggregated information from web searches to figure out the city/region for a given IP range... and sometimes it blatantly fails, because ISPs might allocate IPs in unexpected ways for their algorithms, or move them around to different cities/regions. I'm often getting geolocalized (by IP) to a totally different part of the country. I've seen similar behaviours in other countries and with other ISPs, so it's not something that can fail relatively easily.

Then there might be another source of information, which is more spyware-like. Android devices (via the Google play services, I think) participate in constructing a database of cell tower IDs and WiFi access point MAC addresses along with their GPS-derived estimated geographic position (see more: https://console.cloud.google.com/apis/library/geolocation.go...). Apple has a similar service, too. Theoretically the could use the submitted information to geolocalize the source IP range, but I'm unsure whether they actually do it.

I see thanks for the explaination.

more like IP allocation databases and ping times

Even setting aside languages spoken in multiple places, please leave the accept language header to languages, not regions. I have en us, because that's the language I want, but I've never been in the US and probably never will.

Ye correct. But the context here is to provide 'top of list' items in a dropdown.

E.g. German would be like 3 countries, unless Austria and Schweiz have their own language code. Uk and US got different codes.

Diaspora languages could just have 0 added top items, etc.

I also have us-en, to avoid these crappy machine translations you get sometimes.

> German would be like 3 countries, unless Austria and Schweiz have their own language code.

Officially, we have de-DE for German German, de-AT for Austrian German, de-CH for Swiss German, de-LI for Liechtenstein German – Chrome knows all of those. Plain "de" means German of unknown variant/dialect, but statistically is more likely Germany than any other country.

German is also a secondary official language in Belgium (de-BE), Luxembourg (de-LU), Namibia (de-NA), and also in one region of Italy (de-IT), but software awareness of those German variants is less common (Chrome doesn't know about them, but some other software packages do, e.g. ICU and Microsoft .NET).

> I have en us, because that's the language I want, but I've never been in the US and probably never will.

On my personal laptop, I have en-US, because I don't know why. Maybe it is the default for Chrome?

I have en-AU set on macOS at a system level but Chrome seems to have ignored that.

I just reconfigured Chrome to add en-AU before en-US, so now my Accept-Language header is en-AU,en-US,en

My work laptop has macOS set to en-AU but Chrome set to en-GB. I'm not sure how en-GB happened, possibly something my employer did for whatever reason.

Yes, they are public on IP ranges.

> I think using geo IP is borderline spyware behaviour.

With corporate VPNs it often doesn't work anyway. Even though I'm not in the US, I sometimes am forced to use the US VPN access point (e.g. because someone forgot to add the IP range for the non-US VPN access points to the firewall rule for internal service X, and if I complain it will be fixed in a day or two, but I need to use internal service X right now). While I'm doing that, websites will think I'm in the US, even though I'm on the other side of the planet.

South Dakotans (as opposed to South Carolinians) appreciate this because in a state dropdown you can just press S twice, instead of `south d`).

Or you could just press "SD" instead of "SC" and appreciate how is more intuitive

This only works if the "State" field in question uses state abbreviations. Frequently, such fields use the full name for each state. Therefore, `SS` gets you to South Dakota every time.

It also works with full names when search field supports fuzzy search with word matching (or abbreviation matching with a higher priority).

SS only works when the field is using the mechanism described in the blog, therefore it doesn't work every time

> The primary situation where I find this behavior useful is on the web where I find Country drop-down lists. I am trying to find United States.

Pet peeve: when the website obviously has 99% of users who will pick "United States" for country, but they use an alphabetical list of all the countries in the world.

“We don’t even ship to Alaska because of the lithium batteries in our product, but we’ll still make you scroll past ‘Uganda’ to enter the single country we ship to.”

Not exactly those words, but I’ve seen it.

Actually that's the most sane way for countries sorted by alphabet. Since I live in Canada I always expect CCC...until I hit one.

In a list of "Countries by alphabetical order", I see:

- Cabo Verde - Cambodia - Cameroon - Canada

So if you were typing 'can' instead, you would always be correct (today) even if one of the earlier ones were removed.

Yeah, Canada seems easy to me. United States of America, I could relate to due to so many different ways of writing it.

That only works because for the country list you have no conflicting repeated keys like "ll" going to "lemur" instead of "llama"

And that's the overwhelming majority of cases. Wanting to select an item starting with the same letter repeated twice is rare. It makes sense to speed up common cases at the expense of rare cases.

Not really since those rare cases are more memorable, so in addition to other UI elements having different behavior (though I admit this is the much bigger factor) you don't treat this as a reliable mechanism for search. So you'll just enter the next letter as you do everywhere else, and your frequency balance changes

And it especially doesn't make sense for such an long-standing core UI toolkit to not have these kinks ironed out. These behaviours are already handicapped by their obscurity, no reason to make them behave counterintuitively on top of that

As a long-time Windows user, I simply have to disagree. I use both methods constantly, and removing one would be a significant degradation in usability. Whenever I have to use software that doesn’t have them I miss them sorely. The rare case, on the other hand, is so rare that I don’t even remember the last time I came across it. It is negligible.

The behaviors also aren’t that obscure, assuming you learn that you can select by typing a character in the first place. When used regularly, you then rather quickly learn what happens when you type multiple characters.

I'd say it's the opposite - it makes sense for unsorted lists (CCC gets you to the third C-country) because if it's sortes you can just press C-down-down which is just as fast if you have your hands on the keyboard. And if your right hand is on the mouse, you'll still have to either move the pointer to the right country and click it (at which point might as well only press C once) or move it to Enter (at which point the arrow keys are just as reachable).

Because that’s how previous Windows did it! So there’d be millions trained to expect this behaviour. Developers love to accidentally rug pull on customers by thinking, “there’s no way people would expect it to work that way!”

I expect it to work that way. That's the way I grew up with. It's faster than pressing a letter then pressing down. It's a skip-to-item function to not a search function ARE YOU HEARING ME NAUTILUS

How is it crazy? This behaviour always made sense to me.

I'm basing the listview behaviour based on how I interpret the article.

Suppose you have a list:

  - jaguar
  - llama
  - lorax
  - manatee

Typing 'l' should position the cursor on 'llama'.

Typing another 'l' would signal that you want the next 'l' element and move the cursor to 'lorax'.

To correct the position, you'd either have to hit backspace to go to the first 'l' item, press 'a' to move to the first 'lla' item (I'd hope... but if the control went to the first 'la' item - ignoring the second 'l' I typed, then I'd say the control has gone out of the ballpark)

Or maybe the user moves the cursor with one of the cursor keys to position the cursor on the desired item.

In theory, if you have a folder with every files that have every two-letter combination at the start, there will be 650 files with distinct letters and only 26 files that have the same first letter and same second letter.

In practice, the amount of actual words that have the same first letter as the second letter is minuscule. Even words that have the same letter appearing twice in sequence.

It's just optimized for the most convenient scenario.

> "In practice, the amount of actual words that have the same first letter as the second letter is minuscule."

In the enable1.txt wordlist of 172,823 English words, there are 126 starting with a double letter, and those are largely the variations of oohs, aahs, oomphs, oozes, aardvarks, eels, eerinesses, and oodles of oocytes, oolites, oophytes and oologists near oomiaks.

> To correct the position, you'd either have to [...] press 'a' to move to the first 'lla' item

Tested with some text files on Windows Explorer on Win11, typing lla actually moves from llama, to lorax and back to llama. I also put alpha on the list to see if it would jump to that, but it didn't.

Back in 1991 I was at Sun and tasked with implementing type-to-complete for file dialogs in OpenWindows. Coming from a Mac background, I naturally implemented... type to complete. But the OpenWindows Spec declared it should be "first letter, keep typing first letter".

That method requires you to very explicitly look at what is selected each time you press 'B', as opposed to just typing 'bagend' or 'bilbo'. Maybe it makes sense if you can't type? In any case, I added a secret preference to do it the right way, and then quit.

Imagine if the web browser incremental search worked that way...

I agree.

That's the behaviour that I programmed for the listbox in the Address Book for Microsoft's email product, which you should see in MS Outlook (they might have changed the behaviour since then).

The main difference for that address listbox versus most listboxes/listviews is that the address listbox will update the display to show the sublist of matching items (and do the hard work of updating the scrollbar to show the size of this sublist and how many items are in view).

The expectation was the user would move the cursor with arrow keys or type more or the desired substring if the cursor wasn't placed on the desired item.

> In any case, I added a secret preference to do it the right way

It's harder to do these sort of guerrilla things when every line is code-reviewed. Or maybe you snuck it past your peer?

There wasn't a lot of code review going around our group in 1991 - but you're absolutely right that it would be harder to get away with today. There are a lot of hidden knobs in various places across various systems, and they are a potential liability since they're frequently untested and may even be a vector for an exploit...

sudo dtrace -qn 'pid$target::getenv:entry { printf("getenv ( %s )\n", copyinstr(arg0)); }' -c "/bin/ls -l"

It's crucially useful for menus, where the items are always the same, arranged in the same order. When you use a certain menu item often, you know to press (say) Alt+M-C-C. And it's not unusual to have several menu items with a long common prefix, so typing a prefix wouldn't be efficient. This is particularly useful in long menus that ran out of accelerator keys, or in extensible menus like the Explorer context menu where not all extensions care to define one, or do conflict with each other.

This is also the case when navigating folder hierarchies in Explorer, which, using letter navigation, is similar to navigating nested menus. After a while I know that a certain folder is L Enter C Enter S S Enter P P Enter, and that way is offen quicker than going by prefix sequence (second method), also because you can hit the same key in sequence faster than different keys.

> And it's not unusual to have several menu items with a long common prefix, so typing a prefix wouldn't be efficient

Especially not on systems where companies think your file system and the start menu are advertising space. That gets you multiple entries starting with “Microsoft ”, “Adobe ”, “Google ”, etc.

Yes, it may (still) be possible to rename those (for third party applications, you can on MacOS, for example), but I bet most users won’t do that.

While it's key sequence specific, you can't (in genera) hit the same key faster since you can only hit it the second time after it's been released while you can hit another key while the first one is still down

Another more intuitive solution for menus with long common prefix is to simply type the next unique letter: pa or pb in

PrefixA

PrefixB

No need to type the full PrefixA

If you run out of accelerator keys, any key you type will activate an accelerator, so you wouldn't even have a way to do a sequence? So there is simply mode 2 possible

And folder hierarchies aren't stable unlike menus, so you loose precision if another folder is created /deleted.

Though if you really have to frequently use such long sequences it might be easier to add this folder to a custom favorites panel and use two keys: shortcut to invoke a panel, P accelerator for the name

Remember Mitch the XView guy who always wore Hawaiian shirts?

> That method requires you to very explicitly look at what is selected each time you press 'B', as opposed to just typing 'bagend' or 'bilbo'. Maybe it makes sense if you can't type?

It makes sense if you can type: that is, if you can type while looking at the screen instead of the keyboard because why would you look at the keyboard? To find the keys you want to press, one by one?

This sounds completely reasonable, but this is also the first time I've seen it described as a search. Windows File Explorer works this way.

it's not reasonable for "ll" not to select "llama", but something else because of some invisible mode switch, that's just bad/confusing UI with inaccessibl rules in big lists (because you'd expect the user to hold the whole post-prefix word list in his head and be able to do this calculations in real time to understand what to expect)

Of course, you can still keep both with a fix to this issue unless there is some other more intricate one

I'm annoyed whenever I'm in a list view and either the first or the second mode doesn't work. That's how useful both of them are. Usefulness trumps minor inconsistencies.

The first mode is also crucial for menus.

IMO it all hinges on whether the UI offers somewhere for the user to iteratively construct (and view) a "current search string".

If the user can press "c","a","t" and see "cat" somewhere, then it makes sense that the "catapult" is selected, and that typing "t" might to go "cattle".

However if you don't have that meta-state and a way to display it, then each individual keypress becomes a matter of picking a new selection based on the current selection. Hence the ruleset of "if the selected item starts with the same letter, go to the next item with the same starting letter, otherwise go to the first item that starts with the letter."

In Chen's example, the ruleset is not what you've described here. It is: if the selected item starts with the same letter, go to the next item with the same starting letter, otherwise go to the first item whose spelling matches the letters given so far."

That's why you can match llama by typing "lla"

It's selection, not a filter. Works in dropdown lists too and across multiple operating systems.

I think the up/down keys make more sense here, since they can't be mistaken for search characters.

you don't expect it to work that way, you discover it. once you discovered it, sometimes you have two files that start with e and you press e to get to the one you want, but it got you to the one before it, so you press e again to go to the next one, which is faster than reaching for the down arrow. being able to select files with finesse is important in windows.

windows 9x was probably the last time any user interface tried to be this efficient, now it's just click the arrow and it will make sure to slide the next photo in very slowly in case you forgot that you're waiting for the next photo to appear

another thing i just remembered like this is how the start menu will fade in in windows XP, and submenus. but after you open one submenu and then decide to open another beside it, it admits that the animation is just a gimmick and doesnt do it again.

It's how cmd.exe, power shell do auto complete, right? I agree, I find that useless too, but I always assumed since it appears standard in the Windows world it must be what many expect.

Reply on news.ycombinator.com