---

Andrea Kendall has been a Graphics and User Interface programmer and designer for over 20 years. She is passionate about designing for the user and is currently working on implementing a Web 2.0 GUI using Woodstock.

---

 

Well after 10 long years of faithful service my Sharp Wizard died.

	Question: Why did I keep this so long? Answer:  Just look at that keyboard.   It is so easy to type on. Anyway, I dropped it last week and the plastic hinge broke.

While I was really tempted to get an iPhone, I decided to go with the Sprint HTC phone. The first thing I like about the phone is the nice keyboard.  The other thing I like is that it is based on an OS I am familiar with -  Windows XP.



Things I don't like about the phone are:

• It can be hard to tell if you have closed a program (and it can only run so many)
  • You have to go into another program to check for running programs and stop them (I do this every time I go to turn off the phone)
• It can be hard to tell if the actual phone is on or it is in  flight mode
• It seems a little too easy to make a phone call when viewing contacts
• It does not come with enough memory to actually use the built in camera and run anything else
• The sales person told me it had everything it needed to back up the phone but it turned out I needed Outlook  if running on Windows XP

Now to be fair the sales person did warn me that this was a more 'geeky' phone.

Yes, I could return the phone and exchange it for the Palm OS one but I figure I will get past the learning curve.  However, it will never be the same as my Sharp Wizard..

So goodbye to an old friend.  

Note: I can still turn on the old Sharp Wizard which I am doing because I have to get all the important data off it.  The Sharp was so old it used a COM port and had proprietary software (long lost)  to back up the data.

 

---

Back in August, Jiri Mzourek told us about the building of Sun's usability test labs in Prague, Czech Republic. In October, Kristin Travis told us what it was like to have her engineering team view her usability tests remotely. And in November, I posted an interview with Kim Arrowood, who manages Sun's usability test labs in Menlo Park, California. Now in this post, Kim takes us for a virtual tour of the labs in Menlo Park.

Kim Arrowood has worked in xDesign for over a year managing Sun's usability test labs in the U.S. Before coming to xDesign, she worked at Sun for 6 years in market development engineering as a program manager. Kim is working to improve the visibility of the usability labs in the U.S.

Jen: So Kim, tell me about the usability labs in Menlo Park.

Kim: The labs have both digital and analog recording; we use Camtasia for digital recording, and DVDs for analog recording. We recently installed all new equipment in two of our three labs in Menlo Park, so the labs are really state of the art. We primarily use two of the three labs in Menlo Park and the third lab is used as a staging area for tours and other demo setups. One lab is set up like an office environment, with desks, chairs, and computer equipment. We typically use that for one-on-one (facilitator:participant) usability testing.

The other lab that we use a lot of the time, called the "playspace", is set up in a more creative and casual way. There is a table in the middle with chairs around it, couches, and it's decorated in a more artistic way. It's been built to look more like a design studio than a typical usability lab. For example, it has lamps off to the sides, instead of being lit from the ceiling, and we have toys scattered around the room. We only have one computer set up in the room, and it's off to the side.

Jen: So how do you use the playspace?

Kim: It's great for focus groups, and we record webinars (training) in there. It also has a ceiling-mounted camera that looks down on the table, so we can use it for testing consumer devices or for capturing drawings. Once a week, the playspace is used to host a "design cafe" for teams to strategize and brainstorm, or for people to review their current designs and get feedback on what they are working on.

All of our labs in Menlo Park have an attached control room, separated from the lab by a half-wall and a two-way mirror, but they vary in the lab size and the number or observers they can accommodate in the control room. The playspace can accommodate up to 20 observers, and the other labs can handle up to 10 observers. Each lab also has the ability to support remote observers, for people who can't observe a study in person. This is very useful when part of a team in somewhere else and they can see everything that is going on in our labs.

Jen: So what else should we know about the labs in Menlo Park?

Kim: We've given tours to several different organizations internal and external to Sun. We were part of the CHI 2007 lab tours, and we just gave a tour to the SEED mentoring participants.

Jen: When you give tours, what's the feedback like?

Kim: They think that the control rooms look like a newscast. And the most common question is, "How do you get anything done in the play space?" I tell them that it facilitates creative thinking and communication.

---

