Views and patterns
A view pattern is a reusable presentation strategy for a known kind of work. modelARch infers patterns from model semantics and allows explicit, structured overrides when the product needs a different composition.
Pattern families
Section titled “Pattern families”| Family | Patterns |
|---|---|
| Collections | data table, card grid, kanban, feed, calendar, map, gallery, hierarchy, inbox |
| Temporal work | timeline, activity log, stopwatch, timesheet |
| Detail | detail, profile |
| Containers | master-detail |
| Specialized | dashboard, wizard, cart, financial timeline, bulk import, assistant |
| Conversation | thread |
The exact generated treatment depends on the target and the semantic shape available. Selecting calendar without a meaningful date field is not a complete design decision.
Inference
Section titled “Inference”Inference uses declared semantics rather than only names. Examples:
- lifecycle state plus move actions can support a kanban;
- date/time fields and scheduling actions can support a calendar;
- actor/content/timestamp relationships can support a feed or thread;
- metrics and grouped queries can support a dashboard;
- timer behavior can support a stopwatch;
- weekly work logs can support a timesheet.
The inferred choice remains inspectable and can be rejected.
Composition
Section titled “Composition”Detail and dashboard views can use named slots such as history, relations, subcollections, reviews, gallery, attributes, and primary actions. A structured override can reorder slots, choose an inner layout, hide fields, or bind a slot to a query.
Replace semantics must be clear: when an override supplies a final slot list, omitted baseline slots may disappear. Validation should warn when an override accidentally drops important content.
Actions
Section titled “Actions”Place actions according to intent:
- primary action for the next expected step;
- row or card action for an operation on one item;
- bulk action for a declared multi-item operation;
- form action where parameters require input;
- hidden or disabled behavior only when the backend enforces the same rule.
Custom screens
Section titled “Custom screens”Use custom screens for content that does not derive from a domain concept, such as landing, help, or about pages. Authentication, notifications, files, and audit are modules—not arbitrary custom screens.
Avoid screenshot-driven modeling
Section titled “Avoid screenshot-driven modeling”A screenshot can inspire visual composition but cannot express data source, access scope, action semantics, loading behavior, or error states. Capture those decisions in the blueprint and design system so the view survives regeneration.
See Preview fidelity and the Evolutionary Model reference.