The project's homepage is meant to give an overview of the quality of a project from 2 different perspectives:
- Overall perspective, focusing on the global quality of the entire project
- New Code perspective, focusing on the quality of what's currently under development
These use cases are represented by the two parts of the page, white for overall perspective, yellow for new code perspective. We feel this representation is too simplistic and doesn't reflect the value of those perspectives.
The Overall perspective takes most of the page and feels like the most important use-case here. It lacks an overall view of security hotspots and most critical issues. The global evolution of the project overtime is not easily discoverable.
The New Code perspective shows static values that may not be interesting or actionable ("0 bugs" for instance). The Quality Gate and failed conditions on top of the page are not easy to link to the new code part. It's difficult to understand the exact scope of this New Code period, and to customize it if needed. The activity stream which provide useful clues on the New Code activity is not precise enough and therefore not useful. We have no mention of Pull Request activity whereas it's critical in a workflow focused on New Code.
A third of this page is also occupied by generic project information that clutters the interface and make it less focused and efficient.
We believe each use-case deserves a whole dedicated space with enhanced capabilities to power-up user's effort towards good code quality.
Additionally, the homepage suffers from various usability problems:
Confusing information architecture
- Architecture is not easy to understand at a first glance. Bugs and Vulnerabilities are together, whereas Code Smells have a separated line.
- There are grey lines to separate Quality Gate from Bugs and Vulnerabilities, and from Bugs and Vulnerabilities from the rest, but we don’t immediately understand why.
- The Quality Gate badge can be easily missed, it’s not that big, and there is no white space around it, making it easy to miss.
- Domain names should be used: Security, Reliability, Maintainability
Lack of discoverability
- History of a domain is not easy to find (sparkline buttons displaying only on hover)
- The bubble chart icon is impossible to understand, and there’s no tooltip on it. There’s no way to know it will lead the user to a domain’s measures page.
- It’s not obvious that rating badges are clickable. As they give an information about ratings on hover, users can think it’s their only interactive use, just like the “?” Icons that can be found everywhere in SonarQube.
- Leak Period should be named “New Code” to be widely understood, even by new users that are not familiar with Sonar ecosystem and metaphors
- Core concepts of this page are not explained anywhere. What is Leak, Quality Gate, Maintainability, Security, Reliability, Code smell ?
- When there’s nothing to show for Coverage, we display a “-“ that can be mistaken for “no coverage” whereas it’s just “no data to show”
- Lack of labels on the top right corner. Is this the last analysis ? Is this the last analysis version of project version ?
- Labels are not precise enough in the sidebar: Activity of what ? What is a Key ?
- The background chart gives no extra info, is not clickable, and is not available on all metrics. There’s no explanation why.
Readability and Aesthetic integrity
- There’s no indication that the chart scale changes between overall and leak period. That’s highly misleading.
- The yellow color for the leak period is visually unappealing and lots of people are disturbed by it.
- The coverage donut chart lacks readability because of the contrast between red and green.
- The overall layout lacks contrast with mid-tone colors everywhere. Not easy to spot what’s the real highlight.
As a user landing on the project homepage I want to
- Immediately understand the main purpose of the two main perspectives
- Be able to choose one of these perspectives, and easily switch between them at any point of time
- When choosing the Overall perspective, I want to have:
- The ability to focus on a long-lived branch
- A complete exhaustive vision of the quality of the whole project. Numbers for each main metric should be present.
- Number of overall code smells
- Number of overall bugs
- Number of overall vulnerabilites
- Number of Security Hotspots to review - probably only if I have the relevant permission
- Reliability rating
- Security rating
- Maintainability rating
- Amount of debt
- % of overall coverage
- % of overall duplications
- Number of duplicated blocks
- Highlight of the most critical issues
- TBD / Which ones to highlight?
- Highlights of the Security reports
- TBD / What to highlight?
- Highlight of the most risky components of the code
- Ex1: components with the lowest coverage but the highest complexity
- Ex2: components with the highest amount of duplicated code and issues
- Summary of the evolution of my project overtime - with a special highlight of the various versions
- Evolution of number of issues and their distribution by type
- Evolution of Coverage and Duplications
- Global information: (<= should this really be part of only one of the 2 perspectives? Or just always available somewhere but maybe not on a first level of access?)
- Size of the project
- Distribution of lines by languages
- Quality Gates used
- Quality Profiles used
- Project Key
- Organization Key (for SonarCloud)
- When choosing the New Code perspective, I want to have:
- The ability to focus on a short-lived branch or PR
- A clear focus on the current releasability
- Quality Gate status
- Potentially failed conditions
- Metrics only if they're at risk (actionable numbers, no "0" issues)
- Number of new bugs + associated reliability rating
- Number of new vulnerabilites + associated security rating
- Number of new Hotspots
- Number of new code smells + associated maintainability rating
- Amount of debt on new code
- % of coverage on new code
- % of duplications on new code
- All the good things that have been done in this leak period (positive reinforcement):
- Number of existing issues (whatever their type) that have been fixed
- Amount of technical debt that has been payed back
- Existing uncovered code that is now covered
- Existing duplications that have been removed
- A detailed Project Activity Stream allowing me to understand why some changes happened in the quality of the new code (see https://jira.sonarsource.com/browse/MMF-137)
- A detailed Pull Request and Short-Lived Branches Activity Stream
- The ability to customize the Leak Period
- Easily find the general information about the project without having it permanently present on the page
- Easily find all definitions and methodology explanations
The user choice should stay sticky at least at project level. When choosing the New Code perspective I expect to find it back when I return the next day.
The Overall perspective will be the only one available after the first analysis. New Code perspective will be available as soon as a 2nd analysis is performed. As soon as it is available, it should be selected by default to make it discoverable.