Jen McGinn is an interaction designer in xDesign who is working to improve the user experience with software installation and registration. She has an MS in Human Factors in Information Design and works out of Sun's campus in Massachusetts.

In September we posted an interview with Frank Ludolph describing his work on the New Solaris Installer (NSI). Well, since its release, feedback on the NSI has been phenomenal both inside and outside of Sun. In the past, Solaris had been described as a headache to install. With the NSI, "Solaris can now be installed by mere mortals". In fact, the NSI team won a "People's Choice Award for Collaboration" -- a prestigious award given once a quarter to a deserving team in Sun Software.

Congratulations to the NSI team!

Ondrej Langr is an interaction designer working on NetBeans IDE, and he is located in Prague, Czech Republic

This was the third year in which the World Usability Day also took place here in the Czech Republic. Organized by Sun Microsystems, Czech Technical University and Dobry web (one of Czech Republic's biggest web usability and design consultant companies), under the aegis of Czech SIGCHI, it was a big success. The Czech usability community is steadily growing, and after 80 visitors at the first WUD in 2005 and 140 visitors at WUD in 2006 we had 220 registered visitors this year. The event took place in a Palace Cinema with the capacity of more than 280 people.

The topic of this year's WUD was "Get to know your user", and we had some of the top speakers. Nalini Kotamraju (Sun Microsystems) had a keynote about "What Does it Mean to Know Users?", Jakub Franc (Sun Microsystems) talked about his experience with user research on elderly people done in cooperation with Czech Technical University. Martin Klíma (Czech Technical University) shared the other side of the experience about how it was to adapt user research into a medium-scaled European Commission sponsored research project. During the break between lectures, visitors had a chance to learn more about Czech Technical University’s usability lab and about Czech SIGCHI at two booths in the lobby.

Those who were fast enough to sign-up for workshops (due to limited number of seats, all workshops were booked out during the first day they were announced!) met at Prague’s Sun Microsystems site in the early afternoon. There were three parallel workshops:

• Introduction to Usability Testing, led by myself (15 seats)
• User Research led by Jakub Franc, Sun Microsystem's user researcher (12 seats)
• Web Usability Testing in Praxis, led by Adam Fendrych from Dobrý web (12 seats)

I was not able to attend two out of three workshops, so I can only report on Introduction to Usability Testing. Participants came from both local and international companies, and there were also some students. After the necessary theoretical part where participants learned how to prepare and conduct a usability study, they were led, step by step, through the process of preparing a usability study and got a chance to try a real test session in Sun Microsystems' state-of-the-art usability lab.

The most interesting part of the workshop for me was the discussion. Considering that the usability awareness in East and Central Europe is relatively small (for example, in this area WUD only takes place in Czech Republic, Poland, Bulgaria and Russia), surprisingly many participants had some experience with trying to employ user-centered techniques in their production process. However, their attempts had often failed, mainly because their companies are too technology-driven and because customers and management in this part of Europe still do not see benefits of UCD for their business.

However, the situation is improving. Sun and other members of Czech SIGCHI are building the usability community in Czech Republic and already thinking about how to make the next WUD even better!

Links:

• http://www.worldusabilityday.org - World Usability Day
• http://www.sigchi.cz - Czech SIGCHI
• http://cz.sun.com/wud05/ - World Usability Day 2005 in Czech Republic
• http://cz.sun.com/wud/ - World Usability Day 2006 in Czech Republic

Kim Arrowood has worked in xDesign for over a year managing Sun's usability test labs in the U.S. Before coming to xDesign, she worked at Sun for 6 years in market development engineering as a program manager. Kim is working to improve the visibility of the usability labs in the U.S.

I recently spoke with Kim Arrowood about what it's like to join a design group, when you're not a designer.

Jen: So Kim, tell me a little about what it is that you do.

Kim: I manage our usability test labs. World-wide, we have 9 or 10 labs spread across Prague, Massachusetts, Colorado, and California, but I primarily manage the 3 labs we have in Menlo Park, California. I handle logistics, recruit usability test participants, and help out with technical equipment. I also manage some aspect of operations for our organization, like goals, budgets, and dashboards.

Jen: From your perspective, what's the most challenging or interesting part of coming into a design group?

Kim: The most challenging aspect is the terminology. In my former group, we used the terminology of the customer, but the design group uses both the terminology of the engineering teams as well as terms that are specific to design or usability. For example, I had to learn what it was an interaction designer does and how that is different from the work of a visual designer. And I didn't know what a usability test was until I got to see one, so there was a big learning curve.

One really interesting thing that I learned was how "hands on" design is. I never knew all the work that goes into creating designs before they go to engineering. And I was surprised at how collaborative the design process is. When I worked in engineering, a single person wold work to resolve a single customer problem. But here, there's a very supportive environment -- a lot of teamwork.

Jen: How do you see that manifested?

Kim: Well, when Kristin was working on some designs for the Identity Manager team she took them to the weekly Design Cafe, to get feedback and input on her ideas from other designers in the group. And we have those design cafes weekly, so anyone with an idea or a new mock-up can get feedback from their peers, in a supportive way. But I was surprised, too, at how small the group is, when design is so important to Sun.

Jen: So what is the most interesting part of your job?

Kim: I get to learn a lot more about the products we make; what they are and what they do. I'm reading as much as I can about design and usability testing, but I like to learn about our products by being the participant in our dry runs -- the practice round of a study, when the lab setup and script get tested.

I enjoy participant recruiting, but it's challenging. It's really hard to find good participants; ones that match the test goals for each study.

But the best part of my job is getting involved in the projects, and working on the teams. Everyone works together and communicates -- there are no funny looks and no stupid questions. I really enjoy the collaboration and the teamwork.

Jen McGinn is an interaction designer in xDesign who is working to improve the user experience with the Java Enterprise System installers. She has an MS in Human Factors in Information Design and works out of Sun's campus in Massachusetts.

Last year, one thing I did was to work with a team of Sun engineers and UI designers to create a set of branded interaction guidelines for desktop applications.

[aside] Two weeks ago, I posted an interview with the folks behind the web application guidelines — those are different, because they focus on UI components used in a browser, not a desktop application. [/aside]

The interaction guidelines that I worked on were not component-oriented, but task oriented. Another colleague led the effort on branded system startup, and I led the branded installation guidelines. We may see those guidelines go public at some point, but until then, you can see them in action in the New Solaris Installer (NSI) and the openInstaller framework — even the OpenDS Installer took on some of the guideline design, even though it's a web application.

The openInstaller project team describes the effort this way: openInstaller is an open source community project building a free and comprehensive next generation installer framework. Initial development of openInstaller was done by Sun Microsystems, but is now available under the open source Common Development and Distribution License (CDDL). What's really cool that's not in that statement is that the framework is all Java + XML. I've looked at their code, and if you know a little Java and XML, you can create an installation program quickly and easily. 

From an interaction standpoint, there are a few things that I'm particularly happy with. One is how software licenses are presented to the user. Another thing that you may notice is the placement of buttons. The most frequent interaction is placed bottom right, and then other buttons are organized by projected frequency of use from right-to-left. This organization supports the visual scan patterns of readers of most languages better than button placements that we often see, which are grouped in the bottom right-hand corner, but require the user to read all of the button labels from left to right, to find the most frequent interaction.

From a geeky coolness factor, the openInstaller is written in Java and XML that even I find understandable, and the output of that code is two-fold: not only does it render a GUI, but it renders a command-line CUI, that is comparable to what the user would see in GUI mode. As a result, installers written using the openInstaller framework are easier to develop, maintain, and use.

Kristin Travis has been working in high tech as an interaction designer and usability engineer for more than 15 years. She is part of the xDesign team based in Menlo Park, California, and she currently supports the Identity Manager team, which is based in Austin, Texas.

The last release of Sun's Identity Manager software (in May of 2007) had substantial user interface changes, so when I joined the team in June we discussed conducting a usability study in the Menlo Park usability labs, to get feedback from representative users on the current release.

In my experience, most development team members appreciate seeing how users interact with a piece of hardware or software that they've helped to create. Seeing first-hand reactions to existing functionality helps to shape team members' thinking about changes and new features for a product.

But while I'm located in Menlo Park, the Identity Manager development team is located in Austin, Texas. So the questions I had going into this exercise were: would it be relatively easy to involve a remote development team in a usability study? And would the remote team be satisfied with viewing a study in real-time, but not actually being in the same room as the user?

So what did we do?

In terms of the setup, we created a VNC connection between the usability lab in California (where I was, with the study participants) to a conference room in Texas, where the members of the development team could observe the test sessions.

The remote access allowed the people in Texas (and other locations, if needed) to see what study participants were doing. The Texas team could see the participant's computer monitor and watch, in real time, while the participant interacted with the product. In addition, the team could listen to the participant over an audio conference call that we established between the locations. At the end of each session, if the remote team wanted to follow up with the participant about a particular issue or question, they could do so by using the conference call.

And how did it work out?

Here are some highlights of the feedback that I got from the remote and local teams:

• As with any other type of study, it's really important to conduct a dry run of the session. You don't want to get side-tracked during the study by unanticipated logistical issues. During our dry run, we diagnosed an error in the VNC login instructions for the remote set up. That took a while to figure out, but then things went according to plan.
• The remote team's commitment to the study is essential. Jeff, my main contact in Texas, coordinated the remote conference room, kept everyone there informed about any schedule changes, and attended each study session. Considering the two-hour time zone difference, this meant a few late nights in Austin. But it was extremely helpful to have Jeff complete intra-task dependencies so I could concentrate on working with the participant.
• Jeff said that seeing how the participant interacted with the product was a huge benefit. This was true even though they couldn't "see" the participant directly (as they would have if they had been here locally).

Would we change anything for the next time?

I was in the room with the participant, and Kim, our Usability Lab Manager, was in the control room interacting with Austin by phone, so there was a bit of a communication delay at times. If Kim and Jeff had relevant content to share, Kim had to wait for an appropriate time to break into the conversation that I was having with the participant. It would have been useful to have a '3-way IM chat' up and running, so if the participant discovered any software surprises, or they had any related questions, we could communicate more quickly, without disrupting the flow of the test.

So the questions I had going into this exercise were: would it be relatively easy to involve a remote development team in a usability study? And would the remote team be satisfied with viewing a study in real-time, but not actually being in the same room as the user?

Well, in this case, yes.

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

Things done right in the darndest places...

Every once in a while I imagine myself and Andrew Zimmern from Bizarre Foods trotting the globe, he's searching for strange cuisine and I'm searching for usability blunders. I can see us chatting over the table, smiling for the camera, and me wincing while he chokes down some bizarre-bug-bisque. I would then comment on the strange design of the spoon he's using.

Yes, I know what you're thinking - "What a fantastic idea!!" Change the name of the show to "Bizarre Foods and Users", or "Eat-a-usability", or my personal favorite "Bizarre Food Usage". Funny thing is he still hasn't called me back on it yet. It's going to happen though, and I can be patient.

While I was waiting for that call though, I went down to my local library to find some ideas on potential destinations. And then, while waiting in line to check out my books, I saw the most amazing newfangled contraption ever. It was beauty and simplicity defined, an ergonomic eros of non-error. I was rapt with attention while I watched some brave soul actually use the thing.

I had to try it myself!! It was just so... um... usable!! I approached the lady whom I'd just seen use this usable thing -- a kiosk at the public library -- to check out a book, and then realized she didn't speak English. Her books were in Russian! It was amazing to me that a non-English speaker could go to this public library and check-out books without any assistance!

I immediately found my favorite librarian and asked for a demo. This video shows her showing me how to use the most usable kiosk I've ever used.

Notice that even though the interface is in English, the video instructions are so clear that even someone who cannot read them can see what needs to be done. And, if you listen carefully, you can hear auditory feedback as well, letting you know something happened and you succeeded.

Every once in a while, you'll find something that's really well designed and thought through, and in the darndest places.

Technorati Profile

Nalini Kotamraju is a user researcher in xDesign, and a PhD in Sociology. She has a penchant for research methods and telling it exactly like it is.

Jen McGinn and I recently had the honor of giving a talk about user research at Innovation@Sun, a gathering of Sun's top engineering talent. This illustrious group count among their ranks people who are pioneers in Java (of course), but also in computer graphics, routing security, cryptography, and large-scale distributed computing. Many great technical brains, many patents in pockets. An intimidating group, by most measures.

Jen was presenting (I was back-up) about user research that we had done last year for an organization in Sun. The research findings themselves are terrific and already being applied within Sun. What we wanted to share with this audience was the innovative way in which we conducted the research, and to remind the audience of the importance of understanding the people who are ultimately often the end-users of technical innovations.

One might imagine that such an audience, gathered to exchange information about advances and challenges in the realm of engineering might be -- at best, apathetic -- to a presentation about users and user research. Or at least I had imagined such a response from the audience. Instead, I found that many of the people who stopped by during the poster session or who asked a question after the talk were not only receptive, but were even enthusiastic about user research. In the formal settings, as well as over meals and in hallways, these engineers asked questions about how we think about understanding users and, more often than not, wanted to know how they could utilize user research in their own work for Sun.

Jeff Hoffman has been designing developer and consumer software at Sun since before the boom.

Pop Quiz: What is the application, delivered by Sun, that is most used by people around the globe?

Answer:

There are about 1 million successful installations of Java every day using the Java installer (the installer is just needed for the Windows platform, because Java is already included with Solaris and many Linux distributions, and Apple provides their own Java installer). With all those eyes on it, the installer design receives a lot of attention. The Java installation process may be the first experience that a customer has with Sun and we do our best to make this experience simple, fast, and aesthetically pleasing.

From the user's perspective, the installation process usually starts at a third-party website, which needs the latest Java version to run an applet. The applet could be a game (pogo.com), a map locator (map24.com), or the virtual view of a cruise ship cabin (princess.com). The Java installation experience presents a unique challenge for Sun -- we wanted to make this experience positive for the end user, while providing brand recognition for both Sun and the applet's provider.

Let's have a look at the old installation experience:

The user starts at a third-party website by clicking the "Get Java" graphic which leads to the download and enables them to install the latest version of the Java runtime environment. This download page is simple and straight forward, containing a single button to begin downloading the Java software. The default "automatic" installation process from Internet Explorer involves downloading a small application, which launches the Java installer UI and then continues to download the files that contain the Java runtime environment.

This installer design attempted to reduce the number of panels by putting more "decision points" on a panel -- for example, the initial panel had three purposes:

1. confirm that Java was to be installed
2. Display the license agreement and get the user to agree
3. Provide typical and custom option radio buttons

The design placed too much information on a single installer panel making it appear complicated to the typical consumer. Other installer panels were not visually attractive due to spacing and alignment issues.

We had a couple goals for our redesign of the Java 5.0 installer. The first goal was to keep the number of steps to a minimum, making sure that each step had only one necessary decision point. While creating the current design, the challenge of incorporating the variability (when the user will see a third party offer, does the user have to restart their browser) meant that we had to spec out the various paths and ensure that they made sense. Also de-emphasizing the "custom" install options was necessary.

The second goal was to manage the changing nature of the steps. Our installer has the capability of offering third-party bundled software, such as the Google toolbar. This offer is only shown if the user does not currently have the offered software, or if they have an outdated version. The design of these optional panels needed to be modular so that they would not disrupt the flow of the installation process.

So now lets look at the new Java installer design:

The first panel of the Java installer UI confirms that the user is installing Java, and gives them pointers to important information like our privacy policy and license agreement.

It's still possible for a more advanced user to customize parameters of the install, but since this level of control is not necessary for most users, this feature is not checked by default and placed out of the main control flow. A single click on the first installer panel both accepts the license agreement and continues the installation of Java.

A second panel may appear, offering the user a bundled installation (for example, the Google toolbar).

The next panel (not shown here) shows the progress of the installation process and a message to reinforce the Java brand. When the installation completes, the user is shown the last panel of the installer, which confirms that the Java software was installed without incident. On this last panel, the user may see a checkbox to restart their web browser.

These improvements are already available in the latest release of Java 6. If you want to know about other improvements that have been made in the Java installation and deployment arena, keep a look out for a future blog entry.

Andrea Kendall has been a Graphics and User Interface programmer and designer for over 20 years. She is passionate about designing for the user, and is currently leading the Sun B2B Platform Dashboard in the SOA/Business Integration Composite Applications group.

Designing a Business To Business Dashboard

My team and I have been on a journey to design a “Business-to-Business” dashboard. Like any traveler going on a journey, I didn't go alone. This project required a team of international programmers, our director, the Software Experience Design (xDesign) Group and, most importantly, our customers.

What is B2B?

Business-to-Business is “the exchange of information to support commerce”. This is a world that requires businesses to send standardized information. It's a world that allows a doctor to look up information about a patient or allows a factory to get the best price on steel from its partners. It's a world that spans large businesses and small mom-and-pop shops that want to do business together.

Identifying the Users

The first and most important step was to identify our users: the people who the dashboard had to serve by supporting their tasks and making their lives easier.

• Business users
  • Dollars and cents — cut waste and increase profits.
  • Who is costing us more/less and why?
• Operations users
  • Make sure the end-to-end system is up and running correctly.
  • View alerts about something that was expected to happen but did not. For example, "Purchase order 99587 has not finished processing".
• Business-to-business centric users
  • Track transaction status for standard messages
  • Drill down to lowest level of a message and show:
    • The Message Hierarchy
    • Errors
    • The actual data sent
  • Resubmit messages back to the system after correcting errors
  • View audit information

Designing for the Web

I had sent off some of our best technical minds to explore what options we had for creating the Web application. This exploration brought into sharp focus that design a Web application is very different than designing a desktop application. It was like the difference between working with bronze or clay: you can create works of wonder using each material but you can not expect the materials to respond in the same ways. Using Swing to create a desktop application was like working with clay: very flexible with a rich set of widgets. Working on the Web was like working in bronze, more restrictive.

However, the rewards for working on the Web were also richer. One reward is that the Web is more available to users than a desktop. Our hectic business user would have access to statistics about his enterprise even while on an important trip. Our brilliant business-to-business-centric user would be able to communicate status about orders to our other users. Our crucial operations user would be able to ensure the smooth running of her business-to-business enterprise even at home. And best of all, they would all be using the same Web-based GUI.

Identifying Example Charts and Tables

Having read the requirements, our team knew that we could not possibly know every chart and table that would be needed to shown on our dashboard. What we did know is that we needed good examples that could be shown in a Web 2.0 application, and which contained data that each type of user would care about. Given these examples the customer could add their own charts and tables. Our team to came up with the charts and tables shown below.

 

Working on the Mock-Up

With the example charts in hand and an understanding of our development material (bronze), we started to tackle the next major task of designing the user interface. Working with Sun's Software Experience Design (xDesign) group was key, especially given that we had to create a way to allow our users to explore their data. This would require that we invent a way to show a hierarchical structure where a node can have thousands of children — a paginated tree. These experts quickly created screen designs and acted as much-needed guides on the path to creating a mock-up that we could show to users.

As of this writing we are exploring several other looks for this widget by creating a working prototype. However, ultimately we may follow one of my rules of thumb, ‘ when in doubt let the user decide what works for them ’.

Not the Final Destination, But a Good Stopping Point

At the end of this part of the design journey, we had several things to show for our efforts. The mock-up and some running code. We were able to see how the mock-up fulfilled the needs of our users and knew we were at a good stopping point.

• The business user could find out how much money was sent/received.
• The operations user could monitor the health of the system and check key tasks.
• The business-to-business-centric user could find the data they needed to track, fix it and send it back to an enterprise.

We are confident that the design work we have done will help us create the right application for our users, and that, after all, is the point of any journey in design.

Leon Barnard is an Interaction Designer in xDesign, who is working on SOA/BI and NetBeans products. He recently moved from Los Angeles to Prague and is enjoying Czech food and not needing a car.

My job as an interaction designer is to create designs that help users accomplish their tasks more quickly and/or more easily. Sometimes this is done through surface-level changes like adding emphasis to frequently used actions, adjusting spacing and layout, or by using clearer instructions. The most successful projects, however, often involve taking a very complex task and changing its components so that achieving the desired result becomes less complex. This is much more difficult to do, yet more fun and rewarding. I was recently tasked with making the development and design of WSDL files easier. Since the task is so complex, I wanted to try to devise a better way of accomplishing it that would help novices learn the technology, as well as help experts focus on what they care about most.

WSDL ("Web Services Description Language") is a complex language used to create web services. Web services are computer programs that can be used by many different organizations or individual programmers, to perform a function they can’t perform themselves or perhaps that they don’t want to try and recreate themselves. An infinite variety of transactions and queries can be conducted quickly and efficiently without requiring any special software or network configuration. WSDL has a standard format for taking a request, processing the request, and then providing a response to the source of the request. The processing part is where a company, like Google, would provide its program’s function (called a “service”, or “web service” in this world). While the format is standard and predictable, it’s also created with the computer, not the human, in mind. So the syntax is relatively complex and unintuitive for most less-than-expert folks.

These characteristics of WSDL syntax distract users from their primary task and add confusion, especially for novices. The precise 'what', 'how', and 'where' that the user is concerned with takes up relatively little space in the code. Ideally, this content would take precedence, and the rest would go to the background or, even better, be handled "behind-the-scenes" automatically.

Our design addresses these issues. The biggest change that we made to the existing editor was to move to a more visual, connection-based presentation. In this way, users can see, even at a glance, which pieces were connected to which, allowing them to follow the stream of connections across the file. It prevents errors of mis-typing the names of objects to be connected, because creating a visual connection automatically writes the appropriate code for the user. Next, the core 'what', 'how', and 'where' elements are represented as salient visual objects that draw the user's attention, while the container objects are shown simply as dotted lines surrounding their contents. These visual representations allow users to easily see what they care about most, yet also understand how they are grouped. Finally, some workflow improvements were added to train novice WSDL users and save time for both experts and novices. These include: dragging-and-dropping from a palette, previewing valid drop locations, automatically creating objects and their containers (if necessary) when a connection is made, prompting for necessary configuration information when certain types of objects are added, and being able to collapse groups of objects that are not being worked on, among others.

In summary, the new design offers the following benefits:

• Uses a flow/connection-based model for visualization.
• The focus is on the meaningful elements (not the "container" elements).
• Follows the principle of "recognition rather than recall".
• Drag-and-drop for faster and more intuitive use.
• Multiple steps can be performed at once.
• Is more discoverable and approachable for novices.

Here are some more snapshots of the new design:

Nalini Kotamraju is a user researcher in xDesign, and a PhD in Sociology. She has a penchant for research methods and telling it exactly like it is.

Years ago, shortly after I joined the Software User Experience Group (xDesign) at Sun, my manager asked me whether I would be willing and able to conduct a usability study of a new CLI for one of our software products, Sun Cluster. I, the ever eager new employee, promptly responded yes, that I'd be thrilled to do such a study. I then withdrew to my desk, and typed "CLI" in Google to figure out what it meant.

CLI stands, of course, for command line interface, which is a way to interact with software or an operating system. Once I met with the product team and had my first look at the CLI, I understood why my manger had wanted to feel out my reaction to this kind of study. By the time I joined Sun I was a veteran at usability studies, having led many a user through a graphic interface in paper prototypes or interactive mock-ups (usually web sites of now-failed dot.coms). Testing the intuitiveness of the content and structure of a CLI, initially seemed to be simultaneously a tedious bore (only a bunch of cryptic words, no images?) and a memory challenge (learning how to string those same words together to make software do something?).

However, the usability study of this CLI turned out to be one of the favorite usability studies that I've conducted in the past decade. The fact that those words come out of my mouth still makes people who know me, even a little bit, laugh. What was so great about this study?

What made the study great wasn't just the team's ability to follow through on the findings from the usability study; thankfully, that happens regularly, though to varying degrees. Nor was it the rich feedback that we did indeed receive from the usability participants themselves. What made this usability study great, for me as the researcher, was the commitment of the product team. It's the most dedicated team with which I've ever worked on a usability study.

The software engineers on the product team were committed to hearing what actual breathing users had to say about the proposed changes to the CLI, which is rare, particularly in the context of what was a politically charged project. They hadn't made the changes to the CLI lightly, and they were passionate about making sure that what they had come up with would work for their users. In addition, they were willing to participate fully in the preparation, execution and post-analysis of the usability study, which is a rare occurrence in a field in which usability studies are often used as after-the-fact rubber stamps to mollify potential internal critics rather than to improve products.

Most of the team had never seen a usability study, so we toured the usability labs in Menlo Park, California. After a discussion of various research methods, they accepted that questions about a statistically significant population of users had no place in what we were about to do. Their commitment also involved spending painstaking hours with me, preparing me for the potential questions of live participants, by explaining how the most popular commands were executed both in the original and the proposed CLI, and, most interesting, how it connected to the underlying software structure. They not only attended the usability sessions, but mandated that other engineers, doc writers, and marketing staff on the project attend as well. My manager, who dropped by one of the usability study sessions, said he couldn't enter the observation room (of our largest lab, nonetheless) because it was chock full of observers.

And all this for a usability study for a bunch of words. Just kidding.

Jen McGinn is an interaction designer in xDesign who is working to improve the user experience with the Java Enterprise System installers. She has an MS in Human Factors in Information Design and works out of Sun's campus in Massachusetts.

Over the last week, a usability email list that I belong to has been discussing Don Norman's article, "Simplicity Is Highly Overrated".

In this article, Don Norman talks about his experiences with consumer electronics in Korea, which illustrate something that he has seen time and time again during his 40-some years in the usability field: people choose products with more features at purchase time, because people interpret more features to mean that a product is more powerful and prestigious, and that the features give them more control. Likewise, people will pay more money for products with more features; even when the buyers understand that more features mean more complexity, and as a result, lower usability.

I wasn't as shocked by Don Norman's article as were some of the usability professionals on the email list, because I'd read the Harvard Business Review article, "Defeating Feature Fatigue" (February 2006), which discussed the trade-offs between features and usability, and the relationship between initial sales and customer satisfaction over time. It cites one study as finding that 85% of returned home networking products were returned because people couldn't get them to work.

Barry Schwartz, in Paradox of Choice, describes our anticipation of our experience with a thing as "expected utility" and the actual use of the thing as the "experienced utility". When our experience (experienced utility) is too far removed from what we expected it to be (expected utility), we are confused and uncomfortable (the technical term is "cognitive dissonance").

So while a product with more features appeals to us at purchase time, if our expectations of it conflict with our user experience of it, that tension can make us feel insecure about using the product, feel less satisfaction in owning it, or lead to returning it all together.

Loren Mack is a design architect in xDesign who creates strategic and tactical designs for the Service Oriented Architecture/Business Integration group at Sun.

This is the third entry in a multi-part series (View Part 1) | (View Part 2). In this part, Loren describes the findings of the user research that was conducted.

To solve the problems that we found, we followed classic user-centered design methodology: we didn't start with design. Instead we started by learning about our users. We visited several health care facilities that were already using the current version of the system, and we observed. We learned that health care professionals are very careful and methodical in their work. When they create a "match" between records, they’re certain it is, in fact, a match. They are serious (serious as my Granddad's gun-locker).

