I've run into a brick wall while trying to come up with a suitable tabular user interface for showing hierarchical data in a table while at the same time including a search interface and pagination.

The basic structure of the table might look something like this:Simple Example of Data Table

The user has access to a pagination interface (lower right hand corner) to break up large data-sets as well as a search feature (at top) to search the records.

One of the problems I'm facing is how I should handle the displaying of child rows when it comes to pagination. Should I count the child rows ('case fans, thermal compoints, etc...') when displaying X amount of records per page? My instincts tell me not to count the children because if the user switches pages they will lose context of the parent record they are looking at. Additionally, if I keep the child rows hidden by default (unless the user clicks a "plus" icon next to a parent), it should keep the table more compact. However, by not counting the child records in the total, then the user doesn't know how many total records were returned int he query (i.e. the bottom of the table would say, "Showing 1 Record" when in fact there are 20 additional child records in the table)

Another problem I'm facing is how to display search results in the table if a child matches the search and the parent does not. Additionally, I want to know if I should include all children of a matching parent.

For example, if the user types in the word "case" in the search box, I could return the results like this:enter image description here

The user sees all matches for case within the context of the hierarchy. However, in the event that child records are hidden by default, it might look like "Computer Hardware" was a match to the search. Using this method I would have to show all child rows by default thus stretching the size of the table.

Another option might be to eliminate the hierarchy altogether. This solves both the pagination issue and the search results issue. However the downside of doing this is that the user loses all context of the parent/child relationship between records.

Finally, I'm curious if when running a search like "Computer Hardware" that returns a parent category if I should automatically include all children for the match. While technically the child records don't have a matching string in their title, they still are related to the match because they exist as children of the parent.

Any insight, ideas, or inspiration you might have on this subject would be most appreciated. Areas I've searched for inspiration include the jQuery datatable plugin and the Apple OS X Finder interface.

4 Answers 4


Personally, I think your main issue is to use a table, which complicates things and provides an affordance that collides with what you want to achieve. Think about this: I see your categories list, and see there are 10 per page. Great. Now, I expand your category... and now I see subcategories but some of the categories I was seeing disappeared! This is a HUGE issue.

Now, let's say you just display then as static (so no expand) and you have a category with 12 subcategories... what will you do? You're displaying 10 results per page, so, assuming the category shows as first in the page, you'll still have 2 orphan subcategories!

And while these issues are expected affordances because of the use of tables and you should really take care of this, if you want to still using a table for this, you should count only the categories, and then have an inner table expand for sub categories, regardless of size. See example below:

enter image description here

or simply forget about tables and create cards or lists, see a quick mockup below (I also used smaller sizes so you can see how it works for mobile):

Default Status with Navigation

enter image description here

Search Results

enter image description here

or have a mix of both approaches, like in Material Design Tables (scroll to inline menus and also check Tables within cards)

well, hope this helps!

  • thanks for the thorough response. I had to look up what an "affordance" was in this context but I think you're right. I was trying to express data in a format that isn't naturally compatible with a tabular layout with pagination. Out of curiosity, what did you use to create your quick mock-up? Did you build that in Photoshop or use some other program?
    – Dave L
    Commented Aug 17, 2015 at 21:26
  • yes, it's Photoshop. Sorry about the affordance part
    – Devin
    Commented Aug 17, 2015 at 22:29
  • To be clear, the problem is not with the table, the problem is with pagination specifically.
    – Solvitieg
    Commented Apr 17, 2019 at 23:35

I think an easier way to look at the problem is by thinking about the rows as "denormalized" by including the category as part of the name or another column for each "child row". And when the user searches for something then include both the name and the category in the search. So if the search string matches a category then it would match all items belonging to that category. This is only for argument sake; not to be implemented in a denormalized way. But create all your rules on how to count, how to match, etc pretending that it is a denormalized list.

Philosophical argument

In reality the actual set of information we are looking for are ALL the "child rows"; that is the meat of the information set. And due to our limited human capabilities to handle large sets of information we resort to classifying them into categories. We can even have multiple categories for each item, not only one. However categories are "additional" information that we know about each item; something else we know about them. We may choose to use this information during a search or not. But most of the times we want to include everything we know about each item during a search.

I run into this problem quite often; where the implementation, the tool or the technology clouds my judgement of what the actual problem we are trying to solve. My mind tool to solve these problems is to think as if there is no computer, no implementation, no database schema, etc; just the raw problem. I also try to think about a solution as if there was magic; what is the end result look like if I could get anything I wanted. Then I work backwards from that into a doable solution.

  • I like the "denormalized" approach. I think this method would work well for hierarchies with a single depth parent/child relationship structure. I believe that complex/deep trees (like a file system for example) might not reap the benefit. However, I think your philosophical argument is spot-on. I may need to draw this out on paper first and leave the computer out of the equation.
    – Dave L
    Commented Aug 12, 2015 at 18:57

You are right that a good option would be to eliminate the overall parent/child relationship from the results table. Users don't 'search' for a category, they browse it; meaning a user would select Computer Hardware from some sort of category listing and then browse its children for further refinement. Both Amazon and PCPartpicker handle their content in this way.

The problem with the tree-structure table mixed with search right now is that there are logically more than the 2 categories you're showing in the example. I might search 'case fan', but I might also search 'zalman.' It wouldn't make sense, as a user, to see a result of 'case fan' if I performed the more specific search. A potential solution to this would be to only display non-categories in your results (like a list of Zalman case fans). Then you can list your categories - and even some tree structure - separately, allowing the user to click them and refine the results.

The end result would now be that when I search for 'Zalman' I will see every item related to that phrase. I can then click the 'case fan' category and limit my results to exactly what I was looking for.

  • I believe I see what you mean. If I were displaying these results to the public (like in an online store) then you are totally right. A "flat" approach that lets users browse a category would better than a tree. For my particular use this interface is for web site administrators to help them manage database records that exist in a hierarchy. For sake of this example, I chose the word "categories" because it's easier for me to wrap my head around that concept in terms of "group-able" records.
    – Dave L
    Commented Aug 12, 2015 at 19:03

I dont think one big list is the way to go. Show all the parent categories as big tappable boxes. Let user drill down. It will be easier to find what they are looking for that way vs having to scroll through a big list.

For search, show all entries that match. In each entry you can show a clickable hierarchy of its parents.

  • interesting points. I scanned the web for a long time this morning looking for various examples and came across an example that handles things in the way you mention, treeview file explorer. Ultimately I think it depends on how many (nested) records exist in the data set and what the intended use of the table is.
    – Dave L
    Commented Aug 12, 2015 at 18:52

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.