192 Comments

  • Lou Abigail Menard
    Comment actions Permalink

    Hi ,

    Now that the new 'permisions' feature has now been delivered (cheers to that!) , do we expect that the more flexible hierarchy (Sections within sections) will also be delivered soon?

    As per post of Ryan above ->  "We're hoping to have an EAP available for this in Q4 2018" .

    We are really looking forward to this!

    Also for the Q1 2019 target for publishing articles to multiple sections.

     

    :)

     

    1
  • Daniel Oakley
    Comment actions Permalink

    @Elizabeth B - Unless you're willing to get real specific with your category names you'll need to make your categories quite broad and have them contain a lot of articles. We focused on the search bar a whole lot more than we expected to, because honestly it was difficult to properly find articles without building some complex custom system on top like Chellie did.

    Don't wanna be a downer but we ended up switching away a short while ago, has been good to have some more functional KB support. Hopefully the schedule that Ryan and the team are working with comes through and there'll be some much improved support in ZD soon!

    1
  • Darcy Fitzpatrick
    Comment actions Permalink

    Desperately need to see this extra level built in. Our app is on iOS, Android and Web and we prefer to keep articles organized by platform, but that then leaves us with just one other level before articles, and as our product lines and KB have grown it's just made a mess of everything. 

    Could we get an update on the progress for this? Thanks!

    1
  • Darcy Fitzpatrick
    Comment actions Permalink

    Thanks for the update, Nicole. Glad to know it's in active development, but sounds like it's going to be a while yet. Which we can't really wait for.

    This means we're going to have to redo our entire KB and combine all three platforms into a single article rather than having separate articles for each in their own Categories. Which isn't the end of the world -- it's going to be a lot of work but has forced us to realize there are benefits to doing it this way that we weren't seeing before.

    1
  • Elizabeth B
    Comment actions Permalink

    Thanks for the update Benjamin! I did see the permissions changes in Guide, and read here that it was a pre-req for additional sub-cat's, - so am optimistic. We're using Guide for both internal/external use - obviously for many public KB's of FAQs you don't want to go more than 3 levels deep. But the complexities of internal documentation often necessitate it. Looking forward to the release! PS - what does EAP mean?

    1
  • David Burke
    Comment actions Permalink

    Thanks Bogdan! I propose a Sub-sections party once it goes live.

     

     

    1
  • Bogdan Andrei Sturzoiu
    Comment actions Permalink

    Hey everybody!

    I'm happy to announce section-in-sections (a.k.a. Flexible hierarchies) is now officially in EAP: https://support.zendesk.com/hc/en-us/community/topics/360000031708

     

    1
  • Allison S
    Comment actions Permalink

    Hi there, 

    Just checking in on the status of the EAP? I signed up on 12/17/18, still haven't heard back. I am eager to try this functionality out! Thanks!

    1
  • Jessie Schutz
    Comment actions Permalink

    Hey guys!

    Thanks very much for the feedback on this! I've gone ahead and moved this post over to our Product Feedback forum, so other folks who might find this useful can add their votes and use cases.

    0
  • Sergey
    Comment actions Permalink

    Feels good to know that this is an issue requested by many other members of the community.

    Our team needs a simplified hierarchy, we want to be able to only have two levels: sections-articles. As we're building the mobile app, we want our FAQ within it to be as simple and straight-forward as possible. This will not only help our users find the information faster but also deflect tickets that could have been sent to our tiny support team.

    Could any Zendesk developer provide a comment regarding this matter? Is it currently being developed or postponed until later?

    0
  • Christian Colding
    Comment actions Permalink

    Hey guys,

    I wanted to just thank you all for pitching in with your feedback and use cases. There is no doubt that it helps us to understand how we could build this.

    Unfortunately I don't have much of an update since the comment I wrote back in January. We definitely understand the need and if we could, we would change this tomorrow. But making this as flexible as we want to, is a very daunting task. It's like we would do open brain surgery on Help Center. That is not to say that we don't want to do it - we do - but just that it will be a while before we can actually improve this.

    0
  • Alex Gerulaitis
    Comment actions Permalink

    Gmail didn't offer nested tags at first either. Then it did, and it didn't help a whole lot. I suspect most of those tags and filters get entangled into an unruly mess and that's exactly why Google came up with their new tabbed experience and Microsoft - with "clutter". Which isn't going to help ZD much either - document space is a whole different animal... :) Once thing for sure: tags can't be a sole hierarchy and navigation mechanism, if for one reason alone: security. Can't assign an ACL to a tag unlike a section. Hence at least one - yet a major - reason for freely nesting sections: ACL inheritance. Not Level 2 or Level 3 - but freely (as many as one chooses) nesting ones.

    Even a small enterprise support group needs multiple ACLs in their KB: junior agents don't need to, and often aren't allowed to, have access to higher level docs. Creating a new "brand" just for the purpose, or maintaining a separate doc space (sites? sharepoint? confluence? - all unlimited nesting btw) - unlikely a viable approach.

    Samantha and Chellie - thank you big time for communicating the user perspective and helping to shape up ZD's response and position.

    0
  • Christian Colding
    Comment actions Permalink

    Hi Alex,

    I completely agree with all your feedback.

    That is also why we need to figure out how we do this the right way. While the underlying technology might end up being tags, we still need to make it easy to use and flexible at the same time. That goes no matter what type of technology we go with.

    0
  • Lauren
    Comment actions Permalink

    + 1 on the option to add subsections to a section.

    0
  • Chellie Esters
    Comment actions Permalink

    @Greg Sohl, I ended up hand-coding the help center to death to create the illusion of sub-sections. I work for a software company so I had the means to do so, but it's not a solution. Please let us know, ZD, when we can use actual sub-sections.

    Chellie

    0
  • Greg Sohl
    Comment actions Permalink

    Roadmap?????

    0
  • Corrin Duque
    Comment actions Permalink

    Thanks for your response Christian.  

    As we too have a complex software to service platform we are constantly optimizing, I recognize the complexity of making a change and the importance of gathering specific needs from a large customer pool so as to design a best fit solution.  Creating an option to select additional tiers also requires that the new options allow for all existing Help Centers to remain completely operational and functions.  Making this a seamless transition is formidable.  So, I completely appreciate the leg work going into the dev teams evaluation, needs assessment, and requirements and risk analysis.

    Look forward to updates.

    And hope other ZD-Help Center users will chime in to articulate their specific level of need and articulate what that looks like.

    0
  • Emilie Vittini
    Comment actions Permalink

    Hey, +1 on the sub-sections.

    0
  • Jennifer Woodson
    Comment actions Permalink

    I made my own post, but I'm adding my vote here too, for a more flexible hierarchical structure. I don't need three tiers, and I would like the ability to remove one.  

    0
  • Andy Minshall
    Comment actions Permalink

    The reason we also need this is, unlike the other 95%+ of Zendesk customers it would seem, we are needing to support two products inside one Help Center.

    An additional level to house FAQ, Help, Videos, etc on the functional use of our software is difficult in itself, but we have a huge overlap of users that need to access the information on two products as we transition the products into one (a long while off).

    Each way I turn, to organise documents by Product or by Article Type, we hit the limit right away. Any solution we have is not ideal and clunky, so please can we get an update on this soon?

    Thanks!

     

    0
  • Daniel Oakley
    Comment actions Permalink

    This is practically required for our help centre. Unfortunately, just two levels of organisation simply isn't enough to make the sort of content we need to put into our knowledge base properly manageable.

    I understand that ZD wants to investigate other options and alternate ways to solve this, but this is something that should be looked at fairly soon.

    Given issues like this, it seems like the easiest way to go would be to keep categories, make sections nestable (so a section can go under either a category or another section, with the appropriate checks to make sure silly loops and such don't happen), and then let articles be attached to either categories or sections.

    Especially if you wanted to support letting articles get attached to categories themselves, it could even be worth looking at consolidating categories and sections into the same object (i.e. turn both Categories and Sections into a new object Section. Make it so Sections can contain other Sections and can contain Articles).

    Just an idea, but however you solve it, it would be really nice to see this looked at soon. This is hampering the capabilities of our knowledge base.

    0
  • Chellie Esters
    Comment actions Permalink

    I had our product development team build our Help Center using custom code and APIs to give the 'illusion' of multiple levels, so the information can be segmented the way I needed. Unfortunately, that caused severe limitations with API calls and translation methods. Months of development work (that is slow and buggy due to ZD's own APIs, mind you), all because flexible multi levels are not supported. UUUUGGGGGHHHHH!

     

     

    0
  • Mike Woodard
    Comment actions Permalink

    It would also be nice to be able to "follow" at any level from category down to article--not just section or article.

    0
  • Richard Winter
    Comment actions Permalink

    We could also make use of sub-sections or tagging, either feature would allow us to improve our Knowledge Base.

    0
  • David Conway
    Comment actions Permalink

    I agree with the need for subsections as it will greatly help in organizing articles in the knowledge base.  Sure we would want the users to just search, but there are a lot of users who like to drill down and look for the article rather than searching.  This would also make the Help Center look and feel cleaner.  Otherwise, we would have to make several categories or sections.  This would just confuse the users and they would simply not use the system at all.  I have seen this type of behavior with users on several applications.  Subsections would be more of an added value to Zendesk than it would take away from it.  Thanks.    

    0
  • Åsa
    Comment actions Permalink

    This is definitely needed. The current 3-level system is not adequate for complex product documentation.

    0
  • Hanz Thumas
    Comment actions Permalink

    Same here.. Very much in need of subsections or nested ones. Don't care how it's solved. Just as long as we're finally presented a solution for this - and many other things I might add..

    I'm growing a little tired of the gruesome time it takes for Zendesk to provide customers with what is clearly needed.. 2 years? and in the mean time not a thing has changed? Maybe Freedesk is more willing to provide its customers with proper service.. for half the price.. It is becoming very unclear to me why we pay so much for the enterprise version while customer service (and satisfaction) is below average..

    0
  • Simon Andersson
    Comment actions Permalink

    I agree. It's absolutely worthless not being able to use subsections in the Help Center.

    0
  • Linda Larsson
    Comment actions Permalink

    Can we please get an update on this? I hope it could be something else than that ones we've been getting that past few years telling us it won't be fixed in "the near future"...

    It's becoming very tiresome to run into this issue again and again when trying to come up a better way to organise the knowledge base.

    0
  • Christian Colding
    Comment actions Permalink

    Hi Greg,

    My replies are below:

    • When will the research be completed? Is there a goal date?
      We do not know when research will be completed. When you don't have a clear picture of the problem you are trying to solve, it's difficult to say when you're gong to solve it. The research intends to solve the problem, after which we'll start to actually build it.

    • Where are the surveys of users from this list, gathering requirements? Your users can be one of the most substantial points of research input.
      We have started with conversations. I talk to many different custmers about this. The problem here isn't so much to understand it from a customer perspective. The problem is to understand how we can solve it from a product perspective. What can we build that will effectively solve the problem? What can we build with our current architecture? What can we do if we change the architecture? What architecture needs are requires? What does changing the architecture mean to existing customers? What do we do with migration from the old way of classifying your content to the new way? etc.

    • Where is this on the Zendesk road map?
      I am not entirely sure what you are asking here. As mentioned we have yet to figure out how to build this and how long it's going to take, before we can start to talk about potential timelines, which directs me to your next question.

    • What is "very long"? 6 mo? 6 yrs?
      It's difficult to say, but I would say at minimum a year. It all depends on what solutions we reach, how we are going to build them, which resources we have available (etc.) which goes back to conducting research.

    Regarding your other comments, then I would like to point out that we actually do understand the user requirements very well. There are just many different use cases that we then need to make sure that we solve with the same solution. We don't want to spend significant time building something that doesn't solve the problems. We should make sure to have a solid solution that we know will work, before we start building it. We are definitely committed to solving this problem, but it's difficult to commit to solving it before you truly understand it. That's what we are working on.

    Luckily we learn from our mistakes. The reason research and finding a solid solution is so important, is because we don't want to end up in a situation like this again. Imagine we just added another level. Then we could spend a lot of time building that, but it wouldn't really solve the problem and would significantly delay a real solution. We do not want to make that mistake again.

    We want to do the right solution and we'll only do that by truly understanding the problem from all possible perspectives.

    0

Post is closed for comments.

Powered by Zendesk