Forum:Portable Infoboxes

Okay, I know this thing was discussed before while I was away, but at this point in time, I feel we really need to go over this again. At this point, the use of portable infoboxes has gone beyond aesthetics and gone well and truly into the question of actual functionality. Case in point, Jackson's Revenge, where I've had to align the template to the left, because otherwise we were left with a bunch of broken code. Think it looks bad? Well, because we can't join boxes anymore, that's what we're now stuck with. But hey, at least pages like the Siege Breakers and Devil Dogs look slightly...less...terrible. If you want to see it look even worse, look up the JR's edit history.

As I said, this is no longer a question of aesthetics, this is a question of actual functionality. So far, the following issues with the new boxes have been identified:


 * Boxes can no longer be linked (which has given us stuff like Jackson's Revenge in worst case scenarios), and at best, has left us with the meta-campaign info being separated from mission info in mission articles. Whatever one thinks of the latter, the former is now borderline illegible.


 * Only HTML code has been able to set foreground and background color, and so far the bot that was said to clean them up has apparently been ineffective. This has affected faction and character pages, and to a lesser extent, mission pages (as in, the color no longer corresponds with player color). I'd also like to point out that HTML code, while I'm familiar with it, is far less user friendly for editors. I've just seen Psi-Ragnarok try to alter the color of the Void Seeker, and lo and behold, it hasn't worked. Why? Because "green" no longer works as a field.


 * Portraits can no longer be adjusted for size within the new boxes. In some cases, this has given us issues like Edmund Duke and Jake Ramsey, and has extended to hero units as well (see Fenix (dragoon). This has also affected faction boxes (see Terran Dominion and Tal'darim for example).

Now, as I understand, the argument for portable infoboxes is that it makes things easier for mobile users, and that mobile users account for over 50% of wikia page views in some cases. Alright, fine. I understand how ad revenue works. But at this point, functionality has reached the point of being outright broken in some examples. This isn't quibbling over aesthetics, this is actively impeding information (faction color), legibility (code), and yes, aesthetics (portrait size). I'd also like to point out that such boxes aren't going to make it any easier for mobile users to edit/create pages - there's inherent drawbacks with mobiles as editing tools when compared to a keyboard. The idea of "shafting" mobile users has been brought up, but it appears to have got to the point where we're sacrificing far too much to accomodate them. Potentially this is a solution without a problem, as mobile edits still occurred at times before this, and no-one complained about the format before.

If these issues can be sorted, great. But I'd like to propose the following:

1) Revert the boxes. I appreciate that work has gone into the new ones, but so far this has resulted in broken pages.

2) Return to the showcase concept. If the boxes can be recreated there, with proof that functionality can be maintained, then we can alter the code of the original boxes. Looking at the examples chosen, clearly a lot more testing needed to be done. We can go through each box and make sure that nothing is lost in the transition, because clearly, something has.

I'll wait for other admins to weigh in before doing anything drastic, and I know that in theory these issues were sorted before, but I have to question - is this the kind of thing that we signed off on? Jackson's Revenge is a worst case scenario, but so far not a single page has benefited from the change (IMO), at least from the perspective of an editor.--Hawki (talk) 00:28, June 15, 2017 (UTC)


 * I'm liking the showcase idea until we get things correct. I don't think the color HTML issue is necessarily that bad, except that we would have to hunt down ***many*** templates. We could probably replace that with templates. (So Black might be 000, or whatever color.)


 * Not having a smartphone, I unfortunately cannot see what the wiki looks like on a mobile device, either before or after the changes.


 * Meco's infobox template encompassed all templates at once, which would fix sizing issues (you wouldn't actually need to stack templates on top of each other). PSH aka Kimera 757 (talk) contribs 00:41, June 15, 2017 (UTC)


 * I might be able to borrow a smart phone from a family member. I do have an iPad, if that falls under mobile usage.


 * Except stacking templates was key to functionality in some cases. Also, did it actually fix size? I remember I had to fix the px a few times after forgetting to enter it, which resulted in the image ballooning. If anything, that's technically one thing the new infobox has 'fixed,' in that ballooning is no longer an issue, but again, the px format gave us the best of both worlds. Stuff like the Terran Dominion is bearable, even if the icon is smaller, but the Duke/Ramsey/Fenix examples (and others)...yeah, I think we've kind of gone over the line there.


 * I can live with HTML code, but again, it's far less user friendly. In every case, for the edits, I've had to follow the link on my profile to the page, find the code, and copy-paste. In the past, it was simply a case of "color." I'm also questioning about new users.--Hawki (talk) 00:46, June 15, 2017 (UTC)


 * I believe PSH is referring to my modular infobox (Template:Infobox, examples).


 * The modular infobox creates - in terms of HTML markup - one big table. This is different from the current boxes where (via the the concattop and concatbott flags) the boxes only - imperfectly - appear to be part of the same table; in terms of markup they are separate HTML tables, which is why it's imperfect.


 * From a quick look at the wiki-markup for the portable infoboxes, I suspect the modular infobox could be converted into portable infoboxes. - Meco (talk, contribs) 23:31, June 15, 2017 (UTC)


 * You and Technobliterator have coding skills way beyond mine. What changes would need to be made to template: infobox to make it portable?


 * Also, I create a template:black and template:white; while there's already a ColorText template, it's not intended for background. It's probably more efficient to create a single color template that can handle this though. PSH aka Kimera 757 (talk) contribs 23:46, June 15, 2017 (UTC)


 * Aside from being split into - effectively- incomplete HTML tables, the structure and coding style of the modular infoboxes are very similar to (I guess) the monolithic boxes before the change-over to the portable boxes. So whatever was done to the old monolithic boxes can probably be done to the modular ones too.


 * There are two complications concerning conversion.
 * All of the component modular boxes need to be converted before any can be used, because
 * The modular boxes are actually used in a few articles already.


 * So make temporary templates, test (can use the examples for that), then copy the code from the temporary templates into Template:Infobox.


 * If there's any interest in that I can take a look at it; progress will likely be slow since I'm a bit occupied with some other volunteer we dev stuff at the moment. Technobliterator may need to take a look at it - and perhaps may even want to do it themselves just to make sure it's done right - since they are going to be here more often than me. - Meco (talk, contribs) 15:04, June 16, 2017 (UTC)


 * When I chose the examples used in the Showcase, I chose the first page I found in the whatlinkshere for the infobox being converted. I checked the next three I saw to make sure that I was getting it right, but understandably there may have been use cases I missed. I'd also like to clarify that these boxes don't have to be in their final state. Anyway, as for the issues with the new infoboxes:
 * While I didn't build in a feature to link the boxes right now, it is possible to do it, and I can do it and get it done on a showcase first. I may have underestimated how important this feature was to you - I had heard from some users that they were moving away from stacking infoboxes on top of each other anyway, and therefore wasn't sure if I needed to keep the feature in.
 * Regarding the color codes, the bot wasn't "ineffective". It was run with the wrong commands and didn't fix every page it should have. As I type this message, it's being run properly. For editors, if it genuinely proves to be a huge problem still, PSH's solution should work. Otherwise, Special:Contact/feedback and request that the boxes be able to take "red", "blue" colors instead of just the hex colors. Personally, from what I can tell, many of these colors could be better suited as themes. The infobox has different themes set for races right now, where Zerg, Protoss etc changes the color - there are doubtlessly similar themes you could set up and automatically have the color set by typing something else. There could also be a "red" theme or a "green" theme that would be easy to create as well. There are many ways around this problem.
 * Portaits can't be adjusted for size right now because they're set to automatically adjust. It is possible to allow them to be manually controlled but then the automatic adjustment from the others would be gone. Alternatively, it could be possible to set the image parameter to automatically adjust while creating another image parameter, like "image2" or something, that does allow you to set the image, as I know you mentioned it removes a ballooning issue you had before. As it stands, while Edmund Duke arguably looks wrong, doesn't inflating the image just mess with the animation?
 * The end goal is that we shouldn't have to sacrifice anything to accommodate mobile users (who yes, make up 50%+ viewers, and are not insignificant) - that was never the case. It was about finding out what features needed to be retained. So Jackson's Revenge isn't, or doesn't have to be, something you're now stuck with for good. Rest assured that broken pages are not a permanent thing and the majority of these things can be fixed before needing to revert anything.-- V  Technobliterator   T  C  01:11, June 15, 2017 (UTC)


 * A few stray thoughts:


 * I think just moving it to a color name is fine as even our "racial" colors have largely been depreciated and were made in a time where there was really only one or two factions per race, but now we've mostly moved to just using default colors ("green" for Nerazim for example.)


 * The ballooning is largely something we've learned to live when it comes to articles like Duke with as the native resolution for those in SC1 were, well, not great as you can see. And it may make the portrait look a little off, but in its native resolution it's undoubtedly too tiny for the article. So if there was a manual switch to do it that'd be helpful.


 * I admit I also underestimated how many articles had stacked boxes, so I may have given the wrong impression upon my reviews. I thought we'd just have to deal with a few strays and the mission articles, but it seems with the extent we have it it's a core part of our wiki. --Subsourian (talk) 01:19, June 15, 2017 (UTC)
 * In MediaWiki:Themes.css I added a list of different factions and their colors, based off of Template:ColorRace. It may be easier instead to use these themes (which are currently based on the "race" parameter, but can be based on another one instead) for races and factions than rely on bgcolor - it should be easy for a new user to understand, and easy enough for an admin to know how to copypaste in that CSS page to add new themes, say, when SC3 comes out (or if Blizzard decide they want a fourth expansion because lolwhynot). I can add a manual switch easily for the image, or just a second "image2" parameter. As for concatbox, I apologise for underestimating how many articles have the stacked boxes, and how many need them. If cases like JR are the norm, I may need to look into the best way to implement the function, or work around the problem another way.-- V  Technobliterator   T  C  01:38, June 15, 2017 (UTC)


 * Unless there's a quick solution to these things I think we need to revert it for the time being and go back to the drawing board as to how to best implement this. I do think the initiative is admirable (my experience with editing on my phone always involves setting it to browser mode because our mobile site's pretty bad, but that's for a lot of reasons other than the infobox), and it's something I'd like to get done eventually, but we shouldn't have stuff like how our mercenary articles are right now until then. Right now the boxes appear unstable, the color issue has been something that keeps apparently being fixed then creeping back, and with what limited experience on mobile browsers I'm not noticing any major change on how the portraits operated there whereas the browser version has plenty of issues now.


 * I admit at first I didn't think the contatination issue would break as many things, I figured we'd have an odd article like Zagara but that most would just be the missions, which is easily fixable (and I may merge anyway just for sanity's sake). I was initially just going to add the smaller templates to the larger article (like I did with the mission ones) but now that I see the number of Lore+Unit combos I don't think that's feasible, and I don't think there's a way to not have contatination without restructuring a lot of our site.


 * I feel issues like the HTML code problem has to be something we can fix, after all all we do now is have the color "green" associate with a HTML code. It may take a bit (part of my job is HTML though so I know the basics), and if all else fails we can make a cheat sheet for colors as a placeholder. Not ideal, but provided it's temporary that's not a dealbreaker for me.


 * But another problem I have is issues seem to vary between browsers, my junk work IE11 browser ran fine before but now they're getting all sorts of scaling issues, whereas my home PC would have a different set of issues depending on the box. So I dunno, I still like the idea but right now we need more testing. --Subsourian (talk) 01:12, June 15, 2017 (UTC)


 * Per the above points:


 * Inflating some portraits did mess with resolution, but not so much the animation. But again, Duke and other images look ridiculous now. The idea of automatic scaling sounds nice in principle, but it's a bit redundant, because we always used the px code to set the image size. Ideally, an image should fill most or all of the box, and in a lot of cases under the new code, that clearly isn't the case.


 * I'm not entirely up to speed on the 'race theme', but it's a bit redundant. We have a de facto color that we sometimes rely on (e.g. terran civilians), but again, color is tied with affiliation, so the fg/bg color coding has been used extensively. Likewise with Sub, I can live with HTML coding (usually if I was creating a new article, I'd copy-paste from another article and edit the fields anyway) but it's more new users I'm worried about. Ideally you want editing to be intuitive as possible, and while the site certainly isn't that user friendly in a lot of areas, the coloring so far isn't among the iffy areas. Or, wasn't.


 * Seconding Sub (and again, myself), I'm still in favor of reverting, if only temporarily. I'd rather go through each box one at a time and get a signoff before implementing it. Given how edit history works, all the new code will be accessible in the editing history.--Hawki (talk) 01:53, June 15, 2017 (UTC)

Okay, I've been browsing through pages on my iPad and comparing them to the pages on my PC. Following thoughts:


 * The new box does automatically fit the image to it - Duke is a lot less shrunk for instance. However, again, that wasn't really an issue before, as we could fit it manually in the past.


 * The page colors aren't syncing up in some cases, but it could be a hardware thing. As in, the 'gray' code on the iPad is a lot darker than on PC. I don't know if this is due to the boxes or just something inherent to either device.


 * I'm not sure how exactly the changes have improved things, as it's damn near impossible to do anything but the most basic of edits on an iPad, and it would likely be just as hard, if not more so on a phone. I mean, browsing on the iPad is manageable, but that's about it. I've looked at the mobile preview option on both iPad and PC, and they both appear identical. I see that in both cases the mobile preview scrolls things vertically, so if the boxes are reverted, I'll check again on both devices and see if anything's changed where the box has been used. So far, the only advantage I can find is that the new boxes auto-fit images, and that was never an issue to begin with. The iPad functionality hasn't really been improved by the update, I can say that much.--Hawki (talk) 03:24, June 15, 2017 (UTC)


 * It's definitely still possible to create an alternate image parameter for cases like Duke. This means you don't lose the image auto-fit but don't get stuck with cases like that.
 * The "race" theme isn't just a race theme. For instance for Terrans, terradominion and raynorsraiders exists. So typing |race=terradominion in the infobox gives those themes, as well as automatically generating the link. This is also the case for things like hybrids. This was actually possible in the original boxes as well (might not have been used frequently). The bgcolor should really only be used if a character/unit/etc isn't a member of any of the factions.

It will be extremely easy to create an alternate image paramater, like "image2", where "imgsize2" works as desired. The main image function with an auto-fit function is given a specific purpose on the mobile skin (and comes with some added benefits - you can create a gallery of images with PI's image for example), so I advise not moving away from it completely, but if you prefer then I can do that to allow "imgsize" to work and therefore the ability to set the pixel size.

After that, if you're still dead set on a temporary revert, just let me know what exactly you want aside from box concatenation (though we shouldn't need to revert to sort that out either). I would advise that there should be no need to revert every single box and that a large number of boxes should be fine - and that if you want box concat to work, there are some we'd need to convert right at the same time. As far as I can tell, it's UnitBox, FactionBox, and CharBox that are problematic - and I'm totally fine with going through each of these again.-- V  Technobliterator   T  C  09:37, June 15, 2017 (UTC)

EDIT: Alternatively, if the portable infoboxes work on the vast majority of pages, but break in a few instances, then it might be better instead to create a "CharBox/old" or "UnitBox/old" using the old code, while the main infoboxes use the PI code. That way, the PIs are kept on the majority of pages while they do not have to be used in other instances. This could be done in cases of box stacking (that's assuming you're set against create a new template that merges them together without needing to stack separate templates - honestly, I can't imagine that being easy for new users to understand either).-- V  Technobliterator   T  C  09:46, June 15, 2017 (UTC)


 * Well, I'd rather just revert them for the sake of a short-term solution, then we can start working on a long-term solution, since each box is now having its own quirks, and the portable box code will still be readily available. So, in the short term, the wiki returns to full functionality. In the medium term, I might be able to borrow a family member's mobile and get a sense of browsing/editing (if there really is any difference between that and the mobile preview/iPad), so if the old boxes are really that detrimental, I may be able to get a sense of the extent. In the long term, it allows us to take each box as it comes and sign off on it.--Hawki (talk) 12:12, June 15, 2017 (UTC)
 * When converting, I converted each box at once. What we could instead do is convert a box, give it 2 days to spot issues, and then convert the next. I would still say it's best only to temporarily revert the boxes we know have caused issues - there's no need to revert something like GameBox for instance.-- V  Technobliterator   T  C  14:46, June 15, 2017 (UTC)
 * Okay, check Edmund Duke again - got pxcode to work for images again (though they no longer auto-adjust). Does that look better now?-- V  Technobliterator   T  C  17:30, June 15, 2017 (UTC)


 * I agree that if a box isn't causing any issues it's fine to keep around, Gamebox seems fine so far. But yeah we should probably revert some of the bigger offenders.


 * While I think it's improved I think the Duke gif's a bit too big now, but for the life of me I can't remember the size we had before.


 * Also if possible, I've been noticing that while bgcolor's changed and seems to be working better, fgcolor is now giving a similar set of issues. I assume that also has to use the same HTML.--Subsourian (talk) 18:01, June 15, 2017 (UTC)


 * It does indeed. However, is there any reason using the race themes (bear in mind "race" also includes factions, terradominion, raynorsraiders, etc) doesn't work?-- V  Technobliterator   T  C  18:57, June 15, 2017 (UTC)


 * I've corrected Duke - I tried to make it 250px when I was trying to find out why its shrunk. I've removed the px code, so now it's at its original gif size. Jake Ramsey has also sorted himself out (and Fenix (dragoon) so that seems to have sorted itself out.


 * When you say race themes, are you referring to the bg/fg codes? I tried using them (if that is how they're actually spelt), doesn't seem to work. Right now, only HTML does.--Hawki (talk) 21:40, June 15, 2017 (UTC)


 * On a related note, the unit box seems to be okay, in as much that color can now be set. So, that covers the aesthetics of co-op commander articles for instance.--Hawki (talk) 21:45, June 15, 2017 (UTC)


 * Also, faction box still doesn't work for image sizing - it works for the character box, but not factions for whatever reason.

--Hawki (talk) 22:30, June 15, 2017 (UTC)

Faction box should now work for image pxcode sizing - I basically only changed a few infoboxes that you needed to allow for resizing, while the rest still auto-adjust. Obviously I can do this for every infobox rather than just a few if you prefer, I just figured there were some that didn't have images that needed it.

And no - you use the race themes next to race, not next to bg/fg. So |race=terrandominion would output the right theme - which is something that worked in the original boxes but wasn't used, presumably because it outputs race incorrectly. It's possible to get the box to still output Terran as the race when terrandominion or raynorsraiders etc is entered, or another parameter could be used (like |theme=terrandominion).-- V  Technobliterator   T  C  23:28, June 15, 2017 (UTC)


 * Well, theme can go either way. Either we adjust the fg/bg or the race. Fg/bg appears more preferable.


 * Right now, the character and faction boxes seem to be in an okay place, in that the size of the images can be adjusted. I've used the  a few times, and that seems intuitive enough. White is usually the fg color used unless the bg color is gray or white. Battle boxes are fitting anyway and the color can be adjusted, and the game/novel  boxes look fine. Right now, the main issue that remains is the inability to link boxes together. In some pages, I've separated them (see Duke and the Overmind), because I'd rather have them in the game unit section than have them broken.  That does leave us with the mercenary units though. I'm willing to use a separate infobox with them because for such articles, space is really at a premium, and their current appearance speaks for itself. So, I'd be willing to tolerate the current format if we reserve the right to use the old format when it's needed.


 * On another note, the mission boxes also suffer from this, but something we could do is simply add to the battle box template to allow for the fields in the old template. So, for war articles, they remain the same. For mission articles, we simply fill in the extra fields. Ideally I'd rather have the ability to link boxes, but if we can't, I'm willing to go with these compromises.--Hawki (talk) 00:55, June 16, 2017 (UTC)


 * On the topic of mission boxes I already did it, I only did the missions for Rebel Yell though as sort of a test case just in case we wanted to change things up. But I don't mind going through them all as missions are a pretty contained ordeal, but also I want us to figure out some of the other issues with these boxes before I go forward with that.


 * Also I figure converting the old style colors to the may be something easier to do with a bot. As of now most seem to be working in that regard.--Subsourian (talk) 01:09, June 16, 2017 (UTC)

Making sure it's not just me, but I'm noticing every racial unit box appears to have a thin border of whatever the "race" color is (Alarak is yellow, Kaloth is green).

Just to make clear what I was trying to say earlier, tying color to race is something we've stopped doing in general, and it's only really been a thing in older articles. Now adays there are so many subfactions with their own colored boxes that it just isn't practical anymore (protoss has Khalai, Tal'darim, Nerazim, Purifier, Aiur Tal'darim and a whole slew of others). So I don't think we need anything tying race to color since it seems to be causing a lot of issues, or even faction as new ones keep popping up and a few only have one or two faction members and we don't want to have to make a new one every time a minor faction pops up.

But yeah, since I've been here most color boxes have been based off of just finding what units share a faction and going from there. But the border could be a feature to define race too if we want to look at it that way. --Subsourian (talk) 02:15, June 16, 2017 (UTC)


 * Yeah, I understand why tying color to race isn't done anymore because I know there are tons of different factions during the campaigns (although it should still be fine for multiplayer). However, is it still fine to tie color to subfaction? So, |theme=terran, |theme=raynorsraiders, |theme=taldarim, |theme=hybrid...etc to generate the right color? This could replace, or be done in addition to, |fgcolor= and |bgcolor=. I can get this done and show to you on a sandbox how it works, and maybe use the bot to change pages?
 * As for linked boxes - if you guys are already working on a workaround for missions, then that's probably easiest overall, since it would be very difficult to get linked boxes to work. Are there other instances in which boxes are linked? For vehicles and units, I imagine it wouldn't be too bad for those boxes to be split on pages (ie a unitbox would go under another header) but in cases where they definitely need to be linked, I see you guys have created unitbox2 and vehiclebox2 - that should be perfectly fine.-- V  Technobliterator   T  C  11:27, June 16, 2017 (UTC)


 * I don't have a problem with race theme as long as the actual race can still be listed within the box.


 * Concerning splits, I've created the Unit/Vehicle Box 2 for the mercenaries, as they were practically unreadable in their current format. Honestly, I'd prefer to use them more (well, prefer not to have to change at all, but whatever), but those were the only ones that absolutely needed them. Thing is, we can do a split at times, but often, it feels redundant. The Gantrithor is an example where a split feels detrimental, because there's not really anything that can be written in the "game unit" section since it only appears in one mission. But as far as linking goes, characterbox would need linking as well (e.g. Zagara).


 * To answer Sub, I've noticed the outline as well, but I'm willing to live with it.--Hawki (talk) 12:07, June 16, 2017 (UTC)

Other issue I'm noticing; when images are rescaled they appear to be off-center. There's a black border around the left and top corners of the image and another part gets cut off. --Subsourian (talk) 04:14, June 17, 2017 (UTC)

Hey folks, noticed you guys have been creating templates to recolor the infoboxes, and glad that seems to be working out for you. I can still showcase using a race theme for several boxes instead if you would prefer to do that (and then use a bot to change the color templates to use the new themes) and it may be easier long-term. I've also noticed use of Unit/VehicleBox 2 as mentioned above seems to be working out on the pages where PI just wouldn't work - if you're creating a separate template, it may instead be a good idea to create a PI template that combines the two together, like "UnitVehicleBox", rather than join two separate boxes. That way, you have the PI benefits on mobile/other non-desktop skins without having to worry about readability caused in cases where the split doesn't look great.

Do you guys have any issues you need addressing immediately, or should I just work on those two things for my showcase first and then roughly finish off? I'll aim to showcase both features by the end of this weekend. Also just note if there's been a reply on this thread I haven't responded to, I probably just haven't seen it, but if you poke me on my talk page I'll be able to address it immediately.-- V  Technobliterator   T  C  23:42, June 17, 2017 (UTC)