Recent Blog Posts

I was recently asked about designing help systems for mobile. I put a draft version of our help system design recommendations up on the mobile design resources wiki. Obviously this is not a full design, but it should get you started. Please edit as your experience suggests.

Ah, election season. Here in the U.S., early voting has already started. In one state, nearly 20% of registered voters had already voted by Monday. But all is not well in the land of democracy. Or the Republic. Or whatever.

Terrified by the hanging chad paper ballots of the 2000 elections, many states went to electronic, touch-screen voting machines. Ignoring the myriad security issues, let's talk user experience. First, please note that the usability community has had a formal voting usability project since 2001. It's frustrating to watch new machines come out and ignore established security and usability freely available standards. (Some have gone back to paper, with scanners to quickly read the votes. Paper is an interaction method, and one that's pretty well understood; good or bad design can happen in any media.)

We have three key constituents here: election officials, poll workers, and voters.

Many poll workers are essentially volunteering. When I did this in California, I was paid something less than minimum wage, though this was 18 years ago. It's social: neighbors come in and announce that they are here to cancel out each others' votes. You see people you don't normally see. It's a great way for a retiree to spend a day.

Please note I said nothing about "technical" or "computer savvy". So, issue number one is training the poll workers on how to help voters and manage the machines. This problem is pervasive for most interactive voting machines. I've not seen any problems with the fill-in-the-bubble paper votes with on-site scanners in my precinct. Another benefit of the scanner system: you only need one machine for 1-2 precincts, as it only takes 10 seconds to do the computer part of the process.

Now the voters themselves. Hopefully, you've got all walks of society voting, from semi-literate computer novices to folks like typical readers of this blog. All need to be able to vote. Fortunately, there's lots of help, but voters are going to feel somewhat pressured to move quickly. This is especially a problem where states do not send out sample ballots, so voters are seeing the layout for the first time.

Touch screen kiosks are easy to set up and perceived as easy to use. After all, touching is "natural". Unfortunately, it's not that simple. One early voter in Decatur, Tennessee had the voting machine "switch his vote" from one candidate to the other, and was told "the error sometimes occurs when a person??s finger touches close to the line of the box the candidate??s name is in".

Ah, parallax. A problem with touch screens, particularly with kiosk. The touch surface and the display surface are not the same, so what is being touched does not necessarily match what the machine thinks is being touched. The two have to be aligned, but the person doing the aligning has a particular point of view that doesn't necessarily match the voters. And the things can lose alignment over the course of the day.

Too bad the developers did not follow simple kiosk design guidelines. For example, check out SAP's Interaction Design Guide for Touchscreen Applications (Experimental). Don't use it for mobile web design, as you'll have to do a lot of analysis to make it work for that environment, but it is precisely written for kiosk design. And if you read it, a some simple heuristics valid for most touch interaction emerge:

1. The touchable area of a control and its visual representation need not be the same size. That is, the target can be larger or smaller than the graphic.
2. For most situations, provide a separation of at least 3 mm between targets. If a touch does not fall in the target area, do nothing. The user will tap again.
3. The graphic should generally be larger than the target. Ideally, the graphics are also separated.
4. Use large graphics for buttons, around 2 cm square.
5. Provide immediate feedback for the action, such as changing the visual state of the actual control. Bonus: change the label to add a checkmark or some other natural visual.

Excellent resources:

• Touch Usability blog and the voting problems entry
• Usability Professionals Association Voting and Usability project
• Voltage blog best practices of touch screen design

And of course election officials sure can write their requirements to address real needs of voters. Since they seem to use the "requirements" put forth by manufacturers, instead of those independent groups above, probably the best way to change this is to get people who care, and usability professionals best of all, onto the election boards. We're all too busy around here, but please, you should go help out.

Of course, the ballot marking is just a part of the system. Even just taking the polling place into consideration, there is traffic control and flow, paperwork, queuing, interfaces and backlogs on other machinery (e.g. making smartcards for the kiosks), etc. Or, how about if there is a problem with the machines, like the Diebold timeout issue? See the image at the top of this post for a too-wordy potentially untruthful "solution" to help voters. I say the answer is not to 1) lie about the reason, 2) give an excessively-wordy notice out, 3) on small paper, and 4) then take it away from voters before they actually get to see the machine (Steven snuck one out, though).

If this is all too heavy, and you are tired of voting news, try this take on the real value interactive maps add to the TV news. The relevant bit starts about 5:30 in.

I like process and procedure. I didn’t used to, and working with new designers it’s often hard to persuade them it’s worth it, but a project or two is usually enough to show them it works. We work with the client, gather information, interview users, codify everything, parse and organize it, and design systems that can be actually built and meet the needs of the identified user base.

Which is why I could not disagree with this blog post more if I tried. Oh, unless it’s the much longer version this other guy posted which is where the first post came from.

One telling line from that post is:

For our Case Study, I will not do any research and the product will be entirely fictional. This is the approach used by most real companies.

Ah! See, like I mentioned above, there is a formal method to talk to users and gather information. And another thing a lot of people outside of UX don’t get is that users lie. This is why we don’t do focus groups. There are lots of other ways to get at what people do want, how they really use their existing products, and act in their life, etc. If you just ask them what they want, you’ll build a product or feature they will continue to claim they want, right up till they do not use it.