It turns out that most of the records that the system can’t match are easily matched by a human. Some common sense, some knowledge of the history of the hospital or facility where they work, experience with mistakes of the past — all of these things make it easier for humans, rather than for computer systems, to match certain types of duplicates.

For the handful of records that aren’t easily matched, quite a bit of legwork is required to figure out what should be done. Researching files, making telephone calls, talking to people in their facility, all of these tasks may be necessary to ultimately resolve a single case. Sometimes the resolution can take days, so our users may have a stack of "pending" matches on their desk that require their attention.

To further complicate matters, there’s an important standard with which all healthcare facilities must comply regarding confidentiality. You may have heard about this standard: HIPAA (Health Insurance Portability and Accountability Act of 1996). Most physicians require you to sign a paper stating you’ve read about and understand it before they’ll accept you as a patient. In the context of our project, we found out that each time someone looks at anyone’s medical information that "viewing" is recorded as a transaction to ensure complete confidentiality. So nobody’s flipping through medical files willy-nilly — they’re doing it because it's important (see previous "gun-locker" note).

After learning about our users, the problem was distilled into "How can we help them match multiple records quickly and easily, while allowing them some way of reversing a match if it turns out to be a mistake?" We started the process of brainstorming and kicking around design ideas. We mapped out the health care professionals' tasks and optimized the flows so that the most frequent and critical actions took the fewest number of steps.

This work resulted in a few key design requirements to make the complex matches easier to perform and track:

• The ability to quickly see just enough information to determine if further research would be needed
• The ability to see all the information across multiple systems (and to easily highlight the differences)
• Having some way of putting a case in a "to be researched" or "pending" stack so that it could be retrieved quickly when new information became available

…and, of course…

• Some easy way to reverse a match if it turns out to be an error

This kind of meaningful design work doesn’t happen that often, so when it does it’s really cool. Designing something that makes a difference to a lot of folks, not just the technical community — it's enough to make a guy proud. Sort of reminds me why I decided to do this kind of work in the first place.