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.

A few weeks back, I had the opportunity to sit down and chat with my colleagues, Chip Alexander and Karen Stanley, about the Sun Web Application Guidelines.

Chip Alexander is the User Interface Architect for Sun's Web Applications and co-led the user interface design for the Java Look and Feel Design Guidelines: Advanced Topics.  He has 21 years of experience designing intuitive user interfaces and leading user interface design teams, 6 of them here at Sun.

Karen Stanley is the former Project Manager of the Web Application Guidelines, and has been the lead for making the guidelines available externally. She has worked in the HCI field for 20 years, with experience designing software applications and user interface components, usability testing, and project management.

 
Jen:  Chip, Karen, how do you describe what the Sun Web Application Guidelines are?

Chip: They are a set of building blocks for web applications that have been designed by user interface specialists, thoroughly thought through and usability tested.  They can be used for developing full web applications, allowing designers and developers to focus on their application's particular needs rather than the design of all the controls and elements inside.

Jen: So how long have they been under development at Sun?

Chip: Over six years -- they were started by Robin Jeffries (now at Google) and Tom Spine (now at AutoDesk). The guidelines came first and then the User Interface Review Board (UIRB) was established to help ensure compliance with the guidelines.

Karen: Tom and Robin started seeing applications built for the web, but every group in Sun was designing them differently. Tom saw an opportunity to align the look and feel of web applications at Sun before things got too out of control, so Sun could show a single face to the world.

Jen: Over the years, who else has contributed to the guidelines?

Chip: I've been the architect for the team for the last 5 years or so, and the project management was done by myself, then by Karen Stanley, and now by Liz Clayton. We have the full list of contributors included in the guidelines.

Jen: I know that the guidelines have been Sun-internal all this time, so why are we releasing them now?

Karen: The project Woodstock components are available under an open source license, but there are no guidelines on how to use them. We wanted the open source community to benefit from the guidelines. We've had a close relationship with the Woodstock team during the development of the components — there's been a lot of give and take, back and forth.

Chip: The Woodstock web app components are based on the guidelines, which explain the specifics of how and when or where to use them. The benefit is that web app developers can draw on our design expertise and years of work, giving them more time to build their applications.

Karen: And to see how the designs were intended to be used. We're trying to share our internal work, so that anyone using the Woodstock components will have examples of the components being used in context. The guidelines provide numerous screen-shots showing the components used in the context of an application.

Jen: So why not publish the guidelines as a book, like Sun did with the Java Look and Feel Guidelines?

Karen: The environment is changing. Mary Lautman, the manager of the Woodstock team, has been asking for these guidelines to go public since the components went open source. The amount of work it would take to publish the guidelines as a book is prohibitive. It would take too long — they would be out of date as soon as they were published. This way, we can update them more quickly. The guidelines can be revised as the Woodstock components are revised. Not creating a book and instead releasing our work to the public allows more agility for Sun and ensures that web app developers always have the most up-to-date tools for building their applications.

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.

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.

Will Walker is a senior staff engineer in the Accessibility Program Office. He has worked on software for people with disabilities for almost two decades and currently leads the Orca screen reader project.

At the end of August, I had a chance to sit down with Will Walker, and learn more about the Orca project. To quote their GNOME project page, Orca is a flexible, extensible, and powerful assistive technology for people with visual impairments. Using various combinations of speech synthesis, braille, and magnification, Orca helps provide access to applications and toolkits that support the AT-SPI. AT-SPI stands for "assistive technology service provider interface" and the GNOME desktop implements this API.

Will has had a long history working with assistive technologies. First, at Digital Equipment Corporation, he worked on making the X Window System accessible to people with disabilities, which included work on RAP, one of the first service-based approaches to accessibility. Then, at Sun, he helped author the Java Accessibility API. Next, he joined Sun Labs to work on speech synthesis and recognition, before moving back into the Accessibility Program Office (APO) to lead Orca.

