Hello – I'm looking for a decent way to display hierarchical information within a table that will also allow users the ability to sort records by clicking the top of each column of associated discrete data. When the user sorts, the records would be restacked thus removing the hierarchical view/UI. To go back to the default hierarchical view, the user would click the top of the 'Record' column. The use case here is to allow a user to evaluate the data in a few different ways then make a selection to perform an action such as 'View/Export Records' or 'View Details'

Ive attached a conceptual model of what we currently have for reference but I'm curious if there is a better way to display hierarchical info on a table that can be sorted and selected?

Thank you for the help.

enter image description here

3 Answers 3


Consider maintaining the hierarchical hints when the table is sorted by Discrete Data.

Records sorted by Discrete Data

The only hints of the existing hierarchy I have at this stage is the explicit placeholder names e.g. Level 1 Node - D. Thus your table loses information during sorting that the user may otherwise depend on which can lead to confusion.

The parent-child relationships between nodes seem to be denoted by the |_ icon. Thus, I would keep the indentation only to ensure that the user does not mistake all changes in indentation between rows for parent-child relationships.

  • I agree about giving visibility into the node hierarchy info after the user sorts by discrete data amounts. Not sure if the |_ is the best way or tabs as this is dependent upon the parents being one row up. It could maybe be some text inserted after the node name i.e. 'Level 1 Node - A (Child of Level 0 Node)' Commented Oct 11, 2016 at 18:09

I think one important thing is to show very clearly, which rows will have additional levels within them. This makes the UI more predictable, since the user will know what happens when they click a row.

One classic way to do this is to use an arrow that points to the right on the left of the row. When the row is clicked and it "opens" the arrow should point down.

You could also use numbers in parantheses on each row to show how many "items" each row includes. So if I expand one row and it shows me 3 additional rows, the name for the original row would be "Name of the row (3)"

Here is an example of what I mean:

enter image description here

Btw. I like that in your proto, when the user sorts the table based on the right side column, all the open rows close. Otherwise it might get very confusing.

  • The OP hasn't indicated that the rows support click to expand behaviour. If you look closely there are no 'open' rows that close in the example. Commented Oct 11, 2016 at 16:15
  • Yeah, I noticed that after I posted. I would definitely recommend including that behaviour though. What happens if one of the first rows has let's say 50 items within? The user has to scroll a lot to find any other content on the page if there is no possibility to click and close that row.
    – Satu
    Commented Oct 11, 2016 at 16:22
  • 1
    Thanks for the responses everybody! Collapsible nodes would seem valuable to the user with the example I provided however both the parent and children nodes have different discrete data numbers and are not aggregated at the parent level. So, 2 children that belong to the same parent node will have separate numbers of discrete data that do not aggregate up to the parent. The parent will also have it's own discrete data number as well. Expand / collapse could still be valid but it will be tricky showing the discrete data amounts per node when the parents are collapsed. Commented Oct 11, 2016 at 18:03
  • If the related data is all independent why is there a need for the parent/child in the first place? I get that in some areas of the data this relationship may exist but if there are no rollups of the children into the parent numbers then the hierarchy does not make any sense to maintain because I would expect an end user to believe that the parent is a sum of the children. So just display the Row Items and their data points and let the users sort as they will.
    – RCburn
    Commented Oct 12, 2016 at 14:01
  • A bit of additional context that highlights the potential need for a hierarchical view: The app we're building is a health IT population health tool and what the prototype above is modeling is a health system organization chart. So, even though the numbers are not aggregates it seems important to still show how each organization node fits in with the overall organization structure. The discrete data column numbers might indicate counts of high cost providers / patients that are attributed to each org node. Commented Oct 12, 2016 at 14:28

The way that I have always done and suggested to do this activity is to maintain the hierarchy. What sorting does in this case is to arrange the nodes of the hierarchy to reflect the sort.

enter image description here

This allows the primary grouping of data to be preserved while sorting the details that a user will leverage to make decisions.

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.