I talked to @Volker_E about this today and we agreed to adapt the patch https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/281100/ for accessibility purposes so that when a search is underway a "reset search" button allows the user to reset the search.

We are aware that editors were unhappy with the size of the form on the history page and are likely to feel the same about this change, so we plan to go to tag this user notice shortly to give editors a heads up.

I feel it would be useful as part of that user notice to have a user style script to compact the form for the editors in advance. Is anyone interested in owning that? @DannyS712 helpfully did one of these for the history>OOUI change (https://en.wikipedia.org/w/index.php?title=User:DannyS712/history.css)

Change 281100 merged by jenkins-bot:
[mediawiki/core@master] Make Special:Contributions use OOUI

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

@Jdlrobson as a result of this change, the "Hide probably good edits" added by ORES is now located below the date options, rather than with the other checkbox filters (new pages only, hide minor edits)

Change 490493 had a related patch set uploaded (by VolkerE; owner: Jdlrobson):
[mediawiki/core@master] Special:Contributions form collapsed when offset is defined

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

To @DannyS712 comment:

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

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

@Jdlrobson @Volker_E When is this going to be in production, if you know? Do you still plan on a script before you go ahead with anything?

https://meta.wikimedia.org/w/index.php?title=Tech/News/2019/40&diff=19412673&oldid=19411385

Looks OK?

In T117736#5524860, @Johan wrote:

https://meta.wikimedia.org/w/index.php?title=Tech/News/2019/40&diff=19412673&oldid=19411385

Looks OK?

Yeah.

As this image shows, this new change will make the search forms to occupy a large percentage of the viewport, in fact whole screen on some computers.

It is collapsible – I think that's an outdated screenshot. I'll let Volker update the task description to keep the screenshots consistent, but here's how it looks like right now on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Contributions:

In T117736#5524856, @Johan wrote:

@Jdlrobson @Volker_E When is this going to be in production, if you know?

Looks like the patches will be included in the next release, so they should be deployed to production wikis next week, 1-3 September.

In T117736#5525795, @matmarex wrote:

It is collapsible – I think that's an outdated screenshot. I'll let Volker update the task description to keep the screenshots consistent, but here's how it looks like right now on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Contributions:

Thanks. It's outdated screenshot indeed.

If this is to go out next week and you want something about a script included in Tech News, that needs to be available at latest 14:00 UTC tomorrow Friday.

@Johan : would suggest revising the wording to have less focus on the size of the form but explain the justification for it :)
This link can be used as a basis for people to opt out: https://en.m.wikipedia.beta.wmflabs.org/wiki/User:Jdlrobson/compactspecialcontributions.css

