Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use only one color for ramps #2216

Open
damithc opened this issue May 16, 2024 · 5 comments · May be fixed by logical-1985516/RepoSense#2
Open

Use only one color for ramps #2216

damithc opened this issue May 16, 2024 · 5 comments · May be fixed by logical-1985516/RepoSense#2

Comments

@damithc
Copy link
Collaborator

damithc commented May 16, 2024

Currently, we use multiple colors for ramps, and file groups.
image

To a viewer, this may to confusing. For example, the viewer might think the color of the ramp indicates the file types that were modified in that commit.

The color in the ramp is currently used to indicate the day the commit was done, so that it is easy to see which commits were done on a specific day, across repos. Personally, I don't think this feature adds much value.

So, one option is to use the same color for ramps so that it is clear the colors are used to indicate file type breakdown only.

What do others think?

@logical-1985516
Copy link
Contributor

logical-1985516 commented Jul 15, 2024

When I was using RepoSense as a CS2103T student, the color of the ramp did confuse me, and I did not know what they meant until I saw this post.

I did an experimental change to test out how using only one color for ramps would look like. It does remove the confusion, but it may be a bit difficult to see the commit ramps.

An alternative is to have each ramp color correspond to a day in the week. This would add some value, since we work in weeks rather than per 5 days. However, there should be documentation or indicators to show that the colors do indeed correspond to days in the week.

Edit: another alternative is to have the ramp color correspond to the main file type that is modified in the commit. If such a file type does not exist, use a reserved color for "mixed" file type. The definition of the main file type can be subjective, but a definition I have in mind is:

  • its LoC modified must be at least half of the total LoC of that commit, and
  • its LoC modified is at least twice the LoC of the second most modified file type (if there is no second modified file type, its LoC is 0 by default)

@damithc
Copy link
Collaborator Author

damithc commented Jul 15, 2024

I did an experimental change to test out how using only one color for ramps would look like. It does remove the confusion, but it may be a bit difficult to see the commit ramps.

@logical-1985516 Can you post some screenshots?

@logical-1985516
Copy link
Contributor

logical-1985516 commented Jul 16, 2024

This is how it looks when all the ramps have the orange color:
image
Trimmed:
image
This is how it looks like if 7 colors (close to rainbow order, due to red and yellow being inappropriate) are used for the ramps:
image
Trimmed:
image

The granularity introduced by the different colors may improve visibility in cases where there are many commits made over a short time period.
I have also edited my comment above to include another alternative, but it may be difficult to implement.

@damithc
Copy link
Collaborator Author

damithc commented Jul 16, 2024

Hmm... when there are many commits in a short span, perhaps it's enough for the reader to recognize 'there is a whole bunch of commits in that period'? i.e., there isn't much additional value in being able to identify each commit separately in such a case.

@damithc
Copy link
Collaborator Author

damithc commented Jul 16, 2024

Edit: another alternative is to have the ramp color correspond to the main file type that is modified in the commit. If such a file type does not exist, use a reserved color for "mixed" file type. The definition of the main file type can be subjective, but a definition I have in mind is:

  • its LoC modified must be at least half of the total LoC of that commit, and
  • its LoC modified is at least twice the LoC of the second most modified file type (if there is no second modified file type, its LoC is 0 by default)

Interesting idea, @logical-1985516
I'm not sure if the implementation effort is worth the effort though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

2 participants