I have a table of items that can be filtered by many aspects, one of which, for example, is status. The filter is represented by a dropdown, where the default option is to not filter by any status.

Is it more correct to label this option "All Statuses", indicating that when selected, all of the possible statuses will be represented in the table, or "Any status", with a meaning more like "show me items with any status".


EDIT -- More Info:

The general context is workflow management. The user is a manager reviewing the items and perhaps assigning them to other users.

The other options in the dropdown are "Open", "Closed", "Assigned", and maybe a few industry specific options like "Referred" or "Under Investigation".

It's a webapp, and the various dropdowns are presented in a <fieldset> labeled "Filters". The status dropdown itself is labeled "Status:". A crude ASCII drawing:

+=== Filters =============...
|  Office: [Any Office|^]
|  Status: [Any Status|^]
  • 1
    Say you have 10 records, all implies you always return all 10. Any could return any of the 10: between 1-10. I'd definitely stick with all.
    – Ben Brocka
    Commented Aug 31, 2011 at 16:57
  • Say you offer cars in ten different colors. Any would return cars without taking care of the color at all. All would implicate that a car is colored motley.
    – danijar
    Commented Apr 7, 2013 at 22:07

7 Answers 7


Interesting reading the other answers that all seem to tend towards using "All". Many filtering interfaces I have seen tend to use Any. And I tend to agree with that. All in combination with a filter just seems strange.

With "any" you are expressing that you do not really care about this field. A record can have any value in that field and still be included in the filtered search result.

With "all" you would be saying a record can only be included in the filtered search results if that fields matches all the possible values for that field... Unless you are dealing with a field that allows multiple selections (a tag field for example), that is just not possible.


Jira (Atlassian's bug tracking system) uses All for projects (to search in all defined projects), while it uses Any for other fields. Projects are configurable of course, but so are versions and issue types. While the issue types would be limited in number, the versions of a project can grow quite significantly in number. Probably more so than the number of projects... (depending of course on the kind of software shop using Jira). All filter fields allow for multiple selection by shift-clicking.

enter image description here


DA01 made me think again about why there is an apparant inconsistency between the project field and the other filter criteria. I think it may have more to do with how "project" is perceived. I suspect that most users/developers do not perceive project as a an attribute (field) of an issue (though technically it of course is), whereas all the other fields are and are perceived to be attributes of issues.

  • Excellent point, Marjan. I think the key to the answer is the term used for the field label.
    – DA01
    Commented Aug 31, 2011 at 22:21
  • 1
    @DA01: Could be, but I think the reason may be how fields are perceived. See update to my answer. Commented Sep 1, 2011 at 6:13

It'd help to see a sample list of options. Between the two choices you've given, I'd lean towards 'all statuses' as that's specific, where 'any status' could be misconstrued. 'Any' isn't the same as 'all' and from your description, it sounds like you are referring to 'all'.

I'd also consider incorporating a label and maybe consider some other terms:

> All
> status 1
> status 2
> etc

That depends. Is your filter labeled as a filter, as a status, or as something else?

Filter: (options)


Status: (options)

have different "predicates". In the first I would name the "show me everything" option as "none" or "--", meaning no filter is in place. In the second, where we're talking about a status and not a filter, I would say "all"; people are used to "all" or "all of the above" from other contexts.

What do other applications (or tables) that your users will be using do?

EDIT based on edit to the question: as you describe it, I would recommend using no text at all; use a blank value or "--", both of which are well-understood in web apps as meaning "no value selected". Your interface already conveys that you're talking about filters.

(I would apply this reasoning to all of your optional filter parameters, not just this one.)


This is a very tricky one, because the terms mean different things, and different to different people. It may be that you need to try one or the other, and see what users think.

If it is clear from the context that this is filtering the data - that is, starting from the list of all entries, the filters will reduce this list. In that case, All would seem to reflect this best.

If the context is that you are adding selections, then Any would seem to be better, because it implies that status will not be included - All would suggest that the range will be extended to include every entry with a status.

So if you are restricting from a full list, All is better. If you are building up from nothing, Any semms to be better. IMO.

But try some and see.


I'm also leaning towards all, but I feel like this needs a verb like Show All Statuses to be completely clear.

If that doesn't work, then I'd definitely label the unfiltered list All Statuses. Any implies a choice from a given number, or a random selection.


If selecting the filter will guarantee that all of the different statuses will be seen on the screen at once, then use "all".

If there are a large number of entries, or many different statuses, then the first page might not contain an entry with every single status available. In that case, use "any".


Speculative thought:

Is "All" more appropriate for when there are few categories and the user has (or can have) a full understanding of them? While maybe "Any" is more appropriate for when the list is long and the user cannot hold them all in his head?

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.