- 185comments
- 68comments
- 14comments
- 16comments
- 20comments
- 163comments
- 94comments
- 29comments
- 173comments
- 815comments
- 150comments
- 1062comments
- 234comments
- 17comments
- 95comments
- 115comments
- 169comments
- —discuss
- 1comments
- —discuss
- 110comments
- 218comments
- 6comments
- 431comments
- 293comments
- 84comments
- 202comments
- 665comments
- 190comments
- 243comments
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).
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.
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.)
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, 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?
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.
C#/.NET and WinForms is still a viable choice. Though for a new project I might try WPF, for a slightly more modern appearance.
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 .