Building a filter bar — improving the user experience of filtering and searching in Unomaly
I’d like to take you behind the scenes of my team’s process, findings and considerations in building a better user experience for filtering through anomalies, in Unomaly.
But first, what is Unomaly?
Unomaly is an anomaly detection tool that with the help of machine learning digests all the logs across your infrastructure — learns what is normal — and surfaces anomalies: logs (events) that never happened before, have new parameters, or normal events that have stopped occurring, etc.
You can filter this data based on a different parameters, such as the system that emitted the log, its timestamp, what type of anomaly it is, the score Unomaly assigned to it, or whether it is tagged by the user as a known event.
Our goal was to improve the user experience of filtering, searching and navigating your data set in Unomaly, making it easier for users to find what they‘re looking for.
Starting point
In the previous version of Unomaly, UI components related to filtering were spread out across the page:
Systems are chosen in the sidebar, score on the slider, time range above the graph. The UI does not reflect the fact that all these relate to the same concept: filtering. Slicing through the dataset, and knowing what you’re looking at requires the user to look in many different places.
In addition to what is immediately visible above, we have the conditions modal:
During a set of user interviews we did to better understand people’s experience with our product, this modal was surfaced as a major pain point. As one can see, this modal requires a lot of clicking.
“if you have to click too much, its a pain” — notes from a user interview
Based on all of the above, we set out on building a new filtering experience, addressing the following issues:
- Group together UI components related to filtering
- Make filtering and options more accessible, easier to discover in UI
- Something that works for both first time users and power users
- Ability to use only your keyboard, or mouse in filtering.
Starting with a prototype
After doing the research, we pretty quickly started to envision some kind of filter bar where the user can type what they’re looking for with the help of autocompletion. What might have steered us in this direction was our daily use of GitLab for our internal development — which features a search bar to browse issues and merge requests.
To figure out if this could work for our use case, we felt building a small standalone prototype made sense. Where we can quickly test the concept and gather feedback.
After some iterations of prototyping and testing we felt confident in our plan:
- Create a new component, the filter bar, that houses all filtering functionality and has a query builder with autocomplete suggestions
- Move the score slider and time range selector components into the new filter bar component
The filter bar released in Unomaly 2.29
Here is a run down of the experience we ended up with, and what is now released with Unomaly 2.29.
Conclusions
1. Prototype early!
In the process of going from the drawing board to implementing an actually working prototype, you discover many small nuances to the problem: micro-interactions, edge cases, etc. Building a prototype helped us figure these out early on.
Prototyping allows you to make spur-of-the-moment decisions and quickly build something functional — and thanks to the low time investment, you can revise these decisions later on, as you gain a deeper understanding of the problem.
2. Talk to users!
Talking to real people using our product gave us confidence in our approach, that we would have lacked had we only looked to our own usage of the product.
