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
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.
This wizard is compliant with the guidelines.
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.
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.
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
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
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.
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.
P1: The layout and usage of UI widgets does not comply with the
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)
- "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.
- 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
- The title should be more explanatory. Suggestion: "Inheritance conflict".
- 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
- 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).
Step #2 - Name and Location
P3: RMI Access Created File, RMI Password Created File are confusing
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.
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.