When I sat down to write my yearly Automattic anniversary post, this is what immediately came to mind but extrapolated onto my work life: the complexity of working with some of the same people for 12 years, the weight of longstanding problems I’ve wanted to solve in our tech and our culture, the awareness of patterns (good, bad, and ugly) that swirl around creating avenues for momentum and strange dead ends, the ways I’ve changed along with the company and the people around me, on and on. I feel what it means to stay engaged for so long in a place that continues to shift and evolve. Some things that drove me wild in the first few years, no longer do and other things do even more. Like a friend who is always late, at a certain point it becomes a deal breaker, you plan around it, or you try to talk about it (again). I’m thankful for how much of a culture exists to “talk about it” at Automattic.

I’ve really tried to meet the moment of the last year: stepping up to lead WordPress 7.1, stepping into a PHP Foundation Board position, sharing my thoughts in a documentary, and authoring more PRs thanks to finding a groove with AI. It’s been enjoyable to be able to create and communicate better with the help of AI tooling yet it’s also been important for me to center and protect my humanness. A co-worker of mine made this fun GIF after the launch of 7.1 (it didn’t fully happen live but nearly did). If you look closely, you’ll see a determined relief on my face to have the release out in the world.

More than any work item this year, the biggest thing I’m proud of and still in awe of is my very first public interview about surrogacy where over a million people watched what I had to say. In the following week after that interview, my soul shook and I barely slept. What started as a website no one visited (surrogacy-stories.com) created this opportunity when a journalist reached out. Steady, vulnerable writing that few people read helped me sharpen my message, find other people born through surrogacy, and helped me speak to a perspective that’s missing. My experience doing podcasts, diving deep about controversial topics in the WordPress community, and bringing contributors together over big topics all served me so well when the interview arrived.

I’ve also prioritized sustainability and rest. I’ve said “no” to way more podcasts, panels, and speaking invites than usual. I went out of my way to spend more time with family and my partner’s family, both young and old. I’ve gone off the grid a few times, opting again for two weeks off all technology. I managed to read 8 books in that time period and I’m not sure the last time I’ve done that in a year with how much reading/writing I have to do day to day. I’ve taken full advantage of my healthcare after an emergency appendectomy and have so appreciated how much remote work has allowed me to be there for my partner who has battled so many health related things this past year. My partner and I took on a garden plot in Seattle and have worked hard to see so much come to fruition. Yesterday evening, I went over to the garden to weed and pick the fruits of our labor: numerous tiny tomatoes, chard, red onion, and a few carrots. A delicata squash, three zucchinis, lettuce, and more carrots are on their way as I write this. We’re both obsessed and nothing has been more helpful in the frenzy of AI slop to watch something slowly grow and to hold it in your hands. I took my mom and one of her best friends to Florence, balancing work and play part of the time. As I walked to coffee each morning, I marveled at how this could be my life and how amazing it felt to bring others with me. I nomaded more this year than usual and loved the chance to do so yet again.

It’s impossible for me to talk about working at Automattic without talking about what working at Automattic gives me in terms of a full life, time with loved ones, true rest, the opportunity to work with folks at scale on hard problems, and the chance to make a real difference on the open web.

Because it’s been so many years, here’s a list of all of my anniversary posts. When I look across a few of them, I see a pattern of gratitude more than anything and that is what still remains.

Problems

Simply put, notes are hard to discover, cumbersome to use, and tricky to track where and when they are left:

• Finding that you can add a note is incredibly difficult, requiring you to use the three dot menu in the block toolbar (related issue, related issue).
• Adding multiple notes to the same block is cumbersome, requiring you to use the three dot menu repeatedly or memorize keyboard shortcuts (related issue).
• The Notes sidebar can’t be open at the same time as Settings so you both have to switch back and forth and can easily miss notes are in the document (related issue).
• It’s hard to see when notes are attached to a block at a glance (related issue).
• When you open a post there is no way to tell whether collaborators have left notes since you last looked (related issue).
• There’s no way to suggest a text change, you can only leave a Note (related issue).
• I can’t customize how notes appear (minimize, expand, hide) when I’m writing (related issue).

