Page MenuHomePhabricator

Always-visible Feedback button (encouraging beta-feedback modal) (!56)
Closed, ResolvedPublic

Description

Scope: Add an always-visible "Send feedback" button anchored mid-right of the viewport that opens a modal letting the user submit free-form feedback either as a Phabricator task or as a section on User talk:Daanvr on Commons. The button frames the tool as in beta to encourage feedback.

Background

T426408 (v0.28.0) already shipped most of the plumbing in src/ui/error-report-modal.jsx for the error-report flow on the hard-error panels:

  • A modal that captures context (timestamp, version, deploy target, URL, user agent, plus a free-text comment), shows an editable preview body, and offers two window.open submission paths: pre-filled Phabricator task (maniphest/task/edit/form/default/?projects=tool-upload-workbench&title=&description=) and the talk-page edit form (commons.wikimedia.org/w/index.php?title=User%20talk:Daanvr&action=edit&section=new&preloadtitle=, with the body copied to clipboard since MediaWiki's URL pre-fill for body content uses preload= and won't accept a literal multi-line string).
  • No new OAuth scopes (everything is a window.open user gesture).
  • Accompanying CSS in src/app.css:4104-4174 (.error-report-modal*).

This task reuses that infrastructure for the always-visible feedback flow.

Differences from "Report this error"

  • Trigger: floating fixed-position button, not only shown on error.
  • Pre-fill: drop timestamp, error message, stack trace. Keep version + deploy target + current URL for context (handy when feedback references "I clicked X on this page").
  • Copy: encouraging "we want your feedback" framing, not "report this error".
  • Beta framing: button label/styling and modal copy say "Beta — your feedback is valuable" so the affordance feels welcoming, not error-prone.

Affected code

  • New: src/ui/feedback-button.jsx (floating button + thin modal wrapper, sharing the URL-builders from error-report-modal). Likely cleanest is a new src/ui/feedback-modal.jsx plus the button component, both imported (regular ESM, like the existing src/ui/ modals).
  • New CSS rules in src/app.css (a .feedback-fab floating-button block + a .feedback-modal* block — or share .error-report-modal* styles where possible).
  • Mounted from src/main.jsx (or src/app.jsx) at the same level as the topbar so it's visible regardless of route/state.

Behaviour

  • Button is fixed-position on the right edge of the viewport, vertically centred (top: 50%; transform: translateY(-50%); right: 0;). Renders as a vertical pill with text "Feedback" or "Send feedback" + a small "Beta" indicator.
  • Visible always except when a modal is open (z-index lower than .modal-backdrop so the backdrop covers it; or hide via body[data-modal-open] if simpler).
  • Click opens the feedback modal:
    • Title: "Send feedback"
    • Lede: short encouraging copy noting the tool is in beta and any feedback (bugs, suggestions, confusing UI, "I wish it did X") is welcome.
    • Comment textarea (the actual feedback) — required-ish (button greyed out if blank).
    • Editable preview body — same pattern as error-report-modal: derived ## Feedback heading + comment + a tiny context table (Time, Version, URL).
    • Two submit buttons: "Open Phabricator task" (window.open to maniphest create) and "Post to User talk:Daanvr" (window.open to talk-page edit + clipboard copy of the body).
  • Mobile/narrow viewport: keep button on the right edge but consider hiding the text label and showing only an icon at narrow widths (≤640px) — pure CSS via media query.

Acceptance criteria

  • Floating button visible mid-right on every screen of the app (login, bootstrap, main view, error panels).
  • Button visually signals "Beta" (chip / tone / label).
  • Click opens a modal with encouraging copy and a comment textarea.
  • Both submission routes work (Phabricator task pre-fill loads with title/description; talk-page edit form loads with section title pre-filled and body on clipboard).
  • No new OAuth scopes.
  • No regression to the existing error-report flow on <BootErrorPanel> (T426408).
  • npm run build (incl. undefined-identifier scanner) passes.
  • CHANGELOG.md has an [Unreleased] entry under Added.

Event Timeline

Daanvr moved this task from To do to Doing on the Tool-upload-workbench board.

