Skip to content

Better repository pages: a re-think of how repository navigation works

Administrator requested to merge sg/better-repo-pages into main

Created by: slimsag

Demo + explanation video: https://youtu.be/sgqtPb8ubAw

an even more verbose explanation of what this is about, no need to read this

The problem

I have a lot of complaints about our repository pages as they stand today:

image

A repository page today is not the best way to navigate a repository on Sourcegraph

That's a really strange statement, but it's true:

An experienced Sourcegraph user will typically:

  1. Use a repo: filter directly, or navigate to the repo and then type in the search bar at the top of the page
  2. Use file:, type:symbol, etc. options to search within a repository to get to the file they're looking for (or, hopefully in the future, use the better fuzzy-file navigation option I can't ever remember the keyboard shortcut for.)

An inexperienced Sourcegraph user will:

  1. Go to a repository page via our search, Google's, or the browser extension
  2. Be faced with TONS of options competing for their attention visually: tens of buttons, a complete dump of files/directories in no apparent order, Git history, and maybe insights if they have those enabled.
  3. Question to themselves "how is this better than GitHub that I'm used to?" and leave, or hopefully realize the search bar at the top of the page is super useful.

The best way to navigate a repository on Sourcegraph is through search. But new users don't know this, and our repository page UX makes every effort to prevent them from learning this.

Repository pages are overpopulated

Here's how the repository page for Sourcegraph's repository looks today, it's crazy - there's just too much on the page:

image image

Past discussions and attempts to fix our repository pages have focused primarily around how we can organize and cram more content onto these pages - how we can make them customizable via widgets, or similar. I think that there's a better approach.

Why the repository view is so critical to growth and user traction

A user's first journey through Sourcegraph is likely going to land them on a repository page first. That's the most natural path of navigation - and how people are familiar with navigating code everywhere else (in their filesystem, on GitHub/GitLab, in their editor, etc.)

People end up on repository pages through the browser extension, Google, documentation links, and (sometimes) through typing the repository name into Sourcegraph search.

In my experience, people really familiar with Sourcegraph tend to avoid repository pages as they're not a good experience - search is.

If we want first-time Sourcegraph users to stick around, we need to do better at communicating why browsing code on Sourcegraph is so powerful - and make the repository page experience less of a "this is a different, bad flavor, of what I'm used to on GitHub"

Simplification

Simplicity is the name of the game. My ideas going into this were:

  • A dump of file names in whatever order this is, should not exist. The sidebar is the best way to navigate a tree of files in a repository - so one should either use that or use search.
  • Commits shouldn't be shown on this page. Shown on a different page, or via the branch dropdown menu.
  • "Code Intelligence" shouldn't have a dedicated button/page, instead it should go under repository "Settings" (currently only available to site admins - that's a problem in doing this)
  • Insights should not be on this page. There should absolutely be a way to view insights for a specific repository, but cramming it onto this page is not the way to go in my view. If we continue down this route, we should be asking:
    • Should we also cram Batch Changes onto this page? After all, someone will want to view the batch changes in the repo.
    • Should we also cram API docs onto this page?

I want this page to communicate the best way to navigate code on Sourcegraph. People are ending up here as their first experience with Sourcegraph, it needs to do that.

Implementation

Here's the new repository page:

image

Note that:

  • If you click the repository name (GitHub icon), it'll now bring you to the code host.
  • READMEs are now shown - I think that's important and the default expectation of 95% of users when viewing a repository.
  • At the top of the page, you get search inputs which communicate how you can search for files, symbols, commits and diffs. It being front-and-center makes it obvious that this (or the sidebar file tree) is the best way to navigate a repository. (these add the relevant repo: filter upon pressing enter.)
  • Code intelligence has been removed as an option; if you're an admin you'll see Settings with code intelligence linked below that. If you're not an admin, Code intelligence will appear.
    • FUTURE: Ideally, I think Settings should be a non-admin page with code intelligence settings under it.
  • Browse is a new button, it brings you to the directory view. Having a directory view is still important, and ultimately I would like for us to have this page reflect GitHub's directory view more closely. For now, though, it looks like this:
image

Extracting code insights into its own repository (or directory) page was too hard (given this was just a less-than-2-day hackathon project), so I didn't implement this. Instead, it will cram itself into the directory page as it did before this change (if the option is enabled). I believe that we should move this to a separate page though - or at least seriously reconsider how it works.

Feature flag

This was for a < 2 day hackathon. The code quality is good, I didn't do anything egregious, so I think we can merge it.

It's all behind a feature flag in user/org/global settings "betterRepoPages": true.

Once merged, I will turn this on for all Sourcegraph employees. If feedback is good after 1-4 weeks, I would turn it on by default.

If feedback on it is poor or there are a lot of changes needed to make everyone happy, I may choose to just axe it all.

Helps https://github.com/sourcegraph/sourcegraph/issues/15057 Helps https://github.com/sourcegraph/sourcegraph/issues/14459

Merge request reports

Loading