Hello again everybody 👋 We haven’t updated the blog in awhile because the transition from GitPrime to Pluralsight has sparked a surge of interest that briefly diverted the feature train. More interest = more demos and feature ideas, which makes for exciting times at GitClear HQ!

For the most part, the demo deluge went better than we would've forecast. Still, customers identified many opportunities to take our best-in-category data quality and direct it to the reports they need. "Simple, relevant and powerful" is the essence of what we wanted to capture in GitClear v3.

Here are some specific areas GitClear v3 will improve:

In the process of building this data, we've rearchitected the way line processing works. We are now maintaining long-term threads of code, so we can connect recently edited lines back through trivial events like moves and find-and-replace, to their creation. This affords much better signal in how features become bugs and vice versa.

Personally, my favorite part of the relaunch is that we will be adding features at the same time we reduce complexity of our menus by half. This half. For GitClear, Amplenote, and Bonanza, we aspire to strike a net neutral balance to navigation complexity when adding features.

linkRollout plan

We will be progressively rolling out the GitClear v3 experience this week. In phase one, from now through Wednesday, we’re going to roll out GitClear v3 to our SaaS customers. This will give us the opportunity to quickly respond to any imperfections that haven't been detected by our CI test suite.

From Wednesday through Friday, we'll release GitClear v3 to on-prem customers. Wednesday will allow ample time to confirm stability of the new features in a deployed environment.

If you’re a paying SaaS customer, you’re first in line for the upgrades. Let's take a look at what's new.

linkFeature walkthrough

Here is a visual walk through the changes we’ve made and why:

linkEasy switching between developers

Previously, switching between developers required a click through the "Developers" tab, then into the desired committer, then into the desired report. This was confusing and inefficient. Here's how you switch between developers now:

open_in_new

Filter from any report down to individual developer view of same report

Instead of having to travel through the "Developers" tab every time you want to switch between committers, how about we just make a list to click? This update saves something like 3-4 clicks per report when a user wants to jump between developer contexts.

linkFeatures bucketed into the way people think about them (code vs PRs vs issues)

Customers want an accurate metric that tunes out noise, but they also want it to align with the questions their customers or managers are going to ask. These questions tend to cluster around concepts that are conversation opportunities. New code. Pull requests. Jira activity. Slack. Story points. So we needed to do better at capturing these.

For starters, GitClear v3 unveils a new team-view of expert domains for a particular set of repos over a range of time:

open_in_new

While metrics like "tickets closed" or "pull requests closed" are in some sense "vanity metrics," they still make for natural conversation entry points. You'll see more guidance in this direction over the week to come.

link

linkLess navigation noise

This feature shows how symmetry can be leveraged to reduce mental burden & ease navigation. Here’s how our tabs expanded before:

open_in_new

Navigating with a committer selected in GitClear v2

There were two big problems. One was that it was really hard to keep track of how the outer menu related to the inner one. To some degree, the tabs seem to be parallel (e.g., "code" and "browse" are on both), so that's encouraging. But there are a couple top level tabs that don't follow the convention of providing a report. And many of the bottom tabs don't seem to exist on the top set of tabs. How does a brain internalize such an arrangement?

The second problem was that many of the committer tabs weren't in the upper bar because we didn't have team versions of those reports. It was "on the list" but never getting done. So we launched team versions of those pages as part of this update. Here's the new team-based "Issues" tab, for Facebook open source teams.

Here’s how the same page (Specific Developer -> Code) now looks:

open_in_new

Same information, one less row of tabs

We convey more information while using one row instead of two.

linkNew historical visualization of code provenance (new), operation, and domain

It’s nice that GitClear started by building a diff viewer. It forced us to constantly dedicate time to nurturing the integrity of Line Impact. But zooming out from the diff view has been a perilous process. Anomalies get noticed, and there are so many things to get wrong.

Now that we've invested in creating reliable data, we want it to serve our customers. To that end, we ditched our monochrome Line Impact viewer that was the default "Historical" graph previously. This graph doesn't spark conversation, and does little to advance understanding. We've reached a higher, more detailed caliber:

open_in_new

Per-repo view of what activity has been brewing in the past year

Here are some other new ways to understand what's happening in your code:

open_in_new

See how development is happening across dimensions

Clicking any of them zooms in, with more labels:

open_in_new

This ought to go a long way toward clarifying the demand curve for various code domains. It can help inform who to hire next. And then GitClear can help you onboard those folks better.

linkMore actionable

Keep an eye on your Highlights page. Depending on your role (CTO, Manager, Developer, etc) we'll start surfacing specific, actionable ideas that you can use to make your development lifecycle more predictable.

linkNot implemented

As alluded to above, we don't like adding features when we can't remove other features. Every tab has a mental overhead cost. It's important for us to stay net neutral in navigation complexity. That has resulted in the removal of a couple features that weren't widely celebrated: Standup Reports and Comparative Committer Summary. If you'd like a standup-like report of recent activity, check out the Commit Activity Browser. It will show the main issue that every developer has worked on in the past couple days. You can scroll through issues as you see fit. The comparative committer summary had a four-part graph that never received any specific attention and wasn't sufficiently actionable.

linkLet us know what you think

We've piled up 50k of Line Impact in the past month building out all this stuff 😅. As your Highlights dashboard will soon call out, making big changing so quickly requires follow up efforts in test coverage and exception triage. If you see any issues with the new reports, please don't hesitate to drop us a line at support@gitclear.com.