Help:Infoboxes/Benefits of Portable Infoboxes

Portable Infoboxes are created for handling the most common single element of wiki pages. There are many different ways to view information from Fandom. Right now the primary ones are on desktop/laptop computers, on tablets, and on smartphones. But there are more ways, and Fandom doesn't always look great on all of them. Ever tried to browse a Fandom community using the Steam browser? Or on your Nintendo Switch? Or even on an Apple Watch? These various presentation options, and others that may come along in the future, have very different needs.

The way infoboxes are created on desktop (mixing HTML and CSS with wikitext) may work for desktops, but they often fail in other user environments. Things can look broken or misplaced because the content can't be separated from the presentation. Portable Infoboxes help solve this issue by presenting the content in a format best optimized for the viewing platform (like the mobile skin). The same content can drive any new experience without re-writing it. Fandom is working to make your content thrive on an ever-increasing number of devices.

Infoboxes draw faster
Because Portable Infoboxes (PIs) were designed to be understood by MediaWiki as native MediaWiki components, the performance speed of painting them onto a page has an edge over comparable wikitext. Portable Infoboxes are faster to paint especially where wikitext templates are made with nested templates and/or Lua.



The process where wikitext becomes HTML (so that browsers can understand it) takes time. Native components like Portable Infoboxes can directly produce special kinds of HTML that can't be made consistently or safely in wikitext, and wikitext templates and tables take more processing time to expand into HTML. Most importantly, Fandom's platform understands where it can make changes in HTML to have the best experience on each platform.

For a point of comparison, let's look at the data for two roughly similar pages. Dead Cells Wiki uses Portable Infoboxes; Enter the Gungeon Wiki does not. Using Google's Page Speed Insights tool to compare the two pages (&quot;Rusty Sword&quot; and &quot;Rusty Sidearm&quot;), we can see some significant speed differences. Given that the two pages we're comparing are relatively the same in size and composition, there are two numbers that are significant in comparison - &quot;Time to Interactive&quot; (TTI) and &quot;Total Blocking Time&quot; (TBT). The way pages load for Google looks like this:



Google measures TTI as the time between when a page looks to be interactive, and when it actually becomes interactive. TBT measures load responsiveness, and is a severity metric for TTI. Comparing our two pages, we note the following:

Here, we can see that the TTI and TBT are almost double on Enter the Gungeon's page when compared to Dead Cells' page. This is largely because of the load efficiency of Portable Infoboxes. Portable Infoboxes are not the only reason that Dead Cells' page is faster, but it is a major contributing factor.

Similar tests for an apples-to-apples comparison show how two identical pages (except for the infobox technique used) on the same wiki can be much faster.

You can reproduce similar tests yourself with identical content pages using a number of tools (including PageSpeed Insights), but we stand behind the efficiency of Portable Infoboxes as a decisive factor as we evolve with the web.

Better building blocks make for better products
Portable Infoboxes create a consistent user experience across diverse communities, and allows Fandom to build products with a higher level of quality and integration. We can build products that anticipate PIs, which is not true of wikitables (which have more than one application and visual display). This allows us to rapidly develop and deploy content and skin improvements and features in a way that can't be achieved with wikitext elements.



As an example of a direct benefit: Portable Infoboxes are recognized as premium content on Fandom's mobile experience. Because we can consistently identify and create Portable Infoboxes, we can place them prominently above the advertisements. Alternately, because we cannot consistently identify wikitables, advertisements render above the content and lede, providing a worse end-user experience.

PIs also enable extensibility. When communities adopt the common PI format, it becomes possible for other programs to understand the information in better ways, and that's when cool stuff can start to happen. As an example, Portable Infoboxes enable more specific and relevant recommendations for what visitors can read next, which helps to keep them on your wiki (and on the Fandom network). For example, if a visitor was reading an article about the actor Idris Elba on the Marvel Database, they would see suggested reading about other Marvel movies Idris appeared in, or other stories that include the Heimdall character; there would be additional recommendations for articles on Dunderpedia (The Office Wiki), Luther Wiki, or Memory Alpha (all of which have articles about Idris and/or characters he played). A common data structure makes it much easier for recommendation systems to find &quot;things related to Idris Elba&quot; on Fandom, and provides a better user experience.

