Dear whoever worked on Xanadu ever ever ever. You keep on saying that you went around the world, talked to anybody who would listen, and nobody got it. Maybe, just maybe, the problem was the message, not the listeners.
I just re-read Wired profile of Xanadu from 1995, and it's the same thing over and over again. It's not the world. It's the message. I mean, once anything is published online, it can never be edited because you link to "start character"-"end character" integer positions as the supposedly immutable snippet? What kind of a universe does that online world live in???
> What kind of a universe does that online world live in?
One that you're misrepresenting. It's like complaining that nothing in a git repo can be edited because commits are identified by long hex-encoded hashes.
Having known that crowd back then, the message was the problem. Everything is pay per view in Xanadu. Wrong business model. They were mostly libertarians, of the "meter everything and let the free market sort it out" persuasion.
Also, they were way too text oriented.
I mean, once anything is published online, it can never be edited because you link to "start character"-"end character" integer positions as the supposedly immutable snippet? What kind of a universe does that online world live in???
The part of the world that has Github, shared Google Docs, and wikis. You can edit, and it's all trackable. It's a poor mass distribution system, but a reasonable approach to collaboration.
Both all-you can eat, apply to any publisher, and some sort of (waves hands) standard pro-rata scale. Probably scaling down with higher volume (RMS suggested a log-of-views basis, because reasons).
In both cases, I'd like to see the reader/viewer fee scaled at least roughly by income/wealth.
https://www.jetbrains.com/toolbox-app/ is the first Jetbrains app that's been ported to Compose. Note that Compose Desktop is still in alpha, pre-release stage.
"Flowers replaced to red" looks like it also tinted the whole sky red. In general, all the image captions imply that the algorithm is able to identify objects (flowers, ice cream scoop, shirt) and only change that object's color.
Modular exponentiation can be done very quickly, you don't need to compute n^4 at all. Not sure if this particular implementation makes use of that, though. In Haskell, I can compute (100000 ^ 1000000 `mod` 15) near instantly.
Python's built in pow function does this, but the ** operator does not. Of course, like Haskell, it also uses arbitrary precision integers by default, so it might take forever to compute something, but it won't overflow unless you actually run out of memory.
Retail stores make tons of money on gift cards - specifically, when people don't use the balance or lose them. See https://www.cnbc.com/2020/01/10/3-billion-of-gift-cards-go-u.... It's like the stores are essentially minting their own money at this point. They have zero incentive to put "checks and balances" in place, unless they start losing money on it from some king of federal penalties tied to cases like the one in the article.
Ironically, even though the contrast ratio of the body content is technically passing the contrast threshold, it's unpleasant to read. It's the combination of the lighter shade of grey, small font size and the thinness of the font glyphs themselves.
Great point! That's one of the reasons we also changed the fonts we use in our product interfaces around the same time, including removing any usage of `light` font weights. We haven't yet made a similar change to our blog design, but it would be a solid improvement for legibility.
I took one look and immediately checked the comments to see if someone else had already brought this up. I looked at the images then, but reading the text itself was too much effort for me.
Indeed, in that they have multiple SVG versions of the same icon (name) for smaller pixel sizes - 16x16, 22x22, 24x24, 32x32 - the last time I checked.
That seems like the appropriate compromise, SVG for various optical sizes. The analog example that comes to mind is Dr. Seuss books. The Cat in the Hat is much less detailed when he is far away, and has very detailed pen work close up.
If you read the closing paragraphs of the article, you will see that I do talk about the physical size of the final representation of the pixel-based icon. However, just because you can use more pixels on higher-resolution displays, it does not mean that you can just take a highly detailed vector artwork and display it.
Being able to display very intricate details for each icon is not necessarily the end goal. The end goal is to preserve the clarity, which is why smaller icons (physically, not pixelwise) should have smaller amount of detail compared to larger ones.
In your example, a 128x128px icon that occupies the same physical size on an extra-high DPI screen as a 16x16px icon on a lower-end screen can (mathematically) have 8 times as much detail along each axis. Just because this is possible to do without losing the signal quality on the level of individual pixels, does not mean that it is desirable from the UX / UI perspective.
You're right that in a world with varying pixel densities, it's not enough to just design an icon for a given pixel size. But physical size isn't the right design target either. An icon designed for a given physical size on a display close to the user's eyes won't work if the display is much further away.
So when you go from thinking about pixel size to thinking about physical size, you're going in the right direction, but you're not going far enough. The relevant metric is more like "the angle subtended at the user's eyes", kinda like how the "CSS pixel" unit works.
Now, given that it's almost impossible for software on the device to know how far away the user is, trying to design up front for that metric (angle subtended by the icon) is also almost impossible.
And even if you did know both the pixel density and the distance to the display, that still doesn't take into account the fact that users will vary in their visual acuity. The right design choice for a 20-year-old user holding the display close to their face is going to be dramatically different from the right choice for a 70-year-old holding the display at arms length.
You can't really design well for all those possibilities up front. The right answer has to involve allowing the user to adjust the "zoom level" to their liking. And that level of flexibility means that automated approaches (possibly something like freetype's autohinting, extended to work in color) are probably going to be a better approach than manual pixel tweaking.
This is actually a good reason to move away from pixel designs and towards vector graphics. An assumption made now is that there is one or maybe two resolutions at which a 128x128 icon is displayed, and this is true for iOS screens. But with a more heterogenous selection of screen resolutions and expected screen distances, the actual display size of a 128x128 icon is basically unknown.
There are two problems you are conflating. One is that low-resolution icons have visual artifacts, and therefore manual pixel hinting is valuable. In general though, this problem only crops up for very small icons, say smaller than 32x32. But as screen resolutions increase, this problem will get easier.
The other problem is that at small sizes, we want icons to be less detailed and therefore more recognizable. A quarter-inch icon two feet from the eyes should have very little detail. This is a problem that vector graphics are very suited for. One can specify a low-detail icon that should be used when the real size of the icon is below some threshold, no matter whether that screen space is 64x64 or 20x20. In a world where the screen resolution of an icon that size can vary by more than a factor of two, using pixels is the wrong approach.
I just re-read Wired profile of Xanadu from 1995, and it's the same thing over and over again. It's not the world. It's the message. I mean, once anything is published online, it can never be edited because you link to "start character"-"end character" integer positions as the supposedly immutable snippet? What kind of a universe does that online world live in???