ComboBoxItem with showFilterEditor and pickListFields

[yavery]

Hi,

I have a ComboBoxItem for which I configure a pickListProperties with showFilterEditor:true. I also
provide an array of fields for the pickListFields property.

Under Chrome and Firefox, all behaves as I'd expect, but under Internet Exploder, as soon as I
try clicking in one of the filter fields, the picker closes. A flashing cursor is still visible following
the picker closing.

I've tried this out using the 8.3p November 2nd release. Any idea why this is happening ?

Following is an extract for the method's code I use. I have also included some screen shots.

Thanking you in advance for any insight.

	//--------------------------------------------------------------------------------------------------------------------------------
	getProductPickerFieldDefinition : function(properties)
	{
		var baseProperties =
		{
			name : 'product',
			title : MeiStrings.get('product.search.field.title'),
			width : 300,
			editorType : 'ComboBoxItem',
			displayField : 'name',
			valueField : 'primaryKey',
			addUnknownValues : false,
			optionDataSource : 'dsProductMemberPickerOptions',
			sortField : 'name',
			sortDirection : 'ascending',
			hint : MeiStrings.get('product.search.field.hint'),
			showHintInField : true,
			textMatchStyle : 'substring',
			pickListWidth : 550,
			pickListHeight : 245,
			criteriaProperties : null,
			pickListProperties: 
			{
			     showFilterEditor : true,
			     handleFilterEditorSubmit  : function(criteria, context, callback)
			     {
			          context['startRow'] = 0;
			          return this.Super('handleFilterEditorSubmit', arguments);
			     }
			},
			pickListFields :
			[
				{ name : 'code', width : '20%', title : MeiStrings.get('product.code') },
				{ name : 'name', width : '60%', title : MeiStrings.get('product.name') }
			]
		};

		var fld = isc.addProperties(baseProperties, properties);

		return fld;
	}

[Isomorphic]

What's happening is that focus moves away from the PickList-as-such and into the FilterEditor, and this is detected as focus moving away from the ComboBoxItem, which should normally hide the PickList (as in, tabbing to the next field, clicking elsewhere, etc).

The difference in browser behavior here has to do with IE's horrific focus handling bugs.

Bigger picture, this was previously brought up and marked "won't fix". This interface - a comboBox filter field and per-field filters - has lots of weird user experience issues in terms of how the different filters strings are supposed to interact. If you want per-field filtering, we'd recommend enabling it for a SelectItem, as shown in samples.

[yavery]

Hi,

Your proposed alternative works but doesn't provide the same visual feedback to the user ...

In our specific user scenario, we need to filter on specific fields and have a visual cue for the
user to know about which columns are filtered and using which value ... Your filterEditor feature
offered just that, while the proposed alternative doesn't ...

Any thing that could be done to have you change your mind and have this "defect" moved
from "won't fix" to "will fix" ?

Thanks,

[Isomorphic]

Again, our recommendation is to use SelectItem with the FilterEditor enabled on the PickList, which seems to provide exactly what you just described.

Just so there's no ambiguity, here's the sample. The SelectItem on the left has a filterEditor enabled.

[yavery]

Indeed the SelectItem+FilterEditor combination does provide what we are looking for, but has
severe "massive data entry" limitations when compared to the ComboBoxItem ...

Its usage requires additional mouse clicks for the user to filter and select values, whereas the ComboBoxItem
allows users to use the field's base input box to address 80%+ of their search needs. They can resort to the
filterEditor only to address those other situations (20%) where the base search doesn't provide the expected results.

I don't think that the SelectItem approach will work for us, unfortunately. The other reason for that being, is that our
current app version uses ComboBoxItem and that's what our users have been using for the last few years ... All
we're trying to do now is add "more advanced" filtering to what's already in their hands.

We're looking for something that would combine both data entry speed (ComboBoxItem) and more powerful filtering
(with visual cue on filters and ways to clear filters just like the FilterEditor feature does).

Anything else you can suggest ?

Thanks,

[Isomorphic]

To further explain the issue with simultaneously showing normal comboBox filtering and a FilterEditor in the pickList is that it's not clear to the end user how these filters are supposed to interact.

Consider, for example, entering some criteria in the filterEditor then returning to the comboBox and hitting tab (with completeOnTab enabled). In what context did you just ask for completion - just the filter string in the comboBox as such or the combined comboBox and filterEditor criteria?

