Hulllo test!

Approved from my end!

@Cparle I believe that was done on purpose, I sadly can't remember the reason but I'll try and track it down and we can see if it was a worthy reason :)

Approved!

Thanks for looking into this further @SimoneThisDot, your explanation makes sense.
I agree that we should always re-state the focus to the selected entry as you have suggested.

Thanks for the great feedback. @Dominicbm you are correct that this needs to be a collection of grouped claims and that my mockups didn't communicate that functionality.

If option #1 "Rewrite the link on the fly as proposed" is possible and the easiest solution, I would prefer that over adjusting the current design.

@alexhollender That seems reasonable to me!

An idea I'm leaning towards...

@SimoneThisDot Can you elaborate a bit on a "small device without touch"? Are you referring to a desktop computer with the viewport really small and no trackpad or more as an accessibility issue on mobile web on a phone?

I'm not sure if I have all the right context here and I'm having some trouble reproducing everything on my own but my initial reaction is either your first or third option Alex.

• Use the Commons icon on Wikipedia, and the standard Upload icon on Commons
• Use the standard Upload icon on both Wikipedia & Commons

Using the Commons icon to mean something while already on Commons seems like a stretch. I don't mind it not being consistent between the two with option 1, since it could help folks know that uploaded media happens on Commons. Also makes me wonder if we need any indication that this link will open up a new page/site. Option 3 seems like a safe and consistent approach.

I wanted to share a first pass of how we might be able to approach this on Commons. These mockups are based on the idea of having both qualifier and reference statements (row three in @Fuzheado's "Approach for attribution" table)

After chatting with a few folks on the team, it seems like removing the "All" from the default filter copy makes sense and is a good direction to go towards but we are still having some trouble getting the right copy on the assessments filter to make it as clear as possible. The main question being: How do we clearly and succinctly differentiate between showing all results (including all results that have an assessment) and all results that have an assessment.

@SimoneThisDot Looks great, using this animation for both instances seems reasonable to me.

@SimoneThisDot Good catch. I incorrectly described the bug in the ticket description, apologies. Let me try again and if it makes sense I'll update the main description of this ticket.

A slight twist to your ideas @egardner, @CBogen to try and get these filters feeling consistent (Besides the namespace filter for now)

@CBogen @egardner Updated the description and designs to show that this happens on the Categories & Pages tab.

I don't consider this to be a bug but rather a product decision. I've had success with with opening a new tab for search results in A/B experiments on other platforms and it is common practice in mainstream image search experiences, both Google and Bing open new tabs in their image search tabs.

Good catch @Etonkovidova. I prefer the star icon since we already are using the placeholder image icon, and the star helps differentiate this line of information. I don't think it's a huge deal/blocker/etc but would like to see it swapped.

Good point. I agree that the red link works better below any spelling correction messaging. I'll bring this ticket up in our next team/estimation meeting to keep it moving, thanks!

Adding a link in the same layout and style makes sense to me!

Thanks @AntiCompositeNumber, this seems like an important addition to Media Search.

Thanks for additional info!

@Etonkovidova Good question! I had incorrectly assumed that these assessments would be for images and video only but if there are other file types receiving these assessments, it can't hurt to show the filter on all of the tabs. I don't think it's a blocker but something to consider when we have the time to update.

Chatted with a few of you about this...some ideas:

After chatting with the team, we decided on starting with the least complex solution to implement as we currently have limited time resources to dedicate to this. We hope to gain more insight on how this filter is being used before investing more time.

Thanks Elena!

@AnneT Having the namespace filter use the same hover state (gray background) makes sense to me!

@ChristianFerrer All good points, thanks. Going to bring this ticket up in an upcoming team meeting and see what parts of this we can accomplish and when. Here are some mockups of your ideas:

@Jseddon brought to my attention that now that we have the "Help" link in the top right, that this design doesn't quite work. A few points I mentioned from our Slack thread

That all makes sense to me. So let's just keep option 1 for now and we can think on any improvements to the filter language and the visible cue issue once we can use it in for production for awhile!

One other thing that I overlooked when we switched this to a dialog is how to represent the text of this action next to the other filters. A few thoughts there:

I've mostly been thinking that the X in dialogs equals a "Cancel" button but after thinking about it "Cancel" does feel like it more explicitly implies that we will not be saving any choices.

@ChristianFerrer Thanks for your input, that could work, still figuring out how they would work together and to not make the "Advanced" link appear to be part of the select options while having an expected interaction once clicked on.

Thanks for your detailed work on this @Etonkovidova!

Hello @Volker_E! Not sure I'm totally following what we need here.

This works for me! Thanks everyone

Really like this idea and could see it be especially useful while searching for image to place in an article.

@Jseddon This looks great!

Thanks @matthiasmullie, that makes sense.

@Etonkovidova Can you help me understand how this ticket differs from https://phabricator.wikimedia.org/T271387?

Thanks for getting this started @nettrom_WMF!

@egardner That seems reasonable to me, thanks!

@Jseddon Sounds good to me, thanks for the suggestion!

Thanks for the heads up @AnneT!

@Jseddon Yup, not bold anymore. Good catch!

The design team just released a very rough v1 dialog component: https://design.wikimedia.org/style-guide/components/dialogs.html

I think its fine to have it on all the tabs to make this consistent

Yeah, I wondered that when I took a look at this @AnneT, thanks for bringing that up.

So the de-facto default is "All"?

Yup! Default is all the namespaces that apply to the Pages & Categories tab

Good points @Keegan, thanks for the input!

@Jseddon For now we just want to adjust "EndofResults"

@Jseddon Tested out removing the 16px from the search results and that seems like it does the job nicely!

This seems fine to me!

Two ideas for this ticket so far:

Per our meeting yesterday, I updated the namespace selector filter dialogs to map a little closer to the special:search experience. Two questions: Do you think that we need that "Default" selection choice? I'm not sure I have enough context to know what to do there. And should we support the "Remember selection for future searches" checkbox, is that a lot of work?

Dropped the above screenshot into Slack and got some good feedback

4 months later I respond...

Works for me!

Seems to be a good improvement!

Thanks for the explanation @matthiasmullie, sounds like we should avoid attempting to add in the rewrite feature at the moment.

@egardner This makes sense, getting rewrites 100% right would obviously be a good thing but that sounds very tricky as you've explained. I also don't think rewrites are a blocker for us making Media Search the default, more of a "really nice to have".

Added a screenshot to the description, the one thing I think we could also update is adding a "header" to the top section of preferences since everything else has one and it felt a bit odd. I put "General" in there but I imagine we could think of something more specific.