963811 - Allow to search within a slug directory (e.g. /en-US/Addons/*)

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Search, defect)

Description

[willmarquardt]

What did you do?
================
1. Searched for 'timers'
2. Checked Topics > Add-ons & Extensions filter

What happened?
==============
Got useless results

What should have happened?
==========================
Should have pointed to this page:
developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/timers

Is there anything else we should know?
======================================
This may not seem important as the first result of the general search was the page I wanted, but I am trying to create a custom MDN search for add-on docs, and was hoping that a URL ending in '&topic=addons' would work.

Comment 1

[Florian Scholz (Open Web Docs)]

The page https://developer.mozilla.org/en-US/Add-ons/SDK/High-Level_APIs/timers has no tags at all.

As far as I know, the topic filter in the search is only based on document tags. While we work hard to get everything tagged properly, it might be worth thinking about what else we could do to the improve the topic filter.

Besides tagging, our content is organized in "zones" or "sections". So everything under https://developer.mozilla.org/en-US/Add-ons/* should be "Addons". Same for https://developer.mozilla.org/en-US/docs/Web/JavaScript/* which would be "JavaScript" and many more likewise. Like with tagging, we are working on moving contents into the right directory like this. Often these "sections" weigh even more than tags.

Is it possible to make the topic filter work with "sections" as described above or is it on purpose that we only rely on tagging here?

Opinions? Jezdez maybe?

Comment 2

[Jannis Leidel [:jezdez]]

:fscholz AFAIK the "sections" aren't really different to other wiki pages from a architecture point of view but the zones can be identified clearly from other documents. What troubles me is that it's not clear to me how those zones would be integrated with the search. Would they be in a separate filter group (e.g. a "Zone" topic filter group next to "Topics", "Document type" and "Skill level")? What other zones are there? Is it a finite list? How are "zones" defined at all? :)

Comment 3

[Florian Scholz (Open Web Docs)]

Trying to give some answers, also based on an irc conversation we had:

> :fscholz AFAIK the "sections" aren't really different to other wiki pages
> from a architecture point of view but the zones can be identified clearly
> from other documents.

Yes, as my two example links point out, there is no clear distinction of our content sections (yet). Zones offer a custom layout but we have other larger content sections which aren't zones. These are based on the slug path. A "tree branch" or "directory".

> What troubles me is that it's not clear to me how
> those zones would be integrated with the search. Would they be in a separate
> filter group (e.g. a "Zone" topic filter group next to "Topics", "Document
> type" and "Skill level")? 

I have no idea how we want to integrate this in the UI/UX yet. That's something we need to figure out.
"Search within the Mozilla/Add-ons tree" or "This tree and below" are ideas. I am not sure this needs to be in the UI if we come up with the query UI holly proposed. Maybe it's just one of the queries in that thing.

> What other zones are there? Is it a finite list?
> How are "zones" defined at all? :)
A collection of docs in a slug path can be called a section. A list is not ready yet. I'm kicking off a inventory project where I look at what contents we have on MDN and will hopefully have a finite list at the end. MDN is huge, there might be large directories and very small ones. Maybe the small ones are important, maybe not.

> Would *all* branches be able to searched?
Ideally, yes. That would be useful for writers as well, like if we want to find out whether we covered a topic in that directory for example. Ideally, I could imagine a prefix-search on a slug which would allow us to define the directory depth like we need it.

> Would *any* document in a zone be ranked higher? or just the startpage of a zone?
I don't think that content should be ranked higher, sections are just how we organize content

Another use case is using the json from the search. We are working on doc status pages [1] that look into the state of a section (more sections and doc status pages to come).
As the advanced search allows us to look for: macro usage, "style" attribute usage, maybe Kumascript errors in the future (bug 951775) and possibly more interesting searches, it would be nice to limit that to a specific section based on the slug directory. No one can fix all MDN content debts but if we bring them down to sections it becomes more achievable. So, this "section/slug path/directory filter" would make use of the json and wouldn't need any UI.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Doc_status

So, things will be more clear once we have an MDN inventory and a better idea of our number of important sections, but I would say filtering the search based on the slug directory generically would be a nice feature.

Comment 4

[willmarquardt]

I think the distinction between zones and tags is irrelevant to the end-user. It's a semantic debate about hierarchical vs flat organizational structure and as such is relevant to those organizing the information but not to those finding it.

From the UI perspective, a search made with the JavaScript "topic" clicked should return anything tagged "JavaScript" as well as anything under the JavaScript zone (https://developer.mozilla.org/en-US/docs/Web/JavaScript).

Comment 5

[Florian Scholz (Open Web Docs)]

Some background information about our hierarchies. Probably useful for the implementation:
Hierarchies are mapped using the topic_parent field in the document model.

Web/
Web/CSS <-- topic_parent = Web/
Web/CSS/Reference <-- topic_parent = Web/CSS/ 
And so on, recursively until there are no sub pages anymore.

So, for a command and query interface in the search, I could image to have something like:

"dir:Web/" -- I'm only interested in open web content
"dir:Mozilla/" -- I'm only interested in Mozilla docs
"dir:Web/CSS/" -- I'm interested in CSS open web content

So, whenever you have subpage, you have a branch to search in. If it is not possible to have the search doing this kind of command and query for all arbitrary branches/sub pages of the site, we can provide a list of the most important ones. We collected major MDN doc sections and they are already available on: https://developer.mozilla.org/en-US/docs/MDN/Doc_status/Overview (Alert: The list can and will change over time, though!)

The docs we want to search through in these cases are already exposed in a similar API: Kuma's $children, which makes use of topic_parent also. The "dir:Path" search like above would search in exactly the same docs like here:

https://developer.mozilla.org/en-US/docs/Web$children
https://developer.mozilla.org/en-US/docs/Mozilla$children
https://developer.mozilla.org/en-US/docs/Web/CSS$children


fwiw, I agree with comment 4.
So, for the UI, I can image to just keep the current filter options, but have a mapping with the path definitions. E.g. "CSS" would still filter for the tag "CSS" but would also search in the path "dir:Web/CSS". But that's only an idea for now.

Does this all make sense? Do we need more clarifications? Feel free to ping me.

Comment 6

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.