The Importance of Right-Left-Up-Down Standards in Product Design

Yesterday I created a meeting on my Android smartphone (Galaxy Nexus running ICS), filled in all the details, invited a couple of people, and then accidentally cancelled it. I had one of those “WTF just happend??” moments.

So I came back to the screen, and I noticed that the “Done” button was on the right and the “Cancel” button was on the left. I scratched my head, like, literally scratched my head, and tried to figure out why I automatically pressed “Cancel” instead of “Done”. And then I realized. When adding or editing contacts on Android, the “Done” button is on the left, and I do that way more often than creating meetings (which I usually do on my laptop). Below is a screenshot. 

Android right left done button

As you can see, when adding/editing a contact, the “Done” button is on the left, but when adding/editing a meeting, the “Done” button is on the right. This just begs to trick users into automatically choosing the wrong option.

This realization gave me a strange feeling of deja-vu. I spent a minute trying to figure out why. And then it hit me- on Android, I always had a feeling that the “Copy” button jumps from place to place and has no standard. Sometimes it’s at the bottom, sometimes at the top, and every time I need to copy something I find myself searching for the button and finding it somewhere else. 

I thought it doesn’t make sense that the button really is someplace else every time, so I started playing with copying in various scenarios to understand the situation. After a few minutes I got it. When you’re marking uneditable text (e.g. when you’re viewing an email from ifttt), then the copy button appears on the bottom, as the leftmost icon. But when you’re editing text, the copy button appears on the top, as the second icon from the right. Wait WHAT??

See below:

On the one hand, it’s clear that the toolbox for editing text is different from the toolbox for marking uneditable text (e.g. you can’t paste). But on the other hand, deciding the toolbox should be absolutely totally completely different is way too extreme. And what says “absolutely totally completely different” more than putting one at the bottom and the other at the top. 

So next time you design an OS, please figure out what your common user functions are (e.g. saving stuff and copying text), and make sure the’y standardized across the user experience. And when I say “standardized” I mean “always in the same place”. Thank you. 

Users can’t read anything, and if they could, they wouldn’t want to

I recently wrote something about an experience I had with my iPad when I just opened it up. I got plenty of angry responses telling me that since I didn’t read the manual I’m not allowed to complain (in other words, RTFM).

Such comments really piss me off. Not because I should not read manuals (I actually do in most cases), but because good products should not expect me to. I’ve written about it in the past, but here’s a short piece of text written 12 years ago by Joel Spolsky that sums it up in the best way: 

When you design user interfaces, it’s a good idea to keep two principles in mind:

  1. Users don’t have the manual, and if they did, they wouldn’t read it.
  2. In fact, users can’t read anything, and if they could, they wouldn’t want to.

Reading this text many years ago had a great effect on my life. I recommend you read it through: Designing for People Who Have Better Things To Do With Their Lives.

And again I’ll stress the point - sometimes you must have a user manual. In most cases you should probably include a user manual for those looking for it. But you should aspire to build products that most people can just start using, without reading anything in advance. 

User guides, updating stuff, and a LinkedIn frustration

So I decided I want to post my tweets on my LinkedIn timeline. I noticed most of my friends do it, so why not me. 

I Googled for “posting tweets on linkedin” and sure enough the first link was what I was looking for:

I clicked the link, and arrived at a simple explanation in the LinkedIn learning center:

In this article there’s the great sentence “you have the option to share all tweets, to share only tweets that contain #in or #li, or not to share tweets at all.“ 

Three options, very simple, even with a screenshot of radio buttons: 1) Yes, share all tweets; and 2) Share only tweets that contain #in. Perfect.

In the learning center, at the bottom of this article, there’s the following link:

So I can even change the settings directly from the article. But when I click it, this is what I get:

What does this mean? Where’s the “Share all tweets”? If the “Share only tweets that contain #in” is not selected, does it mean it automatically shares all tweets? If so - how to I stop it? If not (which would make more sense), how do I share all tweets?

I came from a user guide on a learning center to find out the product is different. I’m confused and frustrated. 