Here’s a run down of how this shows up in the experience so you can visualize it. I used a real world example as the release coordinators I worked with 7.1 on used Notes in the final announcement post for the release to communicate with me and each other.

Opportunities

In the wide range of Phase 3 user research I’ve been a part of over the years, it’s become clear to me that notes, particularly with the added suggestion mode, covers a fair number of use cases organizations have when collaborating in a post. If in future version notes can be properly elevated in the interface to improve discoverability and ease of use combined with new features, like suggestion mode and emoji reactions, I think there’s a strong chance to provide a lot of value for our collective users. Here’s what this could look like for 7.2 based on what’s underway and what feedback we’ve gotten thus far:

• Elevate notes in the block toolbar to make it a more discoverable feature and easier to add multiple notes for the same section. This is a delicate balance! It shouldn’t be overly intrusive.
• Add different modes when suggestions are added so folks can easily switch between editing, noting, and suggesting.
  • Remember to think about other “modes” we might add, like responsive styling so there’s congruence in mental models.
• Ensure notes can appear, even when the settings sidebar is open.
• Add view options to customize how notes appear when writing, including minifying notes or hiding them.
• Add emoji reactions for more expressiveness and collaboration options.

Pulling together various in-progress PRs, here’s what 7.2 might look like. As you watch, I bet you’ll see many areas where we can make refinements to the experience and the good news is that we have time to do exactly that with beta 1 on October 20th.

What gaps do you see, in features or in refinement? What would make notes as usable as possible for you or your team? Bonus points if you open issues directly in GitHub. Shout to Adam Silverstein who is absolutely jamming on so many PRs to move this work forward.

• Fluid typography and spacing.
• Hide/show blocks based on viewport.
• Responsive styling.

More work is underway to add more supported styling controls and to convert some settings to style controls to expand what one can do with responsive styling. Tied to this, we need a UI for fluid spacing as only fluid typography exists right now in the Styles UI. These are all pieces rather than the whole though and looking at the whole of the experience is where the opportunities lie. Here’s a 3 min video of me showing what currently exists:

There are quite a few problems to solve within these different features:

• Adding more friction and visibility when you switch into the responsive styling options per this UX feedback. Right now, it’s subtle when you switch over.
• Clarifying when something has responsive specific styling. Right now, when you look at the options in the block settings, it’s not clear what specifically was changed for that viewport. This touches on how to show the hierarchy of styles and the various subset of issues within that.
• Tying together hiding/showing blocks with responsive styling. This might look like exploring when in responsive styling, the hide/show modal when you delete a block.
• Getting consistent with icons/notices/etc so there’s more of a shared sense of a system rather than just individual features.
• Determining what belongs (and doesn’t) in List View, considering hiding blocks shows up there but any responsive styling changes don’t. We don’t seem to have good consensus and this shows up in the current experience.
• Updating the component used for switching between responsive styling and previewing to add more distinction between the options. A PR is underway that’s a great spot to share feedback on how using a different component feels.
• Determine what “modes” are needed and whether to embrace that conceptually, especially when thinking about everything from responsive styling to the upcoming suggest mode and ensuring they appear where expected (I wouldn’t expect suggestions to be anywhere near responsive styling but I’d want the mental model to feel similar).

I’d love to hear what other people think, especially since responsive controls is a top requested feature and has been for years across the WordPress ecosystem. We have some of the building blocks and we need to iterate for 7.2+ to create something truly delightful.

I returned from Phoenix on Monday after staying longer to hang with my girlfriend’s grandparents who live there. Despite being 93, her two extroverted grandparents wear us both out in the best way. We took her grandma to see The Odyssey at her request. I snuck glances at her during the movie and cracked up when I saw her holding her sweater over her mouth, eyes darting back and forth watching the screen in equal parts shock and enjoyment. I very rarely go to the movies and I’m always struck by how intense of an experience it is. It’s always way louder than it needs to be and there’s something so all consuming about staring at such a giant screen. Every evening we did dinner with them and soaked up some new stories alongside some tried and true ones. I only was given a short list of tech related items to help with, including deleting nearly all of grandma’s photos from her phone despite my explaining she has room. We apparently share the same trait of enjoying cleaning something up (whether photos or tidying a room) and then repeatedly returning to see how good it looks. I’m in the process of doing that with my personal to do list this week too.

