Radial flame graph?

[douglasg14b]

Love this package, but the block view makes it somewhat difficult to get a handle on the visual side of space usage. The radial flame graphs of tools like baobab make it much more intuitive.

Though, tools like baobab tend to be missing the file management capabilities QDirStat has.

Any plans for something along these lines?

[shundhammer]

No. Whenever I tried to use Baobab's graph for real I found it to be pretty much unusable. I get ring segments without any kind of labels, so I have to move the mouse around to see the directory name and the size as tooltips (and at pretty random places, too). Adding insult to injury, it only displays the name of that directory on that level, never a complete path (!?!). It leaves me completely disoriented.

Clicking on such a ring segment does surprising things; it completely replaces the graph, so I have to wonder where I am. I have to use the tree at the left to figure out what it is that it wants to display.

IMHO that graph is completely worthless. It does not add any value whatsoever over the tree view.

Plus, it does not make good use of the screen space: The circular shape leaves everything outside the circle unused and grey, and it leaves vast borders around the graph to have room for the tooltips.

Why anybody would want such a graphical representation is completely beyond me. It may look nerdy at first, but when you start using it, the magic disappears in a heartbeat.

I can only recommend you to get to know QDirStat's treemap. Click around and experiment. Click on a directory in the tree view and watch the selection border. You will notice that the shading also gives visual cues about grouping in directories and subdirectories (thanks to the folks at the TU Eindhoven who came up with that in their SequoiaView and their great technical papers about that kind of shading).

After marking a directory, zoom in and out with the mouse wheel. Also, watch the different colors identifying file types (yet another thing that Baobab is completely missing; their colors are purely decorative).

Use the "up arrow" toolbar button to move a directory up. Use Ctrl-click for multi-selection and watch the yellow frames (showing your complete selection) and the red frame (the current item).

And finally, be aware that the treemap alone is not half as useful as the combination of treemap and tree view: Use the treemap to spot large blobs deep down below in a nested directory hierarchy. That is so much easier than drilling down directory by directory in the tree view.

The treemap is not for everything. It is good for spotting huge files. It is useful for getting a very rough overview about file types on your disk.

But that's when the other views start becoming useful: To really find out just how much space your photo collection, your videos or your MP3 consume, use the file types view. From there, you can select one file type and get a list of directories where they are hiding; use that list to navigate in the tree view and the treemap.

And thus the circle is closing.

The different views all have their usefulness. They all have slightly different applications. You need to experiment with them to find out what they can do for you.

[douglasg14b]

Note: This isn't an argument, but you're initial stance is a very biased/blind one, and I want to point that out. I don't expect to convince you of anything here.

---

You described UX issues that are a problem with one devs specific implementation of the radial flame graph.... but are not points against such a graph in general. Similarly you describe issues that are highlighting a misunderstanding of HOW to utilize a flame graph, or of the feature available to you, which are not points against a flame graph...

Flame graphs are efficient graph types, especially when viewing relative differences between events or items (such as performance profiling, I/O Time, memory usage, or disk space). They are regularly used for these tasks, for professional work, and are far from a novelty/nerdy item. It provides segregated discovery of distinct items that branch out from the root, and "zooming" (clicking on, or if on a timescale literally zooming) to a new root lets you expand the branches from there.

I'd also like to note that efficient use of screen space != filling up every blank space with information. That's poor screen space usage, but good screen space optimization. It's fallacious to assume that blank space is wasted space, that's not how humans view information, and has been a point in "UX Best Practice" for decades. After a few dozen "blocks" it rapidly devolves into an indistinguishable mess for most people. Spacing out and limiting up-front information to the most important items is a regular goal when designing user interfaces.

Displaying literally every item on the drive is wasteful, especially when they are not visually distinguished from each other, it's visual clutter, and obfuscates important information such as "where is this" and "what is this". It requires clicks and navigation to figure out, and is easily lost again among the rest of the mess, which isn't necessary on a flame graph.

---

In this case, a flame cleanly displays the most influential directories and their immediate trees. I actually use baobab alongside QDirStat so I can easily find large directories (and their tree) without having to dig through a classic directory tree view, and I have to dig through a lot of NAS's and filesystems on a regular basis.... There has be no wearing off of the novelty, it's functional.

For instance, looking into a steam folder:

Do a survey and ask randoms which they prefer, you might be surprised to find that the one with relieving whitespace, distinguished AND grouped color palettes, and a visible tree structure would be pretty well received...

How do you quickly find out that Everspace takes up the most room under common/ with each of these graph types? The block view is displaying files, the flame is displaying directories. There is a huge functional and use-case difference between the two.

vs

[shundhammer]

How do you quickly find out what the largest directory is? You use the bar graph in the tree view that you cut off from the QDirStat screenshot; you just look at the long ones and ignore the short ones. That's what that part is there for. You drill down the largest directories in the tree because the small ones are mostly irrelevant.

As I wrote in my first answer, it's the power of the combination of both views that makes them useful tools.

A flame graph is nothing but layered percent bars that are, in the case of Baobab, wrapped around in a circle. I fail to see the usefulness of very much the same visual representation when it's already there (in the form of the percent bars in the tree view).

Flame graphs might have some merits for some use cases, but disk space is clearly not among them. I am sure they can be useful for data moving along the time axis where you can drill down deeper when needed, i.e. stretch out the displayed time interval. But when displayed in a circular graph like in Baobab, that has serious limits; in particular when all of a sudden the full circle no longer displays the full disk, but only a subdirectory. That's when the circle analogy falls apart and becomes more confusing than helpful. So IMHO that is just not an adequate tool for the job.

As for poor implementation, to the defense of the Baobab authors it is only fair to say that it doesn't really work much better with that kind of visualization. Just cluttering the graph with directory names and sizes (and writing them along the circle segments?) would not really work, and it would very likely greatly distort the visuals of the graph. It would overload the user with information snippets. So the only realistic way of doing that is what they actually did: With tooltips.

As for not overloading the user with tidbits of redundant information, that's why the QDirStat treemap omits tiny files beyond a certain threshold; they don't contribute much to the big picture (quite literally). Their color would give more hints about the predominant file types, but that's about all.

And BTW your treemap also shows that being concerned with that directory on that level is maybe not so important at all; you might want to have a look at that large green blob. It might be something that you forgot to remove. And that is something that the treemap shows you at even the most casual glance. You spot the big blobs, you click on them, and you can see in the tree view and in the details window what they are, and as of QDirStat 1.5 or later even if they are system files and, if so, what software package they belong to.

[RuRo]

I agree with douglasg14b. I came here from filelight, which uses a similar radial graph visualization. I was interested in qdirstat since it promised the functionality to collect the data from a remote server for local visualization, but qdirstats "tiled boxes" visualization is practically unreadable to me. You seem to be assuming the people are mostly interested in singular large files, but I work on very large datasets of individually small files on a regular basis and they look terrible on this kind of visualization. The "text" file tree in qdirstat is basically the radial flame graph, but without the ability to overview the general data distribution and with a reduced ability to cleanly "drill down" into subdirectories.

I mean, I'm not gonna hold it against you, if you don't want to implement this feature, it's your project and you can do whatever you want with it. But I politely disagree with your opinion.