This is right there in chapter 1:
As a user, I should never have to devote a millisecond of thought to whether things are clickable-or not.
201–210 of 666 posts
This is right there in chapter 1:
As a user, I should never have to devote a millisecond of thought to whether things are clickable-or not.
Earlier quoted context omitted.
This is why I have reverted to the CLI whenever possible. There's something deeply assuring knowing that I don't have to relearn my whole workflow every few months when the trends change. ls, grep, find, ps, htop will always be what they are. Even the Windows CLI is thankfully consistent. All I want is to get work done the way I want, and I've found the CLI is increasingly the path of least resistance.
sometimes even cli tools go away. eg: ifconfig
Earlier quoted context omitted.
UIs go through 3D and 2D in phases. Windows 2.0 - 3.1: 2D Windows 95 - 7: 3D Windows 8 - 10: 2D MacOS 6 - 7: 2D MacOS 8 - 10: 3D MacOS 11: 2D As a side point, I predict Sheriff and Sans-Sheriff fonts to also go into similar phases too though over a longer time scale. We're in a very long Sans-Sheriff phase now but I think Sheriff will be "in" in 20 years.
FWIW, Macintosh System 6 was just black and white (and only 640x480px), so 3D wasn't really tenable. System 7 and 8 had support for color, and was as 3D as it could muster, like highlight and shadow treatment on buttons and other widgets, and embossed, draggable thumbs. https://en.wikipedia.org/wiki/System_7#/media/File:Mac_OS_7.... Mac OS X brought Aqua, which was a pinnacle of 3D and skeuomorphic design. You know y…
> I feel like the designers of this new theme have never sit down with anyone who's not a "techie" to explain to them how to use a computer. The designers of this new "everything is flat and devoid of visual hinting" trends are maybe, at most, enthusiast, but not professional designers. I don't mean professional in the "hired for work" sense, but in the "really has the knowledge and has studied the psychology behind…
You note that visual and UI design in open source and in proprietary applications show some of the same idiosyncrasies.
You conclude that this makes open source designers more blameworthy.
I would suggest instead, that this is evidence that those evil management overlords in the corporate world are perhaps convenient scapegoats, but actually less to blame than we might think?
Earlier quoted context omitted.
> 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? The border width should get snapped to the physical (sub-)pixel resolution as part of rendering. Typically, this should come with changes in contrast too, such that if a line is forced to become thinner it also gets drawn with higher contrast wrt. the surroundings,…
> All of this stuff can be made to work. We’ve tolerated a great degree of complexity just to make fonts look good at 96 DPI. Looks like we’re able to tolerate a bit more complexity to enable GPU rendering. However, many years into having high DPI displays, it’s not obvious people are willing to take the complexity to make low DPI and high DPI screens look good simultaneously. The thing is, with fonts , we already be…
The font rasterizer already exists (unless it is a bitmap font UI, but those aren't common any more).
How does adding additional mechanisms make for a simpler or cleaner rendering pipeline?
Earlier quoted context omitted.
How's KDE/Plasma with touch these days? I'm running GNOME on my Surface right now because it does pretty well with both Desktop and Tablet modes, but I'm pretty unhappy with the at times patronizing philosophy behind the project.
The biggest complaint from steam deck users seems to be the virtual keyboard isn't reliable, which is a pretty big issue.
Earlier quoted context omitted.
> 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? The border width should get snapped to the physical (sub-)pixel resolution as part of rendering. Typically, this should come with changes in contrast too, such that if a line is forced to become thinner it also gets drawn with higher contrast wrt. the surroundings,…
> All of this stuff can be made to work. We’ve tolerated a great degree of complexity just to make fonts look good at 96 DPI. Looks like we’re able to tolerate a bit more complexity to enable GPU rendering. However, many years into having high DPI displays, it’s not obvious people are willing to take the complexity to make low DPI and high DPI screens look good simultaneously. The thing is, with fonts , we already be…
Earlier quoted context omitted.
I've been hoping that for 20 years but it hasn't happened yet. It seemed like American companies always favoured GTK/GNOME (I guess because Qt/KDE development was more European?), even though Qt/KDE generally managed to do more with less. But I can appreciate that if you're aiming for the corporate market, customizability may be a downside.
I think that Red Hat (now part of freaking IBM ) has always been oriented to big corporations, knows how to speak their language, and is an obvious choice for corporate Linux support. If you're already in bed with RH on the server front, it makes obvious business sense to also follow them on the (much, much smaller) desktop front. Since RH basically owns Gnome development (I know, I know), they impressvely used it as…
“Big likes big.”