A few weeks ago, we were discussing the need for better cybersecurity in their architecture. We spoke about several aspects of security, then they asked an outstanding question.

"What should I buy to be secure?"

It took a few moments to tease out exactly what they thought they were asking. In their mental model they could just buy a box which did what they needed. Want to print from any workstation? Buy a big HP network printer. Want to get WiFi in the office? Buy a bunch of access points. Want a website? Buy a WordPress. Want security? Buy a [fill in the blank]?

Their notion is that most things are products. This is a common belief. I've had clients ask "What do I buy to make this accessible?" or "What can I buy to improve usability?"

In all these cases there are unscrupulous people who will sell you a magic cure-all - but the real answer is that these things are a process; not a product.

Yes, you can buy tools which will help improve your security / accessibility / usability etc. But unless you put processes in place to get people to use them effectively, the tools are useless.

People need to understand why something is important. They need processes which support best practices. The business needs a holistic understanding of how these processes improve the business. And that is all underpinned by tools which make it possible.

There's no magic box which can both protect you from your CEO accidentally CCing confidential data to a competitor and stop DDoS attacks. An accessibility overlay won't help you if your staff refuse to incorporate alt text into their workflow. Automated code testing can't stop you building things without testing them with users.

Security is a verb - it is a doing word. Accessibility is a verb - it is a doing word. Usability is a verb - it is a doing word.

Buy nouns which support your verbs.

By now, you're probably sick and tired of shoving a swab up your nose and / or down your throat. You've grown blasé about the little medical marvel as it reacts to whatever antibodies are flowing laterally. You don't even bother reading the paper leaflet any more. Right?

But that swab test wasn't the only option on the table.

One of the (many) tasks our team was looking into was how to make the experience of taking the test more digital. Instead of black-and-white pamphlet, how about... AN IPHONE APP an interactive website? It could show you videos of exactly what to do! It could have a built in timer to remind you when to check your results! It could have multiple languages - including British Sign Language! AMAZING!

Sure, there would be a cost to producing and updating it - but making it easier for people to take accurate tests could save lives. And that'd be worth it, right? We wrestled with several different ideas and sketches of prototypes. Testing them to see if they were actually useful. In the main, they weren't.

But this wasn't the only digital process we were considering. One proposed Covid test was digital. I don't mean there was a circuit board examining your results. I mean digital - as in it used your finger.

I placed the tiny needle, safely trapped in a plastic sheath, against my forefinger. "With a quick stabbing motion," read the leaflet, "prick the skin." I did so. I suppose the best thing I could say about the experience was that it was a different kind of pain to the brain-piercing horror of the nasal swab. *shudders*

The leaflet continued, "Milk three drops of blood from your finger." I had to pause for a moment. "Milking" blood isn't high on my list of super-funtime activities. Nevertheless, I persisted and managed to spill just enough of the red stuff into the provided capsule.

What was the next step? I looked at the leaflet. "PTO"

So I grabbed the leaflet, flipped it over and stared vacantly at the blood-stained mess.

Ah.

There were many reasons - so I am told - why the finger-prick tests weren't widely rolled out. There was significant cost, the risk from sharps was hard to manage, and people simply didn't like cutting themselves to bleed. It didn't matter how much more accurate the test was - if you can't convince people to take it regularly, it isn't worth it.

Also, it was messy.

Would a whizzy digital service to accompany it have helped? Perhaps a video from a friendly face with a reassuring accent to calm your fears? Gently smiling as they sliced into their fingers? Probably not. People would have just ended up with blood-soaked iPhone screens.

Ew!

Suppose a digital design team has to support a policy which charges people money every time they do a thing. Let's say driving a car across a bridge. There's all sorts of cool tech that you could use in order to make the payment process as simple as possible. Perhaps numberplate recognition tied to a credit card? Or a simple registration process and a push notification? Nice! Do lots of user research and make it as easy as possible. Hurrah!

But…

What if the payment is to discourage use of the bridge. Perhaps the policy owners are worried about damage, pollution, or some other negative thing. Their goal is to reduce usage - by any means necessary.

Does that mean the team should make the process deliberately difficult?

A team might decide that it makes sense to make a service which is hard to use. No mobile-friendly page, a huge form to fill in, unrealistic timeouts, all the things designers usually fight against. Maybe even make the service break every few days?

Rather than using the monetary cost as a disincentive, the service's lack of usability could be the disincentive!!

This is, of course, a deliberately silly thought experiment. Generally speaking, Government wants to make it easy for you to give it money. And there are usually easier ways to change behaviours.

The private sector often places these sorts of barriers in place. Phone lines are "experiencing higher levels of calls than usual" and have dozens of impenetrable options because having a human answer your query is expensive. So it's hard to do.

