RFC-36: Live-Edit Pages in Confluence Cloud

We use labels to define page statuses for approval and review workflows. For example, the app adds a certain label to a page if users have to review its content. Most of our users interact with the app through the content byline item, but users also need to be able to add or remove labels to change the page status.

Thank you for this additional context.

I wanted to flag that Live-Edit Pages do have Labels (they can be modified through the meatball menu), but they are not readily visible on the page unless a user goes to Edit the labels through the meatball menu. They are certainly much less discoverable than with published pages, in our current implementation. How do you see this impacting your app’s experience?

I truly believe that live-edit pages are the only way forward for a modern knowledge management / collaborative document product. Confluence hasn’t been a documentation-only product for a long time - especially since synchrony. This is a competitive must-have.

1 Like

Thank you so much for participating in the first RFC regarding Live-Edit Pages, and thank you to all the partners who signed up for the EAP to test their apps. We heard a ton of thoughtful and useful feedback to shape our thinking. We expect to continue collaborating in the near future, with more pointed RFC’s for specific parts of Live-Edit Pages.

Resolving this RFC

This resolution will highlight our most updated thinking around the biggest feedback themes. This resolution does not mean we are going to start GA’ing Live-Edit Pages. Live-Edit Pages are still only available via Early Access as we polish the experience. We plan to continue working with you on making Live-Edit Pages work best for our shared customers.

Sign up for the Live-Edit Pages Partner EAP

To help us polish the experience, we are re-opening signups for the Live-Edit Pages Partner EAP, so you can test your apps and give feedback. Partners who sign up will be added to the EAP group in the Developer Community, where they can give detailed feedback about their experience.

Updated thinking on major themes of the RFC

Macros

Interactive macros on live-edit pages are absolutely necessary. Otherwise, our app is unusable on live-edit pages.

Partners in the Live-Edit Pages Partner EAP (sign up here) can now test how their macros behave in Live-Edit Pages. Historically, macros had a “glass pane” on them in the Editor - preventing users for interacting with them. In the EAP, we have removed this “glass pane” so partners can properly test how interactive their macros are on live-edit pages.

Macro interactivity in the Editor

  • For non-bodied extensions (i.e. normal extensions, inline extensions), we’ve identified that it is difficult for users to intuitively interact with AND configure macros in Live-Edit. We plan to address this by updating the existing macro interaction design in a way that makes interacting with AND configuring macros in Live-Edit possible and simple. Expect an RFC with our proposals an early May.
  • For bodied extensions, we’re aware that they are very far from WYSIWYG. We are also exploring how to make bodied extensions more functional in Live-Edit Pages, but expect to have solutions for non-bodied extensions first, as they account for a much larger proportion of usage. As a next step, we will engage more with partners using bodied macros in the EAP to inform proposals in a later RFC. In the meantime, users in the EAP can still publish Live-Edit Pages to get full functionality out of bodied extensions.
  • We are also considering giving partners API’s to save macro changes directly from the Editor (in addition to the existing way through configuration UI’s), which could enable even more WYSIWYG experiences.

Custom macro configuration UI’s

  • We do not plan on removing the ability for partner macros to have custom configuration UI’s.

Extension Points

Access to the edit screen is very limited for app vendors pre-change (largely via siloed macros). This puts app vendors who used any of the integration points at a further disadvantage. It would be good to consider how we could extend the new edit/single experience to incorporate some of these.

We heard from you and understand that extension points are critical for Confluence users to be able to discover app experiences–and that they are very limited within the Live-Edit experience today.

While we don’t expect to bring full parity of all extension points in the renderer into the editor, we do plan to conscientiously add select Connect & Forge extension points into Live-Edit Pages before they would GA to fulfill jobs required by partners while aiming to simplify the user experience. As a next step, we plan to engage more with partners using extension points in the EAP to inform proposals in a later RFC.

API’s & Events

Can Confluence macros determine they are on a live edit page? Can we determine from our backend if a page is a live edit page? Background: Some actions of our macros only make sense for published pages, and we want to alert the user to this fact.

We are making API & Event updates so partners can better handle Live-Edit Pages.

API’s

Right now, Live-Edit Pages and draft/published pages are differentiable via the content API by the subtype field. This should now be available via the v2 API. Note that this is not an official public API yet, and is subject to change.

  • Example URL: wiki/api/v2/pages/{pageId}?include-internal-properties=true

New Events (Forge & Connect Webhook)

In the EAP, we plan to expose two new events for Live-Edit Pages to differentiate Live-Edit from published pages (expected availability in May). Live-Edit Pages will:

  • Send a page started event immediately upon creation. This replaces the page created event, which will still fire for published pages.
  • Send a page snapshotted event upon a background snapshot. This replaces the page updated event, which will still fire for published pages.
  • These events are subject to change. Particularly, I want to highlight that the page snapshotted event is likely to change as we iterate on our snapshotting logic.

Separating Published Pages from Live-Edit Pages as new content types

We do not plan to make Live-Edit Pages and Published Pages separate content types. Note that Live-Edit Pages can be published, and will be treated like a normal Published Page thereafter. Also note that we are now offering Events/API’s to help partners better differentiate between Live-Edit and Published Pages.

Page Comments, Labels

A few of you called out that your apps leverage page comments & labels, which are not readily visible in Live-Edit Pages.

  • We understand that page comments are important for partners to be able to communicate actions apps have take on pages to users. Furthermore, some customers may be used to making page comments today. With that, we are considering adding page comments to Live-Edit pages and will share updates when available.
  • Note that labels are available for Live-Edit Pages, but they are currently only accessible via the … menu, and labels aren’t immediately shown on pages.

Got any additional feedback?

Please sign up for the Live-Edit Pages Partner EAP if you haven’t already. Once you sign up, you’ll be able to post in our Live-Edit Pages group in the Developer Community, where the team will actively check your responses.

3 Likes