Patterns

How the parts combine on the platform. A pattern is a decision made once, so a mentor's queue, an admin's review and a student's application all behave the same way.

On this page

The spaces frame

As spaces roll out, every signed-in page sits in the same frame: the tab file of spaces with search and attention beside it, and on the active sheet the space's sidebar and the page. Below 64rem the tabs become a bar at the foot of the screen and the sidebar a drawer.

Community

Builders, alumni and mentors across every cohort.

The page's one display title, then its content. Lists, cards and forms sit straight on the sheet.

Lucy in Community. The sidebar names the space and lists its places; the page holds one task.

A page

  • One display title

    Each screen has exactly one Mattone heading, its h1. Sections below it are Maven Pro h2s.

  • Say what it is for

    A sentence under the title says what the page is for, when that is not obvious from the title.

  • The task near the top

    The primary action comes before the long content it relates to, not after it.

  • Readable lines

    Prose stops at about 70 characters a line; lists and tables can use the width.

  • Space before rules

    Sections are separated by space first, a hairline second, a card third.

  • Nothing behind a hover

    Every action and every piece of information is reachable by keyboard and by touch.

Forms

Server-rendered forms that post, using the kit's fields. Ask only for what you need, mark what can be skipped, and when a submit is rejected say exactly what to fix without losing a word.

A few sentences is plenty. David sees this first.

How would you like to meet?

In a direct conversation.

At rest: labels above, hints under them, one primary action last.
Problem:

Two things to fix before this can go

Your note is kept. Fix the fields marked below and send it again.

A few sentences is plenty. David sees this first.

Write a sentence or two, so David knows what you need.

How would you like to meet?

In a direct conversation.

Choose how you would like to meet.

Rejected: a notice at the top says how many things to fix; each field says what.
  • Validate when the form is sent, not while someone types. The browser's own checks (required, type="email") run first.
  • Errors say how to fix the value: “Enter an email address, like wanjiku@example.com”, not “Invalid input”.
  • A rejected submit re-renders the form with every value kept and moves focus to the notice at the top.
  • Destructive actions get their own small form and a danger button, away from the main submit.

Feedback

Which notice, when. Say it once, where it applies, and say what to do next.

A form was rejected
A danger notice at the top of the form, an error under each field, and focus moved to the notice. Keep everything the person typed.
A change was saved
Show the new state. Add a success notice only when the change is not visible where the person is looking.
Something cannot be undone
A warning notice before the action, in words, and a second step to confirm it.
The page is limited
An info notice where the limit applies: “This channel is read-only after the cohort ends.”
An action failed in the background
Say what failed and keep the person's input; offer the same action again, never a blank page.
Warning:

Removing this request is permanent

David won't see it, and it can't be brought back.

Empty and waiting

An empty list says what belongs there and how it fills; it never just says “Nothing here”. Work in progress keeps its place: a button that is working says so, and the page around it does not jump.

Nobody has asked yet

When a builder asks you for time, their request waits here with their note and their work.

No messages match “ledger”

Try fewer words, or search every channel you can read.

Lists and filters

When views of a list are worth linking to, they are addresses: a PillNav of links that work without JavaScript. When a filter only narrows what is already on screen, it is a row of Pill toggles.

Views with their own address.
Show requests
  • Kevin Omondi · A review of a fare-splitting app
  • Brian Kiprop · Thirty minutes on SQL joins
Filters on this page. Try them.

Overlays

  • Overlays are for quick tasks that keep their context: search, attention, a short drawer. A task that matters gets its own page.
  • A modal takes focus on open, keeps it inside, closes on Escape and returns focus to the control that opened it.
  • Behind a modal, the page is inert and dimmed, so nothing can be reached by mistake.
  • Drawers slide from the edge they live on and are still under reduced motion.
  • No tooltips carrying information. If a word needs explaining, explain it on the page.

Without JavaScript

Every page renders on the server and every essential task works before, or without, any script. Islands of React add speed and comfort, not capability.

  • Forms are <form method="POST">, handled in the page's frontmatter.
  • Menus are native disclosures (<details>); the sidebar drawer opens through its own link.
  • Views live in the address, so back, forward, refresh and sharing a link all work.
  • A kit component in an .astro file with no client directive is HTML only: hydrate it only when it must respond to a press.