I have a ticketing system that deals with outages: think cable company/broadband type stuff. For example, the internet service may go down at Property XYZ. Maybe phone and video as well.

We have a ton of properties, roughly 1500. Some are residential (ie, your home), some commercial (ie, Jane Doe Bakery Shop), some hotels.

The manager I'm building this for wants it on a per-property basis.

So let's say cable tv goes down at property ABC. You create a ticket and property ABC will be one of the listed checkboxes. You submit the ticket and it goes into the system.

The above approach was OK when we were doing just residential, granted it was still alot of checkboxes but the manager seemed to like it.

Now, incoporating everything, the amount of checkboxes will just be insane. So what I did as a first step was have a dropdown:

When the page loads, it won't show any checkboxes. You select, for example, "Commercial" from the dropdown, it'll show all the checkboxes for commercial properties. If you select "Hotels", it'll show all the checkboxes for hotel properties.

Now, this approach is alright I guess, but what if you maybe have a ticket where Hotel XYZ and Commercial ABC is affected? They would be coming from different checkbox 'areas' so it really wouldn't work.

Also, I'm open to completely getting rid of checkboxes, but I'm not sure what's best.

Any input on the matter is appreciated.

  • Can users be expected to know the name of the properties they are sending tickets for without seeing them in a list? I.e. is typing with autocompletion an option? Commented Aug 28, 2015 at 12:58
  • Great question. Yes it is our network operations team, so they will surely know. Not a 'uhhh I think it's this one!' type scenario. I think that is an OK approach, but we've had outages that have affected 30+ properties before: unlikely, but it happens.
    – Nubtacular
    Commented Aug 28, 2015 at 13:00
  • Could upload and image/mokcup of the process and your ideas? My english is not the best to it's hard for me to get the whole picture appropiately. Commented Aug 28, 2015 at 13:29

3 Answers 3


Since you are dealing with expert users, I would consider a multiple-selection autocompleting input field:

Image of a multiple selection autocomplete field

An alternative that uses a bit more space, but much less than hundreds of checkboxes, in order to show the options would be a double list box. This is more user friendly in the sense that you do not have to be an expert in order to look through the list to find a name you recognize, but it is less user friendly in the sense that it takes longer for someone who knows the exact name to make a selection. Whether that tradeoff is worth it depends on your target user and just how many properties there are.

Image of a double list box

Finally, if users are familiar with the checkboxes and you want to keep them, you may be able to use your grouped checkboxes idea by duplicating the selected property names in a list which is always shown (similar to a double list box, really):


download bmml source – Wireframes created with Balsamiq Mockups


In addition to the autocomplete, you might also consider a map-based approach if outages tend to occur in a geographic area. For example, if you know that server X covers everything in zipcode 55555, you could show a map separated by zipcode and plot which locations fall within each zipcode.

If the affected number of properties was relatively large, the map could be used to auto-select large numbers of nearby properties. Individual properties could still be deselected if they were unaffected.


An interesting point is that these days, it is really trivial to scroll a 2000 items list.

In ancient times, say, 4 years ago, when dealing with exactly the issue you raise, I would create some sort of system - a search, nested list, alphabetical buttons or whatever. But today, it's totally trivial to scroll over a couple thousand items.

And note that it is plain easier for the user to do that - it's clearer, there is nothing to think about, and it's trivial technically.

{Additionally, almost all systems have a sort of "faster scroll", often an AZ scroll, built in to make it even faster - like the contacts on your phone.}

An important general point in UX is that we must keep up to date. Consider for example the general idea that web pages with lists (say, a used car site) should have a default number of items per page, and then a selector to allow more items per page.

Now, that's a fine idea. Today (2015) a reasonable default value (with ordinary everyday computers and connectivity) would be say 1000. So, then you would have a drop-down saying "1000 per page, 5000 per page, 20000 per page, show all" - something like that.)

However! A tremendous problem on the internet is people often have that function, and it's way out of date. The smallest count for on-a-results-page will be like "100" which is both (a) funny and (b) incredibly annoying.

Your question at hand, indeed, is not unlike the "results-on-a-page" example I mention. I can't see the slightest problem with a couple thousand items on a page. Anything else would just annoy me, since I'd have to "figure it out."

(Another point to consider, scrolling these days is usually on glass, which is very fast; if have any 90+ year old users who are using a "lap top" then they are using two fingers on the trackpad area to scroll, which is about as fast as glass.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.