Wednesday Apr 23, 2008

Jeff Hoffman is the lead user experience designer for Java Standard Edition.

Jindra Dinga devotes his time to improving the deployment experience of Java for both developers and end users.

Jeff and Duke at JavaOne 2007In a couple of weeks, my colleague Jindra and I will be presenting our process for creating a graphical user interface to the developers at JavaOne. In my last entry, I mentioned a set of user experience talks happening at this year's conference. Now I'd like to describe a bit more about how we developed our session and what's in it.

At last year's JavaOne, our merry little band of Java UE designers presented a very basic overview of user experience design best practices at a 9pm BOF. We dutifully put together a presentation with slides covering a variety of things, and cheerfully presented them to the much larger than we expected crowd. We were terribly nervous, but overall the experience was great and the questions were great too. Some months later the survey results came in and they weren't bad, but not great... Most of the comments were asking for more detail and more examples, so we started discussion about this year's presentation with that idea.

Based on the feedback, this year we are going to take a real example and walk through our process with it. Since we only have 50 minutes (and some of that time needs to be available for questions), we will try our best to reach the level of detail our audience desires. JavaOne Speaker

At the beginning of our presentation we will talk about why it is hard to create good GUIs and how important it is to understand the user's tasks and goals. Later on we take the existing command line process for configuring a network interface connection in Solaris (see Project Brussels) and make it over in to a GUI.

Jindra and I have spent years in the user experience field and we know that it's hard to follow an exact process for every project. We also know that making sure our designs work for our customers requires that we adhere to the principles of design, and we want to make sure that the developers out there understand how these principles apply to a real design problem.

If you're planning to be at JavaOne, sign up to come to our session (TS-4968). Also, if you'd like to say hello to some of the contributors to this blog, stop by the User Experience pod near the Spin-the-Wheel Game in Sun Booth at the JavaOne Pavilion.

Friday Mar 28, 2008

We have an internal alias where various design folks talk to each other about topics that interest them. The discussions there are usually very interesting and I started to think about ways to publish the conversations on this blog. A synopsis seemed dull, and took away from the dynamics that made the conversation interesting. The thread itself could be too tedious to read post - hoc. Just for a lark, I used the template figures designcomics.org and pikistrips.com to come up with this. (click to see larger version)
my comic strip! my comic strip!
I posted it back to the alias to see what people thought and of course this just spawned another interesting discussion about MS comic chat and the contemporary use of avatars.

I enjoyed the creating the comics. It did take some time to distill the essence of the conversations into a size that would fit in a comic strip. I still have lots of words and little action. Maybe I need a super hero. May be I just need to draw my characters :).

To end this post on a note of humor- I find that the job of soliciting blog post does things to ones brain. Someone said to me the other morning "Good Morning" and I caught myself thinking "hey , that would make a great blog post..... ".

Not unlike this xkcd comic strip -



Some sites to check out:

Tuesday Mar 25, 2008


First of all, I do not like to write.

Not just in English, but in any of the 3 languages I speak.

And for my fellow designers who do like to write (and are probably good at it), I have some bad news: no one likes to read specification documents. Even if the spec. is written in Tolstoy language, people prefer to enjoy Tolstoy language in a novel, in their spare time, and not at work, while developing or testing a complicated product full of hidden features and details.

So, I'd rather name my entry "How do I create my UI specs".

This is what a typical page of my spec looks like:

I use mostly Fireworks and Dreamweaver. I create my images (wireframes or mockups) in Fireworks, then place the image into a pre-made HTML table. The table consists of a nest for an image on the left, and an annotations column on the right.

