I am learning the Curlybars templating API, because I want to try to change how the “Articles in this Section” works. For example, if we have 11 articles in a section, it's not a great design from a UX perspective to have the reader click “See more”, taking them away from the current page, only to see just one additional article in the list. A more robust article navigation tree on the left side of the page would be preferable.

But, according to this page, section.articles has a size limit of 10 “for performance reasons”.

Similarly, on the section page where the “See more” link takes you, the section.artilces size limit appears to be 30 - I would like to show more than 30 per page here to eliminate the need for pagination in our larger sections, to try to improve the navigability of our documentation.

Can anyone expand on why these particular objects are so limited for performance reasons? And, are there any ways around these limitations? Thanks!

In our help center, we use iframes in some of our articles. The iframes have a style attribute to set the width and height. We use a local style instead of a CSS class so that we can tweak the height of the iframe on a case-by-case basis.

The “Clean up styles” button that was recently added to the Source code view is very useful! However, it targets the style attribute of our iframes and removes the height attribute (but not the width, for some reason), as shown below:

Before cleanup:

Thank you! Yes I agree - ideally rich text pasting (ctrl+v) should preserve HTML such as links and bulleted lists, but NOT any of the CSS (i.e. don't insert the style attributes in my test case above).

In the Zendesk editor, you can create a link to a header in the same article using the Add Link tool -> Heading tab and selecting a heading. When you do this, the link it generates looks like this: 

Jump to header

This is an issue because the live article URL is different from the URL created by the header link. The live article URL adds the article title, like this: 

hc/en-us/articles/01234567890123-Article-title-here

Because the link does not match the live article URL, when you click the header link, the browser reloads the page, which is unnecesary and hurts the experience for the reader. Same-page hyperlinks should be an instant jump, no refresh needed.

Furthermore, to link to a header on the same page, only this portion of the URL is needed. The rest of the URL is not necessary:

Jump to header

Ideally, clicking on a link to a different section of the same article would be an instant jump without reloading the page. So, it would be nice if the Zendesk article editor constructed the heading link so that there is no page refresh. It seems the simplest way to do this would be to have the Add Link -> Heading tool only include the header ID in the URL as shown above.

When I paste content from a live article into the editor, a lot of unwanted CSS styling is inserted into the HTML. This can be hard to spot at first but causes issues with the appearance of the content.

Here's a link to a video demonstrating the issue: https://app.screencast.com/TOcrnqdz38TD0

This is a problem because this CSS that is introduced causes the pasted content to look different from the source content. See the screenshot below:

Original content HTML from the above screenshot:

Heading 1

Heading 2

Heading 3

Heading 4

Paragraph

Pasted content HTML from the above screenshot:

Heading 1 paste styling original

Heading 2

Heading 3

Heading 4

Paragraph

This is causing headaches when we are trying to copy/paste content from other articles. As a workaround, we are forced to paste as plain text and manually re-add any links, bold/italics, bulleted lists, etc. It is unnecessarily time-consuming.

I have contacted support and they seem to not understand or are willing to acknowledge the issue, so I'm sharing here. I would like at least for someone at Zendesk to please acknowledge that they understand what is happening here and that it is a pain point for my team at my company. We should be able to copy/paste content from our own articles without encountering these types of issues.

This would be extremely helpful. My technique to find my place usually involves doing a ctrl+F search in the code editor for some words near where I want to work. This sometimes fails, because the code editor inserts line breaks, making the search string not match. So I have to search for a single word or a very short phrase that is still unique enough to be effective. It would be very nice if the code editor cursor matched the WYSIWIG editor so I could skip this process and continue working more seamlessly between both editors.

Agreed, the recent changes have made the user experience noticeably worse. Julia's screenshot is a perfect demonstration. There is a lot of wasted white space above the article too, between the title and the toolbar at the top of the page. Editing articles feels claustrophobic, I can't see enough content at once.

Hi Katarzyna, 

Thank you for your response. I completely understand accessibility improvements. But they don't need to come at the expense of general UX. Knowing if the Saved button has been clicked already before clicking it is very useful information that users no longer have. 

As a possible workaround to your issue with the table buttons - if you click the new gear icon in the upper right to expand the panel, then click "Article Settings" in the lower right, that will temporarily remove the bar at the bottom. Then click "Cancel" to bring back the Save button when needed.

That said, I fully agree with all of these issues.

• This new bar at the bottom doesn't seem fully thought through. It sacrifices precious vertical space even though there is tons of space on the side for these buttons. And there's no reason for it to ever obstruct the editor tools, like in your screenshot.
• I don't understand why the View/Preview button is all the way over on the left side, instead of next to the other buttons.
• And as you said, the Save button being enabled when no changes are detected is a step backwards - that was a useful indicator of whether or not I had made changes to an article.
• The Gear icon now lets you collapse the Article Settings pane. But that doesn't actually make the editing space any wider, so there's no real benefit to collapsing it. It would be great if the article body could match the same width as the live article, so things like image size or table width can be judged more easily without having to save and look at the preview.

The reasoning behind this update is not clear at all. Some communication from Zendesk on this change would be helpful.

Please give a quick overview of your product feature request or feedback and note who in your org is affected by this issue 

In Guide, would like to be able to select any two revisions in the Revisions page for an article, and see the differences between them. Currently users can only see the changes to two consecutive revisions.

What problem do you see this solving? (1-2 sentences) 

When editing an article, Guide writers will save the article frequently. This results in a large number of entries in the Revisions page, making it very difficult to see a summary of all changes that were made to the article in a given time period. Being able to select specific revisions to compare would be massively useful to tracking an article's revision history.

When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)

This problem happens on a daily basis. Without this feature, we are forced to write up our own notes for changes that were made. This would be a huge productivity boost.

Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)

Yes, we use other tools like Google Sheets and JIRA to keep track of the status of the articles we are working on, and note any important changes that were made or need to be made. It would be incredibly useful if the "paper trail" that Zendesk saves for user activity was more robust.

What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)

In the list of revisions on the right side of the Revisions page, you would select two revisions, then click a "Compare" button, and then all cumulative changes from the older revision to the newer revision would be shown in the article.