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

Friday Sep 14, 2007

A Sociologist in a Technologist's World: What's a CLI, again?

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

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

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

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

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

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

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

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

Thursday Sep 06, 2007

Feature rich or easy to use? Yes.

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

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

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

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

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

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

Wednesday Aug 29, 2007

Helping to Eliminate Mistakes in Medical Treatment: What We Found (Part 3)

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

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

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

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

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

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

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

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

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

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

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

Monday Aug 27, 2007

A Brief Review of Leonardo's Laptop

Janice Critchlow is a technical writer in the Software Information Products Group. She has been a valued member of the Software User Interface Review Board (UIRB) for many years.

Picture of book cover Imagine a change in the way that we think about and design technology -- a change comparable to those that Leonardo DaVinci influenced in the arts and sciences in the 15th Century. That is the premise of Leonardo's Laptop: Human Needs and the New Computing Technologies, authored by Ben Shneiderman. It's not exactly a book that asks What would Leonardo do? but more a call to action for computer user experience to undergo something of a Renaissance.

Ben starts by reviewing some history related to Leonard DaVinci and computer experiences. Among other things, he cites several instances in which poor user interface design causes more than just inefficient work, but actually causes injury. He talks about how developments in technology relate to user experiences, and goes on to suggest that our technology-centric approach to user interface design should become more user-centric.

After defining the user-centered approach to design, Ben examines the user experience in several segments of our worldview in detail: education, commerce, medicine, and politics. For each segment, he suggests how changing the way that we experience technology could significantly improve our lives.

From my perspective as an information designer, two key concepts jumped out at me. The first was Ben's assertion that a "user interface" encompasses much more than just the look-and-feel of an application and that we need to consider this expanded definition when designing our products. Specifically, he mentions the importance of items such as:

  • Documentation
  • Quality assurance
  • Simplicity
  • Good error handling built into the product
  • Testing

The second major concept was a discussion about getting users to know what they need to know ("bridging the gap"). Ben talks about the different ways that people learn and a variety of techniques that we can use to enhance that learning. Some techniques are within the product interfaces themselves, while others fit into the more traditional "training" space.

References to Leonardo DaVinci's life and works are scattered throughout the discussion, which make for an engaging, although somewhat esoteric, read.

If you're looking for a book about technology, history, and user experience that makes you think, this is an excellent choice. If you're looking for a "formula" to solve all user experience problems, this book is not the answer. In fact, my interpretation of Ben's writing is that there is no simple formula to solve all user experience design problems. Instead, we need to use an approach that considers the users' needs before all else as we mesh technology, sociology, psychology, and art.

Wednesday Aug 22, 2007

Building of Two Usability Labs in Prague, Czech Republic (Part 2 of 2)

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.

When Sun's Prague office became too small, we all moved to a new building. So during the space planning, we made sure that we got a room there for a usability lab. Why build a second lab? The main reason was to have it in the same place as the engineering team so they could easily attend the test sessions.

This time, we decided to do everything on our own: one of our interaction designers, Rudolf Bock, selected the equipment. Based on our experience with the labs at CTU and at Sun in Silicon Valley, we created blueprints and made sure to have a big one-way mirror. From our experience, despite the fact that some participants feel less comfortable in this set-up, it makes a difference to observers -- they feel more connected to the participants.

We got the space with a one-way mirror in the Summer of 2006! Here are pictures of what we have now:

The lab is fully digital, again partially based on Morae. The equipment is:

  • 2x Dome camera Panasonic WV-CS570
  • 1x Panasonic WV-CU360CJ
  • 1x Data multiplex unit Panasonic WJ-MP204C
  • 1x Blackmagic Design DeckLink Multibridge Extreme PCIe
The first usability study was conducted in this lab in November 2006. Since then, we have used this new lab for the majority of our studies. We also plan to show it to the public as part of World Usability Day 2007. Stay tuned!

Monday Aug 20, 2007

My Book Review of Understanding Comics: The Invisible Art by Scott McCloud

Bruce Lee is a brand strategist, who works closely with xDesign to define the branded look and interactions of Software user interfaces.

Understanding Comics: The Invisible Art, by Scott McCloud
224 pages (215 pages of comics) Black and White with 8-page color section. 6.7" x 10.2"

