Asides

I like observing people, and listening to them talk about themselves. So, naturally, I love observing user testing sessions. These are some unrelated (to the user test) notes from some recent sessions.

Like listening to audio books because can listen while doing other stuff… washing, walking, cooking, driving.

I’m emotionally blocked on the idea of listening to books. R loves them. But these are exactly the times when I listen to podcasts or, more recently, radio — walking, gardening, cooking, driving.

Have Bluetooth headphones but forget to keep charging them, so mostly use wired headphones.

Wonder if other heavy headphone users face this too. I’ve heard people saying they prefer wired headphones for audio quality, or Bluetooth unreliability reasons. This feels like a much stronger behavioural reason to me.

Love their Pixel phone – fits in the pocket, fantastic camera, clean, no crap apps. But miss lock screen player notification for Spotify app where they could pause, play and rewind (their previous Samsung phone had this).

This is likely a case of the default privacy settings on Pixel not allowing notification content to be visible on lock screen. A point for the privacy vs convenience debate, and the power of defaults.

Prefer browser to apps for news reading. Love the option to open lots of links from home screen in background tabs and then read them. With apps, can only read one at a time, and then FOMO kicks in – whether something more interesting/relevant down the page will disappear by the time they go back to the home screen.

I’m the same. My wife uses the Amazon app. I use the browser. I can search for something on Amazon, then open all interesting results in individual tabs, read them all, switching between them to compare, before deciding which one to buy.

The Pixel doesn’t have a back button, only a back gesture where you swipe from the right to go back. This interferes with swiping between photos. I accidentally close and go back when I need to go to the next photo.

I love gesture navigation. All my devices have it. I also agree with them. I do often, accidentally, close instead of swiping next. Interference with swipe actions on lists and cards is the same. The edge swipe for navigation drawer is just… dead.

It’s also interesting that they don’t know that we can swipe from either edge, left or right, to go back. Gestures are powerful once we learn them, but really hard to discover.

When looking at photos, videos start playing automatically. This happens everywhere these days. On photos, on Instagram, Twitter… can’t quietly check photos.

Attention/advertisement metric driven features spoiling UX. And yes, I hate this too.

Continue reading Asides

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?

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?

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:

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

Biometrics – to identify, not authorise

Biometrics are your username, not your password.

This tweet by Koushik made a lot of sense on first reading. But I couldn’t place my finger on why I agreed with it. Until I read the paragraph below:

All ‘passwords’ should be replaceable. If your credit card gets stolen, you can block it and get a new card. If your Aadhaar number and fingerprint are leaked, you can’t change it, you can’t block it.

Pranesh Prakash in HT

That clinches it for me.

If my password gets stolen, I can reset it to something new, something stronger.

What do I do if my fingerprint is my password? Can’t get a new fingerprint.

Can’t get a new retina, or DNA either. And they’re all a fair bit easier to steal than a strong password.

Sure, use biometrics to identify if you want. But follow the identification with authentication (with a password, or more), before giving that identity any authority.

Android Keyboards in India

Why don’t Android phones sold in India come with Google’s Indic keyboard set up as default?

Specially for phones that don’t ship with proprietary/3rd-party keyboards, doesn’t it make a lot of sense to pre-install Indic keyboard over the default English keyboard?

It’s such a small step, yet can be quite a big enabler for the users (and, even, possibly a differentiator) – using the power of defaults to deliver a better user experience!

A case for splitting up the WordPress mobile app

Venn diagram of readers and writers on WordPress, specially on mobile.
Readers vs writers on WordPress

By integrating ‘reading’ and ‘writing’ in the same app, you’re forcing the bigger user group1 to also confront tools designed for the smaller user group.

On mobile – skewed by design more towards consumption, than creation – I assume the disparity in these two user groups is even bigger.

Having a standalone reader app, allows it to reach a much larger use case – ‘Help people follow, read, discover’.
Compare this to current use case – install it if you…

  1. post to WordPress frequently from mobile, or
  2. love reading in WordPress reader, despite having little use for other three tabs – write, manage, and notifications?!

A really good standalone reader helps plug in a singular user need2 – reading. That need, in terms of following blogs and websites, only rarely overlaps with the other need that the app currently fulfils – writing.

Though it will place it in competition with feed readers like Feedly, it also has 2 unique benefits as well:

  1. Close integration with a writing platform (related posts, comment & like directly from reader),
  2. The abandoned Google Reader audience that just wants to follow and read feeds, without being overwhelmed with magazine interfaces and more.

A good, successful reader mobile app with large user-base will, eventually, help close the RoI loop: suggest (through ‘discover’) other WordPress/Jetpack blogs, creating an incentive (or delivering reward) for creators using WordPress.


  1. One definition of readers and writers:
    – Writers: 7-day active writers – users who posted at-least once a week.
    – Readers: Unique visitors per week – including logged-in users, not-logged-in readers, and from feed readers.
    Another definition (more relevant to determining use case ratios):
    – Writing: Posts /week.
    – Reading: Page views /week – again, including not-logged-in readers, and from feed readers. 
  2. Should some day also write a similar, smaller, post on WordPress Calypso’s interface – how it needs to be split from current two, into three sections. Currently, the ‘write’ and the ‘manage’ use cases are mixed into the same tab, while ‘read’ is in its own.
    Ideally, ‘write’ and ‘read’ – each a singular, frequent use case – should have their own tabs. ‘Manage’ can be in a far-removed tab, or behind a ‘manage’ button. 

Facebook Android app – a UX minefield

I’m sorry. This is yet another post1 on more UX/UI mess that keeps bothering me.

Starting with something I recently started using after 8+ years – Facebook. FB earned a reprieve from the tech press after its change of heart on native smartphone apps. But their Android app is still way below par for what is the primary user interface for vast proportion of their users.

Here are 2 bits that bugged me right away…

FB Issue #1 – In-post touch areas

Touch Targets - Facebook Mobile
Touch Targets – Facebook Mobile

Facebook states that stories/posts that are posted natively get shared more widely to the followers, compared to those posted as links. Yet, the mobile interface makes it practically impossible to click-through to read those very natively-posted long posts.
Continue reading Facebook Android app – a UX minefield

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

Text screenshots on Twitter are a desire path across the wall gardens around content in apps and platforms, and Twitter’s text-dominant streams.

Twitter cards, though a handicap on pure, free sharing of content, provide a way through the content wall gardens. But even the cards don’t provide the break through text clutter that images do. Specially, on 3rd party Twitter clients.

Trello labels – UI delight!

Trello Is Gold
Trello Is Gold!

A few weeks back when Trello announced their unlimited labels update, I wrote a post about how it broke my usage pattern by significantly increasing keystrokes required to label cards.

Just discovered, by mistake, an even faster way to label than I’ve ever used before. Not sure if this is new, or I was just doing it the harder way all this time.

When hovering over a card, or with a card open, just press the number(s) of all the labels you want to toggle. No need to prepend it with ‘L’ at all!

Here’s how the keystroke count (from the earlier post) looks now.

Target: toggle labels 1 & 3.

My old usage pattern: 4 keystrokes (L + 1 + 3 + Enter)

Forced usage pattern after unlimited labels update: 6 keystrokes (L + 1 + Enter + L + 3 + Enter)

New usage pattern: 2 keystrokes (1 + 3)

Simply put, the number of keystrokes to toggle N labels has gone from N+2, to 3N to just N.

I’m not just pleased, I’m positively delighted! My love, respect, and addiction, for Trello just keeps on increasing!