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?

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.

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.

Many startups and established companies have fallen into the time suck of coming up with a “good” name. God only knows how many Post-It trees have died in the pursuit of naming brainstorms. Then, of course, when a short list of names are finally arrived upon, the URL hunt has to begin.

A great name has never built a successful company. Google, Ensoniq, Wii, Lycos, Teac, Geico, eBay… I could spend all day writing a list of companies with names that would get tossed in the trash at a brainstorming session. When I started my first company, a magazine called Permission, I had no process at all for naming it. I spent my time thinking about what the magazine was going to be, and ignoring the title. One day, sitting at my kitchen table in Chicago, the word “permission” popped into my head, and I wrote it down, figuring it was as good as any other. Much later, when the magazine was established and had a personality of its own, the name seemed to make sense, as if it had retrofitted itself to the actual company. Of course, that was 1991, and getting a URL wasn’t an issue. I did end up registering Permission.com a couple years later, in ’93, only to have the URL claim jumped by a squatter a few years later—but that’s another story.

Today, the reality is that registering your company or product name as a .com domain is all but required, and most people will tell you that every .com that can be registered has been registred. Luckily that’s not true. Short URLs that can be found in the dictionary may be a distant memory, but there are still massive numbers of short .com URLs to be had, if you are willing to throw letters together to see what sticks.

NXdom.com has a powerful, but simple, tool that will serve up a seemingly endless list of unregistered domains based on whatever criteria you need. Rolling a d26 (actually a d3 and a d10, discarding numbers over 26) to pick some letters of the alphabet, here’s an example of a few URLs that came up:

carefire.com
UXair.com
zeropolar.com
MarketApe.com
trision.com
japata.com

A lot of the results that come up are hopeless, like dxexp.com; and some are intriguing, like jadecodes.com, and dynamodels.com. The one thing they always are, though, is available to register at a place like NameCheap or Dotster for about ten bucks a pop.

Spend your time and money on building great things, not worrying about names. If you’d never heard of either company, who do you think would do better, Google.com or Search.com? Let’s put it this way—Search.com gets less than half as much traffic as Dogpile. While we’re at it, MP3.com and MySpace are pretty good names that probably got cheers in their naming sessions, too.

[NXDom]

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.
If you’re at a company with a QA department that covers all the bases, they’ll test your work before it goes out, but by the time it’s in QA, you’re in damage control mode, and it’s too late to really design across browsers. What’s more, if you’re a freelance designer or a small shop, you may not even have a QA team with multiple environments at the ready.
NetRenderer is a public service by German IT service provider GEOTEK Datentechnik. It allows designers and developers on Macintosh and Linux systems to see their sites rendered by Internet Explorer 9, 8, 7, 6, and 5.5.
Another useful feature is the Difference Mode:

A unique Mixed Overlay and Difference Mode helps to identify even subtle positioning discrepancies between IE6 and IE7 by adding or subtracting both images and displaying the result. Screenshot images are always 100% original size and a ruler marks maximum usable viewing widths on 800×600 and 1024×768 displays, taking into account the browser scrollbar.

Don’t wait until you’ve finished designing your site to check cross-browser compatibility.

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

Here’s my proposed solution (which some sites are already doing):

A better experience is to put the user effort on the edge-cases. Namely, don’t require any action from me if I legitimately signed up. Just send me a nice vanilla welcome email.

In the edge case, where some unauthorized person has signed up using my email, then include some directions at the bottom of the email that instruct me how to deal with the abuse. And an extra benefit: If I have a good experience with your site reporting the abuse, I’ll be more interested to legitimately check out the site.

[Quist.co]

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.” In About Face, Cooper’s example of a context scenario is slightly less detailed. He states that “(context scenarios) should not describe product or interaction detail but rather should focus on high-level actions from the user’s perspective.
Of course, in the real world, every project and every team has its own unique identity and needs.
In the case of these user scenarios, a lengthy process of goal setting, persona creation, and ideation had been completed, and the team was looking for a description of the user experience that included some details of the interface itself, in anticipation of the next step in the design process.
This document includes the personas, a summary of each person’s situation, the scenarios, and diagrams of the scenarios. You’ll see that the scenarios have been presented as numbered steps, and each includes a list of the features highlighted in the scenario. This was to make it easier for product managers and developers to discuss the features more easily in meetings.
I consider this example of a user scenario document to be the most detailed format I would use. Any more detail than this, and we’d be in key path scenarios, or even wireframes and use cases.

One 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]

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]

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]

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.