See the conventions a party uses prototype
Table of Contents
| Item | Where |
|---|---|
| Prototype | the prototype |
| Gemini review | none |
| Group | Conventions prototypes |
1. Summary
This prototype argues that the conventions need the same plain entity screens as every other record kind, and that the management journeys sit on top of them as workflows. It answers to See the conventions a party uses.
It is throwaway. It reads no server, opens with no build and no session, and draws mock data. The page marks each place where the server does not provide what the screen needs.
2. Detail
2.1. The three screens
- The list of kinds. Two tabs: Party conventions for the 22 kinds the party holds, and Shared conventions for the four kinds held once for the tenant. The shared tab opens with a warning that every party reads them. Inside a tab the kinds sit in sections, one for each asset class of the product model (interest rates, FX, inflation, credit, commodity, bond). Each section states its kinds and documents. A row shows the number of documents, the number of distinct term sets and the requests that wait. It has a search, a filter on the asset class and sort. It has no pager, because a section holds at most twelve kinds. The party is never a column: a person reads one party.
- One kind's documents. The key first, then the main term columns and the source. It has a search on the key, a filter on the source, sort and a pager. Refresh, Workflows and Add stand at the right of the header. Page, page size, search, filter and order live in the address. The states are loading, loading again with dimmed rows, no records, no match, a refusal in words and a read error with Retry. After a Refresh that follows a change on the server, the changed row carries a gold mark for a few seconds.
- One document. A record page with the Details and History tabs, and a Requests tab only while a request waits on the document. The tab lives in the address. Edit stands on the Terms card, not in the header. It opens a dialog that says when the record was loaded, and asks for a reason and a commentary. Propose waits until a field differs. A reason that needs a commentary says so. An optional field has a Clear control. A newer version that arrives while the dialog is open shows who saved it and what moved, with Keep my edit and Take the new values. A save made against an old version is refused in the dialog. Closing a dialog that holds changes asks first. The Requests tab lists the requests and links to the decision.
2.2. The workflows on top
The Workflows menu holds the guided runs: Find a convention by its terms, Name a convention set and Define instrument conventions on the lists, and Retire a convention on a record page. Each line has the workflow's name and one line about it. A line is drawn only for a person who may start the workflow. Each workflow opens as its own page with its own trail and a link back here. Add and Edit stay buttons, because they are one record and one write. A write that needs a second person says Propose, as it does inside the workflows.
2.3. The UX rules it follows
The screens follow Record screen standard, Entity screen specification, UX Language and UI design principles. The access mark says Editable or Read only, and an action a person may not take is not drawn. Keys are monospace, an empty value is a muted dash, and a time is relative with the exact time on hover. A person is drawn with an avatar and a name. A change reason shows its name and not its code. The Refresh control carries the load time under it and turns gold when the data changed on the server. The strings are English only.
The prototype was checked line by line against the Screen review checklist. The task that did it records each line. Four exceptions stand, each with its reason:
- The list of kinds has no pager. It is a grouped list of at most 22 rows, and a page break would cut across the asset class sections.
- Edit stands on the card, as the entity screen specification says, and not in the header, as the record screen standard says. A convention document is one card of terms.
- A new document does not open its record page after Propose. The document does not exist until Market Risk approves, so the screen links to Requests.
- The Propose, Clear, Retry, Keep my edit, Take the new values and Close anyway actions are not in the icon table. The prototype draws Propose and the dialog actions as the standard words and leaves Clear without an icon, because the table gives the dismiss icon to Cancel.
2.4. States, by query string
?view=kinds|list|record, ?kind, ?key, ?tab=details|requests|history, ?q,
?source=curated|authored, ?scope=party|shared, ?class, ?actor=m.okafor|k.mori,
?dialog=add|edit, ?menu=1, ?state=loading|reloading|error|refused, ?empty=1,
?page, ?size, ?sort, ?dir=desc, ?stale=1 (Refresh turns gold), ?news=1 (a row carries the
changed mark), ?dialog=edit&newer=1 (a newer version arrived) and
?dialog=edit&newer=1&refused=1 (the save was refused).
2.5. What is fake
Three of the 26 kinds carry mock documents: swap, deposit and the IBOR index. The other 23 list three documents with no terms. The families route returns a count of documents for each kind and no count of term sets, so the screen reads each list to count them. The requests that wait are fixtures.
2.6. Where the code lives
doc/prototypes/conventions/see-the-conventions-a-party-uses/. The page is
index.html with its own prototype.js. management.css and management.js are
shared by copy with the four workflow prototypes.
2.7. Verdict
Open. The question for review is whether the list of kinds is a screen of its own or a header of the list of one kind. The journey reads kind by kind, so the prototype draws both.
3. See also
- See the conventions a party uses — the journey this prototype answers.
- Conventions prototypes — the group page.
- Prototypes — the method and the rules.