Seems entirely possible. If a gadget has been used to hide the entire structured data UI, then an error of "Missing mediainfo tabs" from the page initialization script would not be surprising.

Just visited this page and cannot replicate the error, structured data UI seems to be working normally.

Is there a better way to represent un-setting a filter than just hard-coding a specially-designated string?

Hmm, I could see having a special value like "UNSET" making sense, or it could be an empty string. Let me poll the Product Analytics team to see if there's a convention for this and report back.

Treating this as blocked until we resolve T265399; that will determine what approach we can use to set up a testing framework here.

RE timing of the answers to said questions, would it be alright for us to have answers to you sometime next week?

Thanks @ppelberg for starting this. I've recently been doing some analytics instrumentation for our new MediaSearch UI so I'll likely be working on implementation here as well.

@CBogen I think my latest updates to this patch and the schema should capture enough data to answer those questions. Every time the user changes a filter an event will be logged with that filter's new value; it should be possible to get a sense of all filters used in a given session by grabbing all filter_change events and looking at filter types, values, whether or not things were unset after being set, etc.

Regarding filter-change events, here's how I'm approaching this for now:

Thanks @nettrom_WMF – I'll answer what I can below, but some of these questions are things I would like to know more about as well.

I assume we probably want to instrument the autocomplete suggestions as well at some point.

Two thoughts:

• I think the interface language for all logged out users will be english (did a quick test an accept-language doesn't seem to have any effect). I haven't looked too closely at the breakdowns for media, but in content search anonymous users are most of them. Still might be able to derive some information from the logged-in users but we must make sure we exclude logged out during analysis.

One thing currently missing from the draft schema is a notion of "language" – I assume we will want to be able to segment and query data about search sessions by language at some point.

I have an in-progress patch that adds some basic analytics to MediaSearch, using the draft schema from the linked sub-task.

I just published a patch that adds a basic MediaSearch schema along these lines to the Secondary repository. I'll use this schema for local development and testing of analytics instrumentation, but please let me know if I've made any mistakes either in designing the schema itself, or in materializing it with the jsonschema-tools command-line tool.

Thanks for the feedback, this is very helpful and confirms my suspicion that targeting higher-level user actions will be better (and simpler) for now.

Also, since SearchSatisfaction is still a legacy schema, it may be worth writing a new MediaSearch schema after all: this is a simple example that could serve as a starting point.

Thanks @Ottomata for your help in getting things working today. For the sake of posterity I'm going to include some notes here about wiring up a local (MW-Docker-based) dev environment with the eventgate-wikimedia dev server. This setup will be useful for confirming that our MediaSearch analytics instrumentation is working as expected before merging any patches.

@mwilliams we've been talking about work to further refine the grid layout anyway – it might be good to include a sub-task about changing the thumbnail resolution globally.

Thanks @Nuria for the suggestion; @nettrom_WMF and I just had a productive chat about schemas and measurement strategy.

This is because we are using the v-bind directive without arguments in a few places, binding an entire API response object to a given element on the page. This was convenient in the beginning because we weren't always 100% sure what properties from the object we might need as we were adjusting the initial designs, etc. But I can see how it could be confusing or problematic.

I'm about to start working on adding the instrumentation for this, but before I do I have some high-level questions about what's involved. I've never worked with the new event platform and have only limited experience with EventLogging; I apologize if any of these questions are really obvious.

There is one issue with disabling the filters based on whether or not there are any results:

Some notes about what it's going to take to fully enable this feature, while I'm thinking about it:

I think my problems were due to one or both of the following:

I think I found the culprit:

I've noticed this behavior as well. It happens not just when you type and delete, but if you type part of a word and wait for the suggestions, and then continue typing. The expected behavior here would be for the suggestions to be narrowed down as the user adds more characters.

Right now the reason this is happening is that in the App.vue component, we have the following code:

@mwilliams I think this is the last scenario that needs to be specified for how filters interact with various other UI elements. Let me know if anything here seems incorrect.