Fandom

Infobox Wikia

[New feature] Tabbers in Infoboxes

  • Fandyllic wrote: Here is the PI code I see in this example that produces "Tabber-like" results: 
    |image=
    <gallery>
    Kermit-frog-cartoon-funny.jpg|Kermit
    InezsTest2.jpg|Shovels and Rope
    Challenger-0.jpg|Challenger
    Dog in sunflowers.jpeg|Collie
    The-Avett-Brothers-4.jpg|Seth Avett
    Daenerys S3.jpg|Denise
    Killzone.jpg|Killzone
    </gallery>
    

    Is this placeholder code? Will tabs be able to have anything beyond images, support transclusion, be style-able, etc.?

    It's a good first step, but not to the point of advertising to other admins, I think.

    Should we start a separate thread for Tabber-like functionality in PIs?

    It will be just images, and yes, the tabs are style-able. I'm not sure how transclusions play into this, though. They should be supported as before, but you may be referring to something I can't picture right now. 

    Could you maybe link an example of an infobox with transclusions that you'd like supported in the portable markup, but that isn't right now?

      Loading editor
    • It seems to work well, and I think it is enough to convert a lot of wikias to the new infobox. The syntax is also well known to most wikians because it is a gallery.

      I'm conflicted about tabbers for general content. On one hand it will support those who want it, on the other hand it might make infoboxes unnecessarily complex, with every little thing conceivably having tabbers. I've seen infoboxes that span two or more pages, and this would help solve it, but I think that is the result of people wanting to add too much unnecessary information to it.

        Loading editor
    • At some point, we'll also have to admit to ourselves that if we continue to add more things that you can do with a portable infobox, just because they are currently done on desktop, we'll end up with infoboxes that are once agan not really suitable for mobile ... So we're trying to find a balance between allowing communities enough creative possibilities for their content, and keeping it standardized and simple enough to work well on all devices. It's not necessarily easy to find that compromise - and someone is always going to be disappointed. :/

        Loading editor
    • I design my infoboxes with a simple constraint in mind. If you can't view it properly on "printed A4 paper" then it doesn't belong there. Videos, audio and tabbers are all nice and nifty for the desktop, but having too many prevents one from really getting informed. For example, if you have general content in 6 tabs then users would need to keep clicking until they find the information they want. 

      Personally, I would draw the line at "collapsing" the infoboxes, and maybe some way of validating and specifying structured data. Beyond that, I believe the developers would be going into "project creep" territory.

        Loading editor
    • I'm pretty sure they agree with you there. 

        Loading editor
    • This thread should probably contain a link to the example.

      Infobox with tabber

        Loading editor
    • Is this change now in production? It doesn't seem to work with PNG files. :-(

      And the <caption> field for the <image> tag seems to be ignored.

        Loading editor
    • Moviesign wrote:
      Is this change now in production? It doesn't seem to work with PNG files. :-(

      And the <caption> field for the <image> tag seems to be ignored.

      It wasn't added probably because the tabber is still being beta tested. That's why they haven't announced it in a Technical update, I think. 

      That might also be why some features aren't working properly.

        Loading editor
    • Ok, I remain underwhelmed, but hopeful :-)

        Loading editor
    • Moviesign wrote:
      Ok, I remain underwhelmed, but hopeful :-)

      I tested it out using a preview in the visual editor wikia, and it does work with .png files. Also, it seems like they implemented it using a gallery. So caption for the image tag is irrelevant as you'd need to use the gallery syntax to put the captions for each element, unless you mean that you can't use it normally for other image files.

        Loading editor
    • So am I getting an older version that doesn't support .png files? Here is my quick test page: tabber test

      Adding a caption to each image just puts the caption text in the tab, so maybe that is what is intended, but I hope not.

        Loading editor
    • Moviesign wrote:
      So am I getting an older version that doesn't support .png files? Here is my quick test page: tabber test

      Adding a caption to each image just puts the caption text in the tab, so maybe that is what is intended, but I hope not.

      My guess is that there is a bug with spaces and ampersands and so forth in files, .png files still work on your wiki. As far as the captions are concerned, it will be somewhat complicated to support different labels for the tabs and the caption because they'd need to rewrite how the gallery tag works. 

      They may rework that or remove it entirely, as they haven't officially released these features so deploy it at your own risk.

        Loading editor
    • Yep, it's the ampersand. I replaced all the spaces with underscore and that didn't fix it, but choosing a .png file without an ampersand in the name works.

        Loading editor
    • In a url the ampersand has special meaning.  I just wish they would alter mediawiki to disallow such characters in content that will show up on a url and force a rename.

      Anyway, perhaps one way they may support different caption vs tabs is either using the the gallery's "linktext" attribute to provide the tab description and allowing the "gallery's standard " caption as the default caption, or perhaps adding a format tag for images.

      It'll probably depend on how how many wikis require this.

        Loading editor
    • Update:

      They have just been introduced for all users, and now allow the tabber too. So you can make them as complex as you need them to be.

      See: http://community.wikia.com/wiki/Thread:935527

        Loading editor
    • Nice! But I can't get the Tabber version to work at all, even after removing the "bad" files with ampersands in the name. :-(

        Loading editor
    • That's odd. It works perfectly here:

      <infobox>
        <header>Animals </header>
        <image>
         <default>
            <tabber>
               monkeys = [[File:Example.png]]|-|
               rabbits = [[File:Example.png]]|-|
            </tabber>
          </default>
         </image>
      </infobox>
        Loading editor
    • Alright, on the FFWiki, we use tabbers differently.

      See: w:c:finalfantasy:Kefka (Boss). This doesn't have tabbers within infoboxes, so much as it has...infoboxes within tabbers within tabbers within outer tabbers. Reasons for this are firstly the different encounters of the enemy, and secondly the version of the game. In other cases, we use tabbers for some parameters, such as the Steal parameter on w:c:finalfantasy:Yiazmat (Final Fantasy XII).

      This is something we'd like supported, but I'm not sure to what extent it is. I know that someone from Wikia came over recently and did a draft of an infobox using that and a draft of the /stats infobox it transcludes, but when demonstrated, no tabbers were seen. Everything else was working, though.

        Loading editor
    • Technobliterator wrote:
      Alright, on the FFWiki, we use tabbers differently.

      See: w:c:finalfantasy:Kefka (Boss). This doesn't have tabbers within infoboxes, so much as it has...infoboxes within tabbers within tabbers within outer tabbers. Reasons for this are firstly the different encounters of the enemy, and secondly the version of the game. In other cases, we use tabbers for some parameters, such as the Steal parameter on w:c:finalfantasy:Yiazmat (Final Fantasy XII).

      This is something we'd like supported, but I'm not sure to what extent it is. I know that someone from Wikia came over recently and did a draft of an infobox using that and a draft of the /stats infobox it transcludes, but when demonstrated, no tabbers were seen. Everything else was working, though.

      That "information box"  has in my view has stopped being an infobox. It is a group of infoboxes inside infoboxes inside a tabber inside a tabber. There are lots of infoboxes and tabbers mixed up in that infobox

      More importantly, as you've clearly stated, the tabbers aren't in the "information box"they are outside it, so there's nothing for wikia to support because that's outside the scope of infoboxes (unless they decide to support nested infoboxes).

      No offense to FFWiki, but I really hope Portable infoboxes don't support this kind of construct because it will make infoboxes incredibly complex, and very hard to style. I looked at the infobox for half an hour and I'm still confused. From a simple count, there seem to be 20 infoboxes in that small space. No wonder Wikia stopped working on it. 

      I would suggest breaking up that information.

        Loading editor
    • Dessamator wrote:No offense to FFWiki, but I really hope Portable infoboxes don't support this kind of construct because it will make infoboxes incredibly complex, and very hard to style. I looked at the infobox for half an hour and I'm still confused. From a simple count, there seem to be 20 infoboxes in that small space. No wonder Wikia stopped working on it. 

      I would suggest breaking up that information.

      So? If your wiki doesn't want to use infobox structure like that, you don't have to. That's really a pointless argument to use against them, "oh I didn't understand it because I found it complicated, therefore I hope Wikia never helps you solve your problem! Hah!" What I'm asking for is if Staff can provide a solution to my problem, not for someone to lecture me as to how to do things differently - and there are very specific reasons we structured the infoboxes like that, btw.

      If what I'm asking for is for nested infoboxes, then I'll make that proposal instead: can Wikia implement nested infoboxes?

        Loading editor
    • Then I suggest that it be reported to staff. Someone has already listed it as a bug:

      http://portability.wikia.com/wiki/Portable_Infoboxes/Bugs

        Loading editor
    • One thing I would like to see for mobile tabs would be the ability to swipe across them on screen to change which tab is displayed at a particular time. This may make it easier to use on mobile devices than having users tap the tabs.

      I also disagree with the notion that tabbers for general content and nested infoboxes are not portable. I see no reason it should be too dificult for mobile users to switch between tabs displayed to see different content - tabs on change what content is displayed at a particular time. This is a great alternative to cluttering content with multiple additional columns, additional tables taking up space, or additional pages that will display what is often very similar content.

      I agree that adding features to portable infoboxes may reach a point which they are no longer easily portable for mobile, but I think tabs are more helpful rather than less helpful.

        Loading editor
    • Technobliterator wrote:

      Dessamator wrote:No offense to FFWiki, but I really hope Portable infoboxes don't support this kind of construct because it will make infoboxes incredibly complex, and very hard to style. I looked at the infobox for half an hour and I'm still confused. From a simple count, there seem to be 20 infoboxes in that small space. No wonder Wikia stopped working on it. 

      I would suggest breaking up that information.

      So? If your wiki doesn't want to use infobox structure like that, you don't have to. That's really a pointless argument to use against them, "oh I didn't understand it because I found it complicated, therefore I hope Wikia never helps you solve your problem! Hah!" What I'm asking for is if Staff can provide a solution to my problem, not for someone to lecture me as to how to do things differently - and there are very specific reasons we structured the infoboxes like that, btw.

      If what I'm asking for is for nested infoboxes, then I'll make that proposal instead: can Wikia implement nested infoboxes?

      I've been working with FFWiki for the last few days on Lua related issues. I recognize how complex their Infoboxes are, and I agree that the complexity will make it very very difficult to be portable with PIBs current feature set. And, in the longer term, there might be compelling reasons to break those up into more digestible chunks. Nested Infoboxes will most likely never be portable, because they'll choke on mobile and don't render well (in general). However, I don't think Dessamator intended for that to come off as rude as it was interpreted.

      I think, most likely, that Sebastian (the Wikia engineer from Poznań) saw the complexity as a learning opportunity for how complex they need to be and ran afoul of how limited PIBs are now. I also believe that he's still searching for solutions on how to make it work (in the long and short term), and hasn't just abandoned you. 

        Loading editor
    • I confess I kind of freaked out, because thinking about how difficult it will be to make our content portable is stressful as it is, so my bad there. >.<

        Loading editor
    • Indeed, as FishTank notes, my concern was about the complexity of the infoboxes themselves. One comment I often see in Community central is that people are afraid to break the templates they created, so it is worth evaluating whether all of the current functionality of an infobox is actually worth keeping.

      Lots of tabs can be actually very confusing for readers, and even the editors themselves as few will actually know where the information is stored or how to correctly change that information.

        Loading editor
    • To someone outside of the wiki, they may perceive it as confusing for readers or editors - but someone playing the game at the time will know which tab they want to access. It's designed so they can access the specific information for the encounter of the enemy in the version of the game they are playing. Editors, likewise, do not find these templates difficult to understand - not much more difficult than any other template.

        Loading editor
    • Mira Laime wrote:
      At some point, we'll also have to admit to ourselves that if we continue to add more things that you can do with a portable infobox, just because they are currently done on desktop, we'll end up with infoboxes that are once agan not really suitable for mobile

      You're designing the old way, where everything has to be the same. Point of HTML5 is to drop down gracefully. Something don't work or is too complex to show in a given format, then show it another format.Tabbed boxes should actually be a plus for mobile, since they combine long content making use of full width and less height.

      But...the whole design of the XML is kinda disappointing. Gallery is the first tag that's truely modeled after it's purpose, not it's display format. Extensibility is prohitbited and "data" is just as bad as "thing". XML is supposed to be human readable (writeable but do a few 100, and you'll beg to differ), and havin generic "things" again, instead of <character> or <actor>...If you'd base everything on an attribute and let people make up tags, reserving a few for future use and prohibiting ones that are obviously dangerous (script for example) or clashing with real markup, things would become so much more readable.

        Loading editor
    • Lytora wrote:
      Mira Laime wrote:
      At some point, we'll also have to admit to ourselves that if we continue to add more things that you can do with a portable infobox, just because they are currently done on desktop, we'll end up with infoboxes that are once agan not really suitable for mobile
      You're designing the old way, where everything has to be the same. Point of HTML5 is to drop down gracefully. Something don't work or is too complex to show in a given format, then show it another format.Tabbed boxes should actually be a plus for mobile, since they combine long content making use of full width and less height.

      But...the whole design of the XML is kinda disappointing. Gallery is the first tag that's truely modeled after it's purpose, not it's display format. Extensibility is prohitbited and "data" is just as bad as "thing". XML is supposed to be human readable (writeable but do a few 100, and you'll beg to differ), and havin generic "things" again, instead of <character> or <actor>...If you'd base everything on an attribute and let people make up tags, reserving a few for future use and prohibiting ones that are obviously dangerous (script for example) or clashing with real markup, things would become so much more readable.

      I'm not sure where to start with this. Extensibility is not really possible with Tag extension functions, because of how the parser must work. It's not really parsing XML as markup, but loading it as subroutines in a function. Also, extensibility if allowed would be the quickest way to defeat the purpose of portability. Step 1 is ensuring decent rendering on most platforms. Step 2 is going to be significant separation of presentation and content. As far as articles go, PIBs are used exactly the same way with no change in wikitext. However, if you have an Infobox with "a few hundred" parameters, there's no way it's going to be portable anyway.

        Loading editor
    • FishTank wrote:

      However, if you have an Infobox with "a few hundred" parameters, there's no way it's going to be portable anyway.

      And this is my biggest problem with the project so far. Editors should not be forced to limit the information they give to readers. As someone who works on gaming wikis, I can tell you the amount of data that will end up being contained for users gets very high, and even if 90% of users only need to know 50% of it at a given time, that's still 10% of potentially a million monthly visitors who do benefit from a wiki containing the data as opposed to having to hack the game to find it themselves (which I've done to work on enemy pages before, btw). I don't see how it is reasonable to force editors to compromise so heavily to the point where we're actually limiting the data we include. Even if the "hundreds of parameters" as detailed was split, it'd still be on the page, how does it being on the infobox or not make any difference? And how does moving it to a table anywhere help at all, as opposed to making it worse by not giving it the advantages PIs give? Infoboxes already collapse on mobile when they get too big, anyway, I don't see the problem at all.

      I also want to raise the question, which I don't think has been answered (correct me if I'm wrong), about how we know what is and isn't portable. Forgive me, but I question what mobile devices people are using where the loading is that slow, and the screen is that small, that we cannot possibly display that kind of structure for smaller devices. I know that my phone isn't that great, and its screen relatively small, yet it can load pages with many more parameters in less than about 4 seconds and display them just fine when I view it in the desktop version. Now I admit this is anecdotal evidence, but I do mean to question: is it really this hard to make things portable that users should be faced with three choices; harm desktop users, harm mobile users, or limit the information you give to users?

      I know we all mean well, wanting mobile users to benefit from our site as well as desktop users, and I'm not trying to obstruct that at all - I, too, want mobile users to benefit from our site like desktop users can. But I don't want them to benefit at the expense of learning less from the site. I don't want to split the site into different pieces and force readers on both devices to collect them all to learn what they want, or to just leave parts out.

      I don't get what's so unreasonable about not wanting to choose between shafting desktop users and shafting mobile users, when the project should be about making a wiki work well for both.

        Loading editor
    • The issue is that most users don't really possess the experience or data to prove that their humongous infoboxes and pages are really getting read. But this is a well researched field of usability.

      To put it in perspective, suppose there are books with 50000 pages full of infoboxes and other content put together in a small space, how likely are people to be able to consume that knowledge or understand it?

      You don't have to take my word for it and can research it yourself:

      How content is added, placed and organized has a lot of impact on how likely it is that people will read it. Editors may want to add cool little features, but there is a good chance that nobody (except them) is reading those huge infoboxes with so many collapsed sections and optional data in tabbers.

      Here's an extract from one article that will explain it better than I ever will:

      Avoid visual clutter: redundant links, irrelevant images, and meaningless typography flourishes slow users down. (Note that meaningful links, images, and typography are valuable design elements; it is only when overused that these backfire and actually impair usability.) - http://www.nngroup.com/articles/minimize-cognitive-load/

      Ultimately, it is up to the community. If they feel the need to have  many "features" and so much content in a small space, they can keep the old infoboxes, and design it anyway they want.

        Loading editor
    • Thanks for the response. I will try and justify myself:

      To put it in perspective, suppose there are books with 50000 pages full of infoboxes and other content put together in a small space, how likely are people to be able to consume that knowledge or understand it?

      Avoid visual clutter: redundant links, irrelevant images, and meaningless typography flourishes slow users down.

      We're not thinking in terms of a simple book here, we're thinking in terms of game guides. This is in Japanese but should give perspective. Guide books are very different, and we actually have included more data found within the game than a lot of these guide books.

      As I said, even if not every reader understands it, that's no reason not to include the data at all. Not everyone reading a boss page needs to know how much its Magic Defense stat is, but many others will want to know. Not everyone needs to know that it is immune to Blind, but many others will know that it is and won't cast that spell against the boss. In fact, even in cases where we list a boss' immunity to a spell that the party can't have yet, that's still important for anyone using ROM hacks - and believe me, there are a lot of ROM hacks of the games. There is a lot of data here, and it's all useful.

      How content is added, placed and organized has a lot of impact on how likely it is that people will read it. Editors may want to add cool little features, but there is a good chance that nobody (except them) is reading those huge infoboxes with so many collapsed sections and optional data in tabbers.

      That's because not every reader needs the collapsed sections and optional data in tabbers, that's the whole point. By making the data optional, it allows users to select which is more helpful to them, as opposed to splitting hairs by forcing them to scroll through the ones they don't need to know.

      Ultimately, it is up to the community. If they feel the need to have many "features" and so much content in a small space, they can keep the old infoboxes, and design it anyway they want.

      This doesn't solve the problem at all. I know what you mean, you don't want editors to just keep demanding features that reach the point where they don't help people. But my problem here is that this way of dealing with it doesn't help; it doesn't attempt to understand why the features are wanted, why users would want the content in such a small space, and until those things are understood, it's impossible for users to provide any helpful alternatives to the problem here.

        Loading editor
    • Well, the way I see it, some wikis are doing something like [1]. Some wikis want a wiki article to be regular article page, a guide book, a gallery, and a summary, a small database table.

      All of the above is still expected to render accurately, quickly and be presentable, which is not feasible. In reality mobile devices are laptops,  tablets, google glasses, apple watch, android wear, smartphones, feature phones, GPS, dual screen devices, nintendo, and more . Can wiki contributors design content that will consistently render properly in all devices without removing anything?

      Chances are that they can't. If for example, a mobile device reads data using TTS, how will it read a deeply nested infobox?

      As I said, even if not every reader understands it, that's no reason not to include the data at all.

      A regular article is meant to be a brief summary of the subject matter, with references to related in-depth content (e.g. appendixes) in separate pages. Complicated infoboxes violate very basic usability concepts, as shown by those research articles.

      Infoboxes are meant to be short summaries of information. Perhaps another tool might be necessary to cater for other use-cases or wanted features.

        Loading editor
    • I disagree with you that it is not feasible to contain the above. We want a wiki article to contain the same amount of information that a guide book's page would have - of course, the problem is, we have to contain even more because a) we include more strategies, b) we include multiple different releases of the same game on different platforms, and c) we include data that some guide books leave out that has been obtained by hacking the game.

      I still personally don't see how this is an unreasonable ask. What I do see as unreasonable, however, is asking someone to go through several thousand pages to split them up drastically, and then ask readers to collect data from every single one of those pages. I see we disagree on what infoboxes are meant to be. I see them as a convenient way to display data right alongside the article.

      I can think of maybe one or two ways in which we can cut down on the use of tabs, but they will all be incredibly difficult to pull off, and even then, I'll likely run into millions more problems doing that.

      This is a very complicated problem. And it's not like we just bloat infoboxes with useless data because we hate our readers, we include as much data as possible because we want the pages to be, like you said, comprehensible guide books. It's not like we're doing this because we don't care about our users, it's because we want our pages to be as helpful to users as possible. I've had conversations with readers before, seen reviews of the wiki's app, etc, and I don't recall any complaints that the enemy pages - on desktop - were ever difficult to use, which is why we've never had to change anything before. I'm not sure how much your data applies to this situation - it isn't about how much of the data is being read, it's how many people went onto the pages and didn't find what they were looking for at all. Because I really don't think it's that confusing.

      Finally, a few issues with not using infoboxes:

      1. We'll need tabbers regardless of whether we use infoboxes or not. And either way, tabbers do not work on mobile. Simply moving the data somewhere else does not make the page any more portable, that's not a good solution.
      2. Data tables are no more portable than non-portable infoboxes at the moment. We don't solve the problem, we just move it to the side.
      3. This isn't a decision one editor can make and magic across the whole site. There has to be an entire community discussion involved. And there have to be edits to thousands of pages.
        Loading editor
    • I think we've gone somewhat off-topic, so perhaps another thread should be created to discuss how to make complex content portable.

      What I do see as unreasonable, however, is asking someone to go through several thousand pages to split them up drastically, and then ask readers to collect data from every single one of those pages.

      Yes, that is the main issue. People randomly creating content without any planning or good practices to make the content re-usable. MediaWiki was designed at a time when webpages were very simple, and without any good way to share content between pages or a simple user-facing database. This was mainly because most people are not technically inclined, and don't understand database or web-design processes to make content re-usable, e.g. normalization.

      Something that Wikia and WMF will probably be singing for many years is that you separate data from presentation.  It is possible to design tools to collect information from several data stores in Germany, Canada, and China, and put it all together in a way that nobody knows it happened. You just need the right tools to query the "structured data"  and present it properly.

      Ultimately, no matter how much users want to delay this transition or how painful it is deemed, it will happen. Those that aren't willing to adapt will simply be left with archaic tools and problematic pages and infoboxes. This is something that tabbing will not fix.

        Loading editor
    • Structured data is indeed something I'm looking forward to. I agree with most of what you said, but I still disagree with you that the tools in place are "problematic" and not presented properly (beacuse based on the user feedback I've received, and my own experiences before I joined, there have been no difficulties navigating them), and do not believe you have looked into this use case or the reasons behind it. Like you said, we are going more offtopic, so I will leave it at that.

        Loading editor
    • Hey guys I used the script above to add Tabs to my Info Box Template to change the image being displayed, but the way I have it written I would have to edit the template to add the images which is redundant. But I believe that if I replace [[File:Example.png]]  with source="image1" (image2, image3...etc) for each Tab that I it would all work out in my Favor but it doesn't seem than simple to plug and play so what do you suggest I do? Thanks in Advanced.

        Loading editor
    • Can you post a link to the template with which you are having trouble? I don't quite understand what you are asking.

        Loading editor
    • I actually found a solution with the help of another user on this thread http://warframe.wikia.com/wiki/Thread:844993

        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

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.