Monday Sep 15, 2008

Project Kenai Goes Live!

Jim Berney is a senior user experience designer working on Project Kenai.  Jim's been designing both consumer and enterprise applications for over 20 years.

Friday, September 5th, the switch was thrown to make Project Kenai live.  Given that over a year has gone by and lot's of hard work by all, it was an exciting moment.

Since one of the original goals for Project Kenai was to demonstrate web2.0 technologies, the project followed the Agile Development model.  Coming from 8 years of supporting the Java ES middle-ware products where design/development cycles could span over a year, the quick pace of the Agile model was something new.   Design cycles are weeks, not months, or even years.  Instead of one huge delivery at the end, the site functionality and UI evolve.  This allows a much longer alpha period where users can begin to engage with the site, and in the case of Kenai, create new projects and begin working with the features to provide feedback. 

The Project Kenai team set aside the time to perform usability testing after key milestones to obtain additional feedback and to validate design.  Two usability studies have been performed to date, one at the beginning of the private beta period and another just recently in July 2008 before the public beta began.  Also, Project Kenai is using an interactive tool from to collect user feedback in real-time, allowing users to submit, vote, and comment on issues.  Take a look at the preliminary results.

Assuming that user experience design is iterative, the Agile model fits nicely.  Instead of spending a lot of time delivering a fully designed specification (that is never right the first go around), you spend shorter durations of time working on specific layout, component, or page design.  In an Agile model, each new feature, component, or element of design is allocated into a design iteration (the team refers to an iteration as a sprint).  Each iteration is given a concise start and end date.

Deciding how to chunk your design into iterations requires some thought and planning.  In some cases, a single iteration may not be enough time to complete the design features allocated for that iteration.  For example, let's say you're designing the Search feature and how search results will be displayed.  This effort may require multiple iterations both for design and engineering.  Some chunks may also require longer periods of time than originally anticipated.  Leaving slack time in each iteration to support some amount of catch up from the previous iteration is a good idea.  If at all possible, use your bug tracking tool to capture and repackage the unfinished work from each previous iteration.  As you plan your iterations, assume design rework.  Design is going to change, and that change will have ripple effects throughout your interface.

The Agile Model doesn't come without challenges.  Since design is approached as a series of chunks, each containing a discrete set of features, an overall design road-map is important.  Otherwise, your design will come across as piece meal and may not fit together well at the end.  A style guide (brief specification) and set of design templates (e.g., using Illustrator or Visio) can help ensure your design stays on track.  As decisions are made, the style guide and templates are updated accordingly.  I have found that using a wiki to post wireframes, design rationale, and team discussions to be a quick and effective means of communicating.  The wiki, coupled with the wireframes and style guide become the design specification for the project.  Since each project created in Project Kenai is provisioned by default with a wiki, I was able to create a xDesign project, then use the wiki for specification.

Your design road-map must include the visual design for the project.  Once you start to move a design from wireframe to implementation, some level of visual design is assumed.  Thus, unless you plan on lot's of rework, effort should be spent in the beginning of the project to ensure that your visual design is adequate for the first phase of the project.  This is not to say that visual design will not change, but that site-wide changes are major and will disrupt an Agile model.   Each rev of your visual design should be planned and scheduled into the project delivery.

Another problem to guard against is "style creep", where you start off using one style for component design or layout, then as the design matures, the style creeps or morphs into something else, leaving your site with inconsistent look and behavior and requiring a lot of rework across the site.

Reusable components may seem a no brainer, but selecting, customizing, and implementing them isn't.  Since Project Kenai was unlike any other web project at Sun, there wasn't a style guide or UI toolkit just sitting on the shelf waiting to be used.  Everything had to be redefined.  Sure, you can attempt to use third-party widgets and toolkits, but rarely do they just drop in to your design.  Finding and implementing the right components is a critical dependency and must be scheduled.  This was in stark contrast to the Java ES environment where there was an established style guide (Sun Web Application Guidelines) and toolkit (Woodstock).

Early on, the Kenai Project organized a UI team (referred to as a scrum in the Agile Methodology) that included interaction design, product marketing, and engineering.  This team meets at the beginning of each design iteration to specify and design new features, pages, and interaction for the upcoming design/development iteration.  Wireframes are produced that allow the team to visualize and refine the design.  Once the design is approved, engineering begins implementation.

