User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this community
I'm designing a feature where users can simply toggle to get notifications for each type of updates. There's an option that makes it easier to toggle all.
My question is, if the user toggled all the options manually, should the select all toggle button get active automatically too?
Also would select all toggle-off the toggled options?
I am not a fan of the approach you have suggested. I find that having a global toggle can be confusing. The reason for this is exactly why you are unsure and asking this question - because there are strong arguments for it functioning in different ways.
I find the best approach is to just have explicit actions for selecting and unselecting all options. Something like this:
The main benefit here is that there is no confusion about what a global toggle will or won't do. The user clearly knowns what to expect by clicking on either of the links.
This also allows for the options to be further developed into a hierarchy type structure, if required. For example:
As you can imagine from this example, having a global "select all" toggle would really start to confuse the user.
Long Lists
A point was made in the comments that when you have a long list, the global toggle button can be useful to see at a glace if all options are selected without having to scroll the list.
If it is desirable for the user to understand this, then one option that would work with my current suggestion is to include a simple label that shows the number of items that have been selected. For example:
33/34 items selected
I think this information is not required for short lists, but perhaps any significantly long lists that would require (excessive) scrolling might benefit from include this extra information near the select all / unselect all buttons.
Select All and Unselect All based on their respective selection. But then again why do so when we can achieve the same with the available toggle component, which also can even keep the consistency for users' quick understanding.
[-] to indicate that there's a mix of choices nested inside.
Personally, I prefer to have it toggled on/off too, depending on the children state.
At least with the design above, it makes sense to also change the 'parent' state, because should the user want to toggle everything on/off, they don't have to manually toggle the children state (which n actions), they can just change the parent state (just 1 action).
I think it depends on the situation. Selecting all is not only useful for activating all elements, but also for once all have been activated, deselecting only those not required.
In the case described in the question with so few options it's somewhat confusing. But in cases of multiple options, SELECT ALL can be very useful.
The following example is the variation's list of a product from an online store. These can be hundreds. After selecting them all by clicking the top-left button, you can only deselect the ones that don't require any action.
My conclusion is unnecessary for few options, very necessary for multiple options.
TLDR: Don't store and reference the state of a "Select All" toggle
This feels more like a comment (though I have too low rep to post one) but in addition to the given answers one side consideration that could raise issues later is what a "Select All" toggle means when active on the backend, especially if consent is involved. Is that a purely UI display of the collective results of the individual toggles at the moment the page was opened or is that state being stored and referenced elsewhere?
For example, say you have options 1 through 3. Turning on options 1 and 2 require consent ("can we share your info with partners?"). A user clicking select all will ask for consent on all options that need it or a user clicking on individual options will each ask for consent on it. That's fine. However, say that the "Select All" toggle is changed to true and stored as active. Now a new option is added which also requires consent, which the user doesn't want. Because of a bug or disconnect in development, adding that new option didn't turn off the stored "Select All" state. Now before the user notices the new option, the "Select All" state is read on the backend as true, assumed the user has consented to the new option 4, and their info is shared. The user (and others) later discover this and in the current climate of increased user privacy you are now in legal hot water.
This sounds obvious and remedial but if missed could have major consequences.
