Seems that some people don't like the newer user interface of "Search for contributions" and wants to use the older, more convenient drop-downs for choosing a year and a month. Perhaps we can have the option added in the user preferences, so any user can choose to use either the older or the newer (current) "Search for contributions" user interface.
|Open||None||T134802 Improve the curator workflow for reviewing new files|
|Open||None||T120453 Copyvio tools for Commons|
|Open||None||T121797 Implement perceptual/visual image hashing/fingerprinting in MediaWiki for detection of non-exact duplicate uploads|
|Open||None||T121870 Improve Special:NewFiles|
|Resolved||Sn1per||T13836 Easy date selection for Special:NewFiles|
|Resolved||Sn1per||T120733 Improve date range searches on Special:Contributions|
|Declined||None||T170502 Switch between newer and older "Search for contributions" user interface|
|Open||None||T31793 Check uploaded images with Google image search to find copyright violations|
|Open||MarkTraceur||T123517 Automatically check Commons uploads for possible copyright violations|
|Open||eranroz||T230561 Create a ML model to score new files in commons for copyvio issues|
|Resolved||Samwilson||T145165 Investigation: Copyvio tools for Commons|
|Open||None||T132650 Copyright detection (acoustic fingerprint matching) for audio files|
I think the task description and title defines a solution rather than a problem. The use case presented in one of the links is "I want to do a binary search for history diving so that I can speed up my search for some nugget of information". I think that would better illustrate the problem.
The solution to that might be to change the widget rather than to provide a configuration option and would seem more reasonable as a result.
This task "Switch between newer and older interface" is clearly a WON'TFIX / to decline currently. I don't see justification of additional maintenance costs / resources to long-term maintain additional code. You are free to edit the task summary and description to describe an actua problem instead of a potential solution. Thanks!
Unfortunately, that editor is still unhappy with the changes without being notified. Also, any type of widget may not please him. I gave him a link to read about Widgets, but I'm unsure whether that'll change his mind. The best option I can think is adding an option on switching between old and new interface. A "widget" of any kind might do; as said before, that won't please him.
The solution to "I want to do a binary search for history diving so that I can speed up my search for some nugget of information" is the new "Browse history" feature in the diff interface (Extension:RevisionSlider). Special:Contributions isn't intended to meet that use case.
From the discussion link:
"Before it defaulted to the end of the month, now it forces you to select a specific date; there is no default."
This can be fixed pretty easily I believe. Will that help?
I don't agree with the assertion that the RevisionSlider tool is sufficient or "the right tool", especially since we're presently talking about User Contributions, not Revisions. (My comment may have confused you to the actual widgets under discussion--mind you, part of the discussion is that there are 3 or 4 different date widgets presently, so what I say here may be less/more relevant when we later have 1 widget [because 4 widgets is silly].)
But that aside, since you responded that you think RevisionSlider is better than ?action=history at, say, binary searching--I would say it's not. ?action=history is also better than RevisionSlider for history-diving, due to the information density: I can, at a glance, work through literal hundreds of changes in search of some nugget. RevisionSlider is painful on this point: click the paging widget, wait for RevisionSlider to load the next batch of diffs, move the newrev bubble to a new column, find nothing in the diffs (because they display no metadata like the associated edit summary save by hovering over each diff individually, which is a BIG piece of comprehending quickly what has changed), go back to grab the oldrev bubble to move to the current page, rinse and repeat. And RevisionSlider only loads, at-most, around 30 diffs. I can assess the potential relevance of each diff much better from ?action=history.
But that aside, since you responded that you think RevisionSlider is better than ?action=history at, say, binary searching--I would say it's not. ?action=history is also better than RevisionSlider for history-diving, due to the information density: I can, at a glance, work through literal hundreds of changes in search of some nugget.
@Izno: I guess it depends on if your looking for information in a diff or in an edit summary. Personally, I most often use binary searches to figure out who recently added a particular piece of content in an article, in which case I find RevisionSlider to be most useful (although I use XTools for searches over longer periods of time).
Regarding the multiple datepickers, there are only 2 that I know of, but I definitely agree we should consolidate them. See T91148.
If someone wants to make a user script or gadget for this, note that Special:Contributions still supports year and month querystring parameters. You could add input boxes to the Special:Contributions form and set the name attributes of those inputs to year and month.
I think I'm going to close this as declined for now given a) you can make a gadget or personal script to do it "the old way" if necessary and b) T91148: Consolidate MediaWiki core's date and time input widgets; consider moving (one of?) them upstream exists. Additionally, the continued discussion from the original task description indicates that the original complainant was confusing this functionality with the history page.