Developers just love to take what the Web gives them for free, throw it away, and replace it with something worse.
Today’s example, from Open Collective, is a dropdown box: standard functionality provided by the <select> element. Except
they’ve replaced it with a JS component that, at some screen resolutions, “goes off the top” of the page… while simultaneously disabling the scrollbars so that you can’t reach it. 🤦♂️
I wanted a way to simultaneously lock all of the computers – a mixture of Linux, MacOS and Windows boxen – on my desk, when I’m
going to step away. Here’s what I came up with:
There’s optional audio in this video, if you want it.
One button. And everything locks. Nice!
Here’s how it works:
The mini keyboard is just 10 cheap mechanical keys wired up to a CH552 chip. It’s configured to send CTRL+ALT+F13 through
CTRL+ALT+F221
when one of its keys are pressed.
The “lock” key is captured by my KVM tool Deskflow (which I migrated to when Barrier became neglected, which in turn I migrated to when I fell out of love with Synergy). It then relays
this hotkey across to all currently-connected machines2.
That shortcut is captured by each recipient machine in different ways:
The Linux computers run LXDE, so I added a line to /etc/xdg/openbox/rc.xml to set a <keybind> that executes xscreensaver-command
-lock.
For the Macs, I created a Quick Action in Automator that runs pmset displaysleepnow as a shell script3, and then connected that via
Keyboard Shortcuts > Services.
On the Windows box, I’ve got AutoHotKey running anyway, so I just have it run { DllCall("LockWorkStation") } when it hears
the keypress.
That’s all there is to is! A magic “lock all my computers, I’m stepping away” button, that’s much faster and more-convenient than locking two to five computers individually.
Footnotes
1F13 through F24 are absolutely valid “standard” key assignments,
of course: it’s just that the vast majority of keyboards don’t have keys for them! This makes them excellent candidates for non-clashing personal-use function keys, but I like to
append one or more modifier keys to the as well to be absolutely certain that I don’t interact with things I didn’t intend to!
2 Some of the other buttons on my mini keyboard are mapped to “jumping” my cursor to
particular computers (if I lose it, which happens more often than I’d like to admit), and “locking” my cursor to the system it’s on.
3 These boxes are configured to lock as soon as the screen blanks; if yours don’t then you
might need a more-sophisticated script.
The W3C‘s WebDX Community Group this week announced that they’ve reached a milestone with their web-features project. The project is an effort to catalogue browser support for Web features, to establish an
understanding of the baseline feature set that developers can rely on.
That’s great, and I’m in favour of the initiative. But I wonder about graphs like this one:
The graph shows the increase in time of the number of features available on the Web, broken down by how widespread they are implemented across the browser corpus.
The shape of that graph sort-of implies that… more features is better. And I’m not entirely convinced that’s true.
Does “more” imply “better”?
Don’t get me wrong, there are lots of Web features that are excellent. The kinds of things where it’s hard to remember how I did without them. CSS grids are for many purposes an
improvement on flexboxes; flexboxes were massively better than floats; and floats were an enormous leap forwards compared to using tables for layout! The “new” HTML5 input types are
wonderful, as are the revolutionary native elements for video, audio, etc. I’ll even sing the praises of some of the new JavaScript APIs (geolocation, web share, and push are
particular highlights).
But it’s not some kind of universal truth that “more features means better developer experience”. It’s already the case, for example, that getting started as a Web developer is
harder than it once was, and I’d argue harder than it ought to be. There exist complexities nowadays that are barriers to entry. Like the places where the promise of a
progressively-enhanced Web has failed (they’re rare, but they exist). Or the sheer plethora of features that come with caveats to their use that simply must be learned (yes, you need a
<meta name="viewport">; no, you can’t rely on JS to produce content).
Meanwhile, there are technologies that were standardised, and that we did need, but that never took off. The <keygen> element never got
implemented into the then-dominant Internet Explorer (there were other implementation problems too, but this one’s the killer). This made it functionally useless, which meant that its
standard never evolved and grew. As a result, its implementation in other browsers stagnated and it was eventually deprecated. Had it been implemented properly and iterated on, we’d
could’ve had something like WebAuthn over a decade earlier.
Which I guess goes to show that “more features is better” is only true if they’re the right features. Perhaps there’s some way of tracking the changing landscape of developer
experience on the Web that doesn’t simply count enumerate a baseline of widely-available features? I don’t know what it is, though!
A simple web
Mostly, the Web worked fine when it was simpler. And while some of the enhancements we’ve seen over the decades are indisputably an advancement, there are also plenty of places
where we’ve let new technologies lead us astray. Third-party cookies appeared as a naive consequence of first-party ones, but came to be used to undermine everybody’s privacy. Dynamic
DOM manipulation started out as a clever idea to help with things like form validation and now a significant number of websites can’t even show their images – or sometimes their text –
unless their JavaScript code gets downloaded and interpreted successfully.
Were you reading this article on Medium, you’d have downloaded ~5MB of data including 48 JS files and had 7 cookies set, just so you could… have most of the text covered with
popovers? (for comparison, reading it here takes about half a megabyte and the cookies are optional delicious)
A blog post, news article, or even an eCommerce site or social networking platform doesn’t need the vast majority of the Web’s “new” features. Those features are important for some Web
applications, but most of the time, we don’t need them. But somehow they end up being used anyway.
Whether or not the use of unnecessary new Web features is a net positive to developer experience is debatable. But it’s certainly not often to the benefit of user experience.
And that’s what I care about.
Possible future presentation concept: using a cafe/dining metaphor to help explain the proximity principle in user interface design (possibly with a “live waitstaffing” demo?).
For my final bit of Three Rings volunteering this International Volunteer Day, I’m working on improving the UI of a new upcoming feature: a spreadsheet-like page that makes it easy for
administrators to edit the details of many volunteers simultaneously (all backed by the usual level of customisation and view/edit permissions that Three Rings is known for).
It’s a moderately-popular request, and I can see it being helpful to volunteer coordinators at many different types of voluntary organisation.
Don’t have time to write up the test instructions today, though, because I’ve got to wrap up my volunteering and go do some childwrangling, so that’ll do for now!
Progressive enhancement is a great philosophy for Web application development. Deliver all the essential basic functionality using the simplest standards available; use advanced
technologies to add bonus value and convenience features for users whose platform supports them. Win.
JavaScript disabled/enabled is one of the most-fundamental ways to differentiate a basic from an enhanced experience, but it’s absolutely not the only way (especially now that feature
detection in JavaScript and in CSS has become so powerful!).
In Three Rings, for example, volunteers can see a “starchart” of the volunteering shifts they’ve done recently, at-a-glance, on
their profile page1.
In the most basic case, this is usable in its HTML-only form: even with no JavaScript, no CSS, no images even, it still functions. But if JavaScript is enabled, the volunteer can dynamically “filter” the year(s) of volunteering
they’re viewing. Basic progressive enhancement.
If a feature requires JavaScript, my usual approach is to use JavaScript to add the relevant user interface to the page in the first place. Those starchart filters in Three
Rings don’t appear at all if JavaScript is disabled. A downside to this approach is that the JavaScript necessarily modifies the DOM on page load, which introduces a delay to the page being interactive as well as potentially resulting in layout shift.
That’s not always the best approach. I was reminded of this today by the website of 7-year-old Shiro (produced with, one assumes, at least
a little help from Saneef H. Ansari). Take a look at this progressively-enhanced theme switcher:
No layout shift, no
DOM manipulation. And yet it’s still pretty clear what features are available.
The HTML that’s delivered over-the-wire provides a disabled<select> element, which gains the CSS directive cursor: not-allowed;, to make it clear to the used that this dropdown doesn’t do anything. The whole thing’s wrapped
in a custom element.
When that custom element is defined by the JavaScript, it enhances the dropdown with an event listener that implements the theme changes, then enables the disabled
<select>.
I’m not convinced by the necessity of the <form> if there’s no HTML-only fallback… and the <label>
probably should use a for="..." rather than wrapping the <select>, but otherwise this code is absolutely gorgeous.
It’s probably no inconvenience to the minority of JS-less users to see a theme switcher than, when they go to use it, turns out to be
disabled. But it saves time for virtually everybody not to have to wait for JavaScript to manipulate the DOM, or else to risk
shifting the layout by revealing a previously-hidden element.
Altogether, this is a really clever approach, and I was pleased today to be reminded – by a 7-year-old! – of the elegance of this approach. Nice one Shiro (and Saneef!).
Footnotes
1 Assuming that administrators at the organisation where they volunteer enable this
feature for them, of course: Three Rings‘ permission model is robust and highly-customisable. Okay, that’s enough sales pitch.
…every major OS vendor has been adhering to the convention that checkboxes are square and radio buttons are round.
…
Apple is the first major operating system vendor who had abandoned a four-decades-long tradition. Their new visionOS — for the first time in the history of Apple — will have round
checkboxes.
Anyway, with Apple’s betrayal, I think it’s fair to say there’s no hope for this tradition to continue.
I therefore officially announce 2024 to be the year when the square checkbox has finally died.
The Web did a bad enough job of making checkboxes and radiobuttons inconsistent. I’m not saying you can’t style them, Web developers, but let’s at least keep the fundamental
shape of them the way that they have been for decades so that users can understand them!
But yeah, Apple’s new designs could spell the beginning of the end of this long-established standard. Sad times.
What happens when you give Gutenberg and Elementor to complete Beginners? In this challenge, Meg and Lily (two of my daughters) are tasked with re-creating a webpage. They’ve never
used Elementor or Gutenberg before, and I only gave them 30 minutes each.
…
Jamie of Pootlepress challenged his daughters – who are presumably both digital natives, but have no WordPress experience – to build a page to a specific design using both Gutenberg and Elementor. In 30 minutes.
Regardless of what you think about the products under test or the competitors in the challenge (Lily + Gutenberg clearly seems to be the fan favourite, which I’d sort-of expect because
IMO Gutenberg’s learning curve is much flatter that Elementor’s), this is a fantastic example of “thinking aloud” (“talkalong”)
UX testing. And with (only) a £20 prize on offer, it’s possibly the best-value testing of its type I’ve ever seen too! Both the
participants do an excellent job of expressing their praise of and frustration with different parts of the interface of their assigned editing platform, and the developers of both – and
other systems besides – could learn a lot from watching this video.
Specifically, this video shows how enormous the gulf is between how developers try to express concepts that are essential to web design and how beginner users assume things will work.
Concepts like thinking in terms of “blocks” that can resize or reposition dynamically, breakpoints, assets as cross-references rather than strictly embedded within documents, style as
an overarching concept by preference to something applied to individual elements, etc… some as second nature once you’re sixteen levels deep into the DOM and you’ve been doing it for years! But they’re rarely intuitive… or, perhaps, not expressed in a way that makes them intuitive… to new users.
Called @Tesco Abingdon for a #flujab but fell down a black hole in their menu system. Had to choose the “continue to hold” option several times… and then nobody answered
anyway…
Here’s a perfect example I bumped into earlier this week, courtesy of The Green Web Foundation. This looks like a
hyperlink… but if you open it in a new tab/window, you see a page (not even a 404 page!) with the text “It looks like nothing was found at this location.”
In the site shown in the screenshot above, the developer took something the web gave them for free (a hyperlink), threw it away (by making it a link-to-nowhere), and rebuilt its
functionality with Javascript (without thinking about the fact that you can do more with hyperlinks than click them: you can click-and-drag them, you can bookmark them, you can share
them, you can open them in new tabs etc.). Ugh.
Something you can clearly type a numeric day, month and year into is best.
Three dropdowns are slightly worse, but at least if you use native HTML <select> elements keyboard
users can still “type” to filter.
Everything else – including things that look like <select>s but are really funky React <div>s, is pretty terrible.
Calendars can be great for choosing your holiday date range. But pressing “Prev” ~480 times to get to my month of birth isn’t good. Also: what’s with the time “sliders”? (Yes, I know I’ve implemented these myself, in the past, and I’m sorry.)
People designing webforms that require me to enter my birthdate:
I am begging you: just let me type it in.
Typing it in is 6-8 quick keystrokes. Trying to navigate a little calendar or spinny wheels back to the 1970s is time-consuming, frustrating and unnecessary.
They’re right. Those little spinny wheels are a pain in the arse if you’ve got to use one to go back 40+ years.
These things are okay (I guess) on mobile/touchscreen devices, though I’d still prefer the option to type in my date of birth. But send one to my desktop and I will
curse your name.
Can we do worse?
If there’s one thing we learned from making the worst volume control in the world, the other
year, it’s that you can always find a worse UI metaphor. So here’s my attempt at making a date of birth field that’s somehow
even worse than “date spinners”:
My datepicker implements a game of “higher/lower”. Starting from bounds specified in the HTML code and a random guess, it
narrows-down its guess as to what your date of birth is as you click the up or down buttons. If you make a mistake you can start over with the restart button.
Amazingly, this isn’t actually the worst datepicker into which I’ve entered my date of birth! It’s cognitively challenging compared to most, but it’s relatively fast at
narrowing down the options from any starting point. Plus, I accidentally implemented some good features that make it better than plenty of the datepickers out there:
It’s progressively enhanced – if the Javascript doesn’t load, you can still enter your date of birth in a sensible way.
Because it leans on a <input type="date"> control, your browser takes responsibility for localising, so if you’re from one of those weird countries that prefers
mm-dd-yyyy then that’s what you should see.
It’s moderately accessible, all things considered, and it could easily be improved further.
It turns out that even when you try to make something terrible, so long as you’re building on top of the solid principles the web gives you for free, you can accidentally end
up with something not-so-bad. Who knew?
It’s that time of year again when I comparison-shop for car insurance, and every time I come across a new set of reasons to hate the developers at Confused.com. How do you confuse me?
Let me count the ways.
No means yes
I was planning to enumerate my concerns to them directly, via their contact form, but when I went to do so I spotted this bit of
genius, which clinched it and made me write a blog post instead:
Clicking the word “Yes” means “Yes”. Clicking the word “No” means “Yes” as well.
Turns out that there’s a bit of the old sloppy-paste going on there:
Honestly, I’m used to my unusual name causing trouble by now and I know how to work around it in the way that breaks the fewest systems (I can even usually
get airline tickets without too much difficulty nowadays). But these kinds of (arbitrary) restrictions must frustrate folks like Janice Keihanaikukauakahihulihe’ekahaunaele.
I guess their developers didn’t realise that this blog post was parody?
Also, that’s not my title!
This one, though, pisses me off:
As everybody knows, there are only six titles, and two of them are “Dr”.
This is a perfect example of why your forms should ask for what you actually want to know, not for what you think people want to tell you. Just ask!
If you want to know my gender, ask for my gender! (I’m a man, by the way.)
I don’t understand why you want to know – after all, it’s been illegal since 2012 to risk-assess/price car insurance differently on the grounds of gender – but maybe you’ve
got a valid reason. Which hopefully you’ll tell me in a tooltip. Like you’re using it as a (terrible checksum) when you check my driving license details, that’s fine!
If you want to know my title, ask for my title! (I prefer not to use one, but if you must use one I’d prefer Mx.)
This ought to be an optional field, of course, and ideally you want a free text input or else you’ll always have missed somebody (Lord, Reverend, Prince, Wing Commander…).
It’s in your interests because I’m totally going to pick at random otherwise. Today I’m a Ms.
Consistency? Never heard of it.
It’s not a big thing, but if you come up with a user interface paradigm like “clicking More… shows more buttons”, you ought to stick to it.
Maybe their internal style guide says “a More… button with three additional options should use buttons, but four additional options should be a drop-down”. But it seems more-likely
that they just don’t have one.
Again, I’m not sure exactly what all of this data is used for, nor why there’s a need to differentiate between married couples and civil partnerships, but let’s just assume this is all
necessary and legitimate and just ask ourselves: why are we using drop-downs now for “More…”? We were using buttons just a second ago!
This was just crying out for a type-in field. But I guess the same developer who did the “Title” question did this one too, and wanted to show off the fancy “more buttons” control
they’d written. (Imaginary style guide be damned!)
What’s my occupation again?
There’s so much to unpack in the “occupation” part of the form that I’m not even sure where to begin. Let’s just pick out a few things:
I never answered a question this hard even in the exams I did when I was a student. Why do we care where students live… except if they’re postgrads? If I’m a mature student
studying a postgraduate course in medicine while living at home with my parents… which of the five possible options should I pick? And, again: what difference could it conceivably
make?
The student thing is just the beginning, though. You can declare up to two jobs, but if the first one is “house person/parent” you can’t have a second one. If you’re self-employed, that
has to be your first job even though the guidance says that the one you spend most time on must be the first one (this kind of thing infuriated me when I used to spend 60% of
my work time employed, 20% self-employed, and 20% studying).
I’m not saying it’s easy to make a form like this. I know from experience that it’s not. I am saying that Confused.com make it look a lot harder than it is.
Well that clears everything up. Also, I think you mean “houseperson”, unless you’re referring to somebody who is half-house/half-person, like some kind of architectural werewolf.
What do you mean, you live with your partner?
At a glance, this sounds like a “poly world problem”, but hear me out:
What you’re seeing here is a reference-identity error. I can’t possibly be living together with somebody as a couple if their marital status isn’t “Living With Partner”.
I put Ruth‘s martial status as married, because she’s married to JTA. But then when it asked how she was related to me, it wouldn’t accept
“Living together (couple)”.
If I put Ruth as the primary policyholder (proposer) though, I don’t even get the option of “living together (couple)” to describe her relationship with me. ‘Cos it’s physically
impossible to have a partner and be married, right?
Even if you don’t think it’s odd that they hide “living with partner” button as an option to describe a married person’s relationship to somebody other than their spouse… you’ve still
got to agree that it’s a little bit odd that they don’t hide the “spouse” button. In other words, this user interface is more-okay with you having multiple spouses than it is
with you having a spouse and an unmarried partner!
And of course this isn’t just about polyamorous folks: there are perfectly “normal” reasons that a person might end up confused by this interface, too. For example a separated (but not
yet divorced) couple, one of whom has a new partner (it’s not even inconceivable that such a pair might share custody of a car). Also interesting is the fact that the form doesn’t
care about the gender of your spouse (it doesn’t ask for “husband” or “wife”) but does care about the gender of your parent, child, or sibling. What gives?
Half a dozen easy fixes. Go for it, Confused.com.
Given that their entire marketing plan for most of the last two decades has been that they reduce customer confusion, Confused.com’s user interface leaves a lot to be
desired. As I’ve mentioned before – and speaking as a web developer that’s been in the game for longer than their company has – it’s not necessarily easy to get this kind of
thing right. But you can improve a form like this, a little at a time. And every little win counts for something: a more-satisfied returning customer, perhaps, or a new word-of-mouth
recommendation.
Or you can just let it languish and continue to have the kind of form that people mock on the public Internet.
It’ll be a year until I expect to comparison-shop for car insurance again: let’s see how they get on, shall we?
Update (21 January 2021): Confused.com Respond!
I didn’t expect to receive any response to this post: most organisations don’t when I call-out the problems with their websites (not least
because I’m more than a little bit sarcastic about it!). I never heard back from the Digital Climate Strike folks, for example,
when I pointed out that their website was a great example of exactly the kind of problem they were protesting. But Confused.com
passed on my thoughts to Product Manager Gareth who took a look at them and gave me a £20 Amazon gift card by way of thanks. Nice one, Confused.com!
There are plenty of opportunities for friction in the user experience when logging in, particularly while entering a two factor authentication code. As developers we should be
building applications that support the need for account security but don’t detract from the user experience. Sometimes it can feel as though these requirements are in a battle
against each other.
In this post we will look at the humble <input> element and the HTML attributes that will help speed up our users’ two factor authentication experience.
…
Summary: simple changes like making your TOTP-receiving <input> to have
inputmode="numeric" gives user-agents solid hints about what kind of data is expected, allowing mobile phones to show a numeric keypad rather than a full keyboard, while
setting autocomplete="one-time-code" hints to password managers and autocomplete tools that what’s being collected needn’t be stored for future use as it’ll expire (and can
also help indicate to authenticators where they should auto-type).
As my current research project will show, the user experience of multifactor authentication is a barrier to entry for many users who might otherwise benefit from it. Let’s lower that
barrier.
(Joe reads the text on IE and clicks on “Suggested Sites”)
Me: “Why did you click on that?”
Joe: “I don’t really know what to do, so I thought this would suggest something to me.”
…
Finding adults who’ve got basically no computer experience whatsoever is getting increasingly rare (and already was very uncommon back in 2011 when this was written), and so I can see
why Jennifer Morrow, when presented with the serendipitous opportunity to perform some user testing with one, made the very most of the occasion.
As well as being a heart-warming story, this post’s a good reminder that we shouldn’t make assumptions about the level of expertise of our users.
