Page MenuHomeMiraheze

Attempt to improve ManageWiki usability and discovery
Closed, InvalidPublic

Description

Some of this will most definitely need community feedback, so tagging Notice. However, I can't give a 100% guarantee, at least from me, that we'll be able to successfully implement all of this. Although, we can definitely try and start somewhere and gradually implement some of the others in the longer term unless it is deemed impossible to achieve at the moment. I have no idea if it's all possible to do, and these are just some ideas that we could try to implement following some community feedback on them.

Module Improvements

Core

Special:ManageWiki/core could potentially be improved by maybe moving some of the primary settings, such as $wgFavicon, $wgAppleTouchIcon, $wgLogos (ManageWikiSettings has this split out as $wgLogo, $wgIcon, $wgWordmark, $wgWordmarkHeight, and $wgWordmarkWidth), $wgDefaultSkin, and $wgDefaultMobileSkin to Special:ManageWiki/core.

Central Core
I have thought of one thing here, and this is potentially completely unnecessary. But, I think it would be nice to allow searching for wikis by the server URL, so when tasks are created linking only the custom domain, additional looking up of the database name, it would also be useful when the custom domains no longer resolve, since the database name can't be found on-wiki, you'd have to look back at tasks to find the initial requesting task, in order to find the database name, to remove the custom domain from ManageWiki.

Extensions

One idea I have for this is to create a preference to be able to disable section tabs within Special:ManageWiki/extensions, except for "Other" and "Skins", which would revert to the old behavior of Special:ManageWiki/extensions. The reason this would be a good idea is that it would maybe allow easier discovery of extensions by being able to search using the browser word search functions. Additionally, the creation of the sections never went through community feedback, as it was before SRE started doing that. Whether this can even be done is yet to be seen, but it does seem like a good idea to attempt to do it. Furthermore, if the preference is not enabled, we should consider the redesign of the current sections for better discovery, as they currently for the most part use the sections in extension.json, which isn't always ideal, and it's hard to find some extensions.

Settings

Redesigning and reorganising the current sections of Special:ManageWiki/settings may be a good idea. We could also consider maybe pulling setting descriptions from the configuration description or descriptionmsg from extension.json/skin.json. Also, since Special:ManageWiki/settings, does support filtering by extensions or skins now at Special:ManageWiki/settings/<name>, we could maybe add a dropdown box or something above the form with options for every enabled extension and skin for easier filtering and visibility of each of their available settings, with the addition of MediaWiki core and all global extensions and skins as options as well.

Permissions

We could potentially improve Special:ManageWiki/permissions by maybe making it possible to add at least one configuration variable to the main part of Special:ManageWiki/permissions before entering into group permission modification. We could add the ability to create custom rights within the $wgAvailableRights configuration, which, of course, would need to be vetted to adhere to the disallowed rights, etc. But, doing this would potentially allow adding one of the most requested configuration variables to ManageWiki, $wgRestrictionLevels. If we did this, we could also consider moving $wgImplicitGroups to Special:ManageWiki/permissions instead of Special:ManageWiki/settings, where it is now. We could also consider adding $wgRevokePermissions as another tab in group permission modification to be able to configure that for each group. Another thing we could consider is supporting $wgGroupInheritsPermissions to allow certain groups to automatically inherit permissions from another group. We could also consider adding support for $wgGrantPermissions as well as $wgGrantPermissionGroups.

Namespaces

We could potentially improve Special:ManageWiki/namespaces by making it possible to add multiple values for $wgNamespaceProtection, as that config supports an array for multiple values as well. Some extensions even set multiple by default, but because of the fact we don't support them, ManageWiki only supports one, and therefore, only one is in the install step of ManageWikiExtensions. An example of this is StructuredNavigation for the "Navigation" namespace. The extension has two namespace protection permissions: structurednav-edit and structurednav-create. However, since ManageWiki only supports one, it only sets structurednav-edit in the extension install step. Another thing we may want to consider is allowing some of the ManageWikiNamespaces additional settings to be modified for the special namespace if it would work to do. Currently, the special namespace is completely disallowing modification, and under certain circumstances, setting additional settings for it may be necessary, or at least useful.


Global Improvements

User Experience

We could potentially improve the overall flow of the extension, by using heavy JavaScript, to make the user experience better, and allow us to continue modifying the main form after selection of a group or namespace in their respective modules, interactively with JavaScript, so virtually it would not need to reload.

Discovery

We should consider further improvement and discovery of ManageWiki as a whole to make it easier to use, provide better documentation, and make it more understandable and easy to use for less technical-oriented users. One idea could be a complete rewrite of the entire extension (or creation of a new module), which would essentially create a step-by-step wizard, either complete deprecation of the current modules or a whole new module, which you could use to find extensions or skins you want to enable, enable extensions or skins, continue to the next step, manage namespaces, continue to the management of permissions and settings for the extension or skin setup, with some sort for a wizard or something else for core stuff management.


New Additions

Supporting Hooks

We could potentially consider supporting some basic hooks in ManageWiki, potentially by creating a new "hook" type for Special:ManageWiki/settings, which would be able to modify hook output within ManageWiki. Of course, by doing this, we would need some sort of validation/sanitisation for user input within ManageWiki.