Jen: Will, tell me about your involvement in the Orca project.

Will: The first thing we did was to hire Mike Pedersen, a usability expert in screen reading who also happens to be an end user. I was really tired of people without disabilities defining the user experience for people with disabilities. It was important to have a person with a disability in a leadership role to define the user experience. I put Mike in that role. We then formed the Orca advisory board. This was a small group of friends and family who had visual impairments and different use patterns: some people used braille, some people used speech, some people with low-vision used magnification and then we had combinations of all of those.

We asked them, "What do you want a screen reader to do?" "What's your typical day like?". We developed some form of personas and adopted the mantra of the User Experience will drive the architecture, not the other way around. This focus created wins across the board:

• Any decision we made was based on direct user experience
• We avoided over-generalization, but instead solved specific user problems
• We did rapid prototyping all the way

Every so often, we'd stop and refactor as necessary to support new user experience patterns as they emerged. From a modularity standpoint, we used the rule that "we will generalize when the use case exceeds 1".

We also asked ourselves questions to help us make some simplifying assumptions. Did we want Orca to be all things to all people? Did we want to cover more than one platform? We decided to focus Orca on providing access to the GNOME desktop for the professional. This allowed us to simplify by keeping the problem space limited to office productivity applications such as email, web browsing and content management; we didn't have to worry about CD players or games. While this may seem limiting, it is still a huge task with a wide spectrum of problems. As such, we felt like we could generalize to other areas once we better understood the office productivity problem space.

A couple years later, Orca is the official screen reader for GNOME and we are getting a lot of positive feedback from around the world. Mike continues to play a pivotal role -- anything to do with user interaction involves consultation with Mike and our new public list, orca-list@gnome.org, which has over 200 members.

Jen: What's happening with the Orca community?

Will: A big portion of the project involves building "the community." In our sense of the word, "community" isn't restricted to developers. More importantly, it is mostly users. As part of building the community, we wanted to let users know the team members are accessible, they listen, and they "get it." This was done by making a concerted effort to establish effective communication channels for the community.

The primary communication channels we use are the orca-list@gnome.org list and the #orca IRC channel on irc.gnome.org. The team monitors these and regularly engages users in productive conversations. More recently, we have also seen users frequently help other users, which is a great sign of a community that is growing and thriving. I often try to remind myself not to jump into a conversation, but to instead let it happen. Letting people have the freedom to talk can help them emerge as experts.

We have some ground rules for communicating: problems have to come with a constructive suggestion; new members will be treated with respect; and abusive people get private warnings. By keeping a positive atmosphere, we can have an open dialog. We can ask users what they want and why they want it. We can ask what tasks they are trying to accomplish, and then explore different interaction models to arrive at the best solution.

Finally, I need to say that the other team members employed by Sun are also part of this big community. Rich Burridge, for example, is a very valuable member of the team and is well respected in the Orca community. It's just great to be surrounded by such a good crew of folks.

Jen: So what do you think the biggest benefits are or were of having that kind of direct access to your users?

Will: That direct contact has paid off in many ways: users began to have direct personal relationships with the developers and with each other. As a result, the users felt empowered that their requirements were valued and that their voices were being heard.

Direct access also helped the development team understand the domain better. While we all have been involved in accessibility for some time, there is still always a lot to learn, and what better way to learn than to talk directly with end users.

Direct access to our users also helped grow our virtual team. We have an early adopter in Spain, Francisco Javier Dorado Martínez, who helped push Orca adoption throughout Spain. He gives us patches and is thrilled to see his name in the change log. We had worked for months via e-mail, and I finally met him in person at Software Libre 2007. One of the first things he told me was that he was amazed he could mention a bug or feature request and see it in a build later that day.

