1564405 - [Tracker] search results on new frontend

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: General, defect, P1)

Description

[Peter Bengtsson [:peterbe]]

Attachment: Screen Shot 2019-07-09 at 8.13.21 AM.png

Searching for: http://beta.mdn.localhost:8000/en-US/search?q=media
I get this: (screenshot)

Comment 1

[Peter Bengtsson [:peterbe]]

I was never a fan of the "excerpts" part of the search results. It's odd that they are highlighted but the title and summary are not. It's also just oddly laid out.

Kadir, can you either make a judgment call or forward this to someone who can (e.g. Nick)

Comment 2

[Peter Bengtsson [:peterbe]]

Attachment: Screen Shot 2019-07-09 at 8.21.24 AM.png

Here's what it would look like without the excerpts.

Comment 3

[Peter Bengtsson [:peterbe]]

CC'ing Schalk since he's got a good feel for design.

Comment 4

[Schalk Neethling [:espressive]]

(In reply to Peter Bengtsson [:peterbe] from comment #1)

I was never a fan of the "excerpts" part of the search results. It's odd that they are highlighted but the title and summary are not. It's also just oddly laid out.

I would also vote to not have those. I would probably also move the tags to below the relevant result. It does leave a lot of white space on the right, but that should be ok.

Comment 5

[Eric Shepherd [:sheppy]]

For my part, I think just having the summaries rather than the excerpts looks great, and is probably more useful as well.

Comment 6

[Kadir Topal [:atopal]]

Let's limit this to:

• format the the exceprts to fit in
• move tags below the excerpts

Comment 7

[Peter Bengtsson [:peterbe]]

Let's flesh this out a little bit more after our morning chat...

There's two approaches; easy band-aid fixes vs. more complex fixes.

The current (beta) site "looks weird". The display of the excerpts makes the search result look less "regular" and it's also kinda odd to have the little tags on the right. Especially since they're not clickable. (If they were clickable, would that turn the search into `freetext:WHATYOUTYPED && tag:WHATYOUCLICKED"?)
David says the reason he put the tags in on the right-hand side was to make the main content not too wide as it made it too hard to read the summary paragraphs.

One band-aid solution would be to just abandon the excerpts and/or make it something like "If it has excerpts, display that. If not show the document summary".

Another criticism is that it's odd that only the excerpts highlight based on the words you typed in. At least it should do it for the title too.
Can we add highlighting to the summary too??

Another more pressing problem is that on the current prod site, there's a set of highly opinionated filtering options. It's visually presented what those opinions are as it displays it as checkboxes that you can override. Thanks to this, it automatically filters out legacy stuff like XPCOM etc. With the new site search, old legacy (e.g. XUL) is included and might push down more relevant documents from the search results.
David made a comment that we could just do what those default filters do hardcoded'ly in view function to at least get rid of the legacy content search results.

There is a LOT we can do to make the Beta site search better. The band-aid solution of removing the excerpts arguably makes the content worst and we'd only be doing it because of UX style.

There's also another option; Make the beta site search work exactly like the current wiki site search.

The ideal option would be to almost start from scratch and do the right thing. That would involve some of Nick's UX input instead of us guessing what is right.

Comment 8

[David Flanagan [:djf]]

So, I'm not sure what the right thing to do here is, and as Peter notes, I just made this format up. We've had no formal design guidance on it. (Execpt, I'm pretty sure that Nick has agreed that it is good to get rid of all the checkboxes on the current site.)

I put the tags in because:

• elastic search was returning them to me
• if you search for something vague like "element", the tags often disambiguate and make it easy to see which results are HTML, which are DOM API and which are CSS pages.
• displaying the tags gave me a way to do a two column view so that the line length didn't get too wide.

Originally, I left the excerpts out entirely and just displayed the title and summary. It would be simple to revert to that. Arguably it is better than what we've got now which is title and excerpts. On the other hand, when you search for something obscure like "foo" which is not a page title, then the excerpts show you something that you don't otherwise get. I don't feel strongly about the excerpts. The simplest thing would be to take them out for now and see if anyone misses them.

If we do keep the excerpts, then we at least need to fix the word wrapping issue. Apparently I expected that excerpts would be short and always fit on one line. Maybe something changed, or maybe I just didn't test enough, but searching for "element" returns some super-long excerpts that break the layout, and that needs to be fixed.

Hardcoding a manual filter to remove archived results on the client-side seems like a good short-term idea. Maybe there is a better way to encode that filter directly into the ES query, which would be better. And removing those pages from the index completely might be an ever better idea. (Though I expect that the wiki site would still want the pages to be searchable, so this would mean having two different indexes).

Comment 9

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/kuma/pull/5562

Comment 10

[David Flanagan [:djf]]

Peter: PR #5562 fixes the immediate ugly problems of having long excerpts and non-wrapping excerpts. I'd suggest landing this for a short-term fix and then figuring out a longer-term redesign.

Comment 11

[David Flanagan [:djf]]

Peter: I'm assigning it to you because I won't be around, and just don't want the PR to get forgotten. Feel free to unassign if that doesn't make sense, though.

Comment 12

[Kadir Topal [:atopal]]

A few more issues, and we might turn this into a tracker bug for the search:

• The URL of the results are shown, but they are not clickable
• Without the tags, the line length is now full width, reduces readability
• The list is not paginated. It looks like 40 elements are shown. There is no "next" button to go through results further down the list
• There is no information on how many results were found. Combined with the above, you might be looking at all the results, or maybe not
• As was already mentioned: no filters are applied and no filters are available.

Comment 13

[Peter Bengtsson [:peterbe]]

Moved to https://github.com/mozilla/kuma/issues/5748 which will need to be broken up a bit more but it's the right direction.