After doing T99256, we should apply the same transformation to the RecentChanges page.
Description
Details
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Convert Special:RecentChanges to OOUI | mediawiki/core | master | +669 -294 |
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Open | BUG REPORT | None | T353002 RecentChanges, RecentChangesLinked and Watchlist should use Codex for their form elements | ||
Open | None | T117740 Convert non-JS version of Special:RecentChanges to HTMLForm (Codex) | |||
Open | None | T117741 Convert old Special:RecentChangesLinked to HTMLForm (Codex) |
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).
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 :)
I created the task in GCI: https://codein.withgoogle.com/dashboard/tasks/4885660284485632/ and assigned you as a mentor @Haritha28 :)
Change 325049 had a related patch set uploaded (by Victorbarbu):
Convert Special:RecentChanges to OOUI [WIP]
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:
After:
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...
@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?
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".
Please, take a look at T119084: Options form at the top of old Special:RecentChanges needs cleanup (and T50615) as well to get rid of it in one go.
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.
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.