Windows UI redesign: Fluent Inspector design and phased implementation #110

Screen-led review with small semantic jobs

Actual proposed UI screens are now attached to every review job, in addition to the earlier structural flowcharts. There are 19 semantic jobs: 18 new leaf issues under coordination epics #111–#115, plus the existing coherent optional layout job #116. Do not implement an entire epic in one pass.

Start with #117 (Korean/English typography), not all of #111 at once. Review one screen and its job-specific question, record agreement, implement/verify that job, then discuss the next. All jobs are awaiting discussion. A mockup interaction is not approval.

Viewer screen context

Comparator screen context

These are UI illustrations with synthetic imagery/sample values, not implemented native screenshots or literal current-build before/after captures. Each leaf issue identifies its narrow change boundary and unchanged behavior. Verification jobs depict targets, not new product UI or successful test results.

Working source of truth: use the GitHub leaf issue for the screen, agreed decisions, scope, implementation and verification evidence. Local Markdown is supporting design reference; mirror agreed changes where relevant instead of maintaining a competing approval record. Keep discussion in chat or issue comments, then record the conclusion on the corresponding issue before implementation.

Images and editable source are on a documentation-only branch. This planning work does not change application code or authorize a master merge/release. The detailed specification below remains the shared contract.

Visual walkthrough and discussion

Every stage now has a visual walkthrough and discussion questions. Review one stage at a time before implementation; the diagrams are proposals, not proof that the app has changed.

Schematic only: these diagrams explain structure and behavior, not exact pixel geometry, font rendering, or an implemented Windows screenshot.

flowchart TD
  FIRST["Start with #117: Korean/English typography"] --> REVIEW["Look at the picture and discuss this stage"]
  REVIEW --> AGREED{"Design agreed for this stage?"}
  AGREED -- "Not yet" --> REVISE["Revise the picture and specification"]
  REVISE --> REVIEW
  AGREED -- "Yes" --> IMPLEMENT["Implement this stage on a focused branch"]
  IMPLEMENT --> VERIFY["Build and verify the affected workflows"]
  VERIFY --> PASS{"Checks pass?"}
  PASS -- "No" --> FIX["Fix the regression and re-test"]
  FIX --> VERIFY
  PASS -- "Yes" --> RECORD["Record evidence, then discuss the next stage"]
  RECORD --> NEXT["Focused jobs within #111–#115"]
  NEXT -. "Separate follow-up, not a first-release blocker" .-> LATER["#116: multi-row comparison"]

Historical phase-level discussion prompts (reference)

• Discuss Windows UI redesign: Unify Korean/English UI typography #117 (typography) first; do not assume its appearance choices are approved merely because the roadmap exists.

• For each stage, record agreed choices and any changes before implementation. Completion and release authorization are separate decisions.

Reference status: use the focused leaf-job questions above for approval. This phase-wide material is not one implementation job.

Problem

Q1View's Windows Viewer and Comparator need a coherent visual hierarchy without losing their precise image/video/RAW inspection workflows. Recent improvements already introduced Pretendard, typographic folder cards, multiline folder names, multi-selection, drive-root navigation, and stable drawer toggling. The redesign must unify these strengths rather than replace them with a photo-library or dashboard interface.

Proposed solution: Fluent Inspector

A quiet, content-first Windows workspace with discoverable commands and readable technical information. Premium appearance comes from consistent typography, alignment, restrained color, and predictable behavior. Keep the approved Bright Sky Q1 application icon.

Scope: Windows MFC Viewer and Comparator only. Do not redesign the Qt viewer, change the rendering/metric algorithms, or migrate to a new UI framework as part of these issues.

Design baseline: master commit 7b8d50f57eb0738d85d73aeba86c05f94120a4a9 / v2.7.26, reviewed on 2026-10-03. Implementation branches must start from the latest origin/master, not assume this historical baseline is still the tip.

Phased implementation

Complete and verify small changes before taking the next stage. Do not mix cosmetic changes with unrelated decoding or comparison-engine work.

Initial redesign and release-readiness scope

• Windows UI redesign — Foundation epic: three focused jobs #111 — Phase 1 — Shared visual tokens, typography, DPI/theme services, and command definitions.
• Windows UI redesign — Viewer workspace/Browse epic: four focused jobs #112 — Phase 2 — Viewer command/status bars and Browse navigation/selection.
• Windows UI redesign — Viewer inspection/input/feedback epic: five focused jobs #113 — Phase 3 — Viewer Info, contextual controls, dialogs, feedback, and keyboard/accessibility integration.
• Windows UI redesign — Comparator presentation epic: three focused jobs #114 — Phase 4 — Comparator headers, A/B scope, metric presentation, and analysis states.
• Windows UI redesign — Verification/readiness epic: three focused jobs #115 — Phase 5 — Cross-application regression verification, documentation, and release-readiness review.

