Integrity of "expand all" when user can expand/collapse children independently

Question

Consider an application that displays a table (of arbitrary length) where the table is comprised of a header that includes an "expand-all/collapse-all" button, and each row in the table includes a local expand/collapse button. That is, the "expand-all/collapse-all" button is NOT expanding and collapsing the list itself, but rather it is expanding and collapsing the details of each row in the list.

Schematically, here is the list with all rows collapsed. The header row has an expand-all icon (+) and each row has an expand-row icon (+).

+ name   condition   type
+ fred       5         B
+ sally     23         C

If I click on the individual expand-row next to fred, the list would now show this. Note that (a) the expand-row icon on the row has toggled from a plus to a minus, indicating it is now for collapsing, and (b) details about fred appear immediately below the original row.

+ name   condition   type
- fred       5         B
    Before Data    After Data
    foobar1        foobar2
+ sally     23         C

Next, let's say I click the expand-all icon. Note that ALL icons have now switched from plus to minus (regardless of their prior state), indicating they would now collapse when next pressed, and that each row has details immediately below it.

- name   condition   type
- fred       5         B
    Before Data    After Data
    foobar1        foobar2
- sally     23         C
    Before Data    After Data
    chocolate      vanilla with strawberries

Now to my specific scenario and my question:

1. Start with all items collapsed; the header row and all rows have an expand (+) icon.
2. Press expand-all; all rows expand; the header row and all rows now have a collapse (-) icon.
3. Press the collapse icon on the "fred" row; its row icon changes to expand (+). What, if anything, happens to the icon on the header row?

Keep in mind that this list may have anywhere from dozens to hundreds of rows. Technically, the collapse-all icon appears because all rows are expanded; thus if even one row is collapsed then it is no longer the case that all rows are expanded, so should it still show collapse-all? What about if 5 rows are individually collapsed? Or what if (n - 1) rows are individually collapsed, leaving only a single expanded row?

I want the expand-all/collapse-all icon button/icon to do what the user reasonably expects within the limits of this design. My leaning is that what happens on individual rows should be of no interest to the expand-all/collapse-all button (with one exception). If the user has collapsed 5 rows, then collapse-all should still work, just having no work to do on those 5 rows because they are already collapsed. The one exception is that if and when the user manually collapses the very last row, after having collapsed all the others, then and only then should the collapse-all take notice and switch to expand-all.

So--within the limits of this visual layout--is that a reasonable user experience?

Answer 1

One of the best existing examples is that of Gmail. If you have a mail thread, then you might have noticed this small icon (In the image below). They have a single icon, which only shows expand all, until and unless all the threads are in the expanded state, In which case it changes to collapse all.

Answer 2

Illogical design

You have chosen to use a button on the header for the expand/collapse all.

Using a single button means it has to be a toggle button. As you have asserted, having a toggle (two-state) button to represent the state of all items makes little sense - there is a state where not all items will have the same state.

In addition to that, you also make it an action button, which now means that it suffers from the state/action ambiguity.

So it's quite impossible to fuse all these requirements onto a single button. In formal logic terms, have more than 2 states but you lump them into two state - hence the design is illogical.

User stories

With collapse/expand tree/table view, these are the common user stories:

As a user I'd like to:

• See the details of all items, not just the summaries, because I'm interested in the details as much as in the summaries.
• Hide the details of all items. This is because I've expanded myself quite a few items and now less items fit in the view and I find locating individual items based on the summaries hard (typical case with hierarchical folder views).
• Having seen a summary of interest, expand that item so I can (progressively) disclose the details.
• Hide the details of a specific item since it is little relevant or in my way.

Better design

These, respectively map to the following user actions:

• Expand all - It shouldn't be stateful.
• Collapse all - It shouldn't be stateful.
• Expand item - must be stateful.
• Collapse item - must be stateful.

Summary

• Do not provide a +/- button on the header. It is:
  • Unclear
  • Ambiguous
  • Illogical (in a mathematical sense)
• Do provide expand/collapse per item.
• Do provide these (pure, not toggle) buttons:
  • Expand all
  • Collapse all

Answer 3

If possible it is better to have two separate buttons

see the post: Expand/collapse all - Combined or separate button(s)?