rich client 2.0

Improving usability without using ComboBoxCellEditors


2. April 2007
Tom Seidel @ 10:42

celleditor_heading.pngIf you want to write a RCP that makes complex data-structure editable, the TableViewer with a CellEditor might becomes your first choice. It has the advantage to make a direct edit in the ui-component in which it is presented. Especially the ComboBoxCellEditor is the preferred way to select a value from a given list of items. But the use of ComboBoxCellEditors should be kept within a limit. If your application makes excessive use of this CellEditor with a heavy amount of items that can be chosen, CellEditors become a usability-nightmare. The following article describes a way how to use existing concepts in the eclipse sdk to avoid user-frustration and improve the usability of your application at the same time.

CellEditors are mechanisms from JFace to add editing capability to a TableViewer or a TreeViewer. Probably the most familiar CellEditor is the TextCellEditor. CellEditors are always assigned with an implementation of an ICellModifier that provides values for the CellEditor or retrieves edited values from the CellEditor. For further Information see the Docs.

CellEditors as usability-killers

The more you have to use CellEditors for special steps in your application the more uncomfortabe they become. Especially for "power users" who have to deal with a special function that is implemented via CellEditors the use of the application becomes frustrating. The dynamic population of selectable items in a ComboBoxCellEditor should also be a no-go, because if you have more than ten items in the ComboBox the widget becomes unusable. Surprisingly the Eclipse Top-Level Projects like EMF or BIRT are running in this usability dead alley (see Image). From my own experience in working with BIRT the use of CellEditors in frequently needed Widgets is really annoying, even more annoying than a specific lack of functionality.

DataSet Selection in BIRT - A usability-nighmare
Dynamic ComboBoxCellEditor in BIRT

Alternative Implementation

A cool and often used feature is the OpenTypeDialog in the JDT (Ctrl+Shift+T) or the TaskSelectionDialog (Ctrl+F12) in Mylar. It is a very easy and comfortable way to select an item, so why it is not used more often? I have decided to drop the ComboBoxCellEditor and implement a DialogCellEditor that opens such a dialog. The JFace-API requires an implementation of the following Methods. That is all.

PLAIN TEXT
JAVA:
  1. /* (non-Javadoc)
  2. * @see
  3. org.eclipse.jface.viewers.DialogCellEditor#openDialogBox(org.eclipse.swt.wid
  4. gets.Control)
  5. */
  6. @Override
  7. protected Object openDialogBox(final Control cellEditorWindow) {
  8.     final ModelObject returnValue = ((ModelObject) getValue());
  9.     // opening the dialog
  10.     final CountrySelectionDialog dialog = new CountrySelectionDialog(
  11.             cellEditorWindow.getShell());
  12.     if (dialog.open() == IDialogConstants.OK_ID) {
  13.         returnValue.setSelectedLocale((Locale) dialog.getFirstResult());
  14.     }
  15.     // returning the selected object to the cellmodifier implementation
  16.     return returnValue;
  17. }
  18. /* (non-Javadoc)
  19. * @see
  20. org.eclipse.jface.viewers.DialogCellEditor#createContents(org.eclipse.swt.wi
  21. dgets.Composite)
  22. */
  23. @Override
  24. protected Control createContents(final Composite cell) {
  25.     // return the control on an edit-request
  26.     this.label = new Label(cell, SWT.NONE);
  27.     return this.label;
  28. }
  29. /* (non-Javadoc)
  30. * @see
  31. org.eclipse.jface.viewers.DialogCellEditor#updateContents(java.lang.Object)
  32. */
  33. @Override
  34. protected void updateContents(final Object value) {
  35.     // updating the control
  36.     if (this.label != null && value != null) {
  37.         this.label.setText(((ModelObject) value).getSelectedLocale().getDisplayCountry());
  38.     }
  39. }

Advantages of a SelectionDialog

  • Using the comfortable JFace Viewer Implementations with Label-/ContentProvider/ViewerFilter/...
  • Using existing LabelDecorators for the selectable items.
  • Reusing the control in another context (e.g. as a WorkbenchAction)
  • Providing additional Information to the selected item.
  • More usability with more than ten selectable items

CellEditors since Eclipse 3.3

Since Eclipse 3.3 and the addition of some cool features in JFace the implementation of CellEditors has become much easier. Especially the new features of the TableViewer make the integration and customization very comfortable, see also org.eclipse.jface.viewers.EditingSupport.

Example Application

I have written a small application to reproduce the look & feel, especially the feel of using ComboBoxCellEditors vs. SelectionDialogs. The application shows a country-selection. Check out the application (or download) to get an idea.

Value selection via ComboBoxCellEditor
Example RCP with ComboBoxCellEditor
Value selection via Selection Dialog
Example RCP with Selection Dialog

Conclusion

Of course, CellEditors have a right to exist. Especially with the enhancements in 3.3 CellEditors become what they are supposed to be: small, handy, easy and fast to implement helpers for editing the data-model. But they should not be the hub of your application workflow. If special data is edited very frequently you should use alternative UI-Elements like the suggested SelectionDialog.

Download

Download the CellEditor vs SelectionDialog Example as RCP (Source included - 11 Mbyte)
cvs_persp.gif CVS-Checkout (more info)

3 Comments »

  1. Well I’m using ComboBoxCellEditor quite frequently and the only thing you have to make them usable with a large amount of items if to add keyboard support to them. I’ve a Viewer ontop of them and afterwards listen to KeyEvents automatically poping up the DropDown-List and applying a Filter on the items. This makes editing without any Mouse-Interaction possible.

    Comment by Tom Schindl — 6. April 2007 @ 13:42

  2. Well, sometimes it may be a pure matter of taste. In my opinion you should not use the ComboBoxCellEditor excessively. The keyboard support you mentioned is an important point to improve the handling.

    Comment by Tom Seidel — 12. April 2007 @ 11:00

  3. You could of just added same in-place filtering features with completion to the combobox editor. Using dialogs for editing individual table cells is rather flashy…

    Comment by Eugene Kuleshov — 16. April 2007 @ 18:13

RSS feed for comments on this post. TrackBack URI

Leave a comment

Powered by WordPress