[HN Gopher] How does the classic Win32 ListView handle increment...
___________________________________________________________________
How does the classic Win32 ListView handle incremental searching?
Author : AndrewDucker
Score : 58 points
Date : 2024-04-08 14:32 UTC (2 days ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| netsharc wrote:
| 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!
| mewpmewp2 wrote:
| 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.
| rkagerer wrote:
| I wish modern apps gave this level of attentive detail to my
| keyboard.
| rafaelgoncalves wrote:
| Yeah, agreed... Today we see the focus is so much on the
| looks/visuals, no so much investment on the
| usability/accessibility side.
| _zamorano_ wrote:
| 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.
| mixmastamyk wrote:
| > degradation
|
| 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.
|
| We gained a lot but lost a lot as well.
| ryandrake wrote:
| 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.
| dotnet00 wrote:
| 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.
| devmor wrote:
| 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.
| mewpmewp2 wrote:
| Also power users may be using ad block or opting out of
| tracking and therefore being left out of the success
| metrics.
|
| Everything will be optimized towards the clueless.
| vladms wrote:
| 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.
| canucker2016 wrote:
| It's also a lowest-common denominator problem.
|
| 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.
| refulgentis wrote:
| Yes, UX people do recognize it's weird to have something
| invisibly act a certain way that disobeys the plain
| inputs.
| refulgentis wrote:
| 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
| mixmastamyk wrote:
| 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.
| mixmastamyk wrote:
| [delayed]
| jstanley wrote:
| > 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.
| bradrn wrote:
| How is it crazy? This behaviour always made sense to me.
| canucker2016 wrote:
| 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.
| trynumber9 wrote:
| It's selection, not a filter. Works in dropdown lists too and
| across multiple operating systems.
| hornban wrote:
| 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.
| Macha wrote:
| Only if it's a shared beginning.
|
| It's a little less useful when you're searching for Ireland,
| Republic of Ireland, or occasionally Eire.
| hnthrowaway0328 wrote:
| 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.
| salgernon wrote:
| 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.
| mewpmewp2 wrote:
| Yeah, Canada seems easy to me. United States of America, I
| could relate to due to so many different ways of writing
| it.
| salgernon wrote:
| 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...
| canucker2016 wrote:
| 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.
| pradn wrote:
| > 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?
| esafak wrote:
| I think the up/down keys make more sense here, since they can't
| be mistaken for search characters.
| hgs3 wrote:
| 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.
| dataflow wrote:
| 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.
| hgs3 wrote:
| 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.
| dataflow wrote:
| 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.
| toast0 wrote:
| 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.
| nyanpasu64 wrote:
| 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!
___________________________________________________________________
(page generated 2024-04-10 23:00 UTC)