Feature request: clickable grahps on Stats page
nate-double-u opened this issue · 11 comments
feature request
Have the graphs on the Stats page open a filtered search when interacted with.
example
In the Distribution of projects by rating section of the Stats page it may be helpful that when clicked on, a section opens up a search of projects filtered by the category represented by that part of the graph.
Clicking 'sandbox' grade 'A', could open the following search: https://clomonitor.io/search?foundation=cncf&maturity=sandbox&rating=a&page=1
The other graphs on the page could have similar click through behaviour.
rationale
This may make it easier to find groups of projects that are having the same kinds of issues as well as making the graphs more transparent (showing exactly the projects that make up each category graphed).
#394 is great, thanks for that.
Before we close this, we may want to consider adding this functionality to some of the other types of graphs on the page (I just used the donuts as an example). Or discuss if this functionality is especially useful (it'll be interesting to see the analytics on how often the click through gets used now that the feature is implemented on the one type of graph).
No worries!
Sure, we were going to add some more, we can leave it open in the meantime 🙂
We thought that adding links to the last section of the stats page that displays the percentage of repositories passing each check could be specially useful (as well as enriching the filters on the search page), but there are some details that need to be addressed before as discussed in #391.
Your #391 (reply in thread) comment really helped me understand some of the details going on here, thanks!
Response to #391 (reply in thread) as I think it is more relevant to this issue than that topic.
checks are not really happening at the project level, but per repository.
That makes sense - The graphs in the second half of the stats page are repository-based, but all search results are projects.
We'd love to add some extra filters that would allow you to get the entities that pass some checks and/or fail others, export the results to csv, etc. The problem is that if the entity was the project, what would it mean to pass or fail a check, that all of the repositories in the project would pass it? any of them? none?
How does this work now?
(thanks so much for including .gitpod, it makes it easier to spin things up and take a look under the hood!)
If the project is a top-level architectural entity, I'd think repos would be their constituent parts. Some repos aren't critical. Is there a way for a project to flag that a repo is not to be considered for scoring? (I expect that Sandbox projects would have more of these kinds of workspace/experimental repos and that by the time a project gets to Graduated that most of these will be removed)
So at the Graduated level, I'd expect that any repo in the project would have all their repos considered when it comes to passing or failing a check.
We are concerned this may not be super intuitive, but it'd be good to know what do you think.
As long as search results are only projects, I agree linking out to a search result from these Repository graphs could be counterintuitive. However, I'd still be interested in knowing which projects are building up the data here. I'm not sure how best to do this -- If you have time, doing some paper-prototype mockups may help to see if it's clear or not.
An alternative approach would be to add a section where the main entity was a repository. The problem just mentioned would disappear immediately given that checks are done per repository. But in this case, we don't know if we'd be complicating the user experience in CLOMonitor
I don't think we should change the primary entity.
How does this work now?
At the moment all filters in the search page are based on project data. Even though all checks are done at the repository level, the project entity itself has a score and a rating, that's the result of merging all its repositories scores. All of this works based on some configurable weights per section and check.
If the project is a top-level architectural entity, I'd think repos would be their constituent parts. Some repos aren't critical. Is there a way for a project to flag that a repo is not to be considered for scoring? (I expect that Sandbox projects would have more of these kinds of workspace/experimental repos and that by the time a project gets to Graduated that most of these will be removed). So at the Graduated level, I'd expect that any repo in the project would have all their repos considered when it comes to passing or failing a check.
At the moment not all the projects' repositories are listed in CLOMonitor. We hand picked most of the pinned ones plus others that seemed relevant. We've been discussing what would be the best way to manage this data going forward, but it's still not clear (admin UI, some config files, etc). At the moment there isn't a way to not consider a repo that's been added to CLOMonitor for scoring, but we usually don't add those. One or more check sets are manually added to each repository, which define what checks we'll run on it.
As long as search results are only projects, I agree linking out to a search result from these Repository graphs could be counterintuitive. However, I'd still be interested in knowing which projects are building up the data here. I'm not sure how best to do this -- If you have time, doing some paper-prototype mockups may help to see if it's clear or not.
Yes, we'll need to experiment a bit with this 👍
I don't think we should change the primary entity.
It wouldn't be changing the primary entity actually, but adding a new page or tab where the main entity is the repository. The search page and stats would remain as they are (based on projects), it'd be something extra accessible from both of them. Maybe we'll have to experiment a bit with this idea too to see if it fits well and doesn't complicate things too much 😉
Thank you very much for taking the time to go through all of this and for the feedback, it really helps!
The graph pointed with the arrow in the screenshot below is now clickable as well. The date input controls in the search page have been improved to accommodate this feature and have more flexibility (before it was only possible to filter per year with a slider).
The graph on its left probably doesn't fit well with clicking, same as the "projects average score per category" one.
The only one remaining would be the bottom one that depends on finding a solution to the projects/repos discussion we were having here and in #391 🙂
Thanks @tegioz! Links on the heat graph work great.
The graph on its left probably doesn't fit well with clicking, same as the "projects average score per category" one.
I agree with you on this.
The only one remaining would be the bottom one that depends on finding a solution to the projects/repos discussion we were having here and in #391 🙂
Should we convert that conversation into a feature request issue? 🙂
Should we convert that conversation into a feature request issue? 🙂
Yes, I think so 🙂 Thanks!
I can't see a way to convert it, but i've opened an issue: #405
Checks in the last graph of the stats page are now linked to the search page 🙂
We'll deploy it in a few hours.
Cool, thanks!