Knowledge Base discussions

Why is there a "Related Articles" section that links to unrelated, archived articles?

  1. I first noticed this in the Secure connection and security warning error pages in Firefox article, which includes a "Related Articles" section with these archived articles listed:

       Firefox displays files as text
       Firefox exe is always running
       AUS Update XML File Not Found 404
       TypeError avg_DTFox prefs has no properties
       The protocol is not associated with any program
    


    I did an "empty" edit to see if that would fix it (it didn't) ... but then I noticed the same thing in other articles. (No, there are no "Topics" listed under Edit Description for these articles).

    I first noticed this in the [[Secure Connection Failed]] article, which includes a "Related Articles" section with these archived articles listed: Firefox displays files as text Firefox exe is always running AUS Update XML File Not Found 404 TypeError avg_DTFox prefs has no properties The protocol is not associated with any program I did an "empty" edit to see if that would fix it (it didn't) ... but then I noticed the same thing in other articles. (No, there are no "Topics" listed under Edit Description for these articles).
  2. It was a bug - James fixed it this morning - https://bugzilla.mozilla.org/show_bug.cgi?id=681807

    It was a bug - James fixed it this morning - https://bugzilla.mozilla.org/show_bug.cgi?id=681807
  3. They are now unarchived articles in the Related Articles block!

    They are now unarchived articles in the Related Articles block!

    Modified by scoobidiver on

  4. I filed [https://bugzilla.mozilla.org/show_bug.cgi?id=683726 Bug 683726 - Related Articles block is not empty when the article has no topic].
  5. Verdi said

    We still need to come up with other topics and assign them to articles so that we have better related articles. I decided to wait on feedback from Crystal's UX research before implementing something.

    I disagree for two reasons:

    1. If the block displays unrelated articles for a while, users won't pay attention to the block when the implementation comes.
    2. Crystal won't tell you which topics to create but what the block should look like.

    I think topics must be added now to articles:

    • First using questions categories (e.g. addons, data, websites, crash, features) so that searches in the AAQ workflow are right (see Bug 671927 - Take category into account when doing searches in the AAQ workflow)
    • Then with three kinds of topics such as the ones proposed in this thread:
      • Categories (also used for the front page): reference, video-tutorial, privacy, security.
      • Actions: customize, use, solve, install-update, download, load, connect, print, export, import, search, block, disable, backup, save, clear, add, autocomplete.
      • Features and miscellaneous: tabgroup, apptab, popup, tab, bookmark, profile, cookie, extension, toolbar, plugin, theme, browser, password, history, setting, session, email, accessibility, firewall, shortcut, flash, video, audio, version, error, high-usage.

    Topics must be enough numerous so that articles with the same topics should be limited to 5 for the Related Articles block display.

    ''Verdi [https://bugzilla.mozilla.org/show_bug.cgi?id=683726#c1 said]'' <blockquote> We still need to come up with other topics and assign them to articles so that we have better related articles. I decided to wait on feedback from Crystal's UX research before implementing something. </blockquote> I disagree for two reasons: # If the block displays unrelated articles for a while, users won't pay attention to the block when the implementation comes. #Crystal won't tell you which topics to create but what the block should look like. I think topics must be added '''now''' to articles: * First using questions categories (e.g. addons, data, websites, crash, features) so that searches in the AAQ workflow are right (see [https://bugzilla.mozilla.org/show_bug.cgi?id=671927 Bug 671927 - Take category into account when doing searches in the AAQ workflow]) * Then with three kinds of topics such as the ones proposed in [/forums/knowledge-base-articles/707286 this thread]: ** Categories (also used for the front page): reference, video-tutorial, privacy, security. ** Actions: customize, use, solve, install-update, download, load, connect, print, export, import, search, block, disable, backup, save, clear, add, autocomplete. ** Features and miscellaneous: tabgroup, apptab, popup, tab, bookmark, profile, cookie, extension, toolbar, plugin, theme, browser, password, history, setting, session, email, accessibility, firewall, shortcut, flash, video, audio, version, error, high-usage. Topics must be enough numerous so that articles with the same topics should be limited to 5 for the Related Articles block display.
  6. scoobidiver said

    Verdi said
    We still need to come up with other topics and assign them to articles so that we have better related articles. I decided to wait on feedback from Crystal's UX research before implementing something.

    I disagree for two reasons:

    1. If the block displays unrelated articles for a while, users won't pay attention to the block when the implementation comes.
    2. Crystal won't tell you which topics to create but what the block should look like.

    In the bug you filed, James says, "We might require that articles have > 1 tag in common to be considered related." That could be a solution to keep the block from being useless. Also, we don't have tons of repeat visitors. Most people come once.

    As for your other point, the UX feedback is not about the look of the website at all. It is specifically about things like how articles can be browsed, including strategies for a taxonomy to organize them.

    ''scoobidiver [[#post-42331|said]]'' <blockquote> ''Verdi [https://bugzilla.mozilla.org/show_bug.cgi?id=683726#c1 said]'' <blockquote> We still need to come up with other topics and assign them to articles so that we have better related articles. I decided to wait on feedback from Crystal's UX research before implementing something. </blockquote> I disagree for two reasons: # If the block displays unrelated articles for a while, users won't pay attention to the block when the implementation comes. #Crystal won't tell you which topics to create but what the block should look like. </blockquote> In the bug you filed, James says, "We might require that articles have > 1 tag in common to be considered related." That could be a solution to keep the block from being useless. Also, we don't have tons of repeat visitors. Most people come once. As for your other point, the UX feedback is not about the look of the website at all. It is specifically about things like how articles can be browsed, including strategies for a taxonomy to organize them.
  7. Verdi said

    In the bug you filed, James says, "We might require that articles have > 1 tag in common to be considered related." That could be a solution to keep the block from being useless.

    It would be useful for desktop articles, but not for mobile, sync and fxhome ones and needs to be implemented before Crystal's feedback. But Ibai said

    As a developer myself I don't like implementing things to experiment if the experimentation can be done with a workaround that doesn't require development or minimal development. Development hours are "expensive" at plenty of levels (i.e. I rather having James and his team working full steam on Search).

    Verdi said

    Also, we don't have tons of repeat visitors. Most people come once.

    As for your other point, the UX feedback is not about the look of the website at all. It is specifically about things like how articles can be browsed, including strategies for a taxonomy to organize them.

    Thanks for the stats and the feedback on the UX feedback. So let's wait.

    ''Verdi [[#post-42335|said]]'' <blockquote> In the bug you filed, James says, "We might require that articles have > 1 tag in common to be considered related." That could be a solution to keep the block from being useless. </blockquote> It would be useful for desktop articles, but not for mobile, sync and fxhome ones and needs to be implemented before Crystal's feedback. But Ibai [/forums/knowledge-base-articles/707464#post-42132 said]'' <blockquote> As a developer myself I don't like implementing things to experiment if the experimentation can be done with a workaround that doesn't require development or minimal development. Development hours are "expensive" at plenty of levels (i.e. I rather having James and his team working full steam on Search). </blockquote> ''Verdi [[#post-42335|said]]'' <blockquote> Also, we don't have tons of repeat visitors. Most people come once. <br><br> As for your other point, the UX feedback is not about the look of the website at all. It is specifically about things like how articles can be browsed, including strategies for a taxonomy to organize them. </blockquote> Thanks for the stats and the feedback on the UX feedback. So let's wait.