Editor: Add compact notes mode for Notes sidebar#74985
Editor: Add compact notes mode for Notes sidebar#74985
Conversation
Add a "Compact notes" preference toggle in the View menu that collapses floating Note threads into small avatar indicators. This reduces visual clutter while maintaining awareness that feedback exists. Features: - Toggle in Options > View menu to enable compact mode - Collapsed state shows single avatar with unread indicator dot - Hover/focus expands to show author name and timestamp - Click expands the full thread inline - Keyboard accessible with proper ARIA attributes Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @justinemshields. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +472 B (+0.01%) Total Size: 6.84 MB
ℹ️ View Unchanged
|
annezazu
added
[Type] Enhancement
|
Thanks, @annezazu! I think this is a nice start. A couple of surface notes, before I do a full review:
Pinging more folks for feedback, @adamsilverstein, @jasmussen, @t-hamano |
|
Good call with the unread indicator. I took the design too literally. I’ll update to remove the unread concept for now when I have time. Should I wait for more comments on the component piece or shall I implement what you shared? Cc @Duthie for thoughts here too. |
If you have time, I think we can move forward with the current feedback + fixing the lint issues. |
packages/editor/src/components/collab-sidebar/minified-thread-indicator.js
Outdated
Show resolved
Hide resolved
packages/editor/src/components/collab-sidebar/minified-thread-indicator.js
Outdated
Show resolved
Hide resolved
- Consolidate MinifiedThreadIndicator into Thread component with variant prop - Remove separate minified-thread-indicator.js file - Remove unread dot indicator (no actual unread tracking exists) - Use human-readable relative timestamps (e.g., "3 days ago") Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Alright! Did another round of updates. Recap:
Here's a look: Screen.Recording.2026-01-27.at.3.11.56.PM.movKeep the feedback coming! |
There was a problem hiding this comment.
I was expecting less duplication when suggesting a new variant prop for the Thread component.
There's nothing wrong with duplication, but we'll end up maintaining some crucial logic (interactions, a11y) in two places, which can result in variant behavior being out of sync.
Update
Pushed b4815c0 as an example of what I had in mind for simplification. I think there's more room for improvement.
I've also noticed that after you click the compact note, the focus is lost when it's expanded.
Screencast
CleanShot.2026-01-28.at.13.31.53.mp4
|
For some reason—but this happens in trunk too—I'm now getting JS errors when trying to add a comment. Any ideas? Based on the videos, this looks like a promising start. I would love to have tested this with a site that doesn't have a white background color: for me it's still critical that these notes feel like part of the canvas (i.e. same background behind the notes "margin" as in the main canvas), as the metaphor is that of grammar, notes your teacher would add to your essay: underlines, scribbles in the margin, and so on. I also think we need something other than a top level menu item preference called "Compact notes", that seems to have WAY too much prominence for something that on the majority of your posts and pages won't even have a visible effect on yoru document. It can be a preference under appearance, but I also wonder, is it even a preference at all or is it simply that the Notes tray is collapsible? Like this: 
I don't mean to be a blocker to necessarily land this, and in general I'm not against adding options. For me that's about meeting people where they are. But in this case, I'm genuinely unsure if this is a toggle, or just a collapse button in context of the Notes tray. I can see you collapsing/expanding depending on your mood, which speaks more to the collapse button than a set and forget toggle. |
Unfortunately, I'm unable to reproduce the error. The notes e2e tests are also passing, so it might be a local issue.
I think it's a good starting point, though I agree it's too prominent for a similar feature. I like the idea of a collapsed sidebar; we already have something similar for metaboxes. Though I wonder which option is better for discoverability? |
|
I think the discoverability issue is not really the issue to optimize for here, because it is already related to notes which is an important, but still secondary feature to blogging/writing/site building. The problem is, these options accumulate and come with a hidden cost: every item added to the menu reduces the value of every other option already there through the added cognitive overhead. It's a delicate balance that isn't easy to measure. But it's why I would put this option anywhere else than where it currently is. Can be inside the Preferences modal, or it can be a collapse button in the canvas as noted. |
This seems like a genuinely useful feature to add. At a minimum, we could highlight notes that were new or had a new reply (added since the last time the user edited the post). This would only require tracking the last time the user opened the post. I will open a new issue to discuss this feature since I didn't see it anywhere.
Noting that in Google Docs the compact mode is an option under View->Comments (minimize comments): 
One other possibility would be to automatically enter the compact mode when the size/number of comments results in overflow (eg. notes longer that editor canvas). I'm not sure how users would react to this, but it would lead to the feature being used when its most useful (and would help with discovery). |
|
Thank you for helping with this PR @Mamaduka!
I totally agree with this and we need to be careful. In terms of addressing this feedback, in trying to create a toggle for notes, I'm finding it to be pretty finicky space wise, if we use the same design as metaboxes. The toggle overlaps with the notes themselves. If I then move it to the top left, it looks very out of place. toggle.for.notes.movMy preference for now would be to add it to Preferences > Appearance and iterate on an in the experience expand/collapse option in another PR. What do you all think? |
I created this issue to consider tracking unread notes so we could potentially add an indicator: #75026 |
What about putting a dropdown below the existing notes icon that could switch between note modes (collapsed, floating, sidebar) similar to Docs View->comments menu? 
|
Oooh, I personally really like that idea! We'd need to figure out how the overall interaction is meant to work though as right now, selecting that, opens and closes the Notes: notes.icon.movPerhaps, it's a drop down to show all notes, minified, and expanded? |
|
Here's a hacked together "design" for now as food for thought: 
Alternative phrasing: 
|
|
Messing around more while I have time and this actually works pretty darn well: notes.notes.notes.movWhat do you all think? Great thinking, Adam. I haven't pushed the code yet but I can so folks can play around and review. |
Thanks for mocking that up! I like it overall, curious to see how others feel. One UX note, the menu should disappear once a selection is made - in the screencast, it looks like it is requiring an extra click (maybe thats just because its a mockup?). |
|
That's actually in code! In this case, I am matching the experience to the View menu. Here's a comparison: matching.menus.movI think this should be the same for consistency but can be argued out of it :) I can push this to the PR if folks want. Just lmk. |
|
Update: I changed the setting key from
If there are blockers, they are probably:
|
From my opinion, which folks should feel free and empowered to dismiss, no—the point is to give you more space, if it doesn't, there's reduced value to it. |
|
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 Unlinked AccountsThe following contributors have not linked their GitHub and WordPress.org accounts: @justinemshields. Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases. If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
In this PR (or even when "Hide notes" becomes available) I think the answer is "no", perhaps later if that's more clearly warranted but for now I do not believe we need to persist the mode.
Before we get that into this or a separate PR, I think we need to first address the resizing-the-tray concern so that Compact Notes can land (and if in the intervening time Hide Notes becomes available in this PR or a separate one then great they can all land together). |
|
@jasmussen back to the blocker here:
Do you feel that the description in #64664 (and perhaps the existing, related PR #70616) best describes the UX and overall approach that would allow Compact Notes to then collapse the size of the sidebar/tray to allow for more space within the editor frame? If not, mind calling out what's missing so we can iterate there? But if that issue/PR appears good to you, then I'll shift over to trying to help get reviews and testing on that PR. |
|
An entirely different approach would be to render floating notes on top of the canvas without using the sidebar API, i.e., by reserving a small area for floating notes on the right side of the canvas. This approach was proposed here. #66377 (comment) However, this has some technical challenges, and it's unclear if it will be ready in time for 7.0. |
No. I'm unsure about landing 64664 myself: there are knock on effects about rearranging the componentry inside and how it would wrap. It's not at all a strong opinion, if there's a great PR that solves it, it can land. But notably I think of that as sidebars, I still think of notes as content—notes, grammar, suggestions, linting pieces related to the content of the document, and that those sit in the margin of the doc, not a sidebar. I realize I speak in very conceptual terms here, but I feel like the distinction is important looking further ahead. And yes, I could see the margin being resizable, and even collapsible, just like how Docs apps have a vertical separator with a small chevron arrow on it that lets you collapse it situationally. It's the same here. I really don't want to suggest blockers. While I myself question the value of compacting the notes without freeing up the space, if there's for example an easy followup in the beta phase that can address it, it can still be valid. But I do really read the purpose of "compact notes mode" as a way to improve the available space usage: if it doesn't do that, it's more of a distraction free visual change and I would actually tie that to DFM instead of make it a separate option. |
I'm separating the 7.0 timing from this feature, while I'd love for there to be :alot: that gets into 7.0 its more important to me that what lands is solid. Plus, even in missing 7.0 but landing in a Gutenberg release after still gets the functionality out to folks who'd want to use it; no real loss there in my opinion.
I feel like I've heard this similar concept from you a couple times / in a couple places, so looking to explore that a bit here. Let's assume that there are existing plugins that interject grammar, spelling, suggestions, linting, accessibility, etc sort of recommendations/updates to content in custom sidebar panels in the editor as well as within the pre-publish panel. Would you want to see much of that migrate into an experience that's more inside the content/margin and not in the sidebar? If so, I don't know that we have anything yet within Gutenberg that's expressed in that manner (as Notes exist more like a sidebar than in-content). So perhaps the next exploration would be to get Notes (and then perhaps Compact Notes) more in-content and out of a sidebar?
This is an interesting idea, though I wonder if Compact Notes in DFM would deter from what I infer as the core purpose of that mode which is to "just focus on writing" aka authoring and not worry about editing in that mode. If that's not aligned with the product/design thinking, then yes perhaps Compact Notes makes sense (only?) in DFM. |
|
Thanks for asking that question. Some of my thinking is spread across a lot of different issues and comments, it can be hard to make them all cohere, so let me break it down a bit:
The "Annotations API" as it was called when work started several years ago, was always meant to be a way for users to attach comments on a per-selection basis, and back then, sidebar vs. bubbles were also discussed. Aside inspiration from adjacent collaborative docs apps, what it always came back to was maintaining context: inside a sidebar tray, bubbles are sequential, and get pushed down and lose context. Maintaining visual context was one of the key values that "connected bubbles" could bring. That's really at the root of my own thinking about this: essays you give to your teacher come back with similarly contextual comments: notes in the margin, wavy underlines, strike-throughs and injected words. It may not be the perfect metaphor, but it does explain why I feel there's a connection to grammar tools. That may become even more true with RTC support, and may answer your question around plugin APIs. I'd love to invite a grammar agent to give me feedback, suggestions, or other corrections to my doc. Take this PR, it shows "user awareness", consider one of those users a grammar agent instead. Block level comments exist. Inline level comments are being worked on. Suggestions is a natural next step. That's where you'd change mode from editing (or only have suggestion privileges on your user level), to make edits that aren't actually applied but instead each of them add the suggestion as a bubble. A mode switch could be a new menu item, with these being rough sketches of what menus could become (beware, drafts, not really ready for anything but "dreaming"): 
How would a suggestion look like in the canvas? One option quickly put together, and subject to all feedback, but should come as no surprise: 
Note here also how it shows both the in-canvas bubbles, and the document inspector. I acknowledge the Notes tray currently uses the sidebar API, and the benefits this brings. And whether it continues to do so I'll ultimately defer to developers to decide. But it doesn't seem useful to necessarily limit explorations to the shortcomings of said API: either it's worth expanding, or perhaps notes is something else? For example taking that same design one step further, with compact notes included, here they are, simply collapsed with the chevron: 
Every existing grammar tool that uses the existing sidebar plugin API would be able to do that. But the concept of dreaming up the ability to add agents that can apply suggestions, make inline markings, add comments or otherwise, seems like a nice possibility to boost options available. The idea is: we build these tools as collaborative options. And each of them would then also become available to non-human collaborators. The benefit is, it could go further still. We’ve needed a linting interface for documents for a long time. Maps block missing API key? Dead link? Empty image block? Block has custom CSS? We’ve been over unread dots, flags in the list view, pre-publish dialogs. Those can all still be valid, but nothing has felt quite obvious enough. As of 6.9, blocks can be hidden, and when they are hidden, they are truly hidden, not just dimmed. This is to maintain WYSIWYG, which is especially important in 7.0 where not only can blocks be hidden (omitted from the published content), but they can be hidden responsively—e.g. invisible just on Tablet and Mobile, visible on desktop. Being able to resize the canvas and see how the layout actually changes between breakpoints affirms the need to be true to WYSIWYG with block hiding. But how do you then know which blocks are hidden? Or have responive properties? There needs to be an at-a-glance indicator of these things. With all I outlined above on using the Notes tray as a way to surface notes and suggestions in a way that is accessible to humans and agents alike, it feels only reasonable to expand that to include also linting notes such as just that: block visibility notes. 
So many aspects of what I shared here are just ideas, proposals. I expect lots of details to surface as we move forward. But what I find so important is to connect these disparate ideas, see if they can combine. If we do it right, instead of a dozen small features that live in isolation, we have one coherent interface that connects them all. |
I've read (and re-read) @jasmussen's thoughts above, spent some time trying to come up with other UX solutions for how/where Notes render (and generally only came up with "left side of canvas sidebar" as a functional difference) and how we could show Notes-adjacent content (e.g. dead links, accessibility errors), and generally continue to come back to the existing UX is fairly sufficient (especially when the Notes tray can collapse to the compact view).
So perhaps the best place to prospect for ideas and iterations next is potential technical solutions that allow for something more on-canvas in-the-margin and not in / using the sidebar? cc: @ellatrix @t-hamano @Mamaduka @adamsilverstein (as folks who've help lead efforts on Notes) |
|
Coming back to this after time off and a big thank you to everyone who has worked on this while I was out. I really was hoping to see this land for 7.0 but I respect the process and the complexity involved.
To me, yes. When I'm writing content and collaborating with others, it's helpful to get rid of the extra "noise" having the content of the comment visible adds. It's a way of simplifying the interface to return to edits before opening back up again to engage. Compared to the current UX, I think this PR is markedly better but I am very biased. Right now, every time I click on the Notes icon as is, I'm confused by what's being displayed in the sidebar. It's not clear as is that it's showing all notes whereas this adds some nice friction to better explain that as well as bringing a new feature in the form of compact notes. In my mind, we could ship this version for 7.0 and then iterate for 7.1 in having a collapsible view that automatically shifts things in and out of a minimize/expanded version. I'm light on the technical details though so please tell me immediately if that's absurd thinking 🙃 . |
|
If we could add a "Hide notes" mode, I think it would be more worthwhile to ship this PR. What do you think? There may be times, especially on smaller screens, when you want more width for your content. Another suggestion is to NOT persist the mode setting and not save user data to the database. This means that the mode will be initialized on browser reload, but it avoids the issue of keeping that data backwards compatible in the future. |
Do you mean add that as an option along with the rest (Show all, Minimize, Expand)? If so, yes I agree.
I'm also game for this to preserve flexibility in the future. Good thinking and thank you for helping here. |
|
Update:
I think the behavior is similar to Google Docs. Let me know what you think! 1e063bfe19c529c47be3e8226cede17d.mp4 |
|
The display mode toggle looks nice, but it doesn't solve the main issue with compact mode. Even when compact mode is enabled, the sidebar remains the same width. I think "Hide Notes" mode can be shipped separately as a small bugfix/improvement. |
|
Flaky tests detected in aaf9f0e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/22137207623
|
I disagree. From the original issue created for this:
I think we can ship this and iterate for 7.1 to have a resizable sidebar as noted above. |
github-project-automation
bot
moved this to 🔎 Needs Review
in WordPress 7.0 Editor Tasks
t-hamano
moved this from 🔎 Needs Review
to 🗣️ In Discussion / Needs Decision
in WordPress 7.0 Editor Tasks
|
Before deciding whether to ship this PR, we might need to do some prototyping and feasibility audits to see how notes work in a narrow sidebar and whether floating notes on canvas is really possible. |
|
Coming back to this PR and thinking about 7.1, I've also explored adding filtering to the Notes panel in a new PR based on what Jay shared above. I still think this PR stands for 7.1 potentially as well since the new PR just touches the "All notes" and I do think this is a step in the right direction before bigger changes. If it's resizable sidebar or bust, I will need to pass that off to someone else to do considering what @t-hamano shared above about the sidebar being hardcoded and a potential private API being necessary. |
8 participants
Summary
Closes #73417
This PR adds a "Compact notes" preference that collapses floating Note threads into small avatar indicators, reducing visual clutter while maintaining awareness that feedback exists.
Video walkthrough
compact.notes.PR.mp4
Test plan
Of note (get it), @t-hamano https://github.com/t-hamano/notes-data-generator helps to test this as you can quickly add multiple notes from many users.
🤖 Generated with Claude Code
Open questions to answer
cc @WordPress/gutenberg-design in general for the above.