Conventions prototypes
Table of Contents
1. Summary
The market terms an instrument is built on, and the reference data lists each convention picks from.
Six prototypes answer to this group. The first draws how a person starts from an instrument. The second draws the plain entity screens of the conventions. The other four draw how a person manages conventions, as workflows layered on those screens: finding a document by its terms, naming a set, retiring a document and deciding a change. Each one is a static page under
doc/prototypes/, opens with no build and no session, and reads mock data
only. The table below opens each one and says what it argues. Where a
prototype carries a Gemini review, the last column opens it: a review is a
generated alternative kept beside the agreed design, never instead of it.
Prototypes is the top page and the only inventory.
2. The prototypes
| Prototype | What it argues | Open it | Review |
|---|---|---|---|
| Instrument conventions | A person starts from the instrument they want to trade, not from the entity name: the picker walks from the instrument family to the convention that serves it, and the convention states the terms it fixes. It also draws a second person's approval for every write: the request waits, Market Risk decides, and a decline leaves the convention alone. | prototype | none |
| See the conventions a party uses | That the conventions need the same plain entity screens as every record kind: the list of the 26 kinds, the list of one kind's documents and the record page of one document. The management workflows sit on top in a Workflows menu and open as their own pages. | prototype | none |
| Find a convention by its terms | How a person finds the document of one kind that states a set of terms, or learns that none does. The server filters a convention list by key only, so the screen reads every row and compares the terms itself. The page says how many rows it read, because a search that read one page is not a search of the kind. | prototype | none |
| Name a convention set | How a person makes a convention set that a report can choose. A set holds no term: it names one document for each kind it covers. The person describes the set, chooses a document for each of the 26 kinds, reads the reach and proposes the set. Nothing exists until Market Risk approves, so the control says Propose and not Save. | prototype | none |
| Retire a convention | How a person deletes a convention document safely. The reach panel comes before the dialog, because the only thing that makes a delete safe is knowing what else reads the row. The panel says what it cannot read, and does not show an empty list as if it meant none. The delete is a proposal, so the document stays until a second person approves. | prototype | none |
| Decide a convention change | how the second person decides a convention write. The change panel shows the old value beside the new one, because a request that shows only the new value cannot be decided. The queue never lists a request that the person raised, and a person who cannot decide sees only their own requests. A decline needs a comment. | prototype | none |
3. Adding a prototype
Create doc/prototypes/conventions/<name>/ with an index.html, and a
prototype.css and prototype.js when it needs them. Open the page with
the links table every prototype carries, and leave its review row at
none. Add a row to the table above, with the design note beside the
prototype when there is one. Stop there: the site build finds every
prototype under this tree, so no build file names it.
A review goes at doc/prototypes/conventions/<name>/review/, with an
index.html that lists its screens. The row names it, and the
prototype's review row points at it. Prototypes states the
whole method and the rules that hold for every group.
4. See also
- Prototypes — the top page: the groups, and the one way to add a prototype.
- Conventions journeys — the journeys these prototypes answer.