Enriching the article editor

36 Commentaires

  • Bob van Toorn
    Actions pour les commentaires Permalien

    I saw that you use TinyMCE, so here is how an implementation of my request would look:

    In the editor.js file add `formatselect` and `removeformat` like so:

    toolbar: [ "zen-textsize", "formatselect", "bold italic underline zen-forecolor", "numlist bullist zen-align", "zen-link zen-imagemanager table", "removeformat zen-code" ].join(" | "),

    And then add these options to the `formatselect` settings.

    "Paragraph=p;Blockquote=blockquote;Pre=pre;Code=code;Heading 1=h1;Heading 2=h2;Heading 3=h3;Heading 4=h4;Heading 5=h5;Heading 6=h6"

     

    2
  • Jonathan March
    Actions pour les commentaires Permalien

    Thanks Bob. Indeed, these are fundamental.

    2
  • Dan Ross
    Actions pour les commentaires Permalien

    This is critical for us as well. At the moment, our content writers need to manually edit the source for the article for each article they publish. It's tedious and slow. It also means non-technical users are unable to update articles without risking breaking the styling.

     

    Please give the article editor some TLC!

    0
  • Christian Colding
    Actions pour les commentaires Permalien

    Hi Dan,

    Could you elaborate a bit on which specific features your content writers currently use the source code for? It would help us to understand exactly what types of changes we would have to do.

    0
  • Dan Ross
    Actions pour les commentaires Permalien

    Hi Christian,

    Thanks for replying. Here's what our content writers have indicated they need to edit the source for frequently:

    • applying heading styles to titles
    • Creating multi-level bulleted and numbered lists (the formatting menu only supports 1 layer - example below)
    • adding anchors to simplify navigation within an article. 
    • embedding videos
    • applying a font to specific text
    • applying <code> and <pre> tags
     
    I see that Zendesk is using a flavour of TinyMCE as an editor. It is possible to get the same functionality that we see on their homepage (v.4.5.5)? It seems to support nearly all the functions listed above.
     
    Thanks for your consideration,
     
    Dan
     
     
     
    2
  • Christian Colding
    Actions pour les commentaires Permalien

    Hi Dan,

    Thank you for giving me extra details. Definitely helps us. I have a few questions around some of them:

    Creating multi-level bulleted and numbered lists

    I am assuming you are trying to create a list like this?

    If that is correct, you can do that by using the indent/outdent button:

    Granted they are a bit hidden and also you can't use the tab button to create these. I'll look into whether we can improve that, but I want to make sure that this is indeed the functionality you are looking for.

    Applying a font to specific text

    Why do you need to specify the font for specific text? Could you elaborate a bit more on the use case?

    Applying <code> and <pre> tags

    Can you tell me a bit about the differentiation between these? When do you need <code> and when do you need <pre>?

    1
  • Dan Ross
    Actions pour les commentaires Permalien

    Hey Christian,

    Thanks for the tip about the lists, that is what they're looking to do. It is a bit flow breaking in terms of writing, needing the author to stop, mouse over to a nested menu and select an option. Being able to use Tab to do this would be great. I'll pass along the tip to them.

    As for the <code>, <font> and <pre> tags, we're in the software industry. Our most common cases are for API documentation and in some cases, users are able to customize output in-app via HTML(print templates for example). Also, on occasion, sometimes troubleshooting might require the user to execute something on the command line.

    Being able to visually distinguish these sections from the rest of the article are important and presently tedious to implement. 

     

    0
  • Kay
    Actions pour les commentaires Permalien

    +1 for this.

    @Dan, your writers should be able to use the CTRL+ALT+2 (for H2 and so on) as a shortcut.

    @Christian, next to what Dan mentions, I also believe there is interest in having custom styles and custom content embedded. 

    For the custom styles these examples are shown a lot in Zendesk's own announcements articles. When you want to point out something like a 'note', 'warning' or 'tip'. It is vital that this is also shown in the editor and not just on the front-end.

    Video's for one, but also embedded tweets and so on. The ideal solution for us would lie in a separate button in the toolbar, which toggles a pop-up on click where you can paste the embedded code. Then click add, and it will be added at caret position.

    For people who are writing all day, keyboard shortcuts for all options are vital for speed and not getting frustrated.

    1
  • Christian Colding
    Actions pour les commentaires Permalien

    Hi Dan,

    So as I understand it you just need something to support displaying code snippets? Whether it's <code> <font> or <pre> is less important?

    0
  • Christian Colding
    Actions pour les commentaires Permalien

    Hi Kay,

    No doubt about the fact that we need custom styles as well if we want to reduce the need for using the source view - which by the way is something that both we and our customers want, the source view is causing us a lot of problems.

    0
  • Dan Ross
    Actions pour les commentaires Permalien

    Hi Christian,

    Thanks for staying engaged on this! Yes, the primary concern is the ability to display code snippets in a clear and uniform manner, without requiring a dive into the source. Kay's comment about being able to display warnings, tips or notes is a one supported here too. 

     

    @Kay, Our content writers say thank you for that shortcut!

    0
  • Jonathan March
    Actions pour les commentaires Permalien

    Hi Christian,

    To add to this -- we are in the midst of updating a number of old articles for publishing next week. Many of these were written pre-HC, and their auto-conversion to HC was less than perfect (and their manual tweaking was also very inconsistent). We've been told by one of our web pros (who does not actually touch the HC) that we should use both <code> (for its semantic meaning IIUC) and <pre> (for its formatting of multiple lines and spacing) so that's what we're inclined to do, manually for now.

    But we would also like for what we do (manually) now to be compatible with future iterations of the HC editor in WYSIWYG mode.

    Any suggestions / advice?

    Thanks,
    Jonathan

     

    0
  • Christian Colding
    Actions pour les commentaires Permalien

    Hi Jonathan,

    I can't yet say what is happening with our editor when it comes to <code> and <pre> which is also why I am asking for use cases to better understand how those two would be used differently.

    I understand that there can be difference, but can you give me an example of when you need to use <pre>? Like what type of content are we talking about?

    0
  • Jonathan March
    Actions pour les commentaires Permalien

    Again, I am no HTML expert, but AFAIK, <pre> is pretty much essential for multi-line code snippets, especially where leading whitespace is syntactically significant (e.g. in Python, which is what we mostly use). It's important to be able not only to read code online, but also copy/paste/execute it as-is.

    0
  • Christian Colding
    Actions pour les commentaires Permalien

    Jonathan,

    I am assuming that you could change the behaviour yourself using CSS if you wanted <code> to act the same as <pre>, no?

    0
  • Christian Colding
    Actions pour les commentaires Permalien

    Reading up on it, it could seem like we should include both, so <pre><code></code></pre>, but we'll do some more research on it.

    The question is would you ever use <pre> for anything else than code?

    1
  • Jonathan March
    Actions pour les commentaires Permalien

    > would you ever use <pre> for anything else than code?

    Logs, console input/output.

    So technically IIUC it would be most correct to support <pre> with and without <code>, but I would not lose any sleep if the GUI only supported it with code.

    Note that it's also important to support inline code. IIUC, this would mean that you'd need to support code without pre for this use case (kind of like bold, italic, underline).

    0
  • Larry Bear
    Actions pour les commentaires Permalien

    As a tech writer using Guide as the main authoring tool, I hope all of the above can be implemented ASAP, instead of continuously looking for other HATs that can integrate.

    Thanks in advance.

    0
  • Florian K.
    Actions pour les commentaires Permalien

    I was also encouraged to add an entry to this forum and am glad that our company is not the only one with this requirement. 

    We would describe it "Enable setting custom CSS classes for styling blocks in Knowledge Base articles"

    Problem: It is not possible to mark a paragraph as "Note" or "Warning" because the knowledge base editor currently does not support setting CSS classes when editing HTML. Example would be paragraphs where a "Note" shows with yellow background or a "Warning" with light red background and an image.

    Current workaround: Copy-pasting a HTML/CSS snippet into the source.

    Solution: Consists of two parts: configuration and an extended combo in the editor. 
    Configuration: define reusable CSS classes and the according HTML tags (P, DIV, Span, H1,...) they apply to. 
    Editor: In the editor, the already existing combo-box allowing selecting headings/paragraphs would be extended with the custom CSS classes. When selecting the class, the current block element would change to the configured HTML Tag and CSS class.

    This feature has been around in HTML Editors such as Microsoft FrontPage for decades. Technical documentation authoring software such as Madcap Flare also offers configuring custom CSS classes. Microsoft Word has a similar feature called "Styles".

    Severity: Configurable styles would improve the editing work, raise quality of the articles.

    Zendesk itself is affected by this missing feature as Zendesk is using a custom CSS class "note" and "notetitle" in its own articles, such as https://support.zendesk.com/hc/en-us/articles/206401358-About-search-engine-optimization-SEO-in-Help-Center

     

    We would really appreciate it if this feature would be implemented in the near future. Our KB editors are not trained for writing HTML so this would make the writing/editing process a lot easier for them.

     

    3
  • Catalytic Services
    Actions pour les commentaires Permalien

    The ability to enter articles using markdown formatting would be huge for us. Most of the other tools we're using support markdown, so copying content into Zendesk is always a headache.

    0
  • Robert Orzanna (Sheetgo)
    Actions pour les commentaires Permalien

    One more vote for adding Markdown support to the article editor! :-)

    1
  • Romain Pichard
    Actions pour les commentaires Permalien

    Hey,

    One more vote for adding custom style in WYSIWYG to format text without having to change the HTML code manually.

    Thank you ! :)

    1
  • Chaz Spahn
    Actions pour les commentaires Permalien

    +1

    I am in full agreement with Florian and I think those examples of how the Zendesk site is using features we need are perfect!! See below...

    We need:

    • Notes; Tan background, rounded corners
    • Warning; Yellow background, warning triangle icon, border
    • Error; Red background, stop icon, white text, border
    • Code; Grey background, monospaced font, scrollable for long lines, border

    __________________________________________________________________________________

    This text in the https://support.zendesk.com/hc/en-us/articles/206401358-About-search-engine-optimization-SEO-in-Help-Center:

    Has this source:

    Which if copied into the source, in the editor, gives you this:

    0
  • Ryan McGrew
    Actions pour les commentaires Permalien

    Hey all,

    Today we've rolled out an ability to insert code blocks as pre-formatted text in the article editor. It's a small change and doesn't include syntax highlighting, but will hopefully will make it a little easier to insert code into your articles.

    We will continue to take more advanced functionality as a product feedback.

    Thanks!

    0
  • Rebecca McMurry
    Actions pour les commentaires Permalien

    Thanks Ryan!

     

    Any news about Florian's request for 

    • Notes; Tan background, rounded corners
    • Warning; Yellow background, warning triangle icon, border
    • Error; Red background, stop icon, white text, border
    • Code; Grey background, monospaced font, scrollable for long lines, border
    2
  • Jonathan March
    Actions pour les commentaires Permalien

    @Ryan, Thanks, code block support is good news, but the implementation seems unfortunate to me. Can you explain why the decision was made to use </br> inside the <pre> block  rather than the MUCH more readable inclusion of EOL characters in the HTML code? Does this help with multi-browser support?

    EDIT:  Here's where my comment is probably most pertinent: https://support.zendesk.com/hc/en-us/community/posts/203443366/comments/360002080267 Sorry for the duplication.

    0
  • Elizabeth B
    Actions pour les commentaires Permalien

    Formatting components I'd love to see:

    • horizontal rule (to divide text)
    • colored "callout" boxes as mentioned above (information, caution/warning, etc.)
    • icons that serve as a callout (question mark, exclamation point, i for information)
    • native options for jump links to minimize scrolling long articles
    • tabbed content

    Lotus Themes provides these - but alas, still requires html :(

    https://zendeskthemes.zendesk.com/hc/en-us/articles/115000337450

    2
  • Charles Lloyd
    Actions pour les commentaires Permalien

    Zendesk PMs what is the latest on a roadmap to add in the style basics needed for article writing into the editor?

    Either that or open up Guide so we can configure the TinyMCE editor as is described here:

    https://www.tiny.cloud/docs/configure/content-formatting/#style_formats

    Such a basic need... these posts are years old.

     

    0
  • Nicole - Community Manager
    Actions pour les commentaires Permalien

    Hey Charles -

    Longevity of a post is not one of the data points we use for prioritizing developments. Business need, number of users impacted, and market factors are the type of things we look at.

    That being said, I'll ping the product managers for Guide to see if they have anything around the editor planned for 2019. They're all away at a big planning summit this week, so response may be a little delayed.

    0
  • Ryan McGrew
    Actions pour les commentaires Permalien

    Hey All,

    We've made some incremental improvements to include some basic things like headers, video embedding, code formatting etc. in the last year. Not huge steps forward, but some improvements. I do recognize the need for configurable styles but the biggest issue is that we have to be able to support all customers with things that we provide out of the box and there's a ton of interplay between HTML/CSS create via the editor, the Help Center Theme(s) and things like the Web Widget and KC App.

    Because of the multiple publishing destination and the wide variety of things people would like to include as style types (Notes, Callouts, etc.) it would require the ability for each customer to custom define what these components are and how they will work with their themes and Web Widget. This increases the scope of the feature. 

    That being said, we are working on a feature to create re-usable pieces of content that can be used in multiple articles in Q2. This will allow you to to define the content or HTML of a content, and then place it into an article. This would start to solve the use cases that have been raised in this thread.

    1

Vous devez vous connecter pour laisser un commentaire.

Réalisé par Zendesk