Tag: Design

Switches and checkboxes

tldr: Say no to switch toggles. Say yes to checkboxes. (Unless you are Airbnb)

Switches

Switches can be ambiguous about their state and their intent.

IRL, they are usually vertical

Which side is on?

The sensible switch: press down to switch on
The sensible switch: press down to switch on
The American switch: pull up to switch on
The American switch: pull up to switch on

Or labeled for choosing modes

switch_mode

They don’t do RTL well

Using an RTL language? Which is the on side—turned to the right, or to the left?

Android privacy settings, LTR language
Android privacy settings, LTR language
Android privacy settings, RTL language
Android privacy settings, RTL language
Nova settings, LTR language
Nova settings, LTR language
Nova settings, RTL language
Nova settings, RTL language

The accent colours on the switch are a helpful clue.

But the colours can’t help when Digital Wellbeing turns on the grayscale mode.

switch settings rtl grayscale
Grayscale turned on by wind down mode. Which switch is ON, again?

But Google uses them

Yes, they do. They also appear to be learning the folly of their ways. Check out these screenshots from upcoming Android 12:

Android 12 switches with explicit state indicators
Android 12 switches with explicit state indicators
Android 12 switches with explicit state indicators
Android 12 switches with explicit state indicators

Checkboxes

If it’s filled, it’s on. If it’s empty, it’s not.

There’s no right, left, up or down. Language doesn’t matter. Colour doesn’t matter. No ambiguity1. No confusion.

rtl_gmail_checkbox
Gmail. No colours for hint. No RTL support on an RTL device. Yet, no confusion. Checkboxes FTW!

Continue reading Switches and checkboxes

Pretty, and pretty confusing

00100dPORTRAIT_00100_BURST20190731161426921_COVER.jpg
Escalator stop buttons at Waterloo station, London

They look pretty, in a industrial chic kind of way.

The idea is interesting—

  • Red action button in the middle,
  • Operation instruction around it—‘Push to stop’, and
  • Warning around that—‘Penalty for improper use’

And the execution is precise—the button’s radius, the width of gap around the button, and the width of ‘Push to stop’ ring appear beautifully aligned.

Every time I pass them, I get attracted to these buttons.

There’s just one problem. On every attempt, I read the message around the button as:

Penalty for push to stop improper use.

The clarity of message has been forsaken at the altar of design.

Humans don’t read in concentric circles. We definitely don’t read inside-out.

We read from left-to-right, or right-to-left, and top-to-bottom.

In an emergency, when this button would be usually used, we follow instinct—read as we usually do. Not as the designer wants us to—inside out, concentric circle at a time.

This button would be much simpler, and not much less prettier, if it just said ‘Push to stop’ up top, and ‘Penalty for improper use’ at the bottom. (My ugly sketch is below the fold)

Continue reading Pretty, and pretty confusing

App Splash Screens – The Good, the bad and the ugly

I’m not a fan of app splash screens. They delay app usage without presenting any useful, or even pleasant, information or interface. To me, they imply either:

  • badly thought out app design requiring loading loads of data before the UI can even be shown, or
  • a pathetic branding attempt that spoils UX by unnecessarily delaying app access

Here’s some thoughts on how to (not) do splash screens in apps:

The Ugly

My pet favourite object of splash screen hatred is the MyFitnessPal app. It has not one, but 2-step splash screen. The first one shows a progress bar, which I assume shows the status of data stored locally on my device.

Myfitnesspal - Splash screen stage 1
MyFitnessPal – Splash screen stage 1

This is followed by another phase of splash screen madness under the Synchronising data title with a rotating symbol this time (so no indication of progress).

Myfitnesspal - Splash screen stage 2!
Myfitnesspal – Splash screen stage 2!

Only after the local data has been ‘loaded‘, and synchronised with the servers, is the user allowed to see the app UI. And despite this, the headline daily dairy numbers they show on landing screen is wrong most of the time. Specially if another app (Garmin Connect for me) has synced exercise calories with MyFitnessPal.

This feels so wrong. Why can’t they just show me the default landing page UI right away, letting me do what I do on most app uses – log food consumption – as quickly as possible. The changes can all be synced in the background.

The multiplicity of logos on the splash screen, as well as several other UI decisions in the app seem to convey that MyFitnessPal has a weak UI/X team being overridden frequently by a politically strong marketing/content team.

Continue reading App Splash Screens – The Good, the bad and the ugly

Trello label upgrade – UI fine tuning

image

Trello, probably my favourite software out there, implemented an awesome new feature today – unlimited labels. Before today, users were restricted to the 6 system defined labels. We could rename them to what they meant for us, but couldn’t add new ones. This handicap was removed today.

Thanks for the unlimited labels, team Trello!

However, this upgrade also breaks a very useful keyboard ui pattern.

Earlier, I could press L (shortcut for label interface), followed by digits (codes) of all the labels I wanted added, and be done with labeling a card in one go.

Now, I need to press L, followed by label digit, followed by enter, for each label separately. Adding 3 labels to a card went from 5 key strokes to 9 strokes. Makes it harder, tiresome.

I understand the need to break the earlier pattern because of the possibility of double digit label numbers. These would make it impossible to decipher if L13 meant apply labels 1 & 3, or apply label 13.

My suggested alternative: reduce the number of custom labels from UNLIMITED to 26. Then you can use alphabets as codes for custom labels. Now L1C could mean apply labels 1 & C, while L13 would continue to mean apply label 1 & 3.

I hope 26+6 labels would be sufficient for most use cases though the teams at Trello would have better data to check the hypothesis.

Would love to hear views of Trello UX, design teams.

And, thanks for an awesome product!