Hi @DavidMichelson ,
A follow up question:
How is export (e.g. to PDF) going to work? What is exported, the current visible version, or the last saved version, or the last published version?
1 Like
There was not an RFC for the change to make the content sidebar & top navigation available to Confluence users while they edit pages. There was, however a community article and a changelog announcement.
Hi @marc
Could you help clarify what you mean by “page status” in this case? Perhaps with an example of one of the use cases you mention?
Good question. When a user triggers an export, the current visible version will be what is exported.
1 Like
Hi @DavidMichelson,
thanks for the RFC and previewing the current state of live-edit pages.
We have some very serious concerns about what we have seen so far. To be very clear, the current state of live editing would totally ruin our business and prevent our Forge apps from working correctly.
We (like many other app vendors) would definitely need:
- byline items
- interactive macros
- comments
- labels
These four are absolutely essential. Please keep us updated about the further plans and roadmap because, as pointed out before, this has severe (like catastrophic) consequences for our (and others’) business.
4 Likes
Thanks for the response @DavidMichelson. A RFC for overlapping features happening at a similar time would have helped us plan/determine impact. Following change logs, community posts and RFCs (which aren’t always aligned) can feel like whac-a-mole at points.
Hi Adrian. Thank you so much for your feedback. Could you give a little more context on your labels use cases so we can be sure to think of them?
For “comments” - I assume you mean the ability for apps to leave comments on pages?
We’ve tested live edit, and it breaks our macros. We need access to the byline and the system.content.action menu for users, such that they can interact with our macro.
It seems you can’t create a new page from a template. Most of our users use a predefined template to create a page.
I think this is a big change for users. Have you thought of making live edit page a new content type like whiteboards or embeds? It seems a live edit page is not a page/document in the sense of Confluence. It’s something new.
4 Likes
Ah yes, I see what you mean now.
Currently, the content state / page status will be ‘finalized’ when the background snapshot occurs, so it doesn’t occur immediately upon setting it.
I believe this will at least “surprise” users, and it will wreak havoc for users who use Confluence for compliance documents. If a user sets the content state to “Reviewed”, and somebody edits before the snapshot, the document is not “Reviewed” anymore.
This can lead to auditors revoking certifications, and also to legal trouble.
Was there actually any user research in compliance heavy industries? Or does Atlassian think they should stay on Datacenter for ever?
1 Like
Hi @DavidMichelson,
Hi Adrian. Thank you so much for your feedback. Could you give a little more context on your labels use cases so we can be sure to think of them?
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.
Please note that we can’t use the Confluence page status as a replacement for labels because of several limitations (they can’t be searched with CQL, and only a few statuses can be defined per space) and because other tools integrate with our app through labels.
For “comments” - I assume you mean the ability for apps to leave comments on pages?
We are using the footer comments on pages to inform and notify users about status updates. It’s important that users can see and respond to these comments on live-edit pages as well. Inline comments are not sufficient in our case because status updates are not referring to specific parts of the content, but to the entire page.
2 Likes
@DavidMichelson, not sure if this is a viable idea, but have you considered introducing Live-Edit pages as a separate page type? I imagine I’d need both for different use cases:
-
“wiki/published page” for information that requires clear versioning, advanced macros, hooks, integrations and view mode; Marketplace apps can focus their efforts on this type of pages and have a trust that APIs won’t break in future
-
“live-edit page” for team collaboration, transient info that quickly becomes outdated and everything that doesn’t require publishing. Marketplace apps can slowly start supporting this type or clearly mark them as not supported.
This way user has a clear mental model and can choose according to their needs. Ideally, there is a way to convert between two types with a button, but if technically not possible, copy-pasting content from live-edit to published page doesn’t sound too difficult.
To give a personal example, I am managing an engineering team with a lot of knowledge management. I’d use live-edit pages in 80-90% cases, which would save enormous amount of time in avoiding “draft - edit - publish - view” cycles, and only 10% of pages would be “published pages”.
Some other team might have this ratio reversed, so they wouldn’t even want to mess with live-edit pages and stick to an existing flow.
2 Likes
I think this is a great idea. @DavidMichelson
Hi all, thank you for your continued feedback & participation in the Early Access Program.
Since there is still a lot of good discussion happening & we plan to open up some more discussion with partners in the EAP, we are going to extend the resolution date of this RFC into next month, April 24.
1 Like
Hi Julian, I want to clarify that we are not planning on removing the existing custom macro configuration UI as a part of live-edit pges. Apologies if the RFC made it sound as such.
2 Likes
That’s good to know - can you also clarify whether:
- Either ‘as part of’ means custom macro configuration UI might still get removed in context of other initiatives?
- Or if it is here to stay (preferably), Forge apps will gain custom macro configuration UI capabilities anytime soon as well (the lack thereof is a significant competitive disadvantage right now and also blocks Forge only migrations)?
2 Likes
@sopel We have no plans in the context of any initiative to remove custom macro configuration UI.
1 Like
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.
4 Likes
For now, Live-Edit Pages and draft/published pages will be differentiable via the content API by the subtype field. This should now be available via the v2 API.
Example URL:
wiki/api/v2/pages/{pageId}?include-internal-properties=true
Note that this is not an official public API yet, and is subject to change.