Of course, necking a few shots every time you update your website isn't great for your health - so is there another way?

Click the "🥴 Drunk" button at the top of the page and see what happens!

These are a relatively simple set of CSS rules which you can apply to any site in order to simulate inebriation.

(I may have changed these since writing the post. Check the source for the latest version.)

First, monkey around with the fonts. This sets all the lower-case vowels to be rendered in a different font - as discussed in "targetting specific characters with CSS rules":

/* Drunk */
@font-face {
    font-family: "Drunk";
    src: url("/blog/wp-content/themes/edent-wordpress-theme/assets/fonts/CommitMonoV143-Edent.woff2") format("woff2");
    /* Lower-Case Vowels */
    unicode-range: U+61, U+65, U+69, U+6F, U+75 ;
    size-adjust: 105%;
}

The rest of the characters will be rendered in the system's default Cursive font. Characters will also be slanted. The first character of every paragraph will be shrunk:

:root:has(input#drunk:checked) * {
    font-family: "Drunk", cursive;
    font-style: oblique -12deg;
    text-align: end;
}
:root:has(input#drunk:checked) p::first-letter {
    font-size: .5em;
}

Next, use the child selectors to rotate and skew various elements. While we wait for CSS randomness to come to all browsers this is a simple way to select various elements:

:root:has(input#drunk:checked) *:nth-child(3n) {
    transform: rotate(2deg);
}
:root:has(input#drunk:checked) *:nth-child(5n) {
    transform: skew(5deg, 5deg);
}
:root:has(input#drunk:checked) *:nth-child(7n) {
    transform: rotate(-3deg);
}

Make the entire page blurred and saturate the colours:

:root:has(input#drunk:checked) body {
    filter: blur(1px) saturate(2.5);
}

Make any hyperlink harder to click by having it gently bounce up and down:

:root:has(input#drunk:checked) a  {
    animation-name: bounce;
    animation-duration: 4s;
    animation-direction: alternate;
    animation-timing-function: ease-in-out;
    animation-iteration-count: infinite;
}
@keyframes bounce {
    0%   { margin-top:  0px; }
    25%  { margin-top:-10px; }
    50%  { margin-top:  0px; }
    75%  { margin-top: 10px; }
    100% { margin-top:  0px; }
}

Does this really simulate drunkenness? No. It is a pale simulacrum. What it is, however, is deliberately inaccessible to the majority of people.

How does it make you feel using the site in Drunk-Mode? Does it frustrate you? Do your eyes hurt due to the garish colour scheme? Do you keep missing the thing that you try and click on? Are the words so hard to read that it takes you extra time to do anything useful? Will you recommend this experience to your friends and family?

I've written before about cosplaying as being disabled. Strapping on a pair of Glaucoma Goggles will give you an idea of what a visual impairment is like. But it won't give you the experience of living that way for months or years.

You should test your stuff with people who have cognitive impairments or physical disabilities. Find out how usable your site is for someone lacking fine motor control or for those with learning disabilities. Pay disable people to take part in usability studies. Integrate their feedback.

Faffing around with CSS will only get you so far.

To geeks, it is a compelling attraction. Something cool and esoteric lives in there! All sorts of goodies to explore and configure.

To normal people, it is invisible. Normal people don't go pushing random icons on their apps because computers are fragile and may break if you do the wrong thing.

To me, it is a sign that product managers are a menace and must be stopped. A hundred thousand icons vying for your attention have been stuffed away because no one has the authority to prioritise user needs.

As a | user who has received some spam

I want to | easily report it as spam

So that | Google's AI can become ever stronger my inbox is easier to manage

How do you report spam? On the web, it is possible if you're prepared to enter the forbidden lair of ⋮. Click the one nearest the message and you'll see:

But there is no "report spam" button in the Gmail app. Try to find it. I promise you it isn't there.

No, not even behind the door of mysteries which is ⋮. See:

Ah ha! FOOLISH USER!! You thought that you could transfer a mastered skill from one environment to another? You are an idiot. A buffoon. The Eloi at Google mock your Morlock ways.

Here is the report spam button in the Gmail app - hidden in the top ⋮ menu!

And, just for completeness, here's what the top ⋮ on the web has.

Why?!

Why do the Monkey-Punchers at Google have such scorn for its users? Is it because their illegal monopoly means they don't have to compete for users? Do their perverse internal politics only reward employees for adding features, not removing them? Perhaps the web team and the app team are engaged in holy war around a doctrinal schism over icon placement?

We may never know.

OK, but why?

Why do the overflows on the web have icons but on the Android app they're barren?

Why is the order of the options completely different on both?

Why are the names different for the same functions?

We can only assume that the web team are Montagues and the app team Capulets.

What is going on?

Moving a UI from the big screen to the small screen is difficult. Some options aren't relevant in either context. Some labels are too big. Some prioritisation needs to happen. I accept that.

But users only have limited cognitive plasticity. They have a mental model of how a UI works and they expect it to be reasonably consistent.

I keep making the same mistake. Whether I'm on the web or app, I always go to the wrong option! This makes me feel like an idiot. I have a hundred apps to use, each with subtly different UIs - I can't be expected to keep them all straight. But I do expect the a common set of paradigms if the services are under the auspices of a single company.

Why are there two ⋮ menu options? I think the top relates to the conversation whereas the second relates to the specific message? But maybe I'm wrong.

