Java Look and Feel Design Guidelines

New reviewer Jayakrishnan Nair has brought with him a review of Addison-Welsey/Sun's Java Look and Feel Design Guidelines. There's a lot of work being done in Java right now - make sure that it looks correct. The book covers everything from basic controls, keyboard navigation, tables, toolbars, treeviews to the JFC and effective ways to use the JFC components. Java Look and Feel Design Guidelines author Sun Microsystems, Inc. pages 230 publisher Addison Wesley, 06/1999 rating 9/10 reviewer Jayakrishnan Nair (jayakrishnan@netscape.net) ISBN 0201615851 summary This book is a must for people involved in creating userinterfaces for Java applications and applets using the Java Foundation Classes. The guidelines presented in this book will allow for the design of applications with consistent appearance and behavior. With a large number of non-technical users using computers regularly in their lives, ease of use and consistent look and feel have become very important in the design of an application. Products designed without concern for the overall experience of the user will become extinct. A badly designed application sticks out like a sore thumb, whereas an application that is pretty and powerful creates loyal users. Adhering to standards creates applications that look familiar to a new user.

Java Look and Feel Design Guidelines is a very practical book meant for the UI Designer as well as people involved in the design process. The large number of examples is supplemented with about 170 screen shots. Java Look and Feel guidelines for consistent appearance, cross-platform delivery guidelines, internationalization guidelines and implementation tips are mentioned in the appropriate sections and are marked by special icons. A list of books and Web sites on related topics like human interface design, accessibility, internationalization, etc., are given.

Java Look and Feel Design Guidelines is divided into three parts--Overview, Fundamental Java Application Design and The Components of the Java Foundation Classes. This book uses the word "application" to refer to both Java standalone applications and applets.

The Overview part gives a quick visual tour of the Java Look and Feel. The Java Foundation Classes are introduced and the major JFC User Interface Components are visually presented with cross-references to the pages where they are described in detail.

Internationalization allows for the development of applications that are independent of the countries or the language of the users. Such applications allow for the easy customization of the software for a particular region, thus creating a global market. The application may also have to interact with assistive technologies like screen readers, speech recognition systems and Braille terminals. The second part of the book Java Look and Feel Design Guidelines begins by giving guidelines on these two topics.

Given an empty panel, how do you start placing components on it? How much spacing do you need between a label and a textfield? The answers to these questions are given by guiding you through a step-by-step example where a simple dialog box is created using design grids. Colors, Fonts, text and layout of the elements are what create the mood of the applications. The chapter on Visual Design explains how to use these to increase the user confidence and comfort with your application.

The application that is designed for one platform may eventually run on other platforms and display systems with different capabilities. The chapter on Application Graphics gives guidelines in designing icons and buttons and using cross platform color so that the quality of graphics is not affected. Effective use of splash screens, login screens and about boxes to enhance the corporate identity is also discussed.

Part III: The Components of the Java Foundation Classes takes a look at each component of the JFC in detail. This will be the section that will be the most used in the book. Each component behavior is explained and tips regarding implementation and look and feel are given. The Appendix gives the keyboard operations available for JFC components for navigation.

An HTML version of the complete book is available at http://java.sun.com/products/jlf/dg/index.htm for those of you who like to browse the book before buying. The book does not provide code samples for any of the examples shown. Since the book is very specific one about JFC, such examples provided in the appendix or the Web site would have provided a starting point for programmers. Maybe this will come in the later editions.

Other platforms have their own books setting the guidelines. The timely publication of this well structured book has provided Java developers with an unparalleled resource for reference with its comprehensive set of guidelines. This book along with The JFC Swing Tutorial is a must on every developer's physical desktop.

Purchase this book at fatbrain.

Comments

L&F Guidelines good

[Masem]