Over the past year xDesign has worked as an integral part of the Project Kenai team to lead the user experience design.  This effort has included user research, conceptual and page level design wireframes, visual design concepts and production artifacts, usability testing, and much of the html/css markup embedded in the rails applications to implement each page.  Design and change take time, but the Project Kenai team is dedicated to collecting and taking action on user feedback.  

Now that Project Kenai is in public beta, the next few months will be spent refining the navigation, refining the layout of key pages, implementing usability enhancements, and enhancing the visual design.  Watch the beta evolve with each new build!

Wednesday Aug 06, 2008

JavaFX Preview Release

Jeff HoffmanJeff Hoffman is the lead user experience designer working on Java Standard Edition and JavaFX. He's been designing both consumer and developer oriented products since before the boom.

Sun has released the preview version of the JavaFX SDK. JavaFX is a client scripting technology for creating rich Internet applications (RIAs) with immersive media and content across the multiple screens of your life (that currently means the web and Windows/Mac OS X desktops, but will soon include mobile and TV as well).  You can create applications that look like these:

StockWatcher (JavaFX Sample App) 

JavaFX Clock Sample

The xDesign team has been involved in creating the developer network website that you can check out here. We have also worked with numerous writers and engineers on tutorials and samples to show off some of the great features of JavaFX.

Of course, you'll need to have the Java runtime on your system, and the beta of our upcoming Java 6 Update 10 release can be downloaded from here (click on the first orange button labelled JRE 6 Update 10 Beta). And we've already blogged about our involvement in this release.

If you're a blogaholic, then click on over to the JavaFX Blog for lots of interesting stuff.

Sunday Jun 29, 2008

Recent redesign

I have been working on Java deployment for more than 2 years, and it always happens that the web site is updated just in time for the JavaOne conference. Last year, we improved the download user experience and slightly rebranded the web site; this time was similar.

Actually, I would be lying if I said that this time was not so different. It was -- we were requested to do more changes in a shorter timeframe than last time. However, we succeeded! The big thanks should go to a lot of people who contributed to this effort, especially to Mary Kawahira, who really made the difference. She was working through nights and days to make this project a great success. 

This time, we rebranded the whole web site and further simplified the download user experience. In addition, we removed distracting things from the user's flow and made some other small tweaks. For those who have never visited or who do not remember the previous design, I enclose screenshots (before & after) of the home page. 

previous design of page Current design of page

There is still a continuous effort to further simplify the download user experience and make the web site more simple and useful.

For those, who have the Deployment Toolkit (part of Java 6 Update 10 release which should be available around September; Beta is already out) installed, the user experience will be further simplified. This simplification is for those who run Windows and is not related just to the download flow, but also to the help pages where we will ensure users get the most appropriate information without any effort. We are going to have a user study for this project this week, so we will know more after that. Meantime, I can share some screenshots of the help pages that users are going to evaluate.

The first image shows the suggested appearance of a new help landing page (current design can be found here),

suggested help landing page

another one shows the suggested appearance of a help page when a category is selected (current design can be found here).

 suggested help page 2

If you have any comments or questions on the design of, please comment on this entry. 

Jindra Dinga improves the deployment experience of Java for both developers and end users.

Tuesday Jan 29, 2008

Didn't get what you wanted for the holidays?
How about some new UI components?

Back in October, I talked with Chip Alexander and Karen Stanley about the Sun Web Application Guidelines going public. This move was to support the open source development of the Woodstock component set. Both the guidelines and the UI components had been under development for many years inside of Sun, and last year, they were made available to everyone else.

Then, in December, while everyone else was finishing up holiday shopping and attending parties, the team who creates the components and the most dedicated of the folks who write the guidelines were hard at work on their 4.1 release, which was quietly published on December 19th.

What's new in the Sun Web Application Guidelines, you ask? Quite a few components were added to the existing set, most of which include functionality using AJAX technology. Not all of these designs will be incorporated into the 4.1 Project Woodstock components. Some will be added later, while others will be phased in progressively.

