4 ms·

Miller columns! I have fallen in love with this UI paradigm after using them for graph-based tools. Some thoughts: 1. Once you open multiple panes from the sam

Miller columns! I have fallen in love with this UI paradigm after using them for graph-based tools. Some thoughts: 1. Once you open multiple panes from the same column, and go out to 2+ levels deep, it quickly becomes unclear which panes followed from which. There is an underlying tree structure that you are hiding from the user. Explicitly surfacing this tree somehow could greatly increase the usability of the tool. At the moment, opening two reference panes from the same parent column immediately becomes difficult to manage. Some ideas: clicking on a reference pane should highlight the code pane that it is associated with, something similar for code panes might also be appropriate. Highlighting up- and down-stream dependencies would make it much clearer what panes I'm about to delete by deleting a given pane (the user can drag a pane to a different column in order to "disconnect" it and keep it around). 2. If I delete a pane from a column, its descendants stay open, making it even more confusing why I had them open in the first place. 3. The header breadcrumbs are brilliant. 4. You have two types of panes: reference panes and code panes. I'm not sure that's a good idea, since a reference pane is tightly tied to the code pane it came from. It may make more sense to show references in code pane itself, and then let me follow references from there into the next column. 5. I'm on a Mac with a trackpad, which makes horizontal scrolling very very easy. This is not true for all your users. It might make sense to add thin left/right buttons so that I can quickly move a column at a time. At the very least: if I open a new column, the window should scroll to make it visible if it is about to be cut off. Since users screens will most likely be able to handle at least two columns, this shouldn't be too jarring (as long as you use a smooth scroll! quick but clear, 100-200ms)

TeMPOraL 6y ago
> There is an underlying tree structure that you are hiding from the user. There shouldn't be, though. You're following a graph structure of cross-references, in both directions (though it's less obvious here how to open panes for back references). It's not a tree. > If I delete a pane from a column, its descendants stay open, making it even more confusing why I had them open in the first place. Again, not a tree. Deleting panes opened from the pane you're deleting would be a bad thing, because some panes may be just intermediaries you used to find the semantic units you were interested in. The GUI here is similar to Miller columns, but it's not actually Miller columns - it doesn't represent a tree.
- phailhaus 6y ago
  > You're following a graph structure of cross-references Yeah, that's tree-like. I've worked on a similar problem, giving users the tools they need to explore extremely large, dense connected graphs. When you go-to-definition, then show-references, then go to a usage from the first file, you don't go back. You continue forward to the next column, even though the fourth column is identical to the first. The columnar navigation guides you towards tree-like exploration, which is necessary because the actual web of relationships is impossible to effectively visualize all at once. Trees make it manageable. > some panes may be just intermediaries you used to find the semantic units you were interested in. That's true, which is why dragging panes is important. You can explore down a path, find the pane you're interested in, drag it over to the second column, then delete the cruft in one step. The problem with it now is that once you find the pane you like, you have to go back and manually delete every single node that you don't care about.
paulshen 6y ago
Good feedback. Thank you! This iteration explores my question that while navigation history is a tree, what do people want on the screen at the same time? Personally, I find myself usually wanting 2-3 units of information on the screen (most often, a caller and callee). That's why panes are draggable from one column to another. The navigation is semantic but the panes are unopinionated. Iteration 01 https://artifacts.bypaulshen.com/code-explorer/01/?snapshot=9feb3d1a-b41e-44e6-adff-9b522414dc0b https://artifacts.bypaulshen.com/code-explorer/01/?snapshot=... implements exactly what you suggest with showing connections. Closing a pane will recursively close children. Also references are tied to the pane (point 4) 5. yes! I'm going through iterations of exploration but will consider these important points when/if productionizing.
- phailhaus 6y ago
  Looking forward to seeing your future iterations! This is already some great work you have so far.

TeMPOraL 6y ago

> There is an underlying tree structure that you are hiding from the user. There shouldn't be, though. You're following a graph structure of cross-references, in both directions (though it's less obvious here how to open panes for back references). It's not a tree. > If I delete a pane from a column, its descendants stay open, making it even more confusing why I had them open in the first place. Again, not a tree. Deleting panes opened from the pane you're deleting would be a bad thing, because some panes may be just intermediaries you used to find the semantic units you were interested in. The GUI here is similar to Miller columns, but it's not actually Miller columns - it doesn't represent a tree.

phailhaus 6y ago
> You're following a graph structure of cross-references Yeah, that's tree-like. I've worked on a similar problem, giving users the tools they need to explore extremely large, dense connected graphs. When you go-to-definition, then show-references, then go to a usage from the first file, you don't go back. You continue forward to the next column, even though the fourth column is identical to the first. The columnar navigation guides you towards tree-like exploration, which is necessary because the actual web of relationships is impossible to effectively visualize all at once. Trees make it manageable. > some panes may be just intermediaries you used to find the semantic units you were interested in. That's true, which is why dragging panes is important. You can explore down a path, find the pane you're interested in, drag it over to the second column, then delete the cruft in one step. The problem with it now is that once you find the pane you like, you have to go back and manually delete every single node that you don't care about.

paulshen 6y ago

Good feedback. Thank you! This iteration explores my question that while navigation history is a tree, what do people want on the screen at the same time? Personally, I find myself usually wanting 2-3 units of information on the screen (most often, a caller and callee). That's why panes are draggable from one column to another. The navigation is semantic but the panes are unopinionated. Iteration 01 https://artifacts.bypaulshen.com/code-explorer/01/?snapshot=9feb3d1a-b41e-44e6-adff-9b522414dc0b https://artifacts.bypaulshen.com/code-explorer/01/?snapshot=... implements exactly what you suggest with showing connections. Closing a pane will recursively close children. Also references are tied to the pane (point 4) 5. yes! I'm going through iterations of exploration but will consider these important points when/if productionizing.

phailhaus 6y ago
Looking forward to seeing your future iterations! This is already some great work you have so far.