I'm working on a financial app and we're getting mixed feedback from users as to how we've displayed the summary for groups in data tables. We've data tables which are, say for example, shopping lists of types of things so enter image description here

The summary rows are vegetables and fruits in the example table and are collapsible (with a twisty control) so the item rows are hidden when collapsed. Accounting conventions typically display totals (here for the Amount column) at the bottom but we're keen to reduce extra rows and columns so put the subtotals in the summary rows, coupled with the collapsible nature, this works well. So the question is 2 fold,
1. Can you provide a few examples where data tables summarises groups or categories upwards to allow collapsing
2. Is it clear that the subtotals are on the top? Obviously ignoring UI aspects.

1 Answer 1


Until I read your question, I hadn't even noticed the totals at the top. That alone indicated to me that the subtotals on the top are not clear.

Additionally, here are some reasons why your totals should be placed at the bottom:

  • Users read table data from top-to-bottom.
  • Totals are an equation. Relating to the previous point, the user will best interpret a total if they see the components first. A total before the data is like writing out all equations with the answer first, such as: 4 = 2 + 2. Although this is readable, we can process 2 + 2 = 4 easier.
  • "Vegetables" and "Fruit" act as summarizing labels when the data is expanded out, and thus, doubling their use as amount totals might confuse the user.

However, there are some scenarios when you might consider leaving the totals up top:

  • Lots of data. If you have hundreds of rows, being able to quickly identify the total before all the entries might be useful.
  • When collapsed. Because "Vegetables" and "Fruit" act as summarizing labels, it makes sense to place those totals where they are.

Here are some simple interface changes I came up with as a compromise:



  • The totals are placed at the bottom, and can be identified more easily. You could even place a "Totals" label on this row, possible under the Type header.
  • To make this interface even more clear, consider placing the Amount column on the far-right, that way users read the data as Quantity x Rate = Amount. The total would then be placed at the bottom-right of each type, increasing readability further.



  • Assuming the following interface is similar to yours when the rows are collapsed, this interface still allows for the user to see the totals on the type.

Hopefully the above suggestions help!

  • 2
    great answer Alan - thanks for taking the time to show both expanded and collapsed modes.
    – DaveAlger
    Jun 23, 2015 at 19:32
  • Thank you! P.S. - I came across your online resume earlier today, and was blown away. Nice job.
    – Alan
    Jun 23, 2015 at 19:33
  • Great and comprehensive answer. Thanks for your effort. Jun 25, 2015 at 9:59
  • Oh apologies, I'd written more out but somehow it got chopped off. We currently have your suggested solution in the existing app (that we're refactoring) but hoped to find more examples where groups are collapsible, and thus the total consistently sits in the group row rather than moving around depending on the group state. Jun 26, 2015 at 14:03
  • 1
    We have tens, possibly hundreds of rows so seeing a quick summary would be beneficial, and the arrangement wouldn't have the Name column, so the connection of Type and Amount would be more apparent. Also we'd considered the arrangement of Rate, Quantity and Amount but from feedback, our users are more likely to want to type in the amount - a rate and quantity are not always provided or required - as this arrangement allows quicker input and also aids the readability by bringing the Type/Name and Amounts closer. Jun 26, 2015 at 14:03

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.