Poker planning notes:

• If user clicks on a node they see a pop up with list of tokens.
• Metadata already part of the json graph data for displaying the graph.
  • cons of this approach: loading metadata too early might have too much data if there are lots of nodes with lots of metadata
  • pros: optimizes for if user interacts with this feature a lot
  • can consider this more in a followup
• Click again removes the pop up.
• Too much metadata might need scrollable pop up
  • Maybe clicking a close button to close the pop up instead?
• To be considered done:
  • Demo with clicking and displaying
  • Front end tests to verify the content of the pop up

Proposed points: 2

Poker planning notes:

• When user navigate to next / previous graph, apply the mutation to the graph
• Is this applicable to jumping to steps?
  • This is a separate task (timeline view)
• Use case: navigate to next/previous in a filtered graph.
• Currently mutations is stored as a list
• Send mutation to client vs send graph to client?
  • right now the client does not do graph transformation
  • for MVP just send the mutated graph over
• For previous button how to recover previous state? e.g. metadata, deleting a node?
  • naive solution to always apply the mutations from the initial graph
  • optimization can be a separate task
• Steps:
  • client side add next/prev arrows
  • counter for current mutation step
  • server apply mutation to graph
  • send updated graph to client
• How to consider done:
  • Demo of clicking prev/next
  • Verify the client send the right next/prev request
  • Unit tests on the server side for applying the mutations

Proposed estimate: 4

Poker planning notes:

• Displaying a timeline for users to jump to different steps of the graph.
• Display the total number of steps
• Allow user input for jumping to a particular step with input validation
• Won't display mutation reason and highlighting for these kinds of jumps
  • Maybe only highlight the mutation from the prev step
• Can still use the naive way of applying all mutations/ starting from the original graph
• Should we always use one servelet?
  • Having a single servelet to handle all parameters is fine
  • Also currently only one servelet has the guava graph
• How to consider this done:
  • Demo with timeline and user input, see a mutated graph when click the timeline/input the mutation number
  • Tests for sending the correct request
  • Tests for applying the right mutations

Proposed estimate: 4

Terminology:

• filter: change the structure of the graph that is displayed
• highlight: change visual (zoom in, coloring, etc)
  Poker planning notes:
• Requires filtering in the backend that only shows the graph connecting to a node up to radius
• Requirements:
  • Filter by node, and when next/prev buttons are clicked we only see mutations that are relevant to this node (plus radius)
  • Displaying the reason for mutation should work in the same way (display reason on next, don't display on prev)
• Steps:
  • No change to UI
  • Store the index of relevant mutations
  • Check current graph if the node searched is in the current graph. If node isn't in graph send error.
  • Also find the most adjacent mutation that the node was added.
  • Store mapping of node mapped to the mutation indices that mutated the node
  • Apply all the mutations first up to the one corresponding to "next" button, then filter the graph down using node + radius (open to other possibilities)
• Should we include mutations for all the nodes that are displayed? Yes
• Add testing :)

Proposed estimate: 8

Poker planning notes

• Node names are long and hard to see in a large graph
• Even for smaller graphs, they are too long to fit in the node
• Options
  • Change node to rectangular
  • Cut off name of the node after certain number of characters with "..." indicating this is not the complete name, show name in the tooltip instead.
    • Pros
      • allows selecting the node name and copying it.
      • don't clutter the page
    • Cons
      • can't see the full name until clicking on it
    • Node name will be above the tokens in the tooltip (we should do this one)
    • Or right click vs left click or different kinds of clicks
      - Node can have two tooltips
      - (might not be phone friendly)
  • Not show the label at all - people should click on the nodes
    • Pros
      • improve the graph load time
    • Cons
      • no indication of what the node is at all before clicking
• Changing font color and background to make sure that overlaps won't be confusing
• Goal is to make things usable. Not yet making it polished (separate task)

Proposed estimate: 1

Poker planning notes:

• Allow users to search for a file name.
• If there are multiple nodes with the file name, highlight them (user can click on the node to see them and/or zoom in themselves)
• If there is only one node, zoom in on the node
• Cytoscape cannot search by custom field. Current approach to loop over nodes, and check if the token is in the token list.
• Cytoscape might have a filter function for search. But this might not be more efficient than the server search.
• Maybe consider doing this in the server instead?
  • allows for more optimizations. e.g. mapping from filename to node name
• Server returns the list of node names that have the file name in its token list.
• Client updates the graph to highlight these nodes
• To consider this done:
  • demo to show that the functionality works
  • unit tests to verify the search functionality

Proposed estimate: 4

Poker planning notes:

• Very similar to filtering by node name
• There might be multiple nodes per file name
• Would we use the same "radius" as the other one? Yes. If there are three nodes, all three nodes will become "root" for the search
• Should we filter by file + node at the same time?
  • As long as this does not make the implementation too difficult/ slow
• User enter both node and token in the search boxes. Two submit buttons? Or just one for both?
  • Use one for both. leave a search box empty if not to search for it
  • unsure how useful, but simplifies the UI
• Steps
• Function to get multiple "root" nodes from the filter
• Traverse the full graph to only get the nodes that are reachable from the roots up to a certain radius
• Whether this should be merged with integration with next/prev button?
  • Depending on state of Issue #30, might be able to integrate this with next/prev buttons
• How to filter based on token?
  • option 1: traverse graph and compare the token list of each node
  • option 2: implement a token-node map, Need to update the map as graph is mutated