What’s the lesson?

  1. Maintaining learning centers is a bitch. It’s difficult and requires lots of maintenance. 
  2. But if you do it - do it properly. Connect the product release people with the content people to make sure everyone is in sync, and don’t let such things happen.
  3. If you A/B test visual pieces like that, it becomes even more difficult. One crazy option is to maintain different content for different users based on the cookie so that people who get different versions will also get different guides (assuming they have a cookie). But that’s a maintenance hell that probably doesn’t justify the cost. Am I part of an A/B test in this specific case on LinkedIn? Who knows… 

Facebook spamming and A/B testing

A couple of days ago Chris Dixon tweeted the following:

I know some of the Gogobot fellows, and they are definitely not evil. But I know Facebook spamming, and it is pure evil. And I know Chris Dixon, and if he thinks you’re evil then you’ve got a serious perception problem.

When I saw this tweet, as I automatically came to the defense of Gotobot, this was my train of thought:

  1. Maybe Gogobot’s investors pushed them to “get more” and try evil stuff.
  2. Maybe Gogobot’s team, in response, rolled out this evil practice to a tiny subset of the population, in hopes that it will not actually improve the results, so they can show their investors that evil is no good. And the subset needs to be so tiny that it won’t have a real reaction in the world.
  3. Maybe in a miserable random picking, Chris Dixon was chosen as part of this tiny subset. 

Now that’s no excuse, because if you’re considering evil stuff and trying it on a tiny subset, there are risks involved, and when you take risks then such things happen. But this is all in my mind, and maybe the team there did sell their souls to the devil. But I’d rather believe they didn’t. 

Because Gobobot, unlike, say… BranchOut, is has some real value involved beyond the spamming (I mention BranchOut as a company I hate, because they are solely based on Facebook spamming). So I still wish the best of luck to Gogobot and advise they don’t send Facebook messages on people’s behalf without being perfectly clear about that before sending. 

What’s the lesson here?

  1. Don’t be evil.
  2. Specifically don’t abuse people’s trust - when people connect with Facebook, sending messages on their behalf without them being perfectly aware of that, well… That’s something I would expect from Adolf Hitler. 
  3. If you do try something shady just to measure the results of an evil or semi-evil practice, make sure you don’t have popular opinionated entrepreneurs/investors in that list :)

iPad - please don’t ding while you and I are asleep

I bought an iPad. I must admit I don’t really understand how people can use it their main device, but that was exactly the purpose of me buying an iPad. I believe that product people should constantly try and use every product that is immensly successful, in order to develop insights into what makes consumers get excited about stuff.

I just brought it home, set up my email and installed a couple of apps, then went to sleep. The iPad, too, was asleep (there’s this cool smart cover that sends it to sleep once you shut it). Then the iPad started dinging. I recognized the sound because I have an iPhone. It was a new email notification. I get lots of emails so it kept me awake.

I quickly browsed through the settings and could not find a solution to silence the damn thing, so I reached out to my good friend Google for help. The first result was a story by a guy just like myself complaining about the exact same problem in Apple forums. The community there initially dismissed him as crazy, not acknowledging that there is indeed something wrong with the fact that a sleeping device dings at night… At some point he answered:

“Thanks for both of these answers, although they are both nuisance-solutions.  There should be a way to disable the stupid sound without adding something new I have to do every single night, that is ridiculous in my opinion.  When the device is “asleep”, there should be a way to tell it not to make any noise.  Putting it to sleep should cover it.  Should NOT have to mute it or go into some freaking menu to change a setting in addition!  Very lame.”

I couldn’t have said it better… Here’s the full thread.

The thread does include something that solves my problem (I just killed the email sounds because I don’t like them even the iPad is open), but it’s definitely not a complete solution. Don’t get me wrong, meanwhile the iPad is a great device and I’m doing nice things with it (like writing this post). But I think that making sounds by default when the device is asleep is a bad decision.

When I set up the device for the first time it took me through a wizard of several screens, asking me various questions about how I’ll use it. Many of those questions were less important to me than asking me “hey, when the device is asleep, can it still ding?”

So what’s my point here?

First, I’m constantly annoyed by the fact that many people just cannot accept criticism about Apple products. I’ve written about it before. Second, if you ever build a product that can go to sleep, ask yourself: when my owner puts me to sleep, does he think I’ll make unsolicited noises unless they were explicitly requested by him (eg alarm clock)?

I find it hard to imagine a case where the answer would be “yes”.