Recent Blog Posts

I’ve been fascinated with E Ink displays ever since my days at IBM as an intern. An industrial designer alerted me to the technology, and talked about the possibility of making the packaging of a product be self-documenting.

Alas, that was back in 1998. Since then, other products have been announced. I’m especially interested in Readius but am worried that it’ll be as much a letdown as other products on the market.

But now, in 2008, some more functional uses are available. Casio Hitachi has announced a line of devices using E-Ink to decorate the outside of the phone. Yes, in Japan and not the US. When an incoming call occurs, the outside animates and shows you the caller ID or message notification.

See the Slash Phone article with lots of pretty pictures and the E-Ink press release.

I was poking around the web trying to find a comprehensive list of what script events different browsers supported, so that we could design web sites with Javascript without just targeting a single browser. What I wanted to know is how user interaction could trigger scripts.

This was hard enough to find that we created a page on our mobile design resources wiki. We’d appreciate help: I couldn’t find this information for Nokia at all, and Opera Mobile’s documentation was exceedingly breezy. Pocket IE’s information was extremely difficult to find. I’m providing all these links so enthusiasts come correct us, especially Opera folks.

The obvious mobile web scripting interaction design principles are:

• provide a non-script version of the page, unless you really don’t care about the majority of phones


• avoid getting fancy with DOM events: many devices will generate mouseenter, mousedown, click, mouseup, mouseleave with a single user click


• provide mouse equivalents of key events, as many devices don’t support key events at all


• supplement mouse events with key events, as some very high end browsers are on devices without touch screens


• build a version of the page that works with server-side scripting


• beware of other script inconsistencies, though mostly that can be left to developers

What else should we add to this list?

Last week Maj. Mark Sullivan, Deputy Chief of my local police department showed me the way their patrol cars are set up with communications and computer interactive systems. I gather the older versions, before they were based around ruggedized laptops, were called Mobile Data Terminals, so you'll see the "MDT" terminology still.

They are, in many ways, a dream of location services, context and data availability:

• A computer allows the officer in the field to look up licenses, take reports and do other tasks without paper or slow voice communications back to the dispatcher.
• The location is constantly broadcast over a data network, right to the dispatchers' screens. No more "anyone in the area" calls; the closest available vehicle can be sent to a call.
• The dispatcher can send data to the cabin terminal; not everything is sent over voice, so there is less chance of garbled communications, less clutter on the voice channel, and some data will be much more speedily delivered.
• When the car pulls into the police department parking lot, say at the end of the shift, it comes into range of a dedicated high-speed wireless network. The video filmed during the shift is automatically downloaded and indexed to location and other data known or recorded.

I run a plate on my MDT and I can have a photo of the registered owner of the car in about 5 seconds. I'm typing on one right this moment, these things are awesome.

–Cleveland area police officer

But could all this access to information, and communications be a hazard? While the risk of distracted driving while talking on mobiles is apparently very low, the danger from actually looking down at screens is much more immediate and obvious.

