Home screen prototype
Table of Contents
| Item | Where |
|---|---|
| Prototype | the prototype |
| Gemini review | the review |
| Group | Tenancy prototypes |
1. Summary
The first screens built from the Application shell prototype spoke the implementation's language. The home page counted and listed journeys, and a system administrator reading a tenant was asked to enter it and leave it. Neither word is one a person uses about their work.
This prototype redraws the home screen and the tenant screens in the person's own words. The areas hold screens and buttons named for what a person does. Home shows the state of the work. A tenant opens like any other record, and the session that reads it is held for the screen and never offered as a step.
It is throwaway. It is not production code, it reads no service, and every value on it is mock data.
Open the home screen.
2. Detail
2.1. The verdict
Accepted on 2026-10-04. It replaces the shell prototype's landing page and its journey cards; the shell's menu across the header, the mode read from the sign-in and the person's own screens under their name stand as they were.
2.2. What changed from the shell prototype
| Shell prototype | This prototype | Why |
|---|---|---|
| The landing page lists every area's journeys as cards | Home shows the state of the work, with the next actions as buttons | A person opens Home to see whether anything needs them, not to read a catalogue |
| A journey is a card a person chooses | No screen says journey; screens and buttons are named for the action | Journey is how the screens are designed, not a word a person uses |
| System administration's area holds three journey cards | Tenants is one list, with Add tenant and Remove tenant as buttons on it | Adding and removing are actions on the list, not places to go |
| Reading a tenant's data means entering it and leaving it | Opening a tenant shows its overview, parties and people in place | The tenant session is how the read is done, not something the person asked for |
2.3. System administration
- Home opens with a System health card (the built screen has since become a dashboard of four panels on a tab, after the Gemini review below): the tenants in service, on evaluation and setting up, a plain verdict (a green tick and Everything is running, or an amber mark and how many tenants need attention), and the recent activity. Needs attention lists the failed setups and suspended tenants, each with a button to it. A short tenant list follows, with a way to the full one.
- Tenants is the roster: search, type and status filters, Show test tenants, paging. Add tenant and Remove tenant sit on the list; a row is selected to remove it and clicked to open it.
- A tenant opens with tabs for its overview, its parties and its people. A quiet View only label is the one trace of the session underneath, and says that the tenant's own administrators make the changes. A failed setup offers Try again.
- Remove tenant says what removal does before it happens and asks for the tenant's code to confirm.
- Add tenant is one form: the organisation, what to start from, and its administrator.
2.4. The Gemini review of the system administrator's home
Gemini drew the system administrator's home a second time, as a dashboard: four panels in two columns (tenants, services, the compute grid and the message queue) under one installation-wide status, each panel with metric tiles, a footer and a "see all" or "open" control, and a sparkline on the grid and the queue. It is kept as the record of an alternative, at the review, and the agreed design above is unchanged.
The built screen took four things from it, and left the rest:
| Taken | Why |
|---|---|
| Four panels with one status language, and one status for the whole installation at the top | The home had one verdict for tenants and nothing for the installation. A person reads the same sentence in every panel, and the top status says whether any of them needs them. |
| Metric tiles in a box, with the figure large and the label small | The figures read as separate facts instead of one run of text. |
| Two columns, so the four panels have the same weight | The first build gave tenants a full row and squeezed the other three into thirds. |
| A footer on each panel that says when it was read, or which release it is | A panel that cannot say how old it is invites a wrong reading. |
| Left | Why |
|---|---|
| The processor load sparkline on the grid | No read gives the grid's processor load. The grid samples the journey asks for do not exist yet. |
| The scheduler status line | Nothing records it. |
| The broker name as a footer | It is static text that adds nothing a person can act on. |
| The message throughput sparkline as drawn | The built panel draws the rate from the server samples it already reads: the difference between two samples of the message counter, over the seconds between them. The figure is real, and the curve is the samples' own. |
| "All clusters operational" | The installation has one deployment, not clusters. |
2.5. Tenant administration and the party user
The tenant administrator's home leads with the same kind of verdict in its own terms (a locked account), live figures for sign-ins, and tiles for Parties, People and Tenant settings. The party user's home says plainly which areas are not in this release, and keeps them so people know they are coming.
2.6. Colour carries the state
Status badges are filled: green is in service, blue is production, purple is evaluation, amber needs a look, and red has failed. The idea came from a design Gemini suggested for the same screen, with the system health card and the recent activity beside it. Two of that design's row actions were left out on purpose: Act As, because it offers the tenant session as a step, which is the thing this prototype removes; and Edit, because a tenant's own administrator maintains its details.
2.7. What is real and what is not
The colours and type are the web app's own tokens, so the prototype is judged on its words and its structure. The screens, the people, the tenants and the activity are mock.
Two things the prototype draws have no server behind them yet:
- Remove tenant. Its wording (everyone signed out, no more sign-ins, the data out of use, no undo) is the design's assumption. The server has no removal. Since built: the server refuses sign-in at once, and people already signed in lose access within one access lifetime rather than at once, so the dialog says that instead.
- Recent activity. The provisioning runs can tell a tenant's setup story, but no read gathers the deployment's activity in one place.
2.8. Where the code lives
doc/prototypes/tenancy/home/index.html: one file, plain HTML, CSS and JavaScript, no
framework and no build step. The site build copies the directory through
ores-deploy-web-app, beside the other prototypes.
3. See also
- Prototypes — the index of every prototype, and where to open each one.
- Application shell prototype — the shell this home screen sits in.
- The Gemini review — the dashboard Gemini drew for the system administrator's home.