Not sure if this is the right place to leave feedback; if it is, it isn’t obvious; the "Add Actions" drop-down seems particularly confusing. I expected to see an "Add Comment" option but found done. Anyway, if this is not the place for my comments, please move them to the right place.

Anyway, here are my comments after playing with the preview for a bit;

1. Sorting by name doesn’t seem to me particularly useful, particularly with the search capability. I would gladly give it up if it keeps other features from being implemented 
2. Sorting by category seems more natural. But since we don’t really need to sort by name, why not just keep the list permanently sorted by category?
3. Since categories are containers for pages, it seems counterintuitive to have the category on the right. If you’re gonna have a tabular arrangement, it is more intuitive to have the category on the left. 
4. Better still would be to have a hierarchy with the individual pages grouped under each category.
   1. Include the ability to collapse all, expand all, or collapse/expand individual items.
   2. When searching, continue to show the matching pages within their categories
   3. This hierarchical method would use screen real estate better, especially useful on mobile devices, which is how I usually use Wikipedia.
5. The hierarchy could be expanded to a 3-level hierarchy
   1. The 1st top-level category be "Special pages by category" under which the 2nd level would be the individual categories and the 3rd level the individual pages. These categories would be mutually exclusive (no overlap) and jointly exhaustive (they include all special pages)
   2. Additional top-level categories would be possible, rather like adding additional columns to the tabular arrangement for different categorization schemes, One example might be "Special pages by number of parameters" with 2nd levels "Special pages with no parameters", "Special pages with 1 or more parameters, all optional", "Special pages with one or more required parameters". These 2nd level categories would also be mutually exclusive and jointly exhaustive. This isn't the best example for another categorization scheme, but it was the first one I could think of.
   3. Some top-level categories might have overlapping 2nd level categories (ie, not be mutually exclusive). Other top-level categories might not include all special pages (i.e., their 2nd level categories might not be jointly exhaustive).
   4. One final top-level category could be "All special pages alphabetically" with 2nd level categories for individual letters or letter ranges (e.g., A/B/...T/UV/WXYZ).
6. It might be nice to have a brief description of each special page.
   1. Since even a 1-sentence description would consume precious real estate, they should be collapsible.
   2. There should be buttons to hide all and show all descriptions, the former the mobile default and the latter for desktop view.
   3. The user should be able to show individual descriptions. When all are hidden, I might think, This sounds like what I want, but let me check the description first.
   4. The user should be able to hide individual descriptions. When all are shown, I might think, This is not what I want, I'll hide it while I peruse other items.
   5. In addition to hiding/showing descriptions, I'd like to see the first sentence of long descriptions followed by a <u>show more</u> link what would expand to show the whole description, of course with a <u>show less</u> link at the end.
   6. With the more/less option, there should be whole-list options: hide all / show all brief / show all full.
   7. The search option should probably also search through the descriptions.
   8. When descriptions are hidden, they could be visible as a preview by hovering over the individual show/hide icon, and hovering over the <u>show more</u> link should show preview the full text. (These hover previews would be useful in desktop mode but not at all in mobile.)
7. The tech notes promised searching by both the name and any alias for a page. But nowhere do I see the aliases listed. As someone who likes to craft special page links, it would be really nice to know the synonyms.
8. Each special page could include a list of that page's categories ... each of which would be a link to the "special pages" page with that category expanded and all others collapsed. Another link "Related special pages" would navigate to the "Special pages" page with all of that pages categories expanded.

I hope these thoughts give you some ideas on how to expand on your good work.
~~~~

There are two search fields, which is confusing in vector. In monobook is it better, but search field should be in left.

Sorting arrows are in confusing position - for left column near right header

Former page was beettr on PC, now it is too wide ad space consuming, I need more srolling to see all members. In old desiggn i see on my 27" monitor 37 pages (and half of screen is list of headres), in new only 16. What about responsive columns to see 32 members?

It would be useful to permanently hide some specialpages per wiki. e.g wikis without local uploads can hide Media reports and uploads

Sorting by name doesn’t seem to me particularly useful, particularly with the search capability. I would gladly give it up if it keeps other features from being implemented

Adding the ability to sort a column is effortless. It's a one liner in the Pager class :)

I think adding the ability to sort a column is pretty low effort. I think you just add the HTML sortable class to the Codex column. Code.

