Slashdot Log In
Java Look and Feel Design Guidelines
from the make-it-look-right dept.
| 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. |
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.
L&F Guidelines good (Score:3)
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.
desktop space (Score:3)
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 (Score:3)
Re:Obviously this book is a waste of time. (Score:5)
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.
*Follow* the existing standard instead! (Score:3)
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 (Score:3)
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