UI Spec sections that I cover in my annotations column are the following:
1. Page Details: (project name, file name, release #, dates, version, designer name, and page type). Seems like a lot, but some of our products have very similar pages, and spec readers tend to print or bookmark one page here and there, and then have a difficult time recognizing the page they are looking at. By dedicating the top portion of annotations to housekeeping, I make this info always accessible, yet not in your face, so to speak.
2. User Scenario: here I indicate how the user gets to this particular page. Usually by performing an action on a previous spec page, or by opening an application, or both, so there could be several scenarios, and I believe it is necessary to mention all of them.
3. Interaction Rules: The most important part of the spec, of course. As you can see, the wireframe/mockup image is covered with numerous geometric shapes of different colors. These are snippets.

I drag a snippet from the Snippet Panel, give it a number (or a letter), and place it next to the component I'm about to describe in Interaction rules. Note, snippets live in HTML, and NOT in png world. I am not changing the image. Think of it as a sticker. If I have to change the button placing for example, I do not have to redraw the indicator in my png, just simply move the icon when I'm in Dreamweaver. Basically, my images and annotations live in different castles, which is quite handy for editing.
The fact that I place my annotations to the right of the image, makes it very easy to scan and find the appropriate number. If the spec reader is looking for the description of a particular component, he just has to find the right number in the Interaction Rules column and ignore the rest of the information.
4. Page Revision Details: I keep this section to indicate the changes that have been made during numerous revisions of my work. I also use this section to call out uncertainties and TBD areas that need my spec readers' attention. The icon for this section is a lettered blue triangle.
5. Notes: the least visible section - I keep the notes for myself here.

That's for the UI Spec sections.
Of course, there is an index page of all the pages in the spec, a brief description of the project, and special messages to the reader. I sometimes interlink the pages, especially if they are consequent steps of a particular use case.


If some of your spec readers can't access the spec online, you can always create a pdf using Acrobat. It is super easy: choose 'Create PDF doc' > 'From Web Page' > 'Entire Site'. If you are planning to create a PDF, don't forget to name your pages appropriately. Actually, even if you're not planning to create a PDF, still name your HTML pages appropriately - it's like good table manners.

Oh yeah, I use bright orange circle icon to indicate where the text had been changed: we all know that text changes come last, and developers appreciate it if I tell them exactly where they need to retype.

I think that's pretty much it, leave comments if you want to know more.

Monday Mar 17, 2008


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.

 10 Sharp Wizard

 

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.

Sharp HTC 'smart phone'

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.

 


Friday Mar 14, 2008

An object in motion will stay in motion and an object at rest will stay at rest, etc., said Newton. I agree! For me, this is particularly true when it comes to my creative/designing mind. When I'm in the habit of designing and otherwise creating regularly, ideas and energy just begin to flow out more easily. It is more fun to approach, and easier to succeed with design tasks. And when I'm not, well, things get much harder. Stuck, stagnant, uninspired... those become the default designing state. And things go slowly if they do go. Anybody know what I mean? :)

Anyway, last month, I had a wonderful experience that rolled the moss off of my proverbial creative stone :). On a tip from Soraya, I participated in something called Thing-a-Day -- a creative forum where artists and creators of all types signed up online, and agreed to create one "thing-a-day" each day for the month of February.

The medium could be anything -- from painting and drawing, to knitting, music, video, jewelry-making, cooking, robot-building, food sculpture -- whatever. The participants just had to agree to spend somewhere between 20 minutes and an hour each day creating one new thing, then posting it to the community blog, where all the artists/participants could see and comment on each others work daily. I didn't know what to expect when I signed up, but was just looking forward to the challenge of creating something new every day. I gave myself weekly themes, which put some structure around the daily creation, and got to work. The theme for my first week was "morning ritual". Each day that week I did an artwork touching on something I regularly do in the morning. Two of my favorite posts from that week are below:

Well, by 9am the morning after the first day of Thing-a-Day, I knew why I had signed up. 4 new emails were waiting in my inbox -- people responding to what I had posted! This was an unexpected blessing from participating. All of a sudden, I wasn't creating in a vacuum. I posted, and people responded. People posted, I responded. What fun! I spent a bunch of time that same morning making comments on other people's artwork, and enjoying the collective body of work that was growing. I realized how important feedback can be -- to motivate, to inform your design, just to get the energy up around a project.

Anyway, Thing-a-Day was a big success. By the end of February, almost 6,600 new works of art had been created by around 1,400 participants, and an exciting creative community was alive. I personally experienced a giant creative boost by participating, and by getting in the habit of doing creative work every day. The blah/stagnant design fog I had been feeling for months has lifted, and now I'm really really having fun when I sit down to design. And isn't that why we all decided to do this in the first place? I know it is for me -- I love design, and creation in general, and am thankful to be able to do what I do.

