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 01, 2007

Deconstructing the Redesign

Jiri Mzourek is a senior manager in xDesign, responsible for Sun Developer Products and SOA/BI. In his spare time, he evangelizes usability in the Czech Republic by organizing SIGCHI meetings, World Usability Day, and working closely with the Czech Technical University on usability and accessibility related projects.

In May of 2006 Jan Rojcek began a redesign of the web site based on the results of some out-of-the-box usability tests that we'd conducted. You can find one example of the test on our opensource website

The main issues were:
  • The design didn't work well for a new visitor (potential user)
  • To see a NetBeans screenshot, a visitor had to select the correct link from the 42 available links on the home page, and 38 links on NetBeans product page
  • A visitor had the same problem (choosing the right link from 42 or 38) when trying to get to a comprehensive feature description
  • There were 4 pages describing what NetBeans was (First time here?, IDE, Switch, About)
  • Download took at least 3 well-aimed clicks
  • Usability study findings:
    • 3 participants (out of 8) couldn't find how much NetBeans cost!
    • 5 participants reported missing screen shots and too much text on the web site
    • 3 participants reported they had to browse too many pages to find basic information

With this (scary) list of issues, Jano got a "go" to go ahead with the redesign.

He worked with the stakeholders (NetBeans engineering, marketing and webteam) to agree on the main goals of the redesign:

  • New visitor (potential user – not currently using NetBeans) is our primary target
  • Make the basics clear
    • “What is it NetBeans?”
    • “How much does it cost?”
    • “What is so good about it?”
    • “Why should I start to use it?”
  • Make download straightforward
  • Make more attractive
The redesign was focused on the homepage, product page, download page, docs and support page.

Jano created the first sketch of the new homepage:

He sent it to Leos Tronicek (a visual designer), who created two options:

Stakeholders picked the blue one. So Jano, Josef Holy (another interaction designer) and the NetBeans web team fine tuned that one and created a prototype, which was put on staging server.

So, what was next? Of course, Jano wanted to make sure the redesign met the design goals, so he created a script for a second usability study, which was then conducted in September 2006 by Jakub Franc (a user researcher) and Josef Holy. Sorry, that test report is not public, but here is a list of the main issues found with this design for the homepage:

  • The upper banner with the main download button seemed to be ignored by significant number of participants.
  • A majority of participants complained that information on the homepage did not inform them about NetBeans sufficiently. They expected "short", "summarized", "introductory", "high level" information about the product.

Based on those results, Jano polished the design:

The new website was launched on October 30, 2006, on schedule.

For NetBeans 6.0 there will be couple of new changes, driven mainly by simplified NetBeans packaging and download. We'll get rid of the whole "Add-on" section which will mean updating the layout of the whole front page. Details are still TBD.


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


« July 2016