Task T149391, about the Active Filter Display Area, defines two varieties of so-called "Conflict Display States" (see the definitions below, in gray). In both cases, the specified conditions are handled by graying out the relevant filter tags and showing a specialized tooltip explaining what caused the state. I think we could kick the system's response to the user in these cases up a notch, for this reason. These cases differ from the similar "'No Effect' Display States" in one crucial way: the No-Effect cases really have impact on the user, who will—despite the inelegance of her approach—get what she asked for. So telling her what she did wrong isn't really that critical. The tooltips are sufficient in case she's curious." This subtask fully defines those states and all the interface and other changes that pertain to them.
With the conflict states, however, the user's search will always yield no results. She'll see the same message in the Results area as any other search that yields no results: "No contributions meet the selected criteria. Try making the search broader by removing some filters." But "broader" isn't really what's required to resolve a "Conflict" state.
I think we should distinguish between normal cases where a search yields no results vs. cases where an inherent and non-obvious logical problem with the search criteria causes the null result. In such cases, I think the Results Area message above should be replaced by something more like the "Conflict" tooltips defined in T149385, which explain to the user what happened. Something along the lines of:
**No results displayed because the search criteria are in conflict.**=Conflict Display States=
The "New User" filter finds only registered users, so the “Unregistered” filter is canceling its effect. Two more conflicts found.%%%
@Pginer-wmf, if you agree, I'll craft those messages and add them to T149385. Please feel free to provide a design for how, exactly, a message like the one above would be displayed.
> **===Conflict between Unregistered & Experience filters**===
> The Experience filters find only Registered users. If the user selects the Unregistered filter and any combination of Experience filters at the same time, then the filters cancel each other out andout, no results will be found and:
- The tags in the Active Filter Area for all of the conflicting filters will turn grayred (see design below)
> - On rollover one of two tooltips will display: one tooltip for the Experience filters and one for the Unregistered filter (see T149385, under "Experience vs. under TRegistered/Unregistered tooltips" for wording of both).
> ** - The Results Area will display a special message. (See T149385, under "Results Area Conflict Messages" for final text)
===Conflict between Logged Actions or Wikidata Edits and any ORES filter**===
> Logged Actions and Wikidata Edits are not scored by ORESre not scored by ORES, and the ORES extension does not yet handle propagated Wikidata Edits (see T158025) . Thus if the user selects either or both of these filters (and __no other filter in the Type of Change group__) along with any combination of Intent or Quality (ORES) filters, then the filters cancel each other out. No results will be displayed and:
- The tags in the Active Filter Area for all of the conflicting filters will turn red (see design below).
> - The tags in the Active Filter Area for all of the conflicting filters will turn gray - On rollover one of four tooltips will display (see T149385, under "Logged Actions or Wikidata vs. ORES tooltips" for conditions of use and wording for each).
> - On rollover one of two tooltips will display: one tooltip for the ORES filters and one for the Wikidata or Logged Actions filters (see T149385, under Tooltips for wording of both). - The Results Area will display a special message. (See T149385, under "Results Area Conflict Messages," for final text)