It’s been a big week talking about features you can try right now, and a few that will be in your hands very soon. But today, we want to give you a small preview of something we’re testing right now, and will be shipping in the next few months.

In Sara’s post on Monday, she explained what we believe is the future of documentation and product experience — dynamic documentation websites that are tailored to each user’s needs. In other words, documentation doesn't have to be a “one size fits-all” solution.

Docs cannot remain static

The goal of any documentation is to provide fast access to knowledge. And as technology has evolved over the years, documentation has grown with it — from printed documents, to PDFs, to static HTML pages. And today, documentation is typically a website with interactive widgets such as search, user feedback, interactive elements, interactive API playgrounds, and more.

But no matter how many widgets you add, they can’t properly compliment each other if they’re not compiled together. When the sources of your knowledge are static, the combined output will be static too. It will cost time and energy to keep your knowledge up to date, tailor it to your visitors, and link it to your product.

Documentation can't be just a website anymore. Users expect to perform a quick search to find what they’re looking for, to ask questions and get in-depth answers based on their context, and to see a close integration of the documentation into the product.

Your docs also need to be portable. Their content should be surfaced by search engines, indexed by LLMs, and propagate to all kinds of targets and contexts. Your knowledge should go where your users are.

Computed content: composing sources into a unified content stream

At GitBook we’ve been working on building the future of documentation — and that work started years ago. GitBook began as a static website generator, but we quickly realized its long-term limitations and pivoted towards building it as a semantic knowledge repository, storing and processing knowledge in an optimized, internal format.

Until now, we’ve been focusing on the first and most obvious part of that — ingesting pages from GitHub or GitLab as markdown, or from our web-editor, and publishing those as beautiful, functional docs sites.

The next step is ‘Computed content’ — content that originates from different sources without being directly created and edited by the team.

Computed content will directly help us solve a few problems our customers have experienced when building their own documentation:

• Auto-generate full API documentation from an OpenAPI file for streamlined, accurate documentation.

• Enable multi-language documentation with SEO-ready translations.

• Document SDKs and code effectively for comprehensive developer support.

Until now, these cases could be tedious to solve with GitBook. To document an API, you needed to manually create pages and insert OpenAPI method blocks into each of them. To translate documentation you needed to translate content manually or use a suboptimal solution in the website to translate it to the visitor.

With computed content, GitBook won’t require you to create pages and documents manually — instead, it will be able to compute them from dynamic sources. Best of all, the knowledge it documents will still be optimized for search and LLMs — and of course it will still look great in your docs site.

Dynamic content: content adapted for each visitor

With computed content unlocking the possibility of docs providing a semantic stream of knowledge from multiple sources, we can pose another question about the end-user experience. Should all users get the same content and experience from that documentation?

Our answer? No — not when you can tailor that experience for individual users. For example, an app’s alpha testers should see pages about early-access features, while enterprise customers should get more guided steps for the advanced features of their enterprise solution.

A lot of our customers are already using visitor authentication as a way to gate their documentation and ensure only specific visitors can access the content. As we move toward dynamic content, we will expand visitor authentication to not only act as a gateway — but to actually provide enrichment data to GitBook from the authentication backend.

Combined with dynamic content, pages and blocks will be dynamically evaluated, and would be deemed conditional or changing based on this enriched data. Depending on their use-case, or other information from the documented product, each visitor would get the most optimized content experience for their needs.

What’s next

At GitBook, we’re exploring a number of creative solutions to make documentation an adaptive experience for each individual user. Over the next few months, we’ll release new features related to this — starting with auto-translation and dynamic content for visitor authentication.

We’re working on these features right now, and can’t wait to share more information with you soon.

→ Explore how GitBook can power your open source project

→ Read about the future of documentation

→ Get started with GitBook for free