If you've ever seen "this page looks better in the app", that's usually because the app makes more money, or was an executive's pet project. So a business puts up interstitials to prevent users from doing what they (the users) want to do.

Why do budget airlines make it so hard to do anything on their websites? Perhaps because they generate more revenue if people turn up to the airport and have to pay for seats and baggage?

Anyway, the next time you're stuck trying to complete something that should be simple, and are cursing the fools who designed the process, please remember that Hanlon's Razor is only a suggestion. Some badly designed processes are malicious.

The security guard smiled wearily at me, "It happens to everyone!" She said. Which, I'll admit was of small comfort.

Work had taken the (sensible) decision that our entry cards weren't secure enough. In order to gain access to the building we needed to present our card and type in a 4 digital personal PIN number⁰. Only then would the gates open.

I shuffled back to the long line of people setting up their PINs and texted my boss to let them know I was stuck at security.

I got to the front of the queue, swiped my card, and typed my new PIN on the keyboard numpad. Rather than my date of birth, or the first few digits of π, I chose a pattern - 2684 - nice and easy to draw. No way would I forget that¹!

I wandered to the gate, swiped my card, and confidently punched in the patter on the PIN pad.

A red light flashed and a buzzer sounded. I let out an audible swear word. The people behind me, who were also late for their meetings, stared at the absolute cretin in front of them. A moron who forgot a 4 digit number in the 10 seconds it took to walk from one end of the reception to the other.

The guard wandered over. "It happens to everyone. Look at the numbers," she said.

And so I did. The PIN pad had been installed with a privacy shield so that miscreants couldn't see what your fingers were doing. It had the side effect of blocking tall people like me from seeing the pad. So I crouched and looked.

This was the number pad I had to use to get through the door:

But this was the number pad I'd used to set up my PIN:

FFS!

There's an excellent explainer of how the touch-tone telephone got its button order - and another on why it is different from the calculator layout.

In the end, I just set my PIN to the ambidextrous 4564².

Except, it turns out, streaming services.

They use alphabetic keyboards. Worse, each one has a unique layout!

Want to search for that movie staring that guy who was in the film with that one who does the adverts for that thing you like? Here's the keyboards on the various streaming services I have:

Amazon Prime

Three rows. A-M. N-Z. Then a full number row 1-0.

Apple TV

A 6x7 grid. All lower case letters, with numbers appearing directly after the letter z.

BBC iPlayer

A 10x3 grid for the letters, and a separate number pad which goes 1-4, 5-8, 9-0 - unlike any other number pad I've seen.

Channel 4

The same letter grid as Amazon, albeit in upper-case. The space and delete are at the top, rather than the bottom.

Netflix

