Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 28 additions & 8 deletions GLOSSARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,15 +5,27 @@ Tools for DJs and the people who book them. This glossary covers the website at
## Site areas

**Public page**:
A page anyone can read without signing in. Viewers allowed to read more, like members or people granted a press kit, see more on it, but nobody sees controls for changing it there, apart from following, saving or saying they're going. Every profile, act, party, venue, event, set, mix, press kit, artist and track has one (an act's opens to everyone once staff list it), and each links to the others the link matrix lists for it.
A page anyone can read without signing in. Viewers allowed to read more, like members or people granted a press kit, see more on it. People who can change it see the controls for that there, in edit mode; everyone else only follows, saves or says they're going. Every profile, act, party, venue, event, set, mix, press kit, artist and track has one (an act's opens to everyone once staff list it), and each links to the others the link matrix lists for it.
_Avoid_: profile view, read-only page

**Edit mode**:
A public page laid out as visitors see it, with its fields in place of its text, for someone who can change it. Nothing changes until Save writes every change at once; Discard drops them. Creating something opens its page empty in edit mode, as a draft until it's published.
_Avoid_: edit view, editor, admin mode

**View as visitor**:
Seeing a page you can change exactly as a signed-out visitor sees it, with no controls.
_Avoid_: preview (on its own), public view

**Edit bar**:
The bar on a page that holds the controls for the thing on screen, for whoever can change it. Staff see their own section in it, and everything they do from there is logged.
_Avoid_: staff toolbar, toolbar, admin bar

**Link matrix**:
The list of which other public pages each kind of public page links to whenever the data for that link exists.
_Avoid_: sitemap, related links

**Dashboard**:
The signed-in area where every change to what public pages show happens. There's one per account. Its sections follow who the switcher says you're acting as, and its home starts with the onboarding checklist until that's done.
Your hub once signed in: the inbox, bookings, plans, settings, onboarding, and lists of what's yours. There's one per account, and editing a page happens on the page. Its sections follow who the switcher says you're acting as, and its home starts with the onboarding checklist until that's done.
_Avoid_: app, account area, my page, DJ dashboard, promoter dashboard

**Switcher**:
Expand All @@ -37,11 +49,11 @@ The four spaces staff can read from any client: audit, moderation, staff and ind
_Avoid_: staff spaces, root spaces (those include public ones)

**Staff console**:
The separate area where staff moderate and run the site. Only staff can see it. Staff can add or remove people from any act or party, and every action they take there is logged.
The separate area where staff moderate and run the site. Only staff can see it. Staff can add or remove people from any act or party, and every action they take there is logged. The edit bar acts on one thing on screen; the staff console does everything else.
_Avoid_: admin dashboard, admin panel

**Flag**:
A switch that turns a feature on for some people before everyone. Staff set who it's on for in the staff console. Flags are for rolling something out, not for keeping anyone out. Turning one off for everyone keeps who it was on for, ready for when it's back on.
A switch that turns a feature on for some people before everyone. Staff set who it's on for in the staff console. Flags are for rolling something out, not for keeping anyone out. Turning one off for everyone keeps who it was on for, ready for when it's back on. A flag can say which kinds of page it shows on, so staff can switch it from there.
_Avoid_: feature toggle, experiment, setting

**Flag group**:
Expand Down Expand Up @@ -100,7 +112,7 @@ _Avoid_: module, facet, field group