This book by Scott McCloud isn't just about understanding comics. The 215 pages of this 1993 book cover just about everything: time, creativity, psychology, quantum mechanics, and the whole of human endeavor. Seriously, folks, this book uses the comic book form to talk about the process of telling stories using comics. It talks about its own form. But I don't mean to make it seem like the book is either recursively academic or feverishly adolescent. The truth is that the content of this book is universally applicable to nearly any activity that seeks to communicate about the internal or external human experience. Because the comic book links language with images to tell stories, it's more effective than either words or pictures alone. What puzzles me is how this form got such a bad rap to begin with. I recommend this book first to anyone wanting to know something about art or design. Read it now. Ranking: 10 of 10

Wednesday Aug 15, 2007

Helping to Eliminate Mistakes in Medical Treatment: Our Challenges (Part 2)

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

This is the second of a multi-part series (View Part 1)

For this project, our design task involves finding a way to help health care professionals match records that the existing automated system can't.

The system is made up of two parts. The behind-the-scenes part consolidates a patient's records from various data sources to produce a single, complete, and up-to-date record of a particular patient. The system is even smart enough to see that records match even when some of the data in the records don't match.

The second part of the system is a user interface that reports records that might match, but that can’t be matched automatically. In this situation, the system needs some help from a "live operator standing by." Working with non-technical end users and providing them with awesome tools is one of the fun parts of this project.

When the system can’t resolve a conflict, the user interface alerts the health care professional and provides decision support to resolve the conflict. For example, when a baby is born, the hospital uses the father’s social security number as the baby's social security number on the birth certificate. Once common, this practice is now quite a headache for health care professionals later on, because the father and baby appear to be the same person. It's also a hard problem for the system to fix since the records of the father and baby may share the same data in many fields (like social security number and address), but the data in key fields are different (like name and birth date).

While there’s already a tool that lets a live human review these potential matches, it has many usability problems. It’s hard to tell what portions of a record don’t match. It’s hard to see information across more than one duplicate record (such as three systems all having similar, but slightly different data that could all be part of one person’s medical history). And it’s just plain slow.

These issues make it much harder for people to quickly and effectively handle records that the system can’t, and, in many cases, it takes much longer than necessary. Today, the people who do this work full-time print out huge lists of duplicate records and then spend hours reviewing the hard copies to make sure they’re matching the right information. The existing user interface could resolve these issues, but it doesn’t support their tasks well enough to be useful.

To be continued...

Monday Aug 13, 2007

Building of two Usability Labs in Prague, Czech Republic (Part 1)

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 2004, our xDesign team in Prague was facing a problem: the number of usability studies we needed to do in Prague kept growing and growing. Since we had no usability lab, we did all of our testing in two meeting rooms that the rest of the company also used. One served as observation room and the second one as testing room. It worked ... but there were two main issues. We had to "build" the lab every time from scratch, and it took about a day to run wires, set up the computer and camera equipment, and move furniture. The second, even bigger, problem was not having enough space. Sun had started its expansion in Prague, so we were hiring a lot of new people, and the building was very crowded. It became harder and harder to find two meeting rooms that were next to each other and available for a couple of days. And it was impossible to build a lab in the building: there was no space for it!

So I started a discussion with the Department of Computer Science at Czech Technical University. Our history of cooperation had started earlier, in 2003, when I was networking with other interaction designers in the Czech Republic. I found out that the person in charge of Czech SIGCHI was my former professor, Prof. Pavel Slavik. So I contacted him, and we quickly found that both Sun and CTU were interested in cooperating in the field of usability. But that's a different story, which deserves its own post.

Then in 2004, we discussed usability labs, reached an agreement and made a deal: Sun would supply the equipment and know-how, and CTU would supply the space and construction. Both institutions would share the facility, and, after three years, CTU would keep all usage rights and equipment. To construct the lab, we worked closely with the manager of Sun's U.S. usability labs at the time, J.O. Bugental, and we outsourced the equipment and configuration work to a vendor.

The lab was designed and built to contain both standard analog technology (a scan converter and DVD burner) as well as fully digital technology, which is currently mostly running on Morae. There is no one-way mirror -- we observe the tests using monitors and video cameras.

The lab officially opened on November 15, 2004, and the Czech Minister of IT, Vladimir Mlynar, attended. It was the first usability lab in the Czech Republic and, most likely, in all of Eastern Europe!

After the lab opening, we also supplied the promised know-how in two ways. First, we arranged for an external company, Relevantive, to provide a four-day training for teachers and Ph.D. students, which covered usability basics including usability evaluation. Second, we cooperated on ongoing projects, coaching and mentoring students as well as teachers.

Since 2005, CTU added usability to its standard curriculum and became the Czech Republic's leading university in this field. Hundreds of students have access to the lab every year and use it to run their accessibility and mobile device projects.

So this is the story of the first lab. I will talk about the second lab in a later post.

