F-Yeah!
After a week of playing around with a #design prototype, and concluding that nobody would be able to work with it unless they have proper understanding of graph theory I finally decided to revisit the idea of a list and throw everything away except that what worked.
And the new design also works when using paper design. The best part? The new design allows me to lean into skeuomorphic design while keeping it accessible. š„³š
@DevWouter Sounds interesting!
... what was it about? š
Displaying multiple(!) subgraphs of Directed acyclic graph (DAG) as a topological sorted list so that the all heads of a node are displayed in an pleasant way.
In more human speak: Showing all the tasks that can be started of a connected task in #todo2d (the app Iām building) without having to show all the intermediate tasks.
The skeuomorphic solution I have settled on is closely related to a Rolodex.
And yes, I understand that the above reply is a bit wordy and confusing. š
@DevWouter Sounds cute! :3
And no worries, I'm good with graphs. =)
Had my own little share of fun once when building a node distribution algorithm in order to evenly place nodes of an unbalanced tree in this thing that still needs some more love:
https://github.com/platform-system-interface/dtvis
So far, nothing overlaps, and that was quite easy.
The common case I need to prepare it for is when there are hundreds of, possibly more than a thousand nodes, and the depth is rather low, maybe 5 levels. š¬
Looking at the screenshot, it looks like this is always a single tree (each node have a single incoming edge), correct? As for evenly placing nodes I assume you mean visually and not topologically?
Since you mention low-depth my intrest would be at how large groups of nodes (100+) can be "clustered". I always dislike large clusters since I can't mentally organize them.
@DevWouter Yea it's "one" "tree", though a bit of a lie.
In reality, there are references all across, due to the nature of the domain (hardware description): power supplies and clocks among other things have their own "overlay" trees, in part dynamically configurable. I have yet to add that; it's not impossible, but also not too trivial.
Indeed, I meant the visual distribution. It can happen that some 20 or more nodes stem from the same parent. An open issue is collapsing to make it navigable.
Collapsing would reduce information specificity, which depending on where the information "lives" is something you either want or wish to avoid.
I think searching is a must have (which you get for free if the render is an SVG), but I think that having filters would also help a lot. You could use them to hide/show or even let it determine the color of the node/edges. Colors would give the user the ability to categorize (and can later help with the overlay trees).
I enjoyed our exchange as well. You gave me quite a few things to think about.
I hope you find the time š
Wouter Lindenhof
ģ§ģ§ į į±įįįØ Daniel é»ę³å® CyReVolt