And that’s important when you get to the core idea these blogs brought up. Which is that you should trust yourself. I claim that you lie also. I know I do. The problem with focus groups and other preference-based surveys is that people are not trying to lie to researchers; they also lie to themselves. So you don’t know what you want either. Really.

Back at Sprint our team decided to make our own “enterprise” software package. Okay, it wasn’t for the enterprise, but it was internal software for a team of 40+ people. When announced, everyone ran back and made a list of desires, and developers started coding it. Then we assigned a team, interviewed each other, gathered data, etc. and designed it. Guess what? Totally not what had been coded and asked for by everyone, and in the end so exactly what was needed that everyone actually used it (unlike the enterprise software we were avoiding using by building this product).

Which is a good point. My products (usually) work great. I mean, they reduce calls to customer care, get good reviews from users on forums, improve customer satisfaction scores, increase the close rate by 250%, improve sales. Real, measurable results. And 90% of the features and design widgets I put into this work is distinctly not what I want for myself as a user. In fact, I don’t use most of the consumer-oriented products I have built.

Whenever I rant like this a lot of the tech people I know get all upset with me, and take it to mean they can’t do anything. Not at all. Developer input is important, software and database design are important phases, but user input is also an important phase. Just like a DBA can help you build the data store, user experience and usability folks can help you design what your customers actually need and use.

I’m late pointing to the latest Carnival of the Mobilists, so much so that I’ve two now. Find last week’s Carnival at London Calling, and this week’s Carnival at VoIP Survivor. As always, this is one of the best ways to get an understanding of a good cross-section of mobile bloggers.

Want more? Go check out mobile.alltop.com or the mobile version at mobile.alltop.com/m for writings of lots of mobile bloggers, perhaps even “all the top” mobile bloggers. You’ll find some familiar faces (like us!) and some new ones.

Today Michael Mace posted a nice little overview of Everything you always wanted to know about web community, and then some over on his blog. There are links to a couple versions of this long report (which I mostly haven't read yet, cause it's long) but the blog post alone is nice.

Of course, the most interesting thing was after he asked "What does it mean to mobile?"

Good point, and something we've actually dealt with lately. Naturally, all our client work is secret, cause that would make it too easy, but I've started internalizing some principles of community mobile design and this is a good excuse to chat about them.

• First of all, it's a lot easier to read than to post in any way. Entirely aside from the difficulty of entering info into mobiles, most people lurk. They read blog posts and do not comment, they read forums and do not respond, they read reviews and do not post them. Make reading features easy and fast to get to.
• It's only easy to read things when it's easy to read them. Use all your best practices about reading text on mobiles.
• Big communities already exist. If you have one on your desktop website, or can tie into one someone else has, by all means use that. Don't confuse everyone by starting from zero with a mobile social feature unless you have to.

As yet, a lot of these points drive not just design, but strategy. You have to chat with the clients about what the best solution to pursue even is. But one thing is still true: If your company has social info or reviews or something that isn't mobile yet, get it that way soon. You are missing an opportunity every day.

Naturally, this is a "right now" sort of thing. Over time the final state – or at least the next state – of mobile social networks will emerge.

I pulled down AdMob Mobile Metrics, as I always do when they have new data. The results were fascinating, including the fact that the Motorola RAZR and KRZR remain the top two devices accessing the web in the US for the second year running. Of course keep this with a grain of salt: this is devices that access the web either using the AdMob ad network or an AdMob Analytics customer.

AdMob categorized devices in each country according to small, medium, large, and extra large. Larger devices were more typically found in the US and UK, with smaller devices found in Indonesia, India, and South Africa. At the same time, those latter countries’ devices tended to be more capable.

We haven’t found where the MMA defines screen sizes. After all, “small” would be a great thing to know. We typically define small as “width less than 176”. The MMA does, however, define banner sizes using small, medium, large, and extra large. Here they are, with the Little Springs estimates of the corresponding screen size:

MMA label	MMA ad  width	Estimated display size
Small	120	128×128, 128×160, 160×160
Medium	168	176×208, 176×220
Large	216	240×320
Extra Large	300	320×240, 320×480

The above table is useful, but leaves some newer devices like the Sony Ericsson Xperia, HTC Touch Diamond, and Blackberry Bold. Each of these is 480 pixels wide! (The Bold is merely 320 tall but the others are much larger). A 300 pixel banner will look a little lost.

This got us wondering just what the pixel sizes were here. After all, the Bold screen is as wide as the iPhone screen, but is 480 rather than 320 pixels. And the Xperia, at 480×800, has a 3 inch diagonal screen. And we found that the “small” screens tend to have 110-120 pixels per inch, “medium” screens have 125-150 pixels per inch, “large” have 142-193 pixels. And extra large are all over the map.

This data is by no means particularly accurate, and we have a tiny sample. If you’d like to help, just collect some of your old phones and look up their specs. We need to know the phone name, the pixel width and height, then either the mm width and height or the inch diagonal (this is how it’s been reported everywhere). If you can do this, please fill out our quick form and it’ll be added to the database. So far, this site has physical dimensions 70% of the time.

What will we do with the data? First, we’ll publish information correlating reported screen size (pixels) to pixels per inch. This will be up on our mobile design resources site. Second, we’ll negotiate with Luca Passani, who runs WURFL, to add this data to the database so everybody can figure out the correct size.

After all, the HTC Touch Diamond and the Nokia N96 have the same physical screen size but one is VGA and the other is QVGA. A 30×30 icon will be 0.21 inches on one and 0.105 on the other.