Better Validation of Configuration Variables

We should consider maybe something like a new ManageWikiValidation helper class or something to support better validation for numerous configs in both Special:ManageWiki/settings and Special:ManageWiki/namespaces. This would validate stuff like usage of https:// where required, to prevent user confusion, or CSP errors, which would sometimes be given if using http://. An example of this happening is T9032. If it is done incorrectly, then this would immediately give the user an option to correct their mistake and not save the setting otherwise.

Support Making Reason Optional

Reasons are not always necessary, it would be nice to not require them, since often times users just use something like . since they don't need to add a reason, but the field is required. However, one case it may be required, is ManageWiki changes on Meta, so potentially, we could make it a configuration variable, disabled by default, and enabling on certain wikis where it is necessary, such as metawiki.

Add New File URL Type

Adding a type of file URLs can be useful to allow users to not have to make the input use the full static URLs, but rather just File:Example.png, which ManageWiki could then expand to the full URL via lookup when setting the config. This is useful for new users who are not aware they need to use the full static URL for files. Alternatively, we could add validation that the inputs include the static URL and warn users that they do not, but need to.

NOTE: Some of this would likely improve the overall reception of ManageWiki, it's usability, flexability, and discovery, as pointed out by the 2022 annual survey, the larger opinion seems to show necessity in that. We should try and garner community feedback on the ideas listed here, or other ideas users may have, so work on this can begin to hopefully improve that over the next year.

Event Timeline

Unknown Object (User) triaged this task as Low priority.May 8 2022, 16:39
Unknown Object (User) created this task.
Unknown Object (User) moved this task from Backlog to Features on the ManageWiki board.May 8 2022, 17:23
Unknown Object (User) moved this task from Backlog to Long Term on the MediaWiki (SRE) board.
Unknown Object (User) updated the task description. (Show Details)May 8 2022, 22:15
Unknown Object (User) updated the task description. (Show Details)May 8 2022, 22:35
Unknown Object (User) updated the task description. (Show Details)May 8 2022, 22:38

Though I am not sure of the details of some Special:ManageWiki/subpage that I did not use, I agree that there should be an improvement.
Some thought:

  • APIs are needed to use JavaScript and it is not implemented yet at all afaik. I think removing technical debt will be a boring task to do.
  • In addition to the community feedback, it would be helpful if there are analytics like WMF are collecting by using Extension:EventLogging because watching the activity of users can give motivation and hints to developers. But this is not needed hardly but just my thought.
  • There are some options to choose to write JavaScript modules on MediaWiki: OOUI, Mustache, Codex (Vue.js), etc. It is hard to say which one is best because all of them are potentially deprecated or in development.

Anyway, thank you for creating this task!

Unknown Object (User) removed Unknown Object (User) as the assignee of this task.May 9 2022, 05:44
Unknown Object (User) updated the task description. (Show Details)
Unknown Object (User) updated the task description. (Show Details)May 9 2022, 05:47
Unknown Object (User) updated the task description. (Show Details)
Unknown Object (User) updated the task description. (Show Details)May 9 2022, 16:14
Unknown Object (User) updated the task description. (Show Details)Jun 16 2022, 06:47
Unknown Object (User) updated the task description. (Show Details)Jul 16 2022, 20:39
Unknown Object (User) updated the task description. (Show Details)
Unknown Object (User) updated the task description. (Show Details)Jul 16 2022, 20:43
Unknown Object (User) updated the task description. (Show Details)Jul 24 2022, 22:50
Unknown Object (User) added a subscriber: Cigaryno.
Unknown Object (User) updated the task description. (Show Details)Aug 13 2022, 16:02

This feels like am infinitely defined task - where does the scope end? What's the end goal? I think this should be split up into tasks for each part so they can be tracked, fleshed out and opinions can be sought in a more defined manner.

Unknown Object (User) added a comment.Aug 13 2022, 19:41
In T9195#195130, @John wrote:

This feels like am infinitely defined task - where does the scope end? What's the end goal? I think this should be split up into tasks for each part so they can be tracked, fleshed out and opinions can be sought in a more defined manner.

I was just thinking the same thing after my last update also. The main goal is to make ManageWiki more flexible, and easier to use for end-users. Especially based on the results of feedback we have received, including confusion users have surrounding ManageWiki, more the new, beginner users, and the results of the recent annual survey. But for the purposes of tracking, etc.... multiple tasks may be good to split this off into.

Unknown Object (User) moved this task from Unsorted to Long Term on the Universal Omega board.Sep 20 2022, 23:15

I'm going to make a subtask for the "using heavy JavaScript to modify groups and namespaces" part, I have an idea on how to do that without adding any new APIs (at least the namespaces part).

I'm going to make a subtask for the "using heavy JavaScript to modify groups and namespaces" part, I have an idea on how to do that without adding any new APIs (at least the namespaces part).

Maybe not, I figured out how to do it with namespaces but I don't think its possible with groups.

Unknown Object (User) closed this task as Invalid.Mar 18 2023, 03:29
Unknown Object (User) unsubscribed.
Unknown Object (User) subscribed.