@Novem_Linguae; Yes, I know it is trivial to add sorting to a tabular display. But note that I said "I would gladly give it up if it keeps other features from being implemented" Specifically, my idea of having hierarchical drill-down makes such simple sorting impossible. Since sorting adds such little value compared to the great value of a collapsible hierarchy, ditch the table. In the process, you make the list more compact, resolving one of @JAnD's concerns.

To summarize, this change makes things worse, not better. Please do not promote it.

I use this page daily in different languages and I am disappointed with the design change. The new look now rather degrades the UX compared to the old version. It's not a matter of habit, but of adding more time to open pages I use daily. Quick access has suffered for several reasons:

1. Quick access to "Maintenance reports" is the primary role of this page. Previously, these links were first in the list and were available immediately upon opening in multiple columns - this took up 30% of the whole screen and was displayed immediately. Now the same listing take up 100% of the screen, and are accessible after scrolling the entire screen 3 times. This is not quick access, it's the opposite.
2. Stretching rows seems unnecessary. Technical pages like this don't need indentation to add lightness to the UI to look nice - it's just a table format with technical data that needs compactness, not stretching. (see solution #1 below)
3. I find it odd to give both a separate column and color for Public/Restricted status. Just a color would be sufficient.
4. The tabular format with a single column is awkward and non-optimal itself when each item is consisted of 2-4 word phrases. I'd rather expect to output all the list on 1-2 screens, over stretching them to 20 screens (see another solution #2 below)
5. Title search might work for first time users, but for regular users it's inconvenient to type in the same word every day. (see solution #3 below)

General problems with this page: items lack page descriptions as some titles are not intuitive. For example would I understand the role of the "Impact" page based on this name only? I would rather replace the "Access" column with an 'i' icon, hovering over it would pop up a tooltip on the essence of the page or something like that (maybe hover-tooltip on the link itself).

Possible solutions to improve quick access:

1. Reducing indentation: in the screenshot I showed how it would look with 0.5 indents instead of 1.375, which seems more convenient, and allows you to view more items at a time.
   
2. 'Moving blocks' functionality: It would be much more convenient to have a flexible interface in 2-3 columns where you could move grouped items as you like and fix them by sticking - e.g. move and lock "Maintenance reports" in the first column on the top, then move and lock "High usage pages" to the second column at the top, then move and lock another block to be second in the first column, etc. This is an ideal solution and close to the previous design and at the same time maintains the unified tabular look of the new design, but I realize it would require building from scratch. Check the video for a quickly made draft preview.

3. Setting favorite items: You could add a bookmarking/stars functionality, with saving at the top of the list selected items. User puts a star on item and it is permanently saved at the top of the page.

These changes will also retain the current look, but will bring back the usability that it had before. But for now, I'd rather bookmark the individual pages I need in my browser than continue to use the "Special pages" as I used it before.

Putting everything into some massive table is NOT an improvement.

What might be helpful is better shortcuts to special pages. But that requires T326054: Special pages don't display Mediawiki:redirectfrom (aka mw-redirectfrom) when redirected to to be addressed. Then redirects like SP:RC → Special:RecentChanges are very useful.

There are some inconsistencies in the access labels – why is Special:Watchlist labled as "Restricted" while Special:Preferences, Special:GlobalPreferences, Special:ChangeEmail, Special:PasswordReset and a couple of other ones which are available to all logged-in users are labled as "Public"? See dewiki discusssion (I can file a separate ticket if this is out of scope for this task).

In T219543#10854801, @Johannnes89 wrote:

There are some inconsistencies in the access labels – why is Special:Watchlist labled as "Restricted" while Special:Preferences, Special:GlobalPreferences, Special:ChangeEmail, Special:PasswordReset and a couple of other ones which are available to all logged-in users are labled as "Public"? See dewiki discusssion (I can file a separate ticket if this is out of scope for this task).

That's a different issue. We just changed to UI, no logic change has occurred. In long-term, I think we should split into three categories: Public, Users, Restricted. But yeah, out of scope of the frontend change.

What kind of UX/UI textbook did you follow, guys, for making decision, that one big 3-column table is more readable than previous design?

In T219543#10855157, @Ladsgroup wrote:

That's a different issue. We just changed to UI, no logic change has occurred. In long-term, I think we should split into three categories: Public, Users, Restricted. But yeah, out of scope of the frontend change.

Can you give any estimate on when that sort of work (as well as fixing other issues highlighted above) would be done? Because tbqh while some of the changes were an improvement, there is still a lot to do to make the page actually usable. The biggest issue being that you cannot even search for special page names in the wiki language if they do not match the visible label for the page in the list (on Russian Special:SpecialPages, the new files list is called Галерея новых файлов but the special page name is Новые файлы for New files, but you cannot search for the name, never mind the canonical special page name).

you cannot even search for special page names in the wiki language if they do not match the visible label for the page in the list

And how many special pages are like this exactly?

Also, it's been already implemented:

Probably due to some bug it's not indexing it correctly.

It seems like it’s not working then. The issue might be that only canonical Latin names are entirely in lowercase in those data parameters, but Cyrillic ones aren’t. (Ideally, as I wrote above, newfiles should also be there though.) As to the amount of such special pages, I don't know how to count that, but probably many depending on the language. Visible page titles are more verbose than their internal names quite frequently.

Change #1152332 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/core@master] SpecialPages: Use per-language lowercase

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

Did you also remove the link to Special:SpecialPages? I can't find the link to the page nowhere in the UI... It used to be in the menu, but now I can't find it in any menu of the Vector 2022 skin.

Additionaly I'd like to agree with the ones saying that this new design is a UX regression instead of an improvement. There's a big difference between having different group of tools grouped by categories or a huge table with a column with the group name. It's harder to find the link we need easily. With the old interface we could go to the links we needed fast once we knew in which group they were located, but with the new design the only rows that are easy to find without the search are the restricted ones. It was more convenient just going to the part of the page where we knew the report we wanted was than having to use the search filter.

Special pages link was moved to sidebar instead of Tools menu in Vector 2022 (and other skins by extension), but that’s unrelated to this task. See T333211: Reconsider position of special pages link, currently in the page tools

In T219543#10873679, @stjn wrote:

Special pages link was moved to sidebar instead of Tools menu in Vector 2022 (and other skins by extension), but that’s unrelated to this task. See T333211: Reconsider position of special pages link, currently in the page tools

Link to Specialpages is missing T395757

Anyway -- Would it be possible for people who somehow think this is a good idea to get consensus for these disimprovements to be made before they are actually rolled out?

In T219543#10855157, @Ladsgroup wrote:

In T219543#10854801, @Johannnes89 wrote:

There are some inconsistencies in the access labels – why is Special:Watchlist labled as "Restricted" while Special:Preferences, Special:GlobalPreferences, Special:ChangeEmail, Special:PasswordReset and a couple of other ones which are available to all logged-in users are labled as "Public"? See dewiki discusssion (I can file a separate ticket if this is out of scope for this task).

That's a different issue. We just changed to UI, no logic change has occurred. In long-term, I think we should split into three categories: Public, Users, Restricted. But yeah, out of scope of the frontend change.

It is a issue from the patch set (ed016f4880f5d05367fa8c9858d1864d51861d15).

The old page uses the terms

• Normal special pages.
• Restricted special pages.

The new page uses the terms

• Public
• Restricted

But "Public" is not the same as "Normal" when special pages that requires log in are shown on Special:SpecialPages for all users (like Special:Preferences)

Change #1152332 merged by jenkins-bot:

[mediawiki/core@master] SpecialPages: Use per-language lowercase

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

In T219543#10885464, @Umherirrender wrote:

In T219543#10855157, @Ladsgroup wrote:

In T219543#10854801, @Johannnes89 wrote:

There are some inconsistencies in the access labels – why is Special:Watchlist labled as "Restricted" while Special:Preferences, Special:GlobalPreferences, Special:ChangeEmail, Special:PasswordReset and a couple of other ones which are available to all logged-in users are labled as "Public"? See dewiki discusssion (I can file a separate ticket if this is out of scope for this task).

That's a different issue. We just changed to UI, no logic change has occurred. In long-term, I think we should split into three categories: Public, Users, Restricted. But yeah, out of scope of the frontend change.

It is a issue from the patch set (ed016f4880f5d05367fa8c9858d1864d51861d15).

The old page uses the terms

• Normal special pages.
• Restricted special pages.

The new page uses the terms

• Public
• Restricted

But "Public" is not the same as "Normal" when special pages that requires log in are shown on Special:SpecialPages for all users (like Special:Preferences)

"Normal" is an even worse term to describe non-restricted special pages. What does "normal" mean? Normal in what way? How Special:Watchlist is not "normal" but "Special:Preferences" is?

The opposite of restricted is unrestricted.

Just like the opposite of improvement is disimprovement.

Please take note.

I also agree that in its current form, this is a usability regression:

• The two pieces of metadata attached to each page don't really warrant a table layout, especially as one of them (public/private) is not of particular interest to the user in most cases. If you can access the page, it's somewhat incidental that other users can't, and so displaying this subtly with italics (as it was before) or a padlock icon would be sufficient.
• While the categorisation is sometimes arbitrary and perhaps not the best way to find special pages, it didn't restrict the ability to search for a special page which could be done with native ctrl+f. We could also easily implement a search on a multi-column list, similar to what I implemented on Special:Preferences, where the contents of the page gets filtered as you type.
• Having multiple columns made it much easier to scroll through all the preferences (at least on desktop) and see what was available. It is also inherently more responsive that a table layout, and the mobile version of the page is even longer now on narrow devices, which means the only way to find a special page is by search, whereas previously it would've be reasonable to browse by category.

I think a better use of the space on desktop would look something like:

One could even allow more columns to make it easier to visually search

Search would just filter the list as you type:

As a frequent user of this Special page on many wikis, I really like Ed's design ideas. Strong +1.

Context/use-case/user-story: I'm very much a visual-snapshot-memory type of searcher, and I prefer using a mouse over typing.
Hence I've always found the pages I'm looking for within this index, based on my memory of the "chunk size", and relative-location within the page, and skimming for keywords in the ==Section== headings or the lists themselves.

One additional idea (perhaps not needed, but worth considering) is adding a default "Table of Contents" at the top/side.
IIRC we've never done this by default (and https://wikiconference.org/wiki/Special:SpecialPages doesn't have one which I guess confirms that), but some gaming wikis I'm familiar with have added one, e.g. https://noita.wiki.gg/wiki/Special:SpecialPages and https://support.wiki.gg/wiki/Special:SpecialPages
I hope that helps!

