WARFRAME Wiki:Desired Features

Documenting wiki features that stakeholders desire. Be specific. Unrealistic features (in the business sense) are welcome as "stretch" goals for a general sense of feature scope. For guidance, write your desires as a user story: "As a <user_type>, I want to be able to <some_action> so I can <reason/purpose>".

Legend:

• ⭐ - important

Last updated: Tue, 23 Jul 2024 01:40:45 +0000 (UTC) by User:Cephalon Scientia

Wiki Readers and Users[]

• ⭐ Improvements to Fandom Discussions:
  • Ability to filter posts by date/content type. Right now it is very difficult to find historical posts for archival reasons.
• ⭐ Ability to search by keywords on pages in search modal. This is especially important on Lua modules since a developer may want to track down which modules a function is being used in or where a module is being imported.
• ⭐ Return search bar in the top right corner of wikis.
• ⭐ Less intrusive ads. Ad spaces should not shift article content while readers are parsing through a page or impede the readability of article content.^{[1][2][3][4][5][6]}
  • Mobile experience is notoriously still bad in ad space taking up article content.
• Passwordless login.
• ⭐ Two-factor authentication (2FA). Introduced in February 23, 2023 as per https://community.fandom.com/wiki/User_blog:DToast/Arrived:_Two-Factor_Authentication_for_Fandom_Accounts
  • Time-based authentication
