+1 on collapsing/expanding parts of the graphs, so it'll be easier to focus on subgraphs.
Anything that can help figure out how to map the graph component back to the application would be helpful. For example, I'm finding stream tags useful to correlate a specific oplet to the the functional call. On the longer term goal, I can see using a tree to visualize a chain of functional calls (nodes) on TStreams objects (edges). However, I'm trying to imagine how the tuple flow would integrate into this tree. In particular, how union would be displayed. I need to think more. On Thu, Mar 17, 2016 at 2:42 PM, Susan Cline <[email protected]> wrote: > I’ve been thinking about different visualizations for the topology graph > based on Dan’s comments below. > I’m wondering if a tree layout might be a bit better. > > Here is an example of a very basic d3 tree diagram: > > http://bl.ocks.org/d3noob/8324872 <http://bl.ocks.org/d3noob/8324872> > > Some of the things that we could add to this that would make the graph a > bit more readable are: > > the ability to collapse downstream child nodes/streams > the ability to collapse parent nodes (?) > the ability to show the path to the parent node > > In tree diagrams we could make the size of the nodes uniform, so not as > much visual focus would be on them. > We could remove labels for the nodes altogether, and just label the > streams. > > Thoughts on this? > > Susan > > > > On Wed, Mar 9, 2016 at 2:33 PM, Dan Debrunner <[email protected]> > wrote: > > > >> > >> Somewhat related to this is there should be a view that represents how a > >> developer coded their application, which is through the topology api, > where > >> (for the most part) oplets do not exist. I'm not sure what exactly this > >> would look like, but it's a move away from having oplets as the first > class > >> objects, to having streams and windows as the first class objects. Maybe > >> such a graph would look similar but the focus would not be on oplets, > e.g. > >> oplet names like OP_1 have no meaning to the application developer. > >> > >> We may in the future have the physical representation (oplets) be > heavily > >> transformed from the logical view (topology), so in that case having a > >> logical view is much more useful, e.g. imagine an extreme case where the > >> graph has been optimized down to a single oplet. > >> > >> See: https://github.com/quarks-edge/quarks/wiki/Quarks-Etiao-Runtime > >> > >> > >> Dan. > >> > >
