Hi everyone. I'm Tim Quievryn, the Director of Technical Support at Wikia. I'm personally reaching out to the Wookieepedia team to talk to you about the new infobox markup known as Portable Infoboxes and the tools we have to help with the transition. Before getting into that, I want to take a moment to share with you the "Why?" of this process.
Why are infoboxes changing to Portable Infoboxes?
Put simply, most current infobox templates across Wikia translate very poorly to mobile experiences, and indeed any device that doesn't use desktop-style displays. On desktops and laptops, they often look amazing. The problem is that traffic across Wikia, including on Wookieepedia, is trending towards mobile. There is an important graph from our Community Central forum post about infoboxes a couple weeks back, and I want to share it here as well, because it shows just how big the trend towards Mobile is:
[[File:Wikia mobile traffic growth.jpg|center]]
Mobile is the future. Not just for Wikia, but for the web as a whole. Take a look at the recent trends and future growth predictions for mobile traffic - it's staggering.
We partnered with the Wikia community to create this new Portable Infobox markup to make sure that your hard work can be displayed on mobile devices (as well as any future technologies) easily and without any new coding conventions. It’ll take some effort up front, to be sure, but we’re here to help, and the work you put in now will pay for itself tenfold in the future. I know how important mobile has become to the community here, particularly the Wookieepedia app, and this change will pay big dividends for your mobile audience.
Tools we’ve designed to ease the process
We’ve introduced two new features to help with the conversion. One is a tool for migrating the “old” infobox code to the new markup. It identifies templates on your wikia that look like infobox templates and places a box on the right rail of the template page. When you click the “Generate draft markup” button in this box, it opens a new tab containing a draft of your infobox using the new markup.
The second is a new feature on Special:Insights that will highlight which infoboxes on your wikia have not been migrated to the new infobox markup. It’s fairly intuitive - you can click on the infobox title link itself to see the old markup, or simply click the “Convert!” button on the right, which performs the same action as the “Generate draft markup” button.
Likely the most work that will need to be done on Wookieepedia is Monobook styling. This is not designed with Monobook in mind, but Monobook will work with these new infoboxes if you update your CSS with additions for the new infobox classes.
Star Wars Fanon is one community that has already adopted Portable Infoboxes. I know the infoboxes there match the ones you have here. Here’s a great example of the new infobox in action.
This is our help page for the new markup. If you would like, I can help get things rolling by converting a template or two as an example if you want as well as watching this forum post for any questions. --DaNASCAT (help forum | blog) 00:24, July 29, 2015 (UTC)
Discussion
After speaking with a few other people about this, the biggest concern we have is that this change isn't going to look good on desktop. The Anakin Skywalker example on the Fanon Wiki looks great on mobile, but it doesn't look very good on Monobook. The change is ballooning the text and increasing white space and the overall vertical size of the template. In Monobook especially, this is going to have the side effect of causing image placement problems as we're forced to work around increasing infobox sizes. It's certainly possible that some of our coding people could rig up some CSS changes to make the temple keep its current formatting for Monobook and Oasis, but I think the easier and more practical solution is just to hide infoboxes in the mobile skin. It's not like they serve any great critical need except for the name field, and hiding them would allow readers to go right from the main image straight into the article text. Our mobile pages would be much more presentable without them. Toprawa and Ralltiir (talk) 04:09, July 29, 2015 (UTC)
- I share T&R's concerns. The Portable Infoboxes are just, to put it bluntly, ugly. A good article should have all the information in the infobox present somewhere in the actual article, giving the reader all information available on the subject without having to read the infobox. We should strive for our articles to reach such a level that the infobox should be able to left out of mobile view. - AV-6R7 (talk) 04:19, July 29, 2015 (UTC)
- Let me start by specifically saying that it is not possible to simply remove infoboxes from mobile. That's just one of those technical "not built" things. From an opinion standpoint, I'm not sure that hiding infoboxes in mobile would be good or beneficial for any community. I just looked up the numbers to double check and, in the last month, it's been exactly an even 50-50 split of mobile and desktop views to Wookieepedia. So I would politely urge you to consider the fact that we are talking about the user experience of half your 3.25 million viewers last month. 1.6 million is not a minor number. Infoboxes are just as valuable to mobile users as to desktop users - a quick way to view critical information about a character/movie/comic/etc. In fact, I would argue on a site like Wookieepedia it's more important to mobile readers than desktop readers. Think of how long a page about one of the movies or main characters is. That is a lot of scrolling in mobile, especially if you don't know instinctively on the first visit where the information can be found in-article. CSS is pretty easy to manipulate to mimic the old looks and each portable infobox has a built in id for class styling. My suggestion is that we (I will definitely happily start a draft if requested) edit a relatively low-use template - Template:Era specifically - and then use CSS to show/test how close to the old look we can make these infoboxes. --DaNASCAT (help forum | blog) 04:46, July 29, 2015 (UTC)
- There have been concerns about the sizing and spacing with these new types of infoboxes; I've spent the last half hour or so coming up with CSS fixes to the point where the portable infobox is very very close to the existing ones, other than the footer with the Hide/Source buttons and the alternating gray coloring of the rows. (unfortunately, I closed the tab before I could nab a screenshot) However, I'm finding several other issues:
With templates such as Template:Era, there are a series of rows that need to be one row across, and includes standardized text—i.e. Year "input here" Before Blah. (fixed this) I'm not seeing a way to make them a single row at the moment.aaaand never mind, figured this out.- The Draft button's a little wonky, though that might be the way I've developed the infoboxes. The title and subsections aren't being recognized as what they are, and some fields, like width, are being included.
- Our infoboxes use a unique image loader that (for desktop skins only) maximizes the quality of the image, using Template:Imagewidth. Is there a way to implement or integrate this? Cade
Calrayn 20:16, July 29, 2015 (UTC)
- Yeah, unfortunately if the styling parameters are nested a certain way, the Draft creator just assumes they are actual template parameters. We'd just need remove them from the actual <data> field and then add them to the appropriate field using <format> tag. Re the image width, would you mind shooting me two-three examples of pages where the image width is drastically different? I see the logic train in that template (It's pretty neat if I may say so myself) --DaNASCAT (help forum | blog) 21:57, July 29, 2015 (UTC)
- It originated as a way of eliminating the |250px needed in infobox images, and the quality boost was an unexpected result of the adaptive resizing. Acklay Wilds was an example used during the development: instead of loading the image at a 250px width, it loads the image at a larger size (650px here, but the widths are staggered depending on the actual image's max width) and then shrinks that image to 250px. This is a comparison of three settings—top is the current resized, middle is the limited-to-250px, and bottom is the full-size image shrunk to 250px. It's subtle on most pages. Cade Calrayn 22:20, July 29, 2015 (UTC)
- Okay, that makes sense. I'll look into that and if there's not a great solution present it as a use case to the team that's building the features. We're pretty much upgrading the infoboxes when there's a viable need to. In the interim, I've looked at the draft - I don't see
widthorimageBGnbeing used in a random sample (I looked at about 12 pages) of that template. Is it being used? I'd like to see how if so. If not, I might just assume it's parameters from another template that just never needed to be used in Template:Era. --DaNASCAT (help forum | blog) 00:18, July 31, 2015 (UTC)
- Okay, that makes sense. I'll look into that and if there's not a great solution present it as a use case to the team that's building the features. We're pretty much upgrading the infoboxes when there's a viable need to. In the interim, I've looked at the draft - I don't see
- It originated as a way of eliminating the |250px needed in infobox images, and the quality boost was an unexpected result of the adaptive resizing. Acklay Wilds was an example used during the development: instead of loading the image at a 250px width, it loads the image at a larger size (650px here, but the widths are staggered depending on the actual image's max width) and then shrinks that image to 250px. This is a comparison of three settings—top is the current resized, middle is the limited-to-250px, and bottom is the full-size image shrunk to 250px. It's subtle on most pages. Cade
- Yeah, unfortunately if the styling parameters are nested a certain way, the Draft creator just assumes they are actual template parameters. We'd just need remove them from the actual <data> field and then add them to the appropriate field using <format> tag. Re the image width, would you mind shooting me two-three examples of pages where the image width is drastically different? I see the logic train in that template (It's pretty neat if I may say so myself) --DaNASCAT (help forum | blog) 21:57, July 29, 2015 (UTC)
(reset indent) We use imageBG to customize the background of the image field for a number of reasons, but it's hard to find an example article with the {{Era}} template. The {{Company}} template provides a better example of imageBG usage, though. AccuTronics, Arakyd Industries, Atgar SpaceDefense Corporation, and on and on and on - we set them to white to match the background they were shown on in the source material when the infobox would otherwise be black. Most of our fictional company logo SVG images need that. -- Darth Culator (Talk) 03:32, August 2, 2015 (UTC)
- Sorry, missed the responses here. Per Culator about the imageBG parameter. As for the width field, as far as I know it's primarily used in our event infoboxes—specifically where there's three or more sides that necessitates a wider infobox. It's been a bit since I reworked our infoboxes and used RoboCade to rejigger the parameters on articles sitewide, but I'm pretty sure that any uses of |width outside of those battle cases are rare. Cade Calrayn 19:16, August 9, 2015 (UTC)
(reset indent)Regarding the lack of user customizability through |imageBG or other parameters, I used JS over on SWFanon to re-implement that functionality. Using vanilla JS means the styling is practically instantaneous. here, while the corresponding script is in Common.js.TK-999 (talk) 10:14, August 11, 2015 (UTC)