adding onto my post over at bsky: I'm curious, what is the best way to visualize / explore nested data structures you have seen?

PANE does something kind of similar to what you’re showing here, with nested boxes, but is more compact. In general, I’d recommend working towards compactness.

Number: value: "2"

has few advantages over

2

.

neat, I should add indexes as well. How do you decide at which point to lay-out a list horizontally? wrt the numbers: For my thing I do have a view which shows the numbers plain, but the view from the screenshot is intended to print the structure as raw as possible. It's an early buggy testing system where I'd wanna catch stuff like extraneous properties being added

I explored some time ago

https://akovantsev.github.io/corpus/spy paste e.g. https://vega.github.io/schema/vega-lite/v4.json there and play with click/cmd+click/alt+click on

[]{}""

(EDN looks prettier though) pro tip: then, save page as a single interactive file

https://people.csail.mit.edu/ebakke/research/reportlayout_infovis2013.pdf and whatever Dataset does

Thanks for the further examples! @Mariano Guerra more UI inspo, nice! @Misha A interesting I noticed for myself that I prefer information to mostly on grow vertically but seeing your spy, I'm wondering whether opinions differ more on that than I thought. @alltom I remember seeing this paper a while ago but it left my memory, thanks for bringing it back. It's kind of sad (but reflective of the state of programming), that even the authors only describe it as database UI when I don't know why we'd want to look at nested data anywhere in any other way. For Dataset I think I did not find what was meant

@Gregor it depends on what are you looking at and what are you looking for. Some things are best to be looked at top-down, for others side-by-side does the job. That's why in this spy it is on-demand, as well as collapsed or not. Also it is info-per-space management: top-down-only and sideways-only are 1D, both-on-demand - 2D, add folding and it is 2.5D

I think zoom is an under-utilized way of representing nesting. I also appreciate the three-list method that apple uses in its file structure navigation... The middle panel is what you most recently selected with its siblings, the left is its parent with its siblings, and the right is its children.

I vaguely remembering Glamorous Toolkit having UI in that direction (cc @Tudor Girba)?!

People seldom want to look at everything all at once, and it's not often feasible in other methods, either. For all but the smallest structures you are going to have to scroll or pan. Not sure it's a particularly big downside. The same downside is true of zoom, too.

{foo [1 2] bar [3 4]}}

🙂

If the structure is unfamiliar, but you know for a fact it is small, maybe? That doesn't feel like very often to me. And for a sufficient size of data structure, (and it seems like large and complicated is the reason to worry about it at all) seeing everything is impossible anyway. So maybe you want to complicate the UI when the structure calls for it, and show everything when you actually can? For that collapsible sub-components probably work better.

Yes, the basic flow in GT relies on miller columns. It’s not the most extensive interface, it’s the simplest we found to handle the flow for arbitrary problems. Other flows are certainly possible.

un/familiarity is in the eye of the observer

agreed. my point is that being able to see everything is more useful for navigation when you don't know where to find what you are looking for. If I'm looking for something and I know exactly where it is, my vibe is "show me the thing I'm interested in, as quick as possible, and nothing else." But then again, maybe I'm wrong about "and nothing else". You could navigate the "focus" through "everything", instead of a subset, and just have more distant information from the focus sort of "shrink" away. Like a fisheye lens, or a tree printed on the surface of a sphere that you spin... But I've never seen that implemented in a way I actually wanted to use... would love to see good examples of that.

If you know exactly where the thing you’re looking for is, why would you even need a visualizer of the nested structure? Just type in the path. Presumably the value of a nested-structure visualizer is either 1. to help you find the thing you’re looking for, if you don’t know exactly where it is, or 2. to help you survey the structure more broadly, in case you’re not looking for any one thing. In either case, peripheral / broad visibility is essential.

I spend a lot of time debugging the JSON output of Python scripts. I will almost always just put the name of the object into the debugger and then use the visual colapsing tree nesting features to find what I'm interested in, rather than typing the address of the thing I want to look at in the object. So I like to see "more than nothing" and "less than everything" I guess. Maybe that's idiosyncratic, I don't know.

No that’s certainly relatable. I’m probably jumping into a conversation halfway through and not attending to context. Anyway, the “hyperbolic tree” thing above is very much the fisheye lens thing you mentioned. Here’s a video:

Yeah, the hyperbolic thing falls into the category of things I don't have any desire to use. I can see too much that I can't use. I would rather the edges faded away into invisibility rather than look like tiny useless branches. That browse-off presentation is super cool! You should share that in #C5U3SEW6A But the analysis feels like it's missing some human factors. I look at my kid, who does rock climbing, and I see a guy who wants to do something because it is hard, but he can get better at it, and begin good at it has value for him that doesn't come from efficiency or effectiveness at gaining altitude. If you look at games, the design objective is to make the person feel like they are getting better at something that it has (usually non-utilitarian) value to be good at, and make sure you are scaling that growth properly. Why do we not use similar principles in UI design? We seem to be measuring only for the first interaction, and not even for whether the first interaction motivates the second, etc. Like, I like the idea of information smell, because it hints at a human ability that humans probably like being good at - and getting better at - using.

Reminds me of TheBrain. I used it for a while but ultimately abandoned it. Too much information (>> 7±2 things to think about) and too little control over final appearance (final layout matters, humans must have the last say, machines can't put the finishing touches on layout).

> I spend a lot of time debugging the JSON output of Python scripts. I will almost always just put the name of the object into the debugger and then use the visual colapsing tree nesting features to find what I’m interested in, rather than typing the address of the thing I want to look at in the object. So I like to see “more than nothing” and “less than everything” I guess. Maybe that’s idiosyncratic, I don’t know. @Jason Morris When you expand the structure of objects you are using a generic view that’s applicable to any object. Have you considered creating a custom view that shows the perspective you are looking for?

dis/interest is in the eye of the observer too. I am looking at it from the logging/debugging workflow pov: • initial scope is roughly defined by user: "log this struct" • but you don't know yet with what purpose you'll be looking at it later, which fields at what depth would you need to look at compare with what else • later, when you browse logs - first you see everything there is, because tool-rendering-logs has no way to predict what are you looking for now • next, by interaction (query, collapse/expand, zoom in/out etc) you tell it what to focus on. • views which can't show you everything there is all at once (miller-columns) are not suitable for such tasks: imagine you could only see 1 log line at a time, or 1 table column at a time, 10 db table rows at a time. Ofc there are counterproductive extremes: loading 1 000 000 rows on the screen as the very first render. But if tool can show me 100000 all at once if I ask it too is much better than "yeah, dude, no problem, here's paginated table 10 rows at a time".

I'm with you on the hyperbolic tree critique, for sure. But I genuinely can't imagine wanting to visually process 100,000 of anything at once. It sounds inherently undesirable, to me. But it would be very cool to be wrong about that.

pixels? ))

tenor_gif2783894867840200131.gif

Do you guys ever collaborate with or get feedback from designers?

Not on FoC projects, personally...

Screenshot 2024-11-14 at 22.10.09.png

Something related I run into recently. Haven't tried it and one downside of the graph is that it takes a lot of space. Also not really sure how it would ever be better than a tree if your data structure isn't a cyclic graph.. https://jsoncrack.com/

My current approach is Miller columns where each column is an indented outline or a table:

I like it. Elements with nested structure become outlines, lists of objects with no nesting become tables? Or how do you decide?

preview in left-tree-view looks custom maid. is it?

@Jason Morris Default is to decide by type: objects(records) are outlines, arrays are tables. @Misha A Not sure I understand the question.