User blog:TimmyQuivy/FandomDesktop: A New Experience Has A New Customization Policy

As we continue transition our platform’s communities onto our new Unified Community Experience (UCX), you are now getting the chance to design and test how your community will look.

For many of you, beyond the basic theme and color pattern of the wiki, there will be other things to test and redesign. Tweaking your wiki’s appearance often goes well beyond the defaults and into the realms of deeper customization.

As we will explain, with the rollout of the UCX, we are today also rolling out an updated Customization Policy - the rules for how and what you can customize in your community. Based on your feedback from the previous version of the Customization Policy, there are a few areas we believe we are able to offer a more open approach. However, there are still some hard and fast, black and white rules that we must lay out. Read on to learn more.

Striking a Balance
Customization and community identity have always been core to the Fandom experience. That’s why Fandom has developed the UCX with further user customizations in mind. While we tested, explored, and iterated upon the “default” look, we also examined heavily-customized communities and tried to understand how additional layers of user-created customizations would affect the final look.

Yet, while customization is important, there must be logical limits in place of what can and can not occur. As people move from one community to another, evolving from reader to editors to founders, it's important that they are able to take what they learn from one wiki and build on that. A key part of this learning experience is having the user interface and features be consistent - visitors should be able to rely on the interface and features being in expected places as they move around Fandom.

The Customization Policy below exists to maintain this critical balance - customization and creative expression on one side and consistency and usability on the other. In particular, this new version of the customization policy will focus most strongly on the usability of a community. While we are allowing more parts of the design to be modified than in previous versions of this policy, we are going to be more aggressive about ensuring readers with varying levels of technological and physical abilities will be able to use your community.

General Guidelines
Simply because you “can” do something doesn’t mean you “should”. While there are some specific things we allow and don’t allow listed further down the page, it’s always a good idea to consider a few things before moving forward with a customization.


 * 1) Theme Designer - We’ve built a lot of customization options into our Theme Designer tool. It’s designed to allow you to quickly and easily make changes to your design without having to mess with complicated CSS/JS code. It’s best to use a tool purpose-made for site design rather than having to configure the code manually, which could have unexpected consequences.
 * 2) Discuss changes with your community. - It’s always important to ensure your community is on board with a site design change. What looks good to you may look bad to others. It’s also important to consider if the proposed change solves a problem or limitation with your current design. If it doesn’t, is the change actually necessary?
 * 3) Consider usability. Critically, remember there are individuals that use your site that may have physical limitations that could make a customization detrimental to their reading or editing experience. Avoid a reliance on color coding to be inclusive of colorblind individuals. Make sure any custom fonts or font-sizes can be read by those with poor eyesight - test on a screen reader when possible. And opacity can be taxing on even those who have normal vision.
 * 4) Consider screen sizes. Remember that the UCX desktop design has a fluid width, so how a customization appears on your screen may look different on others. This is especially true if you have a larger-than-average monitor. Hardcoding a CSS change to space things out a certain way on your screen may unexpectedly compress or distort the viewing experience for other users.
 * 5) Consider performance. It’s also important to consider the CSS & JS files take up computational and rendering time, especially if you are loading up an image. Poor speeds can hurt your SEO. It can also affect users with lower-bandwidth connections. If you must load images using CSS or JS, make sure they are as small and compressed as possible.

What Is & Is Not Permitted
It is important to note that all the following policies apply to site-level JavaScript & CSS (i.e. code stored on your wiki’s MediaWiki namespace). You may continue to use your personal JavaScript/CSS however you would like as long as it does not affect any other user. Also please note that, as noted in a previous section, if a customization makes a part of the community unusable, regardless of what “area” that customization affects, we will ask you to modify or remove it.

Noteworthy changes from the previous customization policy are italicized.

Article Content Space - Communities may customize the content area of their community (that is to say the area of the page where user-submitted content is displayed) as desired.

Basic Interface Elements & Advertisements - The user interface and advertisements are the basic, expected functions of the site, and must remain in place. For example, a visitor should always see the “Edit” button or the "Recent Changes" button in the same place, and it should work as they expect. Additionally, custom cursors are not permitted. Some features are optional, but these should be managed via the settings or with staff help, rather than being removed via CSS. This helps us to track the features and get accurate data on how they are being used across Fandom.

Site Background - The complete background of the page may be modified using CSS to override or complement the “page header”-type image. Other changes to the background may not force the site to be rendered in a certain width or otherwise modify the fluidity of the layout.

Global Navigation - We consider this a core element of the site due to both its value to cross-wiki discovery and as the entry point to the user’s personalized experience. As such, the left hand global navigation bar may not be altered, repositioned, obscured, or otherwise affected in any way.

Site Navigation - Additional top-level menus may not be added to the local navigation beyond the functionality allowed through the navigation tool. Additional items on all other child menus may be appended as necessary.

Article Page Header - The page header may be modified through the use of properly-licensed fonts. However, Fandom staff will be particularly proactive in addressing any issues that negatively impact the usability of this part of the page and will ask you to change it if we deem it unusable.

Right Rail - Additional elements and modules are allowed to be placed in the right rail, below the default elements. However, they may not push down the placement of the advertisement module in that space.