877768 - In Related topics, hide the ones that are empty

Status: RESOLVED DUPLICATE of bug 881433

(support.mozilla.org :: Knowledge Base Software, task, P1)

Description

[Ibai Garcia [:ibai]]

When we moved away from Refine and Focus to Related Topics we have killed the code that removes subtopics that are empty.

This causes problems in Firefox for Android and Firefox OS. Example:
https://support.mozilla.org/en-US/products/mobile/fix-problems

All the related topics are empty.

We need to fix this before we even move to the new topic/subtopic pages.

Comment 1

[Ibai Garcia [:ibai]]

Clarification to "all the related topics are empty": Meaning that all the links in the Related Topics box point to an empty page (i.e. those topics have no articles).

This is an artifact generated by the fact that all the products are sharing the same hierarchy tree and that's not necessarily true. At the subtopic level there are many differences and at the topic level we are starting to see differences with Firefox OS.

Based on the IRC conversation on the topic, this is not a trivial solution so we should all agree on what's the best moving forward. Some solutions discussed on IRC:

- Make Topics to be product specific. With this model "Getting Started" for Firefox for Android is different than "Getting Started" for Firefox Desktop. These method give us extra flexibility at the cost of needed to adapt the "Edit Description" section of the "Edit articles" pages to make sure that is clear which topic you need to select depending of the article that you are working with (nested presentation of the topics, maybe?)

- Pull the subtopics that the articles of an specific topic have anytime somebody lands on a topic page. This would make it easier to maintain the content. Performance could be damaged and the effects of too much automation mean that we lose visibility of what will show up for a specific page (it's less straight forward).

More? Probably there's something in between that we could do too.

I'm adding this to the next sprint tentatively. We should fix this ASAP.

Comment 2

[Kadir Topal [:atopal]]

Ibai, the latter is what I asked for here: https://bugzilla.mozilla.org/show_bug.cgi?id=868208#c12

Ricky, was there an issue with implementing that? I'd still say that's the most straight forward solution, and we don't need to rebuild the content of the topic pages all the time, only when an article's product is changed. Which is essentially only when we add a new article. We don't add new articles all that often.

Having completely separate trees for products might cause issues for maintainability. We have articles like the sync ones that are shared between desktop and mobile. We'd need to either find a workaround or create duplicate articles. Also, the more "education" themed articles we add the more we'd need to duplicate, if the articles are not product specific. 

On the other hand, having strict separate trees for products would make it possible for us to implement bread crumbs easily. Not sure if that's enough of an upside though.

The maintainability issue is of course for our content manager to decide. CCing Michael

In any case, this is a blocker for the topic pages. Without solving this we'll crate links in the main content area that link to empty pages, and the topic pages might become incredibly long.

Comment 3

[Ibai Garcia [:ibai]]

Having a non-strict hierarchy is creating way too many issues with dependencies that are hard to prevent.

The only issue that you are commenting on for articles is resolved if articles can belong to multiple topics and subtopics.

In a more schematic way:
- Today: Articles can belong to multiple subtopics. Subtopics can belong to multiple topics. And topics can belong to multiple products.
- Tomorrow: Articles can belong to multiple subtopics/topics but subtopics only belong to one topic and topics only belong to a product.

This solution would not simplify the problem with breadcrumbs but it would be a way more predictable system to maintain from the CM point of view. 

If breadcrumbs are a problem that we want to resolve, we can create the concept of pointer articles that are only redirects to the real article (we can reuse the redirect system that we already have...I think).

How does this sound?

I'm marking https://bugzilla.mozilla.org/show_bug.cgi?id=862122 as a blocker for this bug. Almost any solution requires to remove the concept of starting with Tasks/Topics.

Comment 4

[Verdi [:verdi] Best to slack me]

I think Ibai's proposal will work. If I understand it correctly, each product will have it's own topic/subtopic tree and only show topics and subtopics in that tree. Articles on the other hand can exist in more than one place (like they can currently). 

This will allow, for example, "Firefox Sync data is secure - Find out more" to still show up in both Firefox > Customize controls, options and add-ons > Firefox Sync settings AND Firefox for Android  > Customize controls, options and add-ons > Firefox Sync settings. And will prevent us from having to hide subtopics without content like Firefox for Android  > Customize controls, options and add-ons > Bookmark options.

In this way we'll have a strict hierarchy without unnecessary duplication of content. It will also give us something to base breadcrumbs on. For users coming from Google to a multi-product article we can either show no breadcrumb or default to the largest product breadcrumb.

Comment 5

[Ricky Rosario [:rrosario, :r1cky]]

Closing this in favor of our new approach described in Comment 4 => Bug 881433