Two out of three ain't bad

I lied earlier. There's a third way to report spam.

On the web, hover over one of the mysterious small icons - the ones with ridiculously thin lines and low contrast - and you'll be rewarded with this:

Make it make sense!!

At least, that's what I thought. A few days ago my little cybernetic helper suddenly started speaking!

Not exactly a Shakespearean soliloquy, but a hell of a lot better than trying to decipher BIOS beep codes.

All of my electronics beep at me. My dishwasher screams a piercing tone to let me know it has completed a wash cycle. My kettle squarks mournfully whenever it is boiled. The fridge howls in protest when it has been left open too long. My microwave sings the song of its people to let me know dinner is ready. And they all do it with a series of tuneless beeps. It is maddening.

Which brings me on to Star Wars.

Why does the character of Artoo-Detoo only speak in beeps?

Here's how we're introduced to him⁰ in the original script:

                THREEPIO
        We're doomed!

The little R2 unit makes a series of electronic sounds that 
only another robot could understand.

                THREEPIO
        There'll be no escape for the Princess 
        this time.

Artoo continues making beeping sounds

There are a few possibilities. Firstly, perhaps his hardware doesn't have a speaker which supports human speech?

Artoo demonstrably has a speaker which is capable of producing a wide range of sounds. So perhaps he isn't capable of complex symbolic thought?

This exchange from Empire Strikes Back proves otherwise.

INT.  LUKE'S X-WING - COCKPIT

Luke, looking thoughtful, suddenly makes a decision.  He flips several 
switches.  The stars shift as he takes his fighter into a steep turn.  
The X-wing banks sharply and flies away in a new direction.

The monitor screen on Luke's control panel prints out a question from 
the concerned Artoo.

                LUKE
            (into comlink)
        There's nothing wrong, Artoo.
        I'm just setting a new course.

Artoo beeps once again.

                LUKE
            (into comlink)
        We're not going to regroup with 
        the others.

Artoo begins a protest, whistling an unbelieving, "What?!"

Luke reads Artoo's exclamation on his control panel.

It could be that Artoo can't speak the same language as the other humans. C-3PO boasts that he is fluent in over 6 million forms of communication¹ - so it is possible that Artoo can speak but just can't speak out language².

Speech synthesis is complicated but playback is simple. Artoo can play recordings. His memory could be stuffed full of useful phrases which he could blast out when necessary. So perhaps he only has limited memory and doesn't have the space for a load of MP3s?

Except, of course, his memory is big enough for "a complete technical readout" of the Death Star. That's got to be be be a chunky torrent, right?

The only reasonable conclusion we can come to is that R2-D2 is a slave³. Sentient organics apparently hold some deep-seated prejudices against robots and "their kind".

The Star Wars universe obviously has a version of this meme:

Which brings me back to my home appliances.

This isn't a technology problem. Back in the 1980s microcomputers had passible speech synthesis on crappy little speakers. Using modern codecs like Opus means that pre-recorded voices take up barely any disk space.

The problem is: do I want them to talk to me?

• When I'm upstairs, I can just about hear a shrill beep from the kitchen. Will I hear "washing cycle now completed" as clearly?
• Would a manufacturer bother to localise the voice so it is in my regional language or accent?
• Is hearing a repetitive voice more or less annoying than a series of beeps?
• If the appliance can't listen to my voice, does it give the impression that it is ordering me around?
• Do I feel a misplaced sense of obligation when inanimate objects act like living creatures?

It is clear that the technology exists. Cheap home appliances have more than enough processing power to play a snippet of audio through a tiny speaker. But perhaps modern humans find something uncanny about soulless boxes conversing with us as equals?

I went to type in my 2FA code on a website - but no numbers appeared on screen. Obviously, I was an idiot and had forgotten to press the NumLock button. D'oh! I toggled it on and typed again. No numbers appeared. I switched to another tab, my numbers appeared when I typed them. So I was reasonably confident that my keyboard was working.

I swapped back to the 2FA entry and tried again. Still nothing. Then I tried typing the numbers using the number row on my keyboard. My 2FA code appeared.

WHAT IN THE SAINTED NAME OF ALPHONSE CHAPANIS IS GOING ON?!?!?

Developers often use JavaScript to "improve" the standard features of HTML. For example, using <input type="number"> has some accessibility concerns and using inputmode="numeric" is great for showing a number key board on mobile, but not much else.

So a developer wants a reliable way to make sure a user can only type numbers. Fair enough.

There are two ways to do this - a right way and a wrong way - using KeyboardEvent.

One way is to listen for the character being sent from the keyboard - known as the key.

The other is to listen for the button being pressed on the keyboard - known as the code.

A good demo of this is at keyjs.dev - play around with it to see what keyboard buttons your browser can detect.

When I press 7 on the top row of my keyboard, the key is 7 and the code is Digit7.

But when I press 7 on my number pad, the key is 7 but the code is Numpad7.

The JavaScript on the website was rejecting any key code which wasn't a "Digit"!

Perhaps I am a weirdo for insisting on both having and using my numpad? Perhaps developers need to test on something other than MacBooks? Perhaps JavaScript was a mistake and the Web would be better without it?

Either way, don't be like that website. Let users type in using whatever keys they like.

Google used to have some beautiful logos for its apps. Each had a distinct shape, style, and colour. Then, someone decided that they all needed a consistent visual language. And this mess was born.