Proposed estimate: 4

Poker planning notes:

• Modify the GraphNode class to have an additional attribute for how it changed and why it changed.
• Whether to send the mutation list to the client instead? And the client would change node style based on mutation list
  • This means we can technically do everything in the client? TBD
• Timeline view don't need to display reason or highlight. This applies only to prev/next buttons.
• On the client side, adjust the styling of the node based on the mutation
• How to know what changed when navigating to previous?
  • We would have the mutation from N to N+1.
  • Can have a function to negate the mutation for coloring and displaying the reason
• What are some reasons for mutation?
  • Tools may append some reason to the mutation (any string)
  • Additional information for user to debug the graph. E.g. adding new synthetic node.
• How to consider this done:
  • Demo to show highlighting and reason for mutation on next/prev
  • Unit test for GraphNode's additional attribute.

Proposed estimate: 4

Poker planning notes:

• Allow user to input a node name and only display the nodes (parents, children) that are connected to this node
• The display would respect the previous "depth" input for the user (generalize the "depth" name)
• Steps:
• client side user input + send to server
• server side function to search for a node
• server side function for traversing edges from a particular node and returning the result graph
• send back the graph to the client
• To consider this done:
  • unit tests for the server functions
  • demo for the functionality
  • frontend tests for the url parameters.

Proposed estimate: 1

Poker planning notes

• Front-end only zoom in feature based on a regex/prefix match
• Cytoscape should have some functionality for doing these kind of matches
  • if not, use javascript to filter all the node names based on prefix/regex and send all the matched names to cytoscape
• Zoom in and highlighting is the same as #12

Proposed estimate: 2

Poker planning notes:

• Goals of the task:
  • Adding an input field for the user to search the name of the node and have the graph zoom in on that node
  • use case: user can inspect one node and surrounding nodes.
  • The underlying graph wouldn't change, the zoom only affect what the users see.
  • will only zoom in on the node if it exists
  • if the node doesn't exist, display this to the user
• How to control the zoom?
  • cytoscape can specify a zoom
• Graph is stored in the server. Graph is passed via json to the client. Can do everything in the client
• How to zoom out?
  • A separate button? Empty the text box?
• Steps:
  • Text field to get input from the user
  • Investigate API for cytoscape to see whether it allows zooming (there's an example on their website http://www.wineandcheesemap.com/)
  • On the client display the zoomed in graph
• How to consider this done?
  • unit tests for the search functionality + return error if not exist
  • manually verify that the zoom functionality works

Proposed estimate: 2

Poker planning notes:

• Precompute node to mutations list or compute it when nodes are requested?
  • Estimate of how much data we need to precompute vs compute as requested
  • number of nodes, number of mutations
  • Another option: log user actions and send it to some real users to see how they interact with the tool
  • Another option: compute the mutations list asynchronously
• Optimize generating the graph when users press "prev"
  • revert mutation function
    • Reverting add token might remove more tokens => mutate the mutation list to be the "effective mutation"
    • duplicate the mutations list but with reverse mutations
  • cache the mutation number to a graph => space inefficient
• Cytoscape is slow to draw big graphs. (e.g. unfilter functionality)
  • Cytoscape has document on optimization for big graphs (edges and lables are expensive)
  • https://github.com/cytoscape/cytoscape.js/blob/master/documentation/md/performance.md#core/graph-manipulation/cy.batch
  • Don't display node names for large graphs (labels are expensive)
• If the user request the same graph, send another request to the backend and has to redraw
  • Do some checks in client-side and not send a request to the backend if the graph is the same.
  • Or just use Cytoscape's caching
• Always redrawing the graph?
  • Cytoscape has caching parameters.
• Jumping to a timeline before the current graph
  • dependent on optimizing the "prev" button.

Poker planning notes:

• Display a fixed depth or collapsing the node on click?
  • click is also used for metadata so using click might not be ideal
  • left click vs right click? cytoscape might not have a right click option
  • 2 buttons; up = reduce the layer, down = expand.
  • Decision: using drop down/user input for max depth from the root. Root = nodes with no in edges. Always show the roots.
• What if the first layer (children of roots) is already 5000 nodes?
  • one use case: filter on one root and display the depth up to N for this root. (not in scope for this task)
• Should the graph be mutated on the server side or client side?
  • Don't know how big the graph is, might be a lot of json data.
• When are the roots determined?
• roots stored in the server somewhere, created at initial graph creation, updated as mutations are applied
• Steps:
  • client side add user input.
  • server side generate a graph that has only nodes up to a certain depth
  • give the graph as json to the client
• How to consider this done?
  • server side unit tests for the roots.
  • server side unit tests for the max depth function for returning the graph
  • on the client side manually verify that the graph is only displayed up to a certain depth.
  • client side unit test that the client is sending the correct request to the server (request parameters)

Proposed estimate: 4

Poker planning notes:

• Requires Issue #32
• Similar to Issue #30
• Might already be done by Issue #32
• If not:
  • Use similar mechanism as #30 to get the mutations relevant to the graph that has been filtered.
  • When users click next/prev, only show the mutation that changes one of the nodes/edges in the filtered graph
• For multi-mutation, always show it as if it was a single mutation
  • Filter the list of multi-mutation to only contain the relevant ones though.
• There might be additional corner cases, complications due to all these combinations.

Proposed estimate: 6