Today I have an interview with Jeff Hoffman, a member of the Java team at Oracle. Enjoy the interview!

Hi Jeff – could you please introduce yourself to the readers?
Jeff Hoffman, I’m the lead user experience developer for Java at Oracle.

You’re a member of the Java team at Oracle, but what is it that you actually do in general?
I work closely with the Java team members who are creating anything that will eventually be seen by an end user.  I cover the end-to-end deployment experience from the java.com website where most users get Java on their computer to the launch sequence for an applet or web start application. This is where I have the largest impact since install, update and application launch processes have a lot of end user visible components.  Much of my focus these days has been on the impact that our security measures have on application launch — specifically the dialogs we show when an application is requesting elevated permissions.

What does a regular day entail for you?
Understanding the various ways Java is installed and launched. Filing bugs where I find that the experience for the end user is clunky or the feedback we’re providing isn’t clear. Discussing possible approaches for addressing these issues with developers.  Thinking about what kinds of user research we can perform to get useful feedback on how Java is deployed in the world.

How does JavaFX figure into your role at Oracle?
I’ve been working on JavaFX since the 1.0 release.  I’ve been involved with creating samples, providing feedback on components and working with the docs team on tutorials.  I designed the installers for the 2.0 runtime and SDK releases.

Installers are an interesting thing. If they are designed properly, they’re almost unnoticed, but if they fail to work, you can be given a very hard time.
Yes, I agree. No one’s end goal is to install a technology like Java or JavaFX. It’s just a step on the way to completing a user’s more important task — like being able to play a multi-user game with friends or finishing their taxes.

The installer’s role is to help the user by providing the base technology that they need, and to do so as quickly and efficiently as possible. The user should not have to think about what they’re doing — so we don’t burden them with unnecessary options. We just ensure that the information they need to know is easily accessed. We also leverage the commonly used installer technology on the platform so that it’s as compliant with the rest of the OS as possible.

We do extensive usability testing of our installers so we can see how well we’ve achieved our goals. I’m happy to say that over the years, the data we have collected through this testing has improved the installer experience quite a bit, and users are successfully completing millions of Java installs every day.

Java installers have always installed Java versions side-by-side, leading to systems that are bogged down in multiple versions. On Java.com you suggest removing older versions of Java. Does this give you headaches, and do you have plans to improve this situation?
In the past, that was true — however as of several years ago (and the release of Java 6 Update 10), we now patch the existing version of Java on your machine instead of installing a whole new one every time. This has reduced the problem quite a bit.  However, the bigger issue is that some old applications specify that they’ll only work on an old version of Java, and this can compromise the security of the user’s system.  In general, a lot of these applications still work fine on newer versions of Java, so we recommend that people remove the old versions.

Currently, we provide detailed instructions for how to remove these old versions via the Windows Control Panel facilities — however we’ve seen that this process can be error prone, and can result in old versions remaining on the machine, and possibly removal of the up-to-date version!  So we are working on solutions to automate the process and eventually incorporate this in to the Java install and update flow.

What feedback have you received about Java installers, and what is it that you really want to achieve in future releases?
In general, the Java install process is pain free for almost all users.  The proliferation of Windows 7 and 64-bit versions of Windows has resulted in comments that some users aren’t sure which Java installer to use.  They see a 64-bit sticker on their machine, but don’t realize that the default browser is still a 32-bit process, so they need to install the 32-bit Java runtime for their browser based apps.  The java.com website automatically chooses the appropriate installer for our supported configurations, so this isn’t a huge deal. If users are running desktop apps that require 64-bit Java, then they would need to install that also.  Explaining something as abstract as 32-bit vs. 64-bit architectures to an end user really isn’t easy.  In some ways this is a transitional problem and will go away as soon as commonly available browsers and OSes are all 64-bit.

As OSes become more vigilant about the software you download and install on a machine, users are asked to deal with multiple security warnings (like from Windows User Account Control) before they can install Java.  Currently, you’ll get UAC messages when you install Java for the first time, and each time you are asked to update. These messages seem to appear “out of the blue”, so the user isn’t sure what generated them.  We are taking steps to upgrade our installer technology and change our requirements so that users remain protected without being confronted by warnings.

Lastly, I’m happy that we’re integrating the Java and JavaFX installers both for the runtime and the SDK, since everyone appreciates one less installer!

Thanks for taking the time to chat with me. Do you have anything else you’d like to say to the readers?
I’m always interested in hearing from our users about their experiences — both good and not-so-good.