Throughout our application, we use “pickers” for selecting items.
For example, we use a picker for queues when dispatching a case:
a picker for contacts when creating a case:
and a picker for the installed part on a case:
For a small list of items (lets say < 100), such as a list of queues, we’ll just show the user all of the available items straight-away. The user can scroll to see them all, or start typing and the list will be filtered in place.
When there are a large number of items, such as a list of contacts when creating a case, which can be thousands, tens of thousands, or even millions, we make the user type to start the search process. There’s no way we could retrieve millions of contacts from the database and show them to the user in a drop-down list, and have that be a good experience for the user.
Being that our application has a wide range of usages, across a variety of verticals, we also get into the unknown list size scenario. For example, the number of contacts at a particular site. This gets used when picking contacts on a contract – i.e. which contacts at a given site are covered by this contract.
This all depends on how the application is used. For us here at Dovetail, we typically have no more than 20 or so contacts related to a site. But, we have some of our customers who have thousands of customers at a site.
So, how do we handle this scenario, and still have it work across a variety of use cases?
What we decided was to allow for a configurable threshold. We picked 50 as a starting point, but that’s a customer configurable setting.
If there are 50 or less contacts at a site, then we just show them all.
If there are more then 50, then the user has to start typing in some filter criteria to start seeing results.
Video link: https://www.youtube.com/watch?v=jhO74QMm0f0
We’ve discussed enhancing this even more, such as providing more guidance/explanation to the user about why the list may not be populated if there are a large number of items. Perhaps an enhancement for the future.
This hybrid approach takes a bit more work on our part from a development standpoint, but we think it offers a good balance of user experience and system performance.