Offer the free-key link inline with the API-key sheet's rationale - #106
Draft
aurpsis-aai wants to merge 1 commit into
Draft
Offer the free-key link inline with the API-key sheet's rationale#106aurpsis-aai wants to merge 1 commit into
aurpsis-aai wants to merge 1 commit into
Conversation
A keyless user reading "Blurt needs an AssemblyAI API key" now finds "Don't have a key? Get a free one" in the same breath, as a text link, instead of having to spot the "Get a Free Key" push button down in the action row. The link opens the dashboard's key page and leaves the sheet open behind the browser, ready for the paste; it stays hidden once a key is stored. The button row is now a plain Cancel / default-action pair. Co-Authored-By: Claude Fable 5 (Jeeves) <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
This PR improves the API-key entry sheet UX by moving the “get a free key” affordance into the rationale text area as an inline, link-styled control (shown only before first connect), and simplifies the sheet action row to just Cancel + default action. It also adds a UI test to ensure the link is present only in first-connect mode.
Changes:
- Updated
APIKeyEditorSheetto show a link-styled “Get a free one” button inline under the rationale when no key is stored, with a more descriptive accessibility label. - Simplified the sheet’s button row by removing the prior leading “Get a Free Key” button.
- Added a UI test validating the link is shown only before the first successful connect.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| App/Blurt/Blurt/Wizard/Steps/APIKeyStepView.swift | Moves the “get key” action inline under rationale as a link-styled SwiftUI Button, and simplifies the action row. |
| App/Blurt/BlurtUITests/SettingsUITests.swift | Adds a UI test to verify the get-key link appears only in first-connect mode. |
Suppressed comments (1)
App/Blurt/BlurtUITests/SettingsUITests.swift:157
- Same issue here: asserting against
reopened.buttons[...]can be brittle if the link-styled control is not surfaced as a Button element type. Match by identifier across element types usinganyDescendant(identified:), and usewaitForExistence(expectingfalse) so the assertion can’t pass just because the view hasn’t finished building yet.
XCTAssertFalse(
reopened.buttons[UITestIdentifiers.apiKeyGetKey].exists,
"A stored key means the user has found the dashboard — no link on rotate")
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+146
to
+148
| XCTAssertTrue( | ||
| sheet.buttons[UITestIdentifiers.apiKeyGetKey].waitForExistence(timeout: 5), | ||
| "The first-connect sheet should offer the get-a-free-key link") |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
In the API-key entry sheet, a keyless user now finds "Don't have a key? Get a free one" as a text link directly under the rationale sentence ("Blurt needs an AssemblyAI API key to transcribe your speech…"), instead of the "Get a Free Key" push button that sat at the leading edge of the button row.
Buttonwith.buttonStyle(.link)so it reads as a link but remains a button element for XCUITest and VoiceOver; carriesaccessibilityLabel("Get a free API key")so the label is self-describing when reached via rotor/Tab, where the "Don't have a key?" prefix isn't read.Why
Where to get a key was the sheet's least discoverable affordance: the answer to "where do I get one?" lived in the action row rather than with the sentence that raises the question. Link styling also matches what the control does — navigation to the web, not one of the sheet's commit-or-cancel actions.
Destination note: key generation lives on the dashboard's API-keys page (the playground pages under
/dashboard/playground/*have no key-generation UI), so the existingAPIKeyStore.dashboardURLtarget is kept.Testing
testGetKeyLinkShownOnlyBeforeFirstConnect: link present on the first-connect sheet, absent after a key is stored.swift format lintclean on both files; macOS HIG review pass done (link-vs-button semantics, placement, accessibility label).checkis the build/UI-test gate.🤖 Generated with Claude Code