JMX Support UI Specification Review II

Author: Jiri Kopsa
$Revision: 1.1 $ $Date: 2005/04/19 11:59:23 $

This is a review of the JMX Module (version 13 April 2005), which can be downloaded from:

This review was preceded with a review of UI specification. The findings that were done in the preceding review but were not yet corrected are written in italics.

New JMX Agent Wizard

This wizard is compliant with the guidelines.

Workflow: New JMX Bean Wizard

P1: Wrong tables behaviour

This applies to the tables in Step #2, Step #3 and the tables in the dialogs activated with the "Edit" buttons.
  • User should be allowed to select a row; the actions (remove) should relate to the selected row, not the last one. When a row is added it should be selected.
  • The "Remove ..." buttons should be disabled if the table is empty.
  • If a row is removed, a row that follows it should be selected.
You may also consult the Java Look&Feel Design Guideline.

P1: Package text field should have the same behaviour as in the New Java Class Wizard.

Currently, when a package name is typed, it starts to appear in the project window immediately. When "." is typed after a name, it starts to behave even more curiously. If the wizard is canceled the package remains in the project.

P2: Description fields not used in Standard MBean

It seems that the description fields (bean, attributes, operations) are not used in Standard MBeans.  If that is true, the description field should be disabled and description columns should be hidden (or disabled) if the "Standard MBean" type is chosen.

P2: Finish button disabled in Step #2

The Finish button is disabled in Step #2 although it is possible to finish the wizard in Step #2 without any attributes and/or operations added. The finish button should be enabled in the Step #2 if an empty MBean is allowed (although not reasonable), or a validation forcing the user to add an attribute/operation should be added to the Step #3.

You may want to consult the Tools User Inteface Styleguide.

P1: Wizard behaviour in regards to JUnit tests

In general, if the Finish button is pressed before reaching the last page, the default values for the rest of the pages should be used. This is not considered in the New JMX Bean Wizard. If the Finish button is pressed before the last page is reached, a JUnit test is not created. However, when reached that page, JUnit is created without any other user input needed.

