gui design - What is the expected paging behavior of a tree?

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.

Answer

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:

Animals
    → 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.