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, apart from these questions, I see no problems with it. Capt. Miller^Talk 06:58, December 16, 2017 (UTC)

1. The primary goal of using PIs is to improve the function of infoboxes on all devices (including but not limited to mobile). I'm super curious what experience you had with them that caused your phone to crash, as that definitely shouldn't be possible. Can you send message me on Special:Contact about what you experienced and where (and when), so I can figure out how that went wrong?
2. How you code the Templates changes. It uses the syntax described at Help:Infoboxes. As far as inserting them into articles and editing the information in them, that's potentially easier with PIs than classic infoboxes. There are tools in the visual editors for inserting and manipulating PIs that are not otherwise available.
3. The users' ability to add information is actually improved, as Visual Editor (and soon RTE editor) makes this a graphical experience for PIs that is not matched with classic infoboxes. If they work with the source editor, there is no difference in how they do so.

— FishTank (wall) 07:32, December 16, 2017 (UTC)

Thanks for explaining that, all sounds good to me.

Also, sorry, but I meant the browser on my phone. I wouldn't worry about it as the model was already dated at that point. Capt. Miller^Talk 10:24, December 16, 2017 (UTC)

I've added the import line for the Portable Infobox CSS. As a reminder, that CSS will only affect Portable Infoboxes (of which you currently only have drafts, not any live on articles). I'll use it to create the rest of the drafts over the next week, which will not be approved until we've discussed the end products here and they've been well tested. I'll check in here with the results after New Year's. Thanks! — FishTank (wall) 10:42, December 25, 2017 (UTC)

Hello. I want to chime in to point out something about PI and why Wikia has so many interest in implementing them. FishTank hasn't been totally honest here (well, Wikia hasn't been honest with the users in general in the past 3 years anyway). The only reason Wikia exists now is to make money, and while PI syntax allow to create new infoboxes easier, there's no real need to use them on existing ones, except that Wikia will use them as a markup to easily deliver in-content ads inside or just after the infobox, specially on mobile devices. You know, ads at the top of the article can be skipped easily by scrolling, but this allows an ad right after the infobox, which you're forced to view. Better mobile experience is an excuse to not make it so obvious, and forbid.

Another thing that you need to know: while FishTank has written this post and replies stating he's asking, not forcing, the real thing is that PI will be implemented on this wiki sooner or later, even if all of you disagree. This is Wikia's roadmap:

1. (current stage) A first post in a very collaborative mood to seek for consensus, trying to convince all of you how good are PI, and rebut any objections to PI implementations. The idea is to get the "community" approval to implement them.
2. If previous stage fails, a new post will be made several months later, this time with "almost-finished" drafts of the most important infoboxes used on this wiki using PI, and a defined deadline of when they'll be implemented. Community can raise concerns but they'll be dismissed. The only way forward will be to identify issues of the drafts and fix them before being implemented. See an example on the Spanish Pokémon wiki.
3. Even if the previous stage has a majority of the community against it, the drafts will be published on the templates, and all templates will be protected so only sysops can edit them. If a sysop reverts any template to use the old wiki syntax, will be demoted (with a reason "interfering with FANDOOM network operations").

I'm not trying to convince you against converting your templates to PI on your wiki, because as I said, they'll be implemented anyway. But I wanted to let you know the experience on other wikis where we opposed to it, and give you an advice. Since they'll be implemented anyway, try to at least point out to FishTank all the flaws of the drafts, to be sure the new templates are as close as the originals and work correctly on all the pages where they are being used. We refused to collaborate with them, and the PI drafts were totally untested and broke a lot of pages, making several of them look horribly or not displaying the information correctly. That's why I reverted them and I was demoted. And it took several days and even weeks to fix those templates to make them work properly (apparently FishTank is unable to understand wiki syntax correctly or at least translate it to PI code without big omissions). Best of luck with Wikia and happy New Year! --Ciencia Al Poder ^{FANDOOM no more} 13:45, December 30, 2017 (UTC)

