RFC-140: Updating categories in the editor's element browser

[DavidMichelson]

RFCs are a way for Atlassian to share what we’re working on with our valued developer community.

It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.

Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!

Project Summary

We are planning on updating the categories in the editor’s element browser (both the slash menu and view more modal) to make discovering app macros & other elements easier for users. We wanted to give the developer community a heads up and open up discussion for feedback.

• Publish: 21 July 2026

• Discuss until: 28 July 2026

• Resolve by: 4 August 2026

Problem

We want to improve the discoverability of all elements within the editor’s element browser (both the slash command menu, and the view more modal). Today:

• The slash menu version of the element browser is one long, continuous list without clear categories or grouping to help users browse it.

• The view more modal version of the element browser does show categories, however, the categories themselves are outdated, and don’t well enough reflect our offerings.

Element browser - Slash menu

Element browser - View more modal

Proposed Solution

We plan to:

• Update the set of categories we have to better capture our shared offerings.

• Update the slash menu to actually show the categories.

• Update the view more modal to show the new categories.

• Cosmetically modernize the slash menu and view more modal.

Existing category names

• Rovo
• Formatting
• Confluence content
• Navigation
• Admin
• Reporting
• Development
• External content
• Media
• Visuals and images
• Communication

Proposed new categories names

• Recommended (This category will be curated by Atlassian, and have 5 items max, always showing the next category above the fold).
• Structure (contains elements like Action item, Table, Status)
• Media (contains elements like Image, video, or file, Link, Emoji)
• Embed (contains elements like Google Drive, Figma, Dropbox)
• Text formatting (contains elements like Bullet list, Heading 1, Quote)
• Rovo (contains elements like Ask Rovo)
• Data and charts (contains elements like Database, Jira work items, Child items)
• Block templates (contains Block templates)
• Other elements

Examples of new categories in the slash menu

Examples of new categories in the view more modal

How would this affect apps?

Only apps using macros would be impacted by this change. Furthermore, no work is required in response to this change (unless you’d like your app macros mapped to a different category - read on to learn more).

Apps using macros today can define a categories property (string[]) that lists out all of the relevant categories a macro is using. The value of this property determines where the macro will be shown in the view more modal version of the element browser. For example, if a macro’s categories field included media and development, that macro would show up in both of those sections in the view more modal. See documentation on categories here: Macro.

When we move to the new categories listed above, we will map existing categories to the new categories. See the table below for proposed mapping.

Macro with these existing categories	Would be shown in this new category
Formatting Confluence content Navigation Admin	Structure
Reporting Development	Data and charts
Media Visuals and images Communication	Media
External content	Embed
No categories listed	Other elements

We will also make any new categories applicable to app developers (i.e. excluding Atlassian-native categories like Recommended, Rovo, and Block templates) valid inputs within the categories property. This would add the following valid inputs for the categories field.

• structure

• embed

• text-formatting

• data-and-charts

Recommended, Rovo, and Block templates will not be made into valid inputs as they are Atlassian-native categories. Media is already an existing category, and Other elements will be reserved for apps with no categories listed.

If you would like your app to appear in a different category than it would be mapped to by default, you can update your category before the rollout.

Timelines

Our goal is to release the above changes to categories by the end of September 2026.

Asks

• Do you have any general feedback on the new category mapping?

• In the future, to further clean up the element browser, we are considering only allowing app macros to live in one category (vs. multiple categories today). Do you have any feedback on this idea?

• Is there anything else we’re missing that may impact apps?

[nathanwaters]

“Recommended” should instead be “For You” so that those five macros are personalised to the individual user based on some simple algo that includes most/recently used and suggested.

Atlassian has this tendency everywhere to say something is “curated” but in reality it ends up being some static list that serves interests other than the user’s.

eg the Marketplace homepage always shows the same dozen apps. The “recommended apps” in the lefthand sidebar always shows the same few apps. Is the goal to signal to the open market that Atlassian’s offerings are frozen in time?

[janette]

Hi,
I suspect that Structure category will end up being too wide, because it folds Confluence content and Navigation together. When an app like Refined Macro Toolkit is installed, the Confluence content category already becomes scrollable. How many items do you expect to live in the Structure category, on average?

Admin is a category I have never seen. Is it an active category today.

Last thing: will a macro still be able to exist in multiple categories, the way it works today?

[scottohara]

I like the addition of categories to the slash menu, but I wonder if it creates a perverse incentive for every app to put themselves in the Structure category so they appear higher in the list?

I can’t recall how the current slash menu is sorted, so maybe it’s not creating any new incentives, but just something that sprang to mind when thinking about the proposed change.

[DavidMichelson]