Search engine advantages
Search engines crawl the structure of Portable Infoboxes consistently and immediately, leading to vastly improved SEO comprehension and higher ranking generally results as a natural consequence. Structured data inside a PI is obvious and clearly labeled to Google — this is not true with wikitable-created infoboxes, as they have inconsistent vocabulary.



While Gamepedia's entry for Prapor may be the first entry on a search page, the content of the (wikitext) infobox is not as easy for Google to digest. This lack of confidence in results in less prominent appearance of data presented with the ranking, and may make it difficult for Google to present the data to the end user.



On the other hand, Fandom's entry for Max Caulfield leverages Portable Infoboxes, subpage structure, and standardized context-links (with Template Classification) to build a more complete picture for Google to present. The results are more prominent entry points for readers to discover, and the page appears in Google's Knowledge Graph.

On the whole, the more complete a picture Google has of a page, the more likely it is to rank highly. While it is difficult to track ranking changes at scale, especially when the pages are already ranked in the highest possible position, when Portable Infobox data is feeding the Knowledge Graph it is more likely to be opened and read. Fandom wikis have rarely experienced this prominent placement when Portable Infoboxes were not used. Simply: non-Portable Infobox pages result in Google saying &quot;we think this is important&quot;, whereas Portable Infoboxes generally lead to Google saying &quot;we know this is important, and here's the data we know you want&quot;.

Easy for new editors, powerful enough for masters
Simple infoboxes are built using a user-friendly GUI by default, rather than forcing users to learn code immediately. This allows for rapid development and template deployment, and lowers growth barriers for editors unaccustomed to making templates. There are rarely changes needed to the template embedding in articles to accommodate wikitext infoboxes that migrate to Portable Infoboxes. Portable Infoboxes can use TemplateData code to assist input as easily as can be done with wikitext templates. Using the Portable Infobox Builder is not required, as PI templates can also be built using &quot;source&quot;.

The simplified XML syntax of Portable Infoboxes is easier to understand than complex wikitables for most novice to moderate users, as wikitables tend to have a high learning curve and barrier to entry. Power users also tend to recognize the flexibility inherent in the syntax, as generally any infobox made with wikitables can be made with PIs just as (if not more) easily. Other elements, such as &quot;sidebars&quot; or &quot;vertical navboxes&quot;, can be made with the same syntax. The  child tag facilitates links between articles, making a portable method for replacing page tabs, Era Icons, and other ad-hoc navigational elements. The  feature provides a native and mobile-capable tabbed experience for data rows and groups inside infoboxes, eliminating the need for most workarounds.

Because the CSS selectors of Portable Infoboxes are standardized, CSS coding related to PIs is more recognizable. With well crafted CSS, any new templates are automatically styled as a community wants without replicating inline style coding or reproducing classes in multiple templates. The theme and type features allow tailored styling of full infoboxes and individual elements inside in a central and secure way, no matter what type of object the infobox is documenting.

tl;dr
Portable Infoboxes make for faster and more flexible infoboxes. They work better across all devices, and supercharge an article's SEO. They're easy to create, and easier to maintain than comparable wikitext.

-

Wikitable example:

{| class=&quot;infobox&quot; style=&quot;font-size:90%; width:23em&quot; ! colspan=&quot;2&quot; class=&quot;infoboxname&quot; |
 * colspan=&quot;2&quot; style=&quot;text-align:center;&quot;
 * colspan=&quot;2&quot; style=&quot;text-align:center;&quot;







! class=&quot;infoboxdescription&quot; colspan=&quot;2&quot; | Mod Tiers ! ← Previous !! Next → Comparable Portable Infobox:
 * style=&quot;text-align:center;&quot; | || style=&quot;text-align:center;&quot; |
 * }
 * }

  Mod Tiers