3 Items
#51 – Rethinking Confluence with Live Pages
Matt Reiner
Hey hey hey, this is your Weekly Dose of Confluence where we summarize the latest and most important Confluence News directly in your inbox. If you were forwarded this message, you can subscribe to the free weekly newsletter here.
This week, we’re exploring live pages–coming to Confluence early next year–and how they’ll change the way teams work. We’re also celebrating the ability to add external images to pages and a big change in when the blog feature is enabled in Confluence spaces.
Let's dive in!
Live Edit Pages Will Change, Almost, Everything
We’ve all been there. Hit that “Create” button, write the content for that page, and then… what to do with that “Publish” button?!
Throughout our 10+ years of both using and supporting users on Confluence, that blue button has raised a lot of questions:
“Wait, what happens when I click this?”
“My page isn’t visible to my team until I publish it?”
“Why do I have to click “Update” every time I make a small change?”
“Why can’t this be more like a Google Doc?”
And while the act of publishing or updating a page is a bit odd to a majority of users, we know and love the subset of content creation professionals who rely on the act of publishing changes, version history, and version control. After all, this is the crowd we’ve built our powerful suite of Scroll Apps for.
Well, Atlassian announced at Team '24 Europe that live pages are coming in beta early next year.
So, let’s look at how live pages differ from the traditional publish and update approach, and how both approaches are great for different types of teams.
From Drafting and Updating to Live Editing
With live pages, all changes made are live, and visible to anyone viewing the page. If they have edit permissions, anyone can click on the page and begin making changes. This is really different from the current approach where everyone has a read-only view of the page, and those who have permission can edit the page and update it when they’re ready.
But have now fear! Users can select which approach they want to use on a page. We love this, because having both approaches will be great for different types of teams. Here’s why:
Many users and teams use pages for knowledge sharing, where updates and collaboration are the most important thing. It’s critical for these teams that anyone is able to take action quickly without any barriers.
For those teams managing and controlling a sensitive collection of content, like product documentation, having all changes confined to a separate editing experience is just what they need for ensuring all changes are well thought out and shared only when ready.
Wibbly Wobbly Page History
When a page is set up for live editing, it automatically saves changes every 5 seconds; much the same way changes are saved when using a traditional publish and update page. A key difference here is around the page history, which is the record of changes made to a page. With live pages, a version of the page is saved automatically, 10 minutes after the last editing session. With publish and update pages, in contrast, a new page version is saved each time the page is published or updated. Giving much more control over when a version is created, including the ability to add a note in the version history. Once again, both approaches are great, given the use case:
Most teams don’t really need full control of the history of page changes, and they certainly don’t need to add notes. What’s important for them is that their changes are saved, and that there’s some form of history, for reversion or audits—in rare cases.
For teams with highly controlled content, the publish and update approach still gives them the robust page version history they need to ensure their content is shared when it’s ready.
Ooops, Changes
Live edit pages make it easier for people to jump in and add edits to pages. But what if you don’t want them to make changes? What if you don’t want someone’s cat to run across their keyboard and make those changes for them? 🐈
Well, this was much less of a risk with publish and update pages, because someone would first have to enter edit mode on the page and then make changes.
Again, we think these two options are ideal for different teamadlk)fja#34$90510$3)41#32kirjzq98($&