Profile screen prototype
Table of Contents
| Item | Where |
|---|---|
| Prototype | the prototype |
| Gemini review | the review |
| Group | Profile prototypes |
1. Summary
The profile screen prototype argues what the Profile journeys' screen should look like before any of it is built. It carries three structural variants of the same screen, for the two actors who use it, and the six states the requirement work named, so the layout can be judged with something concrete in front of you rather than in the abstract.
It is throwaway. It is not production code, it reads no service, and every value on it is mock data. It exists because the journey documents settle what the screen does; nothing yet settles where the save boundary sits, and that one question decides the other three.
Open the screen.
2. Detail
2.1. The question
One screen with panels is not in dispute: the photo, the identity fields, the contact details and the sign-in summary are panels of one screen, because a person thinks of them as one thing. What is undecided is where the write happens.
The account and the contact record are different records, and one Save is two writes that nothing makes atomic. So the screen must decide, visibly:
- Whether one Save writes everything the caller may write, or each panel carries its own action and its own reason.
- What a panel the caller may not write says, so the read-only rule is stated on the screen rather than discovered by a refusal.
- Where a reporting-line change goes, now that it is a proposal and not an edit.
2.2. The three variants
Switch with the bottom bar, the left and right arrow keys, or ?variant.
| Variant | Name | The structural argument |
|---|---|---|
A |
One page, one save | The journey document read literally: one screen, panels, one Save for everything the caller may write. One reason, asked once. The two writes are still two writes. |
B |
One page, per-panel save | Each writable panel carries its own action and its own reason, so a half-finished edit is never sent with the other record. The cost is two reasons and two confirmations. |
C |
Panels as rail steps | The shape the setup journeys use: photo, identity, contact, review, one step at a time, with the write deferred to the review step. The most work for the least certainty. |
The variants disagree about structure, not colour. A puts everything on one page and asks for one reason. B keeps the page and moves the boundary down to the panel. C is the same panels drawn as a rail, which is consistent with First run and with the registration door's accepted variant.
2.3. The two actors
Switch with the actor buttons, or ?actor.
| Actor | The screen |
|---|---|
member |
My profile, on their own record. Writes full name, job title, photo and the contact record through the self-service subjects. The username, the sign-in address, the account type and the reporting line are shown and not writable. |
admin |
Change someone's details, with the person search above the same panels. Holds iam::accounts:update and iam::account_contact_informations:write, which is the whole difference from the member. |
The signed-in person is never the person whose record is shown. The header names both, because an administrator who edits their own record by accident is the failure this screen has to prevent.
2.4. The six states
Switch with the state buttons, or ?state.
| State | What it shows |
|---|---|
view |
The screen at rest: the writable panels, the read-only panels, and the reporting line. |
photo |
The picker: an upload through ores.assets, the images the tenant already holds, a preview at the size other screens show the photo, and the choice deferred to a confirmation. The rule — PNG, JPEG or WebP, up to 2 MB, at least 128×128 — is stated beside it. |
saved |
Both records written, each with its new version. |
partial |
The account write landed and the contact write was refused. The screen names the record that failed and carries the refusal code, because "save failed" would leave the person unable to tell which half is real. |
proposed |
The reporting line with a change waiting for approval, naming who can approve it. |
refused |
A write the caller does not own, refused with field_not_self_writable. |
2.5. The reporting line
This is the state the review added. A reporting-line change is not an edit: a person proposes it, and the person's hierarchical superior or a tenant administrator approves it. The proposal is drawn on the identity panel, next to the value it would replace, and the value does not change while the proposal waits.
Nothing in the platform holds such an approval today. The workflow engine can hold the instance; the queue, the notification and the decision are the Draw the reporting line journey's, and the prototype says so on the panel rather than inventing an approval that nothing performs.
2.6. Driving it
Every control is live: choose a variant, an actor and a state; pick a person;
choose a photo; press a Save. Save on variant A produces the half-written
state on purpose, because that is the state a one-Save screen has to be honest
about.
2.7. What is fake
Everything. The tenant, the people, the roles and the rule are hard-coded.
There is no policy read, no server, no account, and nothing is stored. The
photos are the repository's own stock faces: six of the 462 AI-generated
images under external/facestudio/faces that the seeder draws account profile
pictures from. They are copied into doc/prototypes/profile/profile/photos/ so the
prototype is self-contained and publishes with everything it needs, and two of
them stand for people the journey documents name.
2.8. Where the code lives
doc/prototypes/profile/profile/. Three files of code plus the photos, plain HTML,
CSS and JavaScript, no framework and no build step. The site build copies the
directory through ores-deploy-web-app, beside the trade entry and
registration door prototypes.
2.9. The verdict
Variant B, one page with a save per panel, is accepted. The profile and the contact record carry their own versions and their own change reasons, so one reason for both would make the version history contradict the screen a moment after it was saved; and a half-finished edit must not ride along with the record that is ready. Variant A stays on the page as the record of the simpler reading the journey documents first gave, and a panel from it may still be borrowed.
C is not accepted. This screen is a page a person returns to, not a run that proceeds from a beginning to an end, so a rail implies a sequence the work does not have. The registration door's rail is right for the door because registration is a run.
The reporting line is proposed by the person whose line it is, and approved by their hierarchical superior or by a tenant administrator. An administrator acting on a colleague's record is the approver, so their own change takes effect; the proposal exists for the person who cannot make the change themselves.
2.10. What it does not settle
The approval. The prototype draws a proposal waiting for a decision; it does not argue how the approver is told, where the queue lives, or what happens when a superior and an administrator disagree. That is the Membership group's work and it is recorded on the journey.
The two email fields. The screen labels the sign-in address and the contact address apart and shows both, because the journey exposes two fields where a person expects one. Which one other screens treat as authoritative is a modelling decision that this prototype does not make.
3. See also
- Prototypes — the index of every prototype, and where to open each one.
- Profile journeys — the group this screen belongs to.
- Present myself, Keep my details current and Change someone's details — the three journeys this one screen implements.
- Protect my account and Know what I may do — the journeys that own the sign-in and access panel.
- Registration door prototype — the sibling prototype, and the reason the tokens and the rail classes are copied rather than invented.