Community moderators have prevented the ability to post new comments.
when will labels and variable page names be fixed in cloud. Also does anyone follow up when support gives a work around that could never work???
Non-working work-arounds could be worse.... They could have keyboard shortcuts that don't work and cause your screen to rotate! (oops.... they already do! --- See keyboard shortcut for inserting a row into a table... on a Windows 10 PC, this causes the screen to rotate!)
I won't go into the problems with the new editor vs. the old editor but will say it highlights the problem with the Atlassian product management process for cloud products.
In other communities, the product team goes through a community process to define the business value-risks with a product feature proposal, vote on changes, review RFCs on design long before even beta versions of a feature are released to the community for feedback.
Clearly that process is not what Atlassian is following on the Confluence cloud product. Why not?
This is a super valid question that I'll try to provide more background and context on. The new editor has been rolling out gradually for over a year now in an intentionally slow very gradual manner for the purpose of touching very small surface/low risk areas first while iterating as we move forward based on customer feedback. We started with blog posts and then moved on to meeting notes, and it's also why each rollout wave is highly sequenced over several weeks to allow for time to get used to the new experience and to gauge as much feedback as possible. This is also why we haven't migrated any existing content created in the legacy editor yet. I hope this background helps.
I guess once it is 100% rolled-out (or 100% of your customers have been rolled-over), then you may start to update the documentation, and maybe start working on the bugs!
@Pratima The intro page on the new editor has comments from folks who had old editor pages convert to the new editor and completely break them. Also folks who have to create copies of old pages to be able to continue using the old editor.
@Pratima Thank you for your response, but you didn't really answer his question. His question was around "why" don't you get more customer insight before making sweeping change not what is you methodology for making sweeping changes.
We do get tons of customer insights right from the inception of the project and all the way till the rollout reaches 100%. The editor has been in the making for over 2 years based on the feedback we have received from customers and partners. Along the way, we have pivoted and made changes based on our learnings. We do research via focus groups, interviews, surveys (in-product and outside) etc. and then weigh the feedback and incorporate in our roadmap. It is possible that not every piece of feedback gets incorporated due to its viability and demand.
Given the feedback we have gotten here, we do plan to follow-up and do a focus group with the community engaged here.
My deep impression is, Confluence developers do not use Confluence.
The new editor features are so far apart from our daily needs.
I was hoping, the new "experience" would offer more (desperately needed) features.
But au contraire, some useful features were cut! And nothing new, that would really thrill us.
We can get along with tables without background colors, but reducing text color by 32? Does this make any sense?
No more "Search and Replace" feature? We use that nearly daily for documentation in agile software projects...
Still, it is not possible to link to files or folders in a lokal file system. This would really have been useful for us. As a workaround, we set links to a sharepoint page, that holds the links to the file system, that we need (thank you Microsoft). How poor is that?
Why can't we enter HTML code to serve our needs?
Pratima, did you ever think about a user survey BEFORE implementing this changes? Or, as mentioned above, why didn't you just fix all the items mentionend in the forum entries?
Agree ! The new editor table UI ( eg adding rows clicking the + image ) is clearly not used for any high volume work by anyone at Atlassian or anywhere else. Despite that, the UI was released in production mode, not beta mode for user feedback. Big problem on the product management process.
Wouldn't it be hilarious (read: tragic) if internal development occurs all within Sharepoint and Microsoft Project?
James, what's the intent of your post? Was this meant helpful in any way?
We would just be happy to link to files and folders in our Confluence pages and in the context of the page content without a detour to Sharepoint. This would make our life much easier and would be the one improvement we really need to perform the last step to switch all IT documentation away from Sharepoint to Confluence.
@Susanne Schnitzer --- Don't complain about @James Gill 's comment. You started it with the statement "Confluence developers do not use Confluence"
Everyone at Atlassian uses Confluence on a daily basis for all their projects, so I'm sorry that your impression is otherwise. Our goal wasn't to replicate everything in the legacy editor, and there are some things, like Find and Replace, that are definitely on our To Do list.
Since we can't "fix everything" at once, we have to prioritize. The more votes certain features get, the better we can prioritize. Please add your feedback in the backlog tickets referenced in the roadmap.
Just to start off, I am ceasing my cloud confluence service and going back to hosting on prem and many colleagues are discussing a similar strategy for their companies because of the new editor.
Question: I would like to know what the decision making process was for Atlassian to decide that us paying customers should have to forfiet the ability to decide how we want our content presented and have numerous tools simply removed from our toolbox?
If the desire is to provide additional layout options to the user base that's one thing but forcing a single view and removing the ability to control layout and related tooling creates discontent for your loyal fans. Making it easier for some at the expense of removing tooling that has built a loyal fan base is a questionable strategy which is the reason for my leaving the cloud and being discussed by others.
Having been involved with Wiki technology for a long time is disturbing to progressively see the tools to fully control how content is presented and ability to nuance structure erode with each successive release.
I saw a thread about adoption.. and been around long enough to know the editor isn't what will drive adoption. Adoption will be driven by helping people use collaborative tools and improving their approach to sharing with confluence since its strengths have been the dynamic linking, collaborative content, the powerful macros and the flexibility to organize content to suit the ever changing perspectives different stakeholders adopt... vs typically used tools like sharepoint, word docs, excel sheets.. etc which I think we can all agree are not collaborative in nature.
Thank you so much for this thoughtful and detailed comment.
Yes, we did rollout with a smaller toolset to begin with for smaller surface areas in order to learn if we can improve on the previous editing experience. Over the years, this was consistently one of the biggest pain points from our customers – it felt unfamiliar and difficult to understand how it could be used to its fullest. As we've commenced rollout very gradually we've been listening closely to feedback. This is why we re-added layouts and full width. It's true that they work differently from the legacy editor and part of that is intentional. We want anyone to be able to pick up and use this feature. At the same time, we keep investing in supporting macros and other power features. In the future, we'll even take them to new heights.
Will there ever be a way of updating a ‘live’ version of a page with changes made in a ‘development’ version of a page? I have multiple spaces with development, staging, and production (public facing) versions of content. I need to move a line or paragraph from existing pages along with new page from space to space. It’s hard work and with each release it gets more difficult.
for example, the newest version, which I saw this morning, doesn’t enable me to easily link from one page to an existing page using relative links unless I have very recently viewed the page I am linking to. The links between pages must be relative (not hardcoded absolute links) for my already clunky publishing process to work.
Great question. It sounds like you are doing some inventive things in Confluence.
Content change management and versioning can get pretty tricky. Absolute links don't update when the page name changes, so using the relative link is always the way to go in order to keep up with changes in pages names and locations. Linking of various sorts is definitely very useful, and we are evaluating different ways to make this easier.
This is a great question to ask the fellow community members here.
Your update, with the link to the roadmap, just links to http://roadmap/
Any plans to allow attaching files to pages in a batch? Currently have to do this one by one. It's very inefficient and frustrating. Unless I'm missing something...
Same! When I select multiple files with CTRL and then drag them over to a file-list page, it will only add the first one. Would save a lot of time and frustration if we could add files in batches. Is this simply not possible with the way this is set up in Confluence? Or is it a functionality that could be added?
There are several ways to attach files to a page. Assuming that you are just attaching them and not inserting them into the page, you can click the elipsis at the top right when viewing the page, and click Attachments. If you multi-select files in your OS's explorer/finder, you can drop them onto the "Drop files to attach them" area. There are some issues with using Confluence's native browse and upload flow that are being investigated.
Why has the ability to manually override image dimensions been completely removed in the new editing experience? Creating a documentation space was super straightforward before because I could simply go through the process, capturing screenshots of what I wanted to document, and then simply upload all of the images and manually override the dimensions so that they would be consistent.
Now I have to manually crop and resize each image prior to uploading it into Confluence. This is a huge PITA and requires me to spend time editing images rather than creating documentation.
Edit: I see, its a drag and drop selection...that's kind of silly. The option to manually specify image dimensions to be either absolute (120pts) or responsive (4 columns) should be there.
@Pratima as @James Gill says in his comment above,:
'Creating a documentation space was super straightforward before because I could simply go through the process, capturing screenshots of what I wanted to document, and then simply upload all of the images and manually override the dimensions so that they would be consistent.
Now I have to manually crop and resize each image prior to uploading it into Confluence. This is a huge PITA and requires me to spend time editing images rather than creating documentation.'
YES. EXACTLY. SAME.
Good call out. Over the years, supporting pixel sizes has been something that got customer feedback. We heard they didn't know which size to set and that they rarely used it. This makes crafting good looking content easily a non-trivial task with a high cognitive load. This is part of the reason we've employed a grid system to allow for consistent, quick, yet flexible snapping of images - making it easy for anyone to create a readable document.
It would appear that the product roadmap is currently prioritizing new features that nobody has asked for over retaining existing core functional that is used every day to maintain documentation for business critical IT systems.
Can you please explain how a core feature (Page Links) of Confluence has a known bug that is currently listed as Low Priority and has a current status of Gathering Impact while a worthless feature such as emoji's is already implemented? How are bugs and features being prioritized on Atlassian's end?
Thanks for the question! Each feature and bug gets evaluated on aspects like previous feedback over years, usage patterns, and design considerations.
We would look into CONFCLOUD-67714.
We find it difficult to proceed further with the documentation:
I was comfortable working with the way how old confluence editors behaved. For example, in between my numbered list if I want to position an image to the center, I just used CTRL+Enter to fit my image to the center and then continued to number my list. But, with new look and feel the image is not getting aligned to the center consistently (rarely it works). Currently, I use layout to have my numbered list.
We absolutely appreciate that changing editors is not an easy undertaking from your perspective. We're doing our very best to keep the transition smooth, so thank you for that feedback, we will take this one back to the team.
So the AMA is over. Should we continue leaving feedback and asking questions on this page? Or on the other page? If you're done with this page, can you disable comments for it? Or are you planning on still responding? Even though you aren't answering questions on the other page anymore, it would probably help the discussion if we were encouraged back to a single page. And then you would only have to go to one place to "internalise" all of our feedback.
Hi Pratima, is there more information available about how Atlassian respond to the wish of a lot of users to make the previous edit function available again? As you can see there is a lot of dissatisfaction with the changes made. https://jira.atlassian.com/browse/CONFCLOUD-65302.
Best Pieter
Agree.
Can't get a simple commitment from Atlassian product management to allow the user to select the OLD editor OR the NEW editor when creating a new page or from a template. The option isn't hard.
It would probably remove over 80% of all user issues immediately.
Users could choose to migrate when any page to the NEW editor when they felt the functionality was better.
Love to hear in detail why Atlassian can't do this
Thank you for this great question.
The main limitation keeping us from allowing jumping between editors is we can't support bi-directional content migrations due to the difference in how each editor works.
Further, learning from previous rollouts to Atlassian customers and externally, research has shown that being exposed to two editor experiences for a prolonged amount of time creates the most dissatisfaction for users. It creates a lack of predictability and requires a constant learning curve that increases cognitive load.
We can see that the Confluence Editor lost some functionalities, and others doesn't work as expected.
Examples from the legacy editor:
* When I use a Page layout the images inside them can't take an order. As we see, it's a basic function.
* It's impossible to use an expand inside other expand. This is a powerful tool for extended concepts.
* Can't use images and text in same line, when we describe some buttons in our docs it's necessary an option like this.
There are some comments about the new editor, just small corrections and will be the best!
Thanks for the detailed feedback! I'll try to address as best as possible:
@Pratima -- Thank you for giving us a few precious moments of your time.
@Jessica Taylor -- Please either have the comments cut-off on this page, or continue to supply some kind of Atlassian response. As this has been left, this appears to have been an "Ask Me Anything ... and I may or may not respond, but only until the end of the hour" We really do value responses from Atlassian, instead of the community of customers just making comments to one another.
We (your customers) do really WANT THIS TO BE BETTER! We are not just here to complain!
@Bob Sovers Well said! I've asked the community managers to provide us a better platform to take this up properly and go deeper.
A town hall Q&A or user review / focus group.
They are sorting it out!
Thanks for taking the time to give us your feedback on Confluence cloud. We recognize that you are passionate about this topic and have experienced challenges as we've transitioned from the legacy editor to the new one. While we're closing this AMA, it won't be the last!
We also don't want this to be the end of the conversation. We're planning on reaching out to a number of you for a focus group in the next several weeks so we can continue to have a productive dialogue on these changes and take your feedback into account for the future.
THANK YOU!
Community moderators have prevented the ability to post new comments.