(I'd learned how to take screenshots from my FireStick by this point.) The same A-F grid as Channel 4 - but space and delete are reversed.

UKTV Play

The same A-F grid as C4 and Netflix. But this adds a "Clear" button. Oh, and numbers start from 0, not 1.

ITVX

The same A-J grid as the BBC, but space is bigger and delete is somewhere else. Also, the numbers are on the top row like a QWERTY keyboard!

BTW, does anyone need a # & £ button on a search?

Others

Feel free to supply your own screenshots for whichever streaming platform you prefer.

WTAF?!

What I don't understand is why they're like this. I assume each of these services have conducted extensive user testing to see what layout people prefer, and which is faster for the average user, right? Do none of their users have a smartphone? Do they turn away from their smart-TV and handwrite letters with a quill and ink?

I get that an A-Z layout is more logical than QWERTY. But surely there are more people who use QWERTY than not? Perhaps the technophobes generate more support calls? Maybe it's just too complicated to ask users if they want a choice of layout?

But this is my plea to anyone who has to display a virtual on-screen keyboard. Just use QWERTY!

Warning, not for the faint of heart.

The thing is, I can't adequately describe why I - and many others - find it so disturbing.

In all my years of reading English, I've never found a font which slants backwards. I'm used to italics so there's no reason it should seem weird. And yet... it's like the uncanny valley of fonts. Something in my brain just screams "WRONG".

I examined the page to see if it was some kind of fancy CSS transformation. But, no. It appears to belong to a font family called "recline".

Thanks. I hate it.

What's the most unsettling font you've seen in the wild?

I'll admit, this weirded me out. Surely 4 is just far too short. Right? I think almost every 2FA code I've seen has been 6 digits long. Even back in the days of carrying one of those physical RSA fobs, 6 has been the magic number.

But why?

A 2FA code is meant to prevent a specific class of problem. If an attacker has got hold of something you are (your username⁰) and something you know (your password), you are still protected by something you have (your phone). Whether your second-factor is an app generating unique codes, a SIM card receiving SMS¹, or a cryptographic enclave producing signed transactions - it doesn't matter. The attacker can use your password but won't get the unique second code.

Suppose you received a 2FA code that was a single digit. Is that secure enough?

I think most reasonable people would say that wasn't secure. An attacker has a 10% chance of guessing the 2FA. If the system allows for a couple of retries before locking them out, they've got a 30% chance of getting in.

Similarly a 2 or 3 digit code probably doesn't provide sufficient protection.

A typical bank card PIN is 4 digits. So an attacker has a 1 in 10,000 chance of guessing. That might be slightly better as bank PINs usually don't allow repeated digits, palindromes, and a few other combinations.

I suppose that if an attacker had compromised tens of thousands of credentials, and the service allowed for a few incorrect entries, it is statistically likely that they might be able to compromise a few accounts if they were only protected by 4 digits.

As 2FA codes get longer, they begin to reach the limits of what humans can remember. Yes, I know you have an excellent memory - but not everyone does. And I know your fancy 2FA app automatically copies and pastes the codes - but not everyone does. We have to work to what the average user is capable of at a minimum.

I think most people would find it annoying - if not impossible - to remember a 10 digit one-time password.

If you're copying a code from your phone to type into your laptop, there's probably an upper limit on what people will be prepared to do. No one is going to manually transcribe 128 digits. And, if they did, they'd likely introduce several errors.

So the industry has seemingly settled on 6 digits. I've ranted before about the lack of standardisation in the OTP specification. But all of them seem to allow 6 - 8 digits.

I suspect 6 is the standard because that's what the original RSA SecurID tokens used by default.

An attacker would have to be incredibly lucky to randomly guess a 6 digit code - literally a one-in-a-million chance². Even if they had multiple retries, it's still statistically unlikely.

Once I logged in using my 4 digit code, I had full access to my account. But if I wanted to make any changes, I had to wait for another 2FA code to be sent. So I guess the effective length of code was actually 8 digits. Which seems excessive 🤣

Thoughts from the community

I asked my Twitter buddies for their wisdom:

Alex Hudson

@ealexhudson

@edent Depends on retry/lockout policy? 4 digits is enough for a bank card, but there is a physical token involved there - is the account as valuable as that, though?

Gut feeling is 6 digits is right for most circumstances though...

---

Rob Styles

@mmmmmrob

Replying to @mmmmmrob@edent 10,000 combinations is plenty to prevent guessing, and making the code longer doesn't add any additional protection if the message/device is compromised.

Making the code longer makes the usability exponentially worse when the code has to be re-keyed.

---

Ryan Cullen

@artesea

@edent Assuming just three retries before the code expires, 3 in 10,000 doesn't sound too bad. Also easy to remember whilst switching between the messaging app/notification shade and the app/website wanting it. I find with 6 I need to go back and forth. Worse with alphanumeric.

---

James Seconde

@SecondeJ

Replying to @mmmmmrob@mmmmmrob @edent For these sorts of reasons, this is why @VonageDev 2FA (Verify) lets you choose between 4 and 6 digits

---

Rhidian Bramley

@RhidianB

@edent Zero digits. More user friendly and secure to send a hyperlink with a single use time limited encryption key. No heed to compromise usability vs security. Win win.

---

Chris Hill-Scott

@quis

@edent Design System says 5 digits: design-system.service.gov.uk/patterns/confi…

On Notify 2% of attempts are miskeyed – people with dyslexia probably disproportionately affected.

4 would be better – used by Airbnb and Uber – but you need stronger technical measures in place to prevent automated attacks.

---

What do you think?

Tess Rinearson

@_tessr

Is this a phishing attempt? Goes to "githubverification.com" and asks for username and pw

(if so, it nearly got me!)

/cc @github pic.x.com/jgt4oNvjF2

---

In the replies, you’ll see lots of techbros saying “this is why you should switch on 2FA people!!!”

Except, and I hate to bring accuracy to a technical discussion, that’s not how 2FA works!

A second factor allows a site to better authenticate you. It does not help you identify the site.

If you log on to fake-bank.com, the scammers will immediately take your username and password and send it to real-bank.com – the fake bank will then ask you for your 2FA token. That could come via SMS, email, an authenticator app, or even post. Then the fake site uses your real token and logs in as you.

Game Over.

There is almost nothing you can do to authenticate that a site is legitimate.

• Any information that you can request from the real site can be proxied to the fake site.
• The green SSL padlock means nothing for validity. Anyone can get one.
• The top result on Google is invariably an advert for a scam site.

Realistically the only thing you can do is look for “out of band” verification. What’s the URL stamped on your credit card? What’s written on the welcome letter sent by snail mail?

None of these are infallible – and they can all be manipulated by a suitably determined attacker.

The best defence is to use a password manager. I recommend the open source Bit Warden.

A password manager stores your passwords. But it also stores the web address of site’s login page. If you visit githud, the password manager won’t prompt you to use the login details for github.

Defence in depth. Use 2FA to prevent attackers masquerading as you. And use a password manager to prevent fake sites masquerading as real sites.

What About YubiKeys?

No. I'm not a big fan of YubiKeys. In theory, a hardware token can help with this. You register the token with the device and it spits out a code only to the correct site.

But it has significant downsides.

• Cost. The average YubiKey is £50. There are a few around the £30 price point. That’s a huge expense given the small number of sites that support them.
• Usability. Buy a device, register it, install the app, configure it, find the setting in the website, enable it, hope your machine has the right sort of USB ports, press the button at the right time. Take 10 minutes to watch a normal user try to set one up - then tell me if you think this is a good solution.
• Convenience. My YubiKey is on my keyring. My keys are in my coat. My laptop is not near my coat. Given how often I need to log into things, it means adopting a significant change of habit. Or leaving my YubiKey plugged in all the time. Which leads to…
• Risk. YubiKeys have no password lock of their own. At least my crumby Android has a fingerprint lock to prevent people getting my 2FA tokens. But if you’ve stolen my laptop and the YubiKey is plugged in, then you’ve got the keys to my kingdom.
• Support. WebAuthn is a great standard – but only a few sites support it. While it is good at protecting a handful of sites, I encounter it so infrequently that I regularly forget how it works.

While a WebAuthn request can't be proxied - there's nothing stopping a fake site from asking for your token, then rejecting it and asking for a separate factor.

If fake-github.com said "Hmmm we're having problems with our WebAuthn backend - please use a one-time code from your authenticator app for added security" would you be fooled?

WebAuthn and hardware tokens are probably the future. And they’re probably the best way we have to verify site legitimacy. But they’re also currently a poorly supported usability disaster.

Stay safe out there.

A few months ago, I was involved in a medical questionnaire launch. Before it was released, I had several people send me polite (and not-so-polite) queries as to why it was taking so long. "I could build that in five minutes!" was the common refrain.

Some people, dissatisfied with our progress, did just that. They quickly built their own questionnaires and opened them to the public. That's the joy of the Web - you don't need to ask anyone's permission to publish. Some of the questionnaires were pretty good - but many were not.

Here are some of the problems I found with things which people launched in five minutes. This is non-exhaustive, and lightly edited for anonymity. But they were all genuine problems that were found. The problems broadly fell into two categories:

Security

• Submitted medical data over http.
• Allowed anyone to look up a previous submission.
• Stored medical data on a shared webhost in the USA.
• Any user could edit another user's medical information.
• Invasive advertising tracking on the form.
• No mechanism to prevent duplicate submissions.
• Loaded 3rd party JavaScript without SRI.
• Vulnerable to SQL injection.

Usefulness

• Asked for information which wasn't medically relevant.
• Didn't ask for specific information which was medically useful.
• Questions assumed users understood medical terminology.
• Used free-text boxes which another form control would be more suitable.
• Poor accessibility meant visually impaired users couldn't reliably answer some questions.

Just Five Minutes

It's really easy to build a form in 5 minutes. What takes the time is doing it right way.

Most of the time, getting the wrong answer quickly is not as useful as getting the right answer slowly.

There are a few things that really annoy me from a usability point of view. Some of these are the fault of the author, some the publisher, some the eBook format¹, and some the reader app.

Firstly, what's the point of a footnote? This is a rough and untested bit of user-storying...

• As a reader, I want to look up a reference to a quoted work. So that I can see if the author is being accurate.
• As a reader, I want to know a little more about the subject being discussed. Because I'm interested in this specific topic
• As a reader, I want to understand what a newly introduced term means. So that I can understand the rest of the book.

But, there's also another user, who often takes precedence:

• As an author, I want to show that I have done my research. So that critics can't use that to question my credibility.
• As an author, I want to add more details which don't fit in the main body of the text. Because I hate deleting text and my editor told me to take it out.
• As an author, I want to add an explanation for some jargon or terminology. So that readers unfamiliar with the subject don't feel excluded.

(This isn't a thorough bit of user research. It's just me noodling around. Feel free to add your own, well-researched, stories.)

Types of footnotes

In my experience, there are four types of footnote:

1. A citation. Anything from something a bit useless like "(Smith 1984.)" to a fully semantic "Baucherel, Kate, Blockchain Hurricane. Business Expert Press. 2020".
2. A long note. A diversion which, while interesting, is not relevant to the main argument. Think of it a bit like a Director's Commentary on a DVD.
3. A short note. Usually an explanation of an TLA² or technical term.
4. A comedy footnote³.

Here's my problem / User Need - how does a user know which type of footnote they are encountering?

In the wild

Let's take an example. I'm currently reading "Race After Technology" by Ruha Benjamin". It's an excellent book. But I am unsure how I am supposed to read it⁴. (This criticism applies to most books I've read, but this is what I'm currently reading.)

In this example, I click on ¹³ and my ebook reader - KOReader displays a little pop-up at the bottom of the screen.

Before I tap the link - I've no idea what's behind it. And, that's assuming that I know that reference numbers are tappable, and that the tap-target is large enough that I don't accidentally interact with the book in some other way.

Here's another, from the same page: Here the author provides a citation and some explanatory text. How does an author decide what goes in the body and what goes in the notes? How does the user know whether the footnote is a citation or is explanatory?

Finally, again from the same page, there's this: This footnote is so long that the UI pop-up isn't big enough to contain it and displays a scrollbar.

Again, this isn't a criticism of this specific author. This happens on lots of books. The publishing industry seems to have a complete disregard for the user's need.

How do users read? Do they want to click on every footnote link they encounter? Do they expect to read them at the end? Does having a mixture of notes and citations confuse them?

Specification

The ePub specification talks about how to handle footnotes. One of the great things about ePub is that it is based on HTML5. The footnote markup is pretty simple:

<p>
   In that year<a href="https://shkspr.mobi/blog/2020/07/usability-of-footnotes/#ft2f" role="doc-noteref" epub:type="noteref">2</a> there were 67 mills engaged in the manufacture of cotton goods …
</p>

<aside id="ft2f" role="doc-footnote" epub:type="footnote">
   <p>
     2 The manufacturing statistics for 1900 which follow are not those given in the Twelfth Census, but are taken from the <em>Census of Manufactures</em> …
   </p>
</aside>

Most eBook publishers also include a back-link, so that users can easily return to the main text.

The specification doesn't say whether citations should be displayed differently to footnotes.

I guess it would be easy to add class="citation" and have the CSS .citation::before {content="cite ";}

That would allow users to differentiate between ^{cite 2} and ^{note 2}.

Usability

There are some "technical" usability issues here. How the user interacts with links, whether the note appears as a pop-up or inline, and the process of returning to the main text.

But I want to talk about the cognitive issues at play. When footnotes can contain anything from a citation to essential background information, the user is forced to break from the flow⁵ of reading - often in the middle of a sentence. This is a problem in both paper books and electronic books.

I'm still stuck on the user needs. It seems to me that most footnotes are for the author's benefit. If the text is that important, it should be in the main body. If it isn't, leave it out.

Abbreviations can be dealt with inline using the <abbr> element. You should be able to to tap on the TLA to get the definition.

As for citations? Isn't that what HTML links are for? Just link directly to the document in question as part of the running text.

Would it make life easier for reader to include a fully semantic citation inline? Take this scrap of imaginary text:

There are many websites about Shakespeare. As is discussed in Eric M. Johnson's Opening Shakespeare from the Margins (2017), 187-205 Springer International Publishing The Shakespeare User the use of open source software has seen...

Which can be represented by the HTML code:

<span itemscope itemtype="http://schema.org/ScholarlyArticle">
   <span itemprop="citation">
      <span itemprop="author" itemscope itemtype="http://schema.org/Person">
         <span itemprop="name">
            <span itemprop="familyName">Johnson</span>, 
            <span itemprop="givenName">Eric M.</span>
         </span>
      </span> 
      <q>
         <a itemprop="url" href="https://doi.org/10.1007/978-3-319-61015-3_10">
            <cite itemprop="headline">Opening Shakespeare from the Margins</cite>
         </a>
      </q> 
      (<time itemprop="datePublished" datetime="2017">2017</time>)  
      page: <span itemprop="pagination">187-205</span>. 
      <span itemprop="publisher" itemscope itemtype="http://schema.org/Organization">
         <span itemprop="name">Springer International Publishing</span>
      </span>. 
      <span itemprop="publication">The Shakespeare User</span>.
   </span>
</span>

CSS could be used to show / hide various parts of the citation until interacted with. A reader familiar with hypertext should know that visiting a link will take them to an external site. No need for footnotes at all!

Obviously, I haven't done any proper usability studies. Nor have I spoken to any users other than myself.

But surely we need a better way of making footnotes and citations better for readers?

What's next

There have been many attempts to get a <footnote> element into HTML. I think there's some value in adding semantic information to a document. But I probably think that the <aside> element and <cite> element are good enough.

Perhaps the W3C Publishing Group needs to fund some user research to see if ePub notes and citations work well for most users.

Perhaps authors need to realise that linear text is a relic of paper-based publishing and that hypertext affords new ways for a reader to journey through a text.

Or, perhaps, I need to learn how to read without getting distracted.

My mobile network provider sent me this message:

I clicked on the link, and got this error message from their website:

The error is caused by the trailing full-stop.

Remove the full-stop and the page loads.

There are four potential culprits here...

Virgin Media's Web Team

Should their website handle stray punctuation at the end of a URl?

Most webservers can be configured to take users to the page the server thinks they intended to go. This is mostly useful behaviour, but occasionally falls foul of the common DWIM (Do What I Mean) problems.

Even if the web team don't redirect, they should notice the elevated number of 404 errors and investigate the cause of it.

Whisper Systems' Signal App

My SMS app should parse URls without trailing punctuation. It is rare that a URl will deliberately end with a punctuation mark. This issue has been raised with the team before.

Apparently, according to the developers, this is a problem with Android's native library

Android's URl Parsing Library

The same question as above. Android has a built in Web URl regular expression. There are reports that it is inconsistent in the way it parses URls.

A URl which ends with a full-stop is valid. There is a semantic difference between /page and /page. or /?id=a and /?id=a.

But the RFC doesn't take into account how humans actually communicate.

If I send a message saying "visit example.com/go, then example.com/next!" do I really mean for the , and ! to be part of the path?

I can't find any evidence of Google testing this feature with users, nor a test suite to show people what URls are and are not matched.

It appears that the library only includes the punctuation if it is the last character in a string.

Virgin Media's Marketing Team

These are who I think the real villains. Software has bugs. Part of any communications strategy is to test your messages to see whether they work. Not just as calls-to-action, but whether they actually work.

In this case, Virgin should have tested their message on a range of handsets and popular SMS apps. If they had tested the end-to-end journey on Android, this wouldn't have happened.

What next

There's no point me asking Virgin to fix this. They have dreadful customer service and seem content to have a crappy user experience.

It's not Signal's fault that Android's parsing is buggy. Both Signal and Telegram greedily gobble up the . and treat it as part of the link. Interestingly, WhatsApp doesn't. I assume WhatsApp uses its own library.

So, I've raise a bug with Android where - no doubt - it will languish untouched for the next hundred years.

I have a Linux laptop with built in speakers and an external monitor with speakers. The laptop connects to the screen via HDMI. I have my Linux desktop set up for dual screens.

If I drag a window from one screen to the other, I want the sound to follow the window.

Is this possible?

A bit more detail

When I have YouTube running on my monitor, I want the sound to come from the monitor.

When I have a video conference running on my laptop screen, I want the sound to come from the laptop's speakers.

POP!_OS running Wayland gives me the option to set the default audio output.

Some apps - mostly video conference apps - let me select the audio output of that app. So I can set the output to my headphones or screen or laptop or Bluetooth speakers or the misconfigured Smart TV next door.

Is this actually what I want?

My laptop usually has a wired headset and a Bluetooth headset connected - along with the built in speakers. What I really want is for my webcam to notice what headset I'm wearing and route audio to that. If I'm not wearing headphones, notice which screen I'm looking at and route audio that way. Except when I'm playing music on one screen and working on a document on a different screen.

Butler. I want a human butler to surreptitiously readjust the sound output based on my subconscious whims.

Most of the time, it's as simple as making the text a lightish colour, and the background a darkish colour. But all that fails when you use transparencies in images.

Here's a quick example. Using the GitHub app in dark mode, I visited a repo which used a transparent image as an illustration:

Yikes! I can't read most of that text, even if I whack up the brightness on my screen.

Here's what the image looks like in an editor:

As you can see, the majority of the background is transparent - indicated by the traditional checkerboard pattern - with occasional blocks having a background colour.

Background transparency is be great if you can guarantee the background colour! But the web is wonderful; browsers are intended to be the user's agents. This means you can substitute the page's design with your own. Change fonts, make things easier to read, flip colours, whatever you want.

To account for dark mode - or any user changed interface - you have two main options:

1. Remove transparencies
2. Stroke outline

The first is obvious - just put in a background colour. The second is a little harder to explain.

Text can have a colour - fill:#000 paints the text black. Text can also have an outline - known as a stroke. stroke: #fff; stroke-width:2px; paints a 2 pixel white border around the text.

Here's an example SVG (I've mocked up the transparent background):

