What the panel is for
When a user selects an annotation on the map (clicks the marker, taps the feature, draws a selection box around several), the annotation panel opens. The panel is where the work happens — viewing the feature's attributes, editing them, marking the feature for review, adding a note, viewing its history, or escalating it to a senior reviewer.
The map itself stays simple. Click a thing, the panel shows you what to do with it. That separation matters because users with different roles do different things, and the panel adapts to who you are.
How the panel is organized
The panel has four zones, top to bottom. The same layout regardless of project so users can move between projects without re-learning.
Top: identity
The first thing you see is what the annotation is — class, ID, and a one-line summary. Below that is the geometry summary (lat/lon for a point, area for a polygon, length for a line). Above any work, you see what you're looking at.
This zone also shows the annotation's current review status as a colored badge: draft (gray), submitted (blue), approved (green), flagged (yellow), rejected (red). One glance tells you whether action is needed.
Middle-top: attributes
Below identity is the attribute editor. Every annotation class has a defined attribute schema — for a road sign that might be MUTCD code, sign material, condition rating, visibility score, mounting type. Each attribute is a form field with type-appropriate validation (dropdown for enums, number input with min/max for scores, free text with character limit for notes).
Required attributes are marked with an asterisk. Validation runs as you type and the submit button stays disabled until everything required is valid. This catches incomplete annotations before they get into production, not three weeks later in a QA pass.
Middle-bottom: review actions
This zone changes based on your role. An annotator sees: Save Draft, Submit for Review. A reviewer sees: Approve, Flag, Reject with notes, Send Back to Annotator. A senior reviewer additionally sees: Lock Final, Override Schema. Each action writes to the activity log with the actor's identity.
Most users only ever see two or three buttons. The panel doesn't show actions you don't have permission for — they're not greyed out, they're absent. That cuts the cognitive load substantially.
Bottom: history
Every change to the annotation is logged: created by, modified by, attribute changes (before → after), review decisions, comments. The history is collapsible (closed by default for new annotations, open if there's been activity). Each log entry is a single line with a timestamp and the actor's name.
History matters for two reasons. For the user, it explains "why is this annotation in this state right now." For audits or regulatory work, it provides the chain of custody you need to defend the annotation against challenge.
Design choices we made deliberately
One annotation at a time, by default
The panel works on the selected annotation. If you select multiple annotations, the panel switches to multi-select mode with bulk operations (mark all as approved, bulk attribute update, bulk class change). The single-annotation view stays the default because most work is one-at-a-time.
Edits are local until you save
Changing an attribute updates the panel but doesn't write to the server until you click save. This sounds obvious but a lot of annotation tools save on every keystroke, which produces noisy edit histories and bad UX when the network is slow.
The panel is keyboard-navigable
Tab cycles through attributes, arrow keys move between annotations on the map without leaving the panel, Esc closes the panel. Power users — the ones doing 200+ annotations a day — should never need to touch the mouse for routine work.
Mobile is a different layout
On phones the panel is a bottom sheet, not a sidebar. The map keeps the top two-thirds of the screen, the panel slides up from the bottom and takes the bottom third. Touch targets are larger, the keyboard pushes the panel up instead of hiding it. We build mobile second, after the desktop layout is solid, but we always build it.
What the panel doesn't do
Three things, by design.
It doesn't show all annotations in a list. That's a different view (the annotation list page) accessible from the nav. Cramming a list into the panel competes with the map for screen real estate and we'd rather use the map.
It doesn't try to be a full feature editor. For complex geometry editing (reshaping a polygon, splitting a line), we open a dedicated editor mode on the map itself. The panel handles attributes; the map handles geometry.
It doesn't replace the data export. Bulk export, format conversion, and project-wide reports live in their own pages. The panel is for working on one thing at a time.
Want this panel customized to your workflow? It's a React component we adapt per-project. Send a Loom of your current annotation process and we'll come back with a wireframe of the panel that matches it.