What's the best way to display hierarchical tabular data (parent/child relationship) while allowing both pagination and search?

Question

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:

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:

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.

Answer 1

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:

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

Search Results

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.