Entering license plate information – and reading the response – while still moving may improve safety by presenting the officer with critical information (it's wanted in connection with an armed robbery!), but it's also a risk since the officer cannot be paying as much attention to driving, what is happening in the vehicle being stopped, or the rest of their surroundings, like other traffic.

And what about writing reports in the car?

A thirty-year-old officer was sitting in his patrol car in the middle of a busy shopping center parking lot, under a bright light. He was catching up on a couple of reports, using the patrol car's computer. Unfortunately, he lost awareness of the peripheral area.

Another vehicle pulled along side the passenger side of his patrol car. The dirtbag driver leveled a shotgun at the unassuming officer and slaughtered him. The cop's report ended abruptly, mid-sentence. The cop never saw the danger coming.

This is from an article entitled Is your Patrol Car Computer Going to Kill You? by Jim Donahue. He's a police officer in Florida, who has started training programs for mobile computers.

He teaches a class on "technology and tactics." Much like firearms training teaches officers not just the skills of hitting a target but when to use appropriate force, these classes are about how to use your technology as a tactical item. How it influences your work and the implications of using computers, phones, radios and other technology for the job.

While I am leery of training to overcome design issues, this is training to avoid procedural errors. And fixing the procedures can certainly help. The trend, as in all industries, is to get more and more out of your workers, so it is typical for patrol officers to spend their downtime in the field writing reports. As Major Sullivan says, "To write a good, cohesive report you gotta be focused; you can't be looking up every thirty seconds to see what's around you, which you should do if you are out." So it's not even just an issue of safety, but of getting good output from all facets of the officer. To that end, some departments do specifically encourage only note-taking in the field; reports are written after the shift, in the office.

Jim Donahue teaches his students that when they do have to perform paperwork in their car, there are ways to alleviate the awareness issues: find a quiet spot, back the car against a wall or other obstruction, roll the windows down and turn down the radios. And park on gravel if at all possible. You cannot be surprised by anyone walking up, and ought to have time to react if anything interesting happens.

Of course, some of these issues, and solutions, did exist in paper-report days. But shouldn't interactive systems be able to assist better, and be able to improve the situation? They certainly should not hurt, but even maintaining a flawed status quo aggravates the designer in me.

Some of this does seem to be happening. The Mission, KS police will be moving to a new system when their next vehicles arrive, with a smaller touchscreen and keyboard, mounted just below eye level. They are on movable arms to provide access to the vehicle stereo and climate controls, as well as to make the typing position more comfortable, while staying well away from airbags and the driver's body in case of an accident. Officers in other departments with systems like this to tend to say it brings ergonomics, usefulness and visibility up past any pre-computer systems.

These sorts of improvements seem to be moving into the mainstream slowly. The software, and device interaction in general, is an entirely different field, also with wildly variable results. Most of the software started life as desktop data entry systems. Many are simply compressed to fit the smaller screens, and are therefore quite difficult to use. Important functions of the software, or the computer system itself (dimming, or night modes) are often difficult to access, or impossible to decipher without training, which may not be available or comprehensive enough.

All of these are failures of basic mobile principles. Despite being vehicle mounted systems (mostly), the core concepts are the same:

• Glanceable
• Contextually presents information
• Contextually prepared for input
• Personalized
• Always on and always ready
• Obvious and predictable interface

These systems do some of this wonderfully, but generally fail on at least one critical area.

Since I don't think most of our readers don't build life/health/safety devices, you might wonder how this applies to you? Well, this is an excellent case study of a possible future of mobility in many ways. First, the hardware gives capabilities not far from many consumer mobiles. Multiple radios, location services, video, text communications. To get to this level of contextual behavior only takes a dream and some software. Why shouldn't my phone be able to recognize when it is within range of my desktop computer, and automatically use the bluetooth connection to download video to the correct folder?

Risks of heads-down behavior are, as I mentioned already, obvious for consumers on mobiles, and promise to get worse with increasing use of data services (and to my surprise still no voice-xml accompanying the text and graphic output).

But even aside from safety, simply missing out on meetings or family christmases, angering your boss or grandma and generally not engaging with the world is whole new class of risk that is almost the opposite of how mobile devices should be helping users interact with their world

And if you do work on public safety, communications, telematics or military systems, please do try to make them the best interfaces you can.

This is the second of a three-part series on mobile usability testing. Part one is for devices and software native to devices. Part two is for web sites and applications that might go on multiple devices. Part three will talk about adding testing with physical and social context.

In most of our work, we are designing applications or web sites that need to run on multiple devices. When we have control or even just the ability to predict what screen size, rendering engine, input mechanism, user interface paradigm, device interaction, and more is present, we consider that relatively easy. Complexity in the design process quickly arises from managing device diversity.

Developers deal with device diversity problems as well, with coding, porting, and testing. Best practice I’ve seen is to test in a simulator, check actual behavior on a small set of live devices, and then do thorough testing and debugging with a service like Device Anywhere. I’m hopeful that Mob4Hire will also do well.

None of this is relevant for usability testing.

If you are testing a prototype, perhaps focusing on information architecture, then you can do usability testing on simulators and get pretty good results. Most usability tests I’ve seen, however, are done on complete or near-complete products. You simply will not get reliable results from an emulator. User behavior changes, understanding of information changes, perception changes, delay times change, input mechanisms are mismatched, and rendering engines usually are slightly different.

Yes, we talk about this a lot. You can check out some slides, or of course my book, Designing the Mobile User Experience.

We have a few main recommendations for handling usability testing of cross-device applications:

1. Test on actual devices for final product testing. If you are just testing information architecture or some other iterative question, you can use the emulators.


2. Acquire ten or so different models, based on popularity in your market and rendering and UI differences


3. Recruit users using a device the same as or similar to your devices


4. Perform usability tests with these devices.


5. Match the device’s user interface to the participant’s personal device’s user interface.


6. Use the practices for all mobile usability testing, as explained in part one.

Avoid the tempting shortcuts.

1. Use actual devices, not emulators, for final product testing. You’ll find different results, results not relevant to your actual product. You won’t find that a target size is too small on a computer, you won’t find that the page is simply too heavy to be sufficiently responsive. Go ahead and use emulators for iterative testing, as long as you have similar input mechanisms and device+network responsiveness.


2. Use your devices, not the participants’. You have no idea what customizations, downloads, extra bugs, full memory, start state, or more might be on the device to affect your data. Besides, you don’t want to do anything to inadvertently cost them more money.


3. Use an array of devices, not just high end. Unless your entire target market uses the iPhone or N95 or Blackberry, you’ll not get good data. I’ve seen too many “best case” usability studies. If you want a marketing study, be honest about it.


4. Have participants show you their device. They may tell you they have an iPhone when they actually have an Instinct; they may say they have a Sprint device when they actually have a Sanyo device. It can be difficult to know what device you have.

Dear Dr. Inventor,

You do have an interesting concept, and we might be interested in working with you. Keep in mind, however, that I have literally seen 20 innovative hardware input mechanisms invented; most of which have not made it to market.

Indeed, the only one not invented by the manufacturer that I know of is Fastap, a company who started business development for this in 1999. In fact, it was the inventor trying to sell the idea to Sprint’s Usability group, of which I was a member, that introduced it to me. From 1999 to 2008, 10 years, Fastap has only launched on a small number of phones for small operators. LG, for example, has two Telus Mobility Fastap devices.

Why is this? Because the manufacturers will not spend the money on it unless they know they can sell it to the operators. The operators will not buy it if it costs them money, even if it will make them money. And it is very easy for them to justify why your product is not actually as good as you say it is, no matter how good it is.

If it costs more than about 1USD per unit, you have a probable failure. More than about 4USD, and you have a certain failure.

Many alternative keyboard manufacturers, such as FrogPad and Keynetik, are going after smaller markets such as military or industrial workers. You might find some traction there, for much less money. But of course you will not get the GreatNewKeyboard on every phone that way. And you will need to work with someone in business development who knows those markets.

So before investing our time in your product, we would need to know that you had assembled the capital and business development expertise to move forward. You probably need more than two million dollars: some for re-design, some for responding to operators’ requests that will take you nowhere, some to keep you fed, some to do usability tests, some to make prototype units, but most to sustain a business development effort that will leave everybody exhausted.

If you find this money and the right business development team, do come back to us. We can definitely help. But our help would be wasting your money right now.

Sincerely,
Barbara Ballard
President
Little Springs Design

Morten Hjerde, as usual, has excellent insights into the realities of mobile application design and development. If you are targeting native applications on different platforms, his multi-platform development post is a must-read.