Skip to content

docs(pages): reframe Pages site for less-technical playwrights #54

@jscaltreto

Description

@jscaltreto

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

  • Rework the Pages information architecture so the landing experience is not syntax-first
  • Add product-level copy that explains what Downstage is and who it is for
  • Add writer-focused explanation of why someone would choose Downstage
  • Add beginner-friendly install and getting-started guidance in non-jargony language
  • Add a simple end-to-end usage walkthrough aimed at non-expert users
  • Review the current copy for jargon and rewrite where it assumes engineering background
  • Keep the syntax reference, but reposition it as reference material rather than the sole narrative
  • Make sure navigation, headings, and hero copy reflect the broader docs purpose

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions