Landing: day to day usage

[humitos]

Example of "How to use Read the Docs in your daily work" after reading the onboarding book on Book Club.

The idea of this page is to show exactly how customers will use Read the Docs on their day to day work to make them reach that "aha" moment when they realize this workflow is a lot easier than the one they are currently following.

Goals:

• explain how they will use Read the Docs daily
• mention docs as code workflow
• explain write, push, review and deploy stages
• show images representing those exact stages
• mention we don't provide an editor

Page based on https://about.readthedocs.com/docs-as-code/ structure.

ToDo

• Update the pull request screnshot to show a real pull request that matches the project changes
• Update the pull request preview screenshot to one that matches the documentation changes, show the banner and also the docdiff

---

📚 Documentation preview 📚: https://readthedocs-about--307.org.readthedocs.build/usage/

[ericholscher]

This feels like great content. Where do you think it fits into the content? As a "fifth" piece of content along with the 4 steps we have now in the top nav, and replacing the "How RTD works" page?

[humitos]

I wouldn't start replacing any content with this page. I think it's not a 1:1 replacement of anything we already have. Also, the page that I've created is not perfect and it will require more iterations for sure.

I'm currently thinking this page as a complement of "How Read the Docs works?", so we can link it from there with something like "How does it look my day to day with Read the Docs?" or similar.

However, clicking on "How Read the Docs works?" goes to /features/ URL, which makes a lot more sense considering the content of that page. Maybe, a following iteration mean re-structuring that "Product" dropdown and call this "How Rea the Docs works?" something like "All features".

By the way, that /features/ page is linked from the button "Explore all the features" in the "Sign up" modal. It seems we've change the title to make it more attractive some time ago, but the content is still "All features" more than "How it works?".

With that in mind, it may make sense to expose that page as "All features" and the new page as "Usage" to the dropdown. A suggestion to explore:

• About
  • Usage (/usage/)
  • Pricing
  • Enterprice plans
• Features
  • Authoring features (/docs-as-code/)
  • Reader features (/features/reader/)
  • Explore all features (/features/)
• More
  • Supported tools
  • MkDocs
  • Sphinx
  • Jupyter Book
  • Comparisons
  • GitHub Pages
  • Cloudflare Pages
  • GitBook

Keep in mind that in the current Product dropdown, "Building" and "Hosting" features point to the same /features/ page so I've removed them from it.

[ericholscher]

This sounds like a good plan to me. I do worry we're kind of repeating the same concepts, but I agree Workflow/Usage is a bit different than Features, and it's useful to have both. We've been combining them together in the past, which maybe is overloading things a bit much?

I thought @agjohnson had a revamp of the building or hosting page at one point, but I don't see a PR with it, so not sure.

[agjohnson]

The current page at /features was moved at some point, I forget why. It's not really a features page though, it's somewhere in between a feature overview and a workflow overview.

I do think we should have features listed by category -- build/hosting/etc -- but would like to see /features become more purely a feature overview. I think there is still a strong need for a "how does RTD work?" which is the title of the link in the header for /features. So, probably moving that content to /workflow and deciding if we are actually talking about a third page in this issue, or just expanding the /workflow page.

Breaking up the current /features page into building/hosting/etc pages is going to make the current /features page very minimal.

I started one of the sections in book club, but this is probably the wrong venue for a change like that.