Graphics Archive

If you have used tools like Google’s PageSpeed Insights, you probably have run into a suggestion to use “next-gen image formats”, namely Google’s WebP image format. Google claims that their WebP format is 25 – 34% smaller than JPEG at equivalent quality. I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed. Spoiler alert: WebP doesn’t really provide any benefits, and since websites generally use JPEG as a fallback anyway, you end up with having to store two images at the same time, defeating the purpose entirely.

I am a programmer. I do not deal with digital painting, photo processing, video editing. I don’t really care for wide gamut or even proper color reproduction. I spend most of my days in a text browser, text editor and text terminal, looking at barely moving letters. So I optimize my setup to showing really, really good letters. A good monitor is essential for that. Not nice to have. A MUST. And in “good” I mean, as good as you can get. These are my thoughts, based on my own experience, on what monitors work best for programming. There’s a lot of good advice in here. We all know higher pixel densities make our user interfaces and text crisper, but a surprising number of people still don’t seem to know just how much of a gamechanger high refresh rates can be. If you’re shopping around for a new monitor, and you have to choose between higher pixel count or a high refresh rate, you should 100% without a doubt go for the higher refresh rate. The difference 120Hz or 144Hz will make in just how smooth and responsive a UI can be is astonishing. I think the sweet spot is 1440p at 144Hz, preferably with FreeSync or Gsync. Both Windows and Linux support high refresh rates out of the box, but as the linked article notes, macOS basically has no clue anything above 60Hz exists, and you’ll have to be very careful about what display you buy, and be willing to jump through annoying hoops every time you load up macOS just to enable high refresh rates.

Today, it seems we’re on another track completely. Despite being endlessly fawned over by an army of professionals, Usability, or as it used to be called, “User Friendliness”, is steadily declining. During the last ten years or so, adhering to basic standard concepts seems to have fallen out of fashion. On comparatively new platforms, I.E. smartphones, it’s inevitable: the input mechanisms and interactions with the display are so different from desktop computers that new paradigms are warranted. Worryingly, these paradigms have begun spreading to the desktop, where keyboards for fast typing and pixel-precision mice effectively render them pointless. Coupled with the flat design trend, UI elements are increasingly growing both bigger and yet somehow harder to locate and tell apart from non-interactive decorations and content. I doubt anyone here will disagree with the premise of this article, even if you might disagree with some of the examples. These past few weeks I’ve set up virtual machines of all the old Windows releases just to remind myself of just how good the graphical user interface introduced in Windows 95 was perfected over the years, culminating in the near-perfect Classic theme in Windows XP and Server 2003. Later iterations of the Classic theme, in Vista and onward, would sadly retain some of the Aero UI elements even when setting the Classic theme, ruining the aesthetic, and of course, the Classic theme is gone altogether now – you can’t set it in Windows 10. Similarly, Platinum in Mac OS 9 is still more coherent, more usable, and more intentful than whatever macOS brought to the table over the years. We can find solace in the fact that trends tend to be cyclical, so there’s a real chance the pendulum will eventually wing back.

I stopped there because we had to get back to work, but without even leaving the Finder and Desktop I was able to find a bunch of things that long-time Mac users had never known about because they never discovered them in their daily use. None of this is meant to say macOS is garbage or anything like that. It’s just interesting to see when people who love the Mac and are so critical of “discoverability” on the iPad. I’m not even saying the iPad is better than the Mac here, I’m just saying that “discoverability” is one of the big things that has people in a tizzy right now about the iPad, but I think some are laying into the iPad harder than is warranted. You have no idea how many undiscoverable or obtuse features, functions, tricks, and so on you take for granted when using old, established platforms like Windows or macOS.

What explains the popularity of terminals with 80×24 and 80×25 displays? A recent blog post “80×25” motivated me to investigate this. The source of 80-column lines is clearly punch cards, as commonly claimed. But why 24 or 25 lines? There are many theories, but I found a simple answer: IBM, in particular its dominance of the terminal market. In 1971, IBM introduced a terminal with an 80×24 display (the 3270) and it soon became the best-selling terminal, forcing competing terminals to match its 80×24 size. The display for the IBM PC added one more line to its screen, making the 80×25 size standard in the PC world. The impact of these systems remains decades later: 80-character lines are still a standard, along with both 80×24 and 80×25 terminal windows. As noted, a follow-up to our earlier discussion.

A month ago, we discussed an article about just how difficult text rendering is, and today we get to take a look at the other side of the coin – text editing. Alexis Beingessner’s Text Rendering Hates You, published exactly a month ago today, hits very close to my heart. Back in 2017, I was building a rich text editor in the browser. Unsatisfied with existing libraries that used ContentEditable, I thought to myself “hey, I’ll just reimplement text selection myself! How difficult could it possibly be?” I was young. Naive. I estimated it would take two weeks. In reality, attempting to solve this problem would consume several years of my life, and even landed me a full time job for a year implementing text editing for a new operating system.

