Locating Things in Enterprise Web Applications … Do You Search, Filter, Find, Sort?

The number of objects that are being managed and monitored by enterprise applications is continually increasing.  Building lightweight, agile and scalable solutions is extremely important, but having easy to use design patterns to locate things and using those patterns consistently between products in a company portfolio are equally important.
Locating a specific item in a data set can be a difficult task when dealing with a large dataset.  We are working on some patterns in PatternFly to improve locating “things” in enterprise web applications.  There are a few patterns which we have identified as being helpful to a user in locating a specific item: Global Search, Filter, Sort & Find In Page.

Global Search allows the user to find any object within the environment, and then navigate to it.  After entering a specific search string, the user should be provided with a list of matches, and optionally be able to perform a quick previews of any matches.  The user may then select one of the matches and be taken to its location in the application.  Essentially, global search is a navigation short cut of sorts.  Although this is an extremely helpful feature which increases usability, this functionality is often difficult to achieve from an architectural perspective.

With the onset of additional display types to tables such as tiles and lists, making Filter, Sort and Find in Page patterns consistent between display types is very important.  Below is a summary of requirements of each pattern.
Filtering allows a user to show a subset of the dataset which matches input filter criteria.  The first iteration will be limited to simple filter features.  The user should be able to select an attribute to filter by and then input associated filter criteria.  When multiple search criteria are entered, only items which fit all filter criteria will be displayed.

Regardless of which attributes are displayed on the screen, it’s most powerful to allow the user to filter by any of the attributes associated with an item.

Sorting allows a user to reorder the dataset based on a specific attribute order.  Similarly to filtering, the user should be able to sort a data set by any attribute, regardless if it’s currently displayed on the screen.
The first iteration is limited to simple sort features.  The user should be able to quickly select an attribute to sort by.  The default behavior should short the dataset by that attribute in ascending order.  There should be an easy mechanism to switch between ascending and descending order.  In this pattern, the user is limited to a single sort criteria.
Find In Page – Find in Page allows the user to locate a substring within a dataset.  This is traditionally called Find, but many interfaces use an unlabeled magnifying glass to do this.  This pattern is not used consistently in most applications: sometimes it behaves as a filter (only showing results with string matches) and other times highlighting the matches and allowing the user to jump between them.  Many browsers offer the ability to find (highlight & traverse between matches), allowing access to the pattern via <CTRL>F.

The first iteration is limited to a simple find in page feature.  This allows the user to input a string to be found in the “page”.  Once the user inputs a string the component would display the number of matches, and bring the first match in view.  The component would allow the user to loop back and forth between those matches.  Complications occur when paging or infinite scroll is used.  If paging is used, only the current page would be identified as the source.  Similarly with infinite scrolling, the source would be limited to items currently in the buffer.
Let us know what you think of our thoughts on proposed patterns for locating things in web enterprise applications by commenting here.  Keep an eye out for designs to be posted in the coming weeks.
– Serena
Design Pattern Team: Chris & Serena

8 Responses so far.

  1. lhorakov says:
    I really liked your article because I was witness in last time that people= any type of designer, are falling in custom with all search bar option and they do not think about it anymore. So thank you.

    My experience, watching the behavior of developers, that they definitely are in love with FindPage alias CTRL+F. And actually they are Global Search blinded. I explain it to myself that users are already tired of wrong Global Searchs which never finds what should be found (by way of exception).

    Filtering and Sorting? Of course! Must have in app/sw. On non-global website – no global search = no sorting/filtering.

  2. Really nice work!

    I have some questions and thoughts.

    You mentioned Ctrl-F. It was unclear if the plan is to have a Ctrl-F-like feature as some kind of a plugin? Or does Ctrl-F work consistently enough across platforms that it’ll work for PatternFly? (I haven’t tested, but I’d guess ‘no’!)

    It would be neat if there was a way to integrate both in-page and in-app searches with the browser / known key combinations. In other words, if I hit Ctrl-F, I get an app-specific in-page search widget displayed. (Sometimes you want hidden content searched, for example.) If I hit say Ctrl-Alt-F, I get an app-specific in-APP search widget displayed that knows how to do some kind of backend search.

    • serenamarie says:
      @Greg, thanks for reading and commenting. This blog is the first for this set of patterns. It’s really to get people thinking and collaborating with requirements as well as alternate solutions.

      At this point, the request would be that PatternFly would support a find in page pattern in a “toolbar pattern”, and we are hoping that we could use F as a shortcut equivalent to clicking the find in page pattern. Take a look at Google Chrome which simulates the same behavior.

      I like your suggestion about the ability to differentiate between in page and backend search! Keep an eye out for an additional blog coming out within 2 weeks with some of our initial design work on these patterns.

  3. Josephine Qian says:
    “If paging is used, only the current page would be identified as the source. Similarly with infinite scrolling, the source would be limited to items currently in the buffer.”

    Is it something we decided for this pattern specifically? Looks like we are doing something different in the Table pattern
    I am not sure which solution is more appropriate technically.

    • serenamarie says:
      @Josephine, in the table pattern, filter works with the entire dataset. I’m suggesting the same thing for both tile and list. The complication comes into play for all 3 patterns with the “search/find in page” feature. From what I understand there are technical issues which may limit the search/find feature from working across pages or working with the entire dataset when infinite scroll is used.
  4. Allie says:
    Is “filter as you type” a separate pattern or will that be part of the find in page pattern?
  5. […] first step towards performing a task or fixing a problem with an object is often finding it in the first place. For this reason, the data view toolbar places emphasis on patterns whose primary purpose is […]