@Ladsgroup What do you have in mind?
Currently clarity comes down to categorization and titles of the special pages.

Would you think

• a different categorization,
• better titles (which are tasks for specific special pages),
• additional descriptions to the page titles
• search (I don't think that would help at all for sev reasons)

could help?

In T219543#5067063, @Volker_E wrote:

@Ladsgroup What do you have in mind?
Currently clarity comes down to categorization and titles of the special pages.

This can change IMO

Would you think

• a different categorization,

Possibly but the underlying problem is the number of special pages is large now.

• better titles (which are tasks for specific special pages),
• additional descriptions to the page titles

Yes, that would help

• search (I don't think that would help at all for sev reasons)

I agree, let's not do this one

There are so many way to improve the current system but I'm not sure if they are good ideas UX-wise:

• Making it possible to have special pages repeated in different categories
• Making it like Special:Preferences, use tabs instead of section
• Let people have "favorite special pages", things they use quite often
• Add icons to sections/tabs/special pages to reduce to cognitive load?

Change 945950 had a related patch set uploaded (by Krinkle; author: Krinkle):

[mediawiki/core@master] specials: Remove "hide" button from Special:Specialpages legend

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

Change 945950 merged by jenkins-bot:

[mediawiki/core@master] specials: Remove "hide" button from Special:Specialpages legend

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

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

[mediawiki/core@master] [WIP] Redesign Special:SpecialPages

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

Couple notes, which we mostly discussed at the Hackathon.

• All columns in the table should be sortable.
• For the restricted column, this currently only appears for logged in users, so we should consider if it should be visible to logged out users as well or if we should omit the column to logged out users.
• Additionally, let's use something different as a header for that column, something like "Access" or something else, then each row can display either "Restricted" or "Normal".
• During Hackathon, we discussed the potential column for a "Description" of the special page for better explanation as to what it is. Not sure we we want to add this, and how we could dynamically populate it.
• Possibly just a slight oversight, but the search placeholder should say "Search special pages".

I made a lot of changes. This is how it looks like now:

Aliases, categories and access all are searchable now.

Making the table sortable is a lot of work weirdly. I will see what I can do but I don't think it's a blocker for merging the change.

Without "category" being sortable, you can't recreate the old organization of the page (grouped by category), which seems like a regression in functionality.

@Ladsgroup Is it possible to adopt Codex here? We have a sortable Table component that could work well here.

In T219543#10810144, @cscott wrote:

Without "category" being sortable, you can't recreate the old organization of the page (grouped by category), which seems like a regression in functionality.

I personally disagree. 1- These categories are quite subjective and has never had helped me as a Wikipedian in the past twenty years. e.g. why "Try hieroglyph markup" is in "Data and tools", the same category as "Wikimedia wikis"?, why "Mass delete" is in Page tools and not in "Recent changes and logs" or "Maintenance"? Why we have both "High use pages" and "Maintenance reports"? and many more 2- When you search for the name of the category, you will see all special pages in the category:

That being said, I will try to see if I can add sorting.

In T219543#10810945, @DTorsani-WMF wrote:

@Ladsgroup Is it possible to adopt Codex here? We have a sortable Table component that could work well here.

Yeah, the biggest problem is that I have to re-implement the search functionality from scratch. It uses the css-only codex already.

The last patch implements sorting. It was waaaay simpler than I thought:

Great! Any chance we could get the sorting icon to be directly next to the header text?

This is very cool @Ladsgroup. One minor comment: I think the placeholder should be more descriptive despite being in the area, as there are two searches on the view and general "search" might confuse folks.

I changed the input placeholder to "Search special pages". Regarding making it next to the header text. I think it depends on the upstream and if it gets fixed there, it'll be done automatically here too.

When you say "upstream" do you mean in Codex? In the Vue version of the component, the sorting icons are currently next to the header text.

In T219543#10816404, @DTorsani-WMF wrote:

When you say "upstream" do you mean in Codex? In the Vue version of the component, the sorting icons are currently next to the header text.

I mean css-only Codex. As I said before, if I want to use Vue Codex, then I have rewrite the whole search functionality from scratch which is way too big for a volunteer side project.

Right. So sorting is available in the CSS-only version, but the sorting icons are not aligned similarly to the Vue version? Looping in @AnneT for some Codex engineering support here.

In T219543#10817141, @DTorsani-WMF wrote:

Right. So sorting is available in the CSS-only version, but the sorting icons are not aligned similarly to the Vue version? Looping in @AnneT for some Codex engineering support here.

We don't explicitly support sorting in the CSS-only version, although it is possible to set it up - you'd just have to use the same markup that's output by the Vue version for the sortable table headings.

We actually do this in CodexTablePager, a class in core based on TablePager that outputs a server-rendered Codex Table and supports sorting - I wonder if that could be used here, or at least referenced for the sorting markup.

Change #1145993 had a related patch set uploaded (by A smart kitten; author: A smart kitten):

[mediawiki/core@master] RELEASE-NOTES: fix typo in note for the new `Special:SpecialPages` design

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

Change #1141454 merged by jenkins-bot:

[mediawiki/core@master] Redesign Special:SpecialPages

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

Change #1145993 merged by jenkins-bot:

[mediawiki/core@master] RELEASE-NOTES: fix typo in note for the new `Special:SpecialPages` design

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

Suggestion for the tech news:

[[Special:SpecialPages]] have been redesigned to improve user experience. Improvements include: Ability to search in names and aliases of the special pages, sorting, more visible marking of restricted special pages and mobile friendlier look.

Edit mercilessly.

It's live in beta cluster if people want to play with it: https://en.wikipedia.beta.wmflabs.org/wiki/Special:SpecialPages

Search field should probably have a bigger width, as the current one makes sense for English but would probably not display complete label in other languages (Search special pages is something like Найти служебную страницу in Russian, for instance).

Some additional suggestions:

1. Testing it at https://ru.wikipedia.beta.wmflabs.org/wiki/Служебная:Спецстраницы with Russian version, it would be good if the search actually supported entering Version (canonical special page name) to find Special:Version. Currently it seems like even the special pages in the current language name are not used when they don’t match the visible label (in Russian, that can be tested with entering Письмо участнику, which is Служебная:Письмо участнику, translation for Special:EmailUser)
2. Also, might be a good idea to support entering Special:Version (or Служебная:Версия) even if it is a bit redundant. In that case, Special: prefix could just be removed from the query. I think that is how a lot of people think about special page names, so this might reduce friction from the new search for power users.
3. It would be good if you could filter things in the table to a specific category by clicking on its name. It could just involve entering the name into search field programmatically, as far as I can tell.

For Tech News, as this change won't arrive until mid-week for most users (IIUC), I propose linking the Beta Cluster page directly. I will use this draft, unless folks suggest further improvements within the next ~24 hours:

• Later this week, an updated [[Special:SpecialPages]] design will be used. This page has been redesigned to improve the user experience in a few ways, including: The ability to search for names and aliases of the special pages, sorting, more visible marking of restricted special pages, and a more mobile-friendly look. The new version can be previewed at Beta Cluster now. [1]

• Later this week, an updated [[Special:SpecialPages]] design will be used. […]

This might just be the way that I'm reading it, but "Later this week, [[Special:SpecialPages]] will be updated with a new design" feels like it reads slightly easier for me here.

Also, should we invite people to leave feedback on the new design (if any) in this task?

In T219543#10827855, @A_smart_kitten wrote:

This might just be the way that I'm reading it, but "Later this week, [[Special:SpecialPages]] will be updated with a new design" feels like it reads slightly easier for me here.

Agreed, thank you, now updated on Meta.

Also, should we invite people to leave feedback on the new design (if any) in this task?

Seems reasonable, though I'm mindful that the changes were implemented as a volunteer side project, so any extensive change-requests might be more complicated. However, now added to the entry on Meta.

What determines the default order of the categories? It doesn't seem to be alphabetical nor the same order as in the old UI. I think it would be more intuitive and frictionless to use the old category order (or something very similar) as a default since it kinda reflects the relative importance of each category of special pages.

In T219543#10833030, @Samoasambia wrote:

What determines the default order of the categories? It doesn't seem to be alphabetical nor the same order as in the old UI. I think it would be more intuitive and frictionless to use the old category order (or something very similar) as a default since it kinda reflects the relative importance of each category of special pages.

The previous sorting was actually based on first special page in that category got registered which could be very random and had no real logic behind it. For example, if extension Z introduce a new category A, and extension Q introduce new category of Y, depending on the order of loading extensions, A might come before Y or other way around. The only thing the old way did was to move "misc" category to the last. There is no easy way to allow categories to have an order since extensions introduce new ones and you need to have a way to incorporate all of that complexity somewhere.

The current order is alphabetical but based on key name of the special page category, so "RecentChanges and watchlist" comes earlier because the key for it is "changes"

Very nice. Any interest in adding a third column that displays the special page name in an unhidden way? So for example, Special:ListDuplicatedFiles instead of "List of files with duplicates". I think this would make the page more useful to developers. The ability to alphabetize by this column could also be useful.

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: Redirects to special pages don't display Mediawiki:redirectfrom (aka mw-redirectfrom) 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.