Rendering text, how hard could it be? As it turns out, incredibly hard! To my knowledge, literally no system renders text “perfectly”. It’s all best-effort, although some efforts are more important than others. Text rendering is, indeed, in the eye of the beholder, and often preferences revolve around what people are used to more than anything else. Still, displays with higher and higher DPI have taken some of the guesswork out of text rendering, but that doesn’t mean it’s a walk in the park now.

GUIs are bloatware. I’ve said it before. However, rather than just complaining about IDEs I’d like to provide an understandable guide to a much better alternative: the terminal. IDE stands for Integrated Development Environment. This might be an accurate term, but when it comes to a real integrated development environment, the terminal is a lot better. In this post, I’ll walk you through everything you need to start making your terminal a complete development environment: how to edit text efficiently, configure its appearance, run and combine a myriad of programs, and dynamically create, resize and close tabs and windows. I don’t agree with the initial premise, but an interesting article nonetheless.

This program has been around since the early '90s, and runs, among other platforms, on Haiku today. Amazing.

I used to do this back in the early 2000s (goodness, I've been here way too long!). It was a fun thing to do, since you could never make it quite good enough - there was always something to improve. Good times.

The lack of a menu bar in (most) touch applications is really what sets them apart from regular, mouse-based applications. It makes it virtually impossible to add more complex functionality without resorting to first-run onboarding experiences (terrible) or undiscoverable gestures (terrible). While menus would work just fine on devices with larger screens such as tablets and touch laptops - I use touch menus on my Surface Pro 4 all the time and they work flawlessly - the real estate they take up is too precious on smartphones.

If touch really wants to become a first-class citizen among the mouse and keyboard, developers need to let go of their fear of menus. Especially for more complex, productivity-oriented touch applications on tablets and touch laptops, menus are a perfectly fine UI element. Without them, touch applications will never catch up to their mouse counterparts.

Ending the year a new release of the "desktop engine" Arcan and its reference desktop environment, Durden.

Arcan is a different take on how to glue the user-experience side of operating systems together. It has been in development for well over a decade, with the modest goals of providing a more secure, faster, safer and flexible alternative to both Xorg and terminal emulators, as well as encouraging research.

The latest release improves on areas such as crash resilience, wayland client support, VR devices, OpenBSD support and visual goodies. You can read through the full release post, with some of the more technical bits in the related articles about crash-resilient Wayland compositing and "AWK" for multimedia.

While there are some more objective arguments to be made, most arguments for and against either title case or sentence case mostly come down to whatever you're used to - what you grew up with. Title case looks entirely ridiculous and confusing to me, and makes dialog boxes, text, and other things much harder to read than when it's in sentence case.

The reason? We don't use title case in Dutch. Everything is sentence case. In English, it's mostly a case of preference, and either case type is fine as long as you're consistent.

Interestingly enough, Apple - generally considered the poster child for title case - actually localises its choice for case type. When you run Apple software in, say, Dutch - it doesn't use title case at all, opting for sentence case instead, because that's the norm in Dutch.

Title case also appears to be on its way out - generally, while pre-internet publications use title case, publications originating from the internet generally use sentence case. I wouldn't be surprised to see title case fall into disuse almost entirely over the coming decades in English - including at Apple. There's going to be an inflection point where title case will simply look incredibly out of place in English, as younger generations grow up on new publications that do not use it.

Title case is old - very old - probably because lowercase evolved out of uppercase, and over the centuries, we've been slowly pushing uppercase letters to perform very specific functions in text. Capitals have become an integral and core part of punctuation rules in every (?) language using on the Latin, Greek (?), and Cyrillic (?) scripts, and while there is some variation here and there - e.g. German holding on to capitalising every single noun, not just proper nouns - there's a remarkable consistency between them.

I'm fairly certain English' title case is the odd-one out, and as the internet continues to break down barriers between cultures and languages, title case will eventually disappear from English, too.

Volvo recently conducted a survey and asked consumers about their perceptions of self-driving cars. The question that stood out to me was whether a car company like Volvo or a technology company (Google, unnamed) was best positioned to bring safe self-driving cars to the market. Volvo was obviously fishing for a particular answer, and while they certainly have a vaunted reputation for technical innovation in the service of safety, I'm afraid I can't go along with the answer they're hoping for, partially because safety is only part of the story. In my opinion, no car company working alone is going to be able to produce a self-driving car with the kind of usability that consumers will expect. And for self-driving cars, usability is just as important as safety. In fact, they're inseparable.