Graphics Archive

This is the real, full photoshop - the same codebase as the regular Photoshop, but running on the iPad with a touch UI. The Verge's Dami Lee and artist colleagues at The Verge got to test this new version of Photoshop, and they are very clear to stress that the biggest news here isn't even having the "real" Photoshop on the iPad, but the plans Adobe has for the PSD file format.

This does seem to be much more than a simple cash grab, and I'm very intrigued to see if Adobe finally taking the iPad serious as a computing platform will convince others to do so, too - most notably Apple.

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.

Fantastic read with fantastic examples. Set some time aside for this one - you won't regret it.

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.

There's something unsettling about these brutalist redesigns by Pierre Buttin - but I don't outright hate them. There's something very functional about them.

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.

Quite a read, but definitely worth it.

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.

This is a bit of a weird topic, but I think it might be interesting to figure out what, exactly, is going on here. Ever since its very first release Chrome has had a very small, barely noticeable visual bug in its user interface: its window widgets (or buttons) are not aligned properly. As you can see in the screenshot below, they are shifted slightly to the right compared to a window without the bug.

Now, this has never been too big of an annoyance to bother the developers with, so I never made a bug report out of it, and I still don't think it's important enough. Chrome has a custom titlebar compared to regular Windows windows (because of the tabs-on-top), so I figured that was the cause.

Since yesterday, I've been using Firefox 29, and I noticed that it has the exact same bug:

Now my interest is properly piqued. Upon closer inspection, you can see that Chrome and Firefox actually have different offsets. The below image also illustrates that in the normal situation, the right edge of the close widget lines up pixel-perfect with the content area (the red line); this is not the case for Chrome and Firefox, where the close widget and content are misaligned.

These are two different applications with two entirely different codebases, and yet, they have the same visual bug, albeit slightly different in presentation. For some reason, this fascinates me; is it a limitation in how Windows handles custom titlebars? Is it, perhaps, a feature, and is there a deeper reasoning behind it? Is it just sloppiness? Do we have any Windows developers here who could possibly shed a light on this?

Some will call this petty whining, and surely, it is. However, I'm not asking this because I'm bothered by it; I'm asking this because I'm genuinely curious where this bug comes from.

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.