Hey gang!
As promised in the introduction to FandomDesktop back in March, we’re continuing our “More Is More” approach to previewing the changes coming to Fandom and Gamepedia for desktop users later this Spring and into the Summer. More transparency, more design thinking, and more in-depth looks at what is changing before the rollout.
Today, we are looking at how Theme Designer is leveling up with FandomDesktop with new features, better performance solutions, and more customization options to bring your community’s identity to life.
New Look, New Features[]
As part of the UCX project, we’ve rebuilt Theme Designer from the ground up as a stronger feature to enhance the new experience. In other areas of the UCX, we’re focused more on optimizing existing features for the new experience, but with Theme Designer we heard the user need from you and saw the opportunity to level up.
To the left, to the left
Since the current Theme Designer was launched desktop users have trended toward wider screens as graphics technology has improved dramatically and the display technology has kept up. To that end, we revamped Theme Designer to a left-mounted experience, rather than top-mounted one. This allows for more of your page to be shown at a glance when doing design tasks, making those design tasks easier to complete.
Real changes on real pages
The new Theme Designer preview experience is a live one. You are able to select a live page from the wiki to serve as the preview example. Your content, not placeholder content, gets the live adjustments as you play with the theme.
This will allow you to see how particular pages and their specific formatting reacts to the changes you’re testing out in a preview setting, rather than having to apply the changes, leave Theme Designer, check the page in question, and then go back if it’s not how you wanted it. If you want to see another page, you can change the page target in the preview pane’s URL bar and it will update.
Remember interaction cost from the navigation preview, the sum of mental and physical effort required to reach a desired outcome? This SIGNIFICANTLY reduces interaction cost for Theme Designer work by giving you more insight as to which changes affect the elements directly.
Oh… and your favicon changes can now be previewed live in the URL bar of the preview window!
Day and Night
As you undoubtedly noticed in the earlier previews of FandomDesktop, we will be supporting Light and Dark theming natively with the new experience, including support for both themes in Theme Designer!
You will be able to easily toggle between the two themes in the Theme Designer interface to work on each one and see how they compare, all within the same preview window. You will also have the option to set which theme is the community default, presenting readers the experience which you as wiki admins deem the best option for your wiki.
A quick note about how Light and Dark theming will work in terms of user choice:
- At the opt-in launch, Light and Dark theming will be limited to logged-in users only through a user preference
- If a user preference has not been made, the admin-selected theme will appear as the default experience on a particular wiki.
- The on-wiki toggle shown in many of the design mockups is currently slated to be released before the first batch of wikis is converted over to FandomDesktop for their overall experience.
- The toggle will be available to both logged-in users and logged-out users (anons)
- For logged-in users, the toggle will save your choice as a change to your global preference for Light vs Dark theme
- For anon users, the toggle will save your preference for the session. When entering a new session, anon users will be considered to have no preference and be shown the admin-selected default theme on any given wiki.
We needed a little more time to develop the logic for preferencing and toggling and, in the spirit of more transparency, we wanted you all to know ahead of time about this slight change from what has been shown.
Custom Font Choices
Built into the Theme Designer experience will be the option to pick custom fonts for your header text. We will be starting with 5 additional fonts vetted by the Product Design team for usability and accessibility. These fonts are Rubik, Work Sans, Lora, Roboto Slab, BioRhyme, and Inknut Antiqua, which are shown in the above screenshot. Other custom fonts can still be used via CSS, as long as they maintain accessibility standards.
Significant Improvements[]
In addition to changing how the feature works from a fundamental perspective, we also took the opportunity to make some improvements based on user feedback and learned experiences from the Unified Community Platform migrations.
Better Storage Solutions
The legacy theme designer stores certain files, like the wiki logo, in a location outside of MediaWiki. This caused issues during UCP migrations because those images sometimes did not migrate correctly and were difficult to retrieve afterwards.
Going forward, ALL file storage related to Theme Designer will rely upon MediaWiki’s file management, giving wiki admins the option to control their images and revisions through MediaWiki tools, rather than just the limited proprietary management of the previous Theme Designer experience. This will future proof against issues arising from any file management changes we might need to make, as Theme Designer will be treated the same as the rest of the wiki, rather than having another system to migrate.
More colors and better ways to pick ‘em!
In the legacy Theme Designer, you have two ways to go about picking colors: swatches or hex codes. It’s great for design-savvy admins who know hex codes off the tops of their heads or happen to pick one of the colors in our swatch selections. Not great for creativity beyond that.
In the new Theme Designer, we are starting out with a color picker that gives you a LOT of choice in the entire visible range of light… or you can still punch in a hex code if you want.
We’re already looking toward the future on this feature with a desire to go even further beyond those options, including more support for accessibility. More to come from the CATS team on this after the initial rollout of FandomDesktop!
Bigger is Better
As I mentioned earlier, screen resolution has been climbing with advances in graphics technology side-by-side with display technology. We’re heading towards 8K displays in mainstream usage, so we need to evolve with your technology choices.
Thanks to this trend and specific asks from the creator community, the background file size limit will rise from 300 kb to 1 MB.
Logos a-go-go!
One of the big differences between Gamepedia and Fandom in terms of design is how community identity is presented in the form of a wiki logo. Gamepedia wikis use a square avatar, while Fandom wikis use a rectangular wordmark.
With the new FandomDesktop experience, we’ll be supporting both styles in a new unified format just called Logo. The upload resolution will be up to 500x500 pixels, allowing for both formats to fit and enjoy the benefits of higher resolution screens. On desktop, avatar-style logos will display at 100x100 (80x80 on tablet). Wordmark-style logos will continue to display at 250x65.
We’re encouraging wikis to opt for an avatar-style logo. The square avatar-style logo is easier to use in promoting wiki identity in more places than the rectangular wordmark-style logo. When you scroll down an article page, the square logo can roll up into the pinned local navigation, keeping that wiki identity right at the top of your screen. A rectangular logo would cut into your usable navigation space too much. The logo being in the pinned navigation on scroll is optional. We also have some other future features in development which will make use of this more portable element of your wiki’s identity. More on those when they’re ready for public eyes.
The Themes Must Flow[]
You’ve probably read all of this and are wondering: “Okay, but how will this work in the transition?” The CATS team kicked around a number of ideas on this specific concern. How do we make the transition to a new design and a new Theme Designer as pain-free as possible? What they came up with is pretty great with separate flows for getting Fandom and Gamepedia wikis to the same place, functionally.
For Fandom Wikis, the Choice is Yours
When you get onto FandomDesktop as an admin, entering Theme Designer will present you with a choice. You can either import your existing theme or you can start fresh. If you choose to start fresh, we’ll give you a clean slate and let you explore the new Theme Designer experience without any previous theming decisions being part of your initial FandomDesktop design
Note: You will NOT lose your existing theme if you do this. At any time during the opt-in period, you can decide that you actually do want to import the existing theme, you can get it back from the theme history section, and Theme Designer will translate your legacy Oasis theme into a new FandomDesktop theme. For wikis without active admins during the opt-in period, auto-import logic will convert legacy Oasis themes to FandomDesktop themes when the wiki is transitioned fully over to the new experience.
For an existing theme import, the Theme Designer will employ some color logic to look at your Oasis theme during the import process and make a determination as to whether the theme is Light or Dark and save it accordingly. At the same time, it will do its best to make you an appropriate opposite theme for the other option. For example, if Wookieepedia imports their theme, Theme Designer will assign it as Light and then assign a standard theme for the Dark mode. I, for one, am really looking forward to seeing the different Light and Dark Side of the Force themes from the various Star Wars wikis on the platform.
The Gamepedia Import Flow
Gamepedia has never had Theme Designer, as all Gamepedia wiki layouts were done by Wiki Representatives or admins through CSS as part of the curated wiki creation process. When a historically Gamepedia wiki is on FandomDesktop, the initial theme will be the favicon, logo, and a Light or Dark default theme determined by whether the legacy theme is using Hydra or HydraDark. Everything else will be fresh. Given the blank slate approach, the Community Experience and Community Development teams will be providing special support for theming to historically Gamepedia wikis. We will have more to come on that as we get closer to launch.
We have more to come on customization, with detailed information for you CSS-savvy folks on how files, values, selectors, variables, and such are changing with FandomDesktop. Look for that closer to opt-in launch, for which I’ll be announcing a date soon!
And now, as ever, I will take your questions and answer them to the best of my ability!
Click here to follow the Fandom staff blog.
Click here to sign up for the From the Desk of Community email newsletter.
Join our Official Discord server for registered editors!