Wednesday Aug 08, 2007

Helping to Eliminate Mistakes in Medical Treatment (Part 1)

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

I love design; especially when I get to work on something that can make a difference in the lives of everyday people. My latest project is just that: an interface design for a health care tool. It's not a nerdy tool like I normally get to work on, rather it's a tool for health care folks to use to ensure that when I (or you) go to the doctor, the doctor knows who I really am. This kind of information can prevent a blood-type mismatch or having a kidney donated, when I was really supposed to have my toenails trimmed. The cool thing is that this kind of design also can make a difference for every day folks; a group I don't usually impact directly.

The problem that we're trying to solve is keeping the records of a person's various medical treatments connected to each other. Several different systems all have a unique record of a patient that's pertinent to the system-owner's service (the doctor, pharmacy, or hospital). And even though there are really smart people putting information into these systems, well, mistakes can be made — things like hitting the wrong key, misspelling a name, transposing a SSN, that sort of thing — small mistakes that can have a large impact.

A colleague of mine had the same first, middle and last name as another girl, who went to her high school. Coincidentally, they also had the same birthday, one year apart. Unfortunately for them, they also went to the same primary care physician, which they weren't aware of until the other girl's medical charges showed up on my colleague's insurance. This kind of confusion over identity could cause a problem for one or both of them for anything from blood-type to allergies.

So, when I go to my doctor and I need an antibiotic, she should know from previous visits and my health care records that I'm allergic to penicillin. When I go to the pharmacy to get my prescription filled, their records of me would ideally be linked to my doctor's records and I won't get any substitutions for the prescription that would cause me to, say, die of anaphylactic shock.

Wednesday Aug 01, 2007

Deconstructing the www.netbeans.org 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 netbeans.org 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 ui.netbeans.org.

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


Monday Jul 30, 2007

Blogging by Design

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

Recently, I had a conversation with Anant Kartik Mithal, who is Director of xDesign (Software Experience Group) at Sun Microsystems, Inc. xDesign provides a wide range of design services for Sun's software products including visual and motion-graphic design, interaction design, usability reviews, user research, web development and assistance with accessibility compliance.

Nalini: Why launch Design@Sun, a blog by and about Sun's Software User Experience Group (xDesign)?

Kartik: xDesign does an incredible amount of absolutely fascinating design work. As I spend time talking to all kinds of people across Sun — designers, engineers, managers — I listen to the problems they're trying to solve, and the problems are simply fascinating. I think a lot of people inside and outside of Sun would be interested in them. It’s interesting to understand what problems people are solving and how everyone solves them differently. And it’s fascinating to see how people think through the solution process. Look at the design for Solaris’ start-up, for example. I would have done it differently. It’s wonderful to see an absolutely fantastic design that’s different than what I might have done. And the same goes for the work in the Tools space, in the Web Admin space.

Nalini: What kind of problems and solutions will Design@Sun cover?

Kartik: The designers in xDesign, for example, are looking at how we can turn Solaris into a modern operating system and what that means. How can we get the Solaris start-up experience to be fun? Something like start-up poses an interesting design issue. It’s something a user has to go through; it's not something the user necessarily wants to go through. This kind of design problem that’s a little different than those users encounter when executing tasks. If I’m using JavaFX to create an animation, I’m actually getting work done. But if I'm doing start-up and install, these are wasted steps. So how can you make them interesting for users? How can you give the user something back while they're happening? If you take our individual software products, they’re all very different. What we’re trying to do is be as similar as possible across our products. So if you learn to use one of them, you can learn to use all of them. That’s something we achieved in the productivity apps a long time ago, and we’re doing it in the admin apps now.

Nalini: What will people get from Design@Sun?

Kartik: We hope to share with our readers a bunch of interesting problems that Sun is trying to solve. A lot of our stuff is open source so people can follow along as it shows up and comment if interested. Sun is all about making our customers more successful and more productive. And design is all about supporting that.

Also, one of the things that some people have lost sight of is that Sun invests a great deal in its user experience. Whether it’s the hardware or the software. It’s very important to us. It’s very important to us that administrators are able to assemble and disassemble systems as easily as possible. That system administrators are productive with Solaris. That developers are productive with NetBeans. That everyone is productive with StarOffice. We want everyone to be productive.

We were at CHI this year, as we are most years. I was a little shocked when a few people came up to me and said that they didn’t know that Sun had HCI (human-computer interaction) professionals. Very prominent people in the field of HCI work at Sun. Sun has been very active in this field, and maybe this blog can provide people with a better idea of what Sun is doing in design and user experience.

About

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

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today