Based on my own experience from the user study, identifying the correct paths and relationships can be more challenging because of the small arrowheads that can be easily ignored.
Making the arrowheads a bit bigger should improve the readability of the graph.
Related problem
Currently, the visualizer allows the user to select transversal or longitudinal stripes to represent the multiple feature expression that a given edge can satisfy. The transversal stripes can look mixed up depending on the shape of the arc representing the link between the two nodes
Additional context
Suggested solution
It would be ideal to have the colour gradient following the shape of the arc
Alternative solutions
Eliminate the arc shape when there are multiple edges between the nodes. If we can straighten up the links we would not need to worry about the colour gradient orientation. But we should avoid the overlapping of edges between the same pair of nodes
Related problem
Currently, the visualizer adds multiple colours to an edge satisfying multiple feature expressions. We want to explore different ways to encode that. One option is presenting instances of the same edge with different colours or shapes.
Additional context Vehlow, Corinna, Fabian Beck, and Daniel Weiskopf. "Visualizing group structures in graphs: A survey." Computer Graphics Forum. Vol. 36. No. 6. 2017.
Suggested solution
Enable the user to alternate between the multicoloured-edges layout or the coloured-clones layout
into the side panel where we currently show the Overview.
This can make all the selectors visible even in the default view in a collapsible section. It can also save space for the future integration of the tabular view.
The caching of the satSolver results has been implemented but it seems that there are unnecessary calls to the function applying the condition rules. The function getColors (init.js), which is supposed to return the colors for a specific link, is triggering the satisfiability solving when calling applyCondRules.
Solution:
Make the getColors function return the colors without triggering the evaluation of the satisfiability of the presence conditions
This would enable the changes the user implements to be local for each graph and it would eliminate the need for global variables for visual changes (e.g., toggleStripes)
Related problem
It would be interesting to visualize the data- and control-flow involving a given node within a subgraph. By highlighting those paths we can ease the identification of those flows and provide contextual information since the non highlighted paths are still visible.
Suggested solution
The user should be able to trigger the highlighting of incoming or outgoing edges by selecting a in the visualization node
Related problem
Currently, the user can enter multiple feature expressions to comprehend the visualization-aware analysis results. They can assign a colour to be used on links with presence conditions that satisfy each feature expression. However, they don't have the option of making some of the feature expressions invisible in the visualization, which would make it easier to analyze the differences in the analysis results between different product-line configurations.
Suggested solution
Enable the user to turn on/off the visibility of the satisfiability of specific feature expressions.
Related problem
Currently, the graph visualization enables the customization of edges and nodes based on their types. It also enables the user to remove a selected node or edge. However, it is not possible to remove all the edges (or nodes) of a specific type.
Suggested solution
Give the option to the user to select types of nodes and edges that they wish to eliminate from the visualization. The top bar of the visualization frame list all the types of entities included in the visualization. The user could click on them to toggle the visualization of those and consequently apply the desired filter.
When removing a filter with the "remove filter" button, the filter remains selected. This is undesired and can cause a desync between the stylesheet and the list of filters if the user attempts to add a color to a removed filter.
Depending on the deflection, the condition of an edge may appear on the inside, which causes it to collide with the arc easily. It would be better for it to always be on the outside.
Currently, the default color is set for those cases but we might want to apply the colors of all feature expressions if a presence condition is 'true', since it will be present for all software products
Related problem
Currently, the visualizer adds multiple colours to an edge satisfying multiple feature expressions. We want to explore different ways to encode that. One option is assigning specific shapes to each feature expression. The edges satisfying that would be solid/dashed/dotted or a mix of those shapes
Additional context
Vehlow, Corinna, Fabian Beck, and Daniel Weiskopf. "Visualizing group structures in graphs: A survey." Computer Graphics Forum. Vol. 36. No. 6. 2017.
Suggested solution
Enable the user to alternate between the multicoloured-edges layout or the multi-shaped edges layout
Alternative solutions
Use of shape and colour to encode the edge groups