*sigh* I get it. I really do. Brand is a thing. Users often use visual heuristics to identify similar groups. Having each team go wild on an icon design doesn't always reflect the professionalism and consistency that you want to project. The logos aren't awful - but I find them a little boring. Not the worst sin in the world. Though that's only half the problem.

In Google's Android, they've decided that - for consistency - all icons must be firmly encased in a white circle. It makes everything look clean, consistent, friendly, and...

...oh.

I apologise for getting old. My visual acuity isn't what it once was. When I'm staring at my phone, with its screen caked in fingerprint grease, on a juddering bus, after a long day at work, all I want is a quick way to identify the app I want to use.

Like most people, my brain has evolved to take mental shortcuts. It looks for a distinct shape and colour to identify things. I simply can't do that with modern Android's adaptive icons. They all look like white circles with a splodge of colour in the middle.

A few years ago, I wrote about fixing Android's circular icons. Sadly, I don't have the skill to produce my own icon pack. But using the open source Iconeration I was able to manually set my icons to be beautifully inconsistent.

With a glance, I can immediately see which is which. Do I care that they're not all aligned perfectly? Nope!

I've got a high-resolution screen, I want high-resolution artwork. Look at that Firefox icon! It is gorgeous! It isn't a pale, flat, blob - it has texture and uniqueness.

Phones used to be wild and unique - now they're all boring black rectangles. User Interfaces used to reflect the aspirations of their designers - now they're just a bland corporate mediocrity.

I hope, one day soon, the fashion pendulum will swing back and interfaces can become interesting again. Until that day, I'll use Iconeration to make my phone easier and more delightful for me.

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!

Simple. I love it.

It got me thinking about other things which have "zero interfaces". Once they're set up, they just keep quietly working.

The most obvious is a thermostat. If set right, it keeps the heating off in summer and on in winter.

Bank rounding is a fairly modern invention. Every time you spend less than a whole pound, the remainder is swept into a savings account. Spend £3.76 on a muffin? The bank pays the merchant and then transfers 24p to your savings.

Taxes - for most people - works the same way. If you have an ordinary job, tax codes and payments are automatically deducted from your pay cheque. You don't have to think about anything.

Downsides

Anyone who has been sat in an office conference room will know that the lights go off when they don't detect movement. Not ideal if you're sat on a video call! So you end up waving your arms around like a fool.

Just because the inside temperature is warm, it doesn't mean that it feels warm. So heating occasionally needs a boost.

Taxes are usually calculated yearly - but paid monthly. So starting a new job can occasionally result in the automated systems thinking you're earning more - or less - than you should. Which usually means either waiting until the end of the tax year, or making a manual intervention.

What's Next?

How do we build more "set and forget" solutions? What are the limits of zero interface products? Should users be able to override the "Breathe-o-Smart" settings?

If people don't have to constantly interact with something, will they forget that it is there? What consequences does that have?

I tried sharing a website using Google Chrome for Android. I hit the share button, and a panel popped-up from the bottom of the screen.

Hmmm. It didn't have the share destination that I wanted. It was early in the morning - when I'm not at my cognitive best - and I was stumped. There is nothing on this screen - other than the icons - to tell me how I can interact with it. There's no scrollbar, no handle, no "more" icon, nothing.

Let's talk about doors for a while.

I'm sure you've all come across a door with an ambiguous handle. This is what usually happens:

perry

@SloanPerry

when you push a pull door and the person behind says "you need to pull" aye cheers lad sure next plan was to start lifting from the bottom

---

Ideally, all doors would look like this:

Even if you don't speak the language written on the doors, the physical nature of the handles tells you what you can do with them. A flat panel can only be pushed. The protruding handle is designed to be pulled. This design feature is known as an "affordance".

If you're involved in design, at any level, I urge you to read the classic book "Design of Everyday Things". This is what it has to say on the subject:

How can design signal the appropriate actions? One important set of signals comes through the natural constraints of objects, physical constraints that limit what can be done. Another set of signals comes from the affordances of objects, which convey messages about their possible uses, actions, and functions. Where do we grab it, which parts move, and which parts are fixed? Affordances suggest the range of possibilities, constraints limit the number of alternatives. The thoughtful use of affordances and constraints together in design lets a user determine readily the proper course of action, even in a novel situation.

(Emphasis added.)

Let's go back to that accurs'd Android panel. I tried swiping it up - that's what I've learned most panels do in Android. But it did nothing. So I gave up. I didn't feel like battling with my computer to achieve a simple task. I just assumed that Google had chosen a set of default options and I was not allowed to stray from them.

As I went to dismiss the panel, my thumb slipped transversely. Nudging the row a few pixels to the left. The fucking thing was a horizontal slider!

I felt like a bit of an idiot. And that violates the unwritten 0th law of robotics - no computer interface shall make a human feel stupid.

I vividly remember being pissed off 12 years ago at the iPhone's inability to delete podcasts. It turned out that, once again, you had to magically know that swiping a podcast revealed hidden buttons.

The thing is, it's easy to add an affordance. Here's my crappy paint attempt showing a couple of options:

Either an arrow to let the user know there's more to the side (maybe even give it a jaunty animation) - or a scrollbar to show how far through a list they are. I'm sure you can think of a dozen better ways to represent a scrollable area than literally nothing!

Apple's solution is to bisect the final icon in a row, to indicate to the user that there's more available.

