Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create per-control article that links all KB articles related to the control #243

Open
pepinho24 opened this issue Aug 22, 2022 · 1 comment
Labels
est: medium Estimated for 3-5 dev days feature new functionality, style, behavior etc sev: high Impacts all documentations sites

Comments

@pepinho24
Copy link
Collaborator

Is your feature request related to a problem? Please describe.

Currently, the only way to search for a KB is either go through the paged list in the KB home page (e.g. https://docs.telerik.com/devtools/aspnet-ajax/knowledge-base/). There is no way to see all KBs related to a specific control unless you use the control as a keyword in the search

Describe the solution you'd like

Ideally, each control folder would have an article where all related KB articles will be listed.

Describe alternatives you've considered

Here are some previously discussed ideas about the best way to automatically link the KB articles to the respective components:

  • Add a separate .md file for each component - This would allow great flexibility like adding additional content, and determine the name of the article per product suite
    • The name of the article is to be discussed. Generally, we agreed that More examples would be a suitable name.
  • Set the published flag to false. When the plugin which automatically generates the articles finds a related KB it will automatically set it to true.
    -Add an additional tag to each KB article like related_components and list all applicable components/controls there.
  • In order to list the KB articles to a specific location add a template like {% include ....... %}.
  • The list of KB articles will look a lot like they currently show when being searched through the docs.

Key benefits

  • SEO improvements
  • More recognition for the KB articles
  • More business scenarios covered in the documentation - KBs are generally business scenarios taken from tickets.
  • Hopefully, reduced ticket load
  • A quick way for us as support people to find KB articles

Some questions to think of

  • In which folder shall we place the KB articles that cover a common scenario that is not related to a specific component
  • Additional flag in the header (front-matter) of the dedicated article which tells the plugin for which component it is. For example target_component: grid.

This feature was separately requested by the Ajax, Blazor and some of the Desktop teams so it should benefit most if not all docs-seed based suites.

Please follow-up with some additional requirements/ideas/concerns with creating such articles for each controls.

cc: @marin-bratanov @svdimitr @Jekata @DinkoK

@pepinho24 pepinho24 added feature new functionality, style, behavior etc sev: high Impacts all documentations sites est: medium Estimated for 3-5 dev days labels Aug 22, 2022
@marin-bratanov
Copy link
Contributor

This is something we've discussed a few times, and such things have been done manually over the years, always with the effect that these lists easily get stale. Thus, an automatic feature would be nice.

I think it should be hidden behind some class in the docs-seed backend so you can plug it into any page you desire - just add something like {%relatedKb component=grid %} to your .md file and docs-seed will extract the relevant kbs with the corresponding related_component from the list and render their links (with titles, and maybe the seo title in addition, if present and different than the html title).

This will let each team decide where and how and when to use (or not use) this feature, they can enable it on demand, and plug it in any page they want to (say, even the overview of the component), and and an name their articles as they see fit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
est: medium Estimated for 3-5 dev days feature new functionality, style, behavior etc sev: high Impacts all documentations sites
Projects
None yet
Development

No branches or pull requests

2 participants