Add anchor links to any header

[#1]

Hi! I’m Rachel, a Product Manager on the Editor team. We’ve been listening to customers in the community, and we’ve been focusing on some of your top requests and most frustrating pain points!

One thing we’ve heard LOUD AND CLEAR is the request to link to a targeted section of a page. In the legacy editor, this was accomplished with the Anchor macro. We purposefully chose to find better ways to accomplish this without you having to explicitly add macros to your page. We pondered if there was a way to have these targets built into the formatting so that you could just copy a link to that target and reference it where you want!

In the new editor, we rolled out the first version of this built-in targeting by giving every top-level heading an easy to copy URL. We know that it isn’t perfect, yet, but we are working on it!

Now, we are working to add these targets to headings in other places — in tables, in panels, in expands, and in layouts.

We know that adding a target to the heading format may not sync with some of the ways you format content today. You may have a glossary where you want a letter-based table of contents to jump to that letter’s section, or you want the link on one page to jump to a certain part of a section on another page. Presenting content in meaningful, useful ways is an ever-evolving endeavor, and we feel confident that you can use the lower-level headings to accomplish many of your needs. For example, you could use Header 5 for glossaries.

Getting this capability out to you has multiple parts, and we wanted to share each capability with you as it is ready, rather than waiting until it’s all done.

• Links to stand-alone headers

• Links to headers inside other elements (tables, info panels, expands, layouts) - 🔜 coming next quarter!

We know this isn’t everything you’ve asked for - namely being able to get a target link to any content, not just headers (text, elements, images etc) - and we will revisit these additional requests for target linking in the future.

All the best,

Rachel

[Aaron Carlson]

How do you link to a row within a table? This seems to be one of the most common use cases.

[Jeanne Howe]

Not even close to what we had before. Not even close to what we are asking to get back.

Headings in a table row or a Glossary - seriously!

Let's see Atlassian create their documentation in a Cloud instance and see how well this works for them.

[Rodney Hughes]

I have to agree with @Jeanne Howe .

a bizzare analogy

Volvo's reputation is "safety"

Consider the outrage if they released a new car without seat-belts ...

then tried to say we will put them back for the driver as phase 1

and we are working on a "better solution" for the front passenger in the next phase ... maybe soon

and no mention of the rear passenger seats ...!!

This approach creates an impression of incompetency in feature management and total disregard of Users .. especially when we have been whinging for months to get things BACK, not new, just reinstated even it was a bit cumbersome.

Would not it have been better to NOT remove the facility we all NEED AND USE NOW and wait till you got any new idea all right? 

Atlassian and Confluence is around professional documentation which has as one part links to any particular location in a body of text - be that to headings or tables or images or ....

Seriously!  The simplest best user experience would be to roll back to the old editor IMMEDIATELY and let your development team work in peace and quiet without all this User upset in their face!

Us "rear set passengers" want at least a deadline ... so we know how much pain we have to endure in not being able to do what we need .. and for how long we have to tell our Users that we represent that they have to wait to continue doing their work.

[Jeff Mychasiw]

Thanks @Rae for the update.  As you are aware, many of us long time users feel we have taken quite a hit with the loss of functionality in the new editor recently.  What made it worse was the perceived lack of feedback from Atlassian. I do not disagree with some of the comments in this thread, but honesty and transparency from Atlassian goes a long way in making this transition easier. So thanks again for this blog.

One thing that would really make this transition easier would be for you to outline your roadmap that shows what Atlassian is doing to fix "the new editor problem".  You mentioned "focusing on some of your top requests and most frustrating pain points". Can you point to a summary roadmap of what we can expect to be fixed in the next two quarters?  And please don't refer me to this article  https://support.atlassian.com/confluence-cloud/docs/confluence-cloud-editor-roadmap/

This is fine for some but I don't want to see a long random list of missing functions where some are labeled as "gathering interest".  Please tell us what will fixed in Confluence Cloud in the next two quarters so we have something to look forward to.

Thanks for listening

[Sean Chappell]

@Rachel Crossman A major issue my team has with the current implementation of anchors in the new editor is that the links break if the text of the heading being linked to is updated (because the #anchortarget is based on the text of the header text).  For 'living' documents or those that go through rounds of editing, this happens frequently.  This is literally the one issue blocking my team from using the new editor.

Is this something you plan to address?

For what it's worth: macros were and still are a great solution for anchors:

1. They can be placed anywhere.
2. They don't break when content is modified.
3. They're relatively buried in the UI so they aren't getting in the way of anything. 
4. Existing users are familiar with using anchor macros.
5. They aren't mutually-exclusive with the more new-user-friendly anchor functionality you outline in this article – you can do both!

Unless there's some non-obvious reason why macros are inherently bad, I would re-implement them were I in your shoes.  

Thanks for reading!

[Antonio García]

@Rachel Crossman

While I appreciate the honesty in your communication about what you thought, that reveals some serious problems:

• You and your team thought it would be better to get automatically generated links in headings, it's clear you didn't *ask* your users if that was a good idea for them, it is not.
• You wanted to release this imperfect approach, without being tested in the real world, without getting users' feedback and decided to launch it as it was, instead of waiting until the feature was completed. Why the rush???? We could have lived very happy with the old editor until you got the new one in a status in which it doesn't mess with existing functionality.
• It's about adding not substracting, as a user I will never thank you for functionality being wiped out just for the sake of having yet another feature for selling purposes.

There's no shame in accepting you made a mistake: rollback to the old editor while you continue figuring out what the best solution is, and do get feedback, do some pilot testing *before* launching this to the wider audience.

[David O'Shea]

Rachel, a Product Manager on the Editor team; AND COMPLETELY TONE DEAF.  If the Atlassian Confluence Editor team hasn't figured out (and is still making excuses for, and rationalizations of) the lack of FULL FLEDGED anchors in over a year and a half, its time for a new Product Manager of the Atlassian Editor team.   

I means seriously.  It has been 1.5 years now, and the old alternatives are basically gone (or the last vestiges going away), and the "new" cloud editor is a disgrace, a laughing stock, an utterly unusable program for creating online documents- BECAUSE THE SINGLE MOST CENTRAL FEATURE TO ONLINE DOCUMENTS, is the general purpose "anchor". 

Authors understand anchors, how to use them, when to use them, and why they are good.  My patience is gone.  Looking for a new solution now.  Confluence has become a total joke.

1.  Reference from ONE PLACE (link) to ANOTHER PLACE (target).   (Where ONE and ANOTHER, are ANYWHERE!)

2. References that DOES NOT BREAK!   When the TEXT at either ONE PLACE (link) or the ANOTHER PLACE (target) does NOT BREAK when the text wording changes, that's a solution.  Anything else, is not.   In your completely BROKEN PLAN (not even today's broken-ness, but tomorrow's plan), if an author changes the text working of a section header, then the "automatically" generated URL targets all change their names, and ALL of the links to them "BREAK".  DUHHHHHHHHHHHHHHHHHHHHHHH.    How stupid are you folks?   Obviously, REALLY, REALLY, REALLY stupid.   Because if you understood this problem, you would NOT pretend that header-linking provides even a fraction of the functionality that generalized anchors provided.   And QUIT PRETENDING that the header-linking is a "make it easier for users" feature.  It is not easier, or better, or equivalent.  It just a totally crappy workaround.

3.  There is NO WAY to generate automatically generated URL's and KEEP THEM CONSTANT with text changes so that references DO NOT BREAK on text changes, or chapter rearrangements, or section moves, or documentation updates.   If it is automatic, and references the local location data in the name, or references the TEXT of the target in the name, then the name (target name) is fragile, and all the links to it are subject to failure.   In multi-page linkiing, that is DISASTER.  UNACCEPTABLE DISASTER.

4. One also needs in page linking that is more general than only to HEADERS, and mult-page linking that is more general than HEADER targets.  And again, HEADER TARGETS change names CONSTANTLY, they are  HORRIBLE proxy for actual manual created uniquely named targets (anchors) that can be referenced in links.   It is just that simple.

5. QUIT TRYING TO TELL US HOW TO  DO OUR JOBS.   We are CLEARLY far better at it than you.  You clearly have NO CLUE WHAT-SO-EVER when you pump out this RUBBISH about how the "linkable headers will save the day."   THEY WILL NOT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! NOT NOT NOT!!!!!!

6. FINALLY, EXPLAIN WHY YOU ACTUALLY DE-FEATURED THE PRODUCT (resources, effort), and WHEN EXACTLY you will RE-FEATURE the ONLY FEATURE THAT IS NON-NEGOTIABLE, "generalized anchors".  Every WEB product in the universe HAS THEM, except for the new Confluence page editor.   It is a DISASTER.  If you entire editor team is not ONLY WORKING ON THIS ONE FEATURE, then you have your priorities wrong.   THERE IS NO OTHER FEATURE on your roadmap, NO Integration project with another Atlassian program, NO OTHER THING, that any resource you have in the Editor team, should be working on, but to restore generalized anchors.  PERIOD.

7.  If Atlassian cared about keeping customers, they would be moving MORE resources in, from WHERE-EVER THEY HAVE TO, in order to fix immediately this TOTAL WRECKING OF THE PRODUCT that they have foisted on customers.   

The positions that RACHEL, and Atlassian have put out DO NOT MAKE SENSE.   It is like you honestly, really, have NO CLUE WHAT SO EVER, about what you are doing.    If you worked for me, I'd fire you.  In fact, you DO WORK FOR ME, and I am firing you, I am looking for a new product now.   Clearly after 1.5 years of complaints, made PAINFULLY CLEAR by users, you are still to disinterested RESTORE functionality you ALREADY HAD in your old product.   Go back and look at that code, and figure out how to port it over into your new universe. 

I REALLY, REALLY, REALLY DO NOT UNDERSTAND the unmitigated RECALCITRANCE and ARROGANCE of Atlassian in relation to the MISSION CRITICAL FEATURE.    AGAIN, as I (and a FLOOD) of others have said many times before, this isn't even "A" MISSION CRITICAL FEATURE.   IT IS "THE" MISSION CRITICAL FEATURE.    If every breath you take, isn't with the purpose of FIXING THIS DISASTER, then should stop breathing, and perish.   

HOW BAD ARE YOU FOLKS AT MARKETING?

[Rachel Crossman]

Hi everyone,

Thank you so much for all your feedback, we really do appreciate it. We've heard you, we know we didn't deliver everything you needed with our iterations of anchor linking in the new editor. We've taken your feedback and detailed requirements on board, and we've been working on building the Anchor Macro for the new Editor!

Good news - we'll start releasing it in the next few weeks!

We'll be updating this ticket as we release, so you can follow there for updates, or stay tuned on Community and we'll share back when it's on the way, with more details about what's included. 

Thanks again,

Rachel Crossman - Product Manager

[Richard Silverman]

As several people have noted: anchor links must have tags which the writer can easily specify and which are not derived from the text. Deriving them from the text is a basic and obvious violation of the principle of structural markup, and it means that if I edit the text later, all links to that section are immediately broken. It's hard to imagine how you could possibly have gotten this so wrong, for so long. It's been a foundational aspect of HTML since the 90s.

Adding anchor macros to the new editor is also not a good solution on its own, because they won't work completely: if a reader uses the "copy link to heading" hover feature in a Confluence doc, they will still get the wrong link -- the auto-generated one based on the text, rather than the anchor sitting next to it. I think the best thing would be to allow the writer to customize the anchor link for a heading with an arbitrary tag, which then remains unchanged if the heading text is changed. If later editing removes that heading entirely, the writer can then add an anchor macro with the same tag in the right place, to preserve existing links to it. In other words, exactly what you'd do if you were writing the markup yourself. Confluence should make it easier to write good documents, not harder (and certainly not make absolutely basic things impossible).

Even more annoying: one apparently can't even do this directly via the storage format. This is the simplest thing in the world, utterly basic HTML:

<h1 id="foo">Heading</h1>

...

<a href="#foo">link to foo</a>

Confluence accepts this, uploaded via the API – but it strips the id attribute from the h1 tag, which you can see by retrieving the page after update. This is especially infuriating.

[Nathan Rosenquist]

You need to leave edit mode for anchor link mouseover to work. So, if you want to link from one portion of your document to another, you have to publish the document, copy the link from the header, and then go back into edit mode to paste the link elsewhere. Really frustrating and inconvenient.