We returned to Seattle with our garden full of delicious veggies to eat and signs of more to come, like the delicata squash pictured below that’s slowly making its way into the world. Today, I nearly jumped out of bed at 5:30am to drive to Goat Lake trailhead to hike the five miles up to the lake, slowly eat a sandwich, and wood carve for a few hours before heading back down. I managed to finish up a leaf bowl I started a few weeks ago and carved a new spoon that has such a cool handle with a knot perfectly wedged in there. As I drove back through the woods, I blasted music and put all my windows down.

When I was back in cell service, I called loved ones and chatted with a few folks, finally feeling a return to some level of possible socializing after the marathon of last week. Still, I find myself quickly drained. Introvert recovery continues: I touch grass. I carve wood. I hike mountains. I hug trees. I lift heavy things. I water plants. I snap photos. I pick berries. I return to myself, slowly but surely.

This focuses on decisions made after the roadmap was shipped through to release day, listed from oldest to newest, with reasons listed below. I used AI to help compile this list from a combination of the #7-1-release-leads Slack, AI briefings I tried to get to work (it was a bust), and GitHub/trac activity. I’ll likely update this as I remember more items but, for now, these were the bigger decisions that had to be made.

Jun 19 — Ship the 7.1 roadmap.

• Beta 1 was less than 3.5 weeks away, and continuing to tinker with every detail had diminishing returns.
• The roadmap had already been through many iterations with squad feedback, and anything wrong could still be corrected after publishing.
• Decision: ship Roadmap to 7.1.

Jun 19 — Create a separate #7-1-design-assets channel for design work

• Design asset work (highlight grid, video featurettes, microsite) spans many avenues and would create noise in the main release channel, so I kept important release conversations in #7-1-release-leads while letting anyone join the design coordination as they liked.
• This was the first time we ever did release asset in a dedicated public channel. Usually this work ends up on GitHub issues, figma files, and in various calls or DM when we review.
• My hope in making it public is that we could get more perspectives and folks could see how much goes into the assets themselves.

~June 25 — shared a design direction for “Apply globally” with granularity

• After meeting with Aaron, a Gutenberg contributor, in person to talk through some of the 7.1 items when we had happened to be in the same place, I worked on navigating some design decisions.
• I opened gutenberg#79719 to test replacing the per-control “push to Global Styles” action with a granular review modal, in response to feedback that a per-control push felt risky by default.
• Aaron split the individual-style-pushing work into its own PR, gutenberg#79839, building on a DataViews-based approach suggested in gutenberg#49278 (comment). He then saw this through!

Takeaway: this is a great way for release leads to help make decisions while still ensuring the code is up to snuff.

Jul 3 — Confirm forcing the iframe for the post editor in 7.1, rather than the softer block-themes-only approach

• gutenberg#74042 proposed forcing an iframe for the post editor across all of 7.1. t-hamano pinged me directly as release lead, along with the tech leads and everyone who had worked on the effort, laying out the tradeoff: this PR enforces iframing everywhere, while the more cautious gutenberg#79819 would have enforced it only for block themes.
• My call, in this comment: “I assume if we proceed with this approach ahead of beta 1 and a lot of feedback is given after beta 1 that there are issues, we can move to the softer approach. Assuming that is correct, I am okay proceeding as is. I agree we’ve given this a lot of time.” The iframe editor had already been enforced in the Gutenberg plugin for months without major fallout, so I treated the harder approach as the default with a clear fallback plan rather than starting cautious.
• This is the technical decision behind the framing call I’d made on the public roadmap in mid-June: with the PR enforcing iframing everywhere rather than only for block themes, the “block-based themes in 7.1 only” language could come off the roadmap. PR #74042 merged the following week.

July 4 — Dialog and Marquee punted

• Not enough contributions and progress made for two easy decisions to punt the feature from the release.

~Jul 7 — Land the “Posts list: excerpt in Compact view” work as-is

• The design had gone through repeated back-and-forth with no resolution.
• I decided it was better to land what existed and adjust based on real feedback than keep debating it.

Jul 7 — Classic block stays in the inserter for 7.1 exactly as today