The experience has been a great reminder to me of the importance of staying creatively in motion, and also of having a sense of community around what we do. It's got me wondering how we might be able to create similar experiences with what we do here as designers at Sun? I don't know about you all, but sometimes I can feel like a little design island, out here alone. How nice if we can develop more ways to share -- feedback, energy, inspiration, and just an overall greater sense of community to help our work along.

This blog is certainly a great step in the direction! At any rate, I hope you enjoy all the fun work at Thing-a-Day, and find inspiration in it, too :)...

I'll sign off with two more of my favorite posts from the month (snow sculpture emerged as my favorite medium), and then encourage you to check out all the great work that over 1,400 artists posted on Thing-a-Day in February.

http://www.thing-a-day.com

Janet Kowal is a visual designer in xDesign. She has a BS in Graphic Design & Illustration, and enjoys creation of all types. Janet works out of Sun's Menlo Park, CA campus.

 

 

 

Tuesday Mar 11, 2008

Hello,

I turned on google analytics for the blog and will intermittently share the data here.

I turned it on right before Loren's last post and right away we had 80 or so hits from some of the predictable places. This tells me  that most of us  probably have the RSS feed turned on and when we learn that something new is up on the blog - we go check it out.
 a

The average visit length is 2.3 minutes. This is good news. People are either reading the blog entries, or there are staring in stupification at the theme :).

Speaking of themes - if you all are like me (and in this respect I think you are :)) - as soon as you see a new theme , you want to tweak it. So, here is how to do this:

  • Create a blog on blogs.sun or blogs.sfbay
  • Use the "propaganda" theme
  • Download the css file I created
  • Replace the contents of the theme tab in your blog with this css

You are now ready to start tweaking. Send me the results and I will upload them! Don't want to mess with the css - thats fine - send me hex values for colors, mockups, new icons - whatever! Add your notes as comments to this blog (we can test drive the bug-tracker use case for the blog :)). We will share what you send on the blog itself, and find a way to get it into the css template if possible.

Enjoy!
maya


Tuesday Jan 22, 2008

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 NetBeans.org 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...

Editions

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.

Thursday Jan 03, 2008

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

Recently I've been noticing a bit of difficulty among my peers at Sun, as well as other friends I have in the business of design. It seems somewhat widespread that creating good designs, and then having them correctly implemented is a bit of a battle. It makes me think about how leaders of unpopular political resistances must feel as they fight for their position. Speaking their minds, and deploying their Guerrilla fighters to lead the resistance. And here I am, on the side of the Usability Resistance, trying my best to convince the people, overthrow the "usability want-nots", and keep my Guerrillas fighting the good fight.

Guerrillas...

This reminds me rather of a method I and my team have used in the past to design user interfaces. I call it "Guerrilla Interaction Design". It's a way of creating usable GUIs quickly, under pressure (and sometimes under fire). To describe it properly, I should outline a more conventional user-centered design timeline just for reference - which goes something like:

1. Talk with your local, handy-dandy product manager about what they'd like create as a new program, or what they'd like to do to improve an existing one.

2. Get out of the office and go observe users doing what the new program might do, or using the existing one.

3. Figure out what might meet their needs, or improve the experience.

4. Go back to the office and document what users are doing today, and what might be an optimized way of doing it in the future (or possibly what they really need to do).

5. Draw some pictures and create a story.

6. Discuss this with the folks from step 1, and iterate, iterate, iterate.

7. Iterate.

8. Create a paper storyboard, or medium fidelity prototype that someone could review or use to attempt the task with the new, optimized design.

9. Go back out to the field and usability test the design with similar (or the same) users. Observe and document the results and then...

10. Iterate.

11. If you're lucky, all the rough edges are smoothed out and you have a design that delights the users, makes the product manager happy, and is possible to implement by the developers.

12. Deliver your design, and remain "on-call" for potential "gotcha's" that may come up and need quick decisive design action!

Whew! That's a lot of steps! It approximates what most designers might tell you when explaining how to produce a good design, and is a pretty consistent and standard way of achieving a predictable result.

Now... do it in three days...

To be continued...

Thursday Dec 13, 2007

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.