My suggestion is - put a high-contrast stroke around any object where you expect the background colour to be shown through a transparency.

I wasn't being truculent or disobedient. I simply hadn't seen their message. And it was all Google's fault.

At work, we use Google's G-Suite. It's a brilliant set of email and document tools. It also contains two incompatible messaging apps.

When I started using it - the chat product was "Hangouts". At some point, Google released "Chat" - their latest product - and encouraged users to upgrade. So I did.

But Chat and Hangouts are built by two different team who - I can only assume - hate each other only slightly more than they hate their users.

If Alice is on Hangouts and sends a message to Bob on Chat - Bob receives the message.

Similarly, Bob on Chat can message Alice on Hangouts. Hurrah for interoperability!

But this lulls users into a false sense of security!

If Alice on Hangouts sends a message to Bob and Carol in a group, problems occur. Users on Chat won't see group messages from Hangouts.

Similarly, Hangouts users won't see group messages from Chat.

OK. So perhaps the answer is to use both Chat and Hangout simultaneously? Well, that's a recipe for disaster because each app sends its own notification for the same message.

So you end up with multiple notifications for the same message across different apps.

Unbelievably, this is by design!

Group conversations in classic Hangouts or Chat can't be viewed or replied to in the other service. Group messages are not compatible between the two services.