**Capability**:
One thing someone can do for a performer or a party, like editing its page, answering bookings, or checking guests in. Everything people can do for a performer or party is a capability.
_Avoid_: permission, right
_Avoid_: permission (that's staff), right

**Role**:
A named starting set of capabilities, like member, manager, host, cohost or door. A person's capabilities can be adjusted after a role is given.
Expand Down Expand Up @@ -191,12 +203,12 @@ A performer's private area, where the people working on it keep work in progress
_Avoid_: workspace, managers' space, team space

**Draft**:
One person's unpublished changes to a press kit, kept in backstage and visible to the others there. Publishing applies only what it changed onto the published press kit.
Something not yet published: a new page someone has started, or one person's changes to a press kit, kept in backstage and visible to the others there. Publishing a press kit's draft applies only what it changed.
_Avoid_: edit, revision, review request (those go to staff)

**Grant**:
Permission for one account to read one press kit's private part.
_Avoid_: access, approval
Letting one account read one press kit's private part.
_Avoid_: access, approval, permission (that's staff)

## Music

Expand Down Expand Up @@ -241,3 +253,11 @@ _Avoid_: index, catalogue
**Staff**:
The people who moderate and run the site. A moderator decides review requests, hides what shouldn't show and changes who's in a space. An admin can do all that, edit directly, and decide who's staff.
_Avoid_: mod, team, superuser

**Permission**:
Something extra an admin lets a moderator do, like changing who a flag is on for or managing flag groups. Admins hold every permission.
_Avoid_: grant (that's press kit access), capability (that's for performers and parties)

**Subject**:
The thing an action, audit entry or follow is about.
_Avoid_: target, object, entity
2 changes: 2 additions & 0 deletions docs/adr/0001-changes-happen-in-the-dashboard.md
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
# Changes happen in the dashboard, public pages only read

Superseded by [0017](0017-pages-are-edited-in-place.md).

Every change to what a public page shows (a project's listing, its shows, its press kits and their grants, booking threads, requests) happens under `/dashboard`. Staff work happens under `/admin`, which uses the same shell with its own navigation and role check. Public pages can show more to viewers who are allowed to read more, like a press kit's private part and the project's booking details for people with a grant. They never show controls for changing it, apart from a single "Manage" link for the project's managers and staff. There's one exception: following a project and saving it to your planner stay as inline toggles, because they only change the viewer's own data.

Before this, owner controls were scattered over the public pages and private pages sat at several top-level paths. We moved the private routes without redirects, since no notification or outside link pointed at them. Public URLs kept their paths, apart from press kits (see [0002](0002-shared-press-kits-in-root-owned-spaces.md)).
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ Before the locallibrary release: navigation and linking for the pages that exist
- Most of the work is new pages: acts, parties, venues, events, sets, tracks, areas, search and the follow lists. Each lands with its row of the link matrix and its test.
- `/projects/<slug>` is still the act page on main, so the matrix lists today's links under it until acts get their own pages.
- Charts moves under Mixes and Tools leaves the header for the footer, where it already is.
- RSVP buttons on a public event page fall under [0001](0001-changes-happen-in-the-dashboard.md)'s exception for controls that only change the viewer's own data, like Follow and Save.
- RSVP buttons on a public event page change only the viewer's own data, like Follow and Save, so they show to everyone; editing the event itself is [0017](0017-pages-are-edited-in-place.md)'s edit mode.
- The inbox grows from booking events to every decision someone has to make, so notification kinds stop being bookings-only.

## Amended
Expand Down
21 changes: 21 additions & 0 deletions docs/adr/0017-pages-are-edited-in-place.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
# Pages are edited in place

[0001](0001-changes-happen-in-the-dashboard.md) kept every change under `/dashboard` so that a public page would always be a true preview of what visitors see. In practice that split every page in two. Someone fixing a typo in their bio left the page they were reading to find the same words in a form that looked nothing like it, then went back to check the result. Starting an act or a party meant filling in a long form and only seeing the page at the end. Parties and events are where this hurts most, and the apps people already use for them (Partiful above all) build the page as you fill it in.

So every major page type is edited where it's read, by whoever has the capability to change it. A page has an **edit mode** in its own layout: each section's fields sit where its text was, the same size, so nothing moves when it opens. Changes stay on the page until one explicit Save writes them all, or Discard drops them. Saving shows a spinner and then a toast in the same fixed place on every page. Leaving with unsaved changes asks first, and a save that would overwrite someone else's newer change is stopped, as before. Creating something opens its real page empty, in edit mode, as a draft until it's published. **View as visitor** shows the page exactly as a signed-out visitor sees it, which keeps what 0001 wanted from a true preview without hiding the controls.

The controls for the thing on screen live in one **edit bar**, shared by owners and staff. Its staff section holds what only staff can do there, and every staff action from it is logged like anything else staff do. The edit bar acts on one subject, the thing on screen; the staff console does everything else.

The dashboard stays as each account's hub: the inbox, bookings, plans, settings, onboarding, and lists of what's yours or spans several things (people and invites, press kit access, venue rules and approvals). Its forms for a page's content go, and onboarding steps open the page in edit mode instead.

Pages move one type at a time: profile, act, party and event (built this way from the start), press kit (keeping its drafts and Publish from [0002](0002-shared-press-kits-in-root-owned-spaces.md)), venue, mix, show. Projects are skipped, since acts replace them and their edits are review requests.

## Considered options

- Keep editing in the dashboard (0001): the true preview it protected is what View as visitor gives, and the cost was every edit happening away from what it changes.
- Fields always editable for anyone who can edit, with no edit mode (as in Notion): owners would never see their page as others do without switching accounts, a stray click could change a public page, and every page would carry its editing code and its layout for every viewer who can edit.
- Saving each field as it changes: two people editing the same page would trip the stale-write check on almost every keystroke, a half-finished change would be public the moment it was typed, and a page without scripts couldn't save at all. One Save keeps a change whole and works as a plain form.

## Consequences

A page someone can edit isn't cached in their browser, so a save never seems to vanish on reload. Editing code loads only for people who can edit, so visitors' pages stay as light as before.
Loading