Journal tags: picker

Sometimes I look back through my blogging archives and notice what’s changed over time.

For example, I used to write quite enthusiastically about the arrival of a new operating system from Apple. That is no longer the case, to put it mildly. I’m currently holed up on Sequioa, trying to resist all the nudgings to “upgrade” to the tacky design nightmare that is Tahoe. I feel like the protagonist of Pluribus.

I used to write about software I really liked. Sometimes it was software made by Apple. More often it was from some independent developer.

Like, I remember how much I loved a little application called Quicksilver. It just did one thing. You pressed control and space and then started typing the name of any programme installed on your computer. After a few characters Quicksilver would show you the match, you hit enter and the programme launched.

If that process sounds familiar, it’s because Apple ended up incorporating it into their own Spotlight feature. Quicksilver got sherlocked (ask your parents).

Recently though, Spotlight got worse and worse at doing its one job. It’s been laggy and inaccurate, even though I set my Spotlight indexing options to only index the Applications folder.

Then I found TinyStart. It’s like Quicksilver reborn!

A tiny launcher for macOS, fast and focused on the essentials.

Actually, it does double duty. As well as being an application launcher, it’s also an emoji picker. 👍

Best of all, not only is TinyStart a return to the focus and quality of software of yore, it’s also a return to the pricing model. You buy the software—for a measly €5—and that’s it. You own it now. There’s no subscription you have to pay every month.

I love everything about this.

In two of my recent talks—In And Out Of Style and Design Principles For The Web—I finish by looking at three different components:

1. a button,
2. a dropdown, and
3. a datepicker.

In each case you could use native HTML elements:

1. button,
2. select, and
3. input type="date".

Or you could use divs with a whole bunch of JavaScript and ARIA.

In the case of a datepicker, I totally understand why you’d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.

In the case of a dropdown, it’s less clear-cut. Personally, I’d use a select element. While it’s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That’s good enough for me.

Still, I can understand why that wouldn’t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you’re going to have to break out the JavaScript and ARIA.

Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling select elements. That’s one of the reasons why the work being done by the Open UI group is so important.

But there’s one more component: a button.

Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.

Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.

I’ve been trying to understand the mindset of a developer who wouldn’t use a native button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.

I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.

When I hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).

But I now understand that someone else might hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.

I get it. I don’t agree. But I get it.

If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren’t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.

But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It’s not what I would do, but I think I understand the motivation a bit better now.