One detail view for all items
Every item opens in the same detail view, whether event, place, task, post or person. What differs are the fields and the actions, not the surface. This is not austerity but the rule that prevents every module from building its own detail and the five versions drifting apart.
The anatomy
An event: header with type, meta box, content, tags and author. The sample data is fictional. Changes last only for this session.
From top to bottom, and each area answers a question:
- Header and badges: What am I looking at? Which type, from which Space Der gemeinsame Arbeits-, Mitgliedschafts- und Sichtbarkeitskontext. Im Datenvertrag heißt er Group. GlossarSpace The shared context for work, membership and visibility. In the data contract it is called Group. Glossary, private or mirrored?
- Meta box: When, where, with whom, connected to what? A date leads into the calendar, a place onto the map, that is the navigation rule “a field leads into its module”.
- Content: What do I need to know? Text, media, the fields of the type.
- Tags and author: Which topics, by whom, since when?
- Actions and discussion: What can I do or contribute? Edit, delete, reactions, comments.
Empty facts leave no empty meta box: a building block receives null for an empty slot, not an empty shell. A UI rule that holds needs this technical contract.
Where it opens
ItemDetailBody is the reading content, ItemDetailPanel wraps discussion and actions around it, and the host decides where the whole thing opens: in the shared panel, as a drawer on the phone, in the overlay above the map. A module opens no detail itself; it tells the focus which item is active, and the host does the rest (spec 01).
Detail with discussion in the panel, as the feed opens it. The sample data is fictional. Changes last only for this session.
Reading and writing are a pair
A date is, when reading, a point in time with a jump into the calendar and, when writing, a date field. Both belong to the same field of the same vocabulary; the type register keeps reading and writing rendering together instead of splitting them into two components that nobody maintains at the same time. The host opens editing in the same surface (?edit in the focus), with the composer that also does creating.
The same composer for create and edit, with the widgets of the type. The sample data is fictional. Changes last only for this session.
The states are part of it
Empty, loading, failed and read-only are regular states, not exceptions. An item that has not arrived yet shows its anatomy as placeholders instead of an empty surface; an item that does not exist says so once “not found” has been decided (useItem: isLoading only becomes false when the answer is there). A technically present write hook does not make an item editable; the permission decides that (Capability, permission, origin).
The same anatomy in the loading state. The sample data is fictional. Changes last only for this session.
People are not a second UI system
A Personenprofil Die fachliche Darstellung einer Person als Item nach Profilvertrag. Die User-Identität ist ein eigener Begriff. GlossarPerson profile The domain representation of a person as an item under the profile contract. The user identity is a separate term. Glossary carries other fields and other actions than an event: name, picture, get in touch, verify. But it is the detail view of an item of type person that lives in the personal space and is mirrored into groups (spec 12). Until then the reference app still carries a profile overlay of its own; it disappears as soon as the profile is an item. The term “profile” stays as the name of the content, not as a surface of its own.
Where to go next
In Storybook: Items → Detail view with all states, Items → Create and edit for the composer. Spec: Shared components of the modules, Spec 12 profile. Back to the start of the path: Develop locally.