One of the things that I appriciate from Apple was that they insisted (not forced, but strongly urged) you to follow the Human Interface Guidelines when developing apps; what ordering for menus, where to put certain buttons, etc. Given how the Mac interface needs to be built (basically using ResEdit or it's kin to precise position elements), this helped a lot. Of course, they appear to be deviating drastically from that with the Quicktime player and other aspects of MacOSX as previously discussed...

With Java, as you lose (or will generally not use) the precise positioning, and allow layout managers to take over to place elements, you're still left with a lot of questions -- I know that when I was trying to design a Java interface recently that I noticed no key trends here. Because of the WORA aspect of Java, much of the GUI interface for programs inherited from whatever OS it was developed on (various WinXX-isms, or motif-isms for example). Having a guide such as this will help make Java apps look and feel the same across platforms, which can be very good, but for some reason, it's somewhat bothersome that the java app might not be consistant with the native apps on the computer.

A good example is how dialogs are done - WinXX tend to have the OK to the leftmost, MacOS to the rightmost. There's a few other similar examples.

What might be the next necessary step in the next java release (jdk 1.3) is to add another platform dependant part to the system so that when there are differences in the platform for placement of visual elements, the sandbox can set them up to act more like the native system.

Re:L&F Guidelines good

[Millennium]

BS. As an acknowledged expert in the field of marketing, I ask you this question.

Let's see some credentials. You certainly don't talk like an expert in the field of marketing, much less an acknowledged one. And you give us no evidence to believe you, and plenty not to.

Who is the #1 software producer Apple or Microsoft ?

On what scale, might I ask? Here, at least, you sound like a marketer. I'll give you that much.

Answer: Microsoft, because they know when to quit coding and start MARKETING

Which also explains why most of their software is so bad (I have to give a nod to Excel, which I'm forced to admit is respectable). However, here you also talk like a marketer.

Apple have seen the light recently in this regard, but as a marketing expert with an extremely technical background (NT admin, VB developer)

Again, spoken like a true marketer. NT administration hardly qualifies as "extremely" technical (technical, yes, "extremely," no). Nor does developing in VB, which even Microsoft markets as being for non-technical people.

I have to ask the question who are Sun or Apple to tell me how to write my GUI ? Do they know my target market ?

Um, yes, they do. Both of them, especially Apple, have spent millions of dollars researching human interface design. Who are they to tell you how to design your GUI? People who know more about GUI design than you do, that's who. You could do worse than to take the advice of experts.

Are they paying my development staff ? No they are not.

Directly, no, But consider: well-designed apps lead to good reviews. Good reviews lead to better sales. Better sales lead to more profit. More profit leads to better-paid developers. So, in an indirect way, they are helping to pay your development staff.

So they can go to hell.

So you'll have company after your boss and co-workers kill you for writing buggy apps with badly-designed interfaces? I can see why you wouldn't want to be lonely, but I don't think it'll happen.

Re:L&F Guidelines good

[Ed Avis]

Maybe some kind of meta-GUI is needed where you can say what buttons you want in a dialogue box, but not where to place them. The GridBagLayout type stuff is a step in this direction, but you still have to specify the positions of things, even though they are relative rather than absolute.

Things like Glade allow you to describe your GUI in XML. It's possible that you could write a high-level description of what you want in XML, and then use a 'Windows L&F style sheet' or a 'Motif L&F style sheet' together with a set of icons to automatically produce the desired effect. Or maybe this would be better done by actual code rather than getting carried away with style sheets. It would be very cool to simply say what you want the user to input, and have the layout taken care of by platform-specific rules.

Re:L&F Guidelines good

[Ed Avis]

It has always annoyed me how game designers seem to think they know all there is to know about UI design, and insist on creating their own strange point-and-click interface instead of using a Windows-type GUI (or Windows itself) which everyone is familiar with. It's the modern day equivalent of having to enter your name in the high-score table using the joystick, rather than being allowed to actually type the letters on the keyboard.

Inventing a special-purpose UI could be useful for a real-time god game, where everything has to be quickly accessible. But even in these cases the UI could often be made less bizarre and more intuitive without spoiling the game.

Good overview, but you need a practical guide

[Eamonn O'Synan]

This book, viewed on the web link given, seems to give a nice, graphical overview of the JFC as an official 'party line'.

But as a seasoned Swing developer, I would like to see in a book, not just the PR aspects (what's good, what looks nice, what you can achieve), but also some practical advice about overcoming the many bugs in JFC, the many workarounds you need to include in your code, the peculiar hacks that they've done with dialog boxes (especially in internal frames), the threading issues you may encounter (especially if you decide to multithread your front end), etc., etc.

So, read this and get inspired, try it and don't be too discouraged...





--------------------------------------

Ever read the CUA guidelines from IBM?

[crovira]

Great! Another book stating the obvious that nobody will read.

The problem is that nobody will read and apply anything from this book any more than they did when IBM came out with CUA guidelines manual when they created OS/2. (And that one just covered the obvious but it covered a lot of it! Even way back when before Windows 3.0)

Most software is drek because there is no QA done. This is specially true of the UI. Most skins and themes deserve to get their authors a good thrashing behind the wood shed. Finding a gem means that you had to devastate a resource somewhere.

No I didn't write the book, but I wrote the article(s) specially Rovira Diagrams (Computer Language Magazine, Jan 1990, V7N1) which gives some hints about how to think about how you integrate GUI into your apps and how you specify, code and document them...

I'll be glad when I stop looking at crap and the GUI isn't just look&feel by people who think stolen milk crates is an interior decorating "style."

desktop space

[Signal 11]

They said this book was a must on any developer's "physical desk". My "physical desk" at the moment has about 8 empty dew cans, a bag of reese's pieces, a bottle of windex and a rag (for the monitor), about 25 CDs, some floppy disks... quarter-pound of chiplets (the remains of the chips you ate - now inside the keyboard as well).. and exactly *two* pieces of paper.

Now, do you think I'm gonna be able to find space for this book in THAT?! Even the top of my monitor has stuff on it (ah, tux, looking beautiful as always)....

The book is also available on the web

[d3l1r1um]

Sun also has the whole book available on the web, along with updates and errata. Just follow the appropriate links from http://java.sun.com/products/jlf/guidelines.html.

Re:Obviously this book is a waste of time.

[Malc]

"In short forget about coding standards, design reviews and all that other ivory-tower nonsense, fire anyone suggesting such time-wasting strategies, and with the money you have saved, hire yourself some qualified marketing experts and watch the $$$s start rolling in."

Rubbish: don't talk such tripe.

The first product I worked on as a professional had 17 engineers coding like hell with no formal process. Guess what? When we introduced a formal process and started dictating our own deadlines (which seemed further in advance), our product improved, it was delivered more quickly, the user interface became usable, and most importantly, the satisfaction of our clients increased.

If you want to get up and market an awful product, that's fine by me. You're the one who will look foolish to potential clients. You're the one who will be laughed at at trade shows.

Coding standards do matter. For example, when you have people using combinations of spaces, tabs, different size indentation, different size tabs, you will not believe the number of bugs that can be introduced just because the indentation is screwed up on somebody else machine. That is the very simplest coding standard that we implemented. It saves a lot of time being able to sit down with somebody elses code and not have to figure out their conventions before fixing their bugs, or implement enhancements. A software profession shouldn't mind such things: they can keep their personal styles for their hobbies.

User Interfaces do matter. Without formal design, you can end up with an unuseable user interface that is completely inconsistent across the application. Customers generally only see the UI, and so their opinions of the whole product are based on this. It doesn't matter how good the underlying technology is, a flawed UI will lead a customer to believe the whole product is flawed. Besides, if they find a UI unuseable, they won't be able to get at your underlying technology.

Finally, with a properly implemented formal process, there should be very little UI fixing needed when the product is ready. In my experience, UI design goes in parallel with the rest of the product development. The UI design needs be started as soon as possible so that it can be reviewed (by non-engineers) and redesigned as necessary before it's implemented and the rest of the product is ready to ship.

You sound like a car salesman or a spammer.

Re:OT: Could anyone recommend a good beginners boo

[Industrial Disease]

You should at least take a look at Bruce Eckel's Thinking in Java. The PDF version is free (gratis, not libre), so you have nothing to lose by checking it out.

Here's one

[joss]

As another seasoned Swing developer I offer
one right here. Forget about swing, use FLTK instead (http://www.fltk.org/ ) Shit, write
it in COBOL, Visual Basic, assembly, anything but use Swing (er, except MFC which is even worse).

I've been using Swing for the last 2 years
(since it first came out). It's slow, buggy,
leaky, and did I mention slow. Check out the call stack at any point in a Swing program - it's
about 15 levels deep.

Doubtless I'll be called a troll for this. Fine, fuck you too, but I do know what I'm talking about. I admit I'm kindof bitter about this, but if people had been honest about Swing before I got into it I would have been saved a ton of grief.

Re:Obviously this book is a waste of time.

[Malc]

"No. I will be the one who is laughing. All the way to the bank. "

Uh-huh. If I was laughing all the way to the bank I wouldn't be bothering myself with this discussion.


"magic power of marketing spin"

You obviously haven't been using that today. Anyway, I haven't met anybody who has enough "magic power of marketing spin" to sell me a thing. You'd be a fool to try it on me.


"Rest assured I will take steps to fire anyone who suggests I am wrong. I KNOW development, I've been there and done it all before. You cannot tell me anything I don't know"

That sums it all up: you are a fool! Perhaps that is why you need to hide as an anonymous coward when posting? I haven't met anybody who knows everything (I have met a few arrogant/pompous twats who THINK they know everything - but I've taking pervse pleasuring in showing them up, which CAN ALWAYS be achieved).

*Follow* the existing standard instead!

[Gorimek]

UI standards are great.

The problem with this book is that there already *are* UI standards, and they decide to *not* follow them, and create their own instead.

Lets remember why a UI standard is good: It makes the behaviour of different programs consistent and predictable. The user does not have to learn a whole new way of working for each application, and when switching between program, the user does not have to remember a lot of special rules, but can focus on getting things done.

Unless these java programs are run in a java only environment, which I believe does not exist in the real world anytime soon, software written according to this "standard" will in fact be different, non-standard, and expose the poor user to the exact problems that a UI standard is supposed to solve.

Critique of book

[lordpixel]

I read thing book, and while its not bad, its incomplete. The stuff they do say is good, but unoriginal. And they things they skirt around are the hard issues.

In other words, its better than nothing - L&F guidelines good - incomplete guidelines bad.

The best thing about this book is the bibliography, which is very comprehensive and lists a lot of things you should read.
They're very open about the fact that they've simply copied a great deal from their references. Which is good - no point in reinventing the wheel, but there is a lack of imagination.


Here's my main objections:

You can summarise the entire book thus:

If an MS Windows standard exists, follow it blindly and without modification

If no Windows standard exists follow the Mac.

e.g. Close Window is Ctrl-W which is a Macism.
Find is Ctrl-F, Find again is Ctrl-G. Again Macisms. And why? Because there is no standard for find and find again on Windows. (OK alt-f4 is close window, but you can't really do that one handed unless you're a Vulcan so it doesn't count).

It sticks firmly to the Java Look and Feel - not touching any of the real issues or problems with this Look And Feel

e.g.
Windows - OK on left, File->Exit to quit
Mac - OK on right, File->Quit to quit
Linux - OK wherever, File->Quit, File->Exit both common

The Java L&F again follows Windows and Swing has no facility for the sort of overlays supported by Mozilla to deal with these issues.

According to Sun this is not a problem. The whole point of the Java L&F is that it works the same on all platforms, they say.

Oh dear. Sun demonstrate once again that they have no understanding of end users whatsoever.

Every application on your computer uses
File->Quit and has right hand side OK button. So you can just adapt to this one app thats totally different. Well yes, people are adaptable, but the idea of a set off look and feel guidelines that enshrines bad practise into the standard makes me slightly queasy. People want to get their jobs done, not suffer through Sun's UI designer's latest misjudgement.

The single biggest screw up in the Java L&F is the insistence that the alt key must be used for shortcuts. You cannot override this in your application.

This is a disaster area from an internationalisation standpoint - you can't enter a whole bunch of characters when using the Java look and feel as the native OS needs to use the alt key as part of it input method. Doh! Never mind about the Swedes, or those pesky Norwegian teenagers eh?

Speaking of UI - why is the comment entry text area on Slashdot so damn small?

Oh - and the screenshots show modal dialog boxes with *close boxes*. ARGGGGGHHHHHHHHH!!!!!!!
Lord Pixel - The cat who walks through walls

Sun guidelines apply to Metal L&F

[Foaf]

I remember reading the web version of the book when it was in beta (Only computer companies could make beta books).

It suggested that if you're coding for a particular platform then use the appropriate guidelines for that platform. So the Windows guidelines apply when you use the Windows L&F. The Sun guide recommended using the Metal/Swing L&F if it was likely that your app was to be used on more than one platform.

I design and build UIs in Java every day. I always follow the Windows guidelines because even though my code could be run on a UNIX box, it won't be.

While the Sun guidelines are pretty good, I would only recommend buying the book if you design with the Metal L&F.

It's ok

[Anonymous Coward]

Having developed GUIs fore more than 16 years in my professional career, I have no real problem with the book. It summarizes some of the obvious issues (for GUI professionals that is), and gives a nice overview about developing for the Metal L&F (and yes, they say right at the beginning that it is for the Metal L&F, and only for the Metal L&F, and nothing but the Metal L&F). Reading the /. comments it is obvious that most commenters haven't read the book at all. It is not for the Windows L&F, it is not for the CDE/Motif L&F. In generaly it talks about applications, and not so much about stupid applets.

There are open issues in the book - like in most GUI design guides. They sometimes don't follow their own rules in the book. So what? GUI design is hard, and the book authors have experienced just that with their own examples. They could have made the icons available for usage in own applications, they could have spent a few more words on how to actually implement some of the recommended behaviour. Like in most GUI design guides, they didn't - there are other books which fill the void.

They got some things plain wrong - at least in my opinion. E.g. placing dialog buttons to the lower left ensures the longest possible mouse move to reach one of the buttons (you click in an upper left entry field to start entering data, then you grab the mouse again and you have to move it to the lower right side of the window to click the button. They have "Close" instead of "Ok" buttons in notification dialogs - shiver. What does this mean? Nothing, other GUI design guides have the very same problems.

What do you get if you follow the advice in the book? A logical, predictable GUI, not to alien for the typical John Braindead who uses Windows or Mac. A GUI with the distinct Metal L&F. If you don't want that, don't use the book.

Will the book solve all your (GUI) problems? Nop. If you can't design GUIs, if you are not talented, if you don't have end user feedback, you will remain the very same clueless idiot you were before reading the book.

BTW, there is a general pattern in GUI design discussions. On one hand you have those who don't care, who don't know pain, and who develop crap. On the other hand you have the talented people who know that every GUI is just a compromise and a good GUI is a constant battle for perfection (which is never reached).

The first mentioned ones cry out loud whenver the words "GUI design guidelines" are mentioned (they deeply fear GUIs, because they know they always lose). The later ones invoke their brains and pick the useful stuff out of such guidelines (they too know they will lose, but they prefere to battle in style).