> 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.
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.
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.
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.
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.
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.
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?
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.
> 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.
> 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 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.
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.
> 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.”
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).
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.
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
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...
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.
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
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...
> 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?
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.
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."
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.
These are the little things you don't notice but make a difference.
It's a pity this kind of attention to detail is becoming obsolete in favor of flashy but unconvenient UI
I expect this behaviour on any list I find in a Windows app. I also expect keystroke consistency, like press F2 to edit... but all this UI things seems old fashioned.
I assume I don't get that on web apps, but "modern" Windows Apps are also deprecating these conveniences
I wonder if in the apple sphere they're suffering this kind of degradation.
The best example of this decline comes from Microsoft itself.
Here is how Microsoft recommends you do find-and-replace in their simple user-friendly ~20 year old note-taking app, OneNote [0]:
1. On a blank page, type the replacement text to use, or find it on a page.
2. Select the replacement text, and press Ctrl+C (⌘+C on Mac) to copy it to the clipboard.
3. Press Ctrl+F (⌘+F on Mac) to find on page, or Ctrl+E (⌘ + Option + F on Mac) search all open notebooks.
4. In the search box on the top left for Windows, top right for Mac, type the text to find.
5. In Windows, you can select Pin Search Results at the bottom of the results list, or press Alt+O to pin the list. Mac is already pinned.
6. In the Search Results pane on the side of your window, select a search result (a text link next to a page icon) to jump to the page where OneNote has highlighted the text it has found.
7. On the page, double-click or select each highlighted occurrence of the text, and press Ctrl+V (⌘ + V on Mac) to paste your replacement text over it.
Note: When you replace a word or phrase in a sentence, you might need to type a space after the new text is pasted.
8. Repeat steps 6-7 for each additional page in the search results list.
Tip: If you've got a lot of replacements on a single page, copy your text to Word, find and replace the text, and then paste back into OneNote.
OneNote seems to be especially bad. I don't think there's been a day in which I've used it and not had it complain about sync errors with my Office 365 account.
Definitely, it’s an industry-wide ailment caused by a focus on the web and neophyte users.
The irony is that this power user functionality didn’t impede new users, it’s just been gradually forgotten by folks only raised on the web, where almost everything had to be reimplemented from scratch.
Every time someone on HN praises Flutter for being the best way to do UI’s, I shudder to think of all the conveniences I’m used to (on both windows and macOS, I’ve used a lot of both) that are likely completely ignored or forgotten by these UI’s as they struggle to reinvent the user interface from scratch.
The UI’s of the 1990s were often designed using actual user studies, with years of hard-fought learning on how to do things in a way that is discoverable, Accessible, and with effective shortcuts for power users. I worry we’re losing all of this as we reinvent the UI without understanding what we’re rewriting.
It's crazy to me that so many software companies dumped millions and perhaps even billions of dollars in R&D collectively to learn how to do UI&UX effectively in the 80s, 90s, 00s, etc., and every new generation just ignores the previous one completely because it looks dated.
Gen Z, or Gen Alpha, or whatever you call teenagers these days, aren't born knowing how to use a desktop computer. They're born knowing how to use smartphone apps. From what I hear, many of them are terribly ill-equipped to be actually productive with desktop.
They're no different from just an office guy who never used a computer in the 90s or from a kid or got a PC from his parents in the 00s.
Why would the GUI have to adapt to modern users when a new user now is no wiser in practice than a new user back then?
>every new generation just ignores the previous one
One of the easiest first steps when creating your own identity as the new generation is to refuse your predecessors wholesale. This goes triple for something that is about fashion, which GUIs to some extent are a fashion statement.
For some reason, this hasn't happened yet, and the time frame that has passed since the "loss" (e.g. from ~2010 on) is comparable to the time frame the UI patterns were originally introduced (e.g. Windows 1.0 to Windows 95).
I'm afraid the prevalence of touch-screen use and the lack of focus on power users by UX designers is making the degradation permanent.
No. Every creation and discovery is influenced by culture and individuals.
Even if you assume the same level of skill and effort will be used (it won’t) there are still many paths and forks to take.
Consider that most “ui designers” come from graphic design or psychology backgrounds, while 90s UI was designed by engineers. Those groups have different values and make different decisions.
Yea, I think a lot of us old timers do notice these "little things" and it's infuriating when they are missing from the Shiny New Web Version of our desktop apps.
And, like others said, the existence of these niceties does not detract from the experience for non-power users. It's simply a bonus for more experienced users, and these bonuses are slowly going away as more and more developers choose the "give up once the thing kind of works" strategy.
I think what makes it worse is that a lot of 'UX' people seem to actively oppose these kinds of power user conveniences because they think they know better than their users.
It’s not that they think they know better, it’s that they know power users are the minority.
Everything is about minimizing expense to an extreme degree to drive “growth” in the current tech economy, so there’s little focus put into things that do not test as an immediate boost to marketability.
I wish this was the reason. It's just mediocrity and pure, raw ignorance. A result of throwing bodies into the technology industry in a desperate attempt to get the software out.
Considering how much money are poured into AI development would not say that "everything is about minimizing expense". But it is true that user interfaces are not something that will sell your application to the masses.
But to be honest, trying to sell any kind of "advanced software tools" (like compilers or other very specialized tools that provide small gains compared to existing free ones) for "power users" is extremely hard. Was involved in something similar in ~2010 and many power user think they don't need it or they can do it better themselves but anyhow does not want to pay for a complex tool.
Probably the web interfaces is exactly a manifestation of that, many users trying to implement things themselves because they know better. But I prefer writing interfaces with React than with Win32 so I think there is progress.
Which advanced UX do you implement? MacOS? Windows? Gnome or KDE behaviour? CDE?
One could sniff the user-agent and adapt to a recognized OS behaviour but we all see how superficially shallow the UX on the web is. I've given up on expecting anything advanced.
Any UI is as good as its base layer. We wouldn’t have $subj if MS didn’t implement it. But then when you tell them that the browser UI model is just useless crap with smooth animations, you get hellvoted, yelled and thrown fragile css/$()/useX incantantions at.
Which advanced UX do you implement? MacOS? Windows? Gnome or KDE behaviour? CDE?
Browser advanced UX. Not current browser UX, but a hypothetical one which doesn’t suck.
I don't know if this is that clear cut that it's worth making sweeping judgement based on it. I don't think it's a great idea to have it so pressing the same letter twice selects the 2nd item in the list with the same starting letter.
From another fellow grumpy old-timer who appreciates details, this looks more like "undiscoverable alternate mode that is invisible to the user, hacked in by a too clever engineer" than power user nicety
This is the way I remember it working originally. It wasn't until later that I discovered you could type the letters of something to jump to that. So for me, typing the first letter multiple times was just the intuitive and obvious way to do it.
It is discoverable through “g windows tips and tricks”. Reading articles like that went out of fashion too though. Thing with “power” and “advanced” is that you have to learn, because otherwise that info for all features had to be on screen and there’s only so much space on it.
This whole discoverability bs is what has driven UI into intuitive uselessness for everyone, when there’s actually two groups: first (/one) time users and just users (“power” or not). For some reason modern UX designers think everyone is in the first group. Even if an app is naturally multi-time heavy-use.
> because otherwise that info for all features had to be on screen and there’s only so much space on it.
there's practically infinite space on screen since that space has a time dimension and can also be tied to context which also varies. Like with this feature: you can show a tip on the first few searches within a list, you don't need to permanently keep the explanation on screen. Or you can show a hint with ll by having a different style of the second l or something similar
Undiscoverability is precisely one big reason why these things get axed since they're not used, so forgotten about in other contexts (web, new UI framework etc)
And yes, needing to reading random articles like this is a major fail in discoverability as you decrease reach and increase cost for the many poor users
I hate the "discoverability" trend. I don't want discoverable UI. I want UI that is consistent with all my other apps, which I have already learned. I should not have to have an app nudge me to "discover" its oh-so-cleverly-hidden features. I'm not Dora the fucking Explorer, I'm a computer user who expects everything on the platform to behave predictably and consistently.
And while we are at it, "lack of use" is not a good reason to axe features. Some things, by their nature, just don't get used as much but when they are needed they are needed. Product designers have become slaves to their telemetry and metrics, and are letting the tail wag the dog.
I wasn't talking about a trend, but real discoverability, so your rant is misplaced.
> expects everything on the platform to behave predictably and consistently.
and poor discoverability makes this expectation even less likely to be met
Similarly
> "lack of use" is not a good reason to axe features.
But it is a great reason not to implement features in the new framework since you're not even aware of them because they're undiscoverable! (I know, I know, not to you, you've already wasted time doing the discovery the hard way by reading some obscure blog, but then you go teach the devs of those new frameworks!)
Also, what is this imaginary telemetry that is able to track that I want ll to land on llama instead of blindly following invisible-mode#1? It would be awesome if product designers were that competently informed, we would've gotten universally great UIs!
Real discoverability is as real as discoverability of subj, so we’re all misplaced. That bugs me the most, much talks, crap UIs. Empty rationalizing it to death instead of cultivating feature cultures that already work and do not require “design”.
Probably more historical. My recollection is that lists originally worked that way (same letter many times) for a long time. Then a decade+ later I realized it had become smarter.
> Definitely, it’s an industry-wide ailment caused by a focus on the web and neophyte users.
The constant praise for web UI despite the issues always irritated me deeply.
It's like you're supposed to only say nice things about where we are because other people are saying that. And the more impressionable among us believe that because the Thought Leaders are saying that, then it is truth. And the circle continues.
Because most of the time you didn't have to implement this. The UI toolkit implemented this. When you have to do everything from scratch, most people don't.
Take a simple link navbar with a menu of links on a webpage. This has existed since forever. It should be that you can open the menu with your keyboard and use up/down to navigate it. But that means writing JS code. So devs who did it from scratch didn't do it, and only those who used an UI library with that already programmed in by someone else got it.
But "waaaahhhh native apps are soooo hard" they cry.
IDK man, every project from a single developer who uses Win32 widgets is infinitely better, more predictable, more usable, and more professional looking than any shitty electron app.
I agree. I'm writing a desktop app based on a web stack and I'm agonizing over tiny details in how tabbing should work and how the arrow keys should interact with lists etc. I don't know if my UI is any good, but I know that good UI takes a tremendous amount of attention to detail.
Is there a repository somewhere that documents these nuanced interactions? What annoys me when I'm developing native UI is I'm never sure my custom controls are capturing these nuanced behaviors. I shouldn't have to reverse engineer them through trial and error. There are Human Interface Guidelines provided by Microsoft, Apple, GNOME, etc. but they do not document these little behaviors.
Not that I'm aware of, but the underlying point here is you shouldn't be creating custom controls to begin with, if you can at all help it. Not only do you miss our on stuff like this that's currently handled, but you miss out on future improvements you couldn't possibly know about beforehand.
Ideally yes, but sometimes you need custom controls that are similar to existing ones. Example: Notepad++ is famously a vanilla win32 app, but uses the Scintilla code edit control rather than subclassing the native win32 edit control. Code edit controls might implement features, like multi-cursor editing, which are foundationally incompatible with the assumptions the native control made. These subtle design differences can impact core assumptions, like the implementation of undo/redo, so subclassing isn't always an option.
I'm well aware of that, but what I think you're missing is that if you need a large text editor, you'd just... use Scintilla, or one of the handful of alternatives. You wouldn't reinvent the wheel from scratch. The number of people who develop new controls from scratch exceeds the number who actually need to do so by orders of magnitude, in my anecdotal experience.
Sure, but someone wrote Scintilla and the alternatives, including the native control. Would be nice if they had some clear documentation on what they're supposed to do.
I'm well aware of that, but what I think you're missing is that if you need a large text editor, you'd just... use Emacs, or one of the handful of alternatives.
(this is not Emacs boosterism. I could have used any other text editor there)
It was much easier to subclass a control and modify its behaviour by altering the handling of certain messages for that control than creating a brand new control and trying to mimic every behaviour to every Windows message sent.
The Spy (or was it Spy++) app from the Windows SDK was very useful to figure out the best place to subclass the control, along with logging Windows messages and params sent to your subclassed control's WndProc.
That was more viable back when the Win32 common controls were being maintained, but they have basically been out of support and on bare maintenance mode for several years. There are no future improvements and they don't even support currently expected functionality like dark mode, much less basic flexible layout. All OS UI toolkit development moved over to UWP and is currently a mess with the WinUI 2 vs 3 split.
It's worse than bare maintenance, MS may have entered the stage of "clueless breaking" probably for the same reasons outlined above (newcomers don't understand what came before them).
The following is an account as an end-user. It is an old Win32 program from the 90s. Remember the theme styling controls from Desktop->Properties etc? For example you could change the white Control background to something else. Even if it never worked well enough everywhere, it was supported by native Controls. And in this application too. Recently the developer must have migrated the app to a new SDK (I guess). Not only did the clickable buttons lose all their borders, making them harder to eye-track, but all those native Controls? Lost their legacy theming support. Changing the background color no longer applies in the new version, it remains white.
And that's unlikely developer's own work. I assume the SDK adheres to newer guidelines itself.
I've seen projects trying to document a few of these UI patterns for the web, including how to build controls that are also accessible. I don't have any links on me at the moment though. It would be really nice if someone took all of these details and documented them carefully in a single Wiki-style site.
One annoyance with incremental search in file views is that if you press the wrong key, you have to wait some time to begin typing again from the beginning, unless you press Esc to clear the search history... except in file picker dialogs, it instead closes the dialog altogether!
are you familiar with the bug or maybe two different ones
where on a save as dialog you rename an unrelated file, then it defaults the save filename to that renamed file, so you change it, and hit save, then it says "this will replace x file"
similarly on that same dialog with deleting the file something similar happens.
I quit using Total Commander because it didn't work like this. This is software that works the way I think. I discovered this feature 30 years ago because I thought that was the way it should work...and it did.
Some people forget or don't realize that Microsoft was pumping out software hand over fist like this, creating UX that flowed when most software worked like Word Perfect and you needed a giant cheat sheet to get anything done.
This is pretty clever but admittedly this type of incremental search was never intuitive to me - I don't like that I can't see the current contents of the search buffer, which is always problematic if I make mistake when searching for something. Give me a textbox and fuzzy search.
Back in the day (1991 or so) during my brief time as a UI person we called the first mode "H for Hawaii" and the second "HAW for Hawaii". We never attempted the "why not both" option.
What are the exact requirements? If we have LLA, and so back in prefix mode, but then type A, are we back in repeated letter mode, where LLAA would want the second item that starts with LLA, if it existed? Are we always back in repeated letter mode if the input terminates with a repeating letter?
As an old geezer, and not necessarily a great fan of everything microsoft does/burns/kills, I witness with sadness how the standards their roman empire helped build and enforce in the 90's, are deteriorating the last 20 years, first on the web outside ms, and since win8, inside their own desktop OS as well.
I dread whenever the windows(?) team/juggernaut updates any of the built-in microsoft system tools (what you might call "options" or "settings" in what is passing for being able to speak and express yourself in these youtube-tiktok-crayon days.)
When I need to get anything done/fixed/working on windows, I first type "control panel", to get the age-old settings UI that was unbroken in win7.
From there, it is still possible (on win10 - I have avoided win11 so far)
to configure most things in a sane way.
Whenever I land on one of the newer tools, they present a mix of
- "you can't/shouldn't view/see that"
- "you should not be able to change that".
- "some settings have been hidden/are managed by your organisation"
When I hit the newer screens,
I cannot see my IP address, I cannot see my DNS providers,
I cannot change my DNS providers, I cannot enable/disable my networks.
Also, to get back on track: Search/incremental keyboard handling/sorting
on lists of stuff is horrendously "I eat crayons, and my product manager eats crayons!" bad.
Some of microsoft's own system list screens
no longer allows you to easily navigate or search your lists.
So you are presented with rubbish like
having to page through () hundreds of items, presented 3 or 5 elements at a time
(really, on a monitor with a resolution exceeding HD??)
A pet rant, truncating list text fields to arbitrary "let's just show the first 16 characters, and then ...", still on the super-HD screen.. sigh.
On some of them, no variant of incremental keyboard search works,
so with the destroyed scrollbars, you are left with manually moving through them.
() assuming the "scroll" interface even allows paging or using the cursor keys..
The modern scrollbar is the crucified victim of what modern crayon-eating humans have lost:
- the size of the scrollbar thumb used to indicate
the size of the list and the page size, so you could feel if
you were scrolling a list of 20.000 or 300 items.
- clicking beside the scrollbar thumb used to jump one page at a time,
possibly with one single item overlap, so you could "tell" that you had jumped an exact page.
- scrollbars used to have little arrows to let you jump 1 item/row at a time.
- scrollbars used to be VISIBLE, so you could orientate yourself in the document
("I see, I am near the bottom of the document/list").
- nowadays, instead, you have to play a mix of "hide the mouse"
and "gee, I wonder if you can spot WHICH rectangles in this window have extra available scrollbars, IF YOU HOVER IN THE RIGHT PLACE?"
Wouldn't it make more sense for the switch to pattern 2 prefix matching to ignore the repeated characters? So if the user typed LLA the prefix matched would be LA (ignore the first L), not LLA.
Obligatory "falsehoods programmers believe about names" comment: in Welsh, "Ll" is technically a single _letter_. It even has its own unicode point, U+1EFA, though I couldn't tell you anyone that actually uses that. Most people just type 'l' twice.
One of the most common place name prefixes is "Llan" which means "church", as in that Llanfair... place with a long name for the tourists.
If you were to load a list of community wards in Wales and type L, that would get you to Laleston (near Bridgend), and typing L again this way would make you step through a few more before the "Llans" start.
Worse still, this way there doesn't seem to be a way to type "Llanberis" (near Snowdonia/Eryri, highly recommended for hiking trips!) because it will interpret the second L as a sign to jump from Laleston to Lampeter, and then the A will put "La" not "Lla" in the box? Or does it remember that you typed "Lla" and fill this in when you press the A key?
EDIT: read it again and this is actually in the last paragraph. It _does_ remember the second L you typed.
The two codepoints U+1EFA (Ỻ) and U+1EFB (ỻ) seem to be intended for Middle Welsh, not modern Welsh. They're marked under the heading "Medievalist additions" in the code chart.
Meanwhile, for the modern Microsoft implementation: Booting up a fresh Windows 10 laptop. It wants me to select my country from the dropdown. I type in the first letter of my country. Nothing happens.
Hooray!
Was it some sort of slow scrolling without arrow keys as well? I vaguely remember a horrible process of finding my country, but I'm not sure if it was Windows Setup.
Haha, what you said reminded me of some software where you'd hit down on the bottom most entry and the next one would, agonizingly slowly, scroll up into view but if you just grabbed the scroll bar and moved it with the mouse you'd get where you wanted faster. If you tried grabbing the scrollbar after you'd hit 'down' on the bottommost entry, your inputs would be unrecognized.
I'm positive it was MS software, but I can't recall now. I only see the memory.
Visa's exchange rate calculator was similarly annoying – a long list of countries/currencies, but they reimplemented the dropdown control in such a way that typing to jump to the entry I want didn't work. Though at least that one has been fixed recently…
What! This is crazy! There can't be that many people who expect type-to-search to work that way.