Usability Issues with Filter Builder

[bbaker]

Version: SmartGWT Version: v10.0p_2015-12-10/LGPL Development Only
Browsers: All browsers

We're having a couple issues with the Filter Builder.

1. The Filter Builder omits any clause with an empty field and it will not be returned as criteria when filterBuilder.getCriteria() is called
2. The Filter Builder does not validate with any additional validators specified on the DataSourceField or ListGridField. Yet we do see there is some internal validation on Integer fields

We understand these may be by design, but the behaviors have caused us some usability woes.

Usability issues occur when the user enters a filter clause that contains an empty field, believing that this may represent some default value (i.e. zero or empty string), the user submits the filter, and since there is no way for us to detect they entered an empty field (that we've thought of), the filter is saved successfully, and does not behave as the user intended.

We would like to somehow give feedback to the user that a value is required to be entered for these fields. Do you have a recommended approach for this kind of scenario? Is there possibly some technical detail we missed?

I'm not attaching a sample, because you are likely aware of this behavior, but if you would like one, we can provide it.

Thanks

[Isomorphic]

1. getCriteria() has a parameter, includeEmptyValues, which can be passed as true to cause empty fields to be included in criteria. Note that while we make this option available, we consider it a usability downgrade to actually make use of it; our experience has shown that when users add a new clause but have not edited it, their expectation is the unedited blank clause has no effect (rather than being an explicit choice to match a blank string for example). 2. Validators declared for data being saved cannot be applied to criteria in general (in a FilterBuilder or elsewhere). A simple example is a length validator applied to a zip code or similar code; enforcing this would prevent entry of any partial zip code as filter criteria. If you have a situation where criteria should be rejected, the best approach is usually to analyze criteria received from the FilterBuilder and refuse to proceed with a pop up for the user. Another option would be to modify the editor used in the FilterBuilder so invalid criteria are not possible to enter.

[bbaker]

We've been brainstorming how to handle this scenario in our application. The problem is, every option is inconsistent with the current validation behavior. It seems odd to throw a popup for this error, when an invalid clause normally displays a warning icon next to the relevant field (i.e. in the filter builder, entering letters for an integer field). If we want to implement our own warning icon, it's a lot of work to design, implement and test, and the icon will be visually offset somewhere else on this form that is not indicative of which field is in violation.

Would it be reasonable for you to include a flag that could be set on the Filter Builder object or passed in as a parameter to the validate() function, which could enforce the requirement of fields? For example, on validation, if this flag is true and the field value of a clause is null, the builder would not pass validation and a warning icon could be displayed next to the relevant field in violation. This would add flexibility and a lot of value with potentially minimal effort.

[Isomorphic]

We're not sure what you mean here - are you trying to do something similar to "required" validation, forcing the user to enter a value?

Please be very specific about your scenario. The FilterBuilder has been used a lot of different ways and we've never had this come up as a "usability issue" so there seems to be something special about your usage or your user's expectations.

[bbaker]

Yes, the specific behavior we anticipate would be similar (possibly identical) to the 'required' validation.

Example Use Case:

1. User creates clause A
2. User inputs value into field for clause A
3. User creates clause B
4. User does not enter any value for the field in clause B
5. User clicks submit

Expected Result: A warning icon appears next to the blank field in clause B and the form is not submitted

We think this is the most consistent and intuitive user experience.

[Isomorphic]

We don't think this is more intuitive; in our experience end users understand that an empty text field means no filter value will be applied. Your proposed UI would introduce an annoying extra step when clearing criteria.

But, worse, consider a FilterBuilder in its initial state with one clause, where a filter value had been entered and a search performed, and now the user wants to remove the criteria and search with no criteria. Your proposed UI would block searching in this case and require yet another action from the user - perhaps setting the fieldName picker to a blank value (which isn't currently possible or needed).

What you could do instead is introduce a hint for the value field - something like "Enter filter value". This should make it very obvious that an empty field does not produce criteria, if that's your concern.

[Isomorphic]

Note that 6.1 in fact already features such hints, including using appropriate hints for different operators such as matchesField ("Select a field").

[bbaker]

There is simply a lack of flexibility with the filter builder. We would like to require fields. It's unclear why that would be difficult to implement when there is already validation on Integer fields. We have to change some behaviors of our system and implement a workaround to make the usability a little less awkward for our particular users.

So we've started down this path, and now we believe we've encountered a defect with the Filter Builder. The getCriteria(true) method does not return empty clauses with certain operators, even though the parameter includeEmptyValues is set to true .

Use Case 1:

1. Launch FilterBuilderOmitsEmptyFieldCritria.java (attached)
2. In the Filter Builder select 'Text Type' from the field drop down
3. Select 'equals (disregard case)' as the operator
4. Leave the value blank
5. Click the 'Display Criteria' button

Expected: filterBuilder.getCriteria(true).toJSON() displays in the 'Criteria JSON' Text area and contains criteria with a null value
Actual: No criteria is shown in the JSON returned

This occurs with several operators for Text and Integer field types. Some operators, 'between (inclusive)' for example, will return criteria with null values. It's unclear how many combinations of types and operators are possibly effected.

[Isomorphic]

Flexibilty has costs in both performance and complexity. When looking at where to build in flexibility, we look at plausible use cases. So you won't generally find the flexibility to make the system less functional or less usable, as seems to us to be the case here - you don't seem to have addressed the usability issue we pointed out.

Anyway, the bug you reported was fixed months ago - please grab the latest patched build.