We recommend recreating any group conversations users want to continue in Chat.

Chat and classic Hangouts interoperability

I can't understand the sheer contempt for your users which would lead to this situation.

Don't worry - there is a solution! It's easy. Just convince every single person in your organisation to switch! And then to change their app! And uninstall the old one! And then disable the chat Hangouts from the browser! And learn an entirely new UI! And lose all of your old conversations! And lose the ability to chat with external users.

Simple!!!!!!! ARHGGHGHGHGHGHGH!

Google initially said they'd force everyone off Hangouts in 2019. They didn't do that. They've now said All remaining classic Hangouts G Suite users will be moved to Chat in "late 2020".

I smoothed things over with my colleague. We realised that we'd each missed messages from each other - and that cancelled out any ill-will.

We both agreed that Google is a bit shit and that in the future we'd send any important messages over Slack.

Take a look at these checkboxen:

If you click on this label, nothing happens.

If you click on this label, the checkbox will toggle

This is important. Tapping on tiny squares is hard for lots of people. Whether they have visual impairments, motor issues, or just a dirty touchscreen. You should give your user the biggest possible target area to interact with an element.

How is this possilbe? Here's the code for the second checkbox.

<input type="checkbox" id="c1"/>
<label for="c1"> If you click on this label, the checkbox will toggle</label>

