Things I’d Like to Not See Again In User Interfaces

Using Gray as an indicator for Off instead of Disabled

Let me show you an example, from the settings screen on my Xiaomi Mi3 phone, running the Miui user environment:

The Recurring do not disturb time toggle button, as awkwardly as it is named, is clearly indicating with a brighter, contrasting color, that it is set to on. Meanwhile, that Do Not Disturb toggle above it registers to me as disabled: it is grayed out and faint, conform to how functionality being disabled has been indicated since the first Macintosh. Well, guess what, it is not disabled, this is what the designers of this system decided off should look like. If you tap it, it will slide to an on state like the toggle below. I have no idea what an actually disabled toggle looks like in this system.

This color scheme goes against thirty years of accepted standard in visual interaction design, and I am disturbingly seeing it more and more. As interaction designers we are turning every interface into a place where users can’t see what can actually be done, what is available: we’re just asking them to swipe left and right anywhere and hope they discover that something might happen.

This mistake is a very strong indicator a system was never tested with actual users. It’s amateurish, it is a beginner’s mistake. An off button that can be switched to on must advertise it is ready for use, and making it faint and gray does not qualify. Don’t do it.

You see this flaw crop up a lot when a company insists on both having very few brand colors, and that no other colors should be allowed in digital. I had one of those in the last year: it’s primary brand color was a form of red, and only gray and black could be used with it. They wanted us initially to use that red to indicate on or selected. User testing immediately showed what everyone already knew: a control that turns red is actually seen as being wrong or unavailable. We had to have long conversations before we could use a second color, not on that brand palette.

Placing Titles And Buttons So Close Together The Button Takes On The Title

This is a result of pushing minimalism stupid far, and it is just so confusing. And it is all over Android right now.

Example, from Citymapper, an independent app maker:

When I look at the title bar of this screen, I see a control to click to go back to the results screen. That is actually not right, Results is the title of this screen, and that left arrow is to go back to whatever you came from, if you remember what it was. But that is not my first impression, nor the whole gestalt of that title bar, to me it says ‘go back to Results and god knows what it is you are looking at here.’

This is actually not the result of an independent app maker breaking interface convention: Google, owners of the Android experience, actually meant for this arrangement. Here, a screen shot from one of their workhorse apps, GMail:

To me this title bar says: tap the arrow to go to the Compose screen. It isn’t, we are looking at the Compose screen here, and that left arrow goes to whatever.

iOS, while hideous at doing it, actually gets this right:

I see where I am right now, and I see where the arrows are, and where they will take me. Yes, it is a busy title bar, with a lot going on, but I am not left in the dark. The worst is how unnecessary Android’s confusion is; with just one tiny adjustment this could have been so much better:

That’s it. That’s all it takes: moving a label to the right and adding a single line of white pixels. Done. We know what is title and what is control and how related to each other they are (they aren’t). Ok, so the arrow still doesn’t tell you where it goes, but the back arrow on Android has been a messed-up magic mystery tour since its inception anyway.