One of the takeaways is that the Classic block should become obsolete by choice, not by force. I believe time will be better spent to make the alternative genuinely better, while also smoothly, losslessly migrating content, so that users move off Classic block because they want to, not because the door has been removed.

From “The Classic block stays in the inserter for WordPress 7.1“

• The plan to hide the Classic block from the inserter was reverted, and the wp_classic_block_supports_inserter filter and its deprecation notice were removed.
• There’s a full announcement with details about why it was punted already shared.

~Jul 8 — Punt real-time collaboration (RTC) entirely from 7.1

• Scope and transport decisions were unresolved with feature freeze approaching, so a clean deferral was safer.
• This required talking with a large number of contributors to understand where we were, alongside talking with Matt himself. Beyond that, my leaning towards punting came from my own testing and understanding of our options.
• I confirmed this directly with Matt and announced it publicly on Jul 8. I tried to make this decision as early as possible to ensure we could focus on more realistic items to land.

~Jul 8–13 — no on the Knowledge merge proposal, no on AI Client streaming and embeddings

• Matt gave the Knowledge merge proposal a no, and I closed the loop with a public summary of the outcome. Merge Proposal: Expanding WordPress Core Abilities is the related public proposal thread.
• The main reason for the “no” is that the priority for Matt for AI work is around working on evals and benchmarking all the model makers use and target. This ties directly into WP Bench work. He also made it clear that he doesn’t want to put things into Core that aren’t already driven by real-world adoption with impressive week to week growth (think: double digits).
• php-ai-client streaming did not make 7.1, and the WordPress/ai embeddings PR #683 was punted after landing too late.

~Jul 10–14 — Bless a limited list of items for the beta period, scope Notes down, and punt suggestion mode to 7.2

• I pulled together a list of Blessed items to confirm with the release squad: Notes features, displaying inherited styles, and a handful of small revisions enhancements, all close to landing with buy-in from their feature owners. I reconfirmed this list unchanged on Jul 14.
• Confirmed the notes scope, including punting suggestions after a big refactor: @mentions, rich text, and @mention notifications, with emoji reactions, floating notes, and minified mode targeted at Beta 2.
  • Suggestion mode was excluded and punted to 7.2 because a recent major refactor made it too experimental and under-tested.

Jul 13 — Keep the “Add note” toolbar button out of 7.1, but land it in the Gutenberg plugin as an experiment

• gutenberg#78205 would have promoted “Add note” from the block toolbar’s overflow menu to a first-class toolbar button. Jasmussen argued the feature was ready for that kind of prominence, while Mamaduka pushed back that it would take up limited toolbar space for something most users wouldn’t touch.
• My call, in this comment: “I agree, let’s leave it out for now… I want to call back to this though and ask that we land it in Gutenberg sooner rather than later as an experiment to get feedback and make it more likely for 7.2.” With a whole cluster of Notes features in flight at once and not all of them going to land, I wanted one general place to gather feedback and iterate quickly rather than settling each toolbar placement question for 7.1 individually.

~Jul 14 — Punt the Abilities API follow-ups from 7.1

• I punted the Abilities API proposal, partially in light of the direction from Matt previously around AI features.

~Jul 14 — Punt the Table of Contents block from 7.1

• Aki handled this after no contributions moved this block forward.

~Jul 20 — Punt Unicode email address support to a community plugin

• Matt made this call on the proposal itself citing too vast of a surface area for security issues and added complexity, when we have more pressing problems to solve.

~Jul 23 — Defer the React 19 upgrade from Core 7.1

React 19 upgrade won’t be a part of WordPress 7.1. After briefly enabling it in Gutenberg we discovered unexpected incompatibilities in how old and new version of React interact with each other, and in the ways how plugins use React, and we were forced to revert the change.

From “React 19: punted beyond WordPress 7.1, experiment in Gutenberg“