The text is wrapped in the <label> element, which is linked to the <input>'s id attribute via the for attribute.

The reason I bring this up, is because recently I had to sign up to the Miro website. I tried to click to agree to their terms and conditions, but I couldn't click the text.

Let's take a look at the code behind it: The <input> element has the CSS property set to display: none;. It is invisible to the user.

The <label> is an SVG image. The text is not part of the label and thus is not clickable.

I have no idea why they've done this.

You can use CSS to make ridiculously beautiful input elements. But Miro's replacement for a dull square is... a slightly different dull square!

Default: Miro:

Even if that square is a vital part of their brand guidelines, it would have been simple to put the text inside the <label>.

Designers and developers - please take a moment to make sure your labels are fully clickable. Thanks!

Terence Eden is on Mastodon

@edent

Hey @MiroHQ!
That's not how you use the label element. I should be able to click on the text to toggle the checkbox. pic.x.com/HPQFSycltw

---

Miro

@MiroHQ

@edent Noted! Passed along to the team. Thanks for surfacing.

---

Theories

Why do this?

Matt Bluefoot

@MattBluefoot

@edent ... I mean... it is still WRONG, obvs. Just trying to work out how they arrived at that mess.

---

Matt Bluefoot

@MattBluefoot

@edent Oh... you know what? If occurs to me that clicking on the “Terms” link inside a label which also wraps a checkbox might result in the checkbox being checked through event bubbling, even though the user only clicked there to read the terms, not accept them.

