- 308comments
- 74comments
- 35comments
- 239comments
- —discuss
- 105comments
- 190comments
- 36comments
- 160comments
- 74comments
- 5comments
- 176comments
- 4comments
- 18comments
- 238comments
- 99comments
- 70comments
- 158comments
- —discuss
- 3comments
- —discuss
- 3comments
- 137comments
- —discuss
- 89comments
- 8comments
- 310comments
- 820comments
- 262comments
- 683comments
You can also left click on the scroll bar to scroll to a place.
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.
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).
If you hold it down long enough it does do it in a single click.
Look again at what I wrote. Auto-repeat translates into successive click events.
one page up/down at a time though. It gets there eventually, but it's ugly.
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.
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.)
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
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.
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.
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 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.
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.
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.
The designers of your software and their bosses disagree though, default widgets don't provide "branding" and allow the poor designers to express themselves.
I can only hope they'll be put out of a job by models too.
C#/.NET and WinForms is still a viable choice. Though for a new project I might try WPF, for a slightly more modern appearance.
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.
TIL - A scroll bar menu!
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 .
yes, I absolutely hate the new trend of tiny slivers that are basically invisible
I just want normal OS-controlled scrollbars everywhere
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.
"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
That's two actions, while clicking is only one.
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.
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.
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.
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