NetBeans is an IDE, implemented in Java, and designed to create Java programs, with a particular orientation towards distributed and component-based systems.
This critique will focus on the Options dialog for NetBeans. The purpose of the Options dialog is to allow the user to configure the IDE. However, this purpose encompasses several tasks, such as:
This list is not exhaustive. Furthermore, there may be significant overlap between these tasks. Such a large (and vague) purpose makes designing an interface for the Options screen extremely difficult, and I will not attempt to offer a comprehensive solution in this critique. (However, I will make some general suggestions). In NetBeans, however, there are some basic and easily correctable design mistakes that make it far harder to use than similarly complex programs.
The largest problem is the lack of any way for the user to back out of their changes. A standard options dialog would provide a "Cancel" button, which reverts all of the changes made. Some may also provide a "Revert" button, which also reverts all changes, but without closing the dialog. This is worse because this is a modal dialog. If the user wished to experiment with different settings, he or she must change the setting, then close the dialog and see what has changed. If the user wishes to back out of his or her changes, the dialog must be reopened, and the user must remember exactly what he or she changed, and what the previous setting was.
Another problem is that the Options dialog contains important information that is hidden by default, difficult to discover, and difficult to understand once it has been discovered. In the center top of the previous screenshot, you will notice, to the left of the splitter, a set of three dots. This, and the thin line extending down from that area, are the only indication that there are more column on the left half of the dialog.
The user can drag that vertical line to the left, but this does not reveal the additional columns, unlike all similar interfaces I have encountered. Instead, the three dots simply expand into three less-than signs, confusing used as arrows.
A tooltip finally tells the user what to do. This tooltip could be found before the dots were expanded into arrows, but I never discovered it - possibly because the area that activated the tooltip was much smaller. Following the instructions, the full information is finally revealed. Once visible, the additional information is presented only via icons, which have no obvious interpretation.
The lack of a "Cancel" button is most likely because such functionality can be difficult to implement. From personal experience, I argue that it is many time more difficult to add this capability to applications that were not originally designed with it. I expect that this problem dates from an early design of the application that was never improved. The solution to this design problem is simple - the Options dialog must have a "Cancel" button, or equivalent functionality. This flaw is simply unacceptable for a program as complex as NetBeans. Some method of saving and importing sets of options could also be very useful, especially in situations where NetBeans is being used on many computers. It is entirely possible that this functionality already exists, but there is no obvious way to access it from the Options dialog.
The confusing hidden columns are more difficult to explain. It is possible that the designer was trying to avoid adding extra visual clutter to an interface that already includes an enormous amount of information. However, hiding information in this manner actually makes things far more difficult for the user than simply presenting the information. If all the information was available on screen, it might be difficult for the user to process it and find what they want. However, with this design, the user must also analyze the portions of the interface that do not present obvious information, in case something vital is hidden within them.
An easy suggestion is to simply abandon the attempts to avoid clutter by hiding information, and I believe that would be a small improvement. Furthermore, the contents of the "User" and "Default" columns might better be presented as text, rather than icons. If this is not practical (for example, due to space constraints), then better use of tooltips or other context-sensitive help would be good.
These suggestions, however, are only band-aids -- they do not address the core problem, which is the enormous complexity of this dialog. One approach might be to consider that the Options dialog actually has several semi-distinct purposes, as discussed above. Perhaps it could be broken up somehow, possibly into several dialogs. As a counterargument, however, the tree view on the left already provides a subdivision, and breaking it up could make it difficult to find individual options. Ultimately, I believe that this type of complexity is a good argument for developing ways to make complex applications more modular.