---

Nope! If you click this link, the checkbox will not toggle

I like having a large mouse cursor. I find it easier to see on my large monitor, especially when sat at a safe distance. But, if I use a large cursor - I can't see the tool-tips underneath it.

Annoyingly, Apple don't include the larger cursor sizes when taking a screenshot. So you get the joy of me pointing a camera at my screen like some kind of troglodyte sharing memes on your neighbourhood's Facebook group.

Broken Behaviour

What does this tool-tip say?

That's from "Finder" the default Mac file system app.

Expected Behaviour

With the "normal" size icon, I can see what the text says.

Usability pervasiveness

OK, it's impossible to test every combination that a user might choose. But it really feels like bits of MacOS are hostile to accessibility changes.

It is impossible to change the system font size. That top menu is fixed at a tiny size. If you want a more readable font - tough.

Apple knows best.

Tool tip size

You can increase the font size of tool-tips with this obscure command-line incantation:

defaults write -g NSToolTipsFontSize -int 20

Restart the app and you'll get a larger font!

Which is still obscured by the cursor.

Report this bug

Apple have known about this bug for at least 10 years.

Apple knows best.

It's well known that we Brits love our separate hot and cold taps - but I'd never seen anything like this before! Why are the taps so far away from the spigot?

This is the Principle of Proximity.

One of the oldest principles of human-computer interaction is that things that are close together on the screen are seen as related. (Similarly, users view as related those things that are the same color or shape, that move or change together, or that reside within an enclosure, such as a box.)