The respect and thrill is also a two way street. The reason I was at Software Libre was to give a talk on Orca. Based upon the circumstances at the time -- the conference was in Spanish! -- and my familiarity with Javier, I made a last-minute decision to have Javier join me on stage. He was very effective. I've heard reports that he was the hit of the show. I would not have made the same decision had I not had direct communication with Javier in the months prior to the conference.

Finally, from my perspective, the emails that we get that say "thank you" are what keep me going.

Jen: Will, we've talked about what Orca is, and the involvement of the users, but now I want to know: what's the value of open source?

Will: One value to our users is that they can get updates the second we check in a change; not in six months or a year. The open source nature of the project is also very empowering for our users. All of the bugs and the decision-making processes are public. User requests and bug reports are managed in our public database, so there's a written record that they can follow; they see the discussion and the fix.

From a development perspective, we also get new functionality and bug fixes from the community. There are a lot of contributors to thank, but I'd like to highlight a person on our virtual team: Joanmarie Diggs. Joanmarie produces in her spare time the equivalent of a full-time developer and is responsible for significant portions of Orca. Wow! It's just amazing to get that kind of contribution.

We also have other contributors who are being funded by the Mozilla Foundation. Eitan Isaacson is helping us out a lot with migrating to unified bindings for AT-SPI as well as helping with our regression testing framework. In the coming months, I'm going to be relying upon Eitan to help refactor the speech support and roll in support for contracted braille. Scott Haeger has been focusing on providing access to emerging web technologies such as ARIA. I'm very thrilled that the Mozilla Foundation is involved in Orca -- Aaron Leventhal, if you read this, thanks for your support!

Last, Ubuntu has been instrumental in the success of Orca. Like Sun, Ubuntu has embraced accessibility. For example it has accessible install, which is the ability to install an application without assistance from a sighted person. More and more people migrated to Ubuntu as a result of accessible install. The fact that accessible install was such a huge differentiator was an eye-opener for me; I plan to pursue it aggressively for OpenSolaris.

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.

Brian Ehret is an interaction designer working on Sun's identity management products. He has a Ph.D. in cognitive psychology and works out of Sun's campus in Colorado.

Recently, I had a talk with Brian Ehret, the UI designer behind the web-based installer for our open source directory server, OpenDS. The really compelling thing about this installer (and it's hard to really make an installer compelling) is that it's launched right from the browser, so the user can configure the directory server properties without manually downloading a local installer application; everything is handled by Java Web Start. I know -- that was the promise of Java all along, and now, here we are :)

Jen: Brian, can you tell me what existed before the browser-based installer for OpenDS?

Brian: The open source project went live on java.net late in June 2006. At that point, you'd download a zip file to install the directory server, and then run "setup", a command-line utility that prompts you for configuration information. We wanted to drive adoption, so that meant making the software easier to evaluate. But we still support the setup utility for people who don't have web connectivity on their install machine or who simply prefer to use command line.

Jen: So how did you get from the traditional installer paradigm, of running a local application, to running the installer from the browser?

Brian: In one of my early meetings with the team, one of the developers mentioned the idea of using Java Web Start for upgrade and it just seemed like a natural use of the technology for installation. Since the primary face of the project is the website, the idea of putting a link up there that would launch a GUI capable of downloading, installing, configuring, loading with data, and even starting the server in a few quick steps seemed really cool. I put it in the spec along with the panel designs and the developers put in the plumbing to make it work.

Jen: Boy, I wish I'd thought of that. What's the user feedback been like?

Brian: I wish I had good numbers on how many people are using the web setup versus the command-line tool, but we don't yet. We did get some feedback on the user experience and that person's feedback was great; we've already made improvements based on his suggestions.

Jen: So, what's next?

Brian: We're now working on adding upgrade capability to the installer so that users can click the web start link and upgrade their servers to the latest weekly build of OpenDS. The idea is to allow them to stay up to date without having to install a fresh server and then have to configure the server all over again. We are also adding some additional capabilities such as configuring data replication between servers. The design spec and an HTML mockup of the installer is up on our project wiki.