# UI Design

## Environment Baseline

* Confirmation popup source identity is configurable via `MAILSHOTS_UI_SOURCE_LABEL`.
* Default value for `MAILSHOTS_UI_SOURCE_LABEL` is `Mailshots`.

## Purpose

Define user interface requirements common to all pages.

## Top-Level Layout

* Use WordPress admin-page navigation as the canonical navigation model.
* Each plugin page should render its own content region within the standard WordPress admin page layout.

## Navigation

* Implement navigation as a set of WordPress Admin Pages under the FECA Mailshots plugin admin entry.

## Content Pane

* Constrain content pane to one visible screen page.
* When content exceeds available space, scroll inside the content pane.
* Structure the pane into these regions as applicable:
  * context pane (top left)
  * information pane (optional)
  * statistics pane (optional)
  * actions / filter pane (optional)
  * data pane (optional)

## Standard Page Regions

For pages using info/statistics/actions/data regions:

* Place information pane at top-right for hints, feedback, and errors.
* Place statistics pane at top between context area and information pane.
* Place actions pane below top panes.
* Place data pane below top panes/actions.
* Keep controls visible while allowing internal scrolling in the data pane.
* Avoid horizontal scrolling when content width can be adjusted to prevent it.

### Multi-Pane Data Areas

* If a data area contains two or more sibling panes, provide a draggable divider between adjacent panes.
* Use vertical dividers for left/right panes and horizontal dividers for top/bottom panes.
* Persist user-adjusted split ratios per page.
* On narrow viewports, collapse split layouts to a vertical stack and disable drag interaction.
* Keep each pane independently scrollable when content exceeds pane bounds.

## Common UX Rules

* Use configured `MAILSHOTS_UI_SOURCE_LABEL` as source identity in confirmation popups.
* Hide CRUD forms when not in use.
* Use red visual treatment for destructive actions.
* Provide spacing between action buttons and panel edges.

## Default Table Behavior

* Allow user-resizable widths for all displayed table columns, including in Firefox-derived browsers.
* Use edge-drag column resizing with no explicit/visible drag-handle element.
* Persist column widths per table.
* Where a table supports sorting, provide:
  * a `Sort by` dropdown listing sortable columns
  * an adjacent direction dropdown with options `Ascending` and `Descending`
* Do not use per-column header sort controls.
* Keep `Actions` column non-sortable.
* If a page-specific rule conflicts with default table behavior, page-specific rule takes precedence.

## Resize Stability Requirements

* Do not trigger data reloads during column resize interactions.
* Keep table visible while dragging a column-resize handle.
* Do not show transient loading states during resize unless a real refresh is explicitly requested.
* Ensure resize-state updates (for example column widths) do not alter API request dependencies for table-load effects.
* Keep API client functions used in effect dependencies referentially stable across normal UI rerenders (for example resize, hover, selection changes).