UX

UI design principles — start here. The design direction, the spacing, the depth and the type. Every later page assumes these rules and does not repeat them.

UX Language — the meaning of colour: grey is inactive, orange is a missing badge definition, and green, amber and red are status and nothing else. It also sets the access mark, and the difference between History and Audit. Read it before choosing any colour or word for a screen.

Icon guidelines and Badge catalogue — the two vocabularies that UX Language points to. One icon carries one idea. One badge code carries one colour. Look a mark up here before drawing a new one.

Menu structure — the one menu for every person, the area each screen belongs to, and the breadcrumb that follows. Read it before adding a screen, because the next two pages assume the screen already has an area.

Record screen standard — the list, the record page, the writes, the history and the states for a currency, a calendar or a role. Each rule names the shared component that carries it.

Entity screen specification — the extension for a subject made of several kinds of record, such as a person. It adds the tabs, the cards, people as links, the timeline, and the rule that the pager is the request. Where it and the record standard disagree, the record standard rules for one kind of record and this page rules for an entity.

Feed screen standard — the extension for a record that produces market data: the list as a dashboard, the process edited as one set with its engine and previews, saving with a reason and a restart, the ticks, and the quant help. It applies to every asset class. Where it and the record standard disagree, this page rules for a feed.

Configuration screen standard — the extension for a named, party-owned configuration that a report binds and that comes off an ORE XML document: the words, the list, the record page with a tab per section, the documentation contract, the reach, the history, the per-section lifecycle and the import. It applies to every configuration kind in the configuration_type vocabulary. Where it and the record standard disagree, this page rules for a configuration.

ORE element and leaf screen standard — the one way a screen draws a value of an ORE document and the type it belongs to, whether a product parameter, an engine run setting or a convention term: the Simple and Advanced switch, the documentation under a leaf, the value in force, the control, the marks and the gaps, with the exact words. It comes after the configuration standard because a convention is not a configuration section but draws the same leaves, so the leaf rules hold inside a configuration page and inside a record page alike.

Screen review checklist — one line per rule of the pages above, to tick off when a screen is built or reviewed. It adds no rule. Each line names the section that states it.

Every rule of the record screen standard and the entity screen specification carries an identifier at the start of its bullet, such as *RS-LIST-03*: the page's code, RS or ES, the code of the section the rule was born in, and a number that is never reused. The identifier is permanent. A rule that moves keeps it, so the section code says where it was born and not where it lives, and a reader follows the identifier rather than the page. The checklist cites identifiers, and a check reports one, so a reviewer and a test point at the same rule. build/scripts/check_rule_identifiers.py gives a new rule its identifier with --assign and refuses a rule without one, a duplicate, and a checklist line that cites an unknown one.

User Journeys — the goal each screen serves. A journey decides which records a person works with. The pages above decide how each screen looks and behaves.

Qt to web reference data matrix — what each Qt reference data screen offered against what the web shows today. Read it to find a gap before a topic enters the screen pipeline. It is a measurement, produced by a script a reviewer can rerun, and it adds no rule.

Audit of the UX standards — where the pages above disagree, what the form layout leaves open, and what a rule needs so a check can name it. Read it to see what the standards still have to settle. It adds no rule either.

The screen pipeline topics — the Qt entities grouped into eleven topics, each judged as standard or a workflow and ordered for the pipeline. Calendars go first. Read it to know which topic is next and what it carries.

The record screen baseline — what the harness found on every record screen before the pipeline started, rule by rule, and the four captures it filed. A later run replaces its table.

The market simulator screens — the one composite window of the desktop client. It belongs to the cluster by subject and not by sequence. Read it when the question is the Qt simulator, not when the subject advances.