“Search” is a more complex feature than you actually think
This post is the 2nd part of a series in which we will dive deep into Forest admin interface’s feature to explain how to fully exploit them. Read the prologue 👇
On average, 20% of a knowledge worker’s day is spent looking for the information they need to get their work done. If you think about a typical work week, that means an entire day is dedicated to this task!
Search is a fundamental activity and a critical element to consider when building an admin. Especially, if your team is going to use every single day to grow your business.
As a matter of fact, the more data you have, the messier it gets! By the time your database is big enough to have problems that require a powerful search, your company will likely be equally large. It’s not a particularly burning problem for companies just starting up. But it will be a growing pain, for sure!
For companies that are building or maintaining a search feature, you already understand why it’s important to make search immediate, helpful, and robust for your team members. You also know by now, how hard and long it is to develop (not talking about the maintenance) a smooth and excellent search facility which helps your team find what they want quickly and easily.
There is a reason why our friends at Algolia, to name but a few, spent years developing a search engine and are still improving it!
This may sound easy but is extremely complex to do it correctly. Despite its apparent simplicity, a search is a complex admin interface feature in much the same way as CRUD (read our previous article to know more about the acronym which stands for Create, Read, Update and Delete).
Database indexation & retrieval
Indexing means collecting, parsing and storing data in a form to facilitate fast and accurate information retrieval. The process of the retrieval means sorting through the entire search database and narrowing the search down to a more specific set of items.
Main filters operators and extended queries
Let’s take a language like SQL (Structured Query Language) one of the most common and used. A search result is obtained, in another word presented (SELECT), by the selection of data from a certain domain (FROM) that match some conditions (WHERE).
Of course there are extensions which allow more specific, flexible and complex queries in the database. It’s actually almost limitless! The main problem is how to transcribe this queries’ power into a friendly UI user interface?!
- complex conditions (subqueries, joins, etc.)
It happens often that data from multiple relations are required in a query. For this, relations need to be linked. The identical attributes in both relations are linked to do so. - pattern matching and arithmetical operators non-relational functions (sort, group, aggregate)
For instance, customers can be sorted in ascending order according to their names and as a second sort parameter in descending order according to their company. Grouping methods can, however, be used to calculate statistical parameters such as the average of customers’ ages. - complex operators (not just AND - OR - NOT)
It is possible to have multiple conditions and combine them with boolean operators (AND, OR). For negating a condition the NOT operator is used. More complex operators like “was in previous week” or “is in X days” are particularly useful to quickly obtain information for a specific workflow.
Recurring search
On a daily basis, some operational tasks (ex. customer support) are the same. Queries are too. Therefore, to avoid creating them over and over, and make people losing their time, they must be saved as per default.
Performances
Users notice when a system they interact with is laggy. No one like to wait unnecessary seconds, or minutes, for a search to show results. Database structure should be well thought as the search engine. For instance, features like quick search (direct search on columns labels) or most searched fields can help your Business team be more productive.
Access control
Should users only see a restricted subset of data? or can they access all of it? What are the rules of access restriction? etc. Team-based permission feature is a must-have for all company. It’s also complex to design, develop and maintain.
Export
When needed, filtered lists have to be easily and quickly exported from the database (eg. as .csv files) to be used in tools like Excel.
Managing the data to export (which column is/is not exported), and its volume (how many information could be added to the file without crashing the database) is not as easy as it sounds.
In conclusion, a search is not just about building tools that do ranking or retrieval for a specific set of data. Search systems are usually an evolving pipeline of components that are tuned and evolve over time and that build up to a cohesive experience. There is a reason why we are almost every week improving Forest search.
As in most engineering problems, don’t reinvent the wheel yourself.
If Forest fits your constraints … use it. Don’t hesitate to give it a try 😉
Thanks for reading! Don’t hesitate to leave a comment below if you like this article or if you want more details on our solution ✌️
The next article of this series will explain more in details how to full benefits from our main feature, the Layout Editor. Follow us on our Medium channel and get notified when it will be posted.
Visit our website or request a demo for a live presentation 🌲
