What is the expected paging behavior of a tree?
up vote
10
down vote
favorite
2
|
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.
gui-design tree
|
||||||||
migrated from programmers.stackexchange.com Jul 12 '12 at 8:20This question came from our site for professional programmers interested in conceptual questions about software development. |
|||||||||
add a comment |
|
2 Answers
up vote
22
down vote
accepted
|
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
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
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 1Let'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:
"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:
then to:
then to:
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 2Let'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 Is it appropriate to use pagination? Why would I want to see the log records?
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:
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.
|
||||||||||||||||
add a comment |
|
up vote
2
down vote
|
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.
|
||
add a comment |
|
Your Answer
Sign up or log in
Sign up using Google
Sign up using Facebook
Sign up using Stack Exchange
Post as a guest
|