Wednesday Jun 03, 2009

Deploying Java and JavaFX Consumer Applications

Jeff Hoffman

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

JavaOne 2009 is here...

Last night the entire user experience team on Java and JavaFX gathered to discuss what we do with some of the attendees at our Birds-of-a-Feather (BOF) session.

Tonight, we have a second BOF that is focused on deploying consumer applications through the web using Java and JavaFX.  For those interested, the slide presentation is available here.

Now it's back to the show...

Friday Oct 17, 2008

Twittering a Usability Test

We noticed that when the Labs were running user tests, we would see a flurry of email about status and schedule. Stuff that was highly relevant at the moment and then not at all. Material that seemed like it should be on ones twitter-feed not ones inbox. So for the last two user tests , we tried something new. We created a  twitter account for the user test , got a badge for it. We placed the badge on the website we create for the client-product group. Now we could tweet about schedule changes , status, and even how a session was going. In the beginning, the badge was a marginal element on the client page, but in a matter of hours, we moved it to be the main content area. Anyone with the twitter account information could put in the updates. They could do so from a variety of platforms. and 140 characters was just perfect for our short, transient messages. A good use of web 2.0  in the company. Now if we could twitter within the intranet... we could even share comments and notes this way !

Here are a couple of screen shots , to give you some idea of how this worked visually. 

Friday Oct 10, 2008

From Sketchpad to ILoveSketch

Quite some time ago, in the early 1960s, Ivan Sutherland developed an interactive sketching system. Even if you do not consider the bulky house-size computers of the time, Sketchpad remains a remarkable milestone in HCI. Here is a short clip out of a seminar by Alan Kay "Doing with Images Makes Symbols. Communicating with Computers"(Apple 1987) where he comments on Sketchpad:

 Now please fast forward by 46 years an watch what's possible today:

ILoveSketch from Seok-Hyung Bae on Vimeo.

Amazing, isn't it? (Source: IxDA-discuss

Matthias Müller-Prove is a User Experience Architect for Desktop Virtualization at Sun. Sometimes he blogs here – sometimes at Acetylcholinesterase.

Monday Sep 29, 2008

A quick review of is geared towards rapidly creating low fidelity prototypes, including screen flow between various pages.

I decided to give it a try to see if it would help me show the flow between various portions of a screen and its associated overlays.  I wanted to create a very rough and quick representation of the screen to show the main flow between  the screen and its overlays.

Here is my first impressions:

The good

  • Fairly easy to figure out how to use
  • The run feature is nice as you can test drive the screen flow
  • It supports layers for reuse of wire frames
The bad
  • Right now there is no help.
  • There is no way to group widgets
  • There is no way to copy whole pages to another page
  • Lots of bugs still - but its in beta
  • I wish it had more widgets like tables and trees 

Nice concept and worth looking at when it matures a bit.  However, I am not sure if it is really better than my drawing a rough storyboard of my screens...

A quick example of the running application:
(marked up with the Cursor stamp using Snag it)

1. Main screen as first shownMain screen as first shown

2. After selection of OK from Search Overlay


3. Showing Add Record Overlay

4. A snap shot of a page being worked on.  I am setting  what page the OK button goes to.

Andrea Joy Kendall has been a Graphics and User Interface programmer and designer for over 20 years. She is passionate about designing for the user. Currently she is working on a Mock Up for the Open Source project Mural, Master Index Studio as part of the SOA/Business Integration Composite Applications group.

Monday Sep 08, 2008

Page Thumbnails for UI Design

Early in a UI design project, it's efficient to be able to quickly arrange and rearrange the high level navigation and flow of the application or site without getting mired in the details of each page. You can accomplish this by drawing plain old lines and boxes with descriptive labels, but odds are that you have a general idea of what you expect the page to do, e.g., it is a form, or a table listing a bunch of objects, or just a page full of text. It's at this point in design where Page Thumbnails can come in handy. Basically, these are just shorthand visual representations of particular types of pages that, unlike a plain old boxes, imply functionality or purpose of the pages. Drawing the navigation flow using these makes for a more informative and visually compelling view of the proposed design.