• Moving wiki off the Fandom platform.^{[7][8][9][10][11][12][13][14][15][16][17]}
• Better default audio/video player other than Kaltura player.
  • Embedded videos don't show up properly
  • Link to download audio does not take reader to the respective File page unless users are logged in (Fandom redirects access from File namespace for SEO, assuming because these pages don't have "relevant" content)
  • ⭐ Support .webp and .webm playback
• Flexible table of contents that works properly with tabbers (each tabber should have a table of contents only containing contents under said tabber instead of showing all content hidden by other tabbers).
• Some site customization settings for anonymous users such as changing interface language and setting default theme (light/dark)
• Article search filter in Category namespace, especially on Category:Pages with script errors
• More accessible button to switch to mobile view on desktop (like in right rail) instead of scrolling down to the bottom of articles + comment section
• A blog search filter in https://warframe.fandom.com/wiki/Blog:Recent_posts

Wiki Commenters[]

• Tree-like structure for commenting like Reddit. Technically this can already be done in talk pages but having a native commenting thread feature would be beneficial for conducting conversations flow instead of relying on the context and pinging people.
  • An alternative solution would be to expose talk pages to readers on the same article rather than having separate hidden link behind a dropdown menu.
• Bring back support for wikitext syntax in comment sections of articles. A long time ago we were able to add templates and wikitext links in comments.
• Enable article comment section for Project/WARFRAME Wiki namespace.
• Implementing https://www.mediawiki.org/wiki/Structured_Discussions to Talk pages to improve accessibility and engagement in Talk pages for more serious and elaborate discussions on an article topic.

Wiki Editors[]

• ⭐ Expanded RegEx support in find + replace modal when editing pages.
  • Find + match/highlight functionality too.
• LaTeX WYSIWYG editor in VisualEditor.
• Ability to customize Source Editors's and VisualEditor's toolbars for adding custom wiki templates like this wiki's tooltip templates. Discovered MediaWiki:Edittools + Extension:CharInsert which is already enabled on wiki. -Cephalon Scientia (talk) 06:31, 22 January 2024 (UTC)
  • This will speed up the learning curve for editors if they have immediate access to the wiki's most commonly used templates.
• Include text next to toolbar buttons for accessibility reasons.
• Ability to quick insert characters by HTML code for content within template arguments. Discovered MediaWiki:Edittools + Extension:CharInsert which is already enabled on wiki. -Cephalon Scientia (talk) 06:31, 22 January 2024 (UTC)
• Ability to switch between multiple accounts with a click of a button.
• ⭐ Ability to preview page in mobile view when editing in source editor.
• Ability to preview page with right-side rail element to see how content is rendered in anon view.
• Ability to preview page in various screen sizes and viewports for accessibility.
• ⭐ Support .webp for animated/moving images (as a substitute to .gif format for smaller file sizes, better for mobile users).
• Ability to embed graphs onto articles (similar to LaTeX with <math> tags) using DOT syntax, preprocessed by Graphviz.
• Ability to embed Desmos graphs for math visualizations through Desmos API.
  • Getting own Desmos API key for commercial use requires a paid license through a formal partnership, needing at least $1 million USD in annual revenue.
  • Alternative solution is to use GeoGebra Apps API. Commercial use requires a paid license, see https://stage.geogebra.org/license for more details.
• ⭐ More robust filters in Special:RecentChanges:
  • See what pages have been patrolled or not.
  • How many total bytes have been changed (e.g. large vs. small edits).
• Ability to embed BiliBili videos for Chinese audience using Extension:EmbedVideo.
• Ability to embed TikTok videos using Extension:EmbedVideo.
• Have a separate comment section for article update suggestions that editors can view and filter through. A new Special page can be used to aggregate article suggestions across the wiki in the form of a TODO list or comment feed.
• Finding unclosed HTML or parser function tags on articles (can probably use AutoWikiBrowser or other bot software for this though MediaWiki has a built-in Category:Pages using invalid self-closed HTML tags so it could be possible to have MediaWiki auto-detect these).
• Having a shared image/media repository amongst wikis in the same family (e.g. the other sister WARFRAME wikis). That way other wikis don't have to reupload the same content.
  • Closest feature is https://commons.fandom.com/wiki/Fandom_Commons_Wiki
• Thanking system similar to Wikipedia's so that editors know that their edits are appreciated. Implemented using Extension:Thanks as of August 2023.
• Public issue tracking system for content updates or fixes on articles.

Wiki Developers[]

• ⭐ Ability to import wiki modules from other Fandom wiki communities other than Fandom Developers wiki. This to standardize codebases amongst international wiki communities that rely on Lua modules to scale up content production and maintenance.
  • A huge reach would be to work with other MediaWiki wiki farms to allow importing of Lua modules across site domains. Essentially creating a package manager for MediaWiki-based wikis.
• ⭐ Better support when using wikis as a platform as a service since the ability to use Lua scripts to generate wikitext opens up the possibilities of applets. This also extends to Gadgets which are JS snippets in the MediaWiki namespace that serve as front-end applets.
  • Integrated testing suite for continuous integration and development. Module:TestHarness works (https://dev.fandom.com/wiki/Global_Lua_Modules/Testharness), but is limited in its capabilities.
  • Bug reporting platform for anons and non-wiki editors to submit tickets
  • I18n and L10n support. Preferably have a new user role to allow the community to contribute localization strings on MediaWiki namespace or outsource translation platform to translatewiki.net (https://www.mediawiki.org/wiki/Translatewiki.net)
  • Lua module versioning system for bundling code to discrete releases
    • Wiki versioning by extension
    • This will allow developers to review code before importing new versions of modules. Right now we are blindly accepting any changes to modules from the dev Fandom wiki which is not good for security.
  • Code review system for Lua modules (aka a pull request that requires a review by other developers with comments)
  • Ability to lint Lua code when editing modules as well as customizing how linting is done
  • A test wiki that is up-to-date with Lua modules and article content for testing purposes
  • git blame feature on specific lines of code so we don't have to keep asking in Discord who made a specific change
  • Interactive Staging to stage commits
• Support arrow and anonymous functions in JavaScript parser as well as syntax highlighting for latest stable version of JS.
• Ability to use a query language to query data in Lua databases. We can treat Lua tables in /data subpages as NoSQL databases so a robust method to filter, manipulate, and update these pages will improve code stability. Possible solution is to port data to a MongoDB database and have a MediaWiki extension interface with the MongoDB backend. Otherwise, we would have to create a database system and query language in native Scribunto Lua.
  • The closest we have to a "querying language" is DynamicPageList (https://help.fandom.com/wiki/Extension:DPL3/Manual), but that is invoked as a parser function on wiki articles instead of having an API/native library to call it in Lua modules. Have to use frame object within Lua modules which is not ideal for performance (frame:callParserFunction(), see https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual#frame:callParserFunction).
    • Limited to querying and filtering article content.
• Use a proper, established database system to store data in /data subpages in the Module namespace (e.g. MongoDB).
  • This would improve performance by allowing data caching.
  • This would also help with data integrity with the ability to enforce schemas and data types.
  • Data persistence is another feature for database versioning so readers can view old versions of data.
  • Data localization is another plus for translating content into other languages for the international community.
  • Enable proper querying of database content for data aggregation and analysis.
  • Alternatively, this could be implemented as a Wikidata-like wiki paired with SPARQL.
• Want a Data Management System of game objects and data that sits on top of database layer. Don't want editors direct access to database. Want proper version control since this data is Open Data where community can freely read and edit to iteratively improve on data.
• Better documentation on MediaWiki's Action API page https://warframe.fandom.com/api.php. Currently it is using the default API documentation with malaligned text.
• Better/updated documentation page on Fandom Discussions API instead of using a JSON endpoint https://warframe.fandom.com/wikia.php?controller=DiscussionPost&method=help&format=json
• ⭐ Publicly publish Fandom's custom MediaWiki extensions to the open source community with proper documentation and support
• ⭐ Accessible change logs on the Fandom platform. This can be done via a mailing list or a RSS/Atom feed. Change logs must also be on a platform that is easily searchable which means that certain keywords can return the appropriate results and we can filter logs by date. Hacking use of Fandom Discussion for this purpose is not sufficient for developers or user friendly: https://community.fandom.com/f?catId=3871017659269122999
• Ability to fund/tip community efforts and labor in wiki development and maintenence.
• A GitHub-like heatmap of contributing activity over the past X months (can also be generalized to include article edits, no need to be restricted to code commits). See https://warframe.huijiwiki.com/wiki/%E7%94%A8%E6%88%B7:Cephalon_Scientia for an example.
• Optional minimal wiki skin for performance and debugging. Basically strip wikis of all custom CSS and JS, no background image, and no Fandom elements. Just raw article text content with some images rendered.
• ⭐ Accessible NewPP report for viewing wikitext rendering stats. It is inconvenient to look into the HTML source and CTRL+F "NewPP" whenever developers have to debug wikitext.
• Ability to trace back/list all pages that invoke a parser function similar to how we can see all the articles a particular article is linked in through Special:WhatLinksHere. The current workaround to this is to wrap parser function invokes around a template and transclude that template onto articles.
• Ability to install custom MediaWiki extensions that are tailored to the wiki's needs. Many of WARFRAME Wiki's Lua modules can be ported to PHP to work closer with the wikitext parser. This would potentially improve performance and enable unique features such as having basic wikilinks automatically become tooltips without wrapping text around a tooltip template.
• ⭐ Ability to view Lua console output of the page itself without going into Source Editor, previewing the page, and then scrolling down to the bottom to view logs. This would help with debugging and seeing silent errors.
• Ability to query what pages a CSS class is being used on to track down changes to stylesheets.
• ⭐ Tool for dependency analysis and tracking Lua module usage. Best we have so far is Module:DependencyGraph.
• Scribunto/Lua library for generating LaTeX strings without wrapping LaTeX content around math tags (instead of return mw.getCurrentFrame():preprocess("<math>\frac{1}{2}</math>" do return Latex.frac(1, 2)). Is there a Scribunto/Lua hook for Extension:Math?
• Ability to program and debug wiki modules in an external client or IDE like VSCode instead of within the browser. This can partially be done through plugins that use MediaWiki's API to fetch articles but lack native debugging tools like profilers, stack traces, breakpoints, etc.
• As of 20:23, 23 May 2022 (UTC), MediaWiki is in the process of integrating Parsoid into its core library, replacing its current native wikitext parser. Will Fandom follow suit? This will enable conversion of HTML to wikitext as well as providing a possible lexer for wikitext to be used by Lua modules.
• Wiki query language as a Graph Query Language to find presence of keywords on articles, article link relationships, and article category relationships? Wikis represented as a high-level graph data model? Probably can be tied to wiki search engine.
• Ability to define custom hooks so that specific wiki actions can trigger other wiki actions. For example, if I update Module:Weapons/data/primary, changes to that data will be persisted to Module:Weapons/ppdata without the need of an intermediate manual edit.
  • Requires access to MediaWiki application code.

Wiki Admins and Moderators[]

• ⭐ Better/more accessible moderation tools in Fandom Discussions:
  • Ability to temporarily mute certain users
  • Admin activity logs
  • RSS feed or a webhook to alert admins of new reports or posts
  • Ability to moderate discussions on Fandom mobile app
  • Mod mail to privately send messages/reports to entire moderation team in hopes one of them can resolve issue
• ⭐ Improvements to Fandom Discussions:
  • Increase category limit (right now it is at 10)
  • Ability to direct quote replies instead of just pinging the replyer
  • Verbose direct URL link to discussion posts instead of being random numbers (at least include title name of post in URL)
  • Include timestamp when user edited their post/reply (different from initial post/reply)
• ⭐ Expanded analytics
  • On a per-page basis (like aggregate weekly views on a particular page)
  • Historical analytics
  • Browser viewport sizes of readers for improving UX and accessibility
• More customizable user groups and roles
  • Ability to designate long-term/trusted editors with the permission to patrol pages
  • Roles to edit specific pages and roles on a per-page basis
  • Timed, temporary roles that expire after X amount of time
• ⭐ Ability to lock specific comment chains in the comments section of articles
• ⭐ Ability to to define HTML and CSS styling outside of the MediaWiki namespace for better maintenance and modularity (only import/transclude the HTML/CSS as needed).
  • Similar to creating views in web frameworks and model-view-controller architecture
  • See https://warframe.huijiwiki.com/wiki/Html:RichTab and https://warframe.huijiwiki.com/wiki/Html:WarframeItemsGallery for an example
• Accessible page statistics on articles rather than hidden behind history (e.g. wikitext size, rendered HTML size, when latest edit done and by who). Can be expanded to include page analytics.
• ⭐ Use Vue.js (Vue 3) as a modern JS framework instead of OOUI for front-end applications built by developers on the wiki. Wikimedia Foundation is migrating over to using Vue.js within MediaWiki, currently in experimental stages (https://www.mediawiki.org/wiki/Vue.js). See https://doc.wikimedia.org/codex/main/ for the Codex Vue.js UI toolkit and component library for Wikimedia projects.
  • See https://phabricator.wikimedia.org/T241180 for the project proposal.
  • This may revitalize web-applets such as our armor calculator on the Armor article (MediaWiki:Calculator.js) and ability Maximization calculators (Module:Maximization and MediaWiki:Maximization.js)
• Custom CSS styling for mobile view.
• Community Kanban board.
• More customizable Special:Community page.
• Article/file naming convention enforcement.

Wiki Translators[]

• Unknown

Third-Party Developers[]

• Unknown

Game Developers[]

• Unknown

Wiki and Game Archivists[]

• ⭐ Ability to dump article content into ZIM format for less memory footprint when storing wiki content locally.
• ⭐ Ability to dump image and media content uploaded to the wiki in one large archive file instead of scraping through the site and downloading media individually.
• Ability to include article comments in dump for archival reasons.
• ⭐ Wikitext content on this wiki should be portable to non-Fandom wikis. Freely accessible content should not be vendor-locked.

MediaWiki's Desired Features Map[]

See https://www.mediawiki.org/wiki/Feature_map.

References[]