Trades prototypes
Table of Contents
1. Summary
What a person does with a trade: book it, amend it, read it, bring it in from ORE and send it out, record what happens to it, and group trades into one deal. The Trade journeys are use cases. These prototypes are the screens that serve them.
5 prototypes answer to this group. Each one is a static page under doc/prototypes/, opens with no build and no session, and reads mock data only. They share one stylesheet and one script of mock data and components, by copy: each folder holds its own copy, so each prototype stands alone and opens without the others. build/scripts/check_prototype_inventory.py fails when the copies differ. They link to each other.
Prototypes is the top page and the only inventory.
2. The prototypes
| Prototype | What it argues | Open it | Review |
|---|---|---|---|
| The trade view | A trade is an entity. One page with a tab for each aspect serves review, amendment and lifecycle events. Edit asks for the kind of change first, and the kind bounds the fields. A save does not reload the page. It is what a trade row of the blotter opens. | prototype | none |
| Book a trade | Booking is one page in tabs. The trade type is a combo box, and it decides which parts the Instrument tab has, one tab for each. | prototype | none |
| ORE import and export | Import is a workflow because the person must see the plan before it is written and must be able to undo it. Export checks the trades before it makes the file. | prototype | none |
| The trade blotter | One screen reads trades and structures together: a portfolio tree on the left, the list of top-level trades and whole structures beside it, a flat option that reads the legs as trades, and the perspectives the same rows are read through. A structure is one row and its legs are inside it; a row opens the trade view or the structure view. A structure whose legs span books sits at the node that holds them all and says so. | prototype | none |
| The structure view | A package is a kind of structure, so one screen serves every kind and its words follow the kind. The page also checks the legs against the template and prices the structure from a market snapshot. A structure is one deal, confirmed as one document and priced as a whole. A package confirms trade by trade and is priced leg by leg. It is what a structure row of the blotter opens, and it carries the grouping workflow. | prototype | none |
3. How the prototypes follow the UX standards
| Rule | Where to see it |
|---|---|
| One page per subject, one tab for each aspect, tabs held in the address | trade page: ?trade=ACME-100201&tab=history |
| Edit is a button on a card. The reason is asked in the dialog. Save stays disabled until a field differs | trade page: Edit on the Instrument or Booking card |
| A control the person may not use is not drawn | every prototype: switch to reader in the bar |
| The pager is the request | trade list: the request line under the table |
| A save does not reload the page. Refresh turns gold and the person presses it | trade page: save an edit, then Refresh |
| History is a chart over a rail of one-line entries, with details on demand | trade page: History tab |
| A reference is a link to its record. A person is drawn with a photo or initials | every list and card |
| A workflow is in the Workflows menu of the screen it acts on, in the workflow hue. Add is a button | trade list: Book a trade is the Add button, and Workflows holds Import, Export and Group trades |
| A list is the standard list: a page, a stated order and a filter record, and a combo box offers only values that exist | trade list: the request line, and the filter combo boxes |
| A fixed field says why | trade page: Identity card |
| Loading, empty, error and refused states are in place | trade list: the states in the bar |
4. Decisions taken
- A Trades area. The Menu structure page now names the Trades area, its screens and its addresses.
- The page header. The Entity screen specification now makes the trade the one exception to the identifier-only header: it also carries the state and both versions.
- The kind of change comes first. The entity specification now states it for the trade page: the kind of change bounds the fields of the Edit dialog.
- Booking. One page in tabs, with the trade type in a combo box and a tab for each part of the instrument. Booking is the Add of the trade list, and the sequence is dropped.
- The standard entity protocol. The trade screens read and write through the standard entity operations. What a screen needs and the protocol lacks is a change to the model.
- Authorisation. Out of scope for now. The prototypes draw no authorisation. A capture is filed and waits.
5. What is not drawn
- Authorisation. The first prototype of this work, the Trade Entry Prototype, drew it and is retired. Its structure support now lives in Book a trade, which books a leg of a structure, and in the structure page, which manages, checks and prices one.
- A person does not confirm anything with a counterparty here. Confirmations have no journey.
- Currencies, books and the ORE directory wizard are other groups.
6. See also
- Trade journeys — the use cases these prototypes serve.
- Entity screen specification and Record screen standard — the screen rules.
- UX — the structure note that orders the UX cluster.
- Prototypes — the only inventory of prototypes.