So, as my Dad used to say ... especially after the holidays ... don't say we never gave you anything ;)

Tuesday Jan 22, 2008

Design of the NetBeans download page

Jan Rojcek is the Chief Architect for the NetBeans IDE User Experience, and works directly with the Chief Product Architect at Sun's Offices in Prague, Czech Republic.

Recently we announced a new release of NetBeans IDE, so it seems like the right time to look back at the design of the new NetBeans download page I was involved with. When I started working on this project, it seemed like a straightforward design exercise. Put a few well-named and well-positioned download buttons on the web site and you're done. I should have been cautious given the NetBeans team's desire for achieving excellent out-of-the-box experience. Here's how it all evolved.

The NetBeans IDE is a very large suite of software used by Java, C/C++ and Ruby developers. Normally we would just offer a single download option similar to other complex software like Office suites. But developers love speed and simple tools and we were also concerned about the download size of the suite which could have been a problem for users with slow and unstable internet connections. So we decided to explore the idea of distributing the suite in a way that would perfectly suit the needs of individual developer. And that's how it all began...

The Online Installer

The obvious idea was to give the user control of selecting individual NetBeans components for download and installation. One of the solutions was to use a so-called online installer. The user downloads the installer, and during installation selects components the installer then downloads and installs. Well, sounds like the right way to go, but not everyone is online during installation. We decided to pursue a Custom Download solution instead...

Custom Download

Another obvious idea was to let the user select the NetBeans components he or she wants to download right on the download page. The only design concern we had was around the fact that it wasn't a very standard way of downloading software. We were not sure if users would understand it and whether they could use it effectively. To find out, we did a usability study where we tested the download page prototype and it turned out to be well received. But a much bigger concern was the actual implementation of this solution as it either involved preparing all possible download combinations in advance (literally terabytes of data) or having an active server that prepares the download based on the individual user's request. As both approaches seemed a little too risky, we decided to try an "editions" solution...


This is basically a well known way of downloading different configurations, or "editions" of the same product. Each edition has a fixed set of components and the user downloads the edition that works best for him or her. We started with three editions called "Basic", "Standard" and "Full", and used a download page layout that looked like a table with each column representing one edition. That worked okay, but then we decided to align editions better with the needs of our target audience. We ended up with 6 editions: "Java SE", "Web & Java EE", "Mobility", "C/C++", "Ruby" and "All". At this point the table with 6 columns started to look like a brain teaser, which is not what we wanted for an easy product download. Thus we tried a List Layout...

Editions - List Layout

We tried many different layouts of the page to best reflect that the different editions are actually the same product. We also tried to communicate the difference between editions without the need to read the description of each edition five times to notice the difference. All that, plus a vertical space limitation as we wanted to fit all download buttons on the page without vertical scrolling (worse case was ~570px height on 1024x768 screens running Firefox with tabs open). As we were unhappy with the designs we came up with, we went back to the Table Layout...

Editions - Table Layout

The NetBeans Evangelists team felt like the table design best reflects "the only IDE you need" story and it also best describes the difference between editions, so we decided to improve it with better wording and rollover effects. Then we did a usability study and we were quite surprised that the study yielded great results. The download page itself was not an issue at all. Users quickly understood the concept and downloaded what they needed based on their preference. Eventually, we used it for the release of NetBeans IDE 6.0.

Recently we got some positive feedback from a user praising our great download and installation experience, as well as negative feedback citing confusion with the download page where at first sight the user wasn't sure where to click to download NetBeans.

Thinking about this design exercise again and looking at the statistics that majority of users download the "All" bundle, I would tend to say that we should really focus on making the full IDE suite faster, consume less memory, and have simpler menus which would allow us to get rid of the specialized downloads and end up with the simplest and easiest download page with a single download button.

Monday Jan 14, 2008

Easily Skinnable Swing Components

Dusan Pavlica is a senior Interaction Designer in the xDesign group. He moved from Prague to Los Angeles to support SOA/BI team, but he is working on JavaFX project currently.