That's a cute way to do it. But there's evidence that Apple are slowly undoing their great usability work in the name of elegance.

Modern design is so beautiful to look at - but an absolute nightmare to use. You either need to use trial an error on every element, or hope that someone else can tell you what you need to do.

Flat, minimalist, clean, material - whatever you want to call it - is an annoying antipattern. Computers are here to make life easier for humans. Removing affordances is just a nasty thing to do to your users.

Most programming languages have the concept of relational operators. How does variable X compare to variable Y?

If we want to ask if X is less than or equal to Y, we write X <= Y. Which is a bit weird, because Unicode has a "less-than-or-equal-to" character: ≤. But because there's no button for that on a standard keyboard, we use a hacky solution of jamming two characters together.

In the R language, the assignment operator is <- this is because programming keyboards used to have a ← button on them. That button has gone from modern machines, so we make do and mend.

There are some programming fonts which contain ligatures to automatically convert these characters (although this makes some people very grumpy).

Unicode includes ⩶ (U+2A76) and ⩵ (U+2A75) as distinct glyphs. So why are we still hitting the = key multiple times like savages?

This leads to the deeply weird situation where "⩵" ≠ "==" and absolutely no programming language that I know of will let you use the correct Unicode characters!

(Except, of course, Raku - which made this change based on my suggestion.)

Ideally, we need programming languages which support Unicode symbols as first class characters, and keyboards with a hundred more buttons.

Anyway, I found some bugs! I'm a big fan of the Sci Fi Interfaces blog. It details the Human Computer Interaction design of the imagined future. It has primed me to pay attention to the interfaces in films. Look, you have your hobbies and I have mine!

Early on in the film, a crew-member is watching a video message from home:

Let's focus on the date in the lower left corner. The future doesn't believe in ISO8601. So we get the American date format.

03)(29)(2047

Ew! What's with those brackets? I assume that's the 29th of March in the year 2047. The timestamp in the bottom is hours, minutes, seconds, and milliseconds.

A few frames later and we cut to a shot of the crewmate watching the video on a tablet computer (futuristic for 1997!) - but there's an issue. The movie we're watching is in an aspect ratio of 23:9 (CinemaScope). But the tablet is in 4:3. Just like the iPad! So the entire UI has been changed.

But what's the date in the lower left corner?

ZOOM! ENHANCE! ROTATE!

29)(03)(2047

OK, it looks a bit more like 29)(05)(2043 to me - but, either way, the date has flipped to the UK format of Day, Month, Year.

Later on in the movie, the crew watch the "captains [sic] log" with a completely changed UI.

The date format is back to American, but now has colons as separators. And the time no longer has milliseconds. Because why would you need an accurate timestamp for an official record?

Did you notice the media controls on the first playback screen? ⏹️ ▶️ ⏩️ ⏪️ But, in the second interface, they're words - "play, stop, pause". A completely different order, and different functions!

Later on, the crew try to blow up the ship. Because why not? The countdown is in minutes and seconds. Separated with a period. Helpfully saying "Minutes" below the minutes section.

The explosives - which are different to the self-destruct - have yet another time format.

HH:MM:SS although it just says "seconds" above the display.

The bomb also has a "manual" mode:

Notice that the lower buttons' interface on this one is in white and red. Whereas the one above is all white. Why are some of the reds on the left, and one on the right? Surely on critical systems like this, users will value a consistent design language.

If those are touch-screen targets, they're very close together. That looks pretty easy to mistakenly touch a button. Not something you want on explosives!

Event Horizon is a gory horror film. But I think we can all agree that the real horror was in the user interface design.

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!

We both want to see the bills, and we don't want to rely on the other forwarding us an email, or sticking the PDF into a shared folder.

Terence Eden is on Mastodon

@edent

Couples of Twitter! How do you handle emails for "joint" things?

Like utility bills, hotel reservations, and other domestic accounts.

📊

---

Email comes to only one: (240)
240
Joint email address: (46)
46
Something more complex: (26)
26

---

Moving house gave us the opportunity to change all our joint billing accounts. Here's our slightly convoluted setup.

1. We bought a new domain name. As all good projects start.
2. I set up an auto-forward catch-all address. So "anything @example.xyz" is immediately forwarded to my email and my wife's email.
3. We use BitWarden password manager - that lets us share passwords with each other.
4. One of us signs up to a new service as servicename-2019@example.xyz, generates and securely shares a new password, and we both receive the confirmation email.

Why are we doing this?

• One of us could die. It would be extremely annoying to be locked out of an account during a period of bereavement.
• We're jointly responsible for most of these things. It seems silly to split accounts arbitrarily.
• If my phone breaks while we're on holiday, my wife still has a copy of the hotel reservation.
• Neither of us want yet another email account to check.

Reasons not to do this

• If the domain gets hacked / breaks / is blocked or disabled - we'll have lost access to everything.
• We might get divorced. Decoupling things could be harder. Or one of us could lock the other out.
• Surprises and presents are still done on our personal accounts.
• Hard to send from a joint email without setting it up specifically.
• It makes us look like one of those weird old couples who have a joint Facebook account.

What other people do (A.K.A. Market Research)

Caroline Jarrett

@cjforms

Replying to @edent@edent I've answered for me, but my parents only have one email address so they go with 'joint email address'.

---

Carrie Kleiner (Barclay)

@ThisIsCarrie

Replying to @edent@edent Cc or forwarding. But like many others we don’t always share bills-related emails, we just deal with them and mention it if it’s relevant or important.

---

Samathy Barratt

@Samathy_Barratt

Replying to @edent@edent Comes to one address - if its a thing we both need to care about(Travel plans, mostly), the receiver forwards it to the other person.

We don't really consider bills emails to need the attention of both of us. We'd tell each other if an email does.

---

Carol ⭐️

@CarolSaysThings

Replying to @edent@edent Poorly is the unhelpful answer. Most bills/utilities go to my email, but for trips we split the admin. So Thom books the hotel, I do train etc.

Can’t think of how to make it better other than a joint email, as when we’ve given people both addresses, they still always email me.

---

How do you handle this?

Leave a comment in the box. One comment per couple, please :-)