<translate><!--T:49--> [[<tvar|unblock>Special:NewPages</>|Special:Contributions]] will get the [[<tvar|ooui>mw:UX standardization</>|OOUI look]]. This makes the form collapsible, more accessible and mobile friendly as well as consistent with the rest of the MediaWiki interface. While we believe these changes are best for the project as a whole we are aware that not all editors will appreciate these changes and invite such editors to opt out using this gadget as a basis [[<tvar|script>https://en.m.wikipedia.beta.wmflabs.org/wiki/User:Jdlrobson/compactspecialcontributions.css</>|script]]  to make it smaller if you want to.</translate> [https://phabricator.wikimedia.org/T117736]

OK, made it shorter for ease of translation but tried to keep your explanation of why.

In T117736#5525814, @matmarex wrote:

Looks like the patches will be included in the next release, so they should be deployed to production wikis next week, 1-3 September.

Did you mean 1-3 October?

@Pppery, yes 1-3 October is meant.

Not good.
except hugeness (OMG, why always so big UI? first wikidata, then contributions... almost whole monitor are tools and only minority the content)

When I want to check new contributons (e.g. running bot), I mus always click to [search for contributions] and then to [Search], is is one more click.

In T117736#5543491, @JAnD wrote:

When I want to check new contributons (e.g. running bot), I mus always click to [search for contributions] and then to [Search], is is one more click.

This can be hacked by this css (thanks, @revi )

.mw-special-Contributions .oo-ui-fieldsetLayout-group.mw-collapsible-content { display: block !important; }

Why isn't its design similar to Recent Changes (or Watchlist)? These three tools should have some visual identity (uniformity), they should not be completely different

Also missing the long awaited Live updates button (for monitoring bot activity)

Can collapsing be done only for smaller viewports? Unlike action=history, where the same was done previously, the form up above is absolutely crucial on Special:Contribs, and it makes no sense to hide it for everyone. Moreover, the entire form (unlike inputs) should not be restricted to 50em, so this (see checkboxes) would not happen:

Any CSS hack is not enough, this should be redone. I love what you are doing with OOUI, but we absolutely should care more about how mobile-first solutions transfer to desktop.

In T117736#5543568, @Dvorapa wrote:

Why isn't its design similar to Recent Changes (or Watchlist)? These three tools should have some visual identity (uniformity), they should not be completely different

The new design is similar to Recent changes page because it now uses OOUI.

In T117736#5543879, @stjn wrote:

Can collapsing be done only for smaller viewports? Unlike action=history, where the same was done previously, the form up above is absolutely crucial on Special:Contribs, and it makes no sense to hide it for everyone.

Collapsing is not done by default, this was one of the requirements. It's only done when a parameter (target, start or end date) is provided.
When you go to your own contributions, via the “Contributions” link in the personal menu, the assumption is that you want to foremost scroll through your list of recent contributions and interacting with the form is secondary and therefore collapsed.

Moreover, the entire form (unlike inputs) should not be restricted to 50em, so this (see checkboxes) would not happen:

It's not that simple, there are cases where the checkbox row doesn't end at 3 checkboxes, but got 4 in there, ORES addition is currently wrongly positioned (we're aware and tackling this) so there could be even 5.
Giving as example Catalan Wikipedia (with manipulated DOM) to show 5 checkboxes

.mw-special-Contributions .oo-ui-fieldsetLayout-group {
	max-width: none;
}

to your personal common.css if you feel strongly about the 33px more vertically.

Any CSS hack is not enough, this should be redone. I love what you are doing with OOUI, but we absolutely should care more about how mobile-first solutions transfer to desktop.

Thank you for your valuation. Please take into consideration, that the way we approach general interface design and OOUI development not just through the mobile-first lense at all. We take best practices, user experience research and accessibility requirements into account that lead to the way our modern interface is represented. We try hard to satisfy a widest-possible range of users and use cases and sometimes this means changing existing, known patterns to be more inclusive and provide better maintainability.

In T117736#5544873, @Volker_E wrote:

Collapsing is not done by default, this was one of the requirements. It's only done when a parameter (target, start or end date) is provided.
When you go to your own contributions, via the “Contributions” link in the personal menu, the assumption is that you want to foremost scroll through your list of recent contributions and interacting with the form is secondary and therefore collapsed.

I think the assumption that people won’t use the form on 95% of their visits is incorrect. I am generally in agreement with Quiddity’s arguments against any unnecessary hiding, though, so I might be biased.

In T117736#5544873, @Volker_E wrote:

It's not that simple, there are cases where the checkbox row doesn't end at 3 checkboxes, but got 4 in there, ORES addition is currently wrongly positioned (we're aware and tackling this) so there could be even 5.
Now imagine a wider screen as my laptop. At some point you've got a checkbox where you loose the connex to the input field above. A max-width restriction for forms makes sense, even though your one example seems not designed at first sight.
You could still add ... to your personal common.css if you feel strongly about the 33px more vertically.

With 4 or 5 checkboxes in a tight space it would be even more than just 33px vertically, since it would be 3 or 4 lines in many languages instead of 2, like on your screenshot. As for potential context issues, this line of checkboxes doesn’t even have a common context (and definitely no relation to the field above), since it represents a bunch of different actions not really bound by anything. I can see how that kind of distinction can be difficult to make when building a generic library, however.

In T117736#5544964, @stjn wrote:

I think the assumption that people won’t use the form on 95% of their visits is incorrect.

I didn't say that anywhere. ;) My point was that there are different use cases for the same form/view, and we tried to address them in our approach, by making the form not collapsed if directly accessed and collapsed when the parameters target, start and end date are set (also on subsequent pages).
What became more obvious from several feedback given here and on Meta, is that we should evaluate a “pinning” function to leave it to the users to always have the form expanded.

On a side note, I'm a big proponent of context-sensitive user interfaces, giving all the options is counter-productive to inefficient for task completion.

In T117736#5545101, @Volker_E wrote:

In T117736#5544964, @stjn wrote:

I think the assumption that people won’t use the form on 95% of their visits is incorrect.

I didn't say that anywhere. ;) My point was that there are different use cases for the same form/view, and we tried to address them in our approach, by making the form not collapsed if directly accessed and collapsed when the parameters target, start and end date are set (also on subsequent pages).

In reality, the most prominent (and common) use case for Special:Contribs is from either: 'Contributions' from the Toolbar at someone's userpage/talkpage, 'contribs' at ( talk | contribs | block ) bar at History or watchlist &/or CheckUser interface, so it is practically 100% hidden all the times.

I mean, it is technically correct to say "It's not hidden by default" but given that most people don't browse it that way (rather than going to Special:contribs and putting their target, people click the Contribs page from somewhere else which means their forms are pre-filled) it is practically hidden by default.

Agree with revi’s comment entirely.

Suggestion if the form stays the same way: for users that don’t exist, the form should be open (example).

Having tried using the new form, not having a username autocomplete on the first field is a grave omission that can’t be explained rationally (Firefox 69 if that makes a difference).

In T117736#5545298, @stjn wrote:

Having tried using the new form, not having a username autocomplete on the first field is a grave omission that can’t be explained rationally (Firefox 69 if that makes a difference).

T234510: autocomplete in Special:Contributions no longer works

I don't know the right place for this but thanks to this new change we've lost the ability to autogenerate usernames. ie. If I start typing praxi, nothing generates which is a massive detriment to all projects.

In T117736#5546651, @Praxidicae wrote:

I don't know the right place for this but thanks to this new change we've lost the ability to autogenerate usernames. ie. If I start typing praxi, nothing generates which is a massive detriment to all projects.

This is being tracked at T234510.

I added T234733: User field in OOUI Special:Contributions is very short as a post-rollout subtask.

Removing T234569: Special:Contributions – add 'pinning' functionality to collapsible form? as subtask, which will be cared about, but it's not directly blocking current task.

I want to thank you for finally solving this task. It's a great idea for users to generate content collaboratively and horizontally, but this model doesn't favor process efficiency, user experience or innovation, so these areas require skilled professionals who fight against tradition, stagnation, short term and subjectivity. Users hardly ever like change, but I do think the improvement is significant and right now I don't miss anything from the old version. Keep up the good work! :-)

While I think UI-Standardization is a good thing, I do not understand why we have to show forms like this in such a imparactical fashion on desktop. When looking at my contributions today, I was quite shocked – I have seen OOUI migrations before that I considered questionable, as they usually take much more space with little gain for most use cases. But I never experienced it that extreme before – ironically on a page which is impossible to use comfortably on mobile anyway (try to click these links…)

If I expand this box, more than half my deskrtop screen is filled with this box, which has just been a small annotation before. And to make things worse, nearly 2/3 of the box is just empty whitespace. Why? Is there any reasons to not adjust this responsibly for large screens? As far as I know, reponsive does not mean "good for small devices"… It would be easily possible to use a two column layout on large screens, or to move the "Hide minor edits" button to the line above for them. Is there any reason not to do that?

Basically, the developers have to take into account the best practices when standardising the interface. For forms, putting labels above the fields and putting fields on separate lines provides the most readability (it is easier to read labels that way), even though it uses more vertical space. Checkboxes and radio buttons are made bigger for the benefit of mobile users and people with physical or motor disabilities, which also uses more vertical space. Our interfaces can be convoluted, but I think folks try their best to meet everyone’s needs.

‘Hide minor edits’ thing is a bug that will be fixed, IIRC.

Basically, the developers have to take into account the best practices when standardising the interface. For forms, putting labels above the fields and putting fields on separate lines provides the most readability (it is easier to read labels that way), even though it uses more vertical space. Checkboxes and radio buttons are made bigger for the benefit of mobile users and people with physical or motor disabilities, which also uses more vertical space. Our interfaces can be convoluted, but I think folks try their best to meet everyone’s needs.

I did not critisize the largeness of the ui elements, as I kind of get why they are this way. (However, it is not like it is impossible to tell if you are using mobile devices…) However, I do not really see how your statement is an argument against a multi column form on wide screens, to actually use them.