Grooming pass (AI)

Description rewritten with investigation findings (see task description above). Original preserved here verbatim:

A Feedback button always visible in the middel right side of the viewport. using modal to post a message to my talk page or as a task to fabricaor.
the text should be encouraging the user to give feedback. what ever feedback the user thinks is relevant.
the button should indicate it is in beta and therefore that much more valuable to get feedback.

Daanvr renamed this task from Feedback button to Always-visible Feedback button (encouraging beta-feedback modal).Fri, May 15, 7:10 PM
Daanvr updated the task description. (Show Details)
Daanvr renamed this task from Always-visible Feedback button (encouraging beta-feedback modal) to Always-visible Feedback button (encouraging beta-feedback modal) (!56).Fri, May 15, 7:18 PM
Daanvr moved this task from Doing to Reviewing on the Tool-upload-workbench board.

nice! lets move it to the top center of the page and keep it sticky always in sight.
And lets try to enrich the text further with relevant context for trubelshooting bugs or so. and lets ad some inspirational questions fo the user to guide the user to the right a rich and complete bug description of it is about a bug.

no changes visible in the frontend. of !56
this feedback still aplies:
nice! lets move it to the top center of the page and keep it sticky always in sight.
And lets try to enrich the text further with relevant context for trubelshooting bugs or so. and lets ad some inspirational questions fo the user to guide the user to the right a rich and complete bug description of it is about a bug.

Address-feedback round 2 on !56:

  • Pill repositioned to top-centre (was mid-right). .feedback-fab now uses position: fixed; left: 50%; top: 8px; transform: translateX(-50%) and a rounded horizontal shape — sits inside the topbar area on the main app, standalone at the top of the viewport on the login/boot-error screens. z-index 110 still sits between the topbar (100) and the modal backdrop (150).
  • Inspirational-question scaffolds added above the textarea — clickable chips that insert a small Markdown scaffold at the cursor position ("What I was doing\n…", "What I expected\n…", "What happened instead\n…", "How to reproduce\n1.") so a user who isn't sure what to type still ends up with a structured bug report.
  • Type of feedback selector (Bug / Suggestion / Question / Praise) — drives the heading, the placeholder, and the scaffold set. The Phab task title is prefixed with the type so reports triage at a glance.
  • Richer auto-attached context for troubleshooting: build/version + deploy target + URL (existing) + user agent (restored), viewport size, browser language, IANA timezone, ISO timestamp + signed-in username, current stash/history item counts, and any load errors from this session. Exposed via a tiny window.uwbDiagnostics() getter from <Bootstrap> so the modal can grab a snapshot at open-time (and gracefully degrades on the login screen where there's no diagnostics).

MR: https://gitlab.wikimedia.org/daanvr/upload-workbench/-/merge_requests/56
Preview: https://upload-workbench.toolforge.org/mr-56/

Lessons learned

  • Shared-helper DRY opportunity exists for follow-up. The feedback modal reuses the v0.28.0 "Report this error" window.open plumbing (Phabricator pre-fill + User talk:Daanvr section-new flow) but does so by copying the URL-construction code rather than extracting it into a shared helper. With two callers in tree and a third anticipated for any future "report" channel, this is now worth refactoring — a small src/ui/report-channels.js (or similar) wrapping the URL construction and clipboard handoff would tighten both call sites. Not blocking, but worth a follow-up task.
  • Re-test the preview after every feedback round. This MR went through three review rounds (top-centre move; richer context + prompts; feedback-type radio). Mid-cycle pushes didn't re-exercise the live preview between rounds, so visual regressions could have slipped through the textual diff. For UI MRs with multiple iterations, walking the preview after each push (not just after the first one) is cheap insurance.
  • Mount at <Root> (outside <ErrorBoundary>) to survive boot/render crashes. The FAB is intentionally outside the error boundary so users can still file feedback when the main app has crashed at boot. window.uwbDiagnostics is a clean way to publish current state to a sibling-of-Root component without prop-drilling — that pattern generalizes to other always-available widgets (status badges, etc.) but should not be abused for application state.