Separate structural follow-up

• Windows UI redesign — Phase 6 follow-up: Comparator 2×2 and multi-row layouts #116 — Phase 6 — Comparator multi-row layouts: 2×2 plus explicit 1×4 compatibility.

Phase 6 is not a prerequisite for the initial redesign release. This parent tracks the whole roadmap and may remain open after the first redesign release. Arbitrary comparison pairs, Swipe/Blink/Heatmap, and new metric algorithms require separate proposals.

Execution order: #111 → #112 → #113 → #114 → #115. #116 is a separate structural follow-up after the core verification gate, not a release blocker.

Each implementation issue must record its branch/PR, completed acceptance checks, known limitations, and any new regression. Do not close an implementation issue based only on a mockup or a successful build.

Detailed visual specification

1. Aesthetic decisions

• Retain Pretendard; improve role sizes, weights, line spacing, DPI handling, and alignment instead of replacing an already approved font.
• Use opaque neutral work surfaces. Avoid excessive card outlines, oversized headings, dashboard panels, and colored decorations.
• Reserve blue for focus, selection, and one primary action in a local action group. Folder names and normal values are not all blue.
• Keep images rectangular and unaltered: no UI tint, rounded crop, decorative shadow, hover brightness, or crossfade.
• Keep native Windows title-bar behavior, Snap, system dialogs, and accessibility contracts. Optional Mica is a frame-only enhancement with documented runtime support and opaque fallback, not a dependency.
• Light and Dark use the same layout and interaction meanings. Dark does not dim image pixels or the C/D panels.

2. Color tokens

Default app theme: System, with explicit Light and Dark choices. Canvas brightness is a separate preference.

Use semantic colors only for actual states, with text/icon cues. A normal Recycle Bin command is not a permanently red primary button. High-contrast mode uses Windows system colors instead of forcing these HEX values.

Canvas presets: neutral default #303030, dark #181818, light #ECECEC, all with R=G=B. Transparency checkerboard is a display option and must not silently alter capture/export/comparison buffers. Diff markers may use #FF80B5 plus a contrasting outline/shape and a Diff label. Channel plots need channel labels and distinguishable line patterns, not color alone.

Calculated sRGB contrast for the specified pairs:

These are design calculations, not a full application accessibility certification. Verify actual foreground/background pairs in every state. Target 4.5:1 for ordinary text and 3:1 for essential non-text identification; decorative dividers need not meet the latter if identification does not depend on them.

3. Typography

Use the bundled Pretendard Variable for Korean and English UI. Retain Windows glyph fallback for missing scripts/emoji. Use Cascadia Mono, or Consolas, only for precise aligned numeric data.

Synced, Current frame, View only, and Move to Recycle Bin remain UI-font text. Do not use monospaced text just because it is English. Normal selection counts use 14/20 rather than large headings.

App-drawn menu buttons/panels use Pretendard. OS-owned title bars, native popup menus, file dialogs, and Properties dialogs may follow Windows fonts. Do not force a full owner-drawn menu rewrite before preserving Alt/menu navigation, UI Automation, text scaling, and high contrast.

Use role-based DIP sizes consistently across GDI and DirectWrite. A 14 DIP size is not 14 points. Scale geometry with DPI and Windows text scaling; the default heights below are minima, not ceilings. Do not shrink labels to fit narrow windows or apply negative tracking to paths and mixed-script names.

4. Geometry and responsive behavior

• Base spacing unit: 4 DIP; normal gaps 8/12/16/24.
• Standard command bar: minimum 44 DIP; Compact: minimum 36 DIP.
• Standard command button: minimum height 32 DIP, horizontal padding 8; Compact minimum 28. Aim for effective 44×44 touch targets without enlarging all visible icons.
• Icons: 16 DIP normally, up to 20 for dedicated panel controls. Keep the approved application icon; do not fake a larger native caption to enlarge it.
• Status bar: minimum 24 DIP, 12/16 text and 4 DIP vertical padding.
• Browse: default 280 DIP, range 240–440; Info: default 280, range 260–400. Respect saved user widths.
• Panel padding: 12 DIP. Section spacing: 16 standard / 12 compact. Thumbnail gaps: 12 standard / 8 compact.
• Buttons/inputs radius: 6 DIP; tiles: 4; popups: 8. Main images and comparison boundaries remain straight.
• Dividers: 1 DIP visually; resizer hit area approximately 6–8 DIP.
• Use the existing MFC/GDI/D2D/DWrite structure and a consistent production icon family. Preserve required icon/font license notices.

