Dynamic Developer Documentation
Sourcegraph is a go-to place for questions related to a codebase, like “where else is this function used?” or “are there any secrets committed to the codebase?” Documentation also provides answers about code, so creating a way to write documentation is a natural fit. I worked with a product manager and a full-stack engineer to define the Notebooks experience prior to its general availability launch, and afterwards to improve some usability issues.
Notebooks are made up of components called “blocks” which can contain Markdown, embedded Sourcegraph search queries, code files, and direct links to symbols. Because Sourcegraph indexes your whole codebase, notebooks can access any file in any code host. Notebooks dynamically update, so even if a file is moved, it will still appear in the notebook.
Key Questions
What personas will use Notebooks? When?
How are the needs of a notebook creator different from those of a notebook reader?
How do we build Notebooks in a way that supports developer flow?
Pre-General availability work
While there was a lot of traction around Notebooks, there were still lots of little things to add and polish before launch. I designed a getting started page to help onboard new users, new block types to increase the utility of Notebooks, and prototyped new ways to add blocks to notebooks.
Post-General availability work
After Notebooks launched, I worked on a number of design debt items. Chief among these items was redesigning the notebooks blocks to be more consistent with each other and with our design system; this came out of internal feedback. I explored a number of different design directions before moving forward with a minimal design that also improves the reading experience by having more consistent widths and outlines.