Theming & Responsive Layouts

Build the Adaptive Operations Console by separating appearance from layout. In the Wisej.NET visual system, knowing which layer owns a decision helps you change the application consistently instead of fixing individual controls one at a time.

Follow the appearance key from a server control to the theme and then to the browser widget. The key selects the visual definition, so one theme change can affect every control that uses that appearance.

A theme describes colors, fonts, images, appearances, states, styles, and properties in one structured file. Named color and font tokens connect those definitions, making a visual choice reusable across controls, widget metrics, and designer previews.

Distinguish theme decisions, server-control properties, and direct browser styling. Use the theme for shared appearance, control properties for the relevant behavior and layout, and scoped cascading style sheets only where a browser-specific rule is justified.

A fixed button background describes only one visual value, leaving hover and pressed behavior unresolved. Choose an appearance key for those states, a class for the metric card, an inline style for a computed value, and docking for placement.

Dock the toolbar above, status below, navigation left, details right, and workspace in the remaining area. Give the workspace a minimum size, and use the viewport-filling page's resize event to report the browser width for inspection.

Inventory the visual decisions before editing a theme. Record the controls, ten color tokens, three font tokens, five regions, and six breakpoints, assigning each item an owner so later changes go to the appropriate layer.

Narrow the browser to tablet width and watch the width indicator and docked regions. The details panel is pushed out, exposing the limit of this desktop shell: docking alone has not yet defined how the workflow adapts.

For the first lab, deliver the five-region shell, recorded base theme, visual inventory, and browser-width status. This establishes a visible baseline whose current limitations can be compared with the responsive improvements in later modules.

Create AdaptiveOps from an existing base theme so the console inherits a complete visual foundation. The Theme Builder lets you express the application's identity centrally instead of rebuilding its appearance through scattered control-property assignments.

Repeating a brand color across many local overrides makes each adjustment harder to coordinate and still misses interaction states. A central theme gives the color and its state behavior one maintained definition instead of tying them to internal browser structure.

Inspect colors, images, fonts, and appearances as separate theme sections. Within an appearance, states and components define styles and widget properties; understanding that structure tells you where a change belongs and what the application may override.

Click the preview to discover the appearance path through Last Clicked before editing it. Use the tree to locate structure and the property grid to change values, then check the live preview to confirm the intended control changed.

Let action-button inherit the base button and override only the intended three states. Focused and disabled behavior remain inherited; inspect state order with default first before changing a color that may be coming from a later state.

Define the ten named colors and three fonts once, then reference those names from appearances. The primary blue and accent amber become shared tokens, so future brand changes do not require finding repeated hexadecimal values across the theme.

Select the startup theme in Default.json and use Application.Theme when changing only the current session. Assign action-button to the primary command and remove its fixed background, otherwise the local override can hide the theme's intended appearance.

Switch the console to AdaptiveOps and inspect more than its default colors. Hover and press Save, check the invalid editor, and read the theme status so the demonstration verifies state behavior as well as successful theme selection.

Build the tokenized theme and its requested appearances, including action-button, then test them in both preview and the console. Seeing the same definitions work in those two contexts helps catch overrides or missing states before handoff.

Compare three ways to style the same metric card by asking who will maintain the result. A theme appearance, a named class, and an inline style may look identical today while creating very different responsibilities for future changes.

Use an appearance for a reusable visual variant and a class for a searchable application-specific rule. Repeated anonymous inline overrides have no shared definition, so every copied panel becomes another place that can drift when the design changes.

Choose the owner before writing the style: theme for standard controls, appearance key for meaning, class for application-specific interface, and inline style for one computed value. Remove conflicting overrides that prevent the chosen owner from actually controlling the result.

The Assign command expresses its role with action-button, while the theme supplies its states. Likewise, a stale-row state describes presentation; the application must still own the underlying business data instead of inferring it from a color.

Replace four copied styles with the shared metric-card class. Keep the service-level agreement bar's computed seventy-two percent as the single inline value, and use a themed stale state to present data whose meaning remains in the model.

Distinguish startup configuration, a session's selected theme, and mutation of a shared theme object. Editing the shared object changes what other sessions see, so a personal dark-mode choice must select a separate theme rather than alter the shared definition.

Load the named dark theme, assign it to Application.Theme, and remember the preference in the current session. Handle a missing file explicitly; the startup configuration stays unchanged because this choice belongs to one session.

Inspect cards, badges, the primary command, and the stale row, then compare two sessions side by side. Dana's dark selection should leave Priya's light theme intact, providing direct evidence that the switch is session-specific.

Deliver the scoped stylesheet, one computed inline style, semantic command appearance, stale state, and session-only switch. Explain the owner of each choice so the review can verify both maintainability and isolation between users.

Replace the console's resize-coordinate calculations with container relationships. When the layout describes which region belongs against each edge and which fills the remainder, resizing no longer needs a new set of manual positions for every width.

The desktop coordinates look correct until the viewport narrows. Anchored details overlap the fixed workspace and Save leaves view, showing that each extra coordinate patch treats one symptom without defining how the regions should share limited space.

Dock children in the intended order so edge regions consume space before the workspace fills what remains. Padding reduces the available display rectangle; margin does not create docking gaps, so use the property the layout engine actually reads.

Avoid a sizing loop where an automatically sized parent depends on children docked back to it. Let oversized content scroll instead, and use minimum and maximum sizes to express useful limits without forcing the whole hierarchy to resize around itself.

Build the five docked regions with eight pixels of page padding and minimum sizes for workspace and grid. Once the container layout owns resizing, remove the old handler so two competing mechanisms no longer assign the same geometry.