Viewer client area excludes the native title bar. At default scale, 1440×900 with two 280 DIP side panels leaves an 880×832 DIP canvas; 960×600 with Browse leaves 680×532; 640×480 leaves 360×412. Optional media controls reduce canvas height further.

At about 1200 DIP and above, both side panels can be shown; at narrower widths, show one supplemental panel at a time. Keep the last-used panel, retain saved widths/preferences, and do not unexpectedly reopen panels when widening a window.

Command overflow is based on measured strings and actual scale, not only fixed breakpoints. At wide widths show File/View/Tools, Open, Browse, Fit, 100%, Scaling, Compare, Info. Move Scaling/Compare first when space is limited. Around 640–899 DIP retain File, Open, Browse, Fit, 100%, Info, More. Do not automatically add a second native-app command row or reduce font sizes. The conversation mockup's 320px reflow is not a proposed mobile product.

5. Viewer behavior

Default view: file association opens image-first with Browse and Info closed. Keep zoom/Fit state distinguishable and show only useful read-only status. Empty state: Open an image or video, Open files, Paste image, and a drop hint; no mandatory home dashboard.

Browse: title/count → parent/path → List/Gallery and thumbnail size → items → local selection actions. Selection changes must not add a global banner that resizes the canvas. Breadcrumbs preserve the current folder when ancestors collapse; an editable full path needs conflict-checked shortcuts and Esc cancellation.

Parent navigation is visible and continuous: D:\00\_temp → D:\00 → D:\ → drive list. Every real folder and drive root keeps [..] as the first item. Drives use [C:\], [D:\]. Preserve existing UNC-root behavior without introducing automatic network discovery. Failed navigation retains the existing folder/image and reports the attempted path.

Folders retain typographic [name] cards, not decorative folder illustrations. Initial Gallery folder height is 116 DIP, label padding 8, font 13/18. Left/top-align folder names; center only [..]. Use all available height for wrapping, then ellipsize only the final visible line. Do not globally impose two/five lines. Expose the full name through tooltip and UIA.

Thumbnail filenames are visible by default, normally two lines with final-line ellipsis. Names can be hidden, but current/focused/selected filenames remain discoverable through a detail/accessibility path. Initial thumbnail display should show full contents (Contain); tile cropping never changes the main image transform.

Preserve existing preview eligibility: Gallery omits non-preview documents/archives/etc.; List still exposes all files. Keep supported-image decode failures as identifiable unavailable previews. Empty Gallery distinguishes No previews in this folder from an empty folder and offers Switch to list.

Separate three states: current open image (small current marker + accessible status), multi-selection (accent boundary + subtle fill + check), and keyboard focus (2 DIP outline + offset). They may coexist. Hover does not change selection or apply image effects.

Single click selects, double click/Enter opens. Preserve Ctrl/Shift/range anchors and exclude folders/parent items from file batch deletion. Show Compare selected files only for 2–4 eligible media files. For >4, hide Compare and explain the limit. Keep only genuinely applicable multi-selection commands; do not expose single-file Properties/Open/name-copy as if they operate on the entire selection. File clipboard operations and image-capture Copy remain distinct.

Use Move to Recycle Bin, count-aware confirmation, safe initial Cancel focus, and accurate partial-failure reporting. Do not promise an unimplemented Undo or permanent deletion.

Info: separate File / Input / Display / Pixel. Distinguish source Y/U/V from display R/G/B; unknown values are —. RAW controls only apply to relevant inputs; playback/frame timeline only appears for video/sequences. Pixel overlays use compact opaque neutral plates that do not cover the inspected point.

6. Comparator behavior

• Default A/B side-by-side panes with equal width, 1 DIP separator, minimum 48 DIP source headers, 28 DIP A/B markers, 12/16 role labels, and 13/18 filenames.
• A=Reference, B=Compared. Show actual synchronization status, not a decorative Synced label.
• Minimum 72 DIP metric row: actual A/B scope and Current frame / ROI / Sequence average, then actual values. Use 16 DIP numeric values and 12 DIP channel/unit labels.
• PSNR includes channels and dB, with meaningful infinite/unavailable cases. SSIM/LPIPS are not fabricated quality percentages.
• Pending/preparing/calculating/stale/cancelled/error are distinct from completed results. Do not display zero or an old-frame value as a new calculation. Do not invent progress percentages.
• Still images start without a temporal graph. Sequences expose frame controls, progress, and a collapsible graph, initially about 144 DIP high, with meaningful units, frame/time axis, current position, and unfinished regions.
• Current metric/difference scanning scope remains A/B only. C/D are View only and their image pixels remain unchanged.
• 2×2/1×4 layout generalization is a later structural task, with panel coordinates/drop/focus/ROI synchronization tests. No arbitrary pair-selection UI until the engine actually supports it.

