From a discussion to clarify my take with @Prtksxna on the topic:

@Prtksxna: Might lead to more interactions than needed though

@Volker_E that's exactly the trade off
one click more
therefore it should be possible to add that functionality to OOUI Special:Pages as option, but not by default
also a cookie or some persistent setting could be of interest
maybe a volunteer never wants to see the form

@Prtksxna nods
@Prtksxna: Hidden forms is one alternative too, yes. Not one that I particularly like though (exactly because its hidden ☺ ) But an alternative to consider, certainly.

@Volker_E: let's be sure we're on the same page, with hidden I mean collapsed to, let's say the legend

not completely hidden

A collapsible form similar to RevisionSlider comes to mind.

Are you referring to the collapsible interface?

Closed	Open

Sorry I am not a big RevSlider user so don't know all the elements so well.

@Prtksxna Yes, a collapsible element similar to this should be considered (with small adaptions, like title/legend being left aligned).

We have had a discussion about field labels on top versus horizontal, among other places, at T117724 on related patch https://gerrit.wikimedia.org/r/#/c/366603/

@Prtksxna made a test case there with horizontal layout and max-width of the labels:
https://phabricator.wikimedia.org/F9952734
which shows the disadvantages of orientating and violating gestalt principle of proximity pretty clearly.

I'm convinced that above approach won't lead us anywhere, it will introduce just design debt and only maybe tame the repeated feedback of change on OOUI taking up too much space. For this reason above treatment on Special:Pages which include an instant result list below seem to better address vertical space concerns.

Horizontal scrolling in general seems less a usability issue than changing orientation from top-to-bottom and left-to-right.

An ability to give an HTMLForm an optional 'collapsable' parameter with two options:

• 'collapsed' or
• 'expanded'.

'collapsed' results in:
It takes the first form legend and adds some CSS class(es) to it which result in a clickable appearance and add a down-facing caret at the end of line.
The current legend labelElement is turned into a clickable area with a treatment similar to a frameless ButtonElement.
.oo-ui-fieldsetLayout-group(s, forms to evaluate on this) will be hidden.
Including ARIA attributes (aria-controls & aria-expanded) at best similar to http://www.oaa-accessibility.org/example/20/

collapsed view:

We have different types of Special pages and not all need the same treatment. Pages which primarily show just one form (Upload, BookSources) are alright with form taking up vertical space. Then come the list or report special pages which might (AllPages, ActiveUsers) or might not (BrokenRedirects) have filtering capabilities. The ones with the filtering could surely use something like a collapsible form as you're suggesting.

It might be even better if in the collapsed state it could mention a little of what kind of filtering is being currently applied.

Expanded	Collapsed

While a collapsed form is surely a good first step, I worry if we're misjudging what is required here. Most eye tracking and proximity studies on forms have been on pages where the forms have been the main focus of the page, for example - a checkout process. Ours is more a case of filtering, where the resulting data is the main focus for the user. I don't know of any recent studies about this usecase, if someone knows any good ones I'd like to read.

The 'filter' UI patten often has multiple form elements stacked from left to right, something that might not be straightforward to do in OOUI and will require us to give attention to each page before converting it. It might be something that we want to look at.

https://iritec.jp/web_service/13048/	https://dribbble.com/shots/2359706-NHL-stats-filtering	https://dribbble.com/shots/3550439-Patient-Case-List/attachments/789532
T188435: Bring consistency to visual design of Interaction Timeline	Special:RecentChanges

Again, I think a collapsed form which maintains state is a good first step.

@alexhollender I see convergent potential here for our Quarterly goal and your ideas for selected mobile views…

Thanks for looping me in. My interest is special pages on mobile. As discussed here, many special pages are filterable/searchable lists. The thinking I've done so far has similarly focused around figuring out a way to collapse the filter/search fields, allowing the focus to start with the contents of the list. The designs that @Pginer-WMF worked on here T158923#3060814 have been helpful to me.

Change 490493 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Collapse the form at the top of the history page

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

https://gerrit.wikimedia.org/r/490493 results in:

Change 490493 abandoned by Jdlrobson:
Collapse the form at the top of the history page

Reason:
Preserved on https://phabricator.wikimedia.org/T216420

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

Change 490493 restored by Jdlrobson:
Collapse the form at the top of the history page

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

From a conversation with @Jdforrester-WMF. We need to make sure that discoverability of the expand/collapse action is given.
He was adding that it, depending on the form, might be preferable to have certain elements visible by default and collapse just the more specialized.

Change 502620 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] History form can be collapsed

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

Volker this is done right?

@Jdlrobson Just filed a follow-up subtask. Also the patch for Special:Contributions is still under review.

2c from a user perspective:

The History page had its filter form collapsed previously in a similar way. I think that change made things better for mobile, and narrow screens in general, but I fear that for desktop it made the form effectively non-existent. Hard to discover, especially considering a user might not know such functionality is available at all. (Failing to find vs failing to search). Consider the history action, and a user story to see the edits made in February 2018.

My expectation is that a majority of (new) users would start paging until their patience runs out. I'm not sure they'd identify with "Filter revisions" or a far-away generic "expand" button ("show" on enwiki). I didn't raise this as an issue at the time, because I think paging is an acceptable workaround, and the larger use case is relatively rare. Should probably be improved mid-to-long term to ensure curators can ensure the quality and relevancy of our content, but not urgent right now.

For Special:Contributions, though, this form is essential, and has no fallback workflow. I like the mockups from @alexhollender that provide relevant and action-oriented buttons and labels. E.g. "Search for a different user name", "Apply namespace, date, and metadata filters" etc. I think it's important to separate these two fro the user perspective as I'm not sure a typical user would consider everything in the form as a "search query" or "filter settings". The username field represents a higher-level concept, separate from filtering down what results to include.

Would that be worth including from the start when collapsing the contributions's form?

@Krinkle That makes sense and in the long term @alexhollender's approach is worth-while testing.
In the meantime, we do have an intermediate solution though by @matmarex, that strongly tames your stated issue of discoverability as it puts an arrow indicator before the legend and makes the full legend interactive.

Before	Proposed

With

Change 490493 merged by jenkins-bot:
[mediawiki/core@master] Special:Contributions form collapsed when offset is defined

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

Can someone make this pref configs (or a JavaScript snippet) so that I can disable this automatic collapse? Do you want a ticket? I posted this on Tech#Reverting the new "collapsed search interface" on Special:Contribs and digging thru MW commit log pointed here.

@revi Replied on the talk page for now with a quick solution for you. Will observe the situation and decide on follow-ups later…