Wow, gotta love how some people from Wik- goddamn, sorry, Fandom like to keep on blatantly abusing their powers. First, they activate the "Discussions" feature without asking our permission (and refuse to remove it even when we've set up a successful voting procedure against it), and now they're capable of doing things like this? Fantastic. Ultimate94ninja ^{talk · contribs} 16:44, December 30, 2017 (UTC)

I would like to address what Ciencia has said here, even though he has no standing in this community. As made clear above, we're much more interested in discussion from active members of the community. He's entitled to an opinion, of course, but there is a caveat here; he's fairly close to trolling in the places throughout the network where he continues to interject himself into conversations on a network which he claims to have left, and only seems to appear now to disrupt conversations like this one. Therefore, I ask the members of this community to treat his statement with at least a grain of salt. Ciencia's experience described above was unique to his community, for several reasons that we don't need to get into because they don't apply to your community; it is also not accurate.

That FANDOM exists only to make money is disingenuous. We are a for-profit corporation, but obviously we provide a lot of community space for our users to express themselves and contribute about their favorite topics. We do also invest more heavily in revenue-generating operations than those that are less profitable, and make business decisions in some cases that affect communities. All of that is common sense and not in dispute.

In recent years, we've made an effort to make content work on a variety of devices to keep up with an evolving world. We've created tools like Portable Infoboxes to make that effort work better because there is so much individuality and variety in communities; that variety produces unpredictable and sometimes unstable or unreadable results on a variety of devices. With traffic coming from an increasing number of non-desktop devices, it's important for us to present a more consistent experience because otherwise communities lose readers / users. Losing readers is not something we (FANDOM) want to do, and we don't think it's something communities want either.

There are no ads in Portable Infoboxes. There haven't been, and they are not meant to be an ad-delivery vehicle. We don't use them to put any additional ads on desktop or on mobile. This is at best a myth, and at worst an outright lie. The one case where these were found was rectified within an hour (3 years ago), and acknowledged to be an inter-departmental technical error; this rumor persists, nonetheless. We have, as stated many times in many places, worked to reduce the overall number of ads and ad placements network-wide.

Next up, I am indeed asking rather than forcing. And thus far, the consensus seems to be that you don't find them all that problematic. I do, as Ciencia does, suggest that you review the Drafts for flaws. I have a table below for you to do that for the templates drafted so far in this staged rollout. If we need to make corrections or get closer to the original styling, please let me know and be as specific as you can be. We have ample time to modify and test these.

Infobox Drafts

Original Template	Draft Template	Original Screenshot	PI Screenshot
Infobox/soldier	Draft
Infobox/weapon	Draft
Infobox/achievement	Draft
Infobox/level	Draft
Infobox/map	Draft
Infobox/vehicle	Draft
Infobox/army	Draft
Infobox/dlc	Draft

I appreciate the willingness to allow drafts here of what is possible when we work together, and I wish you all the best in the new year! — FishTank (wall) 21:33, December 30, 2017 (UTC)

(inline note) As I said, ads are placed next to the PI on mobile devices, between PI and content. Feel free to test yourself on any page with PI from your mobile phone. I didn't tell any lie, and I didn't say it will put more ads, only said the ads will be inside or next to PI and this is a fact. --Ciencia Al Poder ^{FANDOOM no more} 21:47, January 3, 2018 (UTC)

With some due respect. After what Fandom did to us in regards to Discussions, I'm inclined to not think of Ciencia as trolling. While it may well be likely he has a bias and wants to simply oppose anything Fandom wants to do, I can't really say it's unjustified. This is a smaller matter than Discussions, which is why I sit more neutral on the matter. However the points that Ciencia is raising, especially the "accept it now to have it forced later" rings very true with us, especially after the issues we had with Discussions, a feature our community doesn't even want. I mean, if it turns out after you turn this feature on we don't like it, will you turn it off? Or will we have the same story on how it's not possible and we have to accept it and not be scared of change? We look at every comment in the same light when making these forums, we will not dismiss negative opinion as "trolling".

Crazy sam10 • Talk

11:15, January 3, 2018 (UTC)

Discussions is handled by an unrelated team, but I do take your point. Discussions is an eventuality for many communities as Forum is phased out throughout the network. Portable Infoboxes are a different method of making infobox templates. If they don't work for your community, you can revert them and go back to previous revisions of the template. We'd rather you not outright revert, and talk to us first to see if there are tweaks we can make; but you can definitely go back if you feel you need to. As I said before, we're providing a very generous timetable for testing and feedback. I'd rather not go into February or March before we make progress, but am willing to do so if you're actually providing feedback. — FishTank (wall) 18:21, January 3, 2018 (UTC)

Alright then, let's actually think about this for a minute. Fandom have the option to make everything they do an optional change on the Staff Dashboard, from Discussions to Portable Infoboxes. Now of course, this makes perfect sense. Why force regressive changes on Wikis? It's poor business sense and shows a total lack of intuition. So how about this - Fandom implement Portable Infoboxes, which is a progressive move, then encourage, but not force, the changes through the use of the admin dashboard, which avoids regressing Wikis just for the sake of getting your ideas across, which don't work for all Wikis. As we've seen with Discussions here and on Bandipedia, both of them have failed hard and so we're not convinced that this will work either. Making it optional and letting us trial this stuff with a guarantee of being able to revert whenever we want demonstrates progress and common sense which is what I'm asking for here. YELLOWLUCARIO ^TALK  14:22, January 3, 2018 (UTC)

It's actually not as simple as flipping a switch. Templates have to be (and have been, in Draft form) re-written. As you say, we're encouraging here, not forcing. The Portable Infobox language has been around for 3 years now, and it's stable. All I'm asking is for a trial, and I'm doing the work of the actual authoring to get started. None of this is meant to be invasive. Right now, for the templates that have been ported (those on this list that have "View the draft" as a button), you can go to an article and add /Draft to preview how it looks and acts. For example, if you go to Luger, you can use {{Infobox/weapon/Draft | ... instead of {{Infobox/weapon | ... and hit the Preview button. I'm suggesting you try that for a few pages (particularly any non-standard ones) and provide feedback. If you decide that are comfortable with the template, go to the template Draft and hit the "Approve this draft" button. If you don't like it, tell me what we can do to fix it. If and when they've been deployed, give us an opportunity to fix your issues before throwing the baby out with the bathwater. That's what I'm asking. Is that reasonable to you? — FishTank (wall) 18:21, January 3, 2018 (UTC)

So long as I can hear a guarantee that this feature can be turned off if the community decides it doesn't like it, I will happily move this to a vote.

Crazy sam10 • Talk

17:16, January 7, 2018 (UTC)

The infoboxes are elective. If your community decides to revert them, you won't have to keep them. I don't see that policy changing. We'll ask if there are changes that can be made to suit your needs, and we may persist in asking from time to time if there are new developments or we can better facilitate your needs. But we're not demanding you must keep them if they don't work for you. I can guarantee that, to the best of my ability. If I get overruled by my bosses later because of a policy change, that's out of my control. — FishTank (wall) 18:14, January 7, 2018 (UTC)

"Therefore, I ask the members of this community to treat his statement with at least a grain of salt. Ciencia's experience described above was unique to his community, for several reasons that we don't need to get into because they don't apply to your community"

— FishTank

Frankly, I do believe that it would be prudent for you to go on record and explain the unique reasons that Fandom used as justification for forced implementation of PIs on the Pokemon Wiki. The reason I request this is simply because those reasons, whatever they may be, may apply to this Wiki in the future. Furthermore, by knowing what the reasons are, this community then possesses the ability to take steps to ensure that they do not ever apply to this Wiki if it chooses to do so. --Guitar t-bone^{Talk to AJ} 18:21, January 7, 2018 (UTC)

es.Pokemon (aka WikiDex) is our largest Spanish-language community, by traffic, both now and then. They generate millions of page-views per week. As is the case with most of our communities now, the majority of that traffic was from mobile devices. However, a significant portion (potentially a majority) of their articles had infoboxes coded in wikitext that were broken on those mobile devices. Use of custom JavaScript, for example, to switch elements (image tabs, in particular) means those links (or images) are dead on mobile devices. Fixed layouts with tables exceeding the margins, without a structure that was legible on mobile devices (or made sense on desktop devices), make the articles less than functional. Here are some links to screenshots of the kind of thing I'm referring to. (1 2, 3, 4) The bounce rate (when a page is loaded for only a second or two before going to another link or using "View as desktop / Desktop site") was through the roof, signaling to us that people refused to or were unable to view the articles on mobile and that the page experience is "broken"; no one wants to visit broken articles. At more than a million mobile page-views per week, it became a business decision, and FANDOM needed to intervene. The leadership under Ciencia has (for as long as anyone can remember) been actively antagonistic and obstructionist. Good faith suggestions and efforts on our part have historically been met with hostility, not based on the merits of the products, but on the vitriolic sentiments of the administration. We really don't like enforcing compliance. We don't usually have to do that where the local administration and community are willing to give a fair hearing with sufficient time to test and prepare. We much prefer an opportunity to fix problems the community has with a proverbial screwdriver and not an axe. Will that suffice, Guitar t-bone? — FishTank (wall) 19:36, January 7, 2018 (UTC)

It does not take a genius to know that the abundance of mobile views to the Pokemon Wiki is directly caused by the immensely popular mobile game Pokemon Go. That being said, Call of Duty does have the mobile game Call of Duty Heroes. Now although it has nowhere near the popularity of Pokemon Go, it still does have a significant number of active players. But, given Activision's recent acquisition of mobile game giant, King, it has been announced they are making a new mobile Call of Duty game. So is it safe to say that this move by Fandom is in anticipation of that game's release? And second, given the inevitable rise in mobile traffic upon its release, how likely is it that Fandom will make a forceable business decision if we choose not to use PIs? --Guitar t-bone^{Talk to AJ} 20:07, January 7, 2018 (UTC)

Actually, Pokemon GO contributes traffic but is not the most popular part of that community. They've been longitudinally popular for years prior to Pokemon GO. That's beside the point, though. FANDOM prioritizes portability operations based on a number of factors; migration impact, anticipated traffic spikes, quality assurance (eg. "this site is visibly broken on a lot of pages"), and interdepartmental request (due to sold campaigns, strategic operations with the studio, etc.). In this case, we're revisiting communities where we can make the highest impact and facilitate performance and mobile aesthetic. Call of Duty migration impact ranks #6 this week. It's ridden pretty high on that list for years, which is why it was selected in the early days of Vanguard. I wanted to take another pass at it now to see if we could try a different approach and clear it from the priority ranking, not because of any impending games. It's still not very likely that we'd enforce a business decision, since we're having a productive conversation about how we can implement it rather than a "leave us alone and never talk to us again" attitude; so long as we're doing that, I'm sure we can reach at very least a compromise before any drastic actions. — FishTank (wall) 22:01, January 7, 2018 (UTC)

serious truth concerns

The leadership under Ciencia has (for as long as anyone can remember) been actively antagonistic and obstructionist. Your inherent failure to mention that Ciencia was willing to modify and tweak existing wikitext infoboxes with CSS or JS was met by blatant refusal to even consider is honestly at this point extremely concerning to anyone. So this isn't a case of Ciencia not willing to cooperate or compromise rather you refused to consider it. That's a bit insulting since you flat out dismissed that offer. After that, wikidex told you to go pound sand

http://portability.wikia.com/wiki/File:WikiDex_Kingler1-M-2017-05-10.png looks perfectly fine to me, this was your second screenshot

PS: i'm not trying to distract here, this is a matter of ensuring CoD community can actually trust that your words and actions actually align rather than contradict. You can make this a lot easier on yourself, FishTank, if you just be honest. This isn't to start an argument, this is purely fact finding.

Nerfmaster8 (talk) 19:38, January 8, 2018 (UTC)

We flat out dismissed the offer because modification of mobile articles using CSS and JavaScript is a non-starter, given the entirely intentional stripping of them in Mercury. That is not a focus of future Mercury development — development which is separate from that of Portable Infoboxes. We would not have accepted that compromise, did not offer it, and responded as to why; further, there's no indication that Ciencia and his community would accept any change including that one. The details of what happened on a completely different community, especially as you are not privy to all of them, are a distraction as they have little to do with the merits of Portable Infoboxes here on Call of Duty. In that screenshot, the image-selection buttons are non-functional and there's no significant layout or structure in that table (headers are unclear, alignment is off, the arrows are "retro", the meanings of the data fields are not obvious). This article's infobox simply did not work properly, and the PIs added the lacking context and layout. — FishTank (wall) 21:11, January 8, 2018 (UTC)

Vote

This forum is very quickly getting out of hand. While I do appreciate getting information from other sites and how they dealt with it, I don't want this turning in to a full-fledged battleground. As such I'm putting to a vote now so we can push to closing this. Option 1 is that we accept the new infoboxes on the express promise it can be removed if we want it removed. Option 2 is that we simply don't accept them.

Option 1

1. I honestly see no problem with implenting these. If we're going to disagree on the basis of past actions, it isn't really a fair enough excuse. Wikia's made a point to be more cooperative with our community (even with FishTank expanding on the issues with es.pokemon, which seems to be a touchy subject), so I think we should be judging this solely on the merits of PI alone, not disagreeing in spite. Capt. Miller^Talk 04:29, January 11, 2018 (UTC)

Option 2

1. The changes (as I've seen on the drafts) don't look really good to me compared to the original infoboxes. Additionally, there are valid points in the issues addressed by some users such as Sam and Ciencia, and due to the possibility (no matter how small) that we might not be able to turn it off if we accepted it at first (I mean, even FishTank admitted "If I get overruled by my bosses later because of a policy change, that's out of my control"), I'm gonna have to say no. Ultimate94ninja ^{talk · contribs} 19:47, January 10, 2018 (UTC)
2. Per above. YELLOWLUCARIO ^TALK  21:53, January 10, 2018 (UTC)
3. Fandom, you and I have personally talked about how to approach communities regarding PI. Part of that was learning to take "no" for an answer. I concur with my fellow administrators and community members who have expressed their discontent with PIs and their distaste with the way this is routinely handled by staff.      23:21, January 10, 2018 (UTC)
4. Per your quote, "Since we're having a productive conversation about how we can implement it rather than a "leave us alone and never talk to us again" attitude; so long as we're doing that, I'm sure we can reach at very least a compromise before any drastic actions."

Anyone with an even elementary knowledge of the situation here knows that it's just a super sugar-coated way of saying, "as long as we're having a productive conversation to agree to implement PI, there won't be any drastic actions.

Or in layman's terms, "if we don't reach consensus, we're going to implement them anyway."

That being said, I must oppose your request and ask that you and FANDOM go fly a kite. --Guitar t-bone^{Talk to AJ} 05:53, January 11, 2018 (UTC)

Despite the vitriolic tone of this entire forum, I must ask you to refrain from bending UTP. Joe 23:01, January 11, 2018 (UTC)

Comments

• As a reminder, the actual styling can be altered to be closer to the original. The screenshots represent a first draft. — FishTank (wall) 21:49, January 10, 2018 (UTC)