Page MenuHomePhabricator

[SPIKE] Allow recent changes to display filters in AMC mode
Closed, ResolvedPublic



During our hackday and in follow up conversations, we studied the changes needed to made the recent changes filters functional on mobile. This task will study the viability of the proposed changes and with the goal of creating a task for making the changes themselves

Acceptance criteria

Investigate the viability and relative difficulty of each of the following items:

  • Other review tools section will be collapsed. When uncollapsed, the section will contain all links available on the desktop site.
  • Saved filter functionality will be identical to desktop. User will have the ability to:
    • Save filters
    • Rename saved filters
    • Delete saved filters
    • Load saved filters
  • The following active filters will be available:
    • Basic
      • If possible, type ahead will be in modal of filter selection
    • Tags
    • Namespaces
    • Time filter (gear icon)
      • Users will have the ability to group icons by page
      • If a user has the grouping as a user preference, we will not suppress the preference and display the results as a list
    • Users will NOT be able to highlight results
    • The active filters section will be collapsible
  • Minimal fixes will be made to the “Use non-JavaScript interface” setting
  • New changes and live updates buttons will function as they do on desktop
  • The list of abbreviations will be hidden. If we cannot hide it, we can collapse by default
  • Other open questions:
  • can we display filters in a modal or should we try to use the native multi-select element?
  • How do these work links on filter headings will be removed
  • Tell us what you think about these filter headings will be removed

Design notes

(from T223922: [EPIC] Display core version of recent changes page for AMC users):
Basic mockup - these mockups show what's possible with relatively little CSS overrides. Below there is a "refined mockup" that goes a bit further in terms of cleaning up the filter section and naturally would require more CSS.

full pagetime range and # of results filter menusaved filters menu

The two main components to consider here are:

filters as native select elementsfilters in a modal
Refined mockup

Developer notes

Potentially helpful CSS here T223922#5222606

Event Timeline

ovasileva created this task.
ovasileva removed a project: Epic.
pmiazga added a subscriber: pmiazga.

@Jdrewniak could you analyze this task, please? are there any unanswered questions?

When looking at this task, it occurred to me that a lot of the features work to an acceptable degree on mobile (IMO).

Many of the layout bugs can be fixed through CSS and skin-specific overrides for Minerva.

Where the filters really fall down though, is the tag-selection dropdown.

This dropdown is broken for two reasons:

  1. The resizing behaviour causes the options-container to shrink to width=0 on mobile
  2. The selection modal brings up the software keyboard, which severely limits the screen real estate.

When evaluating solutions to these problems, we talked about redoing the filters as native <selects> elements, or placing them in a MobileFrontend modal (per description), however I think we overlooked another solution, which is: fix the dropdown.

Fixing the dropdown would mean:

  1. prevent the dropdown from shrinking to width=0
  2. Not triggering the virtual keyboard when the dropdown is activated.

I think in this case, text input (and thus keyboard) is non-essential. As long as the dropdown items remain selectable, it still provides the necessary functionality of adding/removing filter tags/namespaces etc.

The shrinking behaviour is created by OOUI's setClippableElement() and setClippableContainer() on line#57 of MenuSelectWidget.js. Commenting out these two lines prevents the clipping behaviour, resulting in an almost useable widget (if not for the checkboxes triggering the virtual keyboard):

Where the filters really fall down though, is the tag-selection dropdown.

It seems like all three filters (basic, namespace, and tags) use the same dropdown panel thing and are equally broken?

I think we overlooked another solution, which is: fix the dropdown.

Good point. I think we made the assumption that fixing the filter menu but leaving it on the page wouldn't be a great experience. I think you're right in challenging that assumption. I added a quick mockup below. If we wanted to go that route I don't think we'd be able to support the search functionality (space is too tight and the search field not being fixed to the top of the screen makes things a bit hectic). The value of putting it in a modal is that there would be more space, and we could keep the search functionality.

@alexhollender, yes, all three filters use the same dropdown, and are thus equally broken :)

I think we made the assumption that fixing the filter menu but leaving it on the page wouldn't be a great experience

That's true. I might not be a great experience, but it might be an adequate experience. When compared to the native <select> element, the dropdown has the advantage of being more descriptive, organized into sections, and having a "highlight" feature. When compared to the overlay idea, in theory the dropdown retains all it's functionality with more available space, which is definitely a plus.

The downside of the overlay idea though, is that it would require us overriding a substantial amount of Mediawiki core behaviour for a solution that is mobileFrontend/Minerva specific. The MF Overlay code is buggy and error-prone, and if the core code were to ever change, it would likely break the MF/Minerva solution as well. In essence, making the functionality skin-specific is a high maintenance burden.

I've created T225499 and updated T223363 (that one could probably use more detail though) to reflect what I think are the two bigs chunks of work in this spike.

  1. Make the filter dropdown work on mobile
  2. Make the filters look good :)

With regards to making the dropdown work on mobile, I've found some easy solutions that fix some of the bugs (the menu options disappearing for example). The hardest part of T225499 I think is handling the virtual keyboard.

I think we should wait for that task to be completed before doing the visual changes in T223363. I haven't identified any unforeseen challenges with those style changes though, so I hopefully that task won't be too difficult.

@Jdrewniak cool, sounds like that might be the best direction. We don't need to support highlighting btw. By removing that button on each row there is more horizontal space for the description.

JTannerWMF added a subscriber: JTannerWMF.

Looks like Readers-Web-Backlog is working on this, so we are marking this external

Jdlrobson added a subscriber: Jdlrobson.

Jan it looks like the spike got carried out. Why did we keep it open? Are there more specific questions that need answering that we can put in a new task or does T225499 and T223363 cover everything we need?

Closing out after chatting to Jan