The main idea of skinnable Swing components came up after James Gosling's presentation of Matisse (new GUI builder in NetBeans) at JavaOne 2005. Some people from audience were really excited about cool components used in the demo of the MP3 player. The components looked like rounded buttons with nice skins and completely different than the typical ugly Swing components. I would say the presentation was successful because of the cool look of the components.

So then, within the scope of the Innovation project (project focused on innovative ideas and design approaches in Prague's xDesign Group), we were thinking about some improvements of Matisse related to the ability to change components' skins easily. Then Jan Taus joined our team and was willing to work on it as a part of his Master's Thesis. I led him to implement it in a way that the user can re-skin a component easily without needing to write code.

He created an experimental NetBeans plug-in, which allows the user to set new skins of components in a visual way without coding. The user can prepare skins and even animations in a visual editor (e.g. Photoshop) and then can easily apply them to components in the Theme Editor.

There is a screen shot of the Theme Editor:

Some example of buttons in a new skin:

We presented all of the results of our research and experimental version of the Theme Editor to the NetBeans development team. They were interested in it and we discussed how to utilize the idea of easy skinning in NetBeans and the JavaFX project too. In my opinion, the improved version of the Theme Editor (e.g. its UI can be polished or it can be integrated into the Matisse better) could increase the popularity of Matisse or support the success of JavaFX.

Wednesday Dec 26, 2007

The Deployment Toolkit

Jindrich Dinga is an Interaction Designer at Sun Microsystems, and he currently designs developer and consumer software.

It has been a couple of months since we posted the blog entry about changes to the Java installer. Today I want to tell you a couple of things about another usability improvement in the deployment area -- the Deployment Toolkit (DT).

If you're responsible for a web site that provides Java content, like games, applets or other features, you probably struggle with these common concerns: What if people who come to the site don't have the latest Java? Will they come back to the site after they get the latest Java? Are they confused when they have to allow an ActiveX control to run? There are currently a whole set of related issues. Using the Deployment Toolkit, however, these issues will be gone.

The Deployment Toolkit consists of some Javascript code and a browser plug-in. It works with the majority of browsers on Windows. DT will be delivered as a part of the basic Java installation, and because it is signed by Microsoft, Windows users who have it on their machine will no longer see an ActiveX warning when they update Java.

So, assuming that users will have the DT plug-in already installed, how will the user experience improve? DT Javascript on your web site will detect if users have the required Java version, and if not, it will redirect them to the web site to download and install the latest. When they're done, it will redirect users back to your web site. This means that users will no longer get lost or distracted, and they can continue with your provided Java content. And what if a browser restart is required by the update? No worries -- after the restart, your website will be loaded in the browser automatically.

Now, you may ask when this feature will be available to try? The beta is scheduled for the first quarter 2008 as part of Java release 6uN.

Continue to follow the Design@sun blog to learn about other usability improvements in the Java space.

Wednesday Dec 05, 2007

Brand and Software User Experience

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

I recently spoke to Soraya Younossi, xDesign’s Art Director and Brand Liaison.

Nalini: Tell me about the role of the Brand Experience Group and its relationship to xDesign.

Soraya: As it applies to our software applications, the overall objective of our brand is to ensure that there is an integrated user experience throughout our product offerings. Our objective is to set UI standards that not only meet but exceed our customers' expectations. We must convey a unified and coherent design system that embodies our values and vision.

In order to achieve a seamless user experience across products and platforms, we take on an inclusive approach to design with an emphasis on communication and sharing. We collaborate with teams throughout Sun in an effort to integrate and bridge brand and design standards.

The consumer experiences our brand on a subjective visual plane first and foremost. It is the gateway that sets all the users' expectations that follow. It is therefore critical that the brand expressions and interaction designs are aligned to ensure that we meet our customers’ expectations.

We have taken on a tremendous challenge in setting standards that express our values and culture. These values are captured on many levels of the interaction experience. The look-and-feel is a powerful signifier of real change. The brand promise and reputation rely on how these standards transcend into the deeper levels of the interaction design and user experience.

Nalini: Can you tell me a bit about Nimbus?

Nimbus embodies the design system that defines our software and desktop applications' look-and-feel. It captures our unique values and differentiates us from our competitors. It is a design system that is inclusive and complementary to Sun's overall strategic goals.

It is a system that has been informed by all of Sun’s product offerings. We have examined all of the related touch points--from the web to software to desktop and hardware designs--to ensure a coherent brand expression that transcends domains and reflects one unified message that is aligned with Sun’s strategic goals.

This message has been captured in the choice of the color palette to the stylistic design elements that define and make our interface designs unique. We were conscientious in considering cross-platform constraints to ensure that we would complement the user experience in a consistent manner.

Nalini: What aspects of Nimbus stand out for you?

Soraya: Nimbus is a sophisticated and contemporary design system that is relevant to our times. It reflects a refinement that opens possibilities for designers such as myself. The framework is sound and provides the flexibility for growth and evolution.

My main concern is to ensure that we stay consistent in the implementation of the Nimbus design system and that the design does not stagnate and continues to evolve. It is critical to continue the evolution of the design principles in order to stay competitive in the marketplace.

There is so much that is captured in the framework that still needs to be expressed and showcased in our product offerings. One particular aspect that is of great interest to me is the dimension that falls between the visual design system and the interaction design. It falls into the subjective realm of the brand experience that reflects the detail of care and informs the quality of the user experience.

It is an aspect of the Nimbus framework that we have not addressed to the degree that is needed. It is the element that bridges and satisfies both right and left brain activity. In its simplest expression it ties back to an user experience that not only supports but enhances a particular interaction. We need to move forward and think dynamically, not just statically, about an interface design. I believe that this is part of the challenge that we, as designers, need to address.

Nalini: I’ve often heard the complaint that branding adds complexity to product design, and I’ve heard you say that branding brings simplicity. Can you speak to that?

Soraya: A successful brand translation is about providing a unified message and the guidelines that support it. I would argue that interaction designers focus on the core design features and then provide the standards that help set user expectations.

In order to do that, we simplify the product design by providing guidelines to standards that help enable users to fulfill their tasks. These standards ensure that our customers can rely on a framework that has been implemented consistently throughout our product offerings. These are the building blocks that guide and inform the designers. The manner in which they are combined and structured is up to the individual teams, which shape the creative thinking, individual expression and brand evolution

Nalini: What would you say if I suggested that Sun’s core audience–developers and system administrators–have less of a need than do average consumers to respond emotionally to our products?

Soraya: As I mentioned earlier, everyone is subject to an emotional response to any interaction. It’s a question of weather you choose to validate that or not.

Our goal is to enhance the interaction and user experience of our product offerings. Now, if that improvement is experienced on a subjective as well as an objective plane, then I don’t see a conflict. My personal belief is that a successful product has to capture and take into consideration both the objective as well as the subjective user experience. What is critical is that we meet users' expectations of our product features and help enhance users' ability to do their work in a seamless and supportive framework.

Tuesday Nov 13, 2007

Designing a Color Scheme for Netbeans 6.0

Stepan Doubrava is an interaction designer located in Prague, Czech Republic. He is currently working on improving the user experience for SunStudio and other developer tools at Sun.

As NetBeans began to be a multi-language IDE, we realized it was necessary to make all the syntax highlighting in different editors visually consistent. While creating this new color scheme, I came across several different, and sometimes contradictory, requirements:

  • Lots of colors were needed for different tokens, but not so much as to make the editors look like a crazy fruit salad.
  • The colors needed to be bright and contrast enough so one could recognize the colors on various monitors, but not so bright as to irritate developers who stare at it the whole day.
  • A balance was needed between highlighting everything for expert users, or only the most important tokens for less experienced users, so that everyone could remember the meanings of all the colors.
  • The amount of bold text needed to be reduced due to it's poor readability while keeping the visual structure of the code.

As expected, I came across numerous arguments, where everyone had their own opinion on proposed colors and was eager to share it. In the end, though, we were able to agree on several points.

Here are some of those points and concepts that made it into the current design:

  1. All the spots requiring user intervention are wavy underlined. Errors (red underline), Warnings (yellow underline), Unused fields (gray underline), Deprecated (should have been brown underlined but I had to use the old syntax (black stroked) for deprecated as a trade off for the developers to accept the gray underline for unused fields. I am hoping to bring it up again in the near future.)
  2. Embedded or inactive content has a different background color. For example in HTML, code snippets in JavaScript or CSS Styles are in a sense embedded, therefore highlighted with a different background color as well as guarded blocks in Java.
  3. The selection has a light blue background but the selected text doesn't change its color.

Unfortunately, items (2) and (3) in some sense clash in the current implementation, because when embedded content is selected it has a blue background, which was different from the original intent of showing the original background + blue ... Hopefully we can improve this for the next release.

In the longer term, I believe the concepts used for these design decisions should be reviewed to address the points where we compromised, which would further fine-tune the implementation.

Tuesday Oct 30, 2007

openInstaller User Interface Design

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.

openInstaller screen

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.

Monday Oct 15, 2007

The Sun Web Application Guidelines go public!

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.

Picture of ChipChip 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.

Picture of KarenKaren 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.

Thursday Oct 11, 2007

Refreshing the NetBeans Brand

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.

I recently spoke with Leos Tronicek, a Visual Designer in xDesign and located in Prague, about the recent re-branding of NetBeans. NetBeans is the original free Java IDE, as well as a vibrant open-source project dedicated to providing rock solid software development products (such as NetBeans IDE and NetBeans Platform).

Nalini: Recently you worked on the refresh of NetBeans. What can you tell me about the project?

NetBeans IDE Splash ScreenLeos: We wanted to refresh the visual identity of the NetBeans IDE along with the visual representation of We had been doing small refreshes of the NetBeans brand for each major release of the IDE, but with this release we decided, along with management and marketing, that we could move forward more. We wanted to build an even better visual identity and put guidelines in place. The earlier visual identity was abstract. The initial target audience was very broad so we were really conservative, but now it's more young and fresh. And now we thought more about the use of the NetBeans brand on the web site, that it should work on different media and format, from the web page to billboards to welcome screens. We wanted to maintain the feel and perception of NetBeans so people who see it will still say “OK, it's still NetBeans, but a bit different.” People still have to understand that it's NetBeans from first sight.

Nalini: The refresh of seemed to go really well. Can you say why?

Leos: If you ask anybody (in xDesign) what is the best approach to web site design, they will know. If I ask you or somebody doing a web site what to do first, they know. I would think who is my target audience, what content do you want to show, what do people want to see, what are we trying to push. Then we would discuss, decide what should be where and do some mock-ups and layout and make it nice in visual design. But it usually doesn't work this way. There are so many bad approaches, like “Oh ,we want it just like this other web site we like” or “We want to have everything on the home page.”

This project was better in terms of conception. We started, not from what we would like to have there, but we listened to people, checked some statistics about what are the most visited pages.

The process worked because someone was directing it and saying clearly: "This feature will be this way." Usually everybody is invited to bring comments to any part of the creation process, which is bad. This time it was, “OK, you are a professional in UI design. You get to decide." I could think more about the visual part, how to layout different areas, how to make some parts more visible. I could concentrate very well on the visual part itself because everything was done right, and I had everything I needed. I didn't need to come and explain that if they wanted to do something one way, I would have to do it another way.

They gave me final layouts and said that there might be some tweaks, but said: “This is more or less what it will be in final form so make it work visually.” You have to give the right part to the right professionals. Everybody has an opinion on visual design but it doesn't mean theirs' is the right one. If you visit a doctor and he tells you what to do, you wouldn't do anything else because you think it's better. In visual design it's more common because everyone likes something. Everyone has his own taste, and with visual design it's much easier to lose the control over the design.

Nalini: How did the audience react to the refresh of

Leos: First, we made a beta version and did a usability study, even though we thought it was very good. We found some small issues around workflow and ease-of-use and we made changes that helped a lot.

After the launch, we got some good feedback from inside of Sun and outside of Sun. For this kind of site, it's difficult to maintain the same quality from home page to the last page, which is deep in the structure. For this project I was working with so many people; it went really well. It was a good feeling to work with professionals on a project that went well and followed the plan. The whole creation process was a collective effort, and I was just one part of it. I'm proud of it. And I want to thank all the people that worked on it also.

Thursday Sep 27, 2007

Improving the Java User Experience

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?


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 (, a map locator (, or the virtual view of a cruise ship cabin ( 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.

Monday Sep 24, 2007

The New Solaris Installer (NSI):
Installation Made Easy

Jen McGinn is an interaction designer in xDesign who enjoys creating new things, and then writing about them.

Frank Ludolph is an interaction designer in xDesign with more than 30 years of experience in user interface design and development.

At the end of August, I spoke with Frank Ludolph, the Senior Interaction Designer responsible for greatly simplifying the user experience of installing and upgrading the Solaris operating system.

Jen: Frank, what was the impetus behind the new Solaris installer (NSI)?

Frank: A lot of people find Solaris hard to install. The installer asks a lot of questions that many users don't know how to answer. The first time I tried to install Solaris on my laptop, it took me four tries to successfully install. And the installer had the old 1990's Motif look. The underlying architecture of the software showed through too much as well. For example, system configuration was separate from the installer, so before the installer ran, it asked the user a large number of configuration questions and then threw away the answers when the user was upgrading rather than installing. With the release of Solaris on x86, which broadened the target audience to developers in addition to system administrators, installation needed to be better and easier.

We decided to replace the old installer. The UI team reviewed a number of current operating system installers, both proprietary (Mac OS X and Windows) and open source (SUSE, Fedora, Ubuntu). We decided the goal of the installer should be to do minimal configuration during install; just enough to get you up and running following reboot. During installation, you'd only be asked to choose the installation target, set the clock, assign a root password, set up a user account (so you don't have to log in as root), and specify the language support to be installed. Any specialized configurations, which relatively few users needed, could be done by after the reboot. A new Solaris feature, Network Auto-Magic (NWAM), allowed us to drop network configuration questions because it automatically configures the wired and wireless network connections when the newly installed system is booted.

We then created an interactive UI mock-up that targeted both desktop and enterprise users. This mock-up was used during early engineering discussions when the functionality and architecture were being developed. But we estimated that it would take at least a year to fully implement the new installer. Too long.

Then Solaris Express Developer Edition (SXDE), a fast-moving project targeted at developers, appeared. This project had fewer functional requirements than on the full installer and allowed for a phased implementation of the installer.

In the first phase, guided by our earlier studies, we just cut a lot of questions and screens out of the old installer by choosing defaults appropriate for our target users. The SXDE installer would install developer tools, Sun Studio and NetBeans, and add them to the Launch menu. When the system started up, it automatically configured network connections and greeted users with a web page with developer-specific help. The installer wasn't pretty -- the flow wasn't as smooth as it might be and the visuals were dated, but it was much easier for developers, the target audience of the product, to get a developer desktop up and running.

The second phase of the new Solaris installer, Dwarf, has a modern, branded graphical appearance and a user experience that is the equal to any of today's installers. It still has plumbing from the old installer underneath, but the team worked very hard so that the graphical user interface masks the old architectural underpinnings. The architecture itself will be addressed in the third phase of implementation, named Slim. Future phases will add the support needed by enterprises. When that is complete the old installer can be retired.

Jen: So a little over a year ago, you were working on writing the branded interaction guidelines for system startup, and I was leading the team to write the branded guidelines for install -- I love how I'm seeing convergence between the Solaris installer and the OpenDS installer and the OpenInstaller, as a result.

Frank: Also with respect to consistency in the user experience, the GNOME desktop is themed, and because the Sun theme, Nimbus, is the default on Solaris, the installer picks it up. As a result, the look and feel are consistent from installation through to the desktop experience.

Jen: So what's the coolest thing about the new Solaris installer?

Frank: It has a modern look-and-feel, new users are successful, and the short, six-month SXDE release cycle gives us the opportunity to get feedback quickly from our target audience and make it even better.

Sunday Sep 16, 2007

Simplifying Web Services Description Language (WSDL) Editing

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. New Web Services Description Language (WSDL) EditorI 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:

New Web Services Description Language (WSDL) Editor
New Web Services Description Language (WSDL) Editor
New Web Services Description Language (WSDL) Editor

xDesign is a software user experience design group at Sun.
Follow us on Twitter : Flickr : Blog (see feeds below)


« July 2016