SUMO community discussions

SUMO Information Architecture Project – Phase 1

  • 8 replies
  • Last reply by Matt_G
  1. Michael Verdi
    Michael Verdi 1755 posts
    more options

    Here are the links to the presentation:

    Here are the links to the presentation: *[http://sumo-cdn.mozilla.net/media/uploads/gallery/videos/2012-02-10-13-15-16-6fb33a.ogv Audio of the presentation] (actual presentation starts at 8:30) *[https://docs.google.com/presentation/d/1W8r_eMewxTX2ImDWd-SPLMAF-lrAozvpPDqL-mdI2NA/edit?pli=1#slide=id.p Slides] *[https://docs.google.com/document/d/1gUwc9wlRxruNBr7VheGDNN3mIvIPAxXWmSyFds3fhNg/edit Data Analysis doc]

    Modified by Michael Verdi on

  2. Matt_G
    Matt_G 167 posts
    more options

    Awesome Verdi! Thanks for the links. I'll check them out tonight when I get home from work.

    Awesome Verdi! Thanks for the links. I'll check them out tonight when I get home from work.
  3. John99
    John99 3665 posts
    more options

    Interesting, I will have to listen again, but some initial comments on the audio.

    I am glad you posted this, it is nice to hear this sort of detail about your plans and research.
    Maybe there are massive changes ahead, including changes and reversals of current policies, but as long as they are thought through carefully they should be improvements especially if based on usage evidence.

    Literacy If we are to cope well with our large amount of "pre-literate" users and work to reduce ranking of SEO of Mozillazine articles I hope something will be done to enable contributors, potential contributors and the slightly more technical users also be able to obtain information, otherwise how do new contributors learn anything.

    Tags are mentioned.

    Who is going to do all this tagging?
    Am I correct in believing you intend some new sytem where for instance users start tagging posts, I think Crystal was mentioning tagging from some sort of *controlled vocabulary* I had an idea some modern models promote allowing users freedom to choose their own self organising tags.

    What is it that is going to benefit from these new tags ? solved posts, all posts, almost all articles including other products

    AAQ Search precedence Evolving forum articles is interesting,
    (as discussed in the closing comments,) my view on part of that is that the contributors forum may be a better place for say model answers. Look for instance at the current thread on Firefox 10 and ESR. I think we are a long way off ever being able to get that sort of quality of info in the support forum questions. Support threads tend to be a muddle and the ludicrous highlighting of solution plus first two answers is not a very good presentation method. Unfortunatly that sort of issue also exempifies the KB failings, latest firefox issues just does not keep up with events!

    If we keep KB articles at a limit of say about 150 articles, as the current thinking is (due to maintenance costs) then the current idea of keeping them at the top of search results makes sense. If AAQ articles regularly come up above the KB in ranking you will get a nightmare situation in controlling content. ( My personal view is I am all for allowing KB articles to be more dynamic and easier to edit, - it is currently effectivly a private closed edit Wiki - but if AAQ are alongside or above AAQ you may as well move to a totaly open and unreviewed edit system on of the KB )

    Integrating all products is an interesting concept, has anyone for instance discussed possible dovetailing with Thunderbird with our counterparts (or even made them aware of this presentation)?

    I have not looked at the docuent yet iirc there was mention of it being 500+ pages.

    Interesting, I will have to listen again, but some initial comments on the audio. '''I am glad you posted this, it is nice to hear this sort of detail about your plans and research.'''<br/> Maybe there are massive changes ahead, including changes and reversals of current policies, but as long as they are thought through carefully they should be improvements especially if based on usage evidence. <u>Literacy</u> If we are to cope well with our large amount of "pre-literate" users and work to reduce ranking of SEO of Mozillazine articles I hope something will be done to enable contributors, potential contributors and the slightly more technical users also be able to obtain information, otherwise how do new contributors learn anything. <u>Tags</u> are mentioned. Who is going to do all this tagging?<br/> Am I correct in believing you intend some new sytem where for instance users start tagging posts, I think Crystal was mentioning tagging from some sort of *controlled vocabulary* I had an idea some modern models promote allowing users freedom to choose their own self organising tags. What is it that is going to benefit from these new tags ? solved posts, all posts, almost all articles including other products <u>AAQ Search precedence</u> Evolving forum articles is interesting, <br/> (as discussed in the closing comments,) my view on part of that is that the contributors forum may be a better place for say model answers. Look for instance at the current thread on Firefox 10 and ESR. I think we are a long way off ever being able to get that sort of quality of info in the support forum questions. Support threads tend to be a muddle and the ludicrous highlighting of solution plus first two answers is not a very good presentation method. Unfortunatly that sort of issue also exempifies the KB failings, [[latest firefox issues]] just does not keep up with events! If we keep KB articles at a limit of say about 150 articles, as the current thinking is (due to maintenance costs) then the current idea of keeping them at the top of search results makes sense. If AAQ articles regularly come up above the KB in ranking you will get a nightmare situation in controlling content. ( My personal view is I am all for allowing KB articles to be more dynamic and easier to edit, - it is currently effectivly a private closed edit Wiki - but if AAQ are alongside or above AAQ you may as well move to a totaly open and unreviewed edit system on of the KB ) <u>Integrating all products</u> is an interesting concept, has anyone for instance discussed possible dovetailing with Thunderbird with our counterparts (or even made them aware of this presentation)? I have not looked at the docuent yet iirc there was mention of it being 500+ pages.
  4. AliceWyman
    AliceWyman 6489 posts
    more options

    I'm impressed, especially with the proposed product and KB landing pages that lets you filter Firefox support content by category/topics. I've always missed the ability to browse Firefox KB articles by subject area, like you still can with SeaMonkey's in-product Help "Table of Contents" (SM2.7 screenshot).

    I also like the idea about linking to "forum articles". Similar ideas were mentioned here in the past, about a ""Frequently asked questions" listing pointing to support forum answers for common questions. We just started doing this in new KB articles linked from the interim Firefox Home page "Top Issues" section (e.g., Fix problems with your home page or search) and it's especially useful for emerging issues which can be answered immediately in a forum post, while the KB article editing and approval process takes much longer. In other words, two-tiered support content:

    • Formal KB articles that explain about the Firefox UI and "How to" accomplish tasks or customize Firefox, as well as some well-known "Troubleshooting" issues
    • A more informal set of answers by top contributors that we can tag as "FAQs" or "Common Issues", to cover emerging issues. These "forum articles" should come up at the top of search results, along with KB articles, and should be locked to prevent "spam" (a moderator can unlock, to edit). These forum articles could also form the basis of new KB articles.
    I'm impressed, especially with the proposed product and KB landing pages that lets you filter Firefox support content by category/topics. I've always missed the ability to browse Firefox KB articles by subject area, like you still can with SeaMonkey's in-product Help "Table of Contents" ([http://img706.imageshack.us/img706/9353/sm27help.png SM2.7 screenshot]). I also like the idea about linking to "forum articles". Similar ideas were mentioned here in the past, about a ""Frequently asked questions" listing pointing to support forum answers for common questions. We just started doing this in new KB articles linked from the interim Firefox Home page "Top Issues" section (e.g., [[Removing Babylon, SearchQU or MyStart]]) and it's especially useful for emerging issues which can be answered immediately in a forum post, while the KB article editing and approval process takes much longer. In other words, two-tiered support content: *Formal KB articles that explain about the Firefox UI and "[/kb/category/20 How to]" accomplish tasks or customize Firefox, as well as some well-known "[/kb/category/10 Troubleshooting]" issues * A more informal set of answers by top contributors that we can tag as "FAQs" or "Common Issues", to cover emerging issues. These "forum articles" should come up at the top of search results, along with KB articles, and should be locked to prevent "spam" (a moderator can unlock, to edit). These forum articles could also form the basis of new KB articles.

    Modified by AliceWyman on

  5. John99
    John99 3665 posts
    more options

    I note the report document recommends

    The categories of KB items given as examples, such as https://support.mozilla.org/en-US/kb/category/10 will currently contain obsolete / archived articles

    • producing more KB articles, even if we are not able to localise the articles.
      Any embargo to keep below 175 was I understand a temporary solution, Are we returning soon to a situation where anyone can propose a new article, and there will be a good chance of it being accepted on merit, and not being rejected on the grounds of the total number of KB articles being too high.
      • current guidlines_archiving-articles
        . Ideally, we should have about 175 articles. That will allow us to document things in enough detail while being small enough to maintain and localize.
        Stress the problem of needing to localise being a pressure that is limiting the number of articles.
    The report recommends (p34)
    Recommendation: The KB articles are great. It would be better to have more of them. If they can be authored faster in English, don’t wait for localization to make the articles available. Many people prefer English documentation for its accuracy (real or imagined), and eventually localization will get to them, especially if they are particularly useful.
    I note the report document recommends * removing obsolete articles from the obvious listings <br> page 33 & 34 of https://docs.google.com/document/d/1gUwc9wlRxruNBr7VheGDNN3mIvIPAxXWmSyFds3fhNg/edit?pli=1 The categories of KB items given as examples, such as https://support.mozilla.org/en-US/kb/category/10 will currently contain obsolete / archived articles * <u>producing more KB articles, even if we are not able to localise the articles.</u> <br/>Any embargo to keep below 175 was I understand a temporary solution, Are we returning soon to a situation where anyone can propose a new article, and there will be a good chance of it being accepted on merit, and not being rejected on the grounds of the total number of KB articles being too high. ** current [[how the knowledge base works#w_archiving-articles |guidlines]]_archiving-articles <blockquote>. Ideally, we should have about 175 articles. That will allow us to document things in enough detail while being small enough to maintain and localize. </blockquote> Stress the problem of needing to localise being a pressure that is limiting the number of articles. [https://docs.google.com/document/d/1gUwc9wlRxruNBr7VheGDNN3mIvIPAxXWmSyFds3fhNg/edit?pli=1 The report recommends] (p34) <blockquote>'''Recommendation: The KB articles are great. It would be better to have more of them.''' If they can be authored faster in English, don’t wait for localization to make the articles available. Many people prefer English documentation for its accuracy (real or imagined), and eventually localization will get to them, especially if they are particularly useful. </blockquote>
  6. John99
    John99 3665 posts
    more options

    Policy on Downgrading Firefox Versions
    The study is apparently coming out firmly in favour of the need to allow and explain easy downgrading in emergency[1] situations. This is would need a very major global policy change I believe. Downgrading is generally of course discouraged. We deliberately:

    • remove links to the now unsupported version downloads [2] even if someone has upgraded only within the past few minutes they will not see links for the old version (so currently think Firefox 9 to 10 to 10.01)
    • we deliberately prevent users seeing the likely breaking issues of the new version [3] because it may put them off upgrading
      ( I agree users may be put off upgrading if startup crashes may have been likely, that is one reason for the chemspil1 release [4] but not imho a reason to make the fact hard to discover, even if it is only affecting 100 thousand users)

    So to re-iterate it appears that some of these IA changes are actually requiring policy change

    • e.g. despite fast release cycle have easy downgrade to unsuported version.
    • And KB and other article writing e.g. allow easier editing of KB articles and more of them, and presumably more co-operation regarding writing and content of other articles that are easily exposed and linked as the changes are tested and implemented.

    [1] report

    p42 Recommendation: There are lots of good reasons people need downgrades. If they are not freely available, there should be a fast way to make the case in the forum that one is needed.
    p43 Recommendation: Compatibility is a big deal, and it’s not best dealt with after an irreversible update. While it’s laudable to try to eliminate update hassles by doing it in the background, if your most important plugins are left inoperable or you can’t log in to your extranet at work anymore, that’s pretty disempowering, and it can drive people to other browsers. Registering and posting in the forum to try to resolve such issues is not the way to go. It won’t scale. It would be great if people could have an undo if they find themselves in a situation where they can’t work anymore because of an upgrade surprise and the inability to log in afterward. Maybe for most people it’s not a problem, but for those who are rendered unproductive, it’s an emergency.

    [1 additional]Susans report

    p42 Recommendation: Many people want to know what version of Firefox they have, so they can figure out if it’s compatible with other software and websites they need to use. Make this really easy to discover on SUMO. Apparently the menu item is not always being found. They also want to know if it’s 32- or 64-bit.

    Isn't that also against the new current philosophy on rapid and silent updates: there will be one version of Firefox therefore users need not bother about the version if they are using Firefox it should be uptodate

    [2] our current downgrade advice, note if links followed they will lead to an article linking Firefox 3.6 only, and even that will presumably be removed shortly

    [3]Verdi's reasoning behind decision for not providing info
    link We don't want to discourage users from upgrading. Upgrading is good and warranted for 99+% of people. These issues are only a problem for a very very small proportion of our users. As it stands right now, people with the previous version can see the issues with that version, including the notes that many of them are solved by updating. For fx 8 and below I tell people to update because they are on an insecure version.

    [4] Firefox 10.0.1

    ?? was the bug mentioned above resolved unlocked and linked to from anywhere, we still have reports of startup crashes, even on 10.0.1we are aware of hundreds of startup crashes

    <u>Policy on Downgrading Firefox Versions</u> <br/> The study is apparently coming out firmly in favour of the need to allow and explain easy downgrading in emergency<sup>[1]</sup> situations. This is would need a very major global policy change I believe. Downgrading is generally of course discouraged. We deliberately: * remove links to the now unsupported version downloads <sup>[2]</sup> even if someone has upgraded only within the past few minutes they will not see links for the old version (so currently think Firefox 9 to 10 to 10.01) * we deliberately prevent users seeing the likely breaking issues of the new version <sup>[3]</sup> because it may put them off upgrading <br/>( I agree users may be put off upgrading if startup crashes may have been likely, that is one reason for the chemspil1 release <sup>[4]</sup> but not imho a reason to make the fact hard to discover, even if it is only affecting 100 thousand users) So to re-iterate it appears that some of these IA changes are actually requiring policy change *e.g. despite fast release cycle have easy downgrade to unsuported version. * And KB and other article writing e.g. allow easier editing of KB articles and more of them, and presumably more co-operation regarding writing and content of other articles that are easily exposed and linked as the changes are tested and implemented. --------------------- [1] [https://docs.google.com/document/d/1gUwc9wlRxruNBr7VheGDNN3mIvIPAxXWmSyFds3fhNg/edit?pli=1Susan's report] <blockquote>p42 Recommendation: There are lots of good reasons people need downgrades. If they are not freely available, there should be a fast way to make the case in the forum that one is needed. <br/> p43 Recommendation: Compatibility is a big deal, and it’s not best dealt with after an irreversible update. While it’s laudable to try to eliminate update hassles by doing it in the background, if your most important plugins are left inoperable or you can’t log in to your extranet at work anymore, that’s pretty disempowering, and it can drive people to other browsers. Registering and posting in the forum to try to resolve such issues is not the way to go. It won’t scale. It would be great if people could have an undo if they find themselves in a situation where they can’t work anymore because of an upgrade surprise and the inability to log in afterward. Maybe for most people it’s not a problem, but for those who are rendered unproductive, it’s an emergency.</blockquote> [1 additional]Susans report <blockquote>p42 Recommendation: Many people want to know what version of Firefox they have, so they can figure out if it’s compatible with other software and websites they need to use. Make this really easy to discover on SUMO. Apparently the menu item is not always being found. They also want to know if it’s 32- or 64-bit. </blockquote> Isn't that also against the new current philosophy on rapid and silent updates: there will be one version of Firefox therefore users need not bother about the version if they are using Firefox it should be uptodate [2] our current downgrade advice, note if links followed they will lead to an article linking Firefox 3.6 only, and even that will presumably be removed shortly * advice [[installing a previous version of firefox]] * link entitled ALL older versions offering ONLY firefox 3.6 currently, (and probably will not even offer that or exist after firefox 10 ) http://www.mozilla.org/en-US/firefox/all-older.html [3]Verdi's reasoning behind decision for not providing info <blockquote> [/kb/latest-firefox-issues/discuss/2314#thread-reply link] We don't want to discourage users from upgrading. Upgrading is good and warranted for 99+% of people. These issues are only a problem for a very very small proportion of our users. As it stands right now, people with the previous version can see the issues with that version, including the notes that many of them are solved by updating. For fx 8 and below I tell people to update because they are on an insecure version. </blockquote> [4] Firefox 10.0.1 * forum announcement <blockquote>[/forums/contributors/708145?last=45128 link]After considering the top issues, the release drivers have decided to ship a Firefox 10.0.1 to fix two issues: <br/>1) A top startup crash (bug is security locked because it's a crash) ..... </blockquote> * release notes http://www.mozilla.org/en-US/firefox/10.0.1/releasenotes/ ?? was the bug mentioned above resolved unlocked and linked to from anywhere, we still have reports of startup crashes, even on 10.0.1we are aware of hundreds of startup crashes
  7. David Tenser
    David Tenser 343 posts
    more options

    Keep in mind that the taxonomy is not final. So while you're right that promoting downgrades should be preceeded with a discussion about it, it's not yet set in stone that we will even do that.

    Keep in mind that the taxonomy is not final. So while you're right that promoting downgrades should be preceeded with a discussion about it, it's not yet set in stone that we will even do that.
  8. Michael Verdi
    Michael Verdi 1755 posts
    more options

    Also, about the downgrading advice, I don't know if the presence of security exploits were taken into consideration.

    Also, about the downgrading advice, I don't know if the presence of security exploits were taken into consideration.
  9. Matt_G
    Matt_G 167 posts
    more options

    I finally got some free time today to go through the slides, audio, and documents. First, I just want to say what an amazing job the team has done with this project. The information you've put together is extremely valuable and it validates many of my earlier suspicions. Great work! I found the discussions around search toward the end of the meeting especially interesting!

    It was a bit hard following along with the audio, but from the slides it looks like the new navigation structure is solid. It caters to users who refuse to search. Since it is tag based instead of a traditional folder hierarchy, it also allows you to take multiple routes to reach the same piece of content. This type of navigation is extremely effective and intuitive. I like to think of it as faceted search without a query, but I've heard it referred to as a "guided" help experience as well. I'll probably have more feedback once I can see it in action.

    Susan mentioned that you might use the same set of tags for the forums as well. I think that is absolutely the right approach. This will make it easier to pull metrics around each tag across all of our support channels, giving us a better broad spectrum view. It will also make the transition from Solved Thread > KB Article much smoother. There will be some issues aligning any external content that you index (product pages or marketing docs). If you head down that path, I think I could provide some help.

    I've got a few observations and some suggestions. Many of them are search related. Hopefully it is useful.

    1. The query source needs to be passed along with the query: This seems like it shouldn't need to be stated, but I've seen it overlooked quite often. I am assuming that we will have a persistent search bar on each page. If you navigate to a particular Product/Topic combination and then choose to search from that page we should pick up the query source and filter the search results accordingly. Slide 42 seems to allude to this since we'll have human readable urls that should contain any of the tags the user has selected while navigating. We will need to be especially conscious of giving the user a visual indication that the search is pre-filtered so that they can undo the facet restriction if they choose. You can see how Yippy does this, which was mentioned in the data doc. I'd personally like to see the unselected tags collapse so that you only see your current selections. We will also need to know the query source for some of the tailored searches. There will be times where you'll want to serve a different Best Bet or Process Wizard depending on the product/version etc. If we can put a query source restriction into the rules for the Tailored Search, we will always have that flexibility.
    2. Scaffolding for Top Issues: Susan mentioned that we see a large number of searches for Facebook, email, yahoo, gmail etc. In most cases these are not Firefox issues. We can use Tailored Searches to deflect a lot of this traffic. Susan also mentioned that many people probably don't have the technical knowledge to make those distinctions. A well built Process Wizard can walk a user through figuring out if the issue is really a Firefox issue or if they are better off contacting Facebook if their account has been locked. I know some of you will remember the Process Wizard from the search demo a did a while back. They are extremely useful. The Wizard provides the "scaffolding" Susan mentioned allowing the user to move through the process at their own pace. I could also see Process Wizards showing users how to perform All the steps involved in clearing data for privacy reasons or the Troubleshoot and diagnose Firefox problems steps. A Best Bet could be used for teaching people about zoom/font size which is another issue Susan mentioned. We can play with the medium for delivery as well. I know in the demo I only showed text being returned in a Best Bet, but there is no reason why we couldn't return a video tutorial.
    3. "move bookmarks" vs "get bookmarks': You probably don't want to create a synonym match here. That will pollute the overall accuracy of the dictionary since move and get are not true synonyms. I would create a tailored search in this case that treats them as a synonym match only in the presence of bookmarks. That way our changes are localized only to this particular query and similar variations, ie move favorites, get favorites etc. This only fixes the issue locally though. Since we know many of our page views come from outside searches, it would be best to vary the references in the content when possible.
    4. 'favorites" vs "favorites": This is pretty easy to pick up in the dictionary. There are also pre-built synonym sets for regional spellings. I would assume we could find one without too much hassle and import that into the new search engine. We'll also want to grab common misspellings. These will be easy to identify in search analytics.
    5. Stemming in general: Susan made a good point that we should vary the use of our words as we author content. I know rrosario mentioned that we do have a stemming tool built into the new search engine, but in my experience most of them have limitations. For example remedies > remedy is not as simple as suffix stripping. I'm not sure how powerful stemming is in the new tool, but it is definitely something to keep an eye on.

    That is most of my notes. Sorry for the novel. As you can tell, I'm pretty excited. I'm really interested in seeing the results of the card sorting exercise. That's the true test for a logical and intuitive taxonomy. Every time I do a card sort, I'm always surprised by the results!

    Thanks, Matt

    I finally got some free time today to go through the slides, audio, and documents. First, I just want to say what an amazing job the team has done with this project. The information you've put together is extremely valuable and it validates many of my earlier suspicions. Great work! I found the discussions around search toward the end of the meeting especially interesting! It was a bit hard following along with the audio, but from the slides it looks like the new navigation structure is solid. It caters to users who refuse to search. Since it is tag based instead of a traditional folder hierarchy, it also allows you to take multiple routes to reach the same piece of content. This type of navigation is extremely effective and intuitive. I like to think of it as faceted search without a query, but I've heard it referred to as a "guided" help experience as well. I'll probably have more feedback once I can see it in action. Susan mentioned that you might use the same set of tags for the forums as well. I think that is absolutely the right approach. This will make it easier to pull metrics around each tag across all of our support channels, giving us a better broad spectrum view. It will also make the transition from ''Solved Thread > KB Article'' much smoother. There will be some issues aligning any external content that you index (product pages or marketing docs). If you head down that path, I think I could provide some help. I've got a few observations and some suggestions. Many of them are search related. Hopefully it is useful. # '''The query source needs to be passed along with the query''': This seems like it shouldn't need to be stated, but I've seen it overlooked quite often. I am assuming that we will have a persistent search bar on each page. If you navigate to a particular Product/Topic combination and then choose to search from that page we should pick up the query source and filter the search results accordingly. Slide 42 seems to allude to this since we'll have human readable urls that should contain any of the tags the user has selected while navigating. We will need to be especially conscious of giving the user a visual indication that the search is pre-filtered so that they can undo the facet restriction if they choose. You can see how [http://search.yippy.com/search?v%3aproject=clusty&v%3afile=viv_ISOxhe&v%3aframe=list&v%3astate=root|N532&id=N532&action=list&sw=|Mozilla|Download|&sec=1329251341& Yippy does this], which was mentioned in the data doc. I'd personally like to see the unselected tags collapse so that you only see your current selections. We will also need to know the query source for some of the tailored searches. There will be times where you'll want to serve a different Best Bet or Process Wizard depending on the product/version etc. If we can put a query source restriction into the rules for the Tailored Search, we will always have that flexibility. # '''Scaffolding for Top Issues''': Susan mentioned that we see a large number of searches for Facebook, email, yahoo, gmail etc. In most cases these are not Firefox issues. We can use Tailored Searches to deflect a lot of this traffic. Susan also mentioned that many people probably don't have the technical knowledge to make those distinctions. A well built Process Wizard can walk a user through figuring out if the issue is really a Firefox issue or if they are better off contacting Facebook if their account has been locked. I know some of you will remember the Process Wizard from the search demo a did a while back. They are extremely useful. The Wizard provides the "scaffolding" Susan mentioned allowing the user to move through the process at their own pace. I could also see Process Wizards showing users how to perform '''All''' the steps involved in clearing data for privacy reasons or the [[Basic Troubleshooting]] steps. A Best Bet could be used for teaching people about zoom/font size which is another issue Susan mentioned. We can play with the medium for delivery as well. I know in the demo I only showed text being returned in a Best Bet, but there is no reason why we couldn't return a video tutorial. # '''"move bookmarks" vs "get bookmarks'''': You probably don't want to create a synonym match here. That will pollute the overall accuracy of the dictionary since ''move'' and ''get'' are not true synonyms. I would create a tailored search in this case that treats them as a synonym match only in the presence of ''bookmarks''. That way our changes are localized only to this particular query and similar variations, ie ''move favorites'', ''get favorites'' etc. This only fixes the issue locally though. Since we know many of our page views come from outside searches, it would be best to vary the references in the content when possible. # ''''favorites" vs "favorites"''': This is pretty easy to pick up in the dictionary. There are also pre-built synonym sets for regional spellings. I would assume we could find one without too much hassle and import that into the new search engine. We'll also want to grab common misspellings. These will be easy to identify in search analytics. #'''Stemming in general''': Susan made a good point that we should vary the use of our words as we author content. I know rrosario mentioned that we do have a stemming tool built into the new search engine, but in my experience most of them have limitations. For example ''remedies > remedy'' is not as simple as suffix stripping. I'm not sure how powerful stemming is in the new tool, but it is definitely something to keep an eye on. That is most of my notes. Sorry for the novel. As you can tell, I'm pretty excited. I'm really interested in seeing the results of the card sorting exercise. That's the true test for a logical and intuitive taxonomy. Every time I do a card sort, I'm always surprised by the results! Thanks, Matt