Recent Blog Posts

Today somebody pointed out to me an excellent advance in usability testing efficiency - Morae lets you do all the camera work, screen detection, comment observation, and data stream synchronization with a piece of software and a webcam. It's got other features as well - most notably remote team members can watch the test from the comfort of their own desk. Very nice.

Of course, this won't work for a mobile device. It would obviously work for testing on a simulator, but see our overview of mobile usability testing for details on why I think that isn't the way to go for full testing.

I've writen elsewhere about usability labs-in-a-box designed for mobile, but that doesn't compete with the convenience of Morae.

There is an excellent possibility on the horizon, if enough people just asked for it. And the management listened. TestQuest is a software solution for automating unit testing of mobile devices. You write generic scripts and literally plug in a phone; the software runs the script for the device and records everything including the screen shot.

Very useful - but they currently assume that carriers and similarly-sized organizations are their only market. When I spoke with them, there was no interest in setting up testing centers for mobile developers, let alone anything related to usability testing.

Regardless, TestQuest technology could reasonably be altered to, like Morae, automatically collect usability testing data when using mobile devices. This would advance mobile usability significantly.

The palmOne Treo 600 may be old news, but there are some minor complaints about it that should guide us in future design. Don't get me wrong: there are many many things that this device does right, such as having a hardware switch that turns off all noises without even having to remove the phone from its holder.

Another minor complaint: the QWERTY keyboard is gratuitous. It doesn't add value over, for example, Fastap, which can be used with one hand on keys made for human rather than monkey fingers. But that's an ongoing complaint.

I love the keyboard backlight. I can actually use the keyboard in the dark. This comes in handy more times than I care to imagine.

As I use the device, I realize that implementing something as simple as a keyboard backlight is a bit more complex than it originally seems, at least with the Treo implementation. When typing in some widgets, the backlight works as you expects - it resets the time to turn backlight off until some fixed time after last keypress. In other widgets, such as the URL entry widget in Blazer, the device doesn't reset the timer after keypresses, so the last 80% of the URL is typed in the dark. I assume this problem was due to implementation complexities and not design laziness.

Another complaint: the device should have an autofill feature that lets people type frequent items once, then paste them into any field. Better yet would be for the device to automatically complete the word, but this would take quite a bit more design and testing work to ensure that it is usable by anybody faced with it. Yes, there is third party out there to do this, but it is not as reliable as might be hoped. The feature should be in the OS.

I know this is a mobile usability blog, but there are a couple bad examples of design out there that I have to share. And they are mobility-related.

First, the Multimedia Card Association has decided that their home page needs Flash. The good news is that the home page is not entirely Flash. The bad news is that their server has a slow connection, I frequently have a slow connection, and their Flash file is 3.4 MB. Ridiculous.

The site is perfectly nice on my Safari browser with plug-ins turned off. It has a lot of good content and is reasonably nice - and isn't requiring IE to work. In IE with Flash turned on, however, the site looks odd, it takes an incredibly long time to load, and you can click on something by clicking 4 inches away from it. The site is a disaster. The problem isn't Flash, it's poorly designed Flash.

Second, America West has this wonderful feature in which one person can make reservations for other people, and have the confirmation email sent to their email address. This is a great feature, facilitating coordination amongst a co-traveling group. The problem? The confirmation email gives me a confirmation number, ticket numbers, and the names and seats (and frequent flier numbers) of those traveling. It does not, however, give me the dates of travel, the flight number, the origin and destination city, or the flight times. Great idea, terrible implementation.