You press the button in the middle of your screen - and it makes everything better! You push that button and a taxi arrives, or a pizza is delivered, or your photos are backed up, or you fall in love, or you learn a language.

Life is rarely that simple - and apps are rarely that smart. But let's look at what comes next.

Anticipatory User Interfaces

The most boring app I have is Tado - it controls my central heating. I never need to use the app! It sits in the background requiring no interaction. When it sees I am home, it sets the temperature accordingly. If I'm away overnight, it doesn't bother turning on the hot water. If it sees me travelling home, and it is cold, it pre-heats the house.

Other than my initial set up, I don't have to press any buttons. The app becomes the perfect Butler.

(To clarify - this isn't about learning. Most people's lives are too chaotic for a machine to adequately learn. We very rarely all fit the 9-to-5 grind, with 2.4 kids, and brunch every Sunday. It's one of the problems the Nest thermostat has with its "learning" feature - and why people disable it - our lives are too noisy.)

The app anticipates what you need and delivers it without asking.

Boring is Beautiful

I don't want your app. But if I have to have it - I certainly don't want to interact with it. I don't want your notifications cluttering up my screen. I know your brand-manager harps on about "engagement" and "eyeballs" - but I don't care. Prove to me that you are useful by never interrupting me.

There are so many things competing for our attention. Too many things. It's really easy to make your app noisy and engaging. It looks great on a PowerPoint when you can show how often people open your app, I get that. But every time I get a perky email from my smoke-alarm telling me how wonderful it is, I want to rip it from my wall. Do your job and leave me alone.

So, dear app designers, refrain from sending constant, pleading emails in the vain hope that your click-through-rate will inch ever-closer to perfection.

No. Refine your service so that it can work silently. Let the absence of interaction be a selling point.

Encouraged by my friend Tom Morris's blog post, I picked up a YubiKey NEO for £50. It implements the FIDO U2F standard.

Sadly, the YubiKey is substandard and frustrating to use. Here's what I found.

First impressions count for a lot - and it is pretty disappointing. What you see in my fingers is literally all Amazon sent me. A fob and a bit of card. No instructions, no welcome pack, no getting started guide. What does the circle do? How do I use it with Android?

The plastic is cheap and doesn't look like it would survive in a pocket full of keys. In short, it looks like a freebie USB stick - not an expensive piece of security hardware.

OK, let's get started!

Linux Set Up

Do I need to do anything special to get it working on Ubuntu? Who knows - the Yubico pages literally just point to StackOverflow.

A quick lsusb shows ID 1050:0116 Yubico.com Yubikey NEO(-N) OTP+U2F+CCID - so it seems to be detected correctly. So that should be fine, right?

When I push the button on the YubiKey, it spits out a 44 character password - all lower case characters. It's the same every time. Shouldn't this be unique, like a normal one-time code?

Firefox Woes

Fine, let's follow the steps needed to set up Facebook with a security key.

Ah... Turns out that U2F support will be coming to Firefox in Version 57 which is scheduled for release in mid-November.

Chrome Test

OK, let's switch my browser to Chrome temporarily. That Firefox page alerted me to Yubico's demo server at https://demo.yubico.com/ (which isn't linked from anywhere on their main site). With that I was able to confirm that the key worked. I guess. I touched the button on the key, it autotyped the password and I was logged in. Yay?

I don't really understand what I did or why it worked.

GitHub

The GitHub help pages give a range of scary warnings about setting up 2FA.

There are 12 steps to setting up a U2F. Step one is setting up 2FA via an app - which is a 10 step process.

The short version is:

1. Go to https://github.com/settings/two_factor_authentication/configure
2. Give the key a name.
3. Press the button on the key.

That's it! Pretty simple.

After logging in with a username and password, you get this screen:

I pressed the button and IT WORKED!

Android

OK, so this key has NFC and therefore should work with Android. But how? There's nothing on the Yubico website.

I held the Neo against my phone, and it popped open the default web browser.

I don't understand what this screen is telling me. Apparently I have been "successfully authenticated" - but with what? I haven't typed in a password or given a user name.

That serial and identity - should I keep them safe? Private? Are they dangerous if they get leaked? Do I need them backed up?

Oh, great, yet another app I have to install, configure, and update.

The app

The app is also substandard. The Android version only supports American and German keyboards.

The company encourages you to contribute new layouts to their open source project. But it, like the app, hasn't been updated since 2015!

Back to GitHub

So I tried GitHub via the Chrome browser on Android.

Nope. Just wouldn't work. I held the key to the phone, the app copied the 44 character password, I manually pasted it in. And I got this error, repeatedly. My 2FA codes from Authy worked fine.

I don't know how to fix that.

The other app

There is another app! It isn't linked to from the default page you get when you hold the Neo against the phone. That would be too easy, apparently. After clicking around on the Google Play store, I found Yubico Authenticator

Yubico Authenticator allows you to use a YubiKey NEO to store OATH credentials (TOTP and HOTP supported, as used by Google, Microsoft, Dropbox, Amazon and many more) used for 2-factor authentication.

Aha! I think this is what I need. And it has been updated recently. Well, May 2017.

Again, it is as ugly as the last app. Compare it to Authy which uses icons to help you find the code you need, strong colours to remind you which service you're using, and large numbers to help when copy-typing.

Which of those apps would you rather use every day?

There's no way to copy credentials from another service - so I had to manually set up all 21 accounts again. That was a fun way to spend an afternoon.

1. Scan the QR code of the service.
2. Give it a memorable name.
3. Tap the YubiKey to your phone to store the token.
4. Repeat.

To get tokens out:

1. Tap the YubiKey to the phone.
2. The Authenticator opens up.
3. Scroll to find your code (hard without icons or colours as a guide).
4. Tap a tiny square to copy the code.
5. Swap back to your app and paste it in.

Honestly, I thought I'd be at the login screen of the app, then just have to tap the YubiKey to the phone and have it do it automatically.

Why did I think that? Because that's what the website promises!

LastPass

I use LastPass to manage all my passwords. If I want to use U2F with it, I need to pay them $2 a month for their premium product. LastPass is the only company I'm aware of who charge extra to enable security features.

But I can still use the YubiKey code generator app. Just not the key itself...?

I AM SO CONFUSED!

PGP

I'm one of those daft people with a PGP key in active use. I set it up four years ago as a 4096 bit RSA key. This fifty-quid hunk-of-junk can only handle 2048 bit keys, like it is from the stone age. Why? Who knows.

If you can be bothered, you can generate yet another PGP key and store it on the device. There are no official apps to do this on Android, so you'll need to find yet another third party app to trust. I used OpenKeyChain.

Of course, if you lose the physical hardware you lose the key. There's no obvious way to extract the private key from the YubiKey. I mean, there may be a way - but good luck finding clear documentation.

What's the point?

I get security. I understand the benefits of 2FA. But I struggle with the YubiKey. It's a pain to set up and a pain to use. The apps are outdated, ugly, and underwhelming.

I had thought that this would be a "single use" solution - but it isn't. On a laptop I have to plug it in and touch the button, on Android I have to use NFC to open the app, find the right account, tap to copy, then paste the code manually.

There's no step-by-step guide for new users. It's all trial and error.

For fifty quid, I could buy a cheap Android phone and use Authy for free.

The kicker? When it is plugged into a laptop, a green LED flashes constantly. Urgh.

If you want normal people to adopt security best practices, the experiences need to be easy to use and beautiful. The YubiKey is hard and ugly. Which is a great shame.

In this clip from "Back To The Future" we get a brief glimpse at the controls for setting the destination date:

Ok, we can forgive Brown for not sticking to ISO-8601 - that is the eminently sensible Year-Month-Day-Hours-Minutes-Seconds format - the standard was finalised in 1988, a few years after he allegedly built his time machine.

But why are the "Destination Time" LEDs red - the universal colour for stop/warning? The "Present Time" LEDs are green - not great for men with colour-blindness.

AM/PM are positioned before the hour marker. WTF?

Generally speaking, humans read top-to-bottom. So having the "Destination Time" label in the middle of two displays could prove confusing.

There appears to be no "Seconds" setting - is this level of precision acceptable?

Let's move on and take a look at the sequel - the imaginatively named "Back To The Future Part 2":

OMG! In this latest revision, the AM/PM labels have swapped position!

It's unclear if this is a conscious design choice, or whether the labels have fallen off and been carelessly repositioned. This could lead to the unwary user arriving 12 hours before or after they expect. That is not a great user experience!

Finally, let's take a look at Part 3

Well isn't this just fanfuckingtastic!? The AM/PM has switched again! What utter contempt the designers are showing for their user.

It's obvious that the LED lighting isn't sufficient for either use in bright sunshine - or for viewing from the driver's position.

The label is "Departed Time" - rather than "Time Departed" which would keep it consistent with the other two labels.

And, if that weren't bad enough - take a look at the "Month" section. Yup, it has gone from being JAN/FEB/MAR etc - to a two digit representation!

Oh, and apparently, there's no support for TimeZones. FFS...

Seriously, if you are planning on designing a time machine, please don't take any advice from this nutcase!

During the recent episode "I Found You", the Jessica (the Vampire) places a phone call to Sookie (a sort of telepathic fairy... it doesn't really matter...)

Sadly, Sookie has dropped her phone. Notice the obvious mistake?

Take a look at the dichotomy 'twixt the screen and physical buttons. The touch screen interface places the (red) Decline button on the left, and the (green) Answer button on the right. But the physical buttons are the opposite way around!

See here.

Humans very quickly build up muscle memory. They ignore what's in front of them and instead rely on learned behaviour. If you've ever had a new TV remote which puts the power button in a different position to your old remote, you know the frustration!

Consistency is the key to providing good user experiences.

Of course, the fact that the Kyocera X-tc doesn't have a touch screen really distracts from the mise-en-scène.

Why, yes, I do have a life. Thank you very much for asking.

But it's getting obvious that Android has a serious design problem - even with the gorgeous new "Holo" theme for ICS.

The issue is one of consistency. Users have limited cognitive surplus and often rely on muscle memory to perform tasks. So anything which forces applications to behave in a similar way is often highly appreciated.

One thing which is bugging me about the Galaxy Nexus and ICS is the placement of the "Menu" button. This button is used to open up a program's options, or access its functions. It always used to be a physical key on the device - now it has become virtual.

A virtual key isn't of itself a huge problem - but the placement of it is.

In some apps it appears at the top of the screen, in others it's on the bottom, and on some the button appears in the virtual button bar. Take a look at these examples:

In Twitter, the menu button is on the virtual button bar

In the browser, the menu button is on the top.

In Gmail, the menu button is at the bottom of the screen, but not on the virtual bar.

In the stock SMS app, the menu button starts at the bottom...

...but then jumps to the top!

So every time you go in to an app, you have to search for the menu button and remember where it is for that app for that particular context.

What a total annoyance. You can't just remember once and get used to it - you have to check on every single screen of every single app. No reliance on muscle memory is possible. All very frustrating.

Now, Android isn't alone in this. I remember the last time I used iOS being frustrated with the number of different ways there were to delete an item in stock apps. Sometimes there was an icon (although rarely the same one), sometime you had to swipe, sometime you had to tap-and-hold.

It's a symptom of a lack of strict guidelines. I've worked on a project where - due to no one person being in charge of UI - we ended up with six different icons to represent delete - one of which was identical to the "close window" button!

It's one of those tiny little stumbling blocks which gradually builds up into the user resenting the interface. This is the sort of mistake that professionals in the UI / UX field should not be making.

I stumbled on this fantastic quote from Greg Parker:

Greg Parker

@gparker

A programming language is a user interface for developers. Language authors should learn from HCI principles.

---

When I first started learning C++ (back in the bad old days) I was convinced that any 1st year student could design a better programming language. One which behaved in a sane fashion without a lot of legacy cruft. In many ways, PHP is that programming language. It's simple, logical, and works without having to know lots of esoteric computer science.

I see API design in the same way. Most of the APIs I come in contact with were obviously designed by the original developer for the original developer - with no thought of those who would come after her. Often, they're designed for one specific internal usage, reluctantly opened to the public, and never updated to account for how people actually use them. Oh, and you can forget about decent documentation!

One hackathon I went to a few weeks ago had a Developer Relations employee stand up and say:

Who wants to use our API? It uses SOAP - sorry. If you want documentation - come see me because it's not on the website. Oh, and it's read only. Let me know as soon as possible because it takes 6 hours to approve your API key.

This is madness. Developers are human too! They need some HCI love between them and their APIs.

So, here are my hastily scribbled thoughts on what an API needs at a minimum to entice the busy developer.

I don't think any of these are Earth-shattering, but it's amazing how many APIs fail to meet even these basic requirements.

Easy Access

• Don't make me register, set up an account, or fill in a load of forms - I just want to see what I can do with you before I make a commitment.
• Do give me an Apigee console - or similar - so I can see for myself what's happening.
• Don't give me absurd key signing requirement - I should be able to call the API from a web browser just by typing stuff in.
• Do make it as easy as possible for me to get started - get your CEO (or similar) and see how long it takes her to set up an account & launch her first call. If it's more than 5 minute, go back to the drawing board.

Example Code

• Don't tell me what your API can do - show me a few cool calls to start me off.
• Just because you love Ruby, doesn't mean everyone does. Show examples in a variety of languages.
• Provide examples of code which won't work and explain why.
• Comment your code. It may be obvious to you what "choes=17|L" means, but it may not be to me.

Documentation

• This is possibly the most important area.
• I need to know what I can do, how I can do it, why I should do it a certain way, and what response to expect.
• For. Every. Single. Function.
• If you can't document your API, people can't use it.

Full Enumeration of Responses

• Tell me the full range of response I can expect.
• A good example is Twitter's "retweet_count", the documentation used to imply that the response would always be an integer. However, it would occasionally respond with a string of "100+". Naturally, this meant developers would write code expecting ints which would fail whenever a string was encountered. If you can't tell me what responses to expect - how can I code something which handles those responses correctly?
• What error codes are you likely to throw?

Variety of Response Language

• Yes, you love XML. Guess what? I don't!
• The customer is always right. If the customer (developer) wants JSON, XML, PHPobject, or just plain text - you should give it to them.
• It's the API designer's job to make life easy for developers - so reply in whatever formats the developer wants.

Human Readable Response

• Developers are humans! Yes! It's true! And they can't all pretty-print JSON in their heads. Give them something they can read without resorting to external tools.
• The Wikipedia API is a brilliant example of this. They have a human readable response for their API calls.
• Unless you have a very good reason not to - all your responses should be pretty-printed. It helps with debugging and makes life just that little bit easier for a struggling developer.

Human Readable Requests

• Developers are humans! Yes! It's true! And they can't all remember every little acronym in their heads. Give them something they can read without resorting to documentation.
• What's easier to remember "gnxID" or "getNextId"?
• Keep your parameters consistent.

Unchanging

• Consistency is a virtue. If you have two similar APIs (say, search & read) they should take the same parameters and produce identically formatted responses.
• If you have to change the way your API responds, or the way it accepts request, that's fine - but use versioning so that developers don't have to update their code if they don't want to.
• Never deprecate anything! Once an embedded device has had its firmware burned, it's unlikely to ever be updated. If people or services rely on you, it's simply unacceptable to kill something off. Remember, not every developer or end user can update their software.

Simplicity

• Perhaps the most important of all HCI commandments - Keep It Simple.
• Don't engage in a needless dance where developers have to take several steps to do a single action.
• Try to explain what you're doing in a single sentence. If you can't - it's probably too complicated.

Libraries

• I'm sure you're very proud that your community has created some libraries - but they're not good enough.
• Want people to use your API? Provide libraries in a wide variety of languages.
• Update and support those libraries.

Detailed Errors

• It's not enough to say an error has occurred. Say why it has occurred.
• Error codes must always be accompanied by human readable error messages.
• Do you really need to throw an error? Can your API take a "best" guess at what the user was trying to do? Be generous in what you accept.

Feedback

• Your API sucks. Accept that.
• Provide a mechanism where people can feed back what they think is broken, poorly implemented, missing, or just plain confusing.
• Discuss the feedback openly. See what the rest of your community thinks.
• Act on feedback. If a feature request hasn't been acted on after 6 months, you've probably failed.

So What?

There is nothing new in this post to the seasoned developer. But as Matt Gemmell reminded me recently - some people just don't know the basics.

If you're interested in making your API useful for developers, you have to treat it like any other product. You have to consider HCI factors, you have to do product testing, design, and planning.

Your API is a product. Treat your developers as you would your most profitable users.

Further Reading

There are many books on this subject - the two I recommend are: Basics of the Unix Philosophy (free). The Design of Everyday Things (paper or ebook).

So it was with great mirth that I went along to a BizSpark event a few weeks ago. Microsoft were going to be showing off their latest "innovation" - Windows Phone 7.

I went along expecting to hate it and, instead, found myself curiously drawn to it.

Take a look at the emulator for an interactive demo.

I played with the demo hardware and software and had my expectations blown away.  I'll be honest - I expected crap.  I had horrible memories of the stylus oriented Windows Mobile 6.  The phone which would display an hourglass if you had the temerity to receive a phone call while playing solitaire.

Windows Phone 7 (WP7) was a million miles away from the old Microsoft experience.

Pros

The user interface is refreshingly simple and fun to use.  It's like nothing else I've tried before and I really think that Microsoft has outclassed both Android and Apple.

Pushing so much information to the homescreen really makes you want to use your phone constantly. iPhone only does this half-heartedly and Android does it without much animation or UI consistency.

App Store.  One excellent feature of the MS app store is the "Try Before You Buy" model.  Rather than a developer putting out a free, limited version and a "pro" version they can publish a single app.  They can restrict the features and functionality of the "demo" version until the customer makes the purchase. Or, after a set period of time, the demo version can become non-functioning. Or have reduced function.  Brilliant.

Gaming on this device will be huge. It looks like it will be simple to port games from the Xbox to WP7 - that gives it a great competative advantage. Tie in Xbox Live (or whatever it's called) and you'll get gamers buying the same game twice - once on the console and once on the phone.  The 3D power of the phones was stunning.

Cons

There are some serious shortcomings in the Windows Phone 7 vision of the future which Microsoft urgently need to address.

• Expand the development options.  If you want to write for Windows Phone 7, you'll need Windows installed on your computer.  Given that Android allows you to develop on Windows, Mac and Linux, it doesn't make sense to make developers buy a new operating system.  Especially as iPhone development is tied to Apple.
• Open it up.  I love the idea of integrating my phone with my Xbox live account - but I don't have an Xbox! Open it up so that my Wii or PS3 gaming experience can be pushed to the homescreen.
• The same goes for mail and IM - don't restrict it just to Exchange and MSN.  Openness is hard for Microsoft, but it will attract more customers to the platform.
• Have a firm, public roadmap for enhancements which all manufacturers stick to.  Android is currently being stifled by manufacturers like HTC who refuse to update the software on their customers' devices.
• Revenue share for developers needs to be better. At the moment it's the same 70/30 split being offered by Android and Apple.  It needs to be lower for two key reasons.

1. Attract developers to the fledgling ecosystem.
2. To avoid any accusations of a cartel.  To have all three major platforms "independently" converge on the same revenue share deal looks suspicious.

Now What?

I've played with the prototype hardware and I'm impressed.  The software is really good. Much better that Microsoft's usual standard.

It has to be.

Microsoft are betting their mobile future on this platform.  Win6.5 failed. Kin failed. They can't afford another high profile failure like this.  Mirosoft are putting their best people on this project and, as far as I can tell, are revisiting their Xbox strategy; SPEND SPEND SPEND.

By the time the phones launch (holiday season 2010) you won't be able to move without seeing an advert.  They will crank up their media machine to 11.  Just like the original Xbox, they will buy their way in to the market with a view that - like the Xbox 360 - the real prize is several years away.

I hope they succeed.  Not because I have any love for Microsoft, but because Nokia, Apple, and Google will all have to raise the quality of their software and hardware to compete against Microsoft's marketing expenditure.

I'm a Linux geek - and I think Windows Phone 7 is the best thing to come out of Redmond in a very long time.