← zurück

LODUR Löschwasserplanung — UI differentiation brief (v2, forked 2026-10-10)

Supersedes the build plan in MANIFEST §6–7. Not yet approved for execution.

1. Purpose

Give the client's coder, who already has the working engine seen in the video, a set of UI directions for the Löschwasserplanung module that keep every function, field, unit and number of the existing software but look and operate in a recognisably different way, so that no other designer's expression is copied.

2. Deliverable

• Surface only. Static screens (HTML or image mockups). No working hydraulics, no map integration, no engine. Numbers on the screens are the real ones from the screenshots and may be hard-coded.
• Several distinct approaches, each complete: the three Details panels (Motorspritze, Tanklöschfahrzeug, Wasserbezugsstelle), the small objects (Gewässer, Hydrant, Verteiler), map chips or bubbles, the Werkzeuge palette, the Netzwerk strip, the Warnungen list, one simulation control.
• A hand-off sheet per approach for the coder: a table mapping every original control to its replacement, with the same value range, step and precision, so the engine needs no change.

3. What stays fixed

• Every field, read-out and unit in the inventory (MANIFEST §3). German labels verbatim; the owner reworks wording later. Swiss number formatting (1'800), bar, l/min, m ü. M.
• The standard Swiss fire-service symbols stay present.
• Value ranges, steps and precision of every input (0.1 bar, whole l/min, whole metres).

4. Rule zero: same function, different form

Each control must produce exactly the same numerical effect as the original but must not be recognisably the same control format as anything in the screenshots or the video.

• Not allowed because the original uses them: horizontal or vertical range sliders, pill toggles, native-style dropdowns, the 2×3 grey tile grid, the tab strip with a count badge, the flat progress bar with "Leer in", the plain number field with its unit at the far right.
• Allowed: a rotary dial or an arc gauge, a drum or thumbwheel picker, a notched rail with stops, a stepper with preset chips, a segmented control, a two-button on/off pair, a list sheet for long option lists, instrument rows or a dial cluster for read-outs, a tank column or ring for fill level.
• Ease test: setting 10 bar takes two taps; readable at arm's length with gloves. Elements may be regrouped and reordered freely.

5. Visual direction

• Civic Swiss restraint. Teal accent is acceptable. State colours (green ok, orange attention, red critical) stay separate from the accent.
• Tool pieces: beside each standard symbol, the real object as a consistent 3-D-style piece in a bubble, with a state ring and the live numbers beneath. One family, one camera angle, one style.
• From Peter's variant keep the chip language, big-number read-outs, Swiss formatting and the single simulation bar; drop his vertical slider; floating cards only for small objects.

6. Order of work (each step waits for a go)

1. Control-mapping table: original control → replacement, per panel. Approved before any drawing.
2. Three approaches as quick wireframes of the Motorspritze and Tanklöschfahrzeug panels only.
3. Owner picks one, or asks for a merge.
4. The chosen approach finished in full for every item in §2.
5. Hand-off sheet and final files to the coder.

7. Definition of done

• No control on any screen matches a format from the screenshots.
• Every inventory field is present with its unit and the correct number.
• Phone width and desktop width both shown; light and dark both shown.
• The coder can implement from the hand-off sheet without asking what a control does.

8. Reference material (not part of the deliverable)

The verified calculation sandbox in prototype/engine.js and its 140-assertion test suite exist for checking that mockup numbers are right. They are not to be delivered and not to be extended.