Skip to content

UX iteration for the title generation experiment#290

Open
juanfra wants to merge 5 commits intoWordPress:developfrom
juanfra:tweak/title-generation-ux
Open

UX iteration for the title generation experiment#290
juanfra wants to merge 5 commits intoWordPress:developfrom
juanfra:tweak/title-generation-ux

Conversation

@juanfra
Copy link
Member

@juanfra juanfra commented Mar 10, 2026

What?

Improves the UX of the title regeneration modal by simplifying the selection interface and adding the ability to regenerate options without closing the modal.

Why?

The current flow has different textareas with selection buttons, which made the interaction feel heavier than it needed to be. On the other hand, users had to close and reopen the modal to get new suggestions. Creating unnecessary friction when none of the initial options worked.

How?

  • Simplified the selection UI to radio-style choice cards (inspired by shadcn's ChoiceCard component, adapting to the block editor's design language)
  • Added a "Regenerate" button directly in the modal so users can go through suggestions without closing.
  • Updated the modal title to "Select a title or regenerate for more options" to make the flow clearer.
  • Added proper loading states during regeneration (with disabled controls)
  • Auto-selects the first option after regeneration

Testing Instructions

  1. Create or edit a page.
  2. Click on "Regenerate title" via title toolbar
  3. Verify the modal opens with title "Select a title or regenerate for more options"
  4. Confirm three title options appear as choice cards with radio buttons
  5. Verify the first option is selected by default
  6. Click different options and confirm selection changes visually
  7. Click "Insert" and verify the title is inserted, and the modal closed.

Repeat the same and click on "Regenerate" inside the modal to trigger the regeneration without needing to close the modal.

Screenshots or screencast

generate-title-ux.mp4
Open WordPress Playground Preview

@github-actions
Copy link

github-actions bot commented Mar 10, 2026

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: juanfra <juanfra@git.wordpress.org>
Co-authored-by: dkotter <dkotter@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@codecov
Copy link

codecov bot commented Mar 10, 2026

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 58.72%. Comparing base (5bbb6db) to head (e7dc2b1).

Files with missing lines Patch % Lines
.../Experiments/Title_Generation/Title_Generation.php 0.00% 1 Missing ⚠️
Additional details and impacted files
@@              Coverage Diff              @@
##             develop     #290      +/-   ##
=============================================
- Coverage      58.74%   58.72%   -0.02%     
  Complexity       573      573              
=============================================
  Files             37       37              
  Lines           2950     2951       +1     
=============================================
  Hits            1733     1733              
- Misses          1217     1218       +1     
Flag Coverage Δ
unit 58.72% <0.00%> (-0.02%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@juanfra
Copy link
Member Author

juanfra commented Mar 10, 2026

I'll be fixing the tests.

<Modal
title={ __( 'Select a title', 'ai' ) }
title={ __(
'Select a title or regenerate for more options',
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personal opinion but not sure we need to be this verbose in the modal title. Should be pretty clear that a user can regenerate titles with the regenerate button so I'd suggest just leaving this as Select a title or Select title

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. I was trying to add a more intentional title. Will go back to Select a title.

flex: 1;
}

.components-textarea-control__input {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My concern with these styles is while it makes it look nicer, it's now not obvious that it's a textarea you can click into to edit, which is one of the goals with this UI, provide the ability for someone to edit a suggested title prior to inserting it. Wondering if there's a way to have the UI look nice but still make it obvious the title is editable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. I was actually wondering if we need the textareas to be editable here at all, that's why I intentionally styled them this way.

My concern is it might create confusion. Not sure what the user expectation would be if they regenerate after they modified some suggestions. My thinking is that editing belongs in context, in the actual title field where it'll live, and the modal should really about choosing from suggestions.

But maybe I'm missing something. Is there a specific reason we want editing to happen in the modal rather than after insertion?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was part of the initial spec for the experiment (see #10).

I can't speak directly to the reasoning behind that though I see both sides. For me personally, I'd want a flow of generating titles, choosing the one that matches closest to what I want and then editing it in the actual editor. But I do think there are others that will generate titles and if they don't see one that matches exactly and there isn't an obvious way to edit that first, they'll just discard those rather than inserting first and then editing it.

So the intention here is to not force editing to happen in this preview state but giving that as an option allows users to decide if they want to edit then insert or insert then edit.

.join( ' ' ) }
onClick={ ! isDisabled ? onSelect : undefined }
>
<input
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the new OpenAI provider, it will only return a single result. In that scenario, this checkbox isn't needed. Wondering if this needs to be more flexible so we don't show a checkbox if we don't have multiple results?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. If there's only one result, we probably don't need the radio at all.

@jeffpaul jeffpaul modified the milestones: 0.5.0, 0.6.0 Mar 12, 2026
@jeffpaul jeffpaul mentioned this pull request Mar 18, 2026
33 tasks
@dkotter dkotter modified the milestones: 0.6.0, 0.7.0 Mar 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Needs review

Development

Successfully merging this pull request may close these issues.

3 participants