Page MenuHomePhabricator

[M] MediaSearch: display namespaces and snippets for search results on "Categories and Pages" tab
Closed, ResolvedPublic

Description

As a user of MediaSearch, I want my search results on the "Categories and Pages" tab to include namespaces, text snippets, and timestamps, so that it's easier to tell if a search result is the one I'm looking for without having to click through.

Acceptance Criteria:

  • The namespace for each result is displayed before the title
  • A text snippet for each result is displayed under the title (via gsrprop=timestamp|snippet)
  • The last updated timestamp for each result is displayed (via gsrprop=timestamp|snippet)
  • The design matches this image:

Original task:

Split from https://phabricator.wikimedia.org/T257700#6637973

On Special:Search the search results will display namespaces (if a namespace is different from the main namespace). On Special:MediaSearch the namespace are omitted. That might make it challenging for users to evaluate how relevant their search results are, especially when search terms are common words/phrases.

Note: Displaying some other info, e.g. the last update timestamp, a short description might be considered too.

SearchMedia search-Categories and Pages
Galleries with coordinatesGalleries with coordinates
Pages with mapsPages with maps

Event Timeline

@mwilliams moving this to "needs design" to see if you want to keep the same design as Special:Search (e.g. Category:Media with locations" or "Institution:Metropolitan Museum of Art" or if you'd like to indicate the namespace in some other way.

@matthiasmullie are we able to add the last update timestamp and short description as in Special:Search now that we have the generator info?

@matthiasmullie are we able to add the last update timestamp and short description as in Special:Search now that we have the generator info?

Yes, these will be available under gsrprop=timestamp|snippet

Note: text snippets are notoriously bad for files, and will be even worse with mediasearch algorithm when the match may be from statements rather than text.
But since this is for all non-file pages, I think they should be mostly fine (and I also think it'd be a welcome addition)

@matthiasmullie are we able to add the last update timestamp and short description as in Special:Search now that we have the generator info?

Yes, these will be available under gsrprop=timestamp|snippet

Note: text snippets are notoriously bad for files, and will be even worse with mediasearch algorithm when the match may be from statements rather than text.
But since this is for all non-file pages, I think they should be mostly fine (and I also think it'd be a welcome addition)

Thanks! I'm going to update the task description and acceptance criteria to add this.

CBogen renamed this task from MediaSearch: display namespaces for search results on "Categories and Pages" tab to MediaSearch: display namespaces and snippets for search results on "Categories and Pages" tab.Feb 1 2021, 1:46 PM
CBogen updated the task description. (Show Details)

Starting to try out some options here for where the namespace goes. I think the text snippet having some space in between the title and the metadata should work fine but we should limit how long that line can be so it's still legible. Adding any additional metadata, like a date can fit in the current metadata line as well.

I like option #2! I'll add it to the agenda of our next project meeting to discuss with the team engineers.

Dropped the above screenshot into Slack and got some good feedback

From @matthiasmullie

Hard to tell without a few real life lists, so might be worth trying out a few mild variations during dev and report back. I really like how #2 looks overall. Just not sure whether I prefer title-namespace (#2), or namespace-title (#1 or #3). First appeals to me visually, but I think second may be more useful: namespaces will have a more consistent length so easier to scan rapidly. And given the large differences in the kinds of content in each namespace, it’s also very important information, that I feel may not be prominent enough *after* the title.

From @AnneT

I agree: at first I liked the title/namespace styling of #2 better, but title length is incredibly variable, so it might look more consistent and be easier to understand if the namespace was first. Also, the snippets probably won’t look that nice and clean typically. Some namespaces (galleries and categories, at least) have descriptions we could use instead

Given that good feedback, I tried out a more realistic result set (the same one from the description) based on option #3, where we place the namespace in front of the title and it looks a bit like this.

CBogen renamed this task from MediaSearch: display namespaces and snippets for search results on "Categories and Pages" tab to [M] MediaSearch: display namespaces and snippets for search results on "Categories and Pages" tab.Feb 24 2021, 5:21 PM

Change 666745 had a related patch set uploaded (by Anne Tomasevich; owner: Anne Tomasevich):
[mediawiki/extensions/WikibaseMediaInfo@master] [WIP, need to implement in PHP]

https://gerrit.wikimedia.org/r/666745

A couple of notes, mostly for @mwilliams:

  • Namespaces are kinda weird on Commons! Since Commons' content language is English, namespaces aren't translated, except for the default namespace (Gallery). Also, the main namespace appears in parentheses (see Special:Search) because of the way the message is configured (see https://commons.wikimedia.org/wiki/MediaWiki:Blanknamespace). Just prepping you for what you'll see when this is done...
  • We're localizing the date by user language, so the format will vary a bit from your design: for example, in British English, the date will appear in the format of your design (DD Month YYYY), but in English it will be Month DD, YYYY. That said, I did standardize on 24 hour time since this is what currently appears on Special:Search and it's just cleaner

Here's the UI in English:

British English:

Spanish:

Let me know if you foresee any issues with these peculiarities!

  • Namespaces are kinda weird on Commons! Since Commons' content language is English, namespaces aren't translated, except for the default namespace (Gallery). Also, the main namespace appears in parentheses (see Special:Search) because of the way the message is configured (see https://commons.wikimedia.org/wiki/MediaWiki:Blanknamespace). Just prepping you for what you'll see when this is done...

We could also chose to not show the main namespace (which would be similar to current search and most other links, where the namespace is the prefix of the page title, and titles in the main namespace have no such prefix)
Like this:

  • Namespaces are kinda weird on Commons! Since Commons' content language is English, namespaces aren't translated, except for the default namespace (Gallery). Also, the main namespace appears in parentheses (see Special:Search) because of the way the message is configured (see https://commons.wikimedia.org/wiki/MediaWiki:Blanknamespace). Just prepping you for what you'll see when this is done...

We could also chose to not show the main namespace (which would be similar to current search and most other links, where the namespace is the prefix of the page title, and titles in the main namespace have no such prefix)
Like this:

To me it's confusing that the Gallery namespace is the default namespace, and I think that would confuse a lot of others as well - so I'd prefer to continue to show it.

Thanks for the heads up @AnneT!

  • Is there anyway for us to remove the parenthesis around "Gallery"? They don't make a lot of sense in this context and look pretty weird. I imagine this could be annoying but maybe some sort of brute force remove the first and last character for Gallery sorta thing. Obviously not worth it if that idea is even more brittle or time consuming than I'm guessing.
  • Agree with Carly that removing "Gallery" could be confusing. I also didn't realize that was the default.
  • That date formatting works for me!

@mwilliams to your first point, we could easily remove the parentheses from (Gallery). I'm just wondering if we should, from a community perspective, since they were configured to have the parentheses (but I don't know why). Maybe a question for @Sannita?

(Hey everybody!) @AnneT I really don't know why they put the parentheses there, probably to underline the fact that "Gallery" is the main namespace, and not any additional one. It's one of those decisions that were made when we were "young and dumb".

Anyway, just IMHO we can either go with "gallery" (without parentheses) or use "main" instead of gallery (again, without parentheses). "Main" would be my first choice TBH, since I'm not 100% sure that newbies would know that "gallery" means "main namespace" in Commonese language.

(Hey everybody!) @AnneT I really don't know why they put the parentheses there, probably to underline the fact that "Gallery" is the main namespace, and not any additional one. It's one of those decisions that were made when we were "young and dumb".

Anyway, just IMHO we can either go with "gallery" (without parentheses) or use "main" instead of gallery (again, without parentheses). "Main" would be my first choice TBH, since I'm not 100% sure that newbies would know that "gallery" means "main namespace" in Commonese language.

I'd prefer "gallery" without parenthesis. I don't think to most users the fact that it's the "main" namespace matters, but knowing they're about to click on a gallery does.

Thanks all for weighing in! I'll update this to Gallery (or whatever is configured per-language) with no parentheses (let me know if anyone has any objections)

Change 666745 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Add namespace, snippet, and last edited date to page results

https://gerrit.wikimedia.org/r/666745

Change 667830 had a related patch set uploaded (by Matthias Mullie; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@master] Also requet timestamp|snippet from non-page results

https://gerrit.wikimedia.org/r/667830

Change 667830 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@master] Also requet timestamp|snippet from non-page results

https://gerrit.wikimedia.org/r/667830

Change 668147 had a related patch set uploaded (by RhinosF1; owner: Matthias Mullie):
[mediawiki/extensions/WikibaseMediaInfo@wmf/1.36.0-wmf.33] Also requet timestamp|snippet from non-page results

https://gerrit.wikimedia.org/r/668147

Change 668147 merged by jenkins-bot:
[mediawiki/extensions/WikibaseMediaInfo@wmf/1.36.0-wmf.33] Also requet timestamp|snippet from non-page results

https://gerrit.wikimedia.org/r/668147

Mentioned in SAL (#wikimedia-operations) [2021-03-03T19:14:20Z] <urbanecm@deploy1002> Synchronized php-1.36.0-wmf.33/extensions/WikibaseMediaInfo/src/Special/SpecialMediaSearch.php: b741dc32c59700cb0cdcd82f2d951cf993679689: Also requet timestamp|snippet from non-page results (T271174; T276353) (duration: 01m 09s)

Checked on commons wmf.34. All criteria listed in the task have been met (cross browser testing looks good too).

The following items are for @mwilliams Design. Let me know if some additional testing/clarification is needed.

(1) The UI is different from the mockup in the task description

  • Namespace filter is not present
  • the number of search results is placed below dividing line below tabs
  • the horizontal line does not go across the whole page
commons wmf.34mockup

(2) Chrome dev tools Accessibility testing complains about usage of h3 header (and skipping h2 header).

Heading elements are not in a sequentially-descending order
Properly ordered headings that do not skip levels convey the semantic structure of the page, making it easier to navigate and understand when using assistive technologies.

From the above there is a link to https://web.dev/heading-order/?utm_source=lighthouse&utm_medium=devtools

Thanks for your detailed work on this @Etonkovidova!

Namespace filter is not present

This will come in a later in this ticket https://phabricator.wikimedia.org/T276261

the number of search results is placed below dividing line below tabs

Good catch! This is fine to me, I'm going to put it on my list to think about an optimal location for this but I might prefer this to my mockup :)

the horizontal line does not go across the whole page

Not a blocker and not sure if it's a big enough deal to consider amending for now

As far as the accessibility concern with the headings, I'm not personally aware of how big of an issue this is with screen readers, etc. Going to look into it!

Thanks, @mwilliams for the review! Closing the task as Resolved.