Find a convention by its terms prototype

Table of Contents

Item Where
Prototype the prototype
Gemini review none
Group Conventions prototypes

1. Summary

This prototype argues 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. It answers to Find a convention by its terms.

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. A toggle in the bar at the foot hides those notes.

2. Detail

2.1. The steps

  1. The terms. A kind select and one control for each term column of the kind. A term left as Any matches every value. A term left as Not stated matches only a document that states nothing for it. The page states the asset class of the kind, how many documents it holds and how many distinct term sets they state. A shared kind such as the IBOR index carries a warning that every party reads its documents.
  2. The matches. The documents that state the terms, with the term columns the person left open beside the key. A notice says how many rows the screen read. A kind with no match says so and offers to add a document. Several keys that state the same terms are noted.
  3. A match. The document as a record page: details, the same-terms tab, and the last-changed line. Edit and Delete are drawn for a person who may write, and both lead to the prototype that owns the act.

2.2. How it is reached

It is a line in the Workflows menu of the conventions screens: Find a convention by its terms. The trail is Home › Reference data › Find a convention by its terms, and a link returns to the list of the kind. The owner may decide that a filter on the list serves this act better than a workflow. The prototype draws the workflow so the question can be argued.

2.3. The UX rules it follows

The screen follows Record screen standard, UX Language and UI design principles. It is one screen with a rail of steps. A list has a search, a sort, a pager that starts at 15 rows and states for loading, no records, no match and an error. A write that a second person must approve says Propose and not Save, and the dialog says that nothing changes until the other person approves. An action a person may not take is not drawn. The access mark says Editable or Read only, and no permission code appears on a screen. A reason is a choice from a list. A time is relative, with the exact time on hover. A key is monospace, and an empty value is a muted dash. Colour carries meaning only: green, amber and red are status, grey is inactive, and violet marks a classification. No native select is used. Every string is in English only; the product needs French and Portuguese before a screen ships.

2.4. States, by query string

?step=0|1|2, ?kind=swap|deposit|ibor_index, a term by its column name such as ?fixed_calendar=AED, ?key=, ?actor=m.okafor|k.mori, ?fail=1.

2.5. What is fake

Three of the 26 kinds carry documents: swap with 320 documents that state 201 term sets, deposit and the IBOR index. The Used by column is a fixture: only the curated AED swap is named by a set, and no set exists in the server.

2.6. Where the code lives

doc/prototypes/conventions/find-a-convention-by-its-terms/. The page is index.html with its own prototype.js. management.css and management.js are shared by copy with the other three management prototypes, and the inventory check keeps the copies identical. The icons are the Fluent paths of the application's own icon set.

2.7. Verdict

Open. The question for review is whether the terms panel should draw one control for each column or accept a typed phrase such as AED annual ACT/365. The server filter, not the screen, decides how much of this is possible.

3. See also

Emacs 29.3 (Org mode 9.6.15)