• This decision was made by those who contributed to it and the work continues in the Gutenberg plugin. (#71336)

Jul 28 — Add a way to disable responsive styling, but don’t remove the feature

• Enterprise theme maintainers raised support-burden concerns in dev chat and asked for a pause or an opt-out.
• My call: “A way to disable is fine. I don’t think fully disabling it makes sense.” A full removal was disproportionate to the impact and desire for this feature. Aki built the disable mechanism, targeting RC1 at the latest.
• A way to opt out likely should have been done from the beginning as this is a common request in WordPress, even when a feature is long awaited.

~Jul 31–Aug 3 — Punt “displaying inherited styles”

• Disagreement persisted right up to Beta 4 and there just wasn’t a solid design direction we could land with enough time for proper user feedback.
• This followed the same conservative-scoping principle as the earlier calls when punting, and I wrote a retrospective on it so the squad could learn from the situation.
• This was another example where I tried to unblock things as the release lead by sharing various possible approaches to get consensus but, sadly, none of them ended up working out.

Aug 3 — Punt the “On this day” widget

• Outcome of my 7.1 review call with Matt: he didn’t think it was good enough and wanted it removed.
• I passed along the broader principle to the squad: what we don’t add is sometimes more valuable than what we do.

Aug 6 — Move forward with auto-approve self pingbacks

• After getting a late request from Matt, auto-approved self ping backs landed.
• I discussed the surface area of this change with a number of contributors and agreed that this would be safe to make an exception for this close to the release due to the limited impact and small amount of code.

~Aug 14 — Revert the toolbar focus/hover style change rather than ship it in 7.1

• Trac #65849 started as a report that clicking a toolbar item showed a focus outline that felt distracting. A fix matched the toolbar’s hover state to its focus state, which then drew pushback from several designers who argued it collapsed hover, focus, and “current page” into one confusing signal and introduced visible regressions in plugins like Yoast.
• Once the debate had run for several days without agreement, I made the call in comment:33: “My concern is the :hover rendering and the resulting visual changes in [63190], backported in [63201]. That landed on August 11 and I don’t want it to ship in 7.1.” I sent the improvement of the focus indicator itself to 7.2 (#65445, #65878) rather than trying to resolve the design disagreement days before release.
• The full toolbar focus/hover change was reverted in r63306, backported to the 7.1 branch in r63318, restoring the WordPress 7.0 appearance.

Aug 19 (release day) — Skip the live on-stage release at WCUS and publish the announcement post directly

The original plan was for Matt to accept the proclamation, do the release with slides and the highlight video ready, then start his session. As it turned out, Robert hadn’t seen the slides beforehand, and neither had I. A commit triggered auto-updates early, around 1:30pm MT, when only limited availability was intended (release visible via Downloads > Releases and wp-cli only). By the time I came out on stage, roughly 300K sites had already updated, and a WP Rocket fatal was already being reported and flagged in the release squad channel. Backstage, word came that Matt “doesn’t want to do the button,” which was ambiguous between not wanting to press the button himself and not wanting to do the release on stage at all. The real-time discussion with the release squad starts here.

I made the decision to publish, in this order of importance:

1. Matt clearly said no to the button, even if it was just for himself, and I didn’t want to push against that or make him repeat himself in the middle of a big task.
2. Auto-updates had been running for about three hours, so word was already out regardless of what happened on stage and I worried about the confusion that would happen if we didn’t proceed.
3. The original timeline, releasing right after the proclamation, was gone, and I had no way to know how long it would be until the release could happen.
4. Matt’s presentation didn’t seem related to the release as it went on, and I had no way to check what else it might cover.
5. I had no way to communicate with Matt to follow up or clarify in the moment since he was on stage.
6. All of this was happening at a rough time for APAC squad members, and I didn’t want to prolong things when all signs pointed to the release not happening on stage.
7. The presentation was already running 20 to 25 minutes late, and it seemed likely we would run out of time.

I explicitly owned the call: “I will own this decision if it ends up being wrong later.” I was eventually called on stage about 50 minutes after the original time. Lessons for next time: a new handbook page for running releases live at in-person events, and a triple-check or full run-through backstage before going on.

Testing in real environments matters a ton. It’s part of why this site is running the latest and greatest as are some of the other sites I run. You simply run into different bugs and points of confusion when you’re in the flow of using a product over doing artificial testing. At the same time, since I already have a number of real sites using the latest from 7.1, I wanted to also test scenarios I might not otherwise run into, like 100 revisions in a post or 3+ posts published in the same day appearing in the now punted “On this day” widget. Here’s a list of everything I ended up creating with studio with some bonus additional items I forgot to include:

• Create a plugin that registers icons into a collection as part of the updates to the Icon block.
• Mass import my photos from the photo directory to test the media library’s infinite scroll.
• Create a post with 100 revisions to test revision improvements.
• Create posts without titles to test excerpts displaying instead of just (no title).
• Create 5 posts that were written on today’s date to test the “On this day” widget.
• Create a post with attached images to test the ability to use attached images in a gallery block and insert them from a dedicated section in the Inserter.
• Mass generate comments with varying nesting levels to test re-parenting a comment.
• Mass generate Notes on a post to test @ mentions, in line notes, and rich text (not featured in the video below).

The possibilities are endless and this saved me loads of time! Time that I would have spent just setting up scenarios instead was spent truly testing. If you’re a nerd like me and want to help test, here’s a playground made from the above created WordPress studio site where AI did all the heavy lifting:

Happy testing!

Ultimately, this morning, the decision was made to punt the feature (link to the conversation in the release leads channel and a link to the GitHub thread). Here’s a re-share of part of what I said there: I’ll speak plainly and say that I am so frustrated we couldn’t get this in a better spot (not at anyone in particular, just at the reality of the situation). I really, really want our users to benefit from this landing. At the root of the reason why it didn’t land are a few things: lack of a solid design approach, lack of robust exposure and feedback from users due to it not landing soon enough, and lack of agreement on a way forward. What we did not lack is a willingness to try and experiment. Even if we have a strong idea that this would help users and are centering that, I would rather have more assurance it genuinely is helping in a way that makes sense. Similar to some extra Notes features, I hope to see this land in Gutenberg soon, perhaps first as an experiment to be extra safe. We can do a call for testing and get more direct feedback too.

With the above in mind, I wanted to preserve part of the journey of this feature partially to get any early feedback and partially to have a snapshot of the problems and solutions explored across a range of PRs.

About the feature

Since I ran the FSE Outreach Program back in the early days of the Site Editor, I heard feedback that folks couldn’t understand the hierarchy of styles. In some cases, I’d watch user testing where folks would style a template thinking it would automatically apply everywhere. In other cases, I’d watch people pick a style variation and then open block settings for an individual block in a template only to be confused not to find those styling options reflected in the sidebar. This longstanding problem has been something I’ve passionately wanted to see fixed for a long time.

At a high level, for this release, the full spectrum of the desired feature is to allow folks to see inherited styles reflected in the block settings, identify where they come from via breadcrumbs, override any inherited options, reset them back to inherited options when needed, and push any local overrides globally. This last aspect was actually split out into it’s own PR and approach here using a different approach separate from the overall feature for a simpler design, allowing it to land. The other aspects are what the rest of this post will focus on.

Evolution

Below is a look at an early version of what was developed with me talking through the default state and two options to show inherited styles: a blue dot and a diamond approach.

There are numerous issues with the above designs:

• The feeling of clutter/noise in the interface greatly increases.
• Debates over what’s better accessibility wise, a tooltip or infotip.
• Needing to make big exceptions to the overall design system per this comment.
• Severe layout constraints, considering the small space.
• The underline not clearly indicating a globally inherited value and not being very visible.
• Accessibility and design system concerns with the hover option also acting as a reset mechanism.

After beta 1, the problem then arose that a number of folks were on vacation this time of year or out for various reasons, hampering our ability to come together with enough perspectives. I noted this here as a risk. To keep working moving, I proposed two different possible ways forward:

Diamond with the ability to reset to inherited style

This option shows no indication of something inherited globally but it just reflects the styles you see in the canvas. If you override an inherited setting then a diamond appears to indicate an override (this should be a filled in diamond, sorry!). When you hover over it, you see an option to reset to the inherited styles. This reduces visual noise by not showing an inherited style while still allowing folks to see when they have an override and to reset to global.

Diamond with only a tooltip

This option also shows no indication of something inherited globally but it just reflects the styles you see in the canvas. If you override an inherited setting then a diamond appears to indicate an override. When you hover over it though, you ONLY see an indication that this local change is overriding global styles (copy is rough on this tooltip). To reset, you rely on the tools panel which we know is accessible and is a current known pathway. This is a more scoped down version of the former item in that it only shows a tooltip but without any ability to reset since that already exists in the tools panel.

This last option is what was then pursued in this AI generated PR from yours truly after being taken over by devs. This was possible to generate with AI thanks to the hard work to have a sound and robust technical approach by Aaron Robertshaw.

Exploring infotips rather than tooltips

During this PR, we went back and forth around tooltips vs infotips. Tooltips eventually won out but here’s a view of what the infotip component approach looked like:

Confusion around the reset method

Separately, within the comments of this PR, I noted a big drawback to losing the reset option baked into the same inheritance indication and shared the following video. Put simply, there are two different options to reset the values and it’s not clear why they are different:

This then led to, in some cases, a reset option being added separately to the controls as shown in this comment to help ease some of the confusion there for some of the options.

Adding back in breadcrumbs

Finally, after it felt like we were making headway with the above approach, I explored adding back in breadcrumbs to show where style options were inherited. This was built using AI and was made easy to do thanks to prior work by Aaron Robertshaw once more.

Lessons learned

Here’s what I learned in the process:

• Never lose sight of the overall user problem. Let that guide you to scope back solutions.
• Use AI once the foundation is built to explore many different options. Having clear visuals (even just videos) for folks to react to kept the conversation and ideas flowing.
• Land and debate pieces of work, while not losing sight of the spectrum of the feature set. This often helps find a way forward.
• Knowing a user problem deeply doesn’t replace user feedback on the solution at hand.
• Summer break in certain parts of the world at this time of the year is a real factor in planning for releases and needs to be considered.
• There are many considerations from performance to accessibility to design systems to navigate all at once. Seek those perspectives out and let them sharpen your approach.

Ultimately, I think this was the right call but it was extremely painful to make. On a personal level, I couldn’t shake not liking the diamonds in the interface nor how cluttered it looked so I’m excited to have more time to iterate, make it undeniably awesome, and land it hopefully for 7.2.

“In this world of numbness and information overload, the ability to feel, my boy, is a rare gift indeed.”

Patrick Ness

Ironically, I’ve been so deep in the release that I haven’t been able to share a recent short documentary I was interviewed for about open source. It was terrifying to be interviewed–I cried during parts and found myself deeply appreciative of the questions asked. I stumbled into open source. When I joined Automattic in 2014, I didn’t have a full appreciation or understanding, beyond knowing it was in our creed. Once I started to wrap my head around it, I couldn’t go back. I couldn’t unsee or stop knowing. Suddenly, I started to see all around me just how powerful of a concept it really is and how much is missed by not embracing a more open world. My hope in sharing the documentary below is that folks will watch it in order to get a better sense of why open source matters. Like everything, it’s not perfectly good nor perfectly bad but it does feel like a better way. I also still feel like I’m only scratching the surface of open source. It’s a similar feeling I get when talking to a queer elder who fought to have rights that I sometimes take for granted today.

I feel like I have endless things to say but that’s why tomorrow exists.

In many ways, this feels like a return to what I was doing 9-10 months ago with AI and it feels… right. I’m sure I’ll still contribute PRs here and there but it feels important to think about how best I can sustainably contribute in a way that’s best for the project. For this release cycle and my role in it, this has felt like the best use of time for all involved.

With that in mind, I wanted to share a few examples of what that collaboration has looked like, mainly to serve as inspiration after meeting with the recent AI Leaders graduates this week in Chicago. Bear with me as this is going to be deeply nerdy and detailed–happy to explain anything in the comments below. I am also going to skip over all of the wonderful contributions from everyone on the threads. Please go look into them! I mainly want to focus on how I’m approaching this to show how others might think to contribute.

Process

My process is very simple. I’m using Claude both in terminal and in CraftAgents to work with the PR locally. I make it clear that I am just wanting to work locally and I have no intentions of pushing any updates to it or creating a PR. I previously set up a dev environment so, if you haven’t done that, ask Claude to do it for you and point it at documentation, like wp-env.

Applying changes globally

One of the features for 7.1 shows inherited styles so it’s easy to see when a global setting is impacting the part of your site you’re working on. As part of being able to override those styles, an option was added to push an individual change to a block to the entire site. For example, you could change the font size of a paragraph and push just that font size change to all paragraphs on your site. The approach in progress showed two options every single time you made a local change to a block:

This means that every single time you make a local change and you go to reset it to the global option, you’d be presented with an option to also push the styles globally, separate from the overall “apply globally” option available under Advanced in block settings. In testing the PR, I couldn’t shake that this felt off and initially flagged it for design in this follow up comment. More time passed though and I kept thinking about it before deciding to try something different out that you’ll see below.

Design later reviewed it, said it looked good, and the dev working on the feature is in the process of adjusting the approach. Mind you there are loads of details to work out but this just saved likely hours of back and forth as well as waiting for design to review when I had an idea in mind that just might work.

Surface attached images in Inserter

Despite the concept of attached images existing for a long time, there hasn’t been an easy way to find them from the Inserter. To zoom out, adding seeing attached images is meant to help with two main flows: allow folks see what images are attached to a post and prioritize those for ease & allow folks to attach images to a post for use in the post itself (more newsroom style flow where someone uploads from a media library for someone else to then use that image in content). 7.1 has a dedicated area of work to improve this and a discussion broke out around how best to approach it. Here’s what the initial PR was looking like:

When I first saw this, the attached images section immediately overwhelmed everything else, including seeing the button for the broader media library. At the same time, there are real concerns that most folks may not quite understand the terminology. To try to address this, I offered an alternative UX approach using AI that simplifies things (and makes the images themselves bigger and easier to review): it takes the same approach the other options uses and just adds at the top an “attached images” option. See below:

You’ll notice there’s some jankiness but that’s by design. I’m not trying to have a code ready PR. I’m trying to communicate a way forward and this was a very fast way to do so. Amazingly, the same developer working on this feature already had a PR in that direction and this discussion helped us move towards it.

New image cropper

A call for testing went out for Media Editor Modal: call for testing that adds a free-form image cropper in the Block Editor along with other goodies. I regularly use our image tools to manage my photos so I am keen to see this land and to have it land in a way that feels delightful to use. In testing this out, I found myself again wanting to communicate not just in words what I want to see but in code. I left a comment and shared some still images (after I struggled to get this video to upload to Cloudup) of what I thought might work:

This has evolved so much since this comment over a month ago and I highly recommend folks go check it out/try it out.

What a good reminder to be careful for the full length of something. What a good reminder to be grateful for undo buttons, auto-saves, revision history. I spend so much time in a headspace where things can be fixed and iterated upon that I can feel the ways it bleeds into my carving. When you know something can be fixed later, it inherently changes you, even if there are very real consequences to needing to fix something. I wrote about a part of this four years ago: how great it feels to have to be at attention with something and how much I seek those habits out.

How would I be different if I were in a less forgiving area of work, like if I were the surgeon that operated on me? How would that shape how I live my life, what hobbies I seek out, how I treat others? In many ways, I can already be so rigid and more on the anxious side that it’s probably been a positive for me to work in a world with more room for gray, for trying and failing, and for seeing one’s work through the lens of relentless iteration. Growing up playing soccer, I had a coach yell at me about how after I missed a shot, I put my head down directly distracting me from the game unfolding before me. He taught me a valuable lesson in taking failure head on without blinking and being ready for the next moment after when things could change. I still struggle not to take myself out of the game when things go wrong and I still think about his words. This is also likely why I don’t enjoy golf which suffers from higher consequences when you miss than soccer. I feel the ways I need hobbies like wood carving to stretch me to pay attention differently.

I am also just frustrated with myself for creating yet another hole in yet another spoon. This is at least the second if not the third spoon I’ve done this to in the last year. While I end up giving the spoons away, my minimalist self laments the wasted wood and wasted effort. Why didn’t I pay more attention? What do I need to do differently? I thought I was slowing down, taking my gloves off often enough to really feel the wood and understand where more work was needed. If I’m doing this repeatedly with a physical object, what other holes am I creating elsewhere in my life without realizing? Not everything will be so apparent, especially if others are unwilling or unable to voice it to me and hold the mirror up.

Time to get back to it and not remove myself from the game for too long. Wish me luck. Perhaps the part of me that keeps trying after so many holes is the real part to nurture.