Graphics Archive

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.

I've been looking at a lot of these 8bit fonts because of recent emulation efforts. I'd like to throw Visi On's fonts into the fray, too.

In-car software is absolutely horrifying and crazy complex. A good friend of mine regularly drives brand new and super-expensive cars (in the hundreds of thousands of euros category), and even in those cars, the user interfaces are just terrible. There's a lot of room for improvement and disruption here.

It's rare these days, but it happens: a (what I think) is a completely new UI element (or 'widget', in proper parlance).

In my quest for an Android Twitter client that doesn't suck, I stumbled upon Tweedle, a no-frills, properly designed Twitter client for Android that, as far as I can tell after a few days, does not suck. It integrates properly with Android and has an actual Android user interface - unlike other Android Twitter clients, it doesn't shove any non-standard UI crap in my face. Really, the complicated, overdesigned user interfaces many Android developers come up with just to show several snippets of text in a scrollable list (that's all Twitter is, folks) is remarkable. Let's save that rant for another day, however.

What I find most intriguing about Tweedle is that it includes a UI widget I've never seen before. Instead of a regular scrollbar, Tweedle has a vertical line that increases in length as you scroll down in your timeline, and decreases in length as you scroll upwards. If you reach the newest tweet, the bar disappears. It's a different take on the traditional scrollbar, but to me, it feels like a better fit for a timeline than a traditional scrollbar.

If you scroll far enough down, the line will reach all the way to the bottom. If you keep scrolling beyond that point, the line just stays there. A traditional scrollbar, like in, say, Tweetbot 3 for iOS 7, acts differently. Once the scrollblob hits the bottom of the screen, a new set of tweets loads, and the blob erratically jumps upwards, which is just plain weird when you think about it.

The traditional scrollbar - even a proportional one - does its job best when used with finite scrollable areas. Timelines on Twitter, Facebook, Google+, and so on, however, are essentially infinite lists, which causes traditional scrollbars to jump around whenever you reach the 'bottom' of your timeline and new content is loaded. The line in Tweedle does not have this issue, but it does introduce a new one - once the line fills up and hits the bottom, but you keep on scrolling - it stops conveying any new information.

Still, I find it a fascinating rethinking of the traditional scrollbar, and I hope to see it in more applications.