The behavior of multiselect dimensions may require changes in the UI.
The fact that a dimension is tagged as multiselect should be transparent to the Presentation API developer. There is no special Presentation API development required to enable multiselect dimensions. There are no URL Query Parameters or API objects that are specific to multiselect dimensions.
However, the semantics of how the MDEX Engine interprets navigation queries and returns available refinements changes once a dimension is tagged as multiselect. After tagging a dimension as multiselect, the MDEX Engine will then enable multiple dimension values from the same dimension to be added to the navigation state.
The MDEX Engine behaves differently for the two types of multiselect dimensions:
Multiselect-AND – The MDEX Engine treats the list of dimension values selected from a multiselect-AND dimension as a Boolean AND operation. That is, the MDEX Engine will return all records that satisfy the Boolean AND of all the dimension values selected from a multiselect-AND dimension (for example, all records that have been tagged with "Apple" AND "Apricot"). The MDEX Engine will also continue to return refinements for a multiselect-AND dimension. The list of available refinements will be the set of dimension values that have not been chosen, and are still valid refinements for the results.
Multiselect-OR – A multiselect-OR dimension is analogous to a multiselect-AND dimension, except that a Boolean OR operation is performed instead (that is, all records that have been tagged with "Apple" OR "Apricot"). Keep in mind that selections from the multiselect-OR dimension do not affect what is returned. Though the result record set is determined using all selections in the navigation state, the MDEX Engine chooses the set of multiselect-OR refinements by looking at the set of records and ignoring existing selections from that multiselect-OR dimension. Also note that as more multiselect-OR dimension values are added to the navigation state, the set of record results gets larger instead of smaller, because adding more terms to an OR expands the set of results that satisfy the query.
A comparison of single-select and multiselect-OR dimensions shows the difference in the generation of standard and implicit refinements. The table shows these differences using a simplified case with only one selected dimension value:
Single-select dimension |
Multiselect-OR dimension |
---|---|
Children of the current dimension value are potential refinements because selecting one could reduce your record set. Those that would change your record set if selected are standard refinements, while those that would not change your record set if selected are implicit refinements. |
Children of the selected dimension value are not potential refinements, because selecting one would not expand the record set. Therefore, they are the implicit selections. |
Ancestors of the dimension value are not potential refinements, because selecting one would not reduce the record set. They are the implicit selections. |
Ancestors of the selected dimension value are potential refinements, because selecting one could expand your record set. Those that would change your record set if selected are standard refinements, while those that would not change your record set if selected are implicit refinements. |
Dimension values in the subtrees rooted at the siblings of the selected dimension value and its ancestors are also not potential refinements, because they correspond to record sets which are disjoint (or at least uninteresting to the user, based on their selected dimension value.) Note that these dimension values are not available as refinements in single-select dimensions, but are accessible in multiselect-AND dimensions. |
Dimension values in the subtrees rooted at the siblings of the selected dimension value and its ancestors are also potential refinements, because selecting one could expand your record set. Those that would change your record set if selected are standard refinements, while those that would not change your record set if selected are implicit refinements. |
The process of navigation in a single-select dimension can be conceptualized as walking up and down the dimension value tree. Multiselect-OR dimensions, in constrast, are inverted with respect to refinement generation: dimension values in the subtrees rooted at selections are implicit refinements, while all other dimension values are potential refinements.
Be careful when rendering the selected dimension values of multiselect-OR dimensions. It is possible to create an interface that might result in dead-ends when removing selected dimension values.
Consider this example: Dimension Alpha has been flagged as multiselect-OR, and contains dimension values 1 and 2. Dimension Beta contains dimension value 3.
Assume the user’s current query contains all three dimension values. The user’s current navigation state would represent the query:
"Return all records tagged with (1 or 2) and 3"
If the user then removes one of the dimension values from Dimension Alpha, a dead end could be reached. For example, if the user removes dimension value 1, the new query becomes:
"Return all records tagged with 2 and 3"
This could result in a dead end if no records are tagged with both dimension value 2 and 3.
Due to this behavior, it is recommended that the UI be designed so that the user must be forced to remove all dimension values from a multiselect-OR dimension when making changes to the list of selected dimension values.
Refinement counts on a refinement that is multiselect-OR indicate how many records in the result set will be tagged with the refinement if you select it. When there are no selections made yet, the refinement count is the same as it would be for single select and multi select dimensions. However, for subsequent selections, the refinement count may differ from the total number of records in the result set.
For example, suppose a
Cuisine
refinement is configured as multiselect-OR. In
the data set, there are 2 records tagged with only a
Chinese
property, 3 records tagged with only a
Japanese
property, and 1 record that has both of these
properties.
If an application user has not made any refinement selections yet, the refinement counts are as follows:
Cuisine
[ ] Chinese
(3)
[ ] Japanese
(4)
The record result list for this navigation state includes records 1, 2, 3, 4, 5, and 6.
If an application user first selects only
Chinese
, the refinement count is as follows:
Cuisine
[x] Chinese
[ ] Japanese
(4)
The record result list for this navigation state includes records 1, 2, and 3.
If an application user selects both
Chinese
and
Japanese
, as shown:
Cuisine
[x] Chinese
[x] Japanese
Then the record result list for this navigation state includes records 1, 2, 3, 4, 5, and 6.
Refinements for multiselect-OR dimensions are more expensive than refinements from single-select dimensions.
When making decisions about when to tag a dimension as multiselect, keep the following in mind: Users will take longer to refine the list of results, because each selection from a multiselect dimension still permits further refinements within that dimension.