Encapsulate the details editor in a UserControl that owns scrolling and internal anchors. Expose the ticket and saved event to the shell; this keeps the outer layout independent of the editor's individual text boxes.

Narrow the browser and inspect the resulting behavior: the rail becomes compact, details scroll, and the workspace respects its minimum dimensions. The point is that container rules produce this outcome without executing the removed resize-coordinate handler.

Because the details region is a self-contained UserControl, the shell can relocate it without rebuilding its internals. Dock it below the grid for a tablet or host it in a modal form for a phone as later profiles require.

Deliver a nested-container shell with deliberate docking order, padding, size limits, and a scrolling details editor. Extract the navigation and details controls, and remove manual bounds assignments so reviewers can see that the layout has one owner.

The outer shell now docks correctly, but the content inside each region still needs its own layout rules. Compare Flow, Table, and Flex by the behavior the content requires rather than choosing one container for every situation.

Cards and fields still disappear at tablet width because they are positioned manually inside a responsive shell. Decide whether each region should wrap items, align fields, or share space proportionally before replacing those coordinates.

Watch the same four cards under each engine as the viewport narrows. Flow wraps them, fixed table columns squeeze, and the shown flex setup clips the last card; those outcomes explain why wrapping cards, forms, and proportional regions need different choices.

Extended properties describe a child's participation in its parent layout. Configure flow weights and breaks, table positions and spans, or flex weights and alignment through the container so the parent receives the instructions its engine understands.

Check which engine interprets spacing before adjusting Margin. Flow and Flex enforce it, Table applies it inside a cell, and default docking ignores it; padding is the mechanism that changes available space around docked content.

Let the filter bar wrap, give search the remaining width, and break after Apply. For the editor, use fixed labels beside a flexible field column and make each field fill its cell, keeping rows aligned while the available width changes.

Give the dashboard regions weights of two to one, align them at the top, and retain a minimum size for each. The fluent Wisej.NET Markup version expresses the same relationships; use one notation consistently within a container.

Resize from a wide desktop to a narrow viewport and follow all three behaviors. Cards should wrap, editor columns remain aligned, and details stop at their minimum size, demonstrating that each container is solving its assigned layout problem.

Build the filter bar, ticket editor, and dashboard workspace with their appropriate containers, using fluent extensions for one example. Capture resized results and explain the choice for each region so the submission demonstrates reasoning as well as working layouts.

Give the console profile-aware behavior as well as flexible geometry. A phone needs a different way to reach navigation and editing, so this module connects client recognition to server-side presentation and workflow changes.

The resizable shell still tries to fit desktop navigation, cards, grid, and details onto a phone. Browser media queries can affect styling, but they cannot perform the shown server-control visibility and form-opening decisions by themselves.

Profiles are evaluated from top to bottom and the first match becomes active. They do not merge, so put narrow conditions before the broad desktop fallback; otherwise the broad rule can prevent later phone and tablet rules from ever being selected.

Set per-profile responsive property values in the designer for visibility, display, docking, size, and font. Hiding phone regions or moving tablet details below the grid belongs in those declared values when no procedural behavior is needed.

Use ResponsiveProfileChanged for behavior a property value cannot express, such as opening a modal editor or coordinating a delayed response. Choose the appropriate application or control event source, and keep this code focused on genuinely procedural changes.

Subscribe once, apply the active profile at startup, and apply the event's current profile when it changes. Guard against opening a second editor and unsubscribe during disposal so repeated notifications do not create duplicate windows or lingering handlers.

Compare a syntactically valid profile file with an incorrectly broad first rule against the narrow-to-broad version. The failure is ordering, not file syntax: phone and tablet variants must be tested before the general desktop rule.

Resize through desktop, tablet, and phone while reading the status indicator. Confirm that each profile activates its designed values, and that reaching Phone opens the modal editor only once rather than once per resize notification.

Deliver the six ordered profiles, designer-set phone and tablet values, and the profile-change handler with status reporting. Demonstrate the phone editor transition so the review verifies both declarative adaptation and the one behavior that requires code.

Review the finished Adaptive Operations Console as a product that must remain usable after future changes. The capstone checks accessibility, resize cost, and ownership of visual rules, turning a working demonstration into a maintainable responsive system.

The theme, semantic appearances, scoped styles, containers, and client profiles are already present. Now prove that they work together for every profile, with keyboard and touch access, reasonable resize work, and decisions another developer can explain.

Start with the theme and its appearance variants. Use cascading style sheets only where needed, then consider containers and responsive properties. Add profile-change code or custom profiles when simpler options cannot express the requirement, and document that reason.

ApplyProfile should return early for an unchanged profile and assign final values rather than toggling them. That makes repeated calls stable; cleanup removes subscriptions, while a shared focus frame preserves keyboard visibility across the theme's focused states.

Compare desktop, tablet, and phone views using the test-mode profile indicator. Navigation changes from text to icons to a menu, while details move from the side to below the grid to a modal, preserving access through different presentations.

Record six responsive test cases with expected profiles, screenshots, and checks for layout, scrolling, focus, invalid states, and touch. Repeat this matrix after theme changes and upgrades so regressions are compared against explicit expectations rather than memory.

Keep visible focus, supplement error colors with icons or messages, label icon-only actions, and walk the tab order. Review size limits and automatic sizing, then version theme, styles, and profiles together so accessibility and layout changes receive code review.

Make the grounding pack explain how to answer from course evidence and the ownership decision tree. Flag brittle internal document selectors and direct overrides, and request the actual profile and screen size when the responsive problem is not yet specific enough.

Hand over the finished console with its repeatable profile handler, test indicator, accessibility review, orientation matrix, architecture note, and grounding pack. Together these show not only that the current layout works, but how the next change will be evaluated.