101–110 of 666 posts
The problem with buttons that have shadows (even subtle ones) is that you can't rotate the screen 180 degrees and have it look nice. This is a problem if you put your phone or tablet flat on the table and someone sits opposite to you and looks at the same screen. Better to keep the design flat. It's also simpler.
Non techies have been using flat design interfaces for like a decade now and the world hasn't ended. If you personally like another style, totally fine. But it's odd that programmers always think they know more about usability than people who study it for a living.
> I have had to explain to people tons of times that the random word in the UI somewhere in an application is actually a button they can press to invoke an action.
There is a reason why Apple backpedaled on all that flat insanity for MacOS and iOS. Graphic designers and trendsetters usually know very little about usability, these are 2 completely different disciplines, and the Flat style was imposed by graphic designers, not UX people.
So basically the new GTK is iOS but without the professional designers behind it. What I cannot understand is how Canonical, Red Hat, or some rich SV person hasn’t thrown money at the problem and hired a big wig design firm or person to overhaul it all. Johnny Ive is now even available (if he’d take the project). But even going thru a site like dribbble there are so many amazing designers out there. To me it would be…
The old button was good in the desktop context, but I can't get behind this point: > The design even works very well on Linux phone formfactors. The author must mean something very different when they say "works very well" than I do when I say that. As much as I want it to, nothing about GTK works well in a phone form factor, IME. I look forward to continued improvement that will make that statement incorrect.
I for one don't want the phone form factor to influence my desktop experience. They are two completely different workflows that have conflicting needs IMO.
Earlier quoted context omitted.
Easy for someone who works at Apple to say "just throw money at the problem" while there is so much more to consider. Design as a workflow for Open Source design (as in UI/UX) hasn't even been worked on that much. Ideally, open source contributors work on projects because they care about it, and want to improve it. I'm not sure how many designers are using GTK applications day-to-day to care enough about it to start…
Inherently, good design requires top down authority to force a consistent look, and implementing it requires a bunch of programmers to spend time on boring work. That just doesn't work well in open source where people only want to work on their own thing, sometimes, and in their own way.
For example, style guides written and enforced by a small team can allow open contributions for the UI design.
I think it's mostly that not many have tried to figure out how to organize and actually run large-scale open source design work for UI/UX and that's why we haven't figured it out, I don't think it's "inherently" impossible.
> The only issue with it is that font rendering looks horrific, but that might just be my machine. This is because GTK4 enables pixel/scaling-independent fractional vertical positioning, even with hinting enabled. There's a long (somewhat ongoing) discussion at https://gitlab.gnome.org/GNOME/gtk/-/issues/3787 , though I haven't followed the last few months of discussion. Even though GTK4 aims to achieve scale-indepen…
“Scale-independent layout” (layout that ignores pixel aliasing) really requires PPI over ~200, that is, more than most desktop monitors provide. We’re still just not there.
With font rendering, I think there is hope. Horizontal subpixel positioning with vertical hinting seems like a good tradeoff to me. Grid fitting vertically is not too jarring, and grid fitting horizontally to subpixels instead of pixels looks pretty good too, on low resolution displays.
But it really is a son of a bitch elsewhere. For example, if you want a crisp 1px border on 96 dpi, you could specify it to be a 1px border at 96 dpi… but then what happens at 1.5x or 1.75x scale? From a purely logical position, the blurry line is actually the general case, and the integer scale case is actually an edge case. That desktop UIs aren’t blurry basically always is because we define them in terms of 96 DPI displays.
It gets worse for APIs, because APIs that want to present a resolution-independent world will cause difficult to tolerate bugs. The VS Code terminal will often be blurry at non-integer scales because it is using HTML canvas. If the canvas width or height is not a multiple of the size of a CSS pixel, it will cause the internal buffer to be scaled horridly. The fix might be a new API that reveals true coordinates… very, very nasty.
Apple’s solution was extreme: dump all font hacks, always render apps at 2x, then scale the whole framebuffer for different scale factors. It’s somewhat blurry, but avoids many ugly pitfalls in the common case, and makes apps simpler.
Unfortunately, the rest of the world is just stuck with really bad scaling and more often blurring on 96 DPI displays, the worst of both worlds.
For everyone mad at at "Don't theme my apps," consider why developers are doing it. Getting complaints about how your app is broken because of an overzealous theme that is beyond your control sucks . And after 10 years of dealing with it, GNOME developers decided it was enough. And... I don't wholly agree, but at the same time, themes had a decade to get their act together and stop angering GNOME developers. They did…
Earlier quoted context omitted.
For some value of “normal”. 4K (or better) monitors have long since become the choice for most of those who cares about how font rendering looks. After a decade of “retina” screens, I’m ruined, I can’t stand the look of anti-aliased fonts, whether Windows, Linux or macOS.
> 4K (or better) monitors have long since become the choice for most of those who cares about how font rendering looks. This is the hardware solution to something that can be solved in software. If your game is laggy, of course upgrading to a 3090 is going to help, but that doesn't mean you're solving the problem.
I agree that if you are making something and your target audience will be using non-HiDPI displays, then you should actually design your thing on those displays too. But no matter how good your software is, pixel density places a limit on what you can achieve.
Earlier quoted context omitted.
> 4K (or better) monitors have long since become the choice for most of those who cares about how font rendering looks. This is the hardware solution to something that can be solved in software. If your game is laggy, of course upgrading to a 3090 is going to help, but that doesn't mean you're solving the problem.
It can't be solved in software, due to the Nyquist limit: Sharp high-contrast edges (text) necessarily have high frequencies, and you need a high sampling rate (pixel density) to produce a good approximation of that signal. People have spent a lot of effort to push anti-aliasing techniques as far as they can go, but displays with higher pixel density are just better for displaying text. I agree that if you are making…
So basically the new GTK is iOS but without the professional designers behind it. What I cannot understand is how Canonical, Red Hat, or some rich SV person hasn’t thrown money at the problem and hired a big wig design firm or person to overhaul it all. Johnny Ive is now even available (if he’d take the project). But even going thru a site like dribbble there are so many amazing designers out there. To me it would be…
Professional designers seem to be the ones creating these problems. Back when it was just programmers you could tell a button was a button, a tab was a tab and we didn't hide basic functionality behind a swipe gesture or long press that users were supposed to just know.
Now everything is pretty but harder to use.