I'm working with a tree data structure, which should be visualised (like in a file manager).

The server can calculate the whole tree and the client will display it.

The possible size of a tree can be too big for a client to handle it all at once, so I only request the child nodes for a "opened" node at once.

but there is the possibility to have so many child nodes, that all of them could kill the client. So I need some way of paging, but I don't know which paging behavior is the user-expected one.

It needs to minimize the cached data on the client and to allow the client to get to "far away nodes" (on page 134 of 200) fast.

  • 2
    If you're looking for user-expected behavior, you should be asking your users.
    – TMN
    Commented Jul 11, 2012 at 15:42
  • The client will need to remember the "expanded-collapsed" states of a large number of nodes, so I can't see how that could possibly be minimized.
    – rwong
    Commented Jul 12, 2012 at 4:47

2 Answers 2


You are actually asking how to ensure better interaction design while combining two elements which are not UX-friendly: tree structures and pagination.

1. Tree structures

Unfortunately, hierarchical trees are one of the most inappropriately used controls in the toolbox. They can be highly problematic for users; many people have difficulty thinking in terms of hierarchical data structures.

About Face 3, The Essentials of Interaction Design, Alan Cooper, Robert Reimann and David Cronin, ISBN 978-0-470-08411-3, p. 457.

Tree structures were popular in 1989 because there were no better alternatives. Today, practically every usage of a tree structure is a mess from UX point of view.

One of the most familiar examples, file system, is a mess; aside the fact that an ordinary user doesn't have to manage the files at all, the fact that files are presented as a tree makes things even worse.

Another example, bulletin boards (forums), is a mess too. Stack Exchange shows very well how things would be done correctly. See? No categories, and no tree structure, but rather tags and search.

Unless you have a very serious reason to use trees for data visualization (and you rarely do), switch to a visualization which can actually be used by ordinary people.

2. Pagination

I can understand paginating when you have 10, 50, 100, maybe even a few hundred items. But once you have thousands of items to paginate, who the heck is visiting page 964 of 3810?

The End of Pagination, Jeff Atwood, Coding Horror blog.

First, there are newer, better alternatives which replace pagination. Populating additional records on demand (called endless pagination by Jeff, but I would criticize the choice of the name, since it's not a pagination, and frequently not endless either) is one of the alternatives. Google Images is a famous example of such pattern.

Second, you tell about "page 134 of 200" in your question. Who would access page 134 of 200 (see Jeff's post)? Is it really the only way you found to your users to provide the visualization of your data?

Practical example 1

Let's say you create a web app which hosts photos; lots of photos. Those photos are categorized and presented in a form of a tree. For example a photo of a black cat sleeping on a sofa will be put into:

    → Domestic animals
        → Cats
            → Sleeping cats
                → Black cats

"Sleeping black cats" category also contain 1538 other photos.

Is it appropriate to use trees? Actually, it's the most terrible way of doing things. By creating a tree, you make it mostly impossible for your users to find, visualize and manipulate data at once.

Let's see. Given the tree below, I want to find all the photos of black cats. How would I proceed? First, I need to go to:

Animals → Domestic animals → Cats → Sleeping cats → Black cats

then to:

Animals → Domestic animals → Cats → Playing cats → Black cats

then to:

Animals → Domestic animals → Cats → Running cats → Black cats

then to tens of other categories. What if I want to see the photos of black domestic animals? Or any black animal? See how the web app is totally unusable in a simplest scenario?

But, well, let's say I was searching for black sleeping cats, so there is just one category I have to look into. I discover that inside, I see the first ten photos, and that I have 154 pages of photos. Do you think I will ever go to the page 114? Why? Will it be so useful? What's different about the page 114 compared to the first two or three pages?

Imagine now replacing tree structure with tags and powerful search, and pagination with the ability to populate additional records on demand. Looks better?

As you see, both tree structures and pagination are the worst ways to display the data, making the application worthless and unusable.

Practical example 2

Let's imagine another case. You are creating an app which shows a static HTTP server logs. For every file (→ tree structure), there is a bunch of entries with the date and time of the request, the request parameters, the size of the response, etc. A single file can have been requested thousands of hundreds of times (→ pagination).

Is it appropriate to use trees? Let's say I want to visualize the requests made to companyLogo300x150WhiteBg.png. I don't remember where it is. I don't care about the path. I don't want to display Developer tools in my browser just to see the path, neither do I want to spend a few minutes to search for the path on the HTTP server. I already know the name of the file, why isn't it this enough? Why this stupid app asks me to do stupid things (walk through a tree), instead of figuring out itself the location of the file (search)?

Is it appropriate to use pagination? Why would I want to see the log records?

  • To see if the file is requested over time and how. For example, I want to discover that the company logo file was requested hundreds of times per hour months ago, but is practically unused now, since the website moved to companyLogo300x150WithAlpha.png.

    In this case, raw paginated results are the poorest visualization way you can ever imagine. A chart showing the number of requests over time would be much better.

  • To see who accessed the file and when.

    In this case, again, raw paginated results is unpractical, and you have to come up with a better way to show the data with charts and filters.

As you see, again, both tree structures and pagination are the worst ways to display the data, making the application worthless and unusable.

Note apart: you say that:

but there is the possibility to have so many child nodes, that all of them could kill the client.

Displaying too many entities to the user is never a good idea. A human brain is capable of processing a limited amount of information at a time through visualization. If you show to a person a chart containing two thousand entries (let's say you have a large monitor, so each entry is 1 pixel large, making it possible to display them all at once), it's not very useful. By grouping ten consecutive entries into one with an average, a minimum and a maximum would be much prettier to look at.

When you are asking yourself if a person with an average device would be able to handle a large amount of data, rather think about the way you present this data.

  • I think everything you say is right. I'm making a new reporting UI for web analytics. In the old UI there was the possibility to create tables, treetables, crosstabs etc. and somehow the marketing guys who use this tool for their sites came to think this tree is an allrounder. They build freakishly large reports with big trees, many columns with it and somehow they like it.
    – K..
    Commented Jul 12, 2012 at 9:57
  • Also, I'm already using tagging, but it's an explorative UI and the tags are also hirarchical. They aren't physically existant, but virtual. One hirachy of the data could be browser/name/version another one could be site/date/campaign etc. I will probably include a fliter method into every node, to search for stuff.
    – K..
    Commented Jul 12, 2012 at 11:27
  • Perfect answer, 100% agree. If it is interesting then here terrainformatica.com/index.php/2013/01/… is one of ideas that I tried when designing first versions of the Evernote[.com] application.
    – c-smile
    Commented Jan 27, 2013 at 3:01
  • Great answer. I thought I'd mention that in Example 2 the path forms part of the global id of the file being searched for. So, if 'you aleady know the name of the file,' and ask 'why isn't it this enough?' - the answer is because the filename is not enough to uniquely identify the resource being searched for. Just saying.
    – JW.
    Commented Jul 7, 2013 at 21:28

Why don't you just collapse the root nodes that are not in use? If that doesn't reduce the scope enough, collapse all of the root nodes and all of the first-level child nodes except the ones that are in use.

You can dynamically load nodes as they are opened, and collapse the other nodes in the same rank.

  • Meh... came here because I "have to paginate" a treeview. I thought about it a bit, and considering any node might contain too much elements, it seems pretty obvious to me that the only viable solution, if one wants to "paginate" is to navigate through only one node at a time. It more or less ends-up in something similar to a hard drive explorer, which is definitely NOT a tree. Pagination + tree just seems to make no sense at all to me.
    – Balmipour
    Commented Oct 27, 2020 at 8:14

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.