7. Feedback, input, accessibility, performance

Use sentence-case command labels and clear error/loading messages. Custom command items start at 32 DIP height, 14 DIP text, 16 DIP icons, and 12 DIP horizontal padding; native menus follow OS behavior. Preserve Alt menu navigation.

Theme/appearance settings are separate from rendering/input interpretation. Loading/failure feedback must distinguish file loading, missing previews, inaccessible folders, analysis setup, and partial Recycle Bin failures.

Modal/text/IME input takes priority over global commands. Single-letter shortcuts such as E must not fire while typing; collection/graph arrows keep local meanings. A user input executes exactly one command. Owner-drawn controls need UIA name/role/value/selection/focus/enabled state; do not announce every pixel hover.

Limited hover/popup transitions may use 100–160ms with reduced-motion handling. No drawer slide/refit animation, pixel crossfade, decorative idle paint timer, or metric/decoder restart.

Non-negotiable regression contracts

• E performs one atomic final layout change, ignores held-key repeat, never advances a file/frame, and restores appropriate focus.
• Fit refits once for the final viewport; small images normally stay at 100%. Manual zoom/pan preserves the inspected screen anchor with only necessary clamping.
• Theme/panel changes never alter source pixels, ROI, sampling, HDR/HLG display policy, captures, or metric input buffers.
• Retain bounded CPU/GPU thumbnail caches and visible-first loading; do not decode an entire directory for appearance changes.
• Preserve the same-folder multi-image sequence-detection optimization (see Windows Comparator: avoid repeated sequence scans and decoding when opening multiple images from one folder #107).
• Preserve path-based selection across external directory changes and accurate batch operation results.
• DPI/theme changes and GPU resource recreation preserve data, current file/frame, selection, scrolling, and comparison state.
• Keep native dev-version generation vs tagged CI-version behavior. Do not hardcode a release version for the redesign.

Verification and rollout

Test Windows client sizes 640×480 / 960×600 / 1440×900 DIP; DPI 100/125/150/200%; Windows text enlargement; monitor changes; Light/Dark/System/high contrast; long Korean/English/mixed-script names.

Verify image stability, drive/UNC traversal, 1/2/4/5/many selections, directory watching, partial Recycle Bin failures, same-folder multi-file opening, RAW/YUV/Pixel Exact/ROI/A-B metrics/LPIPS states, focus/IME/UIA, and GPU recreation.

Compare performance with a recorded pre-change baseline on the same machine/files/cache conditions. Separate decode waits from UI feedback. A roughly 100ms feedback target is an initial design goal, not a measured guarantee.

For implementation changes, follow AGENTS.md: locate VS2022 MSBuild with vswhere if necessary, generate the local dev version using Write-Q1ViewVersion.ps1, build/run CoreRegressionTests and build both Windows Release solutions. Fix discovered regressions before marking a phase complete.

Only after the core phases pass: update USER_GUIDE and relevant Store listing/changelog text, review release scope/version, and obtain release direction. The GitHub Actions release workflow remains the authority for tagged packaging/signing/Release/Store submission. This planning issue does not trigger a tag, release, or Store publication; a major bump is not automatic.

Design assets and status

Local design files were prepared at docs/design/desktop-redesign-2026-10-03/: README.md, VISUAL_SPEC.md, and q1view-redesign.html. They are currently local/untracked, so this issue deliberately contains the specification rather than linking to nonexistent files on master. Include the reviewed assets in an appropriate documentation/foundation PR when implementation starts.

The mockup demonstrates image-first browsing, selection, two-file comparison, and the future four-pane layout. Its reused example photos and sample metrics are illustrative, not measured results or new Windows app screenshots. Specified color-pair calculations and mockup interaction checks do not replace native Windows implementation verification.

Alternatives considered

• Immersive photo-player UI: useful for fullscreen, but hides RAW/frame/metric controls.
• Always-open editor workspace: useful for technical work, but too dense for ordinary image viewing.
• Heavy glass/gradient treatment: rejected for work panels because stable image judgment and rendering behavior are more important.
• Full WinUI migration / owner-drawn native-menu rewrite: not required for this staged MFC redesign.

References

• Fluent 2 color, typography, layout
• WCAG text contrast and essential non-text contrast, used as design principles rather than a desktop certification claim
• Windows Acrylic guidance
• Adobe Bridge interface preferences