Skip to content

Repository files navigation

Levo · Visual Cues

Internal collection of self-contained HTML pages that explain Levo logic and show Levo UI — open one in a browser and walk through it. Built for internal logic demos and design/show-and-tells.

Private working repo, public hosting. This repo is public only so it can be served via GitHub Pages. It's for internal consumption — don't commit secrets, credentials, or customer PII. Prod numbers in mockups should be non-sensitive aggregates only.

Two types

Type What it is Example
Explainer Interactive, logic-faithful port of real Levo code. The reader pokes at inputs and watches which rule fires. Built per the interactive-explainer-guide skill. explainers/builder/page-serving.html
Visualizer Static mockup / dashboard showing the shape of a UI or data — no live logic. visualizers/insights/dashboard-popup.html

Rule of thumb: if there's a real algorithm/decision the reader should understand by playing, it's an explainer. If you're showing what a screen or report looks like, it's a visualizer.

Browse

  • index.html — landing page (card grid grouped by type), the GitHub Pages site.
  • index.md — the same catalogue as tables, for browsing on GitHub.

Layout

.
├── index.html                  # landing page (GitHub Pages)
├── index.md                    # catalogue for GitHub browsing
├── explainers/                 # interactive, logic-faithful ports
│   └── <product-area>/
│       └── <section>-<topic>.html
└── visualizers/                # static mockups / dashboards
    └── <product-area>/
        └── <section>-<topic>.html

The type is the top-level folder; the product area is the second folder.

Naming convention

<type>/<product-area>/<section>-<topic>.html

The path reads as the taxonomy left-to-right:

  • <type> = explainers or visualizers.
  • <product-area> = top-level area of Levo (insights, builder, campaigns, …).
  • <section> = the surface within it (dashboard, page-serving, targeting, …).
  • <topic> = the specific thing, when needed (trigger-rules, conversion-logic, …).

All lowercase, kebab-case, no dates/spaces/underscores. ~2–4 words, name the subject not the format. Don't repeat the type or area in the filename (the folders already encode them). New areas are added organically when nothing existing fits.

explainers/builder/page-serving.html        → Explainer › Builder › Page serving
visualizers/insights/dashboard-popup.html    → Visualizer › Insights › Popup dashboard

Standard metadata header

Every page starts with a standardized metadata comment block right after <!DOCTYPE html>, so a maintainer can see at a glance what it is, who owns it, and what it mirrors:

Both keep the same field set/order (Title, Topic, Category, Module, Status, Version, Created/Updated, Owner, Audience, Source/Data, Notes). Bump Version + Updated when you change a page.

Other conventions

  • Self-contained: inline CSS/SVG/JS only. No external assets, no CDN, no frameworks — a page must work by double-clicking the file with no network.

Add a page

  1. Decide explainer vs visualizer, then drop the HTML at <type>/<product-area>/<section>-<topic>.html (create the area folder if needed).
  2. Add the standard metadata header for that type at the top of the file.
  3. Add it to both index.md and index.html, under the matching type section, tagged with its product area. (Copy an existing entry.)
  4. Commit.

See CLAUDE.md for the same rules as an enforced checklist, and the interactive-explainer-guide skill for how to build an explainer.

About

No description, website, or topics provided.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages