Forum:Portable Infoboxes (2017)

Forums: Index → War Room → Portable Infoboxes (2017)

Hello! I'm Isaac, and I'm representing FANDOM's Community Technical team. We help communities adopt to new technologies and features, like content portability. Call of Duty Wiki is a high priority for introducing Portable Infobox templates, which have a lot of benefits for your community. We've talked about this before back in April 2016, and I wanted to address some of the issues raised previously (and new ones you might have).

Call of Duty Wiki experiences millions of pageviews per week, with 75% of those visits from mobile devices. Portable Infoboxes help your articles to be accessed from any device and the flow of your traffic is as important as it ever was. I'd like to reproduce as much as possible the look and feel of your desktop infoboxes in global CSS, and will update the Infobox templates themselves (initially as Drafts for you to approve or ask for changes to) so that they can be accessible on any current and future platform. Maintaining them if you want to make changes should be very simple, and we have extensive documentation on how to modify Portable Infoboxes in the help pages or on the Portability Hub.

Regarding some of your concerns when we did this before: the Templates themselves would stay in the Template: namespace, protected or not as your community sees fit. The styling, which is the inline CSS code, would be in the MediaWiki: namespace, just like Common.css and Wikia.css. Since nearly all of your styling is consistent throughout multiple infoboxes, these style patterns (we usually call them "themes", but that's just a way of saying "consisently applied style") could be altered in a single place rather than in each template (which saves you work in the long run if you decide to change things up). In terms of access, this also protects you from vandalism a bit. But mostly, it makes it easy to just say <infobox theme="MW2"> instead of lines and lines of inline styling for each parameter. And, to be fair, your community has not changed the basic look of your infoboxes via inline styling in the last 2 years, so this trade-off to a more centralized and secure stlying system is not depriving you of something you use often. As for the templates themselves, they still can be edited by typical (non-admin) users just as they are now; in fact, using the standard syntax that we've committed to, typical users have plenty of resources to learn how to code infoboxes in a way that we've seen is less intimidating than with wikitext. Our credo on the Portability team is "future-proof", so users should be able to use the same syntax now as they will for years to come.

Improved mobile clarity is not the only reason why we'd like to introduce these; we're looking at all kinds of emerging devices. The Mercury skin and engine let us target all these devices, and the experience is centered around PIs as the focal point. The PIs also improve desktop performance, as the language is built for the server to produce them lightning fast. On mobile, the experience of infoboxes (when they aren't interpreted and stripped of other styling, as with non-portable code) goes from "looks fine" to "looks good". Mercury is another example of FANDOM tech that's going to be around for a while. It's constantly evolving, but the best benefits of new Mercury features will go to communities with portable code. Before you ask, customization of the Mercury skin is not something we're offering at this time, but if and when we do it will be first available for portable communities.

Original

Portable

Original

Portable

If I can successfully and faithfully reproduce the look and feel of your current infoboxes with high fidelity and present additional proofs of concept for you to see that there's no loss of form or function, would you consider approving them? I can do the coding and styling work myself, and save you from spending your valuable time. We would appreciate your go-ahead, but it is an incremental process and there are multiple stages where you can ask questions or for changes. Please let me know. Thanks! — FishTank (wall) 06:35, December 7, 2017 (UTC)

Discussion

Use another wiki as your testbed. We're sick of having changes forced upon us, most of which are regressive and silly. YELLOWLUCARIO ^TALK  08:46, December 7, 2017 (UTC)

This is not a testbed situation. Portable Infoboxes are already stable and mature, in terms of technology. Yours is near the top of the list of those that would benefit. I'm also asking, not forcing. — FishTank (wall) 11:38, December 7, 2017 (UTC)

Now now YL, no need to be aggressive and dismissive right off the bat. They are asking our permission and the changes seem pretty reasonable this time around. Conqueror of all Zombies (talk) 17:08, December 7, 2017 (UTC)

We really appreciate that Wikia Fandom is actually asking us about a new feature rather than just springing it on us. From just glancing over it, the changes seem pretty reasonable and certainly look like an improvement. I can't really come to much of a conclusion about this feature as I don't really have the time to read through everything right now, but I'm interested to more responses to this. Conqueror of all Zombies (talk) 17:08, December 7, 2017 (UTC)

Whether or not Crazy Sam decides to repeat his concerns from last time, it seems the same point was again missed completely. His point was this "the concern doesn't lie in not having access to editing templates by COD's technical team. many technical members who update and maintain templates are not admins so no access to mediawiki namespace, thus would not in this case have immediate access to update the css changes, admins do not always have the time to update tweaks or do continuous troubleshooting as they are busy. Portable Infoboxes removes inline css as FishTank said, making the technical team's job here much harder." Whether or not infobox css was changed in the past 2 years isn't the point, when they do need too do so, it will impact.

Fandom staff still refuses to create a technical group, spliting access to mediawiki namespace outside of the sysop/admin group for unknown reasons/ratioale. By creating such a group, you would actually resolve not just this concern but allow wikis through the network to get the requested help without providing delete/block/protect rights. protecting the templates also prevents vandalism so moving inline css to mediawiki namespace doesn't really do, much in terms of security from vandalism.

Just to clarify, does this mean you, FishTank, will be doing proofs of concept for the majority or all of COD wiki's infoboxes? its very apparent that at other communities with similar claims didn't work out as intended; templates left in a broken state or only did migration for a select few. Tip for showing proofs of concept, create & link to them at a test wiki rather than adding the here unlike last time which did cause tensions with one Bureaucrat. Nerfmaster8 (talk) 03:49, December 8, 2017 (UTC)

Inline CSS is nearly always discouraged. From experience, managing styling from separate CSS files has benefits in code clarity and reuse. A technical user group is rarely required - theme changes to this wiki's infoboxes are scarce. noreplyz 11:34, December 8, 2017 (UTC)

I did, in fact, address that point you mention. FANDOM staff do not intend to create a technical group in the sense that you describe; given that the core and most secure MediaWiki functions are manipulated in the MediaWiki namespace (messages and JavaScript), we expect the weight of responsibility that comes with being an administrator (or a trusted global group, such as Staff, IVT, or Vanguard) to coincide with such access. We would advise that a community that does not trust an unprivileged user to be promoted to administrator should also not trust such a user to be responsible for site-wide functions (such as JavaScript, CSS, the Admin panel, ThemeDesigner, etc.). That's why the layer of responsibility is there in the first place. Further, communities that would have such a role would pick what the members could and could not do, as policy on such is not at all universal; to delineate on a community level what responsibilities a "technical moderator" would have would not be sustainable for FANDOM, and we are not likely to explore that granular level of detail. Simply put: the most effective solution is to let the admins act for their community, even if that takes however long to respond to user requests for implementation. CSS and JavaScript are not emergencies, and if they become so, that's a FANDOM Staff matter.

Yes, I personally will code all of the remaining infoboxes. I have not made Drafts for all of them prior to this thread, as I felt such action (including making additions to your site CSS) would be considered invasive without the community's permission to do so. We know that you appreciate forenotice and don't like surprises. We have found, after a year of Vanguard and FANDOM Staff making such proposals, that linking to a test wiki is ineffective and actually detrimental to the overall proposal (for various reasons beyond the scope of the presented discussion). If you'd like to see the CSS and templates (Soldier, Weapon), they're available for your review and critique and are not binding. I've examined the rest, and with your community's go-ahead can complete the remainder of the Drafts in a day or so.

Finally: thank you, Nerfmaster8, for your civil discussion on the matter. You're not an active member of this community, but I sincerely appreciate that you've brought potential issues to light that others may not have considered. — FishTank (wall) 17:38, December 8, 2017 (UTC)

honest legitimate question: since you mentioned regarding ineffectiveness of test wikis, how many times has staff or vanguard legitimately showcased created proofs of concept at a test wiki fully working (ask JoePlay for example reference)?

as you said "previous concerns should be resolved prior to any changes directly applied here" should take precedence so the active community isn't infuriated since KAT did revert and threaten to block TTF last time and its good you are not going to add the css directly this time.

perhaps reaching out to CoD admins wouldn't hurt in this case even if they are busy or have lost interest. seeing as CoD wiki runs off consensus and such decisions require at minimum community approval, its in your best interest to actually wait until consensus is formed this time. considering some users are preparing for university finals; it would also be a good show of faith to try and wait another 2 weeks

rather than just going ahead due to "lack of response" as usual protocol.

well I shall be watching to ensure this time your promise is kept and fully deliver on it. this is merely me commenting, it has no weight in consensus as that would be inappropriate. Nerfmaster8 (talk) 04:20, December 9, 2017 (UTC)

What other staff members do is their prerogative, and I wouldn't presume to speak for them. Vanguard members are asked (as a matter of policy we've established) not to use test wikis for demonstrations. Neither of those matters is consequential to the thread at hand, and as I said they are beyond the scope of this discussion. (If you'd like to know why, I'll talk about that on my Wall, but not here.)

It's fair to say (as two admins, active in the community, have touched the thread) that the admins are aware of the thread. Thank you for your insight into how this community works as well; I've done quite a few proposals to different communities and have a very reasonable timetable in mind, which should give all university students — Surprise! I'm one, too! — time to finish finals and beyond. Let's not start off with antagonism. I'm here in good faith. Your concerns are noted, and I'd really like to hear more responses from active members of the community. — FishTank (wall) 05:24, December 9, 2017 (UTC)

I greatly dislike the theme being on a .css page. It makes editing them much more of a hassle. I understand going over multiple pages sounds much harder. But it makes it much easier to navigate and anyone can do it. Furthermore, there may be instances where some templates use different designs to others. Some time back our entire wiki deisgn was interlaced with .css and .js pages, and when we went to change it, it was incredibly difficult because none of us had experience with .css and .js, so we ended up removing all the code simply because we had no idea how to edit it. I don't want the same thing to happen to templates. Also, it's close to Christmas and I work in retail, so I've only just become aware of this thread as of now.

Crazy sam10 • Talk

12:15, December 10, 2017 (UTC)

The themes being on a single central, protected CSS page is not something we can work around. The goal is to make things simple for editors, which is why we developed PIs with the simple syntax in the first place; the whole wiki being interlaced with CSS and JS is something we'd ultimately like to avoid, and centralizing the CSS into a single page combats that (we usually, by convention, put PI CSS into the MediaWiki:Themes.css page). So, having typical user access to site-wide CSS is risky. However, we might be able to work out a compromise in a different area. Nerfmaster8 suggested a new technical group to modify MediaWiki messages, which we're not likely to do with our current policies. But we CAN modify the Content Moderator group rights to include editing MediaWiki: pages, which would allow that group to modify the central CSS. If you would be willing to commit to using PIs, that's something we would do to help you maintain them. Would that be an acceptable compromise? — FishTank (wall) 17:55, December 11, 2017 (UTC)

What I don't understand is how it makes it "simple" for editors by removing the ability to edit it away from users. It may come a point where we need to edit a .css page and none of our admins know how, even if a user knows how to do it a workaround for us wouldn't be to simply give that user admin rights so they can edit a single page. It seems a lot of the new features being introduced seems to be enhancing mobile usage but limiting editing potential.

Crazy sam10 • Talk

19:49, December 12, 2017 (UTC)

That's actually not so difficult to explain. The PIs use significantly less (and clearer) template code than those that use inline styles, so editing the templates themselves is easier to understand. The CSS itself is not significantly different between inline and centralized, because it's the same language; you gain the ability to make broader reaching changes rather than going through and tweaking multiple individual templates. That's what we mean by simpler. So, there's not a skill difference between those that can edit inline CSS and those that can edit central CSS.

You have about 26 infobox templates on your community that are used in article / content space. Most of them (that is to say, 5 for default, 16 for bordered, and two that incorporate orange into the bordered theme) are identical and consistent in their CSS; we'd call those "themed". Further, only 2 of your infobox templates don't use one of these patterns. Once those themes are established (and as mentioned before, you haven't actually changed this significantly or at all in a few years), they don't need to be remade. The CSS is centralized in one file and doesn't need to be reproduced or recoded for new PI templates. The template creator would add theme="bordered" to the <infobox>, and it's all taken care of; no mess, no fuss.

Finally, it should be pointed out that PIs are not a "new" feature anymore; they've been around a few years now. They're in place on more than 40% of FANDOM, and that percentage continues to grow. We consider them standard, and we want to facilitate getting you on-board with the standard with as much ease as possible to you. The features they bring in terms of ease of use in editing more than offset any loss in editing potential. — FishTank (wall) 23:34, December 12, 2017 (UTC)

I don't really see any downsides to the PIs. Considering the CSS pages will almost never need to be touched, I can't say I agree with Sam that users other than admins should be able to edit them. Joe 04:17, December 13, 2017 (UTC)

---

One week in, and we have some responses. With the four admins (and two concerned readers) that have weighed in so far, I'd like to summarize.

• Yellowlucario would like us to not hastily force untested changes; I'm addressing that by involving you in the process far in advance of possible implementation.
• Conqueror of all Zombies thinks the proposed changes are reasonable and an improvement, but wants to hear more comment. I think we're starting to have enough comment to move forward in a baby step by making some more drafts.
• Nerfmaster is concerned that non-admins will not be able to adjust site-wide CSS. This can be mitigated — to an extent — by granting those rights to an existing regulated group; we're willing to make that change if it will facilitate PI adoption here. He is also concerned about an incomplete transition, which I can ensure with a go-ahead.
•  Noreplyz suggests that inline CSS should be centralized.
• Crazy Sam is concerned about style and script fragmentation and the skill required to edit them being restricted to privileged users. We believe this to be a security concern, but can assist if it becomes a significant issue (recently it has not been). Further, the actual edit-potential of the templates by the general public improves with the streamlined syntax.
• Joe Copp sees merit in the security of centralizing the CSS, and that there's no downside in transition.

With those comments in mind, I'd like to move forward. I would start by adding the PI CSS as an import to your site-wide CSS, which will allow you to more clearly see the potential styling of the PIs live, rather than via screenshots; as you do not have any live PIs at present, the only things that would be impacted by such an addition are the PI Drafts and nothing that exists on live articles. You could also have the opportunity to evaluate whether centralized CSS will be within your skill level to modify. With that in place, I would start work on the remaining Drafts for your review. I can post a local sandbox with comparisons so that you can judge on a template-by-template basis if they are acceptable. When you can see those side-by-side, you'll be in a good position to approve the templates for public use or not. I can wait for your consensus decision on whether or not to move forward with making Drafts (not approving the Drafts yet) until Thursday, 2017-12-21. Is this something I can do? Thanks! — FishTank (wall) 19:33, December 14, 2017 (UTC)

This is something I want to bring up. If this streamlines are templates theme, I think this manes we should push towards a neutral wiki theme. Because I do not want to edit the .css every year just because CoD is using a new shade of blue.

Crazy sam10 • Talk

19:39, December 14, 2017 (UTC)

That's up to y'all. My initial idea is matching closely what you have now. If you want to make changes beyond that, let me know and I'll alter the code to be more neutral. — FishTank (wall) 19:44, December 14, 2017 (UTC)

I've got a couple of questions to make sure I fully understand:

1. Is the ultimate goal of using PIs to improve how infoboxes work on mobile devices? I can say from personal experience that they were broken and caused my phone to crash quite often.
2. So this won't change how we code or create infoboxes other then the theme?
3. Does a users ability to add information to infoboxes remain he exact same?

Overall, I don't see any downsides, so I'm onboard with it. Capt. Miller^Talk 06:58, December 16, 2017 (UTC)