Two new posts (well, reposts) in DZone!

And, here they are:

"From HTTP to the ESB - JBossESB 4.7's New Servlet based HTTP Gateway," http://architects.dzone.com/news/jbossesb-http-gateways

"Message Alerts in JBossESB 4.7," http://soa.dzone.com/news/messagealerts-jbossesb-47

Software Usability - Not Just in the Eye of the Beholder

One of the most important parts of any software test definition is the set of "expected results" for the test. If you cannot define the results that you expect the test to generate, then you make the task of determining whether the test has passed or failed much more difficult. For functional tests, this task is fairly straightforward; does method ABC return a boolean true or false value?

For non-functional tests, the task is more complicated. Performance tests can be measured against a set of benchmarks and security tests can be built to ensure that the system under test does not exhibit any of a set of known vulnerabilities such as the OWASP "top 10" (http://www.owasp.org/index.php/OWASP_Top_Ten_Project).

But, what about usability tests? Is usability purely in the eye of the beholder?

I've always tended to work on the "server side" of software products. So, when I had to think about usability tests, I wanted to find some resources that would help me approach the test planning in an organized, systematic way.

I pretty quickly discovered the work of Jakob Nielsen. Dr. Nielsen has written extensively on the subject of usability and is probably the best known web usability consultants in the world. He has defined the five "quality components of usability goals" as learnability, efficiency, memorability, errors (error rate), satisfaction (http://www.useit.com/alertbox/20030825.html

In addition to his books and papers, he also maintains the http://www.useit.com website. This is a great place to learn about usability testing and to find information that can help you in defining specific usability tests.

When Speed (well, the lack of it) Kills

In my own case, I was concerned about how to quantify user interface performance or responsiveness. Dealing with an unresponsive user interface can quickly ruin a user's impression of your application, even if it is otherwise well designed and error free.

I heard an interesting story on the the radio a couple of days ago about a new launched social engineering site. The site designer was asked, "What was your best day so far?" He answered that their first day being on-line was the best day ("yesterday"). He was then asked, "What was your worst day?" He answered "today." The problem was that the site was quickly overloaded and was presenting users with such long delays that people were abandoning the site.

What I needed for my tests was a set of benchmarks to measure UI responsiveness, and do it in a systematic way, so that my test findings would be quantitative, and not based on my opinion of the UI as being "too slow."

What I found was Dr. Neilsen's benchmark definition - http://www.useit.com/papers/responsetime.html

• .1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning no special feedback is necessary except to display the result.
  
• 1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay.
  
• 10.0 seconds is the limit for keeping the user's attention focused on the dialog. for longer delays, the user will want to perform other tasks while waiting for the computer to finish, so they should be given feedback indicating when the computer expects to be done. Feedback during the delay is especially important if the response time is likely to be highly variable, since users will then not know what to expect.
  

It really helped me to be able to compare the responsiveness of the UI to a measureable baseline as I was able to avoid discussions such as:

User 1: This UI is slow.
User 2: How slow?
User 3: Too slow!