A solution was suggested in the previous UI review:
The "JUnit Test Generation" checkbox should be moved to the corresponding step (#5).
The top components should be preceded with a check box "Create a JUnit Test" (which would disable all the remaining components if unchecked).

The layout of the components might be as on the following mockup then. It also suggests some changes to the wording, see the findings in the style section. If the "Create JUnit Test" checkbox is not selected, the other components are disabled.

Figure #1 - New JMX Bean wizard -  Step #5

The use-cases are not well known to the reviewer, but it seems that the JUnit test should not be created by default, thus the checkbox should not be selected by default.

P1: The default JUnit Test Class Name should differ from the MBean Class Name

Optimally it should default to the name of the bean appended with "Test" (as in New Test for Existing Class). It might be also non-editable (as in that wizard).

P3: Description text area default value in Step #2

The description text area contains "NewJMXClass description" as a default value. However, if the class already exists when the Step #2 is entered, the description text area contains "<MBean> description".  This could be perceived as a BUG by the users. See the next finding.

P3: Default values in Step #2, #3 and #4 (applies to Description text area, tables in the steps and edit dialogs)

In most cases, the user will change the description to a more reasonable one. However this is not as easy as in other components with default values. For example, default Class Name can be changed with double-clicking on the text field and typing a new name. The same method cannot be used in the description text area or table cells.

There might be several solutions (ordered by priority):
  • Set the values to empty by default
    This seems to be reasonable in case that:
  • Description is not required and can be empty.
  • The item can be identified with its name in the management tools (JConsole) and the description field is just additional information (leaving it with a name of the item does not add any information).

  • Provide useful default values
    In this case the (default) values would be changed automatically according to the updates done to the names by the user. It seems that the word "Description" is useless - it would not be contained in a reasonable description.

  • Provide one-word default values
    So that can be easily overwritten.
  • P1: Cancel button in Edit dialogs

    It is always good to provide cancel/undo functionality. In the Edit dialogs it is provided by the [x] button. In such cases, there must be also "Cancel" button. The label of the "Close" button will be then changed to "OK". Optimally the OK and Cancel buttons should not be in one group with the "Add ...", "Remove ...". We might place them to the right of the table.

    However, there are several arguments to step aside the guidelines in this case:
    • We are short of "horizontal screen estate".
    • The dialog is simple, it contains only one component - the table.
    • The same pattern is applied in the wizard pages as well.
    Thus all the four buttons can be put into one row in the following order: Add / Remove /  OK / Cancel, whereas the spacing between Remove and OK should be 17 pixels. The whole group of buttons should be aligned to the right border (in all cases).

    Style: New JMX MBean Wizard

    P1: The layout and usage of UI widgets does not comply with the guidelines

    Step #2 - MBean Definition

    There are following issues/suggestions:
    • The label "Description" should be top aligned with the text area and the spacing between the label and the component should be at least 11 pixels. Optimally it would be aligned with the components in the top part of the wizard.
    • Help Button should be disabled if none help is provided (this applies to all steps).
    • The "Specify the MBean Type:" titled border should be replaced with a label (i.e. there should not be any border). This was already mentioned in the previouis UI review:
      The MBeanType TitledBorder should be replaced with a label "Specify the MBean Type:", which should be separated from top components with a separator (see New Java Class Wizard).

    Step #3 - Specify Attibutes and Operations and Step #4 - Add Notifications
    • The warning message that appears in Step #2 if the Package is not specified, should be hidden when going to step #3.
    • Mnemonics should be assigned to the "Add ..." and "Remove ..." buttons. Suggestion: Add Attribute (A), Remove Attribute (R), Add Operation (O), Remove Operation (M), Add Notification (A), Remove Notification (R), Add Parameter/Exception/Type(A), Remove Parameter/Exception/Type (R), Close (C)
    Edit dialogs:
    • "Remove type" button label should be capitalised to "Remove Type"
    • There should be 12 pixels spacing between table and dialog border in the edit dialogs.
    Operation Exceptions dialog:
    • If there is an inheritance conflict between exception classes, an error message box appears.
    • It should have only one button "OK".
    • The exclamation mark in the message should not be preceded with a space.  It might also say "The list contains two or more exceptions belonging to the same class!" or just " The list contains exceptions belonging ..." instead of "The list contains two exceptions belonging".
    • The title should be more explanatory. Suggestion: "Inheritance conflict".
    Step #5 - Specify JUnit Test

    • The wording of the labels "Optional code" and "Optional comments" might be changed to the one suggested in the mockup (Figure #1).
    • In general, a label describing the checkbox should be part of the JCheckBox component.  This allows the user to select the checkbox by clicking on the label. This is not done for the comoboxes on this panel.
    • Mnemonic should be attached to the checkboxes. Suggesting: T, D, J, S
    • The layout of the components (checkboxes) might be adjusted according to the mockup (Figure #1).

    P3: "Created File" and "Other Created File" fields

    Might be changed to "Class File" and "Interface File". The "Interface File" should be then moved above the separator and aligned with the other components.

    P1: The title of the Step #2 and Step #5

    The title of the step should be always equal to the name of the step in the left pane.
    • The name of the step #2 should be changed to "Name, Location and Type" (already mentioned in the UI review).
    • The name of the step in the left pane (currently "MBean Definition") should be equal with the name in the title of the step.

    P2: The Edit dialogs should have NetBeans icon

    P2: The title of the Edit dialogs should have the form "Edit " + "Operation Parameters"/"Operation Exception" etc.  (or shorter Edit Parameters/ Edit Exceptions).

    Style: Management Property File Wizard

    Step #2 - Name and Location

    P3: RMI Access Created File, RMI Password Created File are confusing

    These files should be presented only if they really will be created (i.e. authenticate checkbox is selected). The functional spec also mentions a possibility to choose an existing file.

    Step #3 - Management Property File Wizard

    P1: The layout and usage of UI widgets does not comply with the guidelines

    • The wizard should not resize itself.
    • The layout of the components needs to be adjusted according to the guidelines (TODO: proposal will be provided).

    P1: The Edit buttons and Browse button are not working

    The wizard might be also simplified (i.e. editing functionality might be removed); the property file can be edited in a property file editor.

    Style: Remote Management Configuration Dialogue

    P1: The layout and usage of UI widgets does not comply with the guidelines

    P3: The purpose of the dialog is not clear; some explanation labels might be added.

    P1: Pressing ESC button invokes "OK" action; Cancel button is missing.

    Workflow: Run Debug Actions

    Run/Debug actions are still confusing. Let's discuss them on todays meeting.

    Project Features

    About this Project

    ui was started in November 2009, is owned by Jiří Kovalský, and has 43 members.
    By use of this website, you agree to the NetBeans Policies and Terms of Use (revision 20160708.bf2ac18). © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo
    Please Confirm