Why we migrate to native Confluence where we can
A panel becomes a Confluence panel. An expand becomes a Confluence expand. A status lozenge becomes a status lozenge. None of those become Capable macros, even though they could.
Swapping one vendor's macro for another vendor's macro leaves you exactly as dependent as you were. Where Confluence itself does the job, that is the better destination.
#What goes native
Source macro | Becomes |
|---|---|
Panels and alerts, from several apps | Native Confluence panels |
Expands | Native Confluence expand |
Tabs | Native Confluence expands |
Status lozenges | Native Confluence status |
Dividers | A native horizontal rule |
Titles and numbered headings | Native page content |
Page trees, news and activity streams | The native Confluence equivalents |
#Why tabs become expands
Confluence has no native tab element. Expands are the closest native equivalent that keeps the content readable, searchable and exportable, and they degrade gracefully in PDF and on published sites, which tabs built from a macro do not.
It also means fewer things to migrate next time. Content that ends up as native Confluence markup is not tied to any app, including ours.
#A few things that catch people out
A native conversion is still a conversion: the page changes and gets a new version.
Tabs becoming expands is the change most likely to prompt a question from authors. Mention it before the run.
Where a Capable macro genuinely adds something the native element cannot do, we use the Capable macro instead.
#Related
Fewer apps is a better outcome than more.
