> Sadly, almost nobody uses Win32 scroll bars any more. Everybody uses frameworks that provide their own custom scroll bars.
Yeah and, sadly, those framework implementations are all mired in some amount of bollocks due to lack of care, attention, or interest from their creators. And by bollocks I mean they either behave differently or do less.
But I very much miss the days of consistent UX across Windows applications, or indeed applications on any other OS.
I don’t mind if you want a custom look and feel for your application: I very much do mind if your widgets don’t behave like other widgets of the same type or, at least, where any variance is at least a superset of OS level functionality rather than a crippled subset.
I was always frustrated by how hard Microsoft made this as time wore on and they moved through more and more UI frameworks, and then offerings like CEF and Electron entered the mix as well. The UI story on Windows started getting particularly messy around 2007 or so and has been in an awful state of confusion for at least 15 years now.
I literally have no idea what I’d use to develop a Windows desktop app nowadays and, honestly, none of the options fill me with enthusiasm. With more recent desktop experiments, partly because whilst I might want them to run on Windows I don’t primarily work on Windows, I’ve gone the Rust + Qt route simply because it offers native performance and it doesn’t feel like I’m getting rug pulled by either set of creators any time soon.
> I don’t mind if you want a custom look and feel for your application
I would go further and say that I don’t want a custom look and feel for each app unless the app is a game, especially if your app is a regular line of business app. The default Win32 widgets are good enough. The default Cocoa widgets are also good enough.
> I don’t want a custom look and feel for each app
I'd agree personally, but when you look at the huge success of things like WinAmp's themes back in the day, there clearly is (was?) a large market for it.
People talk about functionality and features (well, tech people do), but for a large part of the population, the eye demands its share. Your application doesn't look good? Sorry, skipped it already. First use doesn't feel intuitive? Delete. Another app does the same, perhaps even worse, but has funkier colors? Switch.
If a framework cannot provide you with the right looks, you have to to override it. Hence the mess.
I want apps to use the default widgets because I want theming and color selection in the OS to work again. That's about the extent I care about look and feel. Microsoft has ruined that on current Windows versions anyway-- making me resort to registry modifications to get the colors I want. Every time I see an application with a "dark mode", which should be an OS-wide theme function, I get a little sad at the wasted developer time.
Beyond the now-denied choice of UI color scheme I do not expect (or even desire) deriving any joy or pleasure from the look and feel of software I use. Most of my computing is for "work"-- be that my job, or paying bills, shopping, etc. I want the UI to get out of my way and, most of all, not to insult my 30+ years of muscle memory and visual intuition. I derive joy and pleasure from software that allows me to quickly accomplish my tasks with minimal thought or friction on my part.
I experience massive frustration with software using UI widgets that don't work like the native OS. Not having the standard keyboard shortcuts, for example, is a great way to make me hate your software. It's an immediate "tell" that I'm going to be disappointed if a program has bad tab order on its UI elements, for example.
Moreover, eschewing the time-tested and battle-hardened native UI widgets speaks to arrogance. It feels like an ego trip and it's almost certainly unearned. Random developers probably can't pull off a widget replacement that replicates all the nuance of the native. Good luck pulling off accessibility and internationalization, too. Even if they can how is reinventing that wheel a good use of their time?
My rage is amplified when I find bugs in software with non-native widgets. They had time to dick around with the widgets-- something already done for them in a vastly more competent and comprehensive manner for free-- but not to ship bug-free code for the software's actual purpose?
The same goes for animations, fades, gradients, etc. The vast majority of software I use is not special or dear to me. It's a tool. I don't want to, in a manner of speaking, look at pictures of the developers kids or vacations as a "toll" for using the software. Making software "pretty" is only self-serving and egotistical.
Yeah, I think that’s probably fair. Games and media apps certainly get a pass from me. Not so much corporate chat apps that are shipped as part of the most popular productivity suite in history (as one example).
Also agree with you on both Win32 and Cocoa widgets.
Also, Win32 and Cocoa widgets feel so reactive and fast. Electron is bloated and so laggy.
Speaking of performance of media apps, I stopped using the official Spotify client after I found out about Spotifast [1]. Yes, it's vibecoded, but it feels so fast and light compared to the real client that I wonder why Spotify itself doesn't fix their official app.
...and even if the app is a game, it can still make great use of Win32 controls creatively. Minesweeper is one example that comes with Windows, and I remember plenty of other casual (non-3d) games in the 90s/early 2000s making use of buttons, both ownerdrawn and stock, likely to avoid having to write their own hit-testing code.
I don't think the original Minesweeper used actual buttons for its playing field. That'd be a lot of controls that can be better handled by one custom drawn control. They also did look different from actual Win32 buttons which likely is another clue.
The designers of your software and their bosses disagree though, default widgets don't provide "branding" and allow the poor designers to express themselves.
Good designers would not disagree. Platform standards are golden standards, any UX designer worth their salt holds that as an absolute.
The problem starts when you want to ship to every device known to man but you only have the dev power to maybe ship it to the web—enter, Electron (and all that other similar crap).
Don’t blame it on the designers or the developers. This comes from above the worker bees.
Electron just makes it easy, but it's long been the status quo. GP was right to mention branding. That's the driver.
There's a document I've seen floating on the Interwebz, a copy of HIG for ancient Windows version, I think one of the 3.x ones. I distinctly remember it for having a note somewhere basically recognizing that giving some of the theming/customization options in the API is a bad idea, but customers want to brand their apps, so what can one do.
This is one of the problems that I can't see being solved, because it's purely social - we'd have to have someone go and tell every entrepreneur out there that branding is a fucking stupid idea and you should not do it, and actually be taken seriously.
I can't even imagine a world in which that is possible.
Separately from the "who thinks it's actually a good UX" question, I think we should also consider the strategic-villainy of established companies which try to slowly shift their captive customer-base into something weird that creates a barrier to leaving.
Yeah, you lose some people with a shifting target, but it's easier to make them swallow 1% different every month than 50% different (to a competitor) all at once.
You're right, it is. I did a lot of C#/WinForms development back in the day. I never liked it but I liked the people I worked with and the company I worked for so I tolerated it.
Reasons? OK, this is going back about 20 years but, and without going on a massive ranty screed [EDIT: oops, failed], compare something like Swing's JTable to WinForms' DataGrid. One is a really nicely designed and abstracted component with a fully pluggable architecture and an out of the box capability to deal with an arbitrarily large data model (perhaps within the limits of 32-bit integers) and the other... isn't. I tried with DataGrid, I really did. I thought other developers at my employer were "doing it wrong" by reaching for third party controls from the likes of DevExpress and Actipro but... they weren't: I was wrong. If you wanted a proper table/grid control that was easy to customise and extend and wouldn't chunder on millions and millions of rows of data you forked over the money to DevExpress for their control and then you got on with your day solving your real problems that you could charge customers actual money for.
We leaned hard on third party control libraries from DevExpress (particularly grid and tree), Actipro (wizard), and Syncfusion (again, grid). To me, with WinForms, and bearing in mind I'd come from Java Swing (which is by no means perfect) it was really weird working with a UI toolkit where what came in the box wasn't sufficient to build any arbitrarily complex UI I might desire. Weird. And frustrating. Same for the lack of abstraction/separation of concerns. In my Java days, when I wanted a wizard I ripped the one out of NetBeans: I did that in at least two prior jobs using it as the basis for multiple wizards across the relevant applications.
And WPF... although architecturally a lot better, IIRC it didn't even have a proper table/grid control: you had to build your own, and when you start thinking about how rich a proper table/grid is, taking into account accessibility, keyboard shortcuts, picking up OS level settings (palette, scaling, etc.), making it behave like a table in any other application on Windows, I just couldn't be bothered building all that... so then it's back to third parties again.
I don't know what third party support for these frameworks is like nowadays but, fundamentally, for the sort of independent experiments I'm working on I don't want to either (i) fork over hundreds or thousands of dollars to third parties for (I think) basic functionality that (I think) should be available as part of the framework and should have been there since day one, or (ii) spend time wrangling the framework to implement this basic functionality because it isn't a core part of the problem I'm trying to solve or the value I'm trying to deliver.
I'd rather just use Qt or something, which at least has what I need.
"compare something like Swing's JTable to WinForms' DataGrid"
Do you actually mean the DataGrid? Because the WinForms "DataGrid" was deprecated in 2002 with .NET 2.0 which added the DataGridView. The software I work on is Windows Forms and I can't say I've had any issues like you describe with the DataGridView. I was able to create a control derived from it that does all the heavy lifting for customizations(Visual, interaction, cell spanning, etc.), of which we had a lot. Enough that we were exploring third party controls, but found we would have to customize those ourselves anyway, so I just wrote my own control based on DataGridView to save us the licensing.
WPF had it's own DataGrid control from the start, though I can't comment from experience on it's versatility, I'd assume given WPF's nested-content approach it is surely at least more flexible than the DataGridView.
> I don’t mind if you want a custom look and feel for your application
This is why I like Delphi / C++Builder's theming. It's standard UI controls -- so you get stuff like the scrollbar menu Raymond mentions -- but you can make it look custom if you want. Same behaviour, different rendering.
This is why I love GNOME. The community is doing a great job with creating GTK4 native applications. I'll often pick a GTK app over a more featured app, because they usually do enough. It's very satisfying to be able to use the same shortcuts in most applications.
> I don’t mind if you want a custom look and feel for your application: I very much do mind if your widgets don’t behave like other widgets of the same type ...
Interesting that you picked 2007 as the start of Windows' decline in this regard when WPF (from the same year) makes it so much easier to change the look without changing the behavior. I my eyes that toolkit does a lot of things right with controls that only define their behavior and not their visuals, which can easily be completely replaced (well, easier than writing a new Scrollbars from scratch).
Anecdote: I do it not because I want a custom feel, but because I want my programs to work on Windows, Linux, and Mac without any special per-OS work. Granted, perhaps the framework I've been using could use native APIs smartly instead of its own...
FWIW I think your Rust + Qt route is fantastic. I've been using Rust + EGUI myself, but have Qt in mind for future projects.
> I literally have no idea what I'd use to develop a Windows desktop app nowadays
This is the "man with two clocks" problem. Win32 is still there, it still works and it still produces scroll bars that work like they did before, but now you have so many other options you're permanently indecisive.
IMO, "scroll here" should be the default action for clicking on a scrollbar. There are already good keyboard shortcuts for page up and page down, but there cannot be a keyboard shortcut for "scroll here". It's wasting the capability of the mouse to duplicate keyboard functionality when you could be benefiting from unique mouse-only functionality.
Oh hell no. If you think "scroll here" is a sane default, you haven't experienced the pain of jumping possibly thousands of lines in a long document with an accidental click, and no easy way to go back to where you were.
I don't think that's a serious problem. There are three possibilities I can think of:
1. You're editing text outside of Emacs. Your cursor remains where it was, so you insert a single character and the document scrolls back to the cursor. You can then delete that character.
2. You're editing text in Emacs. You like to pretend it's still the 1970s and off-screen cursors are some pie-in-the-sky fantasy. You solve the problem with some unspecified ELISP wizardry, which as a self-respecting Emacs user you are surely capable of.
3. You're reading a read-only document. You activate your full-text search, which every good document viewer has, and start typing the last sentence you read while it's still fresh in your memory.
Mouse and keyboard should be alternatives on equal footing as much as possible. The gutter for page up/down has the benefit that you don’t have to move the mouse all the way up and down to the arrow buttons when repeatedly switching between the same adjacent pages, or when you positioned the scroll button slightly off where you wanted the position to be, and adjust it a little by paging up or down — especially when the scroll range is so long that a small mouse move on the scroll bar corresponds to more than one page.
For scroll ranges that aren’t overly long, you can long-press so that the area ends up scrolling to that position. Only for long scroll ranges is it necessary to drag, use the context menu, or the Shift key, for absolute positioning.
There are certainly trade-offs, but it’s not like there aren’t justified reasons for the way it is.
The ubiquity of mouse wheels and two-finger scrolling on trackpads drastically weakens your case for prioritizing the page up and page down behaviors in the scroll gutter. The mouse already offers a low-effort way to adjust scroll position at small to medium scales, generally much easier that repositioning the cursor from above to below the scroll thumb unless you really need to scroll by precisely one page (usually not possible on the web anymore because of floating dickbars).
With regards to Qt, does that mean Qt apps on Windows or something? I use KDE so there are a lot of Qt apps and they are all click-to-scroll in the scrollbar. Of course it's KDE so it's configurable so you can change it to click-for-page-up/down and middle click to scroll, but left-click to scroll is the default.
Very worrying trend is thin scrollbars on websites, or in some rare cases - scrollbar just hidden. Fortunately Firefox has a setting in about:config: layout.css.scrollbar-width-thin.disabled=true .
That is so sad!!
The larger our screens gets the smaller the scrollbars get, making it at least twice as difficult to use.
Where do you remove the option for me to see how long your (now often AI generated) blog post is just by glancing at the scroll bar, why do you remove it.
That’s really crappy UX…
Also - apps (mainly Office 365) no longer use a framework that allows the OS supported use of Accent Color (the thing that allows the active windows toolbar to get a Color that quickly and effectively signals ‘I’m the active one now).
No no - I am Office I am so important that I need to always be green (Excel) or blue (Word) etc. No need for you to know if I am the active window or not - you’ll find out when starting to type and the ‘wrong’ windows receives your input!
It seems that there is a design pattern where product owners favor apps to look nice in board room presentations over making them effective to use for professional users (as well as average Joe).
Don’t get me started on the often lack of keyboard shortcuts - just use the mouse (no thanx - way too much clicking, only use mouse where it makes sense, please)…
widget.gtk.overlay-scrollbars.enabled: false - always show normal scrollbar, don't just expand on hover
widget.non-native-theme.scrollbar.style: (it seems that values 1-5 are allowed)
widget.non-native-theme.scrollbar.size.override: width
I'm not surprised scrollbars are hidden. They're hidden by default on macOS and when you find out that every other OS turns your design into a scrollbar mess, disabling all of them is the quickest fix.
A "scrollbar mess"!? That type of designer is exactly the cause of the problem.
Usability breaks the look of my design, so I'll break usability! Obviously it's more important that everyone sees my amazing graphic design skills, than that they can actually use it!
Usability is one thing, but with Apple hiding scrollbars by default, loads of macOS-designed websites spawn scrollbars all over the place on other platforms because of 1px overflows.
It’s about time that Raymond Chen starts ranting about the increasing amount of UI inconsistencies and loss of formerly ubiquitous features. (Or maybe I missed previous installments.)
Ah yes, Microsoft’s “we care…………to talk about problems we’ll never fix” poster boy. Dude might be a fantastic developer, but he’s being used as a sock puppet.
In Linux/GTK, clicking in the gutter navigates to that position, and I have just discovered that Shift+clicking is equivalent to PageUp/PageDown, and that right-clicking seems to also be equivalent to PageUp/PageDown in Firefox, but scrolls at a fixed slow pace while the button is held in LibreOffice (15s per screenful at 6fps in Writer) and Inkscape (3s per screenful, smooth), and that middle-clicking is mostly PageUp/PageDown, but noop in Firefox; and I think those are the only apps I use (maybe even have installed) with regular scroll bars.
Oh yeah, one more, BibleTime which is Qt: it’s fairly Windowsy, click is PageUp/PageDown, right click is context menu (Scroll here, ---, Top, Bottom, ---, Page up, Page down, ---, Scroll up, Scroll down), Shift+click is same as click, middle-click is scroll here.
(These sorts of things are also one reason why you shouldn’t implement your own scroll bars in web pages: different platforms behave differently, and you can’t match it all sanely or sometimes at all.)
> different platforms behave differently, and you can’t match it all
Why do I care about matching it all? Do we need a scrollbar with all kinds of bespoke per-platform functionality? If I have a scrollbar, that people can use to scroll on all platforms, and it fits the visual aesthetic of my application instead of looking like an absolute dogshit eyesore, is that not good enough? What percentage of the population would you reckon is shift+clicking their scrollbars on a routine enough basis to notice a web-app that doesn't meet their expectations? 1%? 0.1%? 0.0001%? And in this fail case, when they shift+click the scrollbar and it doesn't behave as they expected, how much harm is really being caused? Will it ruin their day or will they maybe just go 'tch' and then use the scrollbar normally to achieve their scrolling needs like everyone else?
Apparently I have angered the scrollbar shift+clicking hordes. There might be dozens of you!
They'll just assume your site/app is broken, because their reference for what's correct is their platform. If they're annoyed enough, they go to a competitor unless it's a site/app mandated by their employer.
There is a literal 0% chance a single person in the entire history of our species has made the decision to switch to different software because shift-clicking the scrollbar didn't do what they expected it to. On the other hand, plenty of people are drawn to applications that look visually cohesive and are not an eyesore; not only because humans appreciate aesthetics, but also because visuals are an information channel and thus having non-obstrusive graphic design that guides your eyes to what matters has a very practical benefit.
I go out of my way to avoid using applications that ignore the macOS system preference for what clicking in the scrollbar does. People who care about the "feel" half of "look and feel" genuinely do exist. Janky scrolling behavior drastically lowers my opinion of an app, and in a web page it prompts immediate closure of the tab.
I didn't say a word about neglecting feel. Your argument appears to be that only Apple's anointed preference can count as "feel", and that anything that doesn't adhere to God-Emperor Jobs' vision is inherently janky. To which I say, username relevant.
"Feel" in the phrase "look and feel" refers to the behavior when interacting with the UI, as opposed to the aesthetic look. You asserted that literally nobody cares about a particular behavior that is the Windows equivalent to what has been a prominently-exposed configurable system preference in every version of Mac OS X/macOS.
Your weird hatred/obsession with Apple is preventing you from understanding that my argument wasn't even in favor of Apple's default behavior, but about software that doesn't respect the preference chosen by the end user who changes that setting away from the default.
I see. I was not aware of this system preference. Perhaps I would be if Apple didn't intentionally wall people out of developing for it unless they participated fully in the ecosystem by purchasing OS-locked hardware that they intentionally deter emulation of while requiring paying them for the privilege to develop for them. I won't ever see eye-to-eye with users who voluntarily opt into that environment, so if the scrollbar behaving slightly differently than expected but still reasonably well is truly a dealbreaker for somebody who stumbled onto my webapps, oh well!
Because it is impossible to change its color. It was/is not uncommon to see custom/dark skinned Windows apps with ugly gray scrollbars looking at you. Even today, only Light and Dark themes are supported, impossible to set a custom color.
"... Custom Draw, the feature found with many of the common controls shipped with Windows. Custom Draw allows an application to completely take over the drawing of a window’s scrollbars, and replace the scrollbar graphics with a completely user defined look."
Interesting that not even Raymond Chen knew about Shift+Click - i found it at some point years ago by trying random stuff on the Win32 controls and it was what i used to try whenever i wanted to tell if a program was using real Win32 controls or made its own since pretty much no toolkit had this behavior including Qt[0] :-P
[0] i think Qt might have added it at some point but it has been several years since i used Windows as a main OS and bothered to check it
Someone ought to catalog hidden behaviors like this in standard UI controls, so that people reimplementing these controls can have a reference. Obviously we can't rely on people reusing the same implementations to achieve consistency, but if there was documentation we'd at least have something to point to.
> Holding Shift while clicking on the scroll bar jumps the thumb directly to the spot where you clicked.
In properly designed bars this is either a default or a configurable option. Moving your mouse to a far away bar and holding shift are more expensive actions than pressing PgDn (or a shortcut), so the action can't be just a page, it has to be something more valuable, harder to replicate
(the even smaller arrows at the top/bottom are even worse)
Completely agree. Besides, if clicking above/below the thumb is PgUp/PgDn, that means the buttons get smaller as you get closer to your destination, making them harder to press. Not good UX! The main counter argument to instantly moving I can think of, is that people may miss-click when trying to resize a window, and struggle to find their way back. Maybe a Ctrl-Z for window location history wouldn't be such a bad idea. You could piggyback off Vim's jump list which is navigable with Ctrl-O and Ctrl-I, though I'm sure a lot of applications already register those mappings.
> counter ... people may miss-click when trying to resize a window
That's a counter against another common sin of UI design that's stuck in the past, another superficially appealing idea that requires users hunting for tiny lines for common operations. That one should be fixed instead of making the scroll bar worse. (they even have that whole dedicated "windows" button that doesn't properly manage... windows)
Besides, lack of proper universal undo (that can undo selection/position changes, including windows) is yet another desktop UI design failure. Similarly to what you've noted, the solution to which is yet again fixing that instead of breaking useful functionality in other elements.
So maybe it should be Win+Z to undo window resizing/moving?
My windows button properly handles windows. Window + left arrow snaps left. Windows + down snaps it down. Etc… It’s literally the best default window manager any OS has.
Nothing proper about that. Your right hand is on your mouse, which you use to move the window border. What's your Winkey answer to that? The actions you named don't resize in the way you want to and require moving your hand off the mouse to the cursor keys... and then back.
You're correct! I wrongly assumed that people were using their computers with:
A) Both hands on the keyboard, making it easy to reach both the Win key and the arrow keys at the same time to snap your windows.
or
B) One hand on the keyboard and one hand on the mouse, making window snapping instant with the mouse.
But I forgot that this is HN, so a significant proportion of readers also use their computers with both hands on the mouse, or no hands and one foot each for the keyboard and for the mouse.
You wrongly assumed that your perception of what's "faster" is correct just because it's setup that way by the OS.
> A) Both hands on the keyboard, making it easy to reach both the Win key and the arrow keys at the same time to snap your windows.
It might be "easy" to reach arrow keys, but it's even easier and faster not having to do that
> B) making window snapping instant with the mouse
Your left window slightly overlaps the right one. You want to resize it by reducing its width by ~5% and its height by ~9% to avoid that
Name your "instant" list of mouse actions to achieve that.
Leave a visual "shadow" of the scroll knob at the old position every time somebody clicks the bar to jump. Then the user can quickly snap back to where they where.
Then they can also jump back and forth effortlessly between two places in a document.
Never seen it anywhere, but I think it would be very intuitive and practical.
The only somewhat similar function I've seen is on Kindle when you jump between footnotes or chapters, and they provide a very convenient interface for jumping back, but buttons instead of scroll bars.
Sadly, almost nobody uses Win32 scroll bars any more. Everybody uses frameworks that provide their own custom scroll bars.
The frameworks that actually wrap a Win32 scrollbar are the ones doing it right; the ones that (badly) reinvent a scrollbar are the ones to avoid. The real problem in this case isn't frameworks, but how they make use of the platform capabilities.
In older versions of Windows if you dragged the scroll thumb then moved the mouse far away from the scrollbar it would cancel the scroll, resetting the scrollbar to its original state.
In the current version it is inconsistent. Notepad no longer supports this but browsers do.
You're joking, they've even managed to break a behaviour as basic as that!? I had no idea. There are so many reasons I'm not interested in using Windows 11, but it seems there's continually yet another issue I hadn't heard of before.
My first thought was "that's new to me, TIL", but when I tried right-clicking a scrollbar in Explorer, I immediately recognised the menu and thought "yeah, that's always been there". Now I'm just confused.
Interesting that shift+click to “scroll here” only came with Windows 7. Could have sworn it had always been there, I use it all the time. Infuriatingly, of all apps Microsoft Office doesn’t implement this! It would be so useful there and it’s Microsoft, but nope, you can’t expect Office to respect Windows conventions. Also, Excel’s scrollbar is deranged in general.
I built a site where the wheel doesn't scroll, it just steps to the next item. Ended up rebuilding half of this list badly (slider, prev/next buttons, Home/End). Didn't know about shift+click until today.
If you mean dragging, then that’s more than just a single click. And if you mean clicking in the gutter, then it
also doesn’t work with a single click; you have to make use of the auto-repeat functionality, which takes O(n) time, where n is the distance between positions in number of pages. Shift+Click does it instantly in O(1).
Not the case in Notepad, Edge, RegEdit, Windows Settings, MS Teams, Firefox on Windows, Bruno, Windows Search. Where exactly did you experience this? All aforementioned were tested in Windows 11
> Sadly, almost nobody uses Win32 scroll bars any more. Everybody uses frameworks that provide their own custom scroll bars.
Yeah and, sadly, those framework implementations are all mired in some amount of bollocks due to lack of care, attention, or interest from their creators. And by bollocks I mean they either behave differently or do less.
But I very much miss the days of consistent UX across Windows applications, or indeed applications on any other OS.
I don’t mind if you want a custom look and feel for your application: I very much do mind if your widgets don’t behave like other widgets of the same type or, at least, where any variance is at least a superset of OS level functionality rather than a crippled subset.
I was always frustrated by how hard Microsoft made this as time wore on and they moved through more and more UI frameworks, and then offerings like CEF and Electron entered the mix as well. The UI story on Windows started getting particularly messy around 2007 or so and has been in an awful state of confusion for at least 15 years now.
I literally have no idea what I’d use to develop a Windows desktop app nowadays and, honestly, none of the options fill me with enthusiasm. With more recent desktop experiments, partly because whilst I might want them to run on Windows I don’t primarily work on Windows, I’ve gone the Rust + Qt route simply because it offers native performance and it doesn’t feel like I’m getting rug pulled by either set of creators any time soon.
> I don’t mind if you want a custom look and feel for your application
I would go further and say that I don’t want a custom look and feel for each app unless the app is a game, especially if your app is a regular line of business app. The default Win32 widgets are good enough. The default Cocoa widgets are also good enough.
Would you really want to use a chat app with just win32 elements?
> I don’t want a custom look and feel for each app
I'd agree personally, but when you look at the huge success of things like WinAmp's themes back in the day, there clearly is (was?) a large market for it.
People talk about functionality and features (well, tech people do), but for a large part of the population, the eye demands its share. Your application doesn't look good? Sorry, skipped it already. First use doesn't feel intuitive? Delete. Another app does the same, perhaps even worse, but has funkier colors? Switch.
If a framework cannot provide you with the right looks, you have to to override it. Hence the mess.
I want apps to use the default widgets because I want theming and color selection in the OS to work again. That's about the extent I care about look and feel. Microsoft has ruined that on current Windows versions anyway-- making me resort to registry modifications to get the colors I want. Every time I see an application with a "dark mode", which should be an OS-wide theme function, I get a little sad at the wasted developer time.
Beyond the now-denied choice of UI color scheme I do not expect (or even desire) deriving any joy or pleasure from the look and feel of software I use. Most of my computing is for "work"-- be that my job, or paying bills, shopping, etc. I want the UI to get out of my way and, most of all, not to insult my 30+ years of muscle memory and visual intuition. I derive joy and pleasure from software that allows me to quickly accomplish my tasks with minimal thought or friction on my part.
I experience massive frustration with software using UI widgets that don't work like the native OS. Not having the standard keyboard shortcuts, for example, is a great way to make me hate your software. It's an immediate "tell" that I'm going to be disappointed if a program has bad tab order on its UI elements, for example.
Moreover, eschewing the time-tested and battle-hardened native UI widgets speaks to arrogance. It feels like an ego trip and it's almost certainly unearned. Random developers probably can't pull off a widget replacement that replicates all the nuance of the native. Good luck pulling off accessibility and internationalization, too. Even if they can how is reinventing that wheel a good use of their time?
My rage is amplified when I find bugs in software with non-native widgets. They had time to dick around with the widgets-- something already done for them in a vastly more competent and comprehensive manner for free-- but not to ship bug-free code for the software's actual purpose?
The same goes for animations, fades, gradients, etc. The vast majority of software I use is not special or dear to me. It's a tool. I don't want to, in a manner of speaking, look at pictures of the developers kids or vacations as a "toll" for using the software. Making software "pretty" is only self-serving and egotistical.
Yeah, I think that’s probably fair. Games and media apps certainly get a pass from me. Not so much corporate chat apps that are shipped as part of the most popular productivity suite in history (as one example).
Also agree with you on both Win32 and Cocoa widgets.
Also, Win32 and Cocoa widgets feel so reactive and fast. Electron is bloated and so laggy.
Speaking of performance of media apps, I stopped using the official Spotify client after I found out about Spotifast [1]. Yes, it's vibecoded, but it feels so fast and light compared to the real client that I wonder why Spotify itself doesn't fix their official app.
[1] https://spotifast.rocks/
unless the app is a game
...and even if the app is a game, it can still make great use of Win32 controls creatively. Minesweeper is one example that comes with Windows, and I remember plenty of other casual (non-3d) games in the 90s/early 2000s making use of buttons, both ownerdrawn and stock, likely to avoid having to write their own hit-testing code.
I don't think the original Minesweeper used actual buttons for its playing field. That'd be a lot of controls that can be better handled by one custom drawn control. They also did look different from actual Win32 buttons which likely is another clue.
Upon closer inspection, you're right about the playing field; but the preference and high score dialogs are made of entirely standard Win32 controls.
The designers of your software and their bosses disagree though, default widgets don't provide "branding" and allow the poor designers to express themselves.
Good designers would not disagree. Platform standards are golden standards, any UX designer worth their salt holds that as an absolute.
The problem starts when you want to ship to every device known to man but you only have the dev power to maybe ship it to the web—enter, Electron (and all that other similar crap).
Don’t blame it on the designers or the developers. This comes from above the worker bees.
Electron just makes it easy, but it's long been the status quo. GP was right to mention branding. That's the driver.
There's a document I've seen floating on the Interwebz, a copy of HIG for ancient Windows version, I think one of the 3.x ones. I distinctly remember it for having a note somewhere basically recognizing that giving some of the theming/customization options in the API is a bad idea, but customers want to brand their apps, so what can one do.
This is one of the problems that I can't see being solved, because it's purely social - we'd have to have someone go and tell every entrepreneur out there that branding is a fucking stupid idea and you should not do it, and actually be taken seriously.
I can't even imagine a world in which that is possible.
Separately from the "who thinks it's actually a good UX" question, I think we should also consider the strategic-villainy of established companies which try to slowly shift their captive customer-base into something weird that creates a barrier to leaving.
Yeah, you lose some people with a shifting target, but it's easier to make them swallow 1% different every month than 50% different (to a competitor) all at once.
> I literally have no idea what I’d use to develop a Windows desktop app nowadays
C#/.NET and WinForms is still a viable choice. Though for a new project I might try WPF, for a slightly more modern appearance.
WinForms is still a bit of a mess if you want high dpi support.
You're right, it is. I did a lot of C#/WinForms development back in the day. I never liked it but I liked the people I worked with and the company I worked for so I tolerated it.
Reasons? OK, this is going back about 20 years but, and without going on a massive ranty screed [EDIT: oops, failed], compare something like Swing's JTable to WinForms' DataGrid. One is a really nicely designed and abstracted component with a fully pluggable architecture and an out of the box capability to deal with an arbitrarily large data model (perhaps within the limits of 32-bit integers) and the other... isn't. I tried with DataGrid, I really did. I thought other developers at my employer were "doing it wrong" by reaching for third party controls from the likes of DevExpress and Actipro but... they weren't: I was wrong. If you wanted a proper table/grid control that was easy to customise and extend and wouldn't chunder on millions and millions of rows of data you forked over the money to DevExpress for their control and then you got on with your day solving your real problems that you could charge customers actual money for.
We leaned hard on third party control libraries from DevExpress (particularly grid and tree), Actipro (wizard), and Syncfusion (again, grid). To me, with WinForms, and bearing in mind I'd come from Java Swing (which is by no means perfect) it was really weird working with a UI toolkit where what came in the box wasn't sufficient to build any arbitrarily complex UI I might desire. Weird. And frustrating. Same for the lack of abstraction/separation of concerns. In my Java days, when I wanted a wizard I ripped the one out of NetBeans: I did that in at least two prior jobs using it as the basis for multiple wizards across the relevant applications.
And WPF... although architecturally a lot better, IIRC it didn't even have a proper table/grid control: you had to build your own, and when you start thinking about how rich a proper table/grid is, taking into account accessibility, keyboard shortcuts, picking up OS level settings (palette, scaling, etc.), making it behave like a table in any other application on Windows, I just couldn't be bothered building all that... so then it's back to third parties again.
I don't know what third party support for these frameworks is like nowadays but, fundamentally, for the sort of independent experiments I'm working on I don't want to either (i) fork over hundreds or thousands of dollars to third parties for (I think) basic functionality that (I think) should be available as part of the framework and should have been there since day one, or (ii) spend time wrangling the framework to implement this basic functionality because it isn't a core part of the problem I'm trying to solve or the value I'm trying to deliver.
I'd rather just use Qt or something, which at least has what I need.
"compare something like Swing's JTable to WinForms' DataGrid"
Do you actually mean the DataGrid? Because the WinForms "DataGrid" was deprecated in 2002 with .NET 2.0 which added the DataGridView. The software I work on is Windows Forms and I can't say I've had any issues like you describe with the DataGridView. I was able to create a control derived from it that does all the heavy lifting for customizations(Visual, interaction, cell spanning, etc.), of which we had a lot. Enough that we were exploring third party controls, but found we would have to customize those ourselves anyway, so I just wrote my own control based on DataGridView to save us the licensing.
WPF had it's own DataGrid control from the start, though I can't comment from experience on it's versatility, I'd assume given WPF's nested-content approach it is surely at least more flexible than the DataGridView.
WPF has a datagrid control now, IIRC it was added in the second or third major version.
> I don’t mind if you want a custom look and feel for your application
This is why I like Delphi / C++Builder's theming. It's standard UI controls -- so you get stuff like the scrollbar menu Raymond mentions -- but you can make it look custom if you want. Same behaviour, different rendering.
In the early days of Delphi you could recognise those apps because the OK and Cancel buttons had a tick or cross in them.
>I very much miss the days of consistent UX
This is why I love GNOME. The community is doing a great job with creating GTK4 native applications. I'll often pick a GTK app over a more featured app, because they usually do enough. It's very satisfying to be able to use the same shortcuts in most applications.
I literally have no idea what I’d use to develop a Windows desktop app nowadays
Pure Win32 still works, and is the most efficient and consistent.
It works, but gives you zero help with dark mode or HiDPI (both are possible, it's just entirely on the developer)
> I don’t mind if you want a custom look and feel for your application: I very much do mind if your widgets don’t behave like other widgets of the same type ...
Interesting that you picked 2007 as the start of Windows' decline in this regard when WPF (from the same year) makes it so much easier to change the look without changing the behavior. I my eyes that toolkit does a lot of things right with controls that only define their behavior and not their visuals, which can easily be completely replaced (well, easier than writing a new Scrollbars from scratch).
Anecdote: I do it not because I want a custom feel, but because I want my programs to work on Windows, Linux, and Mac without any special per-OS work. Granted, perhaps the framework I've been using could use native APIs smartly instead of its own...
FWIW I think your Rust + Qt route is fantastic. I've been using Rust + EGUI myself, but have Qt in mind for future projects.
I want my web apps to work in the web, Geminispace, FTP and dead-tree paper, too, but you have to pick a platform.
> I literally have no idea what I'd use to develop a Windows desktop app nowadays
This is the "man with two clocks" problem. Win32 is still there, it still works and it still produces scroll bars that work like they did before, but now you have so many other options you're permanently indecisive.
Qt doesn't offer anywhere near native performance. You need something like wxWidgets for that, which makes native system calls.
Also, that single phrase you quoted shows how much Raymond despises modern Windows. He can't say that blatantly, of course, but we all know.
IMO, "scroll here" should be the default action for clicking on a scrollbar. There are already good keyboard shortcuts for page up and page down, but there cannot be a keyboard shortcut for "scroll here". It's wasting the capability of the mouse to duplicate keyboard functionality when you could be benefiting from unique mouse-only functionality.
GTK gets this right, and Qt does not.
Oh hell no. If you think "scroll here" is a sane default, you haven't experienced the pain of jumping possibly thousands of lines in a long document with an accidental click, and no easy way to go back to where you were.
I don't think that's a serious problem. There are three possibilities I can think of:
1. You're editing text outside of Emacs. Your cursor remains where it was, so you insert a single character and the document scrolls back to the cursor. You can then delete that character.
2. You're editing text in Emacs. You like to pretend it's still the 1970s and off-screen cursors are some pie-in-the-sky fantasy. You solve the problem with some unspecified ELISP wizardry, which as a self-respecting Emacs user you are surely capable of.
3. You're reading a read-only document. You activate your full-text search, which every good document viewer has, and start typing the last sentence you read while it's still fresh in your memory.
How about making it configurable system-wide? Except that ain't gonna happen with the insane fragmentation we're seeing in UI libraries
At least Mac OS has a global setting for this (oddly placed in the Appearance section):
Click in the scroll bar to
(•) Jump to the next page
( ) Jump to the spot that's clicked
Make it an option so those with a skill issue don't make everyone else use a less powerful tool :)
Not every mouse has a scroll wheel, even today :).
Sure. Not every computer has a keyboard either.
What's stops you from adding an easy way to go back?
Mouse and keyboard should be alternatives on equal footing as much as possible. The gutter for page up/down has the benefit that you don’t have to move the mouse all the way up and down to the arrow buttons when repeatedly switching between the same adjacent pages, or when you positioned the scroll button slightly off where you wanted the position to be, and adjust it a little by paging up or down — especially when the scroll range is so long that a small mouse move on the scroll bar corresponds to more than one page.
For scroll ranges that aren’t overly long, you can long-press so that the area ends up scrolling to that position. Only for long scroll ranges is it necessary to drag, use the context menu, or the Shift key, for absolute positioning.
There are certainly trade-offs, but it’s not like there aren’t justified reasons for the way it is.
The ubiquity of mouse wheels and two-finger scrolling on trackpads drastically weakens your case for prioritizing the page up and page down behaviors in the scroll gutter. The mouse already offers a low-effort way to adjust scroll position at small to medium scales, generally much easier that repositioning the cursor from above to below the scroll thumb unless you really need to scroll by precisely one page (usually not possible on the web anymore because of floating dickbars).
Floating dickbars? What kind of websites are you visiting!?
With regards to Qt, does that mean Qt apps on Windows or something? I use KDE so there are a lot of Qt apps and they are all click-to-scroll in the scrollbar. Of course it's KDE so it's configurable so you can change it to click-for-page-up/down and middle click to scroll, but left-click to scroll is the default.
> IMO, "scroll here" should be the default action for clicking on a scrollbar.
> and Qt does not.
Isn't that what middle click does in Qt?
Thanks, that does indeed do "scroll here". Now to figure out how to swap the left click and middle click functionality...
IMHO it should be long hold. Click to jump by a page towards the click location. Hold down to jump all the way there.
"Long press" is the same as "slow press". When I click I want something to happen immediately, not 500ms later.
Yep, something happens immediately. Something different happens later.
"scroll here" is achieved by hold'n'drag
pgup behaviour allows for intermediate speed when line-by-line is too slow, while dragging is imprecise
>hold'n'drag
That's two actions, while clicking is only one.
Very worrying trend is thin scrollbars on websites, or in some rare cases - scrollbar just hidden. Fortunately Firefox has a setting in about:config: layout.css.scrollbar-width-thin.disabled=true .
That is so sad!! The larger our screens gets the smaller the scrollbars get, making it at least twice as difficult to use.
Where do you remove the option for me to see how long your (now often AI generated) blog post is just by glancing at the scroll bar, why do you remove it. That’s really crappy UX…
Also - apps (mainly Office 365) no longer use a framework that allows the OS supported use of Accent Color (the thing that allows the active windows toolbar to get a Color that quickly and effectively signals ‘I’m the active one now). No no - I am Office I am so important that I need to always be green (Excel) or blue (Word) etc. No need for you to know if I am the active window or not - you’ll find out when starting to type and the ‘wrong’ windows receives your input!
It seems that there is a design pattern where product owners favor apps to look nice in board room presentations over making them effective to use for professional users (as well as average Joe).
Don’t get me started on the often lack of keyboard shortcuts - just use the mouse (no thanx - way too much clicking, only use mouse where it makes sense, please)…
There's also
Works in Thunderbird too.I'm not surprised scrollbars are hidden. They're hidden by default on macOS and when you find out that every other OS turns your design into a scrollbar mess, disabling all of them is the quickest fix.
A "scrollbar mess"!? That type of designer is exactly the cause of the problem.
Usability breaks the look of my design, so I'll break usability! Obviously it's more important that everyone sees my amazing graphic design skills, than that they can actually use it!
I was referring to this: https://web.archive.org/web/20210409223357/https://svenkadak...
Usability is one thing, but with Apple hiding scrollbars by default, loads of macOS-designed websites spawn scrollbars all over the place on other platforms because of 1px overflows.
Thank you, that was a small but clear improvement to my browser.
yes, that and I've noticed many scrollbars have very little contrast with the background color, making them ever more difficult for me to see.
yes, I absolutely hate the new trend of tiny slivers that are basically invisible
I just want normal OS-controlled scrollbars everywhere
It’s about time that Raymond Chen starts ranting about the increasing amount of UI inconsistencies and loss of formerly ubiquitous features. (Or maybe I missed previous installments.)
The absurd UI inconsistencies ushered in with Windows 8 were a big part of my I moved back to macOS and Linux.
If I want a dozen different UI toolkits and three different settings apps in my day, Linux has that covered, with a lot more freedom and reliability.
The days when everything was WinForms were glorious.
I suspect there are reasons he doesn't talk much about anything newer than about Windows 8.
Apparently he also has a MASSIVE backlog of scheduled posts, so it's possible the queue hasn't caught up yet
Disclaimer: I left Microsoft in 2007. At that time he had several years of posts in an internal queue that you could comment on.
Ah yes, Microsoft’s “we care…………to talk about problems we’ll never fix” poster boy. Dude might be a fantastic developer, but he’s being used as a sock puppet.
In Linux/GTK, clicking in the gutter navigates to that position, and I have just discovered that Shift+clicking is equivalent to PageUp/PageDown, and that right-clicking seems to also be equivalent to PageUp/PageDown in Firefox, but scrolls at a fixed slow pace while the button is held in LibreOffice (15s per screenful at 6fps in Writer) and Inkscape (3s per screenful, smooth), and that middle-clicking is mostly PageUp/PageDown, but noop in Firefox; and I think those are the only apps I use (maybe even have installed) with regular scroll bars.
Oh yeah, one more, BibleTime which is Qt: it’s fairly Windowsy, click is PageUp/PageDown, right click is context menu (Scroll here, ---, Top, Bottom, ---, Page up, Page down, ---, Scroll up, Scroll down), Shift+click is same as click, middle-click is scroll here.
(These sorts of things are also one reason why you shouldn’t implement your own scroll bars in web pages: different platforms behave differently, and you can’t match it all sanely or sometimes at all.)
Strangely in Tor Browser I can middle click but not right click, despite it being based on Firefox and running in the same xfce session.
> different platforms behave differently, and you can’t match it all
Why do I care about matching it all? Do we need a scrollbar with all kinds of bespoke per-platform functionality? If I have a scrollbar, that people can use to scroll on all platforms, and it fits the visual aesthetic of my application instead of looking like an absolute dogshit eyesore, is that not good enough? What percentage of the population would you reckon is shift+clicking their scrollbars on a routine enough basis to notice a web-app that doesn't meet their expectations? 1%? 0.1%? 0.0001%? And in this fail case, when they shift+click the scrollbar and it doesn't behave as they expected, how much harm is really being caused? Will it ruin their day or will they maybe just go 'tch' and then use the scrollbar normally to achieve their scrolling needs like everyone else?
Apparently I have angered the scrollbar shift+clicking hordes. There might be dozens of you!
They'll just assume your site/app is broken, because their reference for what's correct is their platform. If they're annoyed enough, they go to a competitor unless it's a site/app mandated by their employer.
There is a literal 0% chance a single person in the entire history of our species has made the decision to switch to different software because shift-clicking the scrollbar didn't do what they expected it to. On the other hand, plenty of people are drawn to applications that look visually cohesive and are not an eyesore; not only because humans appreciate aesthetics, but also because visuals are an information channel and thus having non-obstrusive graphic design that guides your eyes to what matters has a very practical benefit.
I go out of my way to avoid using applications that ignore the macOS system preference for what clicking in the scrollbar does. People who care about the "feel" half of "look and feel" genuinely do exist. Janky scrolling behavior drastically lowers my opinion of an app, and in a web page it prompts immediate closure of the tab.
I didn't say a word about neglecting feel. Your argument appears to be that only Apple's anointed preference can count as "feel", and that anything that doesn't adhere to God-Emperor Jobs' vision is inherently janky. To which I say, username relevant.
"Feel" in the phrase "look and feel" refers to the behavior when interacting with the UI, as opposed to the aesthetic look. You asserted that literally nobody cares about a particular behavior that is the Windows equivalent to what has been a prominently-exposed configurable system preference in every version of Mac OS X/macOS.
Your weird hatred/obsession with Apple is preventing you from understanding that my argument wasn't even in favor of Apple's default behavior, but about software that doesn't respect the preference chosen by the end user who changes that setting away from the default.
I see. I was not aware of this system preference. Perhaps I would be if Apple didn't intentionally wall people out of developing for it unless they participated fully in the ecosystem by purchasing OS-locked hardware that they intentionally deter emulation of while requiring paying them for the privilege to develop for them. I won't ever see eye-to-eye with users who voluntarily opt into that environment, so if the scrollbar behaving slightly differently than expected but still reasonably well is truly a dealbreaker for somebody who stumbled onto my webapps, oh well!
> nobody uses Win32 scroll bars
Because it is impossible to change its color. It was/is not uncommon to see custom/dark skinned Windows apps with ugly gray scrollbars looking at you. Even today, only Light and Dark themes are supported, impossible to set a custom color.
Hmm.
"... Custom Draw, the feature found with many of the common controls shipped with Windows. Custom Draw allows an application to completely take over the drawing of a window’s scrollbars, and replace the scrollbar graphics with a completely user defined look."
https://www.catch22.net/tuts/win32/custom-scrollbars/
Not sure what (or when) Custom Draw was. It's not in my WIN32.HLP file.
Interesting that not even Raymond Chen knew about Shift+Click - i found it at some point years ago by trying random stuff on the Win32 controls and it was what i used to try whenever i wanted to tell if a program was using real Win32 controls or made its own since pretty much no toolkit had this behavior including Qt[0] :-P
[0] i think Qt might have added it at some point but it has been several years since i used Windows as a main OS and bothered to check it
Someone ought to catalog hidden behaviors like this in standard UI controls, so that people reimplementing these controls can have a reference. Obviously we can't rely on people reusing the same implementations to achieve consistency, but if there was documentation we'd at least have something to point to.
> Holding Shift while clicking on the scroll bar jumps the thumb directly to the spot where you clicked.
In properly designed bars this is either a default or a configurable option. Moving your mouse to a far away bar and holding shift are more expensive actions than pressing PgDn (or a shortcut), so the action can't be just a page, it has to be something more valuable, harder to replicate (the even smaller arrows at the top/bottom are even worse)
Completely agree. Besides, if clicking above/below the thumb is PgUp/PgDn, that means the buttons get smaller as you get closer to your destination, making them harder to press. Not good UX! The main counter argument to instantly moving I can think of, is that people may miss-click when trying to resize a window, and struggle to find their way back. Maybe a Ctrl-Z for window location history wouldn't be such a bad idea. You could piggyback off Vim's jump list which is navigable with Ctrl-O and Ctrl-I, though I'm sure a lot of applications already register those mappings.
> counter ... people may miss-click when trying to resize a window
That's a counter against another common sin of UI design that's stuck in the past, another superficially appealing idea that requires users hunting for tiny lines for common operations. That one should be fixed instead of making the scroll bar worse. (they even have that whole dedicated "windows" button that doesn't properly manage... windows)
Besides, lack of proper universal undo (that can undo selection/position changes, including windows) is yet another desktop UI design failure. Similarly to what you've noted, the solution to which is yet again fixing that instead of breaking useful functionality in other elements. So maybe it should be Win+Z to undo window resizing/moving?
My windows button properly handles windows. Window + left arrow snaps left. Windows + down snaps it down. Etc… It’s literally the best default window manager any OS has.
Nothing proper about that. Your right hand is on your mouse, which you use to move the window border. What's your Winkey answer to that? The actions you named don't resize in the way you want to and require moving your hand off the mouse to the cursor keys... and then back.
If your hand is on the mouse you already have a faster way to snap windows without the keyboard.
No you don't, you could avoid some mouse actions by also using a keyboard, so it'll be faster and more convenient
You're correct! I wrongly assumed that people were using their computers with:
A) Both hands on the keyboard, making it easy to reach both the Win key and the arrow keys at the same time to snap your windows.
or
B) One hand on the keyboard and one hand on the mouse, making window snapping instant with the mouse.
But I forgot that this is HN, so a significant proportion of readers also use their computers with both hands on the mouse, or no hands and one foot each for the keyboard and for the mouse.
Edit: Sorry for being sarcastic.
You wrongly assumed that your perception of what's "faster" is correct just because it's setup that way by the OS.
> A) Both hands on the keyboard, making it easy to reach both the Win key and the arrow keys at the same time to snap your windows.
It might be "easy" to reach arrow keys, but it's even easier and faster not having to do that
> B) making window snapping instant with the mouse
Your left window slightly overlaps the right one. You want to resize it by reducing its width by ~5% and its height by ~9% to avoid that Name your "instant" list of mouse actions to achieve that.
Leave a visual "shadow" of the scroll knob at the old position every time somebody clicks the bar to jump. Then the user can quickly snap back to where they where.
Then they can also jump back and forth effortlessly between two places in a document.
Seems like a great idea, have any apps implemented it?
Never seen it anywhere, but I think it would be very intuitive and practical.
The only somewhat similar function I've seen is on Kindle when you jump between footnotes or chapters, and they provide a very convenient interface for jumping back, but buttons instead of scroll bars.
Sadly, almost nobody uses Win32 scroll bars any more. Everybody uses frameworks that provide their own custom scroll bars.
The frameworks that actually wrap a Win32 scrollbar are the ones doing it right; the ones that (badly) reinvent a scrollbar are the ones to avoid. The real problem in this case isn't frameworks, but how they make use of the platform capabilities.
In older versions of Windows if you dragged the scroll thumb then moved the mouse far away from the scrollbar it would cancel the scroll, resetting the scrollbar to its original state. In the current version it is inconsistent. Notepad no longer supports this but browsers do.
You're joking, they've even managed to break a behaviour as basic as that!? I had no idea. There are so many reasons I'm not interested in using Windows 11, but it seems there's continually yet another issue I hadn't heard of before.
TIL - A scroll bar menu!
My first thought was "that's new to me, TIL", but when I tried right-clicking a scrollbar in Explorer, I immediately recognised the menu and thought "yeah, that's always been there". Now I'm just confused.
Interesting that shift+click to “scroll here” only came with Windows 7. Could have sworn it had always been there, I use it all the time. Infuriatingly, of all apps Microsoft Office doesn’t implement this! It would be so useful there and it’s Microsoft, but nope, you can’t expect Office to respect Windows conventions. Also, Excel’s scrollbar is deranged in general.
He's changed it now to say it was all added in Windows 2000.
I built a site where the wheel doesn't scroll, it just steps to the next item. Ended up rebuilding half of this list badly (slider, prev/next buttons, Home/End). Didn't know about shift+click until today.
You can also left click on the scroll bar to scroll to a place.
If you mean dragging, then that’s more than just a single click. And if you mean clicking in the gutter, then it also doesn’t work with a single click; you have to make use of the auto-repeat functionality, which takes O(n) time, where n is the distance between positions in number of pages. Shift+Click does it instantly in O(1).
>it also doesn’t work with a single click
If you hold it down long enough it does do it in a single click.
one page up/down at a time though. It gets there eventually, but it's ugly.
Look again at what I wrote. Auto-repeat translates into successive click events.
Yeah, I’m missing something here… didn’t he say that it goes down by a page if you click there? I always thought it just took you to that spot.
On Windows it's effectively a page down. The behavior you are describing is present on other platforms.
On many Windows scrollbars it's pinpoint click once to reach any spot.
Not the case in Notepad, Edge, RegEdit, Windows Settings, MS Teams, Firefox on Windows, Bruno, Windows Search. Where exactly did you experience this? All aforementioned were tested in Windows 11
What do you mean? In my experience and according to the article, it scrolls pages at a time when you left click on the gutter.
I think the article is focusing on the shortcuts.