Change Details

The design for T273073 calls for a dialog element which will appear when the user wants to select namespaces for a search query (the large number of options makes other ways of displaying this info unfeasible). We don't yet have a Vue-based UI component for this kind of dialog, so we'll need to create one before the filter-by-namespace feature can be completed. One additional hurdle is that Vector skin currently makes non-OOUI dialogs very difficult to do; the skin styles are written in such a way that creating a full-screen overlay is not really possible without using OOUI's WindowManager component. In the SuggestedTags interface, we actually ended up relying on OOUI for the dialogs while using Vue for everything else. We'd like to avoid doing that on MediaSearch because it will necessitate keeping both libraries on the page. However, as a short-term workaround this might be acceptable if we need to get this feature working in time for the default rollout. The design team has a v1 of the dialog component on our style guide for reference: https://design.wikimedia.org/style-guide/components/dialogs.html

The design for T273073 calls for a dialog element which will appear when the user wants to select namespaces for a search query (the large number of options makes other ways of displaying this info unfeasible). We don't yet have a Vue-based UI component for this kind of dialog, so we'll need to create one before the filter-by-namespace feature can be completed. One additional hurdle is that Vector skin currently makes non-OOUI dialogs very difficult to do; the skin styles are written in such a way that creating a full-screen overlay is not really possible without using OOUI's WindowManager component. In the SuggestedTags interface, we actually ended up relying on OOUI for the dialogs while using Vue for everything else. We'd like to avoid doing that on MediaSearch because it will necessitate keeping both libraries on the page. However, as a short-term workaround this might be acceptable if we need to get this feature working in time for the default rollout. The design team has a v1 of the dialog component on our style guide for reference: https://design.wikimedia.org/style-guide/components/dialogs.html **Short Term Solution** We ran into the same problem in our work on the MachineVision extension. The solution there was to simply fall back to OOUI's `WindowManager` and `ProcessDialog` classes. We created a "[[ https://github.com/wikimedia/mediawiki-extensions-MachineVision/blob/master/resources/widgets/OnboardingDialog.js | widget ]]" (not a "component") that served our use-case. Actually wiring up our Vue app to use OOUI's window manager was [[ https://github.com/wikimedia/mediawiki-extensions-MachineVision/blob/master/resources/components/App.vue#L214-L239 | pretty straightforward ]]. The downside of course is that we now need two frameworks, OOUI and Vue.js. However, Commons loads OOUI (as well as jQuery UI) on most pages anyway due to gadgets, so we currently suffer from this problem regardless. In the interest of getting Special:MediaSearch into a state where it could serve as the default search tool for Commons as quickly as possible, I think this approach is fine. In that case, this task no longer blocks T273073. **Long Term Solution** Eventually we hope to port the MediaSearch UI over to a new Foundation-wide Vue component library (WVUI or whatever it turns into). This library will need to include native dialog components; skins like Vector may need to be updated to accommodate non-OOUI window-manager functionality. This would be a good time to come back and pay down the technical debt we are incurring by taking the "easy way out" for now.

The design for T273073 calls for a dialog element which will appear when the user wants to select namespaces for a search query (the large number of options makes other ways of displaying this info unfeasible). We don't yet have a Vue-based UI component for this kind of dialog, so we'll need to create one before the filter-by-namespace feature can be completed. One additional hurdle is that Vector skin currently makes non-OOUI dialogs very difficult to do; the skin styles are written in such a way that creating a full-screen overlay is not really possible without using OOUI's WindowManager component. In the SuggestedTags interface, we actually ended up relying on OOUI for the dialogs while using Vue for everything else. We'd like to avoid doing that on MediaSearch because it will necessitate keeping both libraries on the page. However, as a short-term workaround this might be acceptable if we need to get this feature working in time for the default rollout. The design team has a v1 of the dialog component on our style guide for reference: https://design.wikimedia.org/style-guide/components/dialogs.html **Short Term Solution** We ran into the same problem in our work on the MachineVision extension. The solution there was to simply fall back to OOUI's `WindowManager` and `ProcessDialog` classes. We created a "[[ https://github.com/wikimedia/mediawiki-extensions-MachineVision/blob/master/resources/widgets/OnboardingDialog.js | widget ]]" (not a "component") that served our use-case. Actually wiring up our Vue app to use OOUI's window manager was [[ https://github.com/wikimedia/mediawiki-extensions-MachineVision/blob/master/resources/components/App.vue#L214-L239 | pretty straightforward ]]. The downside of course is that we now need two frameworks, OOUI and Vue.js. However, Commons loads OOUI (as well as jQuery UI) on most pages anyway due to gadgets, so we currently suffer from this problem regardless. In the interest of getting Special:MediaSearch into a state where it could serve as the default search tool for Commons as quickly as possible, I think this approach is fine. In that case, this task no longer blocks T273073. **Long Term Solution** Eventually we hope to port the MediaSearch UI over to a new Foundation-wide Vue component library (WVUI or whatever it turns into). This library will need to include native dialog components; skins like Vector may need to be updated to accommodate non-OOUI window-manager functionality. This would be a good time to come back and pay down the technical debt we are incurring by taking the "easy way out" for now.