Chet Haase is a well-known figure in the graphics community. Join him as he talks about UI development, collaboration between designers and developers, desktop vs. web and more.

Tell us a little bit about yourself.

I’m a software geek, with an interest and focus in computer graphics. I’ve been working on graphics software ever since I got bored in my first job out of college, where I was doing “network analysis.” I raced off to graduate school and have been doing graphics ever since.

I’m now working at Adobe Systems on the Flex SDK, where my current project is (surprise, surprise) to add additional animation support to the library.

I also enjoy writing and speaking about technology, from my blogs to articles to the book that I wrote with Romain Guy, to presenting at technical conferences. Implementing technology is fun, but it’s also fun to articulate to the users of the technology how things work and how they can take advantage of the platform for their applications.

What are the three most important things for a good user experience with a business UI application?

I don’t know about ‘most important’, but here are three that I think are very important:

Understandable: Can the user understand the UI? Is it obvious what they’re supposed to do at any point during the application?

Efficient: Can the user get their job done quickly? This includes power-users: you need to make sure that people that use the application all the time have shortcuts or very fast means of accomplishing common tasks. I saw this in action watching users of Autocad. As a graphics person, I would expect all of the drawing to be via the mouse and display, but the power-users that ran the program all day long performed many of the operations by typing in shortcut commands instead.

Robust: This one is obvious: Can the application avoid errors and crashes? No matter what the application looks and behaves like, if the user can’t get work done because it’s crashing left and right, then they’ll abandon it for anything else that gets the job done.

Can business applications (especially internal) justify being “sexy”? Is the current trend of bringing sleek visuals, animated content, 3D effects and media more than a fad?

Well, I sure hope so, or else I’ve been wasting my life for the past few years…

I think that it’s easy to write off graphical and animated effects as just being eye-candy. But I believe that any application can benefit from some level of effects in order to make the application more powerful, effective, and useable. In the case of a business application, you might not want to put throbbing buttons and spinning sprites all over the screen, or to make the application look more like a media player than an HR forms database front-end. But the same techniques can be used to make this kind of business application more useable; you just need to know how and when to apply them. For example, animation can also be used to provide a subtle pulsation of the default button, or transitions between states of the application. It’s this last one that has been of particular interest to me for some time. Why give your users new GUI pages to figure out whenever the application screens change? Keep them connected to the application, and more productive, by animating between the states so that they can more quickly determine what’s going on and what they have to do.

Animation and graphical effects can be totally gratuitous, but they can also be helpful and powerful tools for any application, as long as they are used properly.

Rich client development tools place great emphasis on allowing smooth collaboration between developers and designers. How important is this for developing business applications?

There should probably be more use of designers in business applications than there is today. “Design” is not just about creating media-rich consumer experiences; it is also about making applications more useable by the target users. The ability for designers and developers to collaborate more closely should help in developing applications that incorporate this design input.

Most of your career has been spent at the pixel level, but your last few efforts (such as timing framework and animated transitions) were on higher concepts. Does this reflect on leaving pixels in the hands of designers?

Actually, that’s more a picture of my recent career at Sun, working on Java, than of my career overall. Prior to that experience, I had worked at both lower levels (e.g., implementing drivers for graphics chips) and higher levels (e.g., writing 3D modeling applications) over an uncomfortably long career in graphics. For me, it’s always about getting pictures onto the screen, no matter where I’m working in the stack.

But to your point, I have spent the past few years trying to apply the lower-level techniques to benefit the higher levels of application development. For example, the timing framework and animated transitions libraries were about providing capabilities to developers that made it easier for them to add animation to their applications. I think that most business application developers have their hands full just implementing the logic of the core application without also worrying about how to use graphical effects. The more painless we can make it for them to do so, the more possible it is for them to apply the techniques.

I suppose this point also relates to designer; if we require people to dive into low-level code to implement nice animated effects, then it’s just not going to happen. Whether those people are designers, who probably don’t want to fool around with code at all, or business developers, who may not have the time or expertise in this area, if that’s what it takes to get those nice effects then the applications will ship without them. On the other hand, if the people that understand the low-level details can create higher-level utilities and tools that accomplish these tasks, then we can broaden the reach of these techniques and make it possible for all kinds of developers to use them.

Are you a proponent of visual designer tools? Do you think that automating the UI development results in better looking and more maintainable applications?

Yes. I’m not a designer myself, so I can’t speak for the tools and experiences that designers have in application development. But having used some decent GUI builder tools, I’m completely in favor of letting the tool do the visual stuff and saving the code for the logic. If it’s all in code, then it’s too easy to decide that that little UI tweak isn’t a big deal because recoding it would be a hassle. But if you have a design tool that makes visual aspects easier to develop and modify, then it is much easier to make small adjustments that may have big user and usability impact.

Do you think that a UI toolkit should enforce a specific and rigidly “guided” approach to UI development and restrict the API expressiveness, even at the cost of alienating advanced developers that will not have access to low level APIs.

Software, for me, is an art form in which nearly anything is possible. If you restrict the capabilities too much without letting the developer get in and hack things differently, that’s not software. I do believe that guidelines should exist, but in a way that helps the developer get the basics right. You want to help them get decent-looking applications without trying too hard, or having to learn and custom-code things too much. But that doesn’t mean you should prevent the developer from changing things as they see fit. It’s their application, after all, and they probably know their target audience and domain far better than the folks designing the toolkit do.

Do you see added value in cross-platform UI toolkits? Is it worth sacrificing access to platform-specific native functionality?

I see value in both. Some applications need to run on multiple platforms and need to have the same, or at least similar, user experiences on these platforms. Other applications need to be tightly integrated into the native desktop and need to have user experiences that are very tightly tied to the native look and feel.

It would be safe to say that the web is winning as the delivery layer of rich applications. What do you thing about a browser as the container layer? How important is it for a UI toolkit to live both in the browser and on the desktop?

Most applications that we run today, if you include the simple shopping and reading experiences we have on the web, are browser-based. So clearly that is an important medium for any application, and I personally would like to see richer experiences than HTML for much of what I do on the web. But I also use many applications that have nothing to do with the web, or at least nothing to do with the browser. For these applications, I don’t want to bother with the browser container, but instead would like the application to run as a normal window on the desktop. The extent to which a rich UI toolkit can serve both of these needs is beneficial to the toolkit as well as to users that can share common experiences and paradigms between the browser and desktop.

The Parleys.com application that was demonstrated at JavaOne and earlier at JavaPolis is a good example of a program and toolkit that spanned both spaces effectively. It has a browser-based model where the user runs the application on the parleys site and a desktop-based version where the user gets a very similar experience in a native desktop window. Since the application uses the same toolkit and UI for both cases, the user can apply their knowledge of the UI on one version directly to the other version; there’s nothing new to learn and they’re up and running quickly.

Is the browser the new platform? Extending the previous question, how important is it for a UI toolkit to be cross-browser?

Cross-browser functionality for a toolkit is quite important today. In some situations, there is only one browser that matters. But even in these constrained situations, you cannot alienate your potential user base by having your application behave poorly if people happen to run it on a different OS, or with a different browser. Also, you can never tell how the future dynamics of the browser wars will work out. So it’s far better to use an approach that makes your application work well regardless of platform and browser.

Is there anything you would like to add?

I would just like to encourage everyone to go out and create rich experiences. Life is too short to run boring applications.