Thank you for your feedback! Definitely understand your concern. We expect ~30 Atlassian native items to live in the structure category at a minimum. But, from our internal testing, with the new category names + slimmer menu items, the scrolling becomes a lot less ‘painful’ – and can easily scale to have many more items in the category.

Admin is a valid entry to the categories field, but it is a lot rarer for apps to live in that category.

A macro will still be able to exist in multiple categories upon initial release – although, we are considering making it so macros can only live in one category, to clean up the element browser and reduce duplicate items - especially in the slash menu. Do you have any additional feedback on that future consideration?

[DavidMichelson]

Thank you for this feedback! We definitely recommend app vendors to use the category that makes most sense for their app, as users may scroll by the app entirely even if it’s in a higher-up category, if it doesn’t match what the use case they’re looking for is.

[DavidMichelson]

Thank you for this feedback, Nathan! For our initial release, Recommended will be curated by Atlassian – but in the future, we are very interested in experimenting with combining curation and usage-based ranking (e.g. popular within your site, or items you use often). We are strongly intent on keeping the Recommended section up to date, as it’s such a key part of editing flows.

[DavidMichelson]

@nathanwaters @janette @scottohara and any other developers reviewing this RFC, we would also love feedback on another approach we considered for categorizing app macros in this new element browser experience.

We could introduce a new “Apps” section to the element browser that would contain all app macros. This could be sorted as follows:

• Macros would be sorted by app from First installed app → Last installed app
• ^ If an app has multiple macros, those will be sorted alphabetically.
• So, for example, the sorting could look like:

Apps

First_Installed_App Macro “A”

First_Installed_App Macro “B”

First_Installed_App Macro “C”

Second_Installed_App Macro “A”

Second_Installed_App Macro “B”

[scottohara]

I was going to suggest maybe there should be a “recently used”, or “most used” section (on a per user basis), but then I started to think more about it and I think that once a user is reaching for the element browser, its because they’re looking for something they probably haven’t previously used (otherwise, I imagine they’d go for the slash menu).

(I’m sure Atlassian has a better understanding of its user’s than I do, so take all of this with a grain of salt)

• If I’m a slash menu user and I know what macro I want, I’m likely to hit / and start typing. So the order of the menu items in the slash menu probably doesn’t even matter (despite my earlier post). Assumption is that I already know (enough of) the macro name I want to place, and typing is the quickest way to get to it.
• If I don’t know the macro I want (or even whether something like that exists), I’m probably more likely to use the element browser. At that point I might use the search box at the top of the element browser if I can articulate what I’m looking for; otherwise my choices are to scroll through the “All” category, or try to narrow my search by thinking about how that macro might have been categorised.

Would an end-user necessarily know (or care) whether the macro comes from an app vs a built-in? Maybe.

For a very particular app, and the user knows (or requested) it is installed; then browsing by app might be helpful.

But I would have thought most content authors are likely thinking more in terms of function they want (what it does) rather than location (where it comes from).

[DavidMichelson]

I was going to suggest maybe there should be a “recently used”, or “most used” section (on a per user basis), but then I started to think more about it and I think that once a user is reaching for the element browser, its because they’re looking for something they probably haven’t previously used (otherwise, I imagine they’d go for the slash menu).

We had the same thought!

@scottohara

Would an end-user necessarily know (or care) whether the macro comes from an app vs a built-in? Maybe.

For a very particular app, and the user knows (or requested) it is installed; then browsing by app might be helpful.

But I would have thought most content authors are likely thinking more in terms of function they want (what it does) rather than location (where it comes from).

Thank you for this perspective! Eager to hear from others as well.

[UlrichKuhnhardtIzym1]

@DavidMichelson - could you please expand on “Atlassian recommended/curated” - what is the true intension and selection process behind this “always-on-top section”?

I do share @nathanwaters concern, that this “always-on-top” fixed selection category may miss what users need 97% of the time.

If the ‘recommended’ category does not adapt to users behaviour/needs or even perhaps page context, it’ll create that slightly annoying UX of missing-the-mark recommendations we all come across so often.

[BenRomberg]

@DavidMichelson that sounds like the inferior choice for us app vendors. IMHO throwing all apps into a single category will make it harder for customers to discover app macros. Please stick with the initial proposal of having new categories.

Thank you!

[DavidMichelson]

@UlrichKuhnhardtIzym1 Recommended categories will adapt based on editing contexts (e.g. you will see different recommendations in Confluence page editor vs. comment editor vs. Jira description editors). We plan to actively curate and measure the success of recommendations, and have a vision for a blended approach between manual curations depending on the context and data-driven recommendations based on site usage.

[DavidMichelson]

@BenRomberg Understood - appreciate your feedback! Our preference is still having new categories, but wanted to make sure we got feedback on the “Apps” section idea as well.