Again, I have a question for you. I have tons of unused Sun swag to exchange for my favorite answers -- a Java gym bag, a Sun CD case, a Sun coffee mug, a desk clock, a laptop bag ... too much to list. Send me a great response to my question, and I'll let you pick.

Here's the thing ... we all have mobile devices: cell phones, laptops, PDAs, nav systems, pen tops, tablets, hand-held game consoles ... and they all provide some value to us. That value may be access to a resource, the ability to perform a new task, the ability to perform an old task in a new way or at a new location, entertainment, productivity, connection to our friends, immersion, or escape.

So in my mind ... I have a vision ... if I took all the functionality of all those disparate devices and combined it with all the benefit that I get from my non-portable devices (for example, my SunRay, my iMac, my cable box, and a Wii) I know what it would look like and what it would do for me. I imagine it every time I look at the iPhone. I want it not only to supplement the cadre of devices that I already have, I want my next mobile device to replace them. All of them.

But I realize that, along many axes, I am not in the majority. As desperately as I want an iPhone, I just refuse to buy one until it meets some of my other demands.

So my question to you is ... when you dream of the mobile device that you wish you had, how is it different from what is available now? Write me your answer in email: jenm at sun dot com.

Wednesday Dec 05, 2007

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

Maya Venkatraman is an Interaction Designer at Sun Microsystems. She started working in the area of Human Computer Interaction in graduate school, where she earned her Ph.D, and has been working in the industry for almost a decade, designing software that is easy to use.

I watched the amazing movie Pan's Laybrinth recently. I wandered over to the Pan's Laybrinth website (a webby award winner!) and found pictures of pages from the directors notebook. Apparently, he is in the habit of putting his thoughts into a journal. Years later in the midst of a project he will remember something he sketched that would be perfect for what he was currently creating. Take a look at this snapshot of the journal. Talk about content rich. Maybe I am a Luddite, but I just don't see someone being able to do this using, say a blackberry.

http://blogs.sun.com/realDesign/resource/notebook.png
Now if they had  a FlyTop  pen (or the more grownup version by Logitech) and the paper that goes with it - they would have best of both worlds. The flexibility of paper, combined with all the goodness of Digitality(tm). I stumbled onto this product about a year ago, and am surprised that it has not yet taken the world by storm. (...all it needs is a wireless chip..)

http://www.itreviews.co.uk/graphics/normal/hardware/h751.jpg Maybe sometime in the future, the notepad portlet/widget, will also connect to my physical notebook. Maybe I will be able to throw some of my web pages on to the wall or white board, and some to my real desktop (surface of four legged table). I could place my digital pen notebook on top of the notepad widget area, to upload the pages I have written. Maybe I am more of a Futurist than a Luddite.

 

Tuesday Nov 13, 2007

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.

Friday Nov 09, 2007

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.

Thursday Nov 01, 2007

Maya Venkatraman is an Interaction Designer at Sun Microsystems. She started working in the area of Human Computer Interaction in graduate school, where she earned her Ph.D, and has been working in the industry for almost a decade, designing software that is easy to use.

http://www.giftsnaccessories.com/gifts-stationery/img2006/maped.jpg I love stationery. If Stacey and Clinton ever appear at my door step and give me a credit card loaded with $5,000.00, I would try to ditch them at the earliest, and duck into the nearby Staples or Office Depot and splurge on notebooks, pencils, pens, sharpeners, and the like. It goes without saying that "back-to-school" is turning into my favorite season ...

One of the nicest finds this year is the stop-signal pencil sharpener. It has a small button on the top, which you press down before you start sharpening. When the pencil is sharp and the point touches the end of the blade, the button pops up to let you know. And you are saved from over sharpening and, thus, breaking the lead. Kids using the sharpener now have a cue that tells them when to stop. :)

During my online journey to discover more about this sharpener I found a blog devoted to pencils, etc.! Maped, the company that manufactures these sharpeners, is in France and has a nice web2.0, flash-filled website, complete with a carousel widget and pop-up bubble. gizmodo.com actually has some entries on sharpeners (and yes, I will be sending them a tip about this one).

Tuesday Oct 30, 2007

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.

This blog copyright 2008 by xDesign