Search Modifiers - To be or not to be. We need your input!

Hello!

I'm really hoping to get each of your input on this really important UX vs. functionality vs. screen density/cognitive load vs. persona problem that we face.

So regarding the things I've highlighted in the two screenshots below, which I'll call search field modifiers, I'm going to make a statement on future potential direction and would like your input.

I believe that 90% of users don't ever use these and therefore by default we should NOT display them everywhere all the time. So, proposed change is the default is to NOT show them and allow users and/or roles that want to see/use them to turn them back on.

Agree? Disagree? Do you use these? Are you ok with a change in the April update to remove them for all users with a user setting (or even configurable feature by role) to add them back?

Please dive in here!

Find more posts tagged with

Comments

Hannah Johnson

I personally feel that having the ability to turn them on is better than initially having them. However, I could see some users preferring it being there right away as they might not have the level of knowledge/comfort in knowing how to add them in.

Could there be an easy "trigger" to add them in vs going thru LPL to add? Also, could it be tied to personalization so if some users like it one way they can have it and others dont need it?

Stace Webley

We do use them to toggle between Contains, Starts With, In Range, Equals, etc. We find that the search goes much fast when using Equals. I would be a user that keeps them on if I had the option to do that. If they were not automatically on would the default be Contains? I think with Date fields we often select In Range.

VID013_SASO_Adding Dropdown, Extend Initiate and Submit.zip

Dr. Awesome

Yes, the easy "trigger" to add them is via the User Settings in the left hand menu. The user could turn them back on (and likely leave them on for good then). This is NOT an LPL config console thing.

Dr. Awesome

If they were not automatically on the defaults would continue to be the same as they are today. Contains for Alpha, Equals for Numeric, etc. This includes continuing on with when you make a config change to override the default and say on Field XYZ that say should be "starts with".

You bring up a great point with Dates. We did wonder if many users never use search modifiers outside of the Date search modifier switching from Equals to > < or In Range alot.

Hannah Johnson

even better!

Dr. Awesome

Now this is fascinating!

Last 14 days search usage by y'all on MT:

Heavy usage of default

curtis-evans

We have 45k associates, and there is a large percentage that likely would never notice this change. For certain roles and job functions, this is something that should be on by default though. As long as this could be configured to be on/off based on role, this could be okay, however I anticipate already that most roles would end up having it reactivated.

If not configurable by role, my added opinion is that toggling this on should not be a requirement when training a new associate, or re-education for everyone who may want to use it. It should be available by default if determined they need it. I think this has the opportunity to be a UX dissatisfier for those that would now have to turn it on where it's been available to them historically.

What I don't see, or am not fully understanding, is what is the benefit of the change? To Infor? To the associates? If the associate doesn't use the enhanced filtering, there is nothing to improve the UX aside from a small segment of screen real estate gained. Is there an impact to Infor Go with this as well?

Stace Webley

That looks pretty representative of how we use them.

unknown

I vote for a configurable feature at the role level with a Setting allowing individuals to enable/override "Robust Filtering". I suggest separate configurable features for list and search forms.

Looking at all the functionality that CommonSpirit has exposed to Employees, not a single page includes a list with Search exposed by default. Find a Coworker has a search form where Robust Filtering could be a benefit. Many will not use it, but the few that will likely find value in using it on Search Forms.

We will enable this feature for all roles other than Employee. We are trying to drive our culture to operate directly in the platform rather than exporting lists, fitlering/making decisions from excel, then keying in Infor (with the exception of ISD).

How does disabling these features by default align with any improvements planned to the reporting model?

Dr. Awesome

Thanks Curt! Awesome feedback.

For Infor's users the benefit of the change is less overall complexity and density of UI, less noise and scary things for those who just don't need it, nor do we want them to even see it. So overall, going for less cognitive load on certain users.

Your comment "I anticipate already that most roles would end up having it reactivated" lines up with my new thinking that perhaps we leave this ON by default and it's a turn OFF for the few model instead.

Dr. Awesome

Thanks Matt. "We will enable this feature for all roles other than Employee." lines up with a switch to potentially leave this ON by default and add configurable feature role level setting to turn it OFF. So, in your case, you'd simply need to tweak your Employee role(s).

For reporting, which are just Lists with the different search variations, this would all be the same discussion/feature on Reports.

unknown

Our vote would be to make the filter on/off toggle a user setting that would stick. We would prefer this not be a configurable role. I would recommend we start with the setting toggled on and let the users decide if they want to personalize it to off. Whatever they choose needs to stick for all lists.

Dr. Awesome

Just an update here - For the April 2023 update we are going to add a configurable feature that allows you to hide these search modifiers for the roles that you don't believe need them. The default will remain as it is today, ON, meaning users will continue to see the search modifiers by default.

Note, that IF the configurable feature is set to HIDE the search modifier the system still shows them for Date and TimeStamp type fields. ><, equals and in-range are just too reasonable and useful on those type of fields to hide.

Infor Financial Reporting and Analytics Advisory Group-20220510_100229-Meeting Recording.mp4

Copyright © 2025 Infor. All rights reserved.