feat(web): redesign onboarding connect step as a cloud sign-in landing#4513
feat(web): redesign onboarding connect step as a cloud sign-in landing#4513elihahhahahah11 wants to merge 8 commits into
Conversation
Reworks the onboarding first screen into a centered cloud sign-in
landing: brand glyph, headline, one primary cloud sign-in button, and
two secondary links (local CLI / your own key) that each open a
dedicated setup page. Removes the AMR card + three-way runtime picker.
Also:
- Drop the three-step stepper across onboarding; Back link moved
top-left on every sub-page.
- Top-right language (compact, opens down-left) + theme (one-click
light/dark) controls; theme applies synchronously to avoid lag.
- About-you fields become flat tappable chips instead of dropdowns.
- Replace Marketing role with Marketing agency (pinned first).
- Cloud button is state-aware: shows Continue (signed in) when already
signed in and advances directly; shows a brief loading state while the
login status resolves (fetched in parallel on mount).
- Fix onboarding container height (100vh -> 100%) so the footer is not
clipped below the tab bar.
Adds onboardingCloud{Title,Body,SignIn,Continue,Alternative,Or,Rights}
i18n keys; renames onboardingRoleMarketing -> onboardingRoleAgency
across all locales.
lefarcen
added
size/XL
|
🧪 This PR changes a user-facing onboarding flow, so it will need a manual QA pass before merge — please hold off self-merging for now. We'll loop QA in once it's merge-ready. 💡 To drive this PR to merge hands-free, paste this to your AI coding agent (Claude Code / Codex / opencode / Cursor …): |
lefarcen
left a comment
lefarcen
left a comment
There was a problem hiding this comment.
Hey @elihahhahahah11, the user-facing walkthrough here is clear and the onboarding direction is easy to follow. Before pool review picks it up, could you complete the Surface area checklist and add a short Validation section with what you actually ran for this flow? That will make the design/QA handoff much easier.
The redesigned onboarding cloud landing shows a Continue (signed in) button when the user is already signed in, which advanced to the next step via setStep without recording any AMR entry attribution. Only the sign-in flow (handleCloudSignIn) recorded onboarding_amr_card / onboarding_amr_sign_in_continue, so already-signed-in users who clicked Continue were invisible to the AMR attribution funnel — systematically under-counting that conversion path. Record the same card + sign_in_continue entries before advancing so the two cohorts (fresh sign-in vs. already signed in) are attributed consistently. Runtime/mode/agent are already set to amr by the existing amrAgent effect, so this is attribution-only with no behavior change.
|
Thanks for the clear walkthrough here. The onboarding direction makes sense to me: making cloud sign-in the primary path and moving local CLI / BYOK into quieter secondary links should make the first-run flow easier to understand. Before UI review/sign-off, could you please add a few screenshots of the key states?
Since this changes the onboarding flow pretty visibly, those screenshots would make the design/QA pass much easier. Thanks! |
mrcfps
left a comment
mrcfps
left a comment
There was a problem hiding this comment.
@elihahhahahah11 Thanks for the onboarding refresh — I found one main-path regression that needs a fix before this is ready to merge.
🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.
Visual regression reviewHead:
8 changed · 29 unchanged · 0 missing baseline · 1 failed Changed cases
Capture or diff failures
Unchanged cases
Visual diff is advisory only and does not block merging. |
The already-signed-in Continue branch advanced without setting runtime, relying on the amrAgent effect to backfill runtime='amr'. If amrAgent hadn't resolved yet at click time, the onboarding_complete_result event could record runtime_type='none' instead of 'amr_cloud'. Set runtime/ mode/agent explicitly here (as handleCloudSignIn already does) so the completion event records the cloud runtime regardless of effect timing.
mrcfps
left a comment
mrcfps
left a comment
There was a problem hiding this comment.
@elihahhahahah11 I re-checked the onboarding cloud landing changes in the latest diff, especially the signed-in AMR fast path, the onboarding tab handling, and the new language/theme controls. The previous runtime-selection regression is fixed on this head: the signed-in continue path now pins the AMR runtime, daemon mode, and agent before advancing, so the cloud path stays aligned with the rest of onboarding. Thanks for tightening this up and for the thoughtful onboarding polish. ✨
🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.The connect-step redesign replaced the AMR runtime card + runtime picker with a centered cloud sign-in landing, so the onboarding suites still asserted removed UI (the /Open Design AMR/ card, AMR version text, the 'Sign in to continue' CTA, dropdown About-you fields). Remap to the new UI while preserving coverage: - AMR auth flows (pending/polling/cancel/error/timeout/recovery) now trigger via the landing 'Sign in to Open Design Cloud' button; assert 'Signing in…', the Cancel sign-in button, and role=alert errors. - 'Continue (signed in)' advances past the signed-in connect step. - Gate-tooltip coverage retargeted to the still-existing BYOK-unverified and Local-no-agent gates on the bottom Continue CTA. - About-you picks go through chip buttons (chooseChipOption) instead of dropdowns; analytics-payload assertions unchanged. - The two AMR-card skeleton tests now assert the surviving behavior: the landing stays usable during agent detection with no card/skeleton. apps/web suite: 334 files / 3333 tests green.
…suite The visual-entry suite waited on the removed runtime-selection surface (the 'Choose a runtime' heading and the .onboarding-view__amr-cloud-card model picker), so its precondition assertions failed before the screenshot — element(s) not found. Retarget the capture to the new Open Design Cloud sign-in landing (cloud CTA + secondary runtime links). captureVisual only writes an artifact (no baseline diff), so no baseline regeneration is needed.
mrcfps
left a comment
mrcfps
left a comment
There was a problem hiding this comment.
@elihahhahahah11 Thanks for tightening up the onboarding cloud landing — I re-checked the latest head and found one small follow-up in the onboarding tab chrome that would be worth addressing.
🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.The redesign replaced the AMR runtime card + runtime picker with the Open Design Cloud sign-in landing, so the shared gotoOnboarding helper (waiting on the removed 'Choose a runtime' heading) failed all tests. Remap to the new UI while preserving coverage: AMR sign-in/poll/cancel/ recovery now drive the landing cloud button; About-you picks go through chips; gates assert against the BYOK/Local panel headers. The three tests that exercised the removed per-runtime model picker on the connect card are narrowed to the surviving coverage (signed-in AMR completes setup / carries agentId 'amr' into the first run). 23 tests green locally via the Playwright harness.
…anding The packaged @electron-smoke onboarding specs probed the removed runtime-card DOM (.onboarding-view__amr-cloud-card / __alternatives / __model-picker, aria-pressed selection). Retarget the eval snapshot, type, validator, and click expression to the new cloud sign-in landing: the primary cloud CTA (.onboarding-cloud__primary) plus the two secondary runtime links (.onboarding-cloud__secondary), and add a Back (.onboarding-view__back-to-cloud) step so the smoke can expand BYOK then Local without the (landing-only) links. Verified via e2e typecheck; these env-gated packaged-Electron smokes run in the release pipeline.
mrcfps
left a comment
mrcfps
left a comment
There was a problem hiding this comment.
@elihahhahahah11 Thanks for the continued iteration here — the onboarding landing polish and signed-in cloud path both look much better on this head. I found one small tab-chrome follow-up worth addressing before QA leans on the onboarding route.
🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.The onboarding redesign hid the Search-tabs trigger button while onboardingActive is true, but the popover portal below rendered unconditionally on tabsMenuOpen. A popover left open across a route flip to /onboarding (e.g. browser back/forward, which bypasses activateTab/ createNewTab) survived as a stray 'Search tabs' dialog floating over the first-run flow with no visible control to dismiss it. Close the menu in an effect when onboarding activates, and gate the portal on !onboardingActive so it cannot render even for the frame before the effect runs. Adds a red-spec regression test (opens the popover, rerenders to the onboarding route, expects the dialog gone). Addresses reviewer feedback on PR nexu-io#4513.
mrcfps
left a comment
mrcfps
left a comment
There was a problem hiding this comment.
@elihahhahahah11 I re-checked the latest head across the onboarding cloud landing, the signed-in AMR fast path, the onboarding tab chrome fix, and the updated web/e2e coverage. I did not find any new correctness or maintainability issues in the changed ranges on 0cfa4ad. Thanks for the careful follow-through on the regressions and the test updates. ✨
|
Heads-up: draft PR #4206 is also open against the same onboarding surface. Both PRs touch You and @chaoxiaoche may want to compare approaches before more review time goes in here. We'll let the maintainer team decide which path should land. |
4 participants
Why
The onboarding first screen previously led with a runtime/AMR card and a three-way "select runtime" picker before users had any sense of what they were choosing. For the common case — sign in to the cloud and go — that is several decisions too many, and the dense card layout buried the primary action. This reworks the first screen into a single, calm cloud sign-in landing (LobeHub-style), and folds the local-CLI / bring-your-own-key paths into clearly secondary links so the default path is one click.
What users will see
Surface area
apps/web) — onboarding connect step (EntryShell),WorkspaceTabsBarfirst-run chrome.onboardingCloud{Title,Body,SignIn,Continue,Alternative,Or,Rights}; renamesonboardingRoleMarketing→onboardingRoleAgencyacross all 19 locales.CLI: not applicable — onboarding is a first-run web/desktop surface with no
odcapability equivalent.Validation
pnpm guard✅ ·pnpm --filter @open-design/web typecheck✅ ·pnpm --filter @open-design/e2e typecheck✅pnpm --filter @open-design/web test✅ — 334 files / 3333 tests green (includes the updatedEntryShell.onboarding,App.onboarding-amr-e2e, and a newWorkspaceTabsBarred-spec regression for the popover leak).e2ePlaywrightui/amr-onboarding.test.ts✅ — 23 passed against the local tools-dev harness.ui/visual-entry.test.tsretargeted to the cloud landing (capture-only, no baseline diff).@electron-smokeonboarding specs (mac.spec.ts/win.spec.ts) updated to the new landing DOM; validated via e2e typecheck (they run in the release pipeline).onboarding_complete_result.runtime_typeis reported only after the connect gate is satisfied (signed-in AMR / selected local agent / verified BYOK); the already-signed-in Continue path now pinsruntime='amr'so it recordsamr_cloudcorrectly.Full CI passed green on a prior head of this branch (all non-skipped checks).