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.

In T170502#3434038, @Izno wrote:

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.

Should I change the title and description then or leave it as is? Or maybe create another subtask?

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!

In T170502#3434038, @Izno wrote:

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.

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?

In T170502#3436401, @kaldari wrote:

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.

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.

Example: https://en.wikipedia.org/wiki/Special:Contributions/Sn1per?year=2012&end=&start=

@Izno The admin there wasn't confusing history page with the user contributions page. The admin was discussing the user contributions page. Ah, well. Won't matter. I notified that person about it.