Page MenuHomePhabricator

Convert non-JS version of Special:RecentChanges to HTMLForm (Codex)
Open, LowestPublic

Description

After doing T99256, we should apply the same transformation to the RecentChanges page.

Event Timeline

I had a partial patch at https://gerrit.wikimedia.org/r/#/c/224723/ (which I'm not working on now, and which will need rebase, but might still be useful).

sidak subscribed.
This comment was removed by sidak.
sidak removed sidak as the assignee of this task.Mar 12 2016, 2:31 PM
sidak unsubscribed.

Hmm, Special_RecentChanges is a bigger change, I'm not sure, if it's suitable for GCI :/ Are you sure, that the task fulfills the requirement for GCI tasks: https://www.mediawiki.org/wiki/Google_Code-in_2016/Mentors#Requirements_of_a_task

I have tried to make a change to the patch and works, so I thought I could mentor this task for GCI as I finished the task in 3hrs. I think I can pick some other bugs for mentoring and I will send in a patch for this one soon.

@Haritha28: Oh, ok, if you think it fits into GCI, feel free to mentor it, it wasn't my intention to prohibit this, I just want to make sure, that the task isn't too complicated for a newbie student :)

Victorbarbu subscribed.

I will claim this in GCI very soon!

Change 325049 had a related patch set uploaded (by Victorbarbu):
Convert Special:RecentChanges to OOUI [WIP]

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

@Haritha28 I cannot reach you on IRC. Can we talk there, please?

I finally got the patch out of the WIP status.

Here is a brief description of the change list:

  • Convert all the existing form fields to OOjs
  • Replace the limit links with a numeric \OOUI\TextInputWidget (+ JavaScript control)
  • Replace the days links with a \OOUI\DropDownInputWidget
  • Replace the from link with a checkbox
  • Use \MediaWiki\Widget\NamespaceInputWidget for namespace selection
  • Wrap the form in a collapsible \OOUI\PanelLayout
  • Create the rcpanelcollapsed user property (with a default to true) which is represented as a checkbox in the Preferences page.
  • Get rid of the legend as every possibly unknown abbreviation is self-explained by it's title attribute value and the legend was taking space uselessly

Current problems:

  • Since the days field was replaced with a dropdown, it has also been replace in the Preferences.php with a dropdown with the same options and same values. The value is correctly saved in the database and successfully read via $user->getIntOption(), however after the button *Save* is pressed in the preferences page, the value of the dropdown resets to the one given in the default attribute
  • There is currently no way of saving the panelcollapsed setting on the spot (e.g. when the user clicks the Collapse button, the setting is saved and remembered)
  • Some tests fail for the patch, and the error is Error: Widget 'namespace' not found. I am not able to reproduce this error in any circumstances and I am not sure why it happens. The error probably comes from a call to OO.ui.infuse() but the id of the field is correct.

Before:

pasted_file (555×1 px, 87 KB)

After:

pasted_file (915×1 px, 85 KB)

First of all: Thanks for your work @Victorbarbu!

However, I'm pretty sure, that the form in it's current state won't be merged :( The reason you'll see in the screenshots above: The current form is really small compared to the input and filter possibilities it provides, so the list of recent changes is in the focus of the users view. However, after applying your change, the form is nearly 4-times as big as before, and takes up to the complete height of my monitor now. The result: As a user I would need to scroll down the page to see what I really want to see: The list of recent changes. So we should work on getting the form as small as possible :)

Currently, there's a lot of space left at the right side of the form. Do you think you'll be able to use this space and fill it with form elements, which are now order one after one? That would shrink the size down, I think.

Another option would be to keep the textual input forms and links (such as the "show/hide" links) as they are and, for now, just convert the other inputs to OOUI. Later we could convert the other forms on top of it. This would also minimize the "new thing" for the users of this form :)

Secondly, I don't think we should re-order the form, as this could be a too much of change for the users at once. The order of the elements should be nearly the same as the filters currently are.

Also: The "collapse" link is a nice idea. However, it comes with two problems:

  • It doesn't solve the big form for users without JavaScript
  • The user still has to interact with the form to see the more important list of changes :)

What do you think about my suggestions? :)

The user still has to interact with the form to see the more important list of changes

@Florian, I think you missed the part where I said I added a user option for the form's default. However, initially, I thought "hey, if the user has the form open the first time and hits collapse, let's trigger something so that when they reload the page or change the changes page - i.e. go to page 2 on the changes list for example - the panel remains collapsed.

Currently, there's a lot of space left at the right side of the form. Do you think you'll be able to use this space and fill it with form elements, which are now order one after one? That would shrink the size down, I think.

I would be able to create a two-columns form, I think that's what you mean, but that implies creating a new layout in OOjs which would take time because nobody will merge that...

Screenshot from 2016-12-08 22-13-06.png (965×1 px, 171 KB)

@Florian, with the newest patch on Gerrit, the page looks like the image above on a 1920x1080 screen.

The form is 2.02x taller than the old one (including margins, borders and padding). I don't think it can go any smaller than this.

Currently Jenkins is complaining about the rcdays undefined index in $preferences ($preferences being the array holding the preferences generated by Preferences.php and extensions), when the Setup.php script is run. This is normal, because I changed the rcdays to rcmaxage so as to allow more time values (since this is expressed in seconds).

Of course I can just eliminate the $wgRCLinkDays and replace it with

$wgRCMaxAgeOptions = SpecialRecentChanges::$changesAgeDurations;

I am going to do this and then the documenttion on MediaWiki will have to be changed, right?

Trizek-WMF subscribed.

@Florian, with the newest patch on Gerrit, the page looks like the image above on a 1920x1080 screen.

You should try on a 1024x768 screen. That's small, but that would fit how people will perceive that change. We have continuous feedback from users who don't have a big screen and who don't like OOui because of the "waste of blank space".

For a general discussion on “spacing” and layout issues of OOUI forms see T136790.

Volker_E lowered the priority of this task from Medium to Lowest.Nov 6 2018, 4:39 PM

With T157642: Graduate New Filters UX out of beta on Recent Changes on ALL wikis finished, the scope of this task is now limited to a very small number of cases – as a result readjusting priority.

Volker_E renamed this task from Convert Special:RecentChanges to OOUI to Convert old Special:RecentChanges to OOUI (HTMLForm?).Jan 4 2019, 3:29 AM
Volker_E updated the task description. (Show Details)

Change 325049 abandoned by VolkerE:
Convert Special:RecentChanges to OOUI

Reason:
Abandoned for inactivity and priority of old RC being converted in presence of much improved RCFilters.

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

Jdlrobson renamed this task from Convert old Special:RecentChanges to OOUI (HTMLForm?) to Convert non-JS version of Special:RecentChanges to HTMLForm (OOUI or Codex).Jan 3 2024, 10:17 PM
Jdlrobson updated the task description. (Show Details)
Volker_E renamed this task from Convert non-JS version of Special:RecentChanges to HTMLForm (OOUI or Codex) to Convert non-JS version of Special:RecentChanges to HTMLForm (Codex).May 21 2024, 1:31 AM
Volker_E removed a project: UI-Standardization.