This is one of several usability issues with two sets of filter fields.

As far as an interface that meets your requirements, you could use ComboBoxItem with a FormItemIcon that pops up a more advanced filtering interface.

[yavery]

Hi,

The way we have it configured currently doesn't seem to be exposing the usability issues you
are mentioning (on FireFox or Chrome). Not that there aren't any, but our particular setup
doesn't seem to be exposing them.

The beauty of having ComboBoxItem + FilterEditor is that the user sees the "default filters" the app
pushes down on him, can clear them, etc., whereas with the proposed approach (using a FormItemIcom),
the "default filters" would only be visible to the user when he clicks on that button to open
the "advanced filters" popup.

We really like how the ComboBoxItem + FilterEditor works with Chrome and FireFox and would like
to have that exact same behaviour with Internet Explorer ...

How can that be achieved ?

Thanks,

[Isomorphic]

The way we have it configured currently doesn't seem to be exposing the usability issues you
are mentioning (on FireFox or Chrome). Not that there aren't any, but our particular setup
doesn't seem to be exposing them.

We don't understand this assertion. There is no "configuration" that would mitigate the usability issue we just took the time to explain.

We really like how the ComboBoxItem + FilterEditor works with Chrome and FireFox and would like
to have that exact same behaviour with Internet Explorer ...

How can that be achieved ?

Sorry, but we're not willing to dive into the nastiness of Internet Explorer focus bugs to produce an interface that we think is fundamentally flawed, so we can't really even offer Feature Sponsorship here, as we do not want to support the "feature" - it's the kind of thing that would break very, very easily, especially when you consider that the FilterEditor can have lots of different types of editors in it, some of which have picklists or pop-ups of their own.

If you can imagine some other interface that doesn't have usability issues, we can advise on how to build it, or propose a Feature Sponsorship if necessary.

[yavery]

We don't understand this assertion. There is no "configuration" that would mitigate the usability issue we just took the time to explain.

The assertion is possible because I personally tested the scenario you outlined with our specific setup,
on Chrome. Unless I misunderstood your steps, I have not experienced any issues.

By configuration, I meant the nature of the fields hosted inside the "pickListFields". We don't have
any "advanced editor" fields or anything ... I understand that some more evolved editors could break this,
but in our particular "configuration", we don't have such fields that cause unwanted side effects.

We're like so close to having this working ... It works on Chrome and FireFox ...

I understand you don't want to fix this because you need to support well beyond "our configuration",
so I guess we'll have to be looking for some other solution to our problem.

If you ever change your mind, please let me know.

Thanks,

[Isomorphic]

The assertion is possible because I personally tested the scenario you outlined with our specific setup,
on Chrome. Unless I misunderstood your steps, I have not experienced any issues.

This is the issue we described:

Consider, for example, entering some criteria in the filterEditor then returning to the comboBox and hitting tab (with completeOnTab enabled). In what context did you just ask for completion - just the filter string in the comboBox as such or the combined comboBox and filterEditor criteria?

This is a usability issue, not a crash.

The issue is that the user doesn't have a way of knowing what is going to happen.

If you, as the developer, *do* know what's going to happen.. that's an unsurprising result :) .. and does not mitigate the usability issue.

[yavery]

I think this is a "you'd need to show me or I'd need to show you" type of thing ... I've been re-reading
your scenario and doing it over and over again, even having another person try it out and the only
aspect we see is that when using the filterEditor (instead of the actual field), data entry is solely used
for filtering, not data entry, hence, when you tab out, the filterEditor value isn't taken as a field value
for the field, which to me, is as expected, but I'm a developer, so my usability standards might not be
on par with a regular user's ;-) ...

Anyways, I understand that this is not something you're willing to fix, so as I said, we'll be looking for
something else to answer our needs.

Thanks,

[Isomorphic]

Oh, you're not following the description.

To clarify, say you are filtering supplyItem and you enter "adding" so a bunch of adding machines show up. You then go into the FilterEditor and filter by price or some other field and narrow to one result, then you click back in the ComboBox field and hit tab.

What did you just select - the first result that matches "adding", or the single result that was shown once you added criteria in the FilterEditor?

Does your answer change if you then leave the field by clicking, come back, and tab out again? The user doesn't even see the PickList in this case.

Note that, aside from this being a usability issue, because this mode is unsupported, the actual results are not specified, and known to be timing-dependent!