User:GuyPerfect/Updates
Leading up to the release of Splatoon 3, we have a fair number of updates to make to Inkipedia. Some of this involves the general presentation, and we'll also be introducing a new accessibility initiative. This page is a general overview of the tasks ahead of us, and will be updated as time goes on to reflect the changing state of the associated projects.
Presentation
The overall website layout and presentation of information is worth reviewing in order to identify areas that work well and areas that could use improvement. Maybe the site won't be fundamentally changed, or maybe it will undergo a drastic overhaul. All of the key components of the website design should be considered in order to build the best and most helpful user experience.
Skins and Globals
Inkipedia offers (at the time of this writing) the following MediaWiki skins: Vector, MinervaNeue, MonoBook, Timeless. Each of these supplies the website page generation with styles, scripts and images to display each page with a distinct look-and-feel. There are also global resources MediaWiki:Common.css and MediaWiki:Common.js that always apply regardless of the current skin in use.
Currently, Common.css is somewhat large and appears to be attempting to establish itself as the site's primary styling, superseding the styling provided by the skins. Much of what is in Common.css—in particular anything that specifies a color—should probably be adapted into the skin styles. The purpose of Common.css is to apply only those styles that should apply to all skins.
A full audit of Common.css and Common.js should be conducted in order to identify not just what should go into skin styles, but also to consider whether everything it's doing is genuinely beneficial.
Primary Views
Most websites have many content pages, but a relatively small number of distinct views. A "view" in this sense is a general page layout, which will be different depending on the type of content being presented. All top-level views should be identified, as that will greatly assist with reviewing the website overall.
Generally, the main views are pretty well listed in the top navigation menu of the main page. We'll want to go through each of them and consider what/whether updates or redesigns are appropriate. Each view will be a project unto itself, so when we get to that point, each will have its own project page to aid with collaboration.
Templates
Inkipedia makes extensive use of templates. For most of its history, templates have been constructed using Extension:ParserFunctions, which integrates with the wikitext and provides features such as template parameters and conditional rendering. Because it integrates with wikitext, complex templates become an unnavigable quagmire of curly braces, as whitespace is interpreted as part of the output and cannot be used to clarify the markup.
Nowadays, we also have access to Extension:Scribunto, which enables authoring templates with the Lua programming language. For complex templates, this gives us better tools for organizing and managing the internal mechanics. Whitespace is not considered part of the output, enhanced features such as loops are available, multiple partial templates can be consolidated into a single module, and performance is overall pretty good as it doesn't require extensive use of database queries.
Whether to use ParserFunctions or Scribunto for any given template will need to be considered on a case-by-case basis. That being said, we have many templates that could probably benefit from being re-implemented in Lua.
Mobile
Although the word "mobile" in the context of web design ostensibly refers to user agents on small handheld devices such as smart phones, from a practical standpoint it more accurately refers to smaller viewport dimensions (even when viewed on a desktop). While it's generally possible to identify the physical characteristics of the user agent programmatically, the line between desktop and mobile is becoming blurrier and attempting to make a distinction between the two is becoming less meaningful. That link down at the bottom that says "Mobile view" or "Desktop view" probably needs to go away.
The alternative to user agent detection is something called responsive web design. The principle is simple: as the dimensions of the viewport change, so to does the presentation of the content. This is primarily achieved through CSS media queries, and the JavaScript "resize" event is also available as needed. As the viewport gets smaller, font sizes can change, elements like the sidebar can move or disappear, and the layout in general can become more accommodating for the smaller browser size. This also benefits the user experience and website maintenance, as it's just one overarching presentation and viewing experience to worry about.
We should consider the merits of doing away with split skins for desktop and mobile and using just one responsive skin for both.
Accessibility
Some users have various visual, auditory, cognitive or other forms of disability that may interfere with their website experiences. These users will often be using assistive technologies such as screen reader software, and will often need to navigate websites using their keyboards. These users have all the same rights to use Inkipedia as anyone else, and accommodations should be made to help them experience the website in the best ways available. Awareness of accessibility needs is on the rise, and I want to see Inkipedia stand as a shining example of how a gaming wiki can do accessibility right.
If we're really into it, we can see about getting Inkipedia officially recognized as accessible through some review and/or certification organization. If nothing else, this is a big boon for SEO.
Technical Requirements
The W3C provides the Web Content Accessibility Guidelines (WCAG) to define what specific things websites can do in order to facilitate users with accessibility needs. This is the gold standard to which websites are held: it is considered in case law (during civil and criminal disputes) and is used as the basis for legislation (including the EU Web Accessibility Directive). Accompanying WCAG is Accessible Rich Internet Applications (ARIA), which provides additional accessibility mechanisms for custom user interfaces on web pages. When used in conjunction with one another, WCAG and ARIA greatly improve the website experience for users with assistive technologies.
WCAG defines three levels of conformance, in order from least strict to most strict, they are called A, AA and AAA. The EU directive requires conformance to all AA criteria, which is what Inkipedia should also target. (Note: while it's tempting to just do AAA for everything, it's not practical. AAA goes so far beyond what is already considered a reasonable level of accessibility that it's disruptive to most typical forms of presentation. You generally don't do AAA unless you specifically design a website to do AAA.)
Policies and Patrolling
In order to successfully implement and enforce the accessibility requirements, certain policies will need to be established on Inkipedia. These policies will dictate the ways in which new content needs to be added, and all existing content will need to be audited and updated for compliance.
The most challenging part of this new policy introduction regards the patrolling of edits. Patrollers will need to be educated on the accessibility requirements and ensure any patrolled edits are likewise conformant. This will probably take the form of some kind of internal certification or assessment process prior to being authorized to patrol. Consequently, all users will need to have their autopatrolled status reset until they demonstrate familiarity with the requirements. Going forward, granting of autopatrolled status probably shouldn't be automated.
It may seem like an unnecessarily aggressive approach to patrolling, but accessibility is no joke (especially if we hold a certification). This does raise the bar for editors, but accessibility is important enough that we need to stay on top of it. If a more convenient solution can be found, that'd be a great thing to discuss. For the time being, it's the best I could come up with.
Auditing
All existing Inkipedia content needs to be reviewed for conformance to WCAG and updated as necessary. All new content added to Inkipedia needs to be conformant.
The best way to accomplish these goals is to parameterize as much as possible. For example, most of the content on Gear pages follows a common layout, so that layout can be generated by templates. As long as the templates are known to be conformant, then so too will be the Gear pages that use them.
Beyond the use of templates, page structure and size/color contrast requirements need to be met. Most of this is handled automatically by MediaWiki, provided the skin styles and heading markup is used correctly.