I created an initial set of Page Thumbnails as an OmniGraffle stencil. OmniGraffle is a Mac application that works great for wireframing, page layout and vector-based drawing. One cool feature is that it allows users to create custom stencils of reusable objects that can be dragged off of a palette and into your document. The stencils can then easily be shared with other users via websites like You can read a bit more about it and download the Page Thumbnails stencil from Graffletopia.

Here's a snapshot of the thumbnails as they appear on the stencils palette:

Page Thumbnails Stencil

These were created based on my experience in web application design and in messing around mapping some existing sites, but the stencil is certainly not complete. The applications that the xDesign group designs at Sun share a lot of common structure (e.g., navigation schemes, page layout) and this constrains the set of thumbnails needed -- so a small set can go a long way. Web sites, on the other hand, are far less constrained in terms of purpose, scope, navigation, etc., and so the potential set of representative thumbnails is broader. To make this stencil (and the method) more broadly applicable, I included a couple of blank objects on the stencil that can be customized and saved for reuse.

I put together an example of a fictitious site to illustrate the idea, and you can see a bit of that below. The full example is also available as a pdf file.  I hope you find the stencil useful. Feel free to leave comments/complaints/questions in the comments section.

Example of Page Thumbnails in action

Tuesday Jun 17, 2008

Tools: Learning with Lynda

Recently I've been going through some of the tutorials at If you haven't heard of lynda, or haven't checked it out lately, you should take some time and look around the site. There are tutorials for all levels of expertise, and just about any tool you've heard of has been covered.

So far, I've gone through some of the content for Flash and Dreamweaver. Both of these tools have some excellent tutorials, and the presentation is very good. I've found though, that in the attempt to cover these tools comprehensively, I end up skipping around looking for the bits I don't know while trying to skip the bits that I do.

One of the nice things about the site is the way they've organized their content. Each tool has several tutorials aimed at users with different experience levels. For instance, the Flash tutorials focus on Actionscript, Mobile, Illustrator, and Flash in general. In each case, selecting a tutorial gives you a very nice table of contents for that "class". The "chapters" are organized well and generally fit my expectations.

In my case, as I knew very little about flash I chose to start with Flash fundamentals. As I began the tutorial, I quickly figured out I couldn't do these "start-to-finish" like I might normally take a class. What I learned (outside of new bits of Flash goodness) is that the sections for beginners generally cover all of the functionality in the tool, so users who've done work with other similar tools (like MDI based windows) will find these bits are called out and explained in painful detail.

The flip-side to this is that in order to learn something quickly, you need to skip some of the individual sections like "Understanding file types", "Exploring the toolbar" or "Working with ...". For me this was quite frustrating as I typically like to master the basic disciplines (with anything I do) before moving on to the more advanced bits. I'm usually just a little paranoid that I'll miss some tiny, innocuous step that then enables some of the more advanced functions.

What's worked for me here is using a different approach to absorbing the tutorial content. I'll find a section I'm unfamiliar with and start after the bits about "Understanding...", "Exploring...", etc. Usually the "Using..." type sections are just about right. In some cases I've found there's that innocuous bit that I don't know and can't infer from context, and so I'll stop the tutorial I'm running and go back to the section that covers what I missed.

Overall this is a new way of learning for me, somewhat uncomfortable, but none-the-less effective. It seems to take less time to get something new, but it's definitely not a linear learning process. I expect as we become more accustomed to using computer-based training, we'll also start changing the way we learn new things. "Change" still seems to be the only thing that doesn't.

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

Monday Apr 21, 2008

Capture, in a Wink!

Untitled Document

A former colleague pointed me to using Wink freeware, to do capture screenshots and create screencasts. Click the picture to check out a quick demo I created using Wink. Here's the exported PDF of the same session.

