The disappearing iPhone notification

For some reason, the iPhone notification settings allow a user to turn off every notification option and still leave “View in Lock Screen” selected.

In practical terms, what this means is that you can have your phone asleep in your pocket, and get a buzz notifying you that something has happened. You take your phone out of your pocket, and on the lock screen, there’s a message waiting for you.

You swipe to unlock, and poof, the message disappears. Pull down the notification screen to see what it was—and it’s not there. Lock the phone again and try to look at it on the lock screen—also gone.

This option makes zero sense. Can anyone think of a reason why a user should be allowed to set their notification options this way?

Get that cancel button out of here!

The debate in the usability community about left vs. right for cancel and submit buttons is a long-standing one, and seems about as close to being resolved as the question of Ford vs. Chevy or Coke vs. Pepsi.

Of course, Cancel goes on the left, despite what Windows 3.1 would have you believe. Even more so on the web than in old desktop software, affirmative choices take you forward, and negative choices take you back. Just like reading a book, you look to your left when looking back. So when you’re clicking “cancel,” you’re really saying “take me back,” and that, naturally, goes on the left. Just because some chucklehead at Microsoft in the ’80s got it wrong doesn’t mean we should use such a silly convention purely out of bad habit.

But, since there are still people who engage in Wrong Thinking and expect Cancel to show up on the right, the one thing a designer should never do is put the Cancel and Submit buttons right next to each other. We’re spatial creatures, and prone to click before we read labels.

If you absolutely can’t get away with separating two such dangerously different buttons, at least provide for some kind of undo.

The folks over at Facebook not only went for the boneheaded backwards order of Cancel and Submit (or in this case, Send), but stuck the buttons incredibly close, and provided no way for the user to recover from the error.

The screenshot shows the message interface for Facebook on a desktop browser. Messages in Facebook are the equivalent of email for their users, and for some people, Facebook messages are replacing email. With such an important role to play, you’d think their designers would want to make sure Facebook messages at least reached the bar email set a couple decades ago. Instead, here’s a place that any user could compose a lengthy, thought-out message, and with one misplaced click, hit “Cancel” instead of “Send” and wipe out their entire work, gone, forever.

Put the Cancel button on the left where it belongs, get those buttons away from each other, and provide some way for users to recover their message if they happen to click the wrong button or leave the page / close the browser for any reason.

 

 

Don’t waste your time looking for a name

In his latest novel, REAMDE, Neil Stephenson describes the process video game entrepreneur Richard Forthrast went through to name his company, Corporation 9592:

When their discussion of the company’s name consumed more than the fifteen minutes Richard felt it deserved, he pulled some Dungeons & Dragons dice out of his pocket and rolled them to generate the random number 9592.

Use NetRenderer to test your site in IE, even if you don’t have Windows

As much as developers and designers around the world would like IE6 to just die already, the reality of the Web is the same as it has been since nearly the beginning—not all browsers are created equal, and we have to test our sites across as many platforms as possible.

Is it time to kill new user confirmation links?

The process of signing up for a web site has become fairly standard by now: give the site your email address when you register, they send you an email with a link that says something like “Please click on the link below to confirm that you wish to activate this registration.”

Jacob Quist suggests that it’s time to kill this process, and take a simpler approach. In his words:

Context Scenarios

User Scenarios – Context Scenarios

There are many different forms a user scenario can take, depending on your stage in the design process, the intended audience, team structure, and the individual style of the experience designer.
This is one example of a user scenario, which conforms most closely to what Alan Cooper calls a “context scenario.”

“We had to have the user experience down cold.”

The New York Times is preparing to take a second foray into paid content, and echoes of their 2005-2007′s Times Select resonate as they craft the new plan.

NY Times CEO Janet L. RobinsonOne of the major reasons cited for the failure of the Times Select experiment was the difficulty people had getting to content once they’d paid for it. Whether through a lack of focus on user experience, budgets spent in the wrong place, or simple inexperience with designing for users, they ended up building a paywall that flummoxed paying users and blocked the sharing and linking that is the lifeblood of the Web.

Time will tell if the new attempt to put a fair market price on quality journalism will succeed. Comments from CEO Janet L. Robinson, however, show that they’ve learned important lessons from the past.

“That is one of the things we learned with TimesSelect,” said Janet L. Robinson, chief executive of the company. “We had to have the user experience down cold.”

[NY Times]

iPad 2, as experienced by a first-time tablet user

iPad2Paul Stamatiou has never used a tablet, and by his own account is not much of an early adopter. The 24 year old “developer and startup guy” shares his thoughts on owning an iPad 2 as his first tablet.

In Paul’s words, “It is all about the apps and experience. Hardware matters only so much as it doesn’t impede the experience.”

[Paul Stamatiou]

 

A better way to ask Facebook users for app permissions

Facebook apps make it easy for developers to connect with users and gather necessary info, but they also come loaded with scary-sounding requirements like “This app is going to have access to all your personal data, photos, home address, and children’s blood type.”

What do you do if you want to let people engage gradually, only granting permission for things when the app really needs them?

Arthur Chang has figured it out, and shared his solution with the world. Hop over to his site for a method using one FQL query.

This method will result in more users signing up when they see that they can actually access the app without having to let it write to their wall before they’ve even found out what it does in the first place.

[ArtChang.com]

It’s still unclear whether having Flash is better than not having Flash.

Motorola’s Xoom tablet has finally added Flash support – one of the features that was touted as a differentiator versus the iPad. As Technologizer points out, the First Law of Mobile Flash seems to be “the version you want is always not quite here yet.”

Technical issues aside (and there are many), Flash remains a tool primarily for mouse-based UIs, not multitouch UIs. It’s notoriously difficult to design for an environment in which you don’t know whether the user can mouseover or not, whether they can use multitouch gestures or not, whether there needs to be scrollbars vs. draggable content, and you don’t even know if the pointing device will be a pixel-accurate mouse pointer or an inaccurate finger.