Summary
The GitHub Pages docs are currently positioned mostly as a syntax guide. That is useful, but it is the wrong front door for many potential users, especially less-technical playwrights who first need to understand what Downstage is, why they would want it, and how to get started in plain language.
Problem
Right now the Pages site mostly answers syntax questions for someone who is already bought in. It does a weaker job of answering the more basic questions a new playwright visitor is likely to have:
- What is Downstage, in practical terms?
- What problem does it solve for me?
- Why would I use this instead of a word processor, Fountain, or a plain text note?
- How do I install it and start using it without already being a CLI/LSP person?
For a potentially less-technical audience, the docs should not feel like a spec with a nice coat of paint. They should feel like an invitation and a guide.
Audience
Primary audience:
- Playwrights and theatre-makers who may not be especially technical
- People curious about plain text writing workflows, but not already sold on tooling jargon
Secondary audience:
- Technical users who still need a concise product overview before diving into syntax details
Goal
Make the Pages site more holistic and beginner-friendly by clearly covering:
- The
why: what problem Downstage solves and why plaintext is useful for playwriting
- The
what: what Downstage actually is, what outputs/tooling it provides, and where it fits in a writing workflow
- The
how: how to install it and use it in plain, layperson-friendly terms before dropping readers into syntax details
Proposed Direction
Treat syntax as one important section, not the entire story. The docs landing page should lead with product understanding and onboarding, then move into the language guide.
Potential content sections:
- A plain-English introduction to Downstage
- A "Why Downstage" section focused on writer problems it solves
- A beginner-oriented "How to get started" section with installation and first-use steps
- A simple workflow walkthrough: write a file, preview/render it, edit with tooling support
- A clearer explanation of what the CLI, renderer, LSP, and VS Code extension are, without assuming prior familiarity
- A syntax guide section that remains available for reference once the reader is oriented
Work
Notes
The current Pages metadata already describes the site as a "syntax guide," which is a good signal that the framing is too narrow. This issue is about improving the product story and onboarding, not just polishing wording.
A separate issue is probably unnecessary unless the redesign grows large enough to warrant splitting visual/layout work from content strategy.
Summary
The GitHub Pages docs are currently positioned mostly as a syntax guide. That is useful, but it is the wrong front door for many potential users, especially less-technical playwrights who first need to understand what Downstage is, why they would want it, and how to get started in plain language.
Problem
Right now the Pages site mostly answers syntax questions for someone who is already bought in. It does a weaker job of answering the more basic questions a new playwright visitor is likely to have:
For a potentially less-technical audience, the docs should not feel like a spec with a nice coat of paint. They should feel like an invitation and a guide.
Audience
Primary audience:
Secondary audience:
Goal
Make the Pages site more holistic and beginner-friendly by clearly covering:
why: what problem Downstage solves and why plaintext is useful for playwritingwhat: what Downstage actually is, what outputs/tooling it provides, and where it fits in a writing workflowhow: how to install it and use it in plain, layperson-friendly terms before dropping readers into syntax detailsProposed Direction
Treat syntax as one important section, not the entire story. The docs landing page should lead with product understanding and onboarding, then move into the language guide.
Potential content sections:
Work
Notes
The current Pages metadata already describes the site as a "syntax guide," which is a good signal that the framing is too narrow. This issue is about improving the product story and onboarding, not just polishing wording.
A separate issue is probably unnecessary unless the redesign grows large enough to warrant splitting visual/layout work from content strategy.