<script src=''></script>

Since you can read all the features on their site, here's what's valuable from a UI designer's point of view. I've used Wink as a quick way to capture existing interaction behavior and mock up new interaction behavior to show engineers. It also enables me to take many screenshots as I walk through an interface without interruption! I no longer have to pause after taking each screenshot to save and name it in another application such as Photoshop.


  • Lightweight and fairly easy to use
  • Captures the context menus and cursor (In My-Old-Screenshotting-Method on Windows, using the " Alt-Print Screen" dismisses the context menu before the screenshot is taken. You can only capture context menus if you capture the entire display with "Print Screen". And either mode does not capture the cursor)
  • Many different types of output - Flash movie, PDF, HTML with a choice of saving images as pngs, bmps, jpg, and more
  • FREE! (vs products like Camtasia)


  • By default the graphics for callouts and buttons aren't the prettiest. You can create your own custom callouts, but afaik, cannot create custom buttons.
  • Once you define the screenshot area, it's a fixed width and height. So anything that falls outside of that area is chopped off, e.g. dialogs or menus that extend past the area are cut off
  • Doesn't remember user choices well and has some annoying defaults for where it saves files. I've accidentally overwritten files :(

Give it a try! Alas, it's only for Windows and some Linux platforms.

Tuesday Mar 25, 2008

How do I write my UI specs?

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.

Thursday Mar 20, 2008

Tales: Guerrilla Interaction Design in Action!

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

...Please read with toungue in cheek...

Hopefully, somebody read my previous post on this topic. I know I did. And without being too narcissistic, I must say I rather enjoyed it. Truly I can be a witty boy at times, and with humility as well.

So, for all of you who agreed with enthusiasm, thank you. Send me money. For those of you who may be skeptical, I'd like to share a recent GID project in the hopes that it may help win you over to the right side. Vive la résistance utilisabilité!

We should begin with understanding how the project started. My boss asked me to talk with some folks from another team that wanted some help from xDesign. They asked for some help with a wizard for creating XML documents. A perfect opportunity to use the Guerrilla Interaction Design process, as...

The Guerrilla is at one with The Wizard

Turns out as well that these folks were no ordinary developers. Both of them flexible and open-minded, they were interested in solving the problem in the most usable way, rather than the easiest to implement way. Score!

After about 45 minutes of discussion, they were able to give me a clear picture of what the problems were and why they were problems. I also learned during our initial meeting that they were definitely open to outside ideas, and seemed encouraged with a few concepts we discussed in the meeting. Frag Damage Multiplier! As you may recall from my previous posts...

The Guerrilla has seen and solved all Wizard design issues

The problems were reasonably straightforward from their description, but the solution wasn't what they were expecting I think. However, after delivering the initial sketches, they seemed very enthusiastic with the direction. They immediately understood the advantages of the approach and seemed pleased. These folks were obviously skilled masters at software development, and from some very realistic screen mockups were able to see the elegance in the solution, since as we all know...

The Guerrilla has mastered speed and accuracy with the WMD (work-tools of masterful design)

So that we all can see the problems, let's take a look at the previous design and identify the issues. Here's the first screen from in the wizard which is relatively straightforward:

Old XML Schema Wizard, Screen 1

And the second screen - again, nothing unusual or complicated:

Old XML Schema Wizard, Screen 2

The third screen however proved to be the nefarious culprit of designer dissappointment, the critter of corruption, the minion of... well, you'll get the picture:

New document location and information

It wasn't a bad looking screen at all. Nicely laid out, and functional, it didn't really look like a problem. But it was. What the user needed to do here didn't fit in the implementation, and that means it wasn't really usable, and we all know "poor usability" must die (or at least go really far away, like Antarctica or somewhere).

The Guerrilla is content to kill off one or two bits of infidel design or poor usability so that eventually only one or two bits remain

So "What's the problem?" you ask...

There's no way to see all selected files together in a single list.
The user needs to select XML schemas (files if you will) to be used when creating their XML document. They can get these files from the machine they're using at that moment, or from known namespaces (think of it as another kind of directory structure), or from the Internet. They'll likely need a few files, and will also likely want to be certain they select everything they intend to.

The current interface makes it hard to see all the selections in one spot. There's a potentially huge list, and displayed in tree-table it's likely the user will need to scroll up and down (excessively) to be certain they've selected everything they want.

The memory load on the user can be excessive.
Many of you have heard the phrase "Seven, plus or minus two". For those of you that haven't, it refers to the average short-term memory storage for most humans. Think "memory" like a horizontal tube, and the "things to remember" like baseballs. Most people have a "memory" tube that's 7 +/-2 baseballs long. For each thing they need to remember short-term, think of it as putting a baseball in the tube. After ~7 balls are in the tube, adding another ball will push the first one out (equivalent to forgetting, and in my particular case my "tube" is only about 5 baseballs long and getting shorter by the minute).

In this interface, if the user needs to select more than 7 or so schemas, they'll likely need to make a paper list and check them off. Extra work, and extra memory load for those who don't "quite" need the list. And the best part is this is something a better design can eliminate completely.

The layout and controls take away space from the list (the primary benefit of this screen).
The "Primary Schema" and "Root Node" fields pertain to only one schema, or selection in the table. Displaying them separately from the actual selections blurs the relationship to the schema list. It would likely cause the user to look at the list, and then at these fields, and then back to the list in order to be certain they've selected the right schema as primary.

Selecting schemas, and then selecting one again to be primary is redundant, and in this case unnecessary.

So, with all this we now have three infidel bits of "unusability" that must die, like villains tied to the tracks of The Design Train, or prisoners dangling over a pit of pointy-sticks (pointing up of course). Tune in next week, when our hero... Nah, I'll tell you about it now.

The new design, Guerrilla style...

Redesigning this screen of the wizard wasn't difficult. The previous points about unusability indicate three basic ideas:

  • The list should contain what the user has selected and not everything they can select from, alleviating the need to remember what was already selected.
  • The selection process will likely require drilling into hierarchical folder structures (directories) and could be deep; the space available to view these structures needs to be at least as big as the list.
  • Once the selections have been made, it's likely that the information about primary schema and root node in the list can be shown in as part of the list, keeping the viewable space large as possible.

Here's the design we ended up with:

New document location and information

The re-work of this screen uses some different design ideas and techniques to improve the usability:

  • The table now takes all of the available space making it easier to see everything that's been selected.
  • As soon as this step in the wizard is displayed, an instruction is shown to help the user understand what to do.
  • Each time the user enters a path or makes a selection, the instruction is shown on a new line to indicate another entry can be added.
  • The user can overstrike the instruction text to manually enter the path/schema information.
  • If the user clicks "Browse", another window displays a typical file-browser where they can navigate to and select from available files or namespace objects.
  • Selections made in the browse dialog immediately appear in the list (behind the browse dialog) providing feedback of the selection.
  • "Select" and "Close" buttons are used instead of "Ok" and "Cancel" to better indicate the slightly different behavior of the browser (meaning it stays open while they're selecting things, and goes away only when they close it).
  • Any selection made in error can be removed from the main list by selecting it and using the "Remove" button, or pressing delete.
Once selections are made, the user can see them all in a single list and now choose the primary schema, root node, and even supply a prefix (honestly I'm not certain exactly what this is, but the XML folks seemed to be pretty certain it was needed so I left it in).

If you click on the image below you can see a short animation of the screen in action:

New document location and information

So here we are, with another brilliant design (thank you thank you) that solves many of the problems which made the previous design feel clunky.

It wasn't that the previous version was poorly done or ugly - in fact it was very well done and it was clear to me the development team paid a lot of attention to the use and layout of controls, the consistency and polish. It was simply that something about it didn't feel right, and when the re-work was presented, the developers said "That's it! We couldn't quite describe what was wrong, but this definitely right."

This entire exercise lasted from a Thursday afternoon to the following Monday morning. Three days. This included creating a presentation storyboard showing before and after images, explaining the design problems and solutions, and even an additional entry screen (piece o'cake) as a last-minute addition. It was also one of a few projects I had on my plate. And, of course this is all possible because...

Inside every Interaction Designer there is a usability "Guerrilla", ready to attack, maim, dismember, and kill bits of infidel design or poor usability

Monday Jan 07, 2008

Guerrilla Interaction Design (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.

Three days is not a lot of time to create a design. It's not a lot of time for anything really. But, in three days a Guerrilla Interaction Designer can crank out quite a bit of design work. And the best part is - no guns! Not even a squirt-gun!

Now I know most of you are thinking "NO WAY!! You simply CANNOT do any good design work in that amount of time!" And, hopefully, most of you will be surprised with my description of how it works. Let me first describe the Guerrilla so we can then understand the process:

The Guerrilla has extensive experience in GUI design in general, and has an experiental arsenal of design solutions to draw upon.

The Guerrilla is at one with his product manager and the product.

The Guerrilla has seen and solved similar problems for most of the requirements.

The Guerrilla is confident in his or her knowledge that any improvement at all is an improvement, and that quick iteration for short release cycles is better than hanging around with actual gorillas.

The Guerrilla is lightning fast and accurate with his or her weapons of choice (my favorite is StarOffice Impress).

And finallly, The Guerrilla is content to kill off one or two bits of infidel design or poor usability so that eventually only one or two bits remain.

It's not really a "Zen" thing, but more of a "I just drank a case of Full Throttle energy drinks" thing. Coupled with an agile and open-minded development team, this model can work pretty well. So now that we know a little about the Guerrilla, perhaps the method will make sense.

There are phases that are simply left out for the sake of quick turn-around times, and there are phases that are done differently. Let's take a look:

1. Discuss the product requirements or potential problems and fixes with the product manager (no more than 2 hours).

2. Based on the Guerrilla's expert opinion, sketch a paper design and review with the product manager (no more than 4 hours).

3. Discuss it with development management to make sure there's nothing too scary to implement, and potentially ignore protests at this point (an hour or less).

4. Grab your favorite WMD (work-tool of masterful design) and get to work! Create the design based on the initial drawings and follow-up conversations with the product manager and development (try to keep this under a day and a half).

5. Show the design to product management, and if that's all hunkey-dory, find a live body (hopefully with some domain knowledge) and walk through the design; look for serious "gotcha's" or bewildered stares. Resuscitate the victim (participant) if necessary. Wash, rinse, repeat (can take up to a day depending on how many live bodies you have at your disposal).

6. Finalize the design and deliver to product management and development management. Bring a flak-jacket in the event that development is uncomfortable with the design, and intends to torture you as a POD (prisoner of development).

7. In the likely event that both recipient parties approve (or mostly approve), and if there is time left in your 72-hour span, wrap the design in some documentation (old newspaper works pretty well) and move on to your next target.


I know it sounds a bit slap-dash, but keep in mind that some improvement is better than no improvement. I wish I had a nickel for all the "full design" projects I've worked on, only to find that by the time I had the design, development was done or the market had shifted (and so, the requirements as well). I might have enough for a fancy latté or something.

While this idea works and fills an important niche, it's key to keep in mind that you're not trying to reinvent an operating system. It works because most if not all the problems presented to the Guerrilla have been seen and solved. His or her experience, coupled with the idea of incremental improvements help Guerrilla UI Design make sense and be effective as a way of designing. It's not always the best answer, but it can help arrive at better answers pretty quickly.

And that's what we want right? Quick solutions to the shifting sands of usability...

Thursday Jan 03, 2008

Guerrilla Interaction Design (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.

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.


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


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


« February 2017