Many of you that have installed Microsoft Dynamics NAV 2013 R2 have for sure noticed that the quick filter behavior has been redesigned in this release and that is why, in this post, we will go through all the changes and the intention behind them.
So let’s start with a bit of history; the first version of the quick filter was released in the Microsoft Dynamics NAV 2009 Windows client, where we replaced the filter window available in the development environment with a filter pane integrated on all Microsoft Dynamics NAV pages. Here the user both has the option of entering filter criteria as plain text and the ability of composing an advanced filter. If you would like to quickly search for a certain record, the recommended practice is to use the quick filter.
Let’s say, for example, that we want to find a contact in the contact list starting with “Man”. We can construct the filter by selecting the Name field and entering the text “man” in the search field.
Notice that all the contacts starting with “man” now appear in the results list. How is this working? Whatever we add to this filter will be internally translated to a string by adding ‘@’ in front and ‘*’ in the end. So our filter string ‘man’ becomes ‘@man*’ and the Windows client filters for any contact name that starts with “man” in upper or lower case.
The following table illustrates more Quick Filter search examples in Microsoft Dynamic NAV 2013.
All records that start with the string man and case insensitive.
All records that start with the string se and case insensitive.
Starts with Man and case sensitive
All records that start with the string Man
An exact string and case sensitive
All records that match man exactly
Ends with 1
All records that end with 1
Ends with and case insensitive
All records that end with man
Starts with and case insensitive
All records that start with man
As part of our development process we regularly perform usability studies and some of them showed the users instinctively thought of the quick filter as a search field and that is why we decided to modify the quick filter behavior to a “contains” rather than a “starts with”. So what does this mean?
Let’s construct the same filter in the Microsoft Dynamics NAV 2013 R2. Notice that the search results list includes contact names which start with “Man” and even have “Man” in the middle of the name.
What has changed? The entered filter will be translated to a string by adding ‘@*’ in front and ‘*’ in the end. So our filter string ‘man’ becomes ‘@*man*’ and the Windows client filters for any contact name that contains “man” in upper or lower case.
To start with in the RTM version of Microsoft Dynamics NAV 2013 R2 we have considered the simple user approach where the special characters in the filter criteria are ignored. However, in the Cumulative Update 13 for Microsoft Dynamics NAV 2013, we have refined the user experience and now respect the entered filter criteria.
The following table illustrates the Quick Filter search examples for the Cumulative Update 13 and later for Microsoft Dynamics NAV 2013.
All records that contain the string man and case insensitive.
All records that contain the string se and case insensitive.
We encourage you to check out the Cumulative Update 13 and we hope that this blog demystifies some of the behavioral differences of the quick filter across Microsoft Dynamics NAV product versions.
Quick filters ar crap. Any version of it. Can we have the field filter, table filter, flow filter forms back, please?
with best regards
Agreed, classic filters worked a lot better.
It's really a great idea to change filter behavior every cumulative update.
My suggestion is to change behavior randomly each 2 or 3 hours...
Where are the "Like" buttons next to these great comments?
Have you done any performance studies with these quickfilters or taken another approach with filtering than the classic approach?
It is commonly known that using wildcard filtering (*) has a huge impact on performance or search with option "Find as you type". We have learned our customers to use this as little as possible.
Try filtering the Web Client not consistent with the RTC, user experience ain't that great.
I've suggest on Microsoft Connect that this be changed. Here's what I'd like to see:
- When a filter is entered into the quickfilter field, add it to the "normal" filters (in the Filter pane that can be dropped down) and clear the quickfilter ready for the next filter to be entered
- When the user right-clicks on a field in the list and selects the option to "Filter to this Value", add it to the NORMAL filters - not the quick filter (right now this is extremely limited as you can only "filter to this value" on one field...the next one replaces it)
And...filter expressions should work the same everywhere. Inconsistency just confuses users.
Really like RHansen idea ..(has pop'ed in my brain a few times to though).. now that shortcuts got really messed up in rtc.. why not make it super easy to make a multifilters by right clicking to add the value of a field to a new filter line
I say .. let filters be custimizeable so each person can get what he/she wants..
good suggestion Rhansen, which is the link in connect to vote on it.
Good thing to add would be to have a property to set the default advanced filter which overrules the default setting of the first field (which it takes now). Most of the time 'No.' field is the first field, but you want to filter on Description or Name.
I think that the filtering works quite nice !!! A minor detail would be to act as in 2009 and below. Ind 2009 and earlier you could type '@*filter*' or '*@filter* with the same result. 2013/2013R REQUIRES that you start with a @-sign. This is annoying for upgrading customers that they have to remember that this has changed.
If one enters 'man' the apostrophes are automatically stripped. This is problematic, because it cannot be detected, if one has entered man, originally, (resulting in all matches *@man*) or 'man' (resulting in exact match). The originally entered filter or search text should not be changed automatically.
Filtering in quick filter, advanced filter, drop-down list and Find (Ctrl+F) window behave differently. Try answering customer's question, "why are the filtering different?" Other than saying, "that is how Microsoft has designed it", what else can we say? (Next question in their minds would probably be, "What is the reason for such bad design?")
Consistent behaviour and experience throughout the system is important when it comes to user interface, especially so if we want to pitch to the users that the product is easy to learn and to use... or is it?