Opening hours and prices do not explain everything a first-time arcade visitor needs. Finding an entrance inside a building or understanding an unusual visiting arrangement may require a short document. Notes provide that space. In August, their storage changed to support both reading the guidance and understanding how it had been edited.

Visitor guidance and document editing

For example, directions to an entrance and usage precautions are easier to scan as separate paragraphs and lists. A single stored string leaves the editor and reading screen to infer those structures independently. Their interpretations can diverge, or several instructions can collapse into one block.

Collaborative guidance also needs a way to inspect the previous text and its author. Overwriting the current value loses that context. Notes, official announcements and photos share an arcade page, but their authorship and stored material differ, so each retains its own storage and permission rules.

Document structure and revisions

Notes are transmitted as Tiptap JSON documents. Paragraphs, lists and emphasis are explicit elements, giving the editor and reading screen the same structure to interpret. Formatting does not need to be flattened into a string and reconstructed later.

flowchart TD
    accTitle: Separating note documents from the current selection
    accDescr: The arcade points to its current note revision. Each revision retains its document and author, with earlier documents linked through change history.
    A[Current arcade note ID] --> N[New document revision]
    N --> D[Document and author]
    P[Previous document revision] --> L[Before-and-after history]
    N --> L

Each saved version becomes a revision, and the arcade holds the ID of its current note. Earlier revisions remain available after a new save, supporting comparisons through change history. Wiki notes and operator announcements can share an editor without sharing the same authorship policy.

Validation and saving

A flexible document format still needs predictable input. The editor sends an arcade ID and document to the notes API. The server checks write access, root and child structure, text and attributes, while limiting document size and recursive traversal.

The menu separates editing by information type. Notes are edited as one part of an arcade document. Original English capture.

An unchanged document returns the existing revision. A changed one stores the author and document, updates the current reference and adds change history in one transaction. That prevents a new revision from existing without its corresponding current selection or history. The screen applies the returned document before refreshing arcade details.

sequenceDiagram
    accTitle: Saving unchanged and changed documents
    accDescr: After checking document structure and write permission, the server returns the existing record for unchanged content, or saves a new revision, pointer, and history together.
    participant E as Note editor
    participant S as Note API
    participant D as Storage
    E->>S: Arcade ID and document
    S->>S: Check structure and permission
    S->>D: Compare current document
    alt Unchanged content
        S-->>E: Existing revision
    else Changed content
        S->>D: Save document, pointer, and history together
        S-->>E: Saved document
    end

Using and maintaining revision history

Visitors can read structured guidance, and contributors edit the same representation. Earlier content and authors remain available when guidance changes; unchanged saves reuse a revision rather than adding duplicates.

flowchart LR
    accTitle: Editing and reading the same document
    accDescr: The editor and reader share the stored document structure, while history links to earlier revisions. Format changes require both views to agree on interpretation.
    D[Stored document structure] --> E[Edit note]
    D --> R[Read note]
    H[Change history] --> P[Inspect earlier revision]

The format brings maintenance costs. New formatting requires matching editor, validation and rendering support, and retained revisions require storage. File publication and note formatting remain separately managed, as do the permissions for other content on the same page.

Related articles and sources: Musecat’s development