I like tabular data (Ladsgroup's approach) more than tiles (Ed's approach). With tiles, my eyes zig-zag a lot, adding mental burden and making scanning slow. A tabular presentation also makes sorting really easy.

One possible issue with the current page is the table rows have a lot of padding, making it difficult to fit lots of data onto the screen. I can fit about 11 rows onto my screen -- I think that could easily be doubled by removing padding.

One nice thing about tabular data is it's easy to add columns. Above I recommended adding a column for the special page name, i.e. "Pages linking to disambiguation pages" in one column and then "Special:DisambiguationPageLinks" in another column. If we wanted to add a "description" column to go into more detail ("Description of this page" in Ed's screenshot), that would also be super easy.

@Esanders 's approach is clearly much better.

One thing that gets to me about the new tabular format is the fact that (it seems like) there's a lot less information conveyed in the same amount of 'physical' screen-space, compared to the previous layout. It could also be seen as unnecessarily repeating some of the same information over and over again — in the old layout, a special page's category was denoted by which section of the page it was listed in; however, in the new design, this category information has to be repeated on each table-row/for each special page.
If I had to choose between the current new design & @Esanders' proposed design; to be honest, I'd probably choose Ed's.

I'd especially be cautious of adding any new columns to the current/new table design (if it's kept), given that — as things currently stand — words in the table are already squashed/split onto multiple lines on mobile:

