Slashdot Mirror
Java Look and Feel Design Guidelines
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.
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.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
I've just recently gotten into programming, and this past week have been learning about using GUI's in Python on a Mac. I found the Apple Human Interface guidelines to be a lot of help. I know not everything of theirs is a holy grail to be copied, but maybe Java developers should publish a similar "standard."
That's Addison-_Wesley_. Like, you know, the ST-TNG kid ...
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...
--------------------------------------
--------------------------------------
Dere's a storm a-comin'...
Gcj and classpath are merging, so you will see a GTK based Swing in the not so distant future.
Unfortunaly occasional freeware coders haven't been very eager to read LNF guidelines so far and probably won't start now.
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."
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
GTK boys and girls should take note of this !
bob
This is a little offtopic here, but could anyone recommend a good Java book for a beginner? I'm a biology geek with little programming experience beyond ZZT-OOP.
I've been using O'Reilly's introductory Java book and it seems to be OK -- but it would be nice if it had a few more example programs to play around with. Some people have recommended Kris Jamsa's Java Now, any opinions here?
Client-side Java is dead. Or so Marc Andreeson said, anyway.
Spend your time reading about servlets & JSP instead.
Mark
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)....
>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.
And people wonder why there are so many crap products out there that crash when you look at them wrong. You gotta love the marketroid attitude. "Don't spend any time making a good product. Just spend money trying to convince people that they want crap."
>As usual my "open source" marketing advice is >free.
And worth every penny.
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.
Standards for User Interfaces are great for toilet bowls. If you want to create things that look just like everyone elses creation, then go into toilet bowl manufacturing.
@vSpid Like, Whatever
Stick with java in a nutshell by O'Reilly. If it's examples youw ant download a lot of Java code. Nutshell is an excellent teaching book and a wonderful reference. What's best is that when you're done using it for the first purpose you'll know it already for the second. We've got a lot of Java folks where I work and all the best learned from O'Reilly.
Consistent appearance and behavior... makes your skin crawl, doesn't it?
-- Eythain
Other than that, I've seen performance approaching that of compiled C++ out of Java, if the app takes pains to avoid new. UI layers simply don't do this.
Quantum mechanics: the dreams that stuff is made of.
"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.
Ivor Horton's "Beginning Java 2" was far from awful - nice compact introduction to OO programming concepts & how to use em in 2 neat chapters.
And you can't go wrong with the O'Reilly books, but that's common knowledge.
Your mileage may vary, of course.
Good luck!
I have a copy of this book and think it makes a pretty good "style guide". It's not really written for a technical audience but can be very helpful for people designing a GUI for an application. It is not as detailed, however, as the Apple Macintosh Human Interface Guidelines, though.
If you are truly "well respected" you would post using your real name rather than as an anonymous coward.
Obviously it was below the minimum quality or you wouldn't be complaining about it, would you?
Get off the high horse and learn to make some $$$s from all these dumb consumers out there who wouldn't recognise a quality operating system if it was given to them free, with source on a plate...
The term "bottom-feeder" comes to mind when I see a phrase like this. As a marketroid, you should also know that people use Windows as a matter of convenience. Yes it's buggy, but it comes pre-installed on their PC's and almost every program they would want to run is available for it, which is not the case with Linux.
Just as the users have their tradeoffs (quality for convenience), developers also have their tradeoffs. Coding standards really help a large project, especially if there is a lot of turnover. Design reviews and code walkthroughs are also a big help. The larger the project, the bigger the help. For smaller projects, though, these activities would take a much larger portion of the total development time, so they are usually scaled back or eliminated completely. Usually when I hear someone tell me that I should eliminate activities like these (or even worse, skip design and go straight to coding) they usually only have experience with short projects and think that techniques for the short projects scale up well.
I do care about making a good product and I'm not about to trash my principles to make a fast buck. If you think that the end goal is to get the most money, that's your opinion and that's why you're in marketing.
If you're not already a programmer, I would suggest Horton's /Beginning Java 2/. It is very readable, and the pace isn't too fast (I found /Just Java/, another frequently recommended book, to be too terse--it is aimed at the experienced programmer moving into Java).
You should carefully evaluate what it is that you want to do. I spent a lot of time trying to learn Java, then decided that for what I wanted to do a scripting language like Python was actually the way to go. I checked out Perl, but the maintainability seemed to be lacking (it seems that ESR and Perens have switched to Python for this reaon, from what I've read). Python is OO, so if I decide later that I really do need Java, I should be able to ease into it without as much difficulty.
hth,
>K
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.
Weblogging Considered Harmful:
I think it's funny when you people fall for a troll like the above.
"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."
Wow, where do you find programmers like that, most of the ones I've ever worked with would have absolute screaming fits if you ever dared to mention coding style standards... The majority of programmers re-write any other programmer's code to meet their style aesthestics, it's the first thing they do. The real fun comes when it's time to enforce standards, you get the 'it works, if you dont like my code, fix it yourself' attitude. Maybe I've just worked with prima-donnas, but they were productive coders, with the exception of a few who obfuscated to hide incompetance.
Starman97@Gmail.com (bring it on spammers)
One book "Microsoft Secrets"
Quality is not the result of coding standards.
However, quality developers may choose to use coding standards to improve their code quality.
I think this marketing guy half gets it, in that he understands that process must not be allowed to interfere with letting the developers do their job.
The point is, could you write down a set of instructions in a book, so I can learn to swim simply by reading the book? Or would it be better for me to try it for myself?
Guidelines are fine, but they are there to be ignored.
Finally, developers do not dictate deadlines. Like it or not, it is the market place which dictates the deadlines. Products stand or fall by being in the right place at the right time, and so time-to-market is of fundamental importance, quality (for closed-source commercial software) is at best of secondary importance. Sad but true.
No. I will be the one who is laughing. All the way to the bank.
I will not look foolish, because I have the magic power of marketing spin at my disposal.
In short, I follow the Microsoft model. Ship early, ship good-enough, charge for support and market the hell out of the product.
I used to work for an ISO9000 organization, its development processes were Byzantine, and the end result was often bug-ridden and late. It was however well documented.
The consumer wants it NOW, and does not care if your non-const functions are const or if someone used a pointer where they should have used a reference, or whether you indented 8 spaces or 4.
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, and I've heard every excuse under the sun.
If you are not ready to ship when MARKETING tells you. You are out of the door....
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.
http://rareformnewmedia.com/
-Peace
Dave
Free as in "the Truth shall set you..."
If I recall my European case law correctly, Intertransglobal Internet Solutions vs Hammersmith County Council in London, England was the landmark case for this.
Apparently their ship date slipped due to attempting to make their code comply with the OSF Motif user interface guidelines. The code was working perfectly, but some of the menu options did not have the correct accelerator "short cuts" defined. (Admittedly there could be a health & safety issue here but bear with me)
The plaitiff in this case was awarded exemplary damages, despite proof from the defense that the product was "of merchantable quality" and "fit for purpose". (the normal standards for consumer protection in the United Kingdom)
The end result was that the company went bankrupt and never produced another application again.
I sure hope I never find myself defending a suit against you, but our legal dept usually handles this. They have plenty of "contacts" who can be very "persuasive" with anyone foolish enough to go up against us!!!
dmg
I started a project a while back which used swing for its gui. It had graphics, 640x480. and it ran at about 15 fps on the fastest machine I tried it on (PIII 550 running Windows). Nothing fancy. Not quake. Red and blue dots on a black background. Nothing I could do would make it go faster. So I scrapped the project. Don't try swing if you need anything graphical other than buttons.
Become a FSF associate member before the low #s are used
"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).
Bruce Eckel's _Thinking in Java_ is worth checking out.
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.
I read this book and was really disappointed with the lack of
references for design decisions throughout the book. As a result, many
of the guidelines seem arbitrary and somewhat whimsical.
I agree that it may be more prudent (at this point in time) to
create a layout manager that places objects consistent to the
current look and feel.
-B
What conclusion can you draw from this ?
You are probably correct.
dmg
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
Lord Pixel - The cat who walks through walls
A little bigger on the inside than out
"Wow, where do you find programmers like that, most of the ones I've ever worked with would have absolute screaming fits if you ever dared to mention coding style standards... "
Then they would be fireed where I work...
"The majority of programmers re-write any other programmer's code to meet their style aesthestics, it's the first thing they do."
How do your configuration management people keep track of changes when a diff shows 90% of the file has changed, and it turns out that it was because some prick re-indened the file?
"The real fun comes when it's time to enforce standards, you get the 'it works, if you dont like my code, fix it yourself' attitude."
We created coding standards up-front. Code that does not meet the coding standards will NOT make it through the code review. It is then the job of the enginer that wrote the code to fix it before it will be included in the baseline. In short, code is assumed to be broken until it makes it through review. Code that fails the standards is broken by denfinition. Period.
"Maybe I've just worked with prima-donnas, but they were productive coders, with the exception of a few who obfuscated to hide incompetance."
They wouldn't have been able to hide their incompetance if they followed coding standards. Besides that, it almost sounds as though these coders never had their code reviewed by their peers. We do. Every line. That's part of the reason for coding standards. I'm a firm believer in peer review. As such, I believe in coding standards. If nothing else, they make per reviews easier, since everyone is familiar with the coding style.
Stop being so patronising about my chosen profession. It is a perfectly valid career, and we are not as clueless as the elitists on Slashdot like to think. This is part of the problem. We know how much time you spend surfing the web when you should be busy writing great software. We can also see all your trendy new technologies for what they are, same sh** different box.
Java ? It's just an poor imitation of Smalltalk (write once run anywhere was a reality in the 1980's)
C++ ? An inferior overly-complex language that deserves to die.
XML ? Well its EDI all over again. We marketers cannot be hoodwinked, we know you are all wasting lots of time.
If you are a commerical software producer it is your LEGAL OBLIGATION TO YOUR STOCKHOLDERS to get the most money.
Everything, and I mean EVERYTHING else is BS.
However, if you want to write quality bug free perfect code, by all means go ahead and do it, but not in my time. I'm paying the bills, I will be the judge and determine what is and isn't acceptable.
I am just glad I work for an organisation that takes marketing seriously and gives its marketers the respect, not to mention the $$$s they so richly deserve.
dmg
I really liked "On to Java" by Winston & Narasimhan from Addison Wesley. Lots of short chapters that introduced (and demonstrated) a single concept at a time. I kept the Nutshell book at hand as a reference.
Java in a Nutshell is an amazing reference, once you know what your doing. In that squishy in between time, there is no better than Sun's own core java series.
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.
my blog: good times, man, good times
Try DKJava.
Thank you.
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).
What about the fact that Sun wrote checks that DISABLE the Windows and Mac L&F UIs if you are not running on a Windows or Mac system? When swing was being developed Sun promised that you would be able to use any L&F on any platform, but they they locked them down claiming some crap about a L&F lawsuit.
What discussions, like this one, of UI standards usually miss is that UI standards benefit experienced users as much as newbies, if not more. The point of these guidelines and standards is to allow people to reuse their knowledge. It's a major time saver to not have to figure out new stuff constantly.
Think of the confusing array of copy keystrokes you may use in a day:
esc w (emacs)
ctrl k ctrl u(pico)
ctrl x (windows)
ctrl insert (secureCRT under windows)
the attention you have to spend tracking this stuff would be better spent elsewhere.
That is the relevance of a book like this. However, the reviewer doesn't discuss the quality of the standards given by the books, which makes the review much less useful.
Marketing is good and needed.
Still, if a product is unusable, it is real hard to market.
It _will_ make it through if you are late for an important money-related deadline. Trust me on this.
I'm sorry but how did this get moderated up twice for just giving a link from the review?
I know you're a beginner, but you really need to get "the bible" (at least IMHO). Get "The Java Programming Language" by Ken Arnold and James Gosling. It is *the* book for reference on Java and has some good examples.