Tenancy prototypes
Table of Contents
1. Summary
The tenant itself, its lifecycle, and the lookups that classify things.
2 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. 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 |
|---|---|---|---|
| Application shell | The shell the journeys hang from: a menu of areas, the cards it opens, and the person's own journeys under their name — seen through the four sign-ins that decide the mode. It sits here rather than in Profile because the Home prototype replaced its landing page, and both answer to the sign-in's tenant. | prototype | Gemini review |
| Home screen | Home and tenant management in a person's own words: the state of the work instead of journey cards, tenants as a list with add and remove, a tenant opened in place with no entering or leaving, and colour for each tenant's state. | prototype | Gemini review |
3. Adding a prototype
Create doc/prototypes/tenancy/<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/tenancy/<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.
- Tenancy journeys — the journeys these prototypes answer.