Change #1165907 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/core@master] Special:SpecialPages: Restore multi-column but keeping indexed search improvements

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

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/0cd0d6a46c/wiki/Special:SpecialPages

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/0cd0d6a46c/w/

Test wiki created on Patch demo by ESanders (WMF) using patch(es) linked to this task:
https://patchdemo.wmcloud.org/wikis/898d4c0581/wiki/Special:SpecialPages

If this is still being iterated on:

I'd like to see the specific user group providing access to a specific link in the column currently labeled "Access" (which I already know is being queried for). It would help all the people with lots of groups to know who can see what, and forms something of an actually useful dissection for that column (rather than arbitrary buckets of "everyone" and "restricted"). And it doesn't need to be re-translated or otherwise have concerns of l10n thrown at it.

(This suggestion should apply regardless of whether it's the land of tables, cards, or a return to the prior "un pretty but generally more functional columns of lists of links".)

Cross-referencing to some discussion about the redesign taking place on enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#SpecialPages

@DTorsani-WMF could we get feedback on the new patch considering on Gerrit your opinion was used to sort of ‘block’ its merge?

In T219543#11072964, @stjn wrote:

@DTorsani-WMF could we get feedback on the new patch considering on Gerrit your opinion was used to sort of ‘block’ its merge?

It looks like it was merged, despite people here trying to tell whoever did it that it was total garbage.

@Bugreporter2 They were talking about Ed's new patch, on which @Ladsgroup left the comment "The change was designed by a designer (Derick), Please before merging the revert, go a designer to sign off on it."

Feel free to merge the revert. This design was an idea at a hackathon. It was not tested or thoroughly discussed. In the future, we should test this type of design change more thoroughly, and if we wanted to move forward with a table view, we should consider having options for the page view, i.e. category view, table view, etc.

Change #1165907 merged by jenkins-bot:

[mediawiki/core@master] Special:SpecialPages: Restore multi-column but keeping indexed search improvements

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

I just merged the patch which restores the previous design, but keeps the addition of the search box. These changes will go live later this week, on the usual schedule (Tuesday-Thursday).

I saw that patch when it was submitted for review, and I saw Derek's comment on it today, but I had no idea there was a vigorous discussion ongoing on this task. I've read it now and I agree with many of the arguments against the the table, which are mostly about the poor use of space and poor scannability (lack of headings). When I first saw the redesign that went live in June, I was a bit concerned about that myself, but I thought that the addition of the search box was a decent substitute. Certainly, though, it seems better to just have them both. (I also really liked the search box because, unlike browser search, it searches in special page aliases in addition to the visible titles, and sometimes they're quite different.)

If anyone wants to work on design changes to this page again (Ed's mockup at T219543#10909252 looks interesting), I would suggest starting a new task, so that the discussion, which got a bit heated, can restart in a better mood – just drop a link here if you do that.

I'm at a loss as to why you didn't remove the search box too. Duplicating what all browsers already provide (find in page) seems like such an uncalled-for addition to the mounting tech debt.

If your solution to "finding a special page is getting harder and harder, now I only search in the page to find the special page I want" is providing the same feature, you haven't solved anything. And I don't think it needed solving at all. The user had already found the solution.

The table of contents does not get updated while searching. This is especially bad UX in non-Vector 2022 skins.

I'm at a loss as to why you didn't remove the search box too. Duplicating what all browsers already provide (find in page) seems like such an uncalled-for addition to the mounting tech debt.

It does do something different from the browser-provided search: it includes the aliases.

It does do something different from the browser-provided search: it includes the aliases.

That's also bad UI/UX if you can't tell.

No, it’s actually great because then people who know a special page by a certain name would be able to find it even if they don’t know the new name. Though there is an unresolved problem with that where canonical English name of the special page isn’t included in the searchable terms (personally I don’t know how to fix it so I haven’t tried).

I mean the fact you can search for aliases should be obvious in the UI.

In T219543#11076262, @Nardog wrote:

I'm at a loss as to why you didn't remove the search box too.

Aside from the aliases, which everyone else already explained, and which I also mentioned in my previous comment, I think the search box has the following advantages over the browser search:

• It filters the list to display just the matching entries, instead of requiring you to scroll the page or jump between the results to see every result
• It gives results faster than the browser search
• It is more easily accessible and discoverable on mobile

Also, I just reviewed and approved a patch that someone else made the effort to write. There were many reasonable ways to compromise on the redesign, but this is the one that was proposed, and it seemed reasonable enough to me.

Duplicating what all browsers already provide (find in page) seems like such an uncalled-for addition to the mounting tech debt.

I think this has a very low "tech debt" cost. It has no new external dependencies (that we would have to regularly update), and can't become a dependency of anything else (which would prevent us from making changes to it, and ossify any bad decisions). If it ever becomes a problem, it can be easily removed.

The table of contents does not get updated while searching. This is especially bad UX in non-Vector 2022 skins.

Huh, yeah, that's pretty bad. Maybe the search box could be moved below the TOC, or maybe the TOC could be removed while searching.

In T219543#11076852, @stjn wrote:

Though there is an unresolved problem with that where canonical English name of the special page isn’t included in the searchable terms (personally I don’t know how to fix it so I haven’t tried).

Oh, that'd be nice to have.

Change #1178091 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/core@master] Special:SpecialPages filter the TOC as well when searching

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

In T219543#11080413, @matmarex wrote:

In T219543#11076852, @stjn wrote:

Though there is an unresolved problem with that where canonical English name of the special page isn’t included in the searchable terms (personally I don’t know how to fix it so I haven’t tried).

Oh, that'd be nice to have.

There we go. Vector-2022 completely throwing away the toc classes that other skins use made it more of a pain, but...

Change #1178091 merged by jenkins-bot:

[mediawiki/core@master] Special:SpecialPages filter the TOC as well when searching

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

Test wiki on Patch demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmcloud.org/wikis/898d4c0581/w/