Jump to content

Best practices for filter field usage in Eclipse Web

Guest Joshua DeLapp

Recommended Posts

Guest Joshua DeLapp

Beginning in Eclipse 2017.3.2, the ability to create visual searches was added under the Advanced Search area. Visual search adds some early case assessment (ECA) capability to Eclipse Web and the ADD platform. Any case field can be marked as a Filter field, allowing it to be used as the basis for a visual search.


There are some "best practice" limitations to this, however:


First and foremost, because Eclipse needs to aggregate the data in the fields used for filtering, marking a large number of fields can have an impact on performance, especially during data imports. Ipro recommends having no more than five filter fields for a given case; when properly selected, this should allow for an accurate ECA of documents while having minimal impact on import and case performance.Note that for cases with very large numbers of documents, the number of filter fields that could impact case performance could be less than five.


Second, when selecting fields to use for visual filters, keep in mind that the intent is to use these for ECA purposes; because of this, choose fields that will filter documents into larger groupings sharing a particular value in common, with a limited total number of possible values. File Type is a very common ECA field, as it will help categorize documents into groups but will have a finite number of possible values in the field. Some clients frequently use E-mail Domain as a filter field; be cautious when doing this, as too many unique domains in the document set can make the filter less useful.


As an example of this, think of popular shopping websites like Amazon.com: The site has numerous filters that can be applied, such as color, brand name, and price range; each of these will separate results into broad categories that can be easily compared, while still having a small enough number of unique values to be useful during ECA.


Finally, ensure that fields selected for filtering contain identifiable information. File Type, for example, is easily understandable; at a glance, a reviewer can tell what a value of ".DOCX" indicates. A field like MD5 Hash, on the other hand, will not be helpful during ECA, as to the reviewer it will just be a lengthy string of random letters and numbers. Moreover, fields like MD5 Hash will potentially contain a very large number of unique values, so even if the hash were identifiable, the overall volume of unique hashes would render the early review of the documents relatively useless.


Using the same example as above, imagine if Amazon.com allowed a search to be filtered by model number. Each manufacturer of a product may have a large number of differing models of the same product; moreover, those model numbers would mean little to the average shopper since they will typically be a relatively meaningless string of alphanumeric characters.


If you have any questions on further best practices for filter fields, feel free to contact Ipro; someone from our professional services team will be glad to assist in setting up fields that will make your ECA successful.

Edited by Joshua DeLapp
word change - Imaging > imagine
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...