FANDOM


  • Hi everyone,

    a long time ago (August 2015) I started working on creating new infoboxes for this wiki. For those of you who don't know what that is, it's a box in the upper right corner of many articles and summarizes the most important information of the page.

    This has mainly been inspired by the fact that our current Template:Infobox is very generic and somewhat unpleasant to use. The new infoboxes are now specific to one type of game element (e.g. questline, character, building). As such we don't have to specify row titles anymore and a consistent row ordering is enforced.

    They are implemented with Wikia's Fandom's Portable Infobox feature (see Help:Infoboxes and w:c:p:Infoboxes). This means they integrate better with the mobile skin and the Android App. In the future we might even get the possibility to access information stored in them programmatically. Basically that would allow us to generate pages like the game content list with minimal effort and have them update automatically (w:c:connect:Content Understanding and Contributions: Possibilities for the future).

    The new infoboxes have been dormant for a while now. But recently I've done some more work and I think it's time to get them to a usable state. I'm now at a point where I think it is best to get some feedback. You can take a look at what I've done so far by visiting User:NoWayThisUsernameIsAlreadyOwnedBySomeone/Sandbox.

    There are two main points where multiple eyes/opinions would be good:

    1. Completeness: I think I've covered most of the current usages of Template:Infobox, but of course I can't say for sure. If you know of an page that doesn't fit any of the new infobox-types please say so. Also let me know if you notice one of the new infoboxes is missing some vital row of information.
    2. Design: The infoboxes currently use the default theme which is quiet basic and not really related to TSTO at all. They can however be styled differently. I've done a set of different styles (see gallery below). The first one shows the current default style that you can see in the actual infoboxes on my sandbox. The second is based on how menus look in TSTO. The third one is a Simpsons-like yellow theme. The forth theme is called "Europa" and is an alternative theme provided by Wikia. For reference I've also added a screenshot of the design currently used on the old Template:Infobox.
      If you don't like any of these options, you can of course come up with your own ideas. Simply create an image with Paint/GIMP/your favourite image editing software. Or you can even draw something by hand and upload a photo of it.
      Edit: I've added a dropdoown selector to the Sandbox. You can now view the default theme, the yellow Simpons theme and the dark Tapped Out Theme.
      None of the themes are final, the self-made ones are simply some quick mock-ups. In order to get to a final version we must first decide on one of them. When that is done I will enable the chosen design so that everyone can see it in more detail. Then further tweaks can be made to improve it.

    Once we're happy with the way the new infoboxes behave and look, I will move them to the template namespace and add some documentation. From then on new pages should no longer use Template:Infobox. Old pages can be migrated whenever they are edited anyway (e.g. limited-time itmes that get re-released) or when someone just feels like doing that. To avoid having two sets of completely different looking infoboxes on pages, I will migrate the old Template:Infobox to the new format.

      Loading editor
    • When someone takes so long to do something so simple but pretty will you always be happy :)

        Loading editor
    • Regarding
      1). From what I saw the seem to cover all current possibilities.
      2). As I pointed out some time ago the (http://imgur.com/usXoRd1) the Simpsons Theme is the one of my preference.


      For the Content Update and Release Date sections. Will those include the date of the original release only, or will still be like up to now (with all of them).?

      For the image entry, is there a way to affect the imagewidth used, because some of the images we use might make the things a little unpleasant (I'm mostly talking about those with a large height).

      How is going to be the approaching for sections like premium and limited, in case they eventually change. Will we still leave traces of the changes, like the ones of the Rail Yard, or Dr. Colossus; or we not like in the cases of income or bonus payout of freemium items upgraded to premium.

        Loading editor
    • As I pointed out some time ago the (http://imgur.com/usXoRd1) the Simpsons Theme is the one of my preference.

      Now that you mention it, I remember (original post). It's been a while indeed. Are you specifically looking for the colors in the screenshot or just for a yellow based theme in general?


      Because images are scaled automatically there is no explicit way to specify the image size. I can however globally limit the maximum height an image can ever have. This should tackle the issue for pages like Eiffel Tower (250px width would just be disastrous there). I don't think it will be needed, but I could even add multiple different max-heights, and them one of them could be selected on a case by case basis.


      You bring up some good points regarding what belongs into infoboxes and what does not. Even though it is not technically related to the new infoboxes per se, it's probably a good idea to define and document some standards along the way. Those might serve as a good starting point for some sort of "Manual of Style". FauxCerf has done some work in this area by providing "copy-paste models" in his user space.

      Regarding the specific points mentioned my thoughts are as follow: If I remember correctly the Content Update field used to only contain the original update until someone just added a second update for some re-released items. And then it got adopted by other editors as well, which would indicate that other people liked it and that it's a good idea. However, personally I think we are duplicating a lot of information there. An infobox is supposed to summarize the most important infromation only. I see that it's important to showcase how much something costed. However it doesn't seem that vital so see all the updates an item has been released in, especially if there are a lot of them.

      The information is still available through the introduction text of the page and also through the links in the Cost/Need to Collect and How to Unlock columns. That's also why I had removed the Release Date field from the infoboxes. I came up with that field in 2015/2016, but I don't think it is currently used, and it is also redundant with the introduction text. I guess one could argue, that to be consistent, the whole Content Update field should be removed as well.

      The premium and limited time fields probably started to have multiple values similarly to the Release Date one. Personally I'm against it for two reasons: No matter when or how an item was obtained, the premium status will always be the same. Having multiple values might indicate "I got that decoration in 2015, so I don't get any bonus percentage. It's premium only for those who bought it in 2016." Additionally multiple rows look bad in the horizontal layout and there isn't really space for any explanation à la Check(since Superheroes 2016). Same goes for Limited Time even though that happens more rarely.

      To summarize: Personally I would prefer to have history only on the Cost, Need to Collect and How to Unlock, to a) not overload the infoboxes with too many information, b) stay somewhat consistent with the amount of information we provide and c) not duplicate the information from the introduction text of the page. I might even go as far as saying we could remove Content Update entirely from the infoboxes.

      Alternative opinions and the reasons for them are of course welcome :)

        Loading editor
    • Sorry for the late reply, this type of answers requires a lot brain processing, and that is very time-costly. LOL

      A yellow theme in general, I had merely changed the background colour from the original image to yellow.

      A multiple limits seems like too much trouble. IMO 250px seems to be THE optimal limit for either one. For example, in the ESBN Sports Desk I set the imagewidth to 200 and the height got to around 250. Exceeding that number on either value seems too big.


      His models were nice and I used them a lot in the beginning; then the "problems" arisen. There were several different models needed for each item type that came in order to reduce the number of edits needed to be done to the page for re-using it. For example Buildings:

      • Premium standalone
      • Premium with character
      • Freemium standalone
      • Freemium with character
      • Event prize standalone
      • Event prize with character
      • Crafting prize,

      add quest, no quest for every one. And that was just for the buildings, the decos were even worse (add an income, no-income version for every one of the above). Nowadays I'm using the closest-in-time item that matches most if not all of the data fields needed that I can recall. For example, the Improvised Snare page was made using Cristo of Springfield as the model. The Sumo Stadium was made using Wes Doobner's Rib Huts, and the very recent Anger Watkins from Brother Faith.

      Bottom-line to make models we're gonna need a wide variety that cover most of the options.


      I have no problem with removing the Content Updates field from infoboxes. Some items of the past, that were re-released a good amount of times, got quite a list in that field like the case of Springfield Cemetery, others, I tried to reduce it such as Marge the Witch case, but it needs to be completely redone if she fails to appear in a Treehouse of Horror event.

      No problem with no history with this two as well. Regarding premium status, one thing I'd like to clarify. You recently updated Kumiko's page and changed to premium character, this is understandable as she was re-released for donuts, that said, to the eyes of the game, she's still completely freemium, and not even reaching Number 1's "premiumness" level. Me on the other hand flagged Fatov as a premium character just because its payouts are premium. There's also FauxCerf change which also seems to be based in payouts.

      Bottom-line I would like to properly define what we consider a premium character.


      Some other stuff that came to my mind,

      • I presume that the Real Estate Value Points reward we currently have for Springfield Heights items are going to be displayed in the Buildings reward field, right?
      • Character Menu Images. Since the Treehouse of Horror XXVII Event they became a little pointless, since they're now just a lower resolution of the unlock images.
      • Menu Images in general. While the Seasonal Image template was an interesting addition, in practice it fell short, very short. We cannot change the parameters of that thing unless we upload ALL item seasonal images which would take a lot of time, especially considering the amount of time we currently have for editing. So, would it be too much difficult to make them all appear (if applicable) to the infoboxes in tabs?.
        Loading editor
    • For all of us normal TSTO wiki users this is complecated

        Loading editor
    • Don't worry about the late reply; just look at me, I'm even worse :P

      Yeah, I'd say 250px seems like a reasonable limit.


      When referring to FauxCerfs models I wasn't really meaning technical side of them being copy-pastable. Instead I was thinking of something like w:c:starwars:WP:LG, defining what belongs into the introductory section of a page, what the about section is supposed to be, etc. Most of the information will be primarily useful to less experienced editors. However, such a Manual of Style will also provide the definitions for things like what we consider premium and what not.

      Regarding Kumiko, I just made her premium without thinking too much about it. I am pretty sure there are multiple (contradicting) definitions to determine premium status of an item used across the wiki. Feel free to change it back to non-premium if you think that is more consistent with the existing pages.

      I also have some ideas how to simplify page creations, even though they are mostly long-term. The new infoboxes will provide some of that though: Correct me if I'm wrong, but I think infoboxes and categories are the main part where pages differ based on what type they fall in. The new infoboxes automatically hide empty fields by default. That means we can use a single empty copy-paste infobox model with all possible fields and just fill in what is needed. And to avoid actual copy-pasting we can use mw:Manual:Creating pages with preloaded text or w:c:dev:PreloadTemplates, the latter could even be added directly with the new infoboxes. In the long run multiple categories can automatically be added through templates, mostly the infobox, but also some navboxes I guess.


      • Yes, Building reward is intended for REVP as well.
      • Character Menu Images: We should probably just upload the highest resolution one (usually unlock image, but sometimes character set as well, see File:Marge Character Set.png) as menu image. Unless of course there is an exception where they differ. For characters that were released before the change, their old menu image can be added to the gallery.
      • If I remember correctly my rationale behind the the {{SeasonalImage}} template was the fact that the old infoboxes don't support tabs. You can theoretically add <gallery type="slideshow">(doc) for the image paramter and it is kind of working. The result however is a complete mess and I had to remove it everywhere I found it.
        The new infobxes in contrast have builtin support for tabs (see Help:Infoboxes#How to use multiple images or videos). You can simply add a <gallery> for the image parameter and it renders nicely for both desktop and mobile layout.
        Loading editor
    • We all know then we have an idea in what somethings means and no idea what other stuff means.

        Loading editor
    • New Infobox dark theme showcase quest
      New Infobox dark theme showcase promo

      I originally didn't want to give my own opinion first but now is probably as good a time as any: I personally prefer the dark theme. The images on the right show two of the things I particularly like:

      • Quest icons with white borders around them blend in nicely with the dark theme, recreating the taskbook look.
      • Rectangular images (like for promotionals) resemble the design of store-categories for events.

      This would mean that we are currently tied. I was hoping for some more people to leave their opinion about the designs. There's no need to think about the other points mentioned in the thread if you don't want to or don't have the time to do so. Locoquito and I have been producing quiet a bit of text :D

      Unfortunately the forums don't support mentioning others. If they did I would probably mention at least @StephenTX, @Mutant Peacock, @BartNinja and @WizzFizz7 (arbitrary order based on last edit) and ask them to leave their opinion. But also @everyone that I haven't put in the list above, please feel free to share your thoughts!

        Loading editor
    • The color black goes well with almost all colors

        Loading editor
    • I don't have much to say at the moment but I think that the new infoboxes look like they would be a good new thing on the wikia, the icon borders would be more noticeable with a different colour background other than white and the rectangular images match the ones that are in the game. I don't have a favorite theme but with the dark theme, it would look great during some content updates like the current Secret Agents event or during Halloween events and the yellow theme does match simpson yellow with other Simpson wikis and obviously show that its about the Simpsons and of course Tapped Out. Sorry if its not much to go by now but i might add more of my opinion in the future.

        Loading editor
    • I forgot to say that in the new infobox images there is no conform-o-meter increase on it and i don't know if you left it out intentionally or accidentally.    

        Loading editor
    • Thanks for the feedback. Being undecided is OK as well. That still gives us some direction: Either dark or yellow, if I've read that correctly?

      The images in the OP unfortunately aren't based on the very latest version of the infoboxes. The current ones have appropriate fields for Conform-O-Meter, Krust-O-Meter and Bonus Payout (see User:NoWayThisUsernameIsAlreadyOwnedBySomeone/Sandbox#Buildings / Decorations)

        Loading editor
    • I've added a live preview for some of the themes to my Sandbox. On top of the page you will now find a dropdown where you can select between the default theme, the yellow simpsons theme and the dark TSTO-menu-like theme.

        Loading editor
    • NoWayThisUsernameIsAlreadyOwnedBySomeone wrote: I've added a live preview for some of the themes to my Sandbox. On top of the page you will now find a dropdown where you can select between the default theme, the yellow simpsons theme and the dark TSTO-menu-like theme.

      Excellent addition. I'm not liking the contrast of a link with the background (on both themes).

        Loading editor
    • What would you prefer? More contrast, less contrast; a lighter color or a darker one? And which for which theme? :D

      I'd like to somewhat keep the general color of links since we need to deal with redlinks as well (added one to the first infobox for demonstration purposes). Completely changing colors would most likely lose the classical "blue -> page exists, red -> page doesn't exist" association.

        Loading editor
    • FWIW, I like the look of the dark theme in isolation, but I have concerns about how well it'd work on top of the white translucent background of the wiki. The default or Europa schemes would look better, IMHO. The yellow one is just hideous, though, so I suppose my vote is "anything but that".

      Also, it's easy to fix issues with appearance; that's just a minor CSS update. I'm a lot more concerned about the contents--both making sure the template has all the options we need and getting all the pages updated. It might be more effort, but I think it might be wise to start with one type of page (e.g. quest), update a bunch of pages to uncover any hidden problems while the code that'll need fixing is still fresh in your mind, and then move on to the next when we're confident that one is okay.

        Loading editor
    • Oh, and another thing... Please make it so the templates auto-add site maintenance categories for any "mandatory" data that is missing, as I recently did manually for characters missing a collection. It would also be nice if they auto-added the more common categories based on their contents, so editors only have to add the ones that aren't obvious.

        Loading editor
    • NoWayThisUsernameIsAlreadyOwnedBySomeone wrote: What would you prefer? More contrast, less contrast; a lighter color or a darker one? And which for which theme? :D

      Whatever makes the links noticeable. In the default theme there's no issue due to the background being a soft colour. In Simpsons theme one, the links aren't very distinguishable from regular text. In the dark one, they aren't very readable. The one that displays the issue better is the Promotionals infobox.

      StephenTX wrote: It would also be nice if they auto-added the more common categories based on their contents, so editors only have to add the ones that aren't obvious.

      I second this. Categories -that we currently don't have- like main 8 ratings: vanity, consumerism..., and why not bonus items, for those pages where a value is added for those entries.

        Loading editor
    • NoWayThisUsernameIsAlreadyOwnedBySomeone
      NoWayThisUsernameIsAlreadyOwnedBySomeone removed this reply because:
      Off topic
      22:01, April 26, 2017
      This reply has been removed
    • It might be more effort, but I think it might be wise to start with one type of page (e.g. quest), update a bunch of pages to uncover any hidden problems while the code that'll need fixing is still fresh in your mind, and then move on to the next when we're confident that one is okay.

      My feeling tells me that we probably won't have enough time to systematically update old pages. The strategy that I kind of have in the back of my mind is as following: Use the new infoboxes for all new pages exclusively. If something isn't possible to do, fall back to use the generic infobox (which will at least have the same look). I can then incorporate what is still needed. Old pages will stay on the generic infobox (again: based on new technology and with new design) until they are edited anyway (returning items, etc.) or until someone actually has some time to spare. For easy discoverability all pages that still use the generic infobox are put into a maintenance category automatically.

      Both approaches are basically the same except for which pages are selected as test-pages. My version would use the high-traffic pages as test-pages, which in general would seem like a bad idea. However if a problem comes up, it will probably be along the lines of "This specific thing can't be expressed with the new infobox", which means it will be noticed when creating/editing the page as opposed to when viewing it. With the fallback being what otherwise would be the default for them all IMHO seems like a reasonable tradeoff.


      Please make it so the templates auto-add site maintenance categories [...] It would also be nice if they auto-added the more common categories based on their contents

      I had originally planned to do that directly when doing the infoboxes. Due to how long it took me to even find enough time to get them done in the first place, I decided to do this as part of an second iteration. The code will most likely just end up in a Lua-module where I can do proper logic, which would keep changes to the infobox-templates minimal. Removing existing categories from pages can easily be done via bot.


      Whatever makes the links noticeable. [...] In Simpsons theme one, the links aren't very distinguishable from regular text. In the dark one, they aren't very readable.

      I will try to think of something, even though I'm not sure what. In the dark theme I could probably make them somewhat lighter...

        Loading editor
    • For easy discoverability all pages that still use the generic infobox are put into a maintenance category automatically.

      Thanks. You do an amazing job of adding new content quickly, and I'd certainly never ask you to stop or slow down, but others wishing to contribute would probably appreciate automatic maintenance categories giving them a ready-made list of tasks to chip away at when they have the time.

      My version would use the high-traffic pages as test-pages, which in general would seem like a bad idea. However if a problem comes up, it will probably be along the lines of "This specific thing can't be expressed with the new infobox", which means it will be noticed when creating/editing the page as opposed to when viewing it.

      I get that, but I was figuring you'd rather get a pile of complaints about each template while it's still fresh and you can solve them all with a more general solution, rather than have them come trickling in as pages are gradually updated and doing a series of small hacks.

      In working through various issues here over time, I've found a lot of oddities that only affect one or two pages in a given category, so I worry that you'll find major design issues months (or years) in the future that you'll wish you knew about now. Or maybe I'm just too jaded from working too long in the software industry.

      The [auto category] code will most likely just end up in a Lua-module where I can do proper logic, which would keep changes to the infobox-templates minimal.

      I don't know Lua, but if you can at least code a few different examples, I should be able to modify them easily enough to cover any other cases that we can think of. Code is code.

        Loading editor
    • others wishing to contribute would probably appreciate automatic maintenance categories giving them a ready-made list of tasks to chip away at when they have the time.

      Yup, that makes sense. Now that I think about it, it is probably best to add some support to explicitly differentiate the absence of a field value (unknown) from the absence of said feature (non-existent, e.g. | collection = none or | voiceActor = none) directly to the first release. There is no need to actually use those values right away, but we can add them to the infoboxes and have them ready for later use.

      [...] rather get a pile of complaints [...] and you can solve them all with a more general solution, rather than [...] doing a series of small hacks.

      [...] a lot of oddities that only affect one or two pages in a given category, so I worry that you'll find major design issues months (or years) in the future that you'll wish you knew about now.

      Yeah, that's a legitimate concern. And it works fine for the smaller categories (Category:Voice Actors as the extreme example). However if we want to update all or at least most of the 1455(decos) + 819(buildings) = 2274 pages for the Building/Deco Infobox before using it on any new pages we'll probably never get there because there is always so much stuff to do (personally I won't have much time during at least the next three months and after that I'll probably focus on realizing some better automation that simplifies editing).

      The two things where I'm less confident that everything is covered are Currencies and Consumables. This is partially caused by the fact that those infobox types are rather new. Ccurrencies never used them and the Consumables category is pretty new compared to the others. Since those two are reasonably small it would be possible to update them in batch mode as you suggested. Simultaneously we could successively update the infoboxes for the bigger (and better established) categories when the pages are edited anyway. Though it would at least be necessary to find all consumables first...I don't think they are consistently categorized or even treated as such).

      I don't know Lua, but if you can at least code a few different examples, I should be able to modify them easily enough to cover any other cases that we can think of. Code is code.

      I can't say that I know Lua either. I've read some of the basic chapters of the Lua Book, done some experiments locally and wrote the stuff in Category:Lua Modules. That certainly doesn't make me a knowledgable Lua programmer. But like you said, code is code, at least if you are familiar with the basic paradigm set of the language in question. Of course writing stuff that way is slow and stupid beginner errors are going to happen. From what I've seen in the book Lua is prone to such errors unfortunately (e.g. some results are magically discarded if you append another parameter). But the amount of complexity is limited, so this should all be handleable.

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message
Community content is available under CC-BY-SA unless otherwise noted.