Dropdooms! How binding a limiteless reference desk can have an effect on your consumer interface efficiency

It’s a situation you never want to find yourself: customer support pulls you into a conversation with a great customer and he is not happy. The website is slow! You have to fix it!

They know websites can almost always be more responsive, but it’s not bad enough to warrant this frustration. You start asking questions. Where is it getting slow? The Add New Deal Screen? This is a simple page, nothing is going on.

You go through the testing process and pull it up:

• Your development environment. You will see a loading time of less than a second.
• The test environment in production. There is also a loading time of under a second.
• The customer account. The loading time is only 45 seconds.

How can that be? You are wondering whether the client’s database is overloaded. They check, but the rest of their account is responding.

That’s when you realize it – the Stage drop-down menu contains 25,000 items.

They became a dropdoom!

What is a dropdoom?

A drop down list that works with no loading issues.

A dropdoom is a normal DROPDOWN UI element that is populated from a user-generated list. If the drop-down menu contains more than (approximately) 300 items, the page rendering will be affected. And then it switches from a dropdown to a dropdoom.

Loading the same screen now takes 3 seconds.

Even on fast computers, dropdowns with more than a few hundred items slow the rendering of the pages.

With the example discussed above, the developers gave customers the ability to add custom deal stages. Assuming the list was short – how many stages can a deal have? Apparently 25,000! The clients were generating so much data that rendering the drop-down list became a performance bottleneck. Since only the customer could see their own data, the developer didn’t know the problem existed until the customer called to complain.

Other examples of real dropdooms are:

• Assign a task to an employee via a drop-down list with all employees. That worked well at first – until the company grew to 2,000 employees. A total of 6 dropdooms have increased the page rendering time by 20 seconds. Using the task system became a chore and eventually people stopped using it to the full.
• A multi-select drop-down list with all of the tags a user has created. For customers with just a dozen tags, the page loaded in less than a second. It became an issue when a client had 80,000 tags, increasing the load time to over 30 seconds.
• A poll with a drop down menu to choose your preferred European city. The dropdown showed a list of the largest 2,080 cities in Europe. This one element added 3 additional seconds to the load time of the survey.

What causes a dropdoom?

Most fields only have a handful of options. But some fields will always grow, slowly at first and then exponentially. If something goes wrong, it is not the user’s fault for hiring too many employees, creating too many tags, or doing a survey with too many cities.

You passed the user experience on to the users but kept control of the user interface. And sometimes customers accidentally abuse a feature – those 80,000 tags were the result of a developer who developed against the API.

What is the solution for a dropdoom?

Instead of a simple drop-down list, the safest default option is to do a type-ahead search. This requires that users have an idea of ​​what to type in for results to appear.

Other options are:

• The top 10 options plus a type-ahead option
• An interstitial / pop-up with all options in paginated results
• A mix of top options and an interstitial option

There is no magic solution and it can be easy to blame the user. Users will always do things that you didn’t expect and that might not make sense to you – but they’re not developers, it’s you. It is your job to develop safe tools to protect the user from accidental performance degradation. If you can think ahead and plan for possible outcomes, you can solve the problem before it even starts – and avoid a dreaded drop-down.