Closeness of Actions and Objects in GUI Design

It applies to websites and sinks!

In Mismatch, Kat Holmes describes how design can lead to exclusion, and how design can also remedy exclusion. Inclusive design methods—designing objects with rather than for excluded users—can create elegant solutions that work well and benefit all. Holmes tells stories of pioneers of inclusive design, many of whom were drawn to work on inclusion because of their own experiences of exclusion.

Part manifesto, part manual. This is an excellent overview of inclusion and design. More than just about usability, it goes to the psychological heart of why we get upset when we can't use things.

It's a little short, and doesn't go into a huge amount of technical detail. But it more than makes up for it in sheer quality of advice.

One to read whether you're designing apps or policy.

The first time a customer holds your product in their hands should be a moment of joy. Something to reinforce the notion that they have been wise with their investment.

I'm going to walk through an example of a poor unboxing usability, in the hope that it will show you what not to do.

This is the Three Home Signal Box - it is a femtocell to improve reception at home.

It arrived in a fairly anonymous postal sack, and has an easy to open box.

Knowing that the audience aren't likely to be technical, it comes with some reassuring messages on it. Good!

This is, of course, a lie.

The instruction card is a little boring, but does the job.

Just plug in the cables! Easy. There's even a picture guide. So, I followed the instructions, plugged in the cables, but nothing worked.

I checked the packaging. There was a warning sticker on there - obviously added after the box was printed. Revisions to packaging in response to customer feedback is sometimes necessary. A slightly ugly hack, but better than nothing.

I checked the flashing lights on the unit. Then re-read the instructions. The very last troubleshooting tip is check that the SIM card is inserted.

What SIM card? This was all that was in the box.

I retrieving the postal sack from the bin. This is what I found inside:

I've no idea why there's a spare PAYG SIM there - or how many people get confused and put the wrong SIM in. But I do know that this is a crappy way to bundle necessary equipment.

Ideally, this is what Three should do:

1. Pre-install the SIM.
2. If they can't, put the SIM in the same box as the device.
3. Make sure the instructions tell people to plug in the SIM before they attach the cables.
4. Stick some instructions on the back of the box, perhaps.

To be fair, once I'd found the SIM, it did tell me what to do with it. Well, I say that. It didn't tell me that I had snap the SIM from the holder. But the instructions on the card's packaging say "For more instructions, see the getting started guide." The same guide that doesn't mention you need to install the SIM!

There is, of course, nothing on the Three website relating to this problem.

Usability testing isn't finished until the user has the product in their hands and have successfully set it up. I've no idea how may dejected customer service agents are giving an exasperated sigh of "and have you put the little green card in the box?"

Make it easy. Make it right.

Do You Want To Phone A Friend?

A popular website asked me to confirm my phone number. It "helpfully" pre-filled the country-code with +1. And proudly displayed the Stars and Stripes.

Except, of course, the USA isn't the only country to use +1 - our friends in the Great White North also use +1.

Thanks to the North American Numbering Plan, a full 25 countries or territories use +1. From Anguilla 🇦🇮 to Turks and Caicos Islands 🇹🇨. OK… their flags look pretty similar! But they're obviously different from 🇺🇸!

Canada 🇨🇦 and Jamaica 🇯🇲 have very different flags - and climates - but they both use +1.

I suspect that the website designers were expecting people to look at the flag and realise that it didn't represent their home country, and then change it. However, for the majority of +1 countries which aren't part of the United States, it looks a little crass.

My home country, the United Kingdom 🇬🇧, uses the +44 code. As do Guernsey 🇬🇬, Jersey 🇯🇪, and the Isle of Man 🇮🇲.

The UK is comprised of Scotland 🏴󠁧󠁢󠁳󠁣󠁴󠁿, England 🏴󠁧󠁢󠁥󠁮󠁧󠁿, Wales 🏴󠁧󠁢󠁷󠁬󠁳󠁿, and N.I. (with a more complicated flag status!)

People can have a complicated relationship with flags. Your glorious banner of home might be my symbol of a conquering despot.

Flags change. Afghanistan's flag has changed 4 times since the year 2000.

Some flags are not recognised by other countries.

Flags represent countries, states, territories, and pirate ships 🏴‍☠️ - but they do not represent international dialling codes!

Lingua Franca

Lots of countries speak English. But the majority of them don't have 🇬🇧 as their flag.

Indeed, lots of people in the UK don't speak English. So using a 🇬🇧 to indicate language choice may be confusing.

If you are in South Africa, there are 11 official languages. Does 🇿🇦 represent Xhosa, Zulu, Afrikaans, English…?

Flags are for golf courses ⛳, motor-sports 🏁, and for Pride 🏳️‍🌈 - not for representing languages.

Do You Have A Flag

I'm pretty sure the law requires me to share this video…