-
The two major redesign decision that our team decided to make for the design studio was to implement the size of the node and add information about the deletions and subtractions. We chose these tasks they emphasized differences between commits, whereas almost all previous visualization functions we implemented grouped by similarlity. For example, the size of the node addresses two of the low-level analytical tasks that were not answered in the previous visualization: find extermum and range. If someone wanted to access the node where crux of the code was implemented, the larger node size would help find this extreme point. We can also determine range because of the comparative differences. These are important as it helps make the visualization have different audiences. In many ways, the previous visualization was aimed at the project manager as it helped show the distirbution of work over the time. As the project manager, he likely knows things like which commits represent larger additions/subtractions to the repository and does not need to zoom in to a particular time to know when this occured. By adding these visualizations, we help someone less knowledgable, like a user of the product who is interested in its history, find relevant information that would seem implicit for members of the project.
-
I implemented this by making the node's size based on how big the commit was. I chose to make the scale logarithmic because there were commits that were extremely large (i.e. someone deleting nearly the entire repository). Then, I made a color scale based ratio of additions to subtractions. I did this, again, beacuse I wanted to make the visualization more readable for a product user, or an interested party, so that they could instanly identify that the large red circles were major deletions to the program and the large green circle were when there were major additions. I also, changed the pop-up data (implemented with tipsy), to reflect the specific number of additions and subtractions in that commit. This wasy, if the user was confused if red meant a lot of additions or a lot of subtractions, they could quickly hover on any node to find the correlation. Finally, I still preserve the branch and the user who made the commit, by the line by category function from part 2 and the emphasis on branch feature from part 2.