FANDOM


  • Ducksoup
    Ducksoup closed this thread because:
    Grown too long - follow the discussion in our new thread!
    04:32, October 14, 2015

    Edit two:  this thread has been closed, and a new one has been opened!

    Edit 5/21: here's a Help page. It's a bit complex but it covers all the bases. As opposed to "regular" help pages, please feel free to edit this one as you see fit - it's a work in progress.

    Infobox templates are among the most-used on Wikia. They’re nearly ubiquitous, and for good reason: they're easy to understand and pack a lot of information into a small area. They “feel” quite natural on Wikia.

    The problem? They translate very poorly to mobile experiences. We have a "workaround" in place right now for our mobile web experience, but some just break. Some others work only on certain devices. And the future is mobile - check out this graph on Wikia's traffic or go check it out for yourself on Quantcast. Mobile devices are the internet's growth path, and there's no reason to believe that will come to an end.

    That's why we're releasing this new early beta markup for infoboxes. This is going to be a collaborative process; we need to get mobile right and we need to do it with your help. Feature requests, markup suggestions, tag changes, anything - let us know here. We may not implement them all, but we will read them all.

    This is a first (and baby) step in a long transition towards mobile-friendly content. It'll be a long trip, but Wikia's actually stoked to start giving y'all the tools to get there, and we'll be around to help every step of the way.

    I've uploaded several examples of the new markup to communitytest.wikia.com:

    Kratos

    Beatrix Kiddo

    Battle of Arrakeen

    Cthulhu

    Phoenix Ikki

    I want to stress again: these code changes are in early beta. They will continue to evolve with your input. That's why we're putting these out there early - we want to hear what you think should be included.

    Please use the comments section below to share your thoughts and ideas!

      Loading editor
    • Hmm. Hi duck soup, from what I got, it's mobile devices that are having the problem. May I propose a Re-Skin fro the mobile devices? Besides, the mobile was kinda irritating to many people.

      Thanks! E-11 23:41, May 18, 2015 (UTC)

        Loading editor
    • Mobile devices should be able to use the Oasis (default Wikia) skin. Isn't that the point of the new breakpoint changes? Incidentally, this new infobox looks drastically different to the old ones on Oasis, but pretty much the same as always on mobile. If infoboxes were broken on mobile then quite frankly the wikias concerned must have been using some pretty funky code.

      Where it says "check out this data on Wikia's traffic", was there supposed to be a link?

        Loading editor
    • Sandtrooper: that's actually something we're working on, too! Unfortunately, the current underlying code structure for infoboxes - including and especially how wildly it varies from wikia to wikia - means that it's neigh-impossible to port the infoboxes in their current form.

      Digifiend: First, yes, I was supposed to post a link there. My fault - I'll get it tomorrow. To your other point: I think adding a "View as Desktop" button to the mobile experience would be great, but that wouldn't take the place of having a native mobile solution. 

        Loading editor
    • Thanks duck. I can see infoboxs messing up when they are very complicated, like ones with tabs, or complex patterns. Thanks for all the work. Also, for the person who made the pages need this and that on the right, need kudos because that'll get TONS of pages all clean. Thanks again!

      E-11 01:51, May 19, 2015 (UTC)

        Loading editor
    • 452

      Ducksoup wrote:

      The problem? They translate very poorly to mobile experiences.
      Please expand upon what the problem actually is, and post screenshots.

      When I look at an article on a tablet or smaller, I expect the first thing I see to be to be the infobox: a two column table of brief information. What do you want to change about this?

      Edit
      For the record, I have received no response to this question.
        Loading editor
    • Everytime I browse the wiki I work at, The Elder Scrolls Wiki, on the mobile app infoboxes are fine. Ours' are a bit different but I see no problem with them messing up, the render just the way they should on mobile.

        Loading editor
    • Frankly i think all these updates are going too far and fast.

        Loading editor
    • You need to highlight this thread. I only got to it by chance, but it's something that others should see.

        Loading editor
    • If we are only using these new templates for mobile they would be fine. I am not ok with using these for laptop's. They look too narrow and long, as well as just not seeming right.

        Loading editor
    • I must say, I'm not a huge fan of these new infoboxes. I don't like being forced to make the infobox in a certain way by the limited tags, especially when that way isn't the standard 2 column infobox. I enjoy making an infobox from scratch so I don't have to worry about Wikia's specificities getting in the way of my design, which can't be done if we're forced to use these tags. What might be better is if we just have to wrap our infobox in tags, say <infobox> tags, and for Wikia to recognise that whatever is in between those tags should be displayed fully with full CSS so the infoboxes work. A style guide can be created somewhere on Wikia, probably at Help:Infobox, which gives a recommended range of widths for best mobile results, or there could even be a way for the tags surrounding the infobox to add a class only in mobile mode so the width can be changed to 100% when one is on a mobile device, but would be at whatever looks good on a desktop page otherwise. Said class would also remove the margins from the outermost element so the infobox sits well in mobile (note that the outermost element is not always the table. For example, the infobox on CCSW has a div with a border which frames the two tables within the infobox as the outermost element). What do you think of that as a solution? It also has the added advantage that very little change needs to be made to current templates for it to work.

        Loading editor
    • Hey Imamadmad and AwesomeOrange89. Thank you for the feedback. This is exactly the info we would like to learn. Current markup is just a framework that allows us to separate view from the display and by doing that display it correctly on any device. We know there is still a lot work to be done to make this feature full mature, that is why we need your help :)

      Would you prefer the new infoboxes if they were more tabular with label on the left and data on the right?

      What are the main limitation of the current markup? We know it's very minimalistic, that's why your feedback is so valuable to us.

      I'll talk with our engineering team about your idea Imamadmad!

        Loading editor
    • Those new infoboxes are ugly. You guys should put more effort into finding a way for current normal infoboxes to continue looking normal AND working in mobile devices.

      What about these: http://en.wikipedia.org/wiki/Template:Infobox_ship_class_overview

      There must be a way to keep infoboxes looking they way they do and being viewable on all devices.

      The ones proposed here are terrible. This is what normal infoboxes should look like.

        Loading editor
    • I honestly think these infoboxes are fine. However, what are the usabiliy issues regrading infoboxes on mobile? Making them 100% width made them look fine.

        Loading editor
    • Shareif wrote: Hey Imamadmad and AwesomeOrange89. Thank you for the feedback. This is exactly the info we would like to learn. Current markup is just a framework that allows us to separate view from the display and by doing that display it correctly on any device. We know there is still a lot work to be done to make this feature full mature, that is why we need your help :)

      Would you prefer the new infoboxes if they were more tabular with label on the left and data on the right?

      What are the main limitation of the current markup? We know it's very minimalistic, that's why your feedback is so valuable to us.

      I'll talk with our engineering team about your idea Imamadmad!

      If they were more tabular, I would give one a try and see if I can either replicate or improve an existing infobox with the new tags via CSS.

      One other thing to mention is that taking the infoboxes away from regular wiki markup may scare some newer users away from trying to edit the default ones as the compactness of the information combined with the more involved markup makes it look "scarier". On the other hand, it may be easier for people coming from an HTML background, or even just a regular coding background, to understand the infoboxes with the tags rather than the wiki markup.

      Another point is that having the tags is relatively restrictive. For example, the levels infobox I made for CCSW, which can be seen on a page here, has three cells on the same row in the bottom two rows to demonstrate the previous, current, and next levels. That could be achieved using the regular infobox format because there was no restriction on what needed to ake up the infobox, so a second table could be appended to the first with 3 columns instead of two and merged with a clever bit of CSS. There is no equivalent infobox tag which could do that in the original proposal. While you might say "well, we could add one", what about tags to solve the problems encountered by the next user? They won't have as many tools to manipulate the infobox to their prefered design/design which works best in the context of their wiki. By restricting the amount of possible elements that can be used to create infoboxes, you are giving users less tools to work with to solve their unique problems, which I think would be a great loss.

      I still think, on balance, that it would be preferable to find a solution which works with current wiki markup rather than having to use these new tags. However, my mind is still open and, with enough evidence, could be convinced that this new system is superior. I still need to see that evidence though.

        Loading editor
    • 452

      And just to clarify: this is what normal infoboxes should look like in the wikiamobile skin.

      As I've already asked - what is the problem here?

      Edit
      For the record, I have received no response to this question.
        Loading editor
    • Umm I thought WIkia said they wouldn't insert adverts into the content space?

        Loading editor
    • 452

      Wait, what? Where are they doing this now?

        Loading editor
    • I saw one in the link you posted - in Wikia Mobile.

        Loading editor
    • Can you clarify how these infoboxes will be implemented

      1. Will it only affect communities that use (LUA?) templates with the <infobox> "magicword"?
      2. Or will it be sitewide like Breakpoints and Typography and communities need to start thinking how to change their infoboxes so it avoids a repeat of the problematic Breakpoints and Typography upgrade?
        Loading editor
    • Ducksoup wrote:

      That's why we're releasing this new early beta markup for infoboxes. This is going to be a collaborative process; we need to get mobile right and we need to do it with your help. Feature requests, markup suggestions, tag changes, anything - let us know here. We may not implement them all, but we will read them all.

      This is a first (and baby) step in a long transition towards mobile-friendly content. It'll be a long trip, but Wikia's actually stoked to start giving y'all the tools to get there, and we'll be around to help every step of the way.

      Please use the comments section below to share your thoughts and ideas!

      Well, it is fine to have a markup, but I think the one you currently have is far too complex for a regular wikian. Rather than keeping this complicated soup of tags and curly brackets, you can use LUA. The infoboxbuilder would create the appropriate markup, and transclude it in the page once it is saved. This level of abstraction would facilitate infobox creation and most users would be none the wiser. 

      Personally, since the introduction of LUA, I've always believed wikia should deprecate and remove all parserfunctions, reduce the emphasis on using tags and let Lua do the heavy-lifting. In fact, I've started hunting down and removing all those abandonware wikitext-parserfunction-html templates. Although unfortunately some templates created by wikia bot can't be deleted.

        Loading editor
    • 452

      Dessamator wrote:

      Although unfortunately some templates created by wikia bot can't be deleted.

      Could you please name an example?

        Loading editor
    • 452 wrote:

      Dessamator wrote:

      Although unfortunately some templates created by wikia bot can't be deleted.

      Could you please name an example?

      Hmm, I must have confused the templates. One of the infobox templates automatically imported by wikia-bot seemed to have made a come-back, when in fact it was another with a similar name. Thanks for making me realize that.

      'The hunt shall continue.'

      By the way, do you happen to know of anyway of finding/listing pages with parserfunctions? I'm trying to erradicate those annoying switch templates.

        Loading editor
    • 452

      When I'm eradicating something specific, I always download a database dump and search through it, or export a subset of pages, such as all templates.

        Loading editor
    • 452 wrote:
      When I'm eradicating something specific, I always download a database dump and search through it, or export a subset of pages, such as all templates.

      That's a good idea. Thanks!

        Loading editor
    • The Elder scrolls Wiki is open to helping with this, but besides wanting to make sure the community is on board with helping I have a concern.

      From what I have both seen and heard, our templates work fine on the mobile. Not only that, but we have put a bit of work into making sure they not only work, but are adapted to each games needs. By changing the templates, I am worried that we would see negatives. I understand we have a growing mobile population, but our PC editors would be effected to by a template change. If something like this was done, we would have to take into account what others felt about these changes and how it effects the wikis look and layout.

        Loading editor
    • Hey all,

      I just want you to know that I'm reading each of these and doing my best to respond at your "home" wikias, where I've started reaching out individually. Please feel free to keep this thread alive, though, so folks like User:Shareif can respond, too!

        Loading editor
    • Shareif wrote:

      Would you prefer the new infoboxes if they were more tabular with label on the left and data on the right?

      I think you could be leading into something with the titles at the top. Let's see after you guys develop it a little bit more. I am not opposed to it at this point.

        Loading editor
    • So using these proposed tags will create the same infobox basically, no variation (ie movement of parameter titles, section headers, etc)? How is styling applied in these examples? Is it strictly CSS?

      I've always liked the two column approach as it saves space. One column can be nearly double the size of the infobox downward (which isn't a bad thing only if the page is longer than the infobox itself).

      I don't understand LUA still (yes it's great to use but it makes no sense to me) so I hope it's not required for the new templates as I don't want to rely on someone else to do all the coding I've always done. I've seen some of the guides on dev, but they don't seem straightforward to me.

        Loading editor
    • Thank you all for amazing feedback!

      The main idea behind the new infoboxes is to create the set of building blocks that all of us can use to build the infoboxes we like. It's of course like with any other building blocks, you pick the order yourself. You can put the image-block on top, then the data-block with description under it, then title-block and then any other blocks you like and have available.

      We know that right now the list of blocks is limited and they are not as easy to use as we would like them to be, that is why we need communities to work with us on making it better!

      We want to make the proces of building infoboxes as simple as possibile. For example the new markup automatically hides empty values. No more 
      {{#if: {{{value1|}}} | {{{value1}}} | }}
       in your infobox markup. Unless you specify a default value the rows with no data will not be displayed. The same applies to sections. I know it's just a baby step but we believe that by tackling use case after use case we can create great and slimple tool for us all, howver we need you help and experteese to successed.

      New infoboxes also intruduce the default theming using wikia's theme which hopefully will save work on new communities. We know it cannot compeete with customized styles, but it's just a default. CSS is still an option. Bonus is that the HTML markup is unified, so it will be easier to take the custom styles from other wikis you like and use then on yours.

      DEmersonJMFMGMRE: We understand the need for space, especially on the wikis that have a policy of putting images only on the right side of the page (it's easy to have infobox taller then the rest of the page). That is why tabular infobox is on our roadmap along with other infobox views that adress this issue. I hope you will like them. Stay tuned.

      TableWizDessamatorDEmersonJMFM: The new infoboxes do not require you to know LUA, however it's possible to invoke LUA modules within the new infoboxes.

      TableWiz: Good questions. This feature is not connected with breakpoints and typography changes. It's in the beta phase, this means it's optional and for volunteers only. We want to test it, get the best out of it and make it useful for all of us. We offer help with migration and you can start using it on your wikia right away, but we are not enforcing anything.

      Dessamator: Great initiative! I think we share the same goal: remove the curly brackets and simplify the markup. Let us know if we can help you somehow!

        Loading editor
    • Shareif wrote:

      It's in the beta phase, this means it's optional and for volunteers only. We want to test it, get the best out of it and make it useful for all of us. We offer help with migration and you can start using it on your wikia right away, but we are not enforcing anything.

      What would I need to do in order to test one of the beta infoboxes?

        Loading editor
    • Hi User:Ripto22475. Thanks for volunteering!

      Take a look at the examples User:Ducksoup gave in his post. Play with them and try using this markup on your wiki or test wiki. Or just let us know where whould you like to use it and how, and we will guide/help you.

        Loading editor
    • Ah okay, so I'm allowed to copy and paste the templates in Ducksoup's example? I should be able to handle that! Thank you.

        Loading editor
    • Shareif wrote:
      Thank you all for amazing feedback!

      The main idea behind the new infoboxes is to create the set of building blocks that all of us can use to build the infoboxes we like. 

      Dessamator: Great initiative! I think we share the same goal: remove the curly brackets and simplify the markup. Let us know if we can help you somehow!

      Is there any documentation available for us to review the markup?

      It is a bit like shooting in the dark if we simply copy the existing templates and change it, but if I have the documentation I can quickly create at least one infobox template. Also from what I see there currently doesn't seem to be a way to create two columns, the comparison is the only tag that somewhat emulates this behaviour.

      What I meant with Lua, is that the existing Infobox builder could be used to automatically generate these new tags. Most of the infobox templates I use were migrated to lua, so it would be simple to generate some interface (or middleware) to create these tags automatically. 

        Loading editor
    • Documentation should be available soon. We'll share it as soon as we finish it. I know it's a bit inconvenient right now.

      Currently infobox builder is not copatible with the new approach. But this is one of the directions we are considering.

        Loading editor
    • I've taken a look at the examples and I have to say I'm fairly enthusiastic about this. Using tags like <title><image><label><data> are so much simpler than having to repeat conditional functions to check if something is empty.

      I have a question: if I want to prepend or append something to the data, how am I supposed to do that? For example:

      <data source="age">
        <label>Age</label>
      </data>

      I want to add " years" to the data. Using the old wiki markup, I would do something like this:

      {{#if:{{{age|}}}|{{{age|}}} years}}
        Loading editor
    • Thanks Ohmystars!

      The current super simple approach allows doing it by hacking the <default> tag:

       <data>
         <label>Age</label>
         <default>{{#if:{{{age|}}}|{{{age|}}} years}}</>
       </data>
      

      Of course this is not a recommended approach, but so far the only possible one. Our engineers are thinking about the markup that would solve this case, but also simple simple and sleek.

      Maybe you could help us? Do you (any of you) have any suggestions on markup that would handle the situation above?

        Loading editor
    • Okay, this is beginning to sound a little better (such as automatically hiding parameters that aren't filled in, no conditions). How would you set a default though or something like Ohmystars just mentioned?

      Using the default theming doesn't excite me or using CSS. Our theme is red and using shades of red on a white background is very difficult (avoiding pinkish-red). Plus multiple character infoboxes have different colors. Styling directly in the template is something I would need. I also think you should distinguish more between the parameter name and the entries (different font size, increased indention).

      I understand (and approve) of simplification but the new code has to do everything the existing code already does. Would tabber still work for images? At present (I know this is a work in progress) but the above examples seem pretty generic (as some are, but others are more complex).

      Do these tags need to be activated if we wish to test them? Will they affect existing infoboxes?

        Loading editor
    • Hey DEmersonJMFM,

      The new markup is available everywhere. You can start using tags wherever you like and it's only up to us if you would like to affect existing infoboxes or not.

      The deafult are handled using <default> tag. For example:

      <data source="allegiances">
       <label>Allegiances</label>
       <default>independent</default>
      </data>
      

      So the <data> tag is looking for "allegiances" property in the template and if there no such property invoked or it's invoked empty then it will render the row Allegiances with value 'independent' as this character apparently is not allied with anyone in particular.

      <default> tag can be used also with <image> and <title> tags.

      Tabber is not supported in the current version, but we know it's a common case for more complexed infoboxes. The same goes with collapsible sections.

        Loading editor
    • Shareif,

      I've tried it and that "hack" doesn't work (nothing is appended). I already expected that, because the default value will only display if the data is empty. If for example age is filled in, then the entire default value (including the part that appends "years") is overwritten with the data.

      I suggest the following markup:

        <data source="age">
          <label>Age</label>
          <field>{{{age|}}} years</field>
        </data>
      

      <field> can also be named <content> or whatever is suitable. I suggest that by default this <field> tag is optional and should only be added if the user wants to have a custom way to display the data. This way, not only can the user prepend or append the data, but also do something like this:

        <data source="gender">
          <label>Gender</label>
          <field>
           {{#switch: {{{gender|}}}
            | Male = ♂
            | Female = ♀
           }}
          </field>
        </data>
      
        Loading editor
    • Awesome! Great suggestion. I'll pass it to our engineering team.

      For the hack to work you have to remove the source="age" from <data> field.

        Loading editor
    • In w:c:dune:Template:Battle they have 2 columns of variables

      <comparison>
        <set><header>Combatants</header>
         <data source="side1"/>
         <data source="side2"/>
        </set>
       </comparison>
      

      Is it possible to use the left column for variable name? I have tried using <data><label> </label></data> but the template just ignores it.

        Loading editor
    • Oh no wonder! I just tested it and yes that works. I actually thought that you forgot to add source="age" haha.

      Well, my suggestion isn't really what you would call "simple simple and sleek". But at least this way any wiki with custom ways of display data output would all be able to implement this new infobox.

        Loading editor
    • I just made my first shell with the new markup. A couple more questions, where is the theme color coming from, headers in Theme Designer? I was expecting it to be red but was surprised to find it blue. Can the image be resized (default and what's inputted) and can a link other than the file page be added to the default?

      Edit: The size difference is huge: old infobox - new infobox. Additionally, in mobile preview the old infobox is not only shorter but better visually.

        Loading editor
    • TableWiz,

      The way I see it, what you want (and some users above who complain that it is "ugly") is essentially just a different styling of the way the data displays. There's no need to mess with <comparison> tags or other tags to accomplish that. Just use CSS to make the label float left and the data right. And maybe the Wikia team would even consider styling it that way by default if that's what the majority wants (I myself support that too). Some users here seem to be really missing the point. It's not about styling or how infoboxes look, but about simplifying the creation of infoboxes that would work on all devices. You can see it as some skeleton thing that people would eventually be able to dress differently but that has the same underlying bones in all wikis. At least, that's the impression I got. I'm fairly enthusiastic myself and see great potential in this. :)

        Loading editor
    • "It's not about styling or how infoboxes look, but about simplifying the creation of infoboxes that would work on all devices. You can see it as some skeleton thing that people would eventually be able to dress differently but that has the same underlying bones in all wikis."

      Yes it's about simplifying the "bones" of infoboxes but if doing so makes styling much more difficult that's a problem. Styling within the template is easier for me than creating a half dozen different looks by swimming through the CSS soup of selectors.
        Loading editor
    • Well, I replaced one of my infoboxes with it, and I guess it is fine. The main limitation of using tags is that unlike wiki-text when you get part of it wrong nothing will show up. This will make it incredibly hard to correct and debug these infoboxes if some vandal/ignorant user comes and makes a single change or even when creating it from scratch. It is always an all or nothing proposition, similar to designing modules. 

      The difference being that a Lua module will always give you exact feedback on what may be wrong while these tags give an unhelpful error message about validating xml. 

      That's the first thing that needs to be sorted out, either that or like I said, deploy them using lua as middleware.

        Loading editor
    • 452: Maybe I wasn't clear before - let's see if I can fix that.

      One of my Wikia coworkers - the clever one posting in this thread, in fact! - likes to say that "we should be able to display Wikia content on a washing machine". It's tongue-in-cheek, I take his point well: the breadth and depth of devices that we need to support is only growing.

      Right now, our approach is, essentially, to backfill mobile solutions as necessary. That's gone OK for a while - some infoboxes, especially ones that are more than two rows, don't fare so well - but it's certainly not a long-term strategy, especially for how quickly mobile traffic is starting to take off.

      We absolutely do not want to change the basic intent of Infoboxes. What we want to do is make sure we're ready for the next device/platform/washing machine that comes along, and the current structure to Infobox code doesn't allow us to do that.

        Loading editor
    • Dessamator: This is great feedback - thank you!

        Loading editor
    • It is too messy. Just make it back to normal. This is happening too fast.

        Loading editor
    • I don't like them, they lack diversity and personality.

      Our custom templates on Kamen Rider and Ranger Wiki we just made have a ton of info that is easy to read and have a style that is unique.

      Examples:

      I'm not comfortable with a singular uniform style, it robs what makes our wikis individual and doesn't have a personal touch we can be proud of.

      Update: Oh, its for Mobile devices! Sorry, didn't read all the way through ^_^'

        Loading editor
    • Well, looking at the source of the new templates, I much rather prefer the current way of writing a template better. It may be just because I am used to the current way, but the proposed new way's code seems a bit overwhelming compared to the current way of writing an infobox. The easiest part of the current way is that you're making a table to be implemented on several pages, not a whole new thing which looks oddly familiar to HTML (which I hated sometimes because of all the tags I had to open and close).

      I can also see that the infobox got a mobile-friendly style change, it doesn't look too bad, but I prefer how it looks now, it looks more professional in my opinion.

        Loading editor
    • yo vi una estoy acostrumbrada ala forma actual

        Loading editor
    • Aldo The Fox wrote:
      I don't like them, they lack diversity and personality.

      Our custom templates on Kamen Rider and Ranger Wiki we just made have a ton of info that is easy to read and have a style that is unique.

      Examples:

      I'm not comfortable with a singular uniform style, it robs what makes our wikis individual and doesn't have a personal touch we can be proud of.

      Update: Oh, its for Mobile devices! Sorry, didn't read all the way through ^_^'

      And I just noticed a problem. Take a look at Takeshi Hongo's page in the mobile skin... the tabber doesn't work! The new infoboxes won't fix that though.

        Loading editor
    • I've done some testing and have run in to some problems with CSS. Over on my test wiki, I have tried to recreate the infobox I made for BCW by using the new tags to replicate the infobox structure and by copying the CSS and changing the selectors from their original classes to their new tag equivalent. However, I have discovered that this doesn't work. Whatever the CSS says, nothing in the infobox changes, however if the tags are just listed as selectors by themselves (eg infobox {...} title {...} header {...} etc.), other parts of the page become significantly messed up (see here for image). This problem does not occur if the selectors are preceded by the parent element name "infobox" (eg infobox {...} infobox title {...} infobox header {...} etc.), but the infobox remains unchanged by any of this CSS. I could just be doing something really dumb with the selectors here, as I'm used to modifying CSS via classes rather than tags alone, but just in case I am right, there needs to be some fixes to allow custom CSS.

      For reference:

        Loading editor
    • At my stage of life ALL of my internet are *Desktop*, not even laptops anymore. My *mobile* is a gov't free-to-seniors phone which means it is no-frills and definitely no internet nor anything "smart" about it. Other than the free minutes…

      I may be a fossilizing dino, but I know I'm not alone on the net or Wikia.

        Loading editor
    • I have no reason to use any of this nonsensical infobox syntax, I code my infoboxes to include important data which requires use of complex code and conditional display of text. That is not going to be changing just because of this update.

      And how on earth do you plan on forcing some wiki's using SMW to use your pointless changes? I can think of the Narutopedia, which uses very complex infoboxes, and there is no way they can be converting their infoboxes to this useless syntax.

      Absolutely unnecessary and a waste of people's time. Infoboxes work perfectly fine in mobile, this syntax will only create bland pages which all look the same. The current syntax of using parserfunctions and other methods that everyone knows is perfectly fine, does not break on mobile and overall, Wikia should invest their time on something else than creating bland environments.

      I might be harsh, but these changes do nothing to improve people's experiences and only forces people to stop using a common syntax language that is far easier to understand and WILL show up errors.

        Loading editor
    • Using the same names as HTML tags <data>, <footer>, <header>, (the wrong but sometimes used anyway) <image>, <label>, and <title> could be asking for trouble. Best case scenario, the ambiguity mildly confuses editors who see these tags in code view. Worst case scenario, MediaWiki's sanitizer whitelists these tags in the future and robots nuke the planet.

      Different names, perhaps XML-style prefixes like <i:header> or <infobox:footer>, would eliminate ambiguity and avoid any namespace collisions down the line.

      As for the HTML output, I love that a comparison is rendered as a <table>, with each comparison set a <tr>, etc., constructing clear relationships between data values. I'd like to see better relationships with the label–data structures, such as <dt><dd> (within a <dl>, of course) instead of the current <h3><div>. Even better if the infobox has a way to accept or parse multiple data values for a label, and output them as multiple <dd> elements for a <dt>.

        Loading editor
    • Maybe I'm just an ignoramus, but what exactly is wrong with the mobile infoboxes?

        Loading editor
    • 452 wrote:

      And just to clarify: this is what normal infoboxes should look like in the wikiamobile skin.

      As I've already asked - what is the problem here?

      Edit
      For the record, I have received no response to this question.

      I would like to reiterate 452's statement - Could we have an answer for this?

      Shyguy-emoticon.gifJoey (talk)

        Loading editor
    • Imamadmad wrote:

      I've done some testing and have run in to some problems with CSS. Over on my test wiki (...)

      If you prefix your styles with .portable-infobox class, the scope of the changes will be limited to the new infobox styling only. For example to style the headings you'd go along the lines of:

      .portable-infobox h3 {
         width:100%;
         background-color:#000000;
         color:#E8E5D4;
         margin:0;
         padding: 5px;
         border-radius:5px;
         box-shadow: 0 0 10px #DECFAD inset;
         font-family:Oswald,Arial,sans-serif;
         font-size:15pt;
         line-height:2em;
         text-transform:uppercase;
      }
      

      Thank you for trying this out and please let us know if you need more information/assistance!

        Loading editor
    • It's going to take me a month to work out what the hell we're doing about infoboxes over at PD wiki - but in the meantime, just thanks for posting that graph of mobile vs desktop users. That's enlightening.

        Loading editor
    • Jemjar wrote: It's going to take me a month to work out what the hell we're doing about infoboxes over at PD wiki - but in the meantime, just thanks for posting that graph of mobile vs desktop users. That's enlightening.

      Just to point out: the graph proves nothing. Just because a graph showcases an increase in mobile traffic doesn't then mean it's up to Wikia to start making a bunch of pointless changes. As showcased above, everyone's current infoboxes work just fine in mobile, so there's nothing to change.

        Loading editor
    • SuperSajuuk wrote:

      Jemjar wrote: It's going to take me a month to work out what the hell we're doing about infoboxes over at PD wiki - but in the meantime, just thanks for posting that graph of mobile vs desktop users. That's enlightening.

      Just to point out: the graph proves nothing. Just because a graph showcases an increase in mobile traffic doesn't then mean it's up to Wikia to start making a bunch of pointless changes. As showcased above, everyone's current infoboxes work just fine in mobile, so there's nothing to change.

      Of course it doesn't prove anything. It's interesting though. Between the presence of that graph and the fact I received a notification of the existence of this thread, Wikia has instantly improved on two of the major reasons for complaints on the Desktop XL switch.

      Interestingly though, while it still "proves nothing", your choice of language in describing the changes as "pointless" says a lot about your opinion and not a lot about the changes being proposed. That's fair enough, honestly I don't really know enough to be aware of whether these infobox changes will be a useful step forward or an unnecessary layer of complexity. I don't really have the time to sit and work it out at the moment either.

        Loading editor
    • Interesting... However, it seems even more restrictive than the lua template! I understand you guys want to make a better mobile experience, but please recall your desktop users as well! :) My main concern is that this doesn't seem to support a 2 column layout even on desktop (you could just make the 2 columns "convert" to the title above on mobile only), and just like the lua template, it seems that I can't define custom classes on specific cells / rows. Also, unlike the lua template, it doesn't seem to even be possible to set a class for the infobox to use (where each cell gets a class based on the infobox's class name). I like the general idea though (since infoboxes are confusing yet common, this could help make it "simpler" for new users), but you need to make it as fluid as possible! Make sure we can use all the normal html atrributes we already can (title="", class="", id="", etc [I'd recommend even style="", as while it's bad, CSS class confuse non-developers / internet pros]), and consider odd usages!

      However, I must support the above questions; what exactly was broken in mobile, and why couldn't it just be fixed by updating how the current infobox system works? The only real difference I seem to see is have a left/right side data cells (which can already be done; and notice how rarely it's done, so not really all that helpful), and the big difference is having the header cells one "row" above the content; this could surely be done automatically?

      Also as mentioned above, any infobox that currently breaks on mobile would already be a mess... and odds are those communities either don't care, or don't know about the issue, and as such wouldn't really implement this, and thus this wouldn't actually fix the "mobile" issue (which, again, we all would love to hear specific about).

      Anyways, keep up the good work, and please remember not everyone uses mobile (and that not all handheld devices use the mobile skin), and thank you very much for putting this out there in such a community-involved way! It's always appreciated! Fewfre 🔎 K14:34 Fri, 22 May 2015

      Edit: I personally would prefer a "navboxbuilder" more than yet another new way to make infoboxes; navboxes can be very complex, and seem to be ones of the more common annoyances in mobile! It would be great if you made a navbox builder similar to how wikipedia / the layton wikia do it, and then navboxes could use bullet point lists in them right out of the box, which also gives you more control how they would be displayed on mobile. I already use the layton "branch" of the navbox on many of my wikis, but considering how complex the code is (and how limited the default one is), navboxes really need your love more than infoboxes!

        Loading editor
    • While I agree that this change is good in some respects, I have to say I've encountered a few concerns with the new layout. Starting with design:

      They’re nearly ubiquitous, and for good reason: they're easy to understand and pack a lot of information into a small area.
      ~ Ducksoup


      The new layout increases the size tremendously, which would be a nightmare for sites like w:c:marvel as their infoboxes are quite big.

      On another note, from what I've tested it seems impossible to append or prepend data. If I want to a specific input to be a numeric but still display a symbol after it (such as Credits (CR)) we'd have to do that in CSS with the psuedotag ::before/::after? Here's what I've tested here, and whilst it is big it doesn't contain all the values we have for the current infobox as seen w:c:elite-dangerous:Imperial_Clipper.

      If we'd want to take strings such as `cost`, should we have to go through a Module to remove the ` CR` added to it and then calculate the `insurance`-tag? On that note, is it possible to use Lua-modules with this new XML-based Infobox?

        Loading editor
    • SpyTec wrote:
      On that note, is it possible to use Lua-modules with this new XML-based Infobox?

      Sure, you can use the mw.html library to create all the necessary nodes and make it work automatically. But the problem is that there currently isn't any documentation so the scope and limitations of such an infobox are currently unknown.

        Loading editor
    • Again thanks for lot of ideas and constructive criticism!

      We know that it's possible to hack current infoboxes to look good on mobile. That's great and thank you for doing it! It helps us a lot. However, what we are trying to accomplish here is much more than just mobile view. We would like your infoboxes to look great not only on desktop and mobile web, but also in apps. We want to make infobox data available through API so you could build better bots or even your own application using this data. Finally, we could use this data to have better search, enhance SEO, build more accurate recommendations and build infobox editing tools.

      This stage is just the first step toward possibilities that are opened by data and view separation. And to make all of these features great we want to hear your feedback as early as possible. That is why, this project is for volunteers only and so far, so minimal in its features. However it's growing with your help!

      We finally have the first version of documentation: Help:PortableInfoboxes. Thank you Ducksoup for adding it to the blog post.

      Fewfre: Great idea with the NavBoxes. Would like to help us build/test new NavBox markup?

      Rigel Kent: Thanks for the markup suggestions! I'll pass it to our engineering team for consideration.

      SuperSajuuk: We know that the the current version of the infoboxes is very minimal, only few building blocks are available. However, you hit something with Narutopedia. One of the great benefits of this new markup is clear separation of data from the view which gives us access to near semantic data. We hope to use it as a platform for more features in near future.

      SpyTec: Yes, the LUA modules can be invoked from within the new markup. We have also tested the size of the new markup and, thanks to auto-hiding empty rows, they need less markup to render.

      Thanks to feedback we have learned about the need for appending and prepending data and we are working on solving this use case. Please share with us if you some ideas or suggestions on how such markup should look like.

        Loading editor
    • I have been using Help:PortableInfoboxes and have 3 questions:
      1) I note that there are no facility to adjust the image width and is set by the infobox width. Looking at the examples, that is 270px. Could you confirm what the minimum image width has to be to avoid stretched/blurred pictures.
      2) I have copied and pasted your alt instructions and get an error message

      <alt source="alternative_title">
       <default>Default alt text</default>
      </alt>
      

      Can you check and rewrite the instructions if required.
      3) What are the conditions for the source word? I used capital "Character" but got an error message but succeeded with lowercase "character".

        Loading editor
    • whilst Wikia as an entire entitiy my be getting more and more mobile views, is this another change that will be forced upon wikis that have almost exclusivly desktop based views.......

        Loading editor
    • @Shareif: I'm afraid I'm not to good with thinking of good markup (my "process" is "fixing" stuff 4-5 times over a year =p), but I think you could probably find a capable list of people interested in doing so by looking at w:c:dev:Lua_templating#Navbox_Implementations. I personally like the layton branch since it's fairly self contained (even the one template it depends on can be combined into the LUA module, which I've done on my branch of it). I wouldn't mind testing it, but I usually don't use many of the "advanced" features of navboxes (such as navboxes inside of navboxes and the left/right images), but I'm sure many of the big wiki that use navboxes (the one that comes to mind for me is w:c:runescape) could be a good testing ground (even if the community isn't interested, looking at their use of navboxes could be helpful).


      Edit:I also wish you guys would make markup for "<mobileonly>" and "<nomobile>" (or something similar). Even with infoboxes, there's times that certain things (such as an image) shouldn't be included on mobile, and while I can use a CSS hack to make stuff hidden on the mobile skin, it doesn't work on apps. the biggest example I have for things I like to hide are parts of complicated templates, as well as "edit" buttons on templates. An example of something that can be nice to "show" on mobile only is an <hr /> tag to separate things on a template that would otherwise run together horribly on mobile. On some wikis there's also section on the main page that are nice to hide (or only show) on mobile (don't need to worry about this on apps since no front page, but still useful for mobile skin).

        Loading editor
    • I'm trying to reproduce some infoboxes from popular wikis using the new code for fun. I started with the character infobox from Disney wiki (#1 wiki in WAM). Check out:

      I tested it in Firefox, so I don't know about other browsers, but the styling looks the same*, except that the creation was 1000x simplified. See the code difference:

      This shows that every infobox can still look as unique as anyone wants, but are now much easier to create and are better compatible with different devices. If anyone wants me to reproduce your infobox for testing purposes, let me know :)

      * There is one mini difference: I couldn't make the columns in the first group "Background information" have the exact same width as the second group "Character information".

        Loading editor
    • Well, you've just proved that staff's effort was fruitful. This new template is 5 times smaller than the older one. The only problem with this markup is that it is generally something only advanced users can use. But I'm sure it be possible to create tools to facilitate its creation. Of course they made it in an incredible inefficient manner, repeating a lot of code instead of using helper templates.

        Loading editor
    • "This shows that every infobox can still look as unique as anyone wants,..."

      Yes, can still look unique. The problem is the amount of CSS required to do so. Creating the infobox shell is easier but the styling is now harder.
        Loading editor
    • Hi! TableWiz, thank you for questions :)

      1. Image will not be streched. There is no mimimum image size. Smaller images will be centered :)

      2. Thank you for the notice, but the markup is correct. Maybe while pasting the quotation mark (" sign) changed? It happens sometimes. Please remove the copied " and rewrite them.

      3. Hmm. I've used both "Name", "name" and "NAME" multiple times while testing infoboxes, and it was working :) Please note however, that if you define in your template one of them, be consistent. The binding is case-sensitive.

      Hope I've helped a little bit. Cheers!

        Loading editor
    • DEmersonJMFM wrote:
      The problem is the amount of CSS required to do so.

      Not really. Most of the CSS were copied from the original template in Disney wiki. Not much extra CSS were added, with the exception of a few lines to make the label and data display as table cells. You can check out the css in my test wiki for reference.

        Loading editor
    • Dianafa wrote: Image will not be streched. There is no mimimum image size. Smaller images will be centered :)

      DEmersonJMFM has created a template on Alvin

      • The image is listed as 188 × 156 pixels
      • On the template it is listed as 270px × 224px

      Using Firefox on a standard width desktop, the image looks blurred. DEmersonJMFM is a contributor to this thread so hopefully he will respond and confirm whether the image is centered or stretched?

        Loading editor
    • TableWiz wrote:

      The image is stretched, if not resized. I asked if images could be resized but haven't heard anything yet.

        Loading editor
    • Can the text be centered?

        Loading editor
    • Minamoto15 wrote: Can the text be centered?

      Yes, using CSS.

      text-align:center;
      
        Loading editor
    • I reproduced another infobox! This one is the character infobox from Wookieepedia (#8 in WAM). Check out:

      Again, I tested it only in Firefox:

      • Infobox code in Wookieepedia (old infobox, it isn't as cluttered as the one in Disney wiki, but it has high dependency as it relies on at least 3 other templates to make it work: infoboxframe, infocell, charcolor)
      • Infobox code in my test wiki (new infobox, the same thing accomplished with one infobox)

      * Again, there is the small difference in width of the cells. And I couldn't get the [hide] to work.

      I'm going to reproduce one more infobox from a popular wiki, then I think I've done enough testing to be able to give the Wikia team valuable feedback.

        Loading editor
    • I have finished matching the BCW infobox with these new tags via CSS. The two look pretty much identical, which proves that for a regular style infobox, these tags work fine as a replacement for pure wikitext infoboxes. Sure, it's a little more work to get there, where the CSS page ends up being a good deal longer than it previously was, but the result looks great in desktop view. And then there's the mobile view.

      Because of the dedicated tags, the view in mobile is much more beautiful than it was using a wikitable. Because of the whole CSS-stripping aspect of mobile, using a regular infobox table looked OK, but you didn't have the title and headers stand out as headers and titles should. The tag infobox, on the other hand, is nicely styled with appropriately emphasised title and headings. It just looks really nice. I even think the non-tabular form of the infobox works on the mobile because it allows the use of more space per line on the already small screen. Only thing I have to say, though, is that there is less information available before expanding the infobox with the new format than the old. Using my test infoboxes on my phone (iPhone 4), the original infobox displays 6 information fields, which is all bar the bottom row. On the new infobox however, only two data fields are shown before expansion, leaving 5 more covered. I think more should be available on page load, like how it is on the Wikipedia mobile site. Preferably completely open in my opinion. What, by the way, is the idea behind collapsing so much of it?

      So, in conclusion, I like the direction you're going in with the tag infobox. I wouldn't be moving the template over to BCW yet, because I would like to see what changes are made to the tags before finishing their beta first, but I think I will in the end if the idea is kept. More development still needs to be done, for example to accommodate previous/next features for episode infoboxes, but this is a good start.

      If you're interested, the infoboxes I was testing with can be found w:c:imamadmad:Infobox test. The top one is the original and the bottom is the new one made with the tags.

        Loading editor
    • Digifiend
      Digifiend removed this reply because:
      what the heck happened to the div tags?
      12:58, May 23, 2015
      This reply has been removed
    • Ohmystars, I notice your wiki recommends Monobook - but the new template looks nothing like the old one in that skin. I suspect you need to copy some CSS code from Wikia.css or Wikia.js to Monobook.css or Monobook.js.

      Just noticed a bug - the div tags are gone when quoting a forum post.

        Loading editor
    • Digifiend wrote:
      I notice your wiki recommends Monobook

      Really? Where?

      For my own convenience, I only tested everything in the Oasis skin, I never bothered to make it work in Monobook, perhaps I should've mentioned that. But if people wants to see how it looks in Monobook, I would gladly make the css available for all skins.

        Loading editor
    • Checking a few of these infoboxes out in monobook, it seems the image is oddly aligned in every case, both default and styled via CSS. It's shifted way too far to the right and is also off vertically.

        Loading editor
    • Imamadmad, yes I just noticed that too. It seems like a bug in the infobox core for the Monobook skin. In some cases, the colors are messed up too (see God of War wiki from the examples).

        Loading editor
    • Thanks guys for involvement and constructive feedback.

      We are aware of the Monobook issue. Hopefully we will release fix for this issue early next week!

        Loading editor
    • Ohmystars wrote:
      Digifiend wrote:
      I notice your wiki recommends Monobook
      Really? Where?

      For my own convenience, I only tested everything in the Oasis skin, I never bothered to make it work in Monobook, perhaps I should've mentioned that. But if people wants to see how it looks in Monobook, I would gladly make the css available for all skins.


      Front page: "For an optimal viewing experience, Wookieepedia recommends using the Monobook skin. See Help:Skin for more information."

        Loading editor
    • Digifiend wrote:

      Front page: "For an optimal viewing experience, Wookieepedia recommends using the Monobook skin. See Help:Skin for more information."

      Oh, but Wookieepedia is not my wiki! It's just one of the popular wikis ranked high in WAM, just like Disney wiki (see my post above), that I chose to replicate the infobox from for testing purposes. Sorry for confusing you!

        Loading editor
    • What is going on?

        Loading editor
    • Hey folks, I replicated another infobox from a popular wiki. This is the character infobox from "Cardfight!! Vanguard Wiki" (#13 in WAM).

      The tabber works too! How cool is that? See the code difference:

      Long feedback coming...

        Loading editor
    • Is the image supposed to be indented? Because on my computer (Internet Explorer, Monobook), ALL of the infoboxes with images have it slightly offset, like a drop shadow or something except it's on top.

        Loading editor
    • So I've tested the new infobox by reproducing existing infoboxes from popular wikis (all with #1 peak rank in WAM list), as posted here 1, 2, 3. Here's my feedback:

      1. I managed to reproduce the infoboxes solely using CSS, without using any "hacks". I looked at the infoboxes of other popular wikis and can say with almost absolute certainty that I can reproduce almost all of them, however different they may look. The majority of the infoboxes differ only in styling, yet they all use different codes to create the infoboxes. Some of the codes are extremely cluttered (like the one in Disney wiki and Cardfight wiki), with many unnecessary repetitions, which are difficult to modify (as you have to repeat the changes 1000x times for just modifying one thing). Others rely on multiple templates to make the infobox work (like the one in Wookieepedia). This new infobox seem to be able to solve all this, as many of the functions (checking if data is empty, etc.) are all done in the background and users no longer need to include them in the code of their infobox.

      The best thing about this new infobox code is that if every wiki implemented it, the css selectors would be the same universally. Anyone who wants to copy the look of another infobox wouldn't have to change their infobox code, only copy the CSS and it would work instantly. People wouldn't have to crack their head anymore about what selectors is used or what additional dependent templates they have to copy just to change the styling.

      2. The only thing I could not reproduce with CSS solely is the functionality to hide infoboxes or make part of the data collapse, like the Wookieepedia infobox. I think this is a functionality that can be added to the infobox core. Though, only a very small amount of wikis have such functionality in their infoboxes, so I don't think that this should have a high priority now. More about collapsing later.

      3. All of the old infoboxes I encountered all over Wikia have their label and data displayed in two columns. I am able to reproduce that look using display:table; but it requires extra work. Especially those with multiple <group>'s are tricky to make the cells have the same width everywhere. Since the majority of the people would want an infobox with two columns, I would suggest to make that possible by default for the desktop version.

      4. I notice that sometimes I want to target a certain data field using CSS, like when I was replicating the Cardfight infobox, but couldn't do that because the fields didn't have an unique class or id attached to it. I solved it in that specific case by employing the :only-child selector, but that isn't something that can be applied all times. I suggest to automatically add the data source (from <data source="">) as a class name or id to the .item-type-key-val div. This also seem to be one of the problems Fewfre mentioned here.

      5. I agree with what Imamadmad mentioned here about the infobox in the mobile skin. An extremely large part of the infobox is hidden from view when collapsed. Is there any reason for that? I guess the thought behind that idea is that mobile users may not want to scroll through long infoboxes before they reach the page content? Why not take an approach from the other side? I suggest to show it fully by default, and then place a button at the top of the infobox that allows users to skip the entire infobox if they want to jump directly to the page content.

      That's it. Hopefully the team finds my feedback useful and keep up the good work. :)

        Loading editor
    • Oh great. Wikia's again pandering to the mobile fanbase. I miss the old layout.

        Loading editor

    • Hey guys! I'm a designer that is a part of the team that is working on the new infoboxes. I just would like to say, that I am really amazed by the amount and quality of all the feedback. It helps us incredibly in making it better.

      It's a pleasure to design for such an amazing bunch of people!

      Thank you!

        Loading editor
    • Hi Ohmystars!

      You did a really GREAT job with styling all this infoboxes, playing with them and providing so much useful feedback. Wikia staff appreciate that!

      Some notes from me:

      2. Yes, good point. We will consider this and others ideas while next steps of infobox improving. The same with point 4.

      3. Even better point! :) We are working on this, please give us some time ;)

      5. Well, we wanted to be consistent with the approach of the old infoboxes. Yes, the reason was that infoboxes are usually long, and if someone wants to read the article content, he has to scroll, and scroll and scroll… as you said. Your idea to take the opposite approach sounds interesting and also is definitely worth considering.

      Thanks again for your thoughts. Please note that the infoboxes are still in the development phase, what means both that we are open for your feedback and thoughts as well as we are still going work on them to make it extremely useful, nice, handy and better than them have ever been :)

        Loading editor
    • ok I'm in help me get on  unblocked from Monster High wiki and I will join Thanks

        Loading editor
    • Ohmystars wrote: ... 3. All of the old infoboxes I encountered all over Wikia have their label and data displayed in two columns. I am able to reproduce that look using display:table; but it requires extra work. Especially those with multiple <group>'s are tricky to make the cells have the same width everywhere. Since the majority of the people would want an infobox with two columns, I would suggest to make that possible by default for the desktop version. ...

      Making it display like a two columned table is much easier if you do it just on the level of each item. Skip the display:table; (as it's not an actual table you're making, you don't have to nest the tags as if you were) and just make each data pair a table row with the label and value as data cells, as with the following:

      .portable-infobox .item-type-key-val {
          display:table-row;
      }
       
      .portable-infobox-item-label {
          width:50%;
          display:table-cell;
          vertical-align:middle;
      }
       
      .portable-infobox-item-value {
          width:50%;
          display:table-cell;
      }
      

      That alone was enough for me to get the data values to work perfectly as a two column table of equal widths, and should (but I haven't done enough testing to check) work no matter what the parent element is.

      The trouble with having it as a two column table by default in the oasis skin is the fact that the default display in mobile would be quite significantly different. It seems that with the default table at least, Wikia is trying to keep the style consistent, which makes sense. I can imagine a lot of angry voices in comments later on when some of the more shouty people realise that it looks different on the different displays (because some people just like to shout about differences before thinking about the benefits of the new situation). But, seeing as that's going to be the result most people are going to be striving for with CSS, maybe it would just be easier to have the table layout as the oasis default. Sugestion: maybe put a class parameter in the infobox tag which lets users decide between a default infobox-table or a default infobox-... I don't know what you'd call the current default design. Having the class would allow users to choose which preset is most applicable to their situation and could work as a good basis for further CSS customisations as no matter which layout people prefer, they can have that as a starting point from the default CSS. Maybe they won't feel the need for further styling at all!

        Loading editor
    • Ohmystars wrote:

      Most of the CSS were copied from the original template...

      You copied CSS from a template? That doesn't sound right. Or did they style their infobox with CSS in a MediaWiki page? I ask because if they already had CSS to style the infobox, it wouldn't be much extra work. We don't style infoboxes via CSS thus if we had to use CSS that's the problem I was getting at.

      Ohmystars wrote:

      The tabber works too! How cool is that?

      How about a tabber that is placed within the infobox code (instead of in a single parameter on an article) and contains two or three parameters within that code like this one? All of our infobox tabbers work/look this way.

        Loading editor
    • Zeus reed wrote: ok I'm in help me get on  unblocked from Monster High wiki and I will join Thanks

      1. This is not the right place to ask.
      2. Looking through your history, the block seems justified. I understand if you don't want to let go of the wiki, but the blocking admin on that wiki has flat-out stated that you used up all your chances and are blocked forever now. It's really no use to you or anyone else to keep asking, especially in a completely unrelated place.
        Loading editor
    • I don't know.

        Loading editor
    • im yes 

        Loading editor
    • Imamadmad wrote:

      That alone was enough for me to get the data values to work perfectly as a two column table of equal widths, and should (but I haven't done enough testing to check) work no matter what the parent element is.

      Infobox width of groups

      The width of the label in the first group is 83px, the second group is 79px (both automatically calculated based on 1366x768 screen size)

      That's because your label and data fields have equal widths. But what about unequal widths? Of course we can give the label a pre-defined width too, like width:80px; for the Cardfight infobox I replicated. But that's only because the original template already had a pre-defined width. What about undefined widths, when you want the width to automatically adapt according to the length of the text and that can vary based on scren size? That was the case for the Disney infobox I replicated. As you can see, it did adapt to the length of the texts, but the width in the first group and the width in the second group differ (though only slightly in this case), see screenshot.

      I somehow managed to work-around that issue in my second attempt (when I replicated the Star Wars infobox) but it's still tricky.

      Imamadmad wrote:
      Sugestion: maybe put a class parameter in the infobox tag which lets users decide between a default infobox-table or a default infobox-... I don't know what you'd call the current default design. Having the class would allow users to choose which preset is most applicable to their situation and could work as a good basis for further CSS customisations as no matter which layout people prefer, they can have that as a starting point from the default CSS.

      I support this suggestion. Perhaps something like this:

      /* The two-column layout */
      <infobox layout="two">
      
      /* The new layout */
      <infobox layout="one">
      
      /* When unspecified, default is the new layout */
      <infobox>
      

      The only difference between the two layouts would be the way the label and data fields are displayed (in two columns or not). The rest (the design of the infobox) can stay the same. I guess that doesn't require too much changes and that would also satisfy the people who dismiss the new infobox at first glance just because of the new styling.

        Loading editor
    • DEmersonJMFM wrote: You copied CSS from a template? That doesn't sound right. Or did they style their infobox with CSS in a MediaWiki page?

      Yes, I copied the CSS directly from the template page. Only for the Star Wars infobox I had to take a look at their MediaWiki CSS page. The other two styled it within their template. Why not take a look at the code of their templates yourself? Here and here. I just copied the parts within style="....".


      DEmersonJMFM wrote: How about a tabber that is placed within the infobox code (instead of in a single parameter on an article) and contains two or three parameters within that code like this one? All of our infobox tabbers work/look this way.

      The original page at the Cardfight wiki used the tabber in the article, so I just followed that. Let me try to replicate your template.

        Loading editor
    • DEmersonJMFM, I replicated your infobox without problem:

      The tabber code is copied from your template:

        Loading editor
    • DEmersonJMFM wrote:
      How about a tabber that is placed within the infobox code (instead of in a single parameter on an article) and contains two or three parameters within that code like this one? All of our infobox tabbers work/look this way.

      Perhaps you're missing the point of the new tags. In technical terms they are meant to separate the data layer from the presentation layer. In layman's terms you keep the data in one place, and change the look in another. Generally speaking those tags shouldn't contain any UI elements, and should only represent the kind of data that is entered into the infobox.

      There are many benefits to this, some already indicated by staff. But beyond simply being a standard practice in the programming world, it facilitates a lot of things. If you move your data from one place to another, there is no need to reinvent the wheel.

      One can quickly glance and discover what the infobox is about by simply looking at the xml, and problems with the gui won't affect the data itself, because as indicated before if you mess up changing the tags, the whole thing won't show. So this is something that should be created once and rarely edited. But one would still be able to change the styles at will without worrying about the data at all.

      The biggest benefit is that it removes the curly brackets and complex code that should never have been placed in the infobox in the first place.

      Come to think of it, perhaps the documentation page should also list some recommended guidelines for building the infoboxes, e.g. separating the data , presentation, and logic/processing layers.

        Loading editor
    • No good is gonna come from mucking about with an already readable infobox system, both on a desktop and a mobile phone. The infoboxes ya'll are proposing are clunky. Everything is crowded together, there is no space between any of chunks of information provided and more or less threaten to break the hell out of customized infoboxes that don't carter to the idea of a mobile version of this website. Again, beta stages or not, CREATE AN OPT OUT SYSTEM for users who don't want any part of this.

      I didn't spend hours creating customized infoboxes tailored to the Wiki's aesthetic just so I could see it get broke by the detrimental "We must cater to the Mobile Audience" mentality of Wikia corporation.

        Loading editor
    • Lily Ford wrote:
      No good is gonna come from mucking about with an already readable infobox system, both on a desktop and a mobile phone. The infoboxes ya'll are proposing are clunky. Everything is crowded together, there is no space between any of chunks of information provided and more or less threaten to break the hell out of customized infoboxes that don't carter to the idea of a mobile version of this website. Again, beta stages or not, CREATE AN OPT OUT SYSTEM for users who don't want any part of this.

      I didn't spend hours creating customized infoboxes tailored to the Wiki's aesthetic just so I could see it get broke by the detrimental "We must cater to the Mobile Audience" mentality of Wikia corporation.

      This isn't something that everyone has to use. Stop complaining about something that isn't an issue

        Loading editor
    • SpyTec wrote: This isn't something that everyone has to use. Stop complaining about something that isn't an issue

      I think I'll complain however I want, especially if it'll get me answers. Where exactly is it specified in the OP that the infobox system they're working on isn't a system they plan on employing across the entire wiki like the Venus layout, exactly?

        Loading editor
    • Dessamator wrote:

      Perhaps you're missing the point of the new tags.

      I understand this seeks to simplify infobox coding/creation. In the technical, coding sense I'm sure I'm missing something. I'm not a professional coder, not even remotely close though I know some of the basics to get things done. UI elements, "standard practices," xml, gui - no idea what you mean.

        Loading editor
    • DEmersonJMFM wrote:I'm not a professional coder, not even remotely close though I know some of the basics to get things done. UI elements, "standard practices," xml, gui - no idea what you mean.

      The simple and short answer is that  they are trying to separate the way data is stored, from the way it is displayed, and the way it is described.  So Infobox tags = how data is going to be structured, template = How data is going to be stored, css = how it will be presented (styled).

      Currently, the best wikitext templates are a mess. They have too much repetitive code, and are horrible for a new editor to try to understand and use. Even experienced programmers will cringe at the thought of making an edit to those wikitext templates, and that's saying something considering that programmers deal with worst unintelligible gibberish (sometimes).

        Loading editor
    • Hey folks, just wanted to let you know I've edited the Help page. In the "Available Tags" section I added the HTML output to the usage examples, so that you know what code will be in the output when you use the XML tags, making it easier for you to know which classes you can target when you want to customize the infobox using CSS.

        Loading editor
    • Thank you all for great work and amazing feedback. Together we can make infoboxes ROCK!

      In the meantime our infoboxes have evolved! Starting from Today new features are available:

      Markup allows handling of the image captions. Caption works exactly like <data> tag, but is placed within the <image> tag. For example:

      <infobox> 
       <image source="image">
        <caption source="caption">
         <default>Default alt text</default>
        </caption>
       </image>
      </infobox>
      

      We have fixed the image scaling issue. Small images will not be expanded to infobox's width but will be centered instead.

      We have fixed the Monobook styles. Now Monobook has neutral, gray colored infoboxes and no broken images. Check them out on Kratos from God of War article.

      We have introduced custom infobox theming. Now you can add unique class to the whole infobox allowing better customizations:

      <infobox theme="ABC"/>

      Will add "portable-infobox-theme-ABC" class to the infobox.

      <infobox theme-source="abc"/>
      Will add a custom class based on value of "abc", the same way as "source" works in <data> tag. For example if infobox was invoked with
      |abc = foobar
      that class will be portable-infobox-theme-foobar".
        Loading editor
    • How exactly is the theme class supposed to be added? I gave my styling the .portable-infobox-theme-general selector and added <infobox theme="general"/> to the top of the infobox and it doesn't work.

        Loading editor
    • Thank you for the update!!! The unique class thing is really helpful, especially when people want to use a different style for each infobox within one wiki.


      DEmersonJMFM, don't add the closing slash when you have added child tags, just this: <infobox theme="general">

        Loading editor
    • Hi DEmersonJMFM,

      Here are some live examples on how to use the themes:

      I hope they will be helpful.

        Loading editor
    • I just tested it and I ran into a "problem".

      Case A: Infobox A uses the default theme (either Wikia's style, or an adjusted version by styling .portable-infobox). In specific articles, a custom theme is applied. This works:

      • Infobox A template: <infobox source-theme="theme" />
      • Infobox A in article 1: {{infobox A}}, the class is .portable-infobox-theme-wikia
      • Infobox A in article 2: {{infobox A|theme=red}}, the class is .portable-infobox-theme-red

      Case B: Infobox B uses a custom theme, named ABC. This works:

      • Infobox B template: <infobox theme="ABC" />
      • Infobox B in article: {{infobox B}}, the class is .portable-infobox-theme-ABC

      Case C: But what if I want this? Infobox C uses a custom theme, named ABC. In specific articles, I want a custom theme.

      • Infobox C template: <infobox theme="ABC" source-theme="theme">
      • Infobox C in article 1: {{infobox C}}, the class is .portable-infobox-theme-ABC
      • Infobox C in article 2: {{infobox A|theme=red}}, the class is still .portable-infobox-theme-ABC (not changed to .portable-infobox-theme-red)

      Case C is when someone has a character infobox with a custom style that differs from other infoboxes (series infobox, battle infobox, etc.) For certain characters, he wants to change the colors of the infobox. How to achieve this?

        Loading editor
    • Ohmystars wrote:
      I just tested it and I ran into a "problem".

      Case C is when someone has a character infobox with a custom style that differs from other infoboxes (series infobox, battle infobox, etc.) For certain characters, he wants to change the colors of the infobox. How to achi

      Doesn't the  default tag work?

       <infobox source-theme="abc">
       <default>ABC</default></infobox> 
      

      Edit: it seems that the infobox tag is enabled for this wikia. So I just quickly checked that the source-theme, doesn't accept the default parameter. It could be added, but for now, you can simply use either the if parserfunction or switch in your template.

        Loading editor
    • Yes, the default tag doesn't work (yet). But I prefer this markup <infobox theme="ABC" source-theme="theme"> over the usage of default tag.

      Instead of a parserfunction or switch, my temporary solution was to use a page selector in CSS to target the specific character articles.

        Loading editor
    • Ohmystars wrote: I just tested it and I ran into a "problem". (...)

      • Infobox C template: <infobox theme="ABC" source-theme="theme">

      Please use theme-source instead of source-theme - it should work as you expect by overriding default theme attribute value.

      Looking forward to more feedback from all of you!

        Loading editor
    • Dessamator
      Dessamator removed this reply because:
      repeat
      13:43, May 26, 2015
      This reply has been removed
    • Dessamator
      Dessamator removed this reply because:
      repeat
      11:46, May 26, 2015
      This reply has been removed
    • Sebastian Marzjan wrote: Looking forward to more feedback from all of you!

      Using Shareif's example....

      The template uses "theme" as its tagword

      <infobox theme-source="theme">
       <title source="name"/>
       <image source="image">
        <default>Kiddo_Bride.jpg</default>
       </image>
      </infobox>
      

      When the template is posted on a page, the "theme" tagword is used to set background

      {{Itheme
      |theme=red
      |name=Phoenix Ikki
      |image=Phoenix_Ikki_2.jpg
      }}
      

      Does Special:CSS have to be changed to "switch on" <infobox theme-source=" ">

      I found a new wikia. The founder had just copy and pasted from Wikipedia which was a page of coding. So I replaced it with a PortableInfobox. I would like to set up so they can color-code the templates with the train line color. Is there something that I can embed in the template (like style="background:red")?

        Loading editor
    • Oh it's theme-source! Perhaps Shareif could correct that in his post?

        Loading editor
    • Whoops, my bad :D Fixed.

        Loading editor
    • Ohmystars wrote:

      DEmersonJMFM, don't add the closing slash when you have added child tags, just this: <infobox theme="general">

      Thanks. Shareif's post was a little misleading.

        Loading editor
    • I got into a problem with uploading a picture for Infobox. Can someone tell me how to do that, because it ends up with dupe link.

        Loading editor
    • Sure, could you share a link to your infobox?

        Loading editor
    • Fewfre wrote:

      Also as mentioned above, any infobox that currently breaks on mobile would already be a mess... and odds are those communities either don't care, or don't know about the issue, and as such wouldn't really implement this, and thus this wouldn't actually fix the "mobile" issue (which, again, we all would love to hear specific about).

      Imamadmad wrote:

      The trouble with having it as a two column table by default in the oasis skin is the fact that the default display in mobile would be quite significantly different. It seems that with the default table at least, Wikia is trying to keep the style consistent, which makes sense. I can imagine a lot of angry voices in comments later on when some of the more shouty people realise that it looks different on the different displays (because some people just like to shout about differences before thinking about the benefits of the new situation).

      Mobile Infobox Before New Markup

      I think the two column approach is nice for larger screens, but I like the idea of the infoboxes "defaulting" on mobile to the original proposed layout. The different style doesn't bother me considering the benefit. To the right is was the last infobox left to be rewritten into the new markup (all other infoboxes are using the new markup live) as seen in mobile preview (current view). It currently looked a little messy but looks was just fine in all other views I've seen. Given mobile ignoring CSS, the present default will improve this infobox quite nicely and I'm hoping the present default (if not solely for mobile) will remain.

      Edit: Last infobox done and noted above.

        Loading editor
    • ok

        Loading editor
    • Shareif wrote:
      Sure, could you share a link to your infobox?

      I deleted it.

        Loading editor
    • Why not just serve the pages with the desktop style by default UNLESS the wiki in question has made a mobile.(css/js) in wich case just load those after the default ones for the wiki. That way every wiki can customize their mobile view on a-per-need-basis. I'm a desktop/mobile user also, and i mostly browse using the desktop view on my mobile... I really don't get why the web is trying to reinvent the web on a per device-type case, we got an standardized HTML5 these days which all webpage rendering engines are working on to support...

      In short make the mobile exceptions work "on-top" of the desktop styles, instead of REPLACING them... (Who wants to browse the web using Lynx these days anymore?)

        Loading editor
    • So far most of the templates on Elder scrolls seem to be ok.  One of our templates color was changed, and we have some reports of the skyrim NPC's templates not working on mobile.

      I myself feel that editing with these templates seems more difficult, or at least will be.  All of this is still rather early so I wont say its a problem yet, but I wanted to make sure that I shared the our wikis current status.

        Loading editor
    • i came into a confusing convo. can someone explain in more depth

        Loading editor
    • yes please offer

        Loading editor
    • ©TriMoon™ wrote:
      Why not just serve the pages with the desktop style by default UNLESS the wiki in question has made a mobile.(css/js) in wich case just load those after the default ones for the wiki.

      That way every wiki can customize their mobile view on a-per-need-basis. I'm a desktop/mobile user also, and i mostly browse using the desktop view on my mobile... I really don't get why the web is trying to reinvent the web on a per device-type case, we got an standardized HTML5 these days which all webpage rendering engines are working on to support...

      In short make the mobile exceptions work "on-top" of the desktop styles, instead of REPLACING them... (Who wants to browse the web using Lynx these days anymore?)

      Thanks for question. Well, it is not so easy and it is not really the case to only change the .css file or and an .js one. 

      First of all, the wiki articles are not just only the text with some images inside. Very often they are really complex and messy with their templates in templates in sliders in tables in tabbers... and so on. ;) AND they are developed by users in order to show them on desktop which is understandable. However, when comes to render items like this on the mobile, they are really tricky and usually VERY NOT NICE :) They often have hardcoded css values, styling and structure which simply cannot be properly rendered without the dedicated mobile skin.

      Moreover, do you really want to load all the heavy, desktop page AND then append to it custom mobile styling? :)

      Thus, we are step by step introducing a mobile friendly syntax elements. It helps us parse wikitext properly and serve it to other skins, which are better prepared for the mobile usage (reduced page load time, big buttons, handful menu, responsivity).

      Is this the answer for your concerns? If not, feel free to ask more :)

        Loading editor
    • Cheatcodechamp: can you be a little more specific? Why do you think these will be more difficult to edit? How can we make it easier on you?

        Loading editor
    • Cheatcodechamp wrote:
      So far most of the templates on Elder scrolls seem to be ok.  One of our templates color was changed, and we have some reports of the skyrim NPC's templates not working on mobile.

      I myself feel that editing with these templates seems more difficult, or at least will be.  All of this is still rather early so I wont say its a problem yet, but I wanted to make sure that I shared the our wikis current status.

      Yes, thanks for the feedback. Did you get any info which tamplates are not working?

      Well, generally, our point was to make it more EASY to edit... :P What will be the possible problem? We are still working on making them more user-friendly, so we are open for your feedback. However, at a first glance, they are much cleaner and readable in comparison to the markup we've encountered in this templates before ;)

      What exactly in your opinion is more difficult? Please, explain, we'll discuss your opinion and try to help :)

      Do you want us to introduce a new infoboxes also on other templates on Elderscrolls wiki? Or maybe you want actually play with them? If you will, you'll probably see how easy it really is :)

        Loading editor
    • Ducksoup wrote:
      Cheatcodechamp: can you be a little more specific? Why do you think these will be more difficult to edit? How can we make it easier on you?


      A lot of us edit using the older methods, the source and visual. When I was toying with the templates to see what was different, I was having trouble adding content. the main problem was the old visual mode, the one with the puzzle pieces representing templates. The option to edit the template was gone.
      Infobox Beta TESWiki test

      The option to "edit" is gone.

      Source mode seems fine, and visualeditor is working fine as well.

      I have a few editors saying that the templates are showing up weird on their phones, mainly for our SkyrimNPC templates, I am unsure if this has been fixed or not.

      @Dianafa the problem with the Morrowind template has been fixed, I assumed it would be and we are thankful for the quick response.

      I always try to toy with templates, its the only reason I understand them as much as I do. My concern is newer editors. Changes like this are frustrating for experienced editors, newer ones get it worse. Like I said above, most of us use the older methods, not only because we find it simpler to use over visualeditor, but some of us dont have an option in the matter due to sub-par equipment, or the few page blanks glitches we experienced scared us off. I love how this is going to help mobile users, but I would also like to make sure this transaction creates as few problems for the editors as possible.

      As for adding the new infobox, I think we will leave that at your discretion. As long as the templates work and our editors are happy, I'm OK with moving forward. Odds are it will be a few years before the next game so we have time to learn how the templates work.

      Thanks to you both, I hope I make sense explaining this. I am glad to see that staff is working as fast as possible in resolving things.


      EDIT: I added the image to show what I was talking about withing thinking about if its OK to add the image to a fourm post.  I am sorry if that is a problem and will remove it if it is.

        Loading editor
    • I like it, and I'd like to try the infoboxes!

      But before I do that, a question: is there a chance of the wikitext changing after getting out of beta? If so, then I suppose it's best for me to wait and then type the wikitext once instead of having to change a template multiple times.

        Loading editor
    • Hi.

      Anonymoustyd: Great to hear that you like the new infoboxes! The core of the markup is unlikely to change. The tags that we are still evaluating and might change include <comparison> and <footer>. We will update the help page with the beta progress next week.

      Cheatcodechamp: Thank you for the kind words and reporting the VE issue. We are working on fixing it!

        Loading editor
    • It could definitely use the divorce between the data and the presentation, so for example this would is possible:

      <data source="length" visible="false" />
      <data source="width" visible="false" />
      <data>
       <label>Dimensions</label>
       <template>{{{length}}}×{{{width}}} m</template>
      </data>
      

      The argument "visible" could let the visual editors know they're supposed to show that field, even though it won't be visible in the infobox. I'm not sure how to handle the conditional visibility of the last row, since there are two points of failure (in absence of one parameter, some infoboxes might want to hide the field and some give a default value), but I'm sure you'll know better anyway.

        Loading editor
    • Dianafa wrote:

      ©TriMoon™ wrote:
      Why not just serve the pages with the desktop style by default UNLESS the wiki in question has made a mobile.(css/js) ......

      ...... Is this the answer for your concerns? If not, feel free to ask more :)

      As might have guessed NO :P

      Let me counter your vision on special mobile presentation: Are current mobiles able to display webpages using "Desktop mode", and render it like it renders on desktop? ^^ I'm sure you won't answer that with a "No", so why all the fuzz? :P

      Oh PS: Yes i know about the bandwidth usage of all the scripts on desktop version of webpages, that's easily decimated by addblockers and DNS-filters, thats how i browse on both mobile and desktop (99% CRAP free)

        Loading editor
    • I do not agree with this idea, from what I can tell there is nothing to improve and not everybody uses their phones to go on wikia and those who use their laptops and desktop computers would not be very happy with these results.

        Loading editor
    • Alex2424121 wrote:
      I do not agree with this idea

      So you don't agree with the idea of simplifying the construction of infoboxes?

      Alex2424121 wrote:
      from what I can tell there is nothing to improve

      Do you use mobile? Do you check how infoboxes appear on mobile? The simple infoboxes look fine but generally those with more information/complexity look worse then they could. Dessamator explains more of the coding improvements above.

      Alex2424121 wrote:
      not everybody uses their phones to go on wikia

      No, but obviously enough people do. Why should content on mobile look bad because everyone doesn't use it?

      Alex2424121 wrote:
      those who use their laptops and desktop computers would not be very happy with these results.

      Once you style the infobox, labtop and desktop users won't even tell the difference visually. Ohmystars did a great job showing that existing infoboxes from top wikis can look almost, if not, exactly as they did before the markup.

        Loading editor
    • DEmerson, you wrote almost precisely what I would've written, here. Thank you!

      Alex: I'm happy to allay any of your fears, here. Trust me when I tell you that WIkia totally respects the styling you've done on your desktop infoboxes up to this point. We just need to deliver a high-quality mobile experience as well. 

        Loading editor
    • I'm using new infoboxes in our Megapolis wiki, so far so good; except its a little tall & images used on infoboxes doesn't appear on What Links Here! So this remove the infobox image from the infobox if the image is renamed and no will even notice, unless they visit that page. Infobox images should appear on What Links Here.

        Loading editor
    • Qoushik wrote:
      images used on infoboxes doesn't appear on What Links Here!

      This and pages appearing on Special:Insights/withoutimages when the image is in an infobox might be related issues.

        Loading editor
    • Thank you Qoushik and DEmersonJMFM. I've created a ticket for our engineers to handle the missing image. We will also make sure that image from the infobox is the image that will represent the whole article in Category Exchibition and social sharing.

        Loading editor
    • Shareif wrote:
      Thank you Qoushik and DEmersonJMFM. I've created a ticket for our engineers to handle the missing image. We will also make sure that image from the infobox is the image that will represent the whole article in Category Exchibition and social sharing.

      I think this is part of a larger problem where images that are created using scripts or other "means" aren't shown. For example, if I use frame:preprocess to create an image using lua, it will not show up in the Special:Insights/withoutimages until the page is refreshed.

      I'm guessing that wikia's parser simply looks for "File:" links in the unprocessed (source) page, so it doesn't document it when the page is created or cache is refreshed. Using special:insights to solve the problem seems to fix pages with that issue, provided that the page contains another "File:" link somewhere. Although doing this for hundreds of pages seems "counterproductive".

        Loading editor
    • QoushikDEmersonJMFM , Dessamator

      thank you for sharing your insights. We'll surely discuss it next week and fix it as soon as possible :) What yould we do without you? ;)

      Cheers!

        Loading editor
    • I question the design of the new infoboxes.

      Things that I'm not keen on:

      • It seems to take up too much vertical space

      I.e. This one really shows that: http://saintseiya.wikia.com/wiki/Phoenix_Ikki?_ga=1.32910781.280084857.1432622686

      It switches from "at a glance" to "scroll down lots just to read the infobox, then scroll back up to read the content"

      While research suggests that people take in information more easily when labels are placed above text , I feel the cost of doing that really takes away from the "at a glance" aspect of infoboxes. Especially when compared to the ones Wikipedia have: https://en.wikipedia.org/wiki/Christmas


      • I feel it'll look better with a border around it. 


      • The lines that separate sections, I don't know, something about them doesn't feel right. 


      • The text size looks too big. Compare it to Wikipedia's info boxes

      I think it needs a few more design iterations. 

      And another design issue is the amount of unused whitespace in the right sidebar. I understand you want to put ads there, but you only show like, 1 ad, or a very small "wiki activity", and the rest of the bar is blank. 

      I feel a more elegant solution could be found.

        Loading editor
    • Bruce A wrote:

      • I feel it'll look better with a border around it. 

      I put the infobox in a template, then create another template with the infobox template isnside a table, and bordering the table.

      My 2 infoboxes: Sandbox

        Loading editor
    • Qoushik wrote:

      Bruce A wrote:

      • I feel it'll look better with a border around it. 

      I put the infobox in a template, then create another template with the infobox template isnside a table, and bordering the table.

      My 2 infoboxes: Sandbox

      They look great!

      I still think they're too long, and the border is a little thick.

      But I feel that's the right direction, as opposed to those shown in the first post in this thread. 

        Loading editor
    • Bruce A wrote:

      • It seems to take up too much vertical space
      • I feel it'll look better with a border around it. 
      • The lines that separate sections, I don't know, something about them doesn't feel right. 
      • The text size looks too big. Compare it to Wikipedia's info boxes

      Hey Bruce A, all the things you mentioned are all just a matter of styling. I know this thread is long and you probably didn't bother to read previous posts, but it is announced in #114 that custom theming of the infobox is now possible and several people have posted custom styling of the new infobox.

      • I've replicated 3 looks of infoboxes from top wikis: see my posts #72, #81 and #92.
      • I also helped out DEmersonJMFM with the styling of the infoboxes in his wiki, check out any page on his wiki for infoboxes using the new tags.
      • Imamadmad has also tested the infobox with a custom style (see #82).
      • The Elder Scrolls wiki is using the new infobox with a custom style.

      So feel free to create your own theme (or ask people to help you) and implement all the points you mentioned above. You can even make it look exactly like the infobox in Wikipedia if that's what you want.

        Loading editor
    • Bruce A wrote:

      Qoushik wrote:

      Bruce A wrote:

      • I feel it'll look better with a border around it. 

      I put the infobox in a template, then create another template with the infobox template isnside a table, and bordering the table.

      My 2 infoboxes: Sandbox

      They look great!

      I still think they're too long, and the border is a little thick.

      But I feel that's the right direction, as opposed to those shown in the first post in this thread. 

      I think its thick too! But that's the only way I could be approximately align it to the center. Take a look at the source, you'll see.!

        Loading editor
    • User_blog:Thisismyrofl/Infoboxes_old_and_new

      I wrote a few blogs on how to create the previous style of infoboxes. I guess they won't be seeing so much use any more, but I'm glad to see the evolution.

        Loading editor
    • I have an idea: What if the ability to add a gradient and/or a border to the new infobox?

        Loading editor
    • Thisismyrofl wrote:
      User_blog:Thisismyrofl/Infoboxes_old_and_new

      I wrote a few blogs on how to create the previous style of infoboxes. I guess they won't be seeing so much use any more, but I'm glad to see the evolution.

      Well, you can always write a new blog on the new infoboxes. Generally speaking, infoboxes aren't something one can simply just wake up and decide to do. In fact,  when I was a novice wiki contributor, I learnt how to create infoboxes using information from your blog. The general help page was too complicated at the time for me.

        Loading editor
    • Thisismyrofl wrote: User_blog:Thisismyrofl/Infoboxes_old_and_new

      I wrote a few blogs on how to create the previous style of infoboxes. I guess they won't be seeing so much use any more, but I'm glad to see the evolution.

      Welcome back!

        Loading editor
    • Hmmmm

      OmakeGifAnime-Yuushibu-Episode7 zps328a53ba

      HMMMM

        Loading editor
    • Dessamator wrote:

      Thisismyrofl wrote:
      User_blog:Thisismyrofl/Infoboxes_old_and_new

      I wrote a few blogs on how to create the previous style of infoboxes. I guess they won't be seeing so much use any more, but I'm glad to see the evolution.

      Well, you can always write a new blog on the new infoboxes. Generally speaking, infoboxes aren't something one can simply just wake up and decide to do. In fact,  when I was a novice wiki contributor, I learnt how to create infoboxes using information from your blog. The general help page was too complicated at the time for me.

      I am always tickled to hear that I've helped someone out! Thanks for letting me know.

        Loading editor
    • Ultimate Dark Carnage wrote:
      I have an idea: What if the ability to add a gradient and/or a border to the new infobox?

      I haven't tried it, but you should be easily able to add it with CSS. Learn it: that's the web standard.

        Loading editor
    • Quick follow up to my previous post on tag collisions. The <caption> HTML tag is already whitelisted in MediaWiki 1.19. <caption> tags outside portable infoboxes appear to be working okay. The <data> HTML tag is whitelisted in 1.21+.

        Loading editor
    • Dessamator wrote:
      Thisismyrofl wrote:
      User_blog:Thisismyrofl/Infoboxes_old_and_newI wrote a few blogs on how to create the previous style of infoboxes. I guess they won't be seeing so much use any more, but I'm glad to see the evolution.
      Well, you can always write a new blog on the new infoboxes. Generally speaking, infoboxes aren't something one can simply just wake up and decide to do. In fact,  when I was a novice wiki contributor, I learnt how to create infoboxes using information from your blog. The general help page was too complicated at the time for me.

      I think a lot can be done to (A) make them good for almost everyone, and (B) make them easy to implement so people don't have to go read a tutorial somewhere to know to even use them.

      If Wikia (and other wikis) have one issue, is that there's quite a barrier to entry for most people, in that most stuff is overly complex without really needing to be. Wikia does a good job at improving this, though. 

        Loading editor
    • It is possible to design a GUI(Graphical user interface) that will automatically create the Html tags. Wikia already has a GUI that helps populate a template using visual editor, but it would only work for a template that makes use of the infobox tags, not to create them directly. Of course, it is quite easy to design a javascript that will generate those tags too, and this can even be done by non-staff. The real problem is designing something that is simple enough for novices, but still allows advanced users to make as many customizations as they like.

      In the end there will always be a trade-off.

        Loading editor
    • Sebastian Marzjan wrote:

      Imamadmad wrote:

      I've done some testing and have run in to some problems with CSS. Over on my test wiki (...)

      If you prefix your styles with .portable-infobox class, the scope of the changes will be limited to the new infobox styling only. For example to style the headings you'd go along the lines of:

      .portable-infobox h3 {
         width:100%;
         background-color:#000000;
         color:#E8E5D4;
         margin:0;
         padding: 5px;
         border-radius:5px;
         box-shadow: 0 0 10px #DECFAD inset;
         font-family:Oswald,Arial,sans-serif;
         font-size:15pt;
         line-height:2em;
         text-transform:uppercase;
      }
      

      Thank you for trying this out and please let us know if you need more information/assistance!


      This seems like a lot of unnessacary work, just to customize this new template. If I'm understanding correctly, this bit of code is just for the headings. So if I wanted to add some more customization to various features of the template, I would need to type up more html(?) for each specific feature. Making templates was hard enough to learn, now you want to throw in more coding. Personally, I would prefer staying as far away from CSS as I can, while still having the ability to style templates anyway I want.

        Loading editor
    • This seems like a lot of unnessacary work, just to customize this new template. If I'm understanding correctly, this bit of code is just for the headings. So if I wanted to add some more customization to various features of the template, I would need to type up more html(?) for each specific feature. Making templates was hard enough to learn, now you want to throw in more coding. Personally, I would prefer staying as far away from CSS as I can, while still having the ability to style templates anyway I want.

      That is simply a result of added customization the person wanted. But wanting to stay away from CSS while still styling templates, is like wanting to take a shower without getting wet. You can't have one without the other. Of course there are tools to make it as painless as possible but in the end you're doing the same thing.

      Anyway, I will concede to one point. Currently, the only way to style these templates is by changing the Special:CSS page. What this means is that ultimately only admins can affect the infobox styles directly, regular users can change their user css but never the infoboxes. This takes away control from the masses and gives it to the very few. 

      This in my opinion is a major oversight. If we consider a wiki where the admins/bureaucrats are absent, it would mean that they are stuck using a default infobox styles or simply use the old style templates. At the very least there should be a way to have some preset styles that allow css changes by non-admins.

      Maybe there could be customized infobox CSS style transclusion from Dev.wikia.com or another central repository. 

        Loading editor
    • If there are no active admins or crats and someone is willing to edit templates, then that person should simply apply for adoption of the wiki. You'll find that on a lot of wikis - including here at Community Central - templates are protected so that only admins can edit them.

        Loading editor
    • Digifiend
      Digifiend removed this reply because:
      duplicate post
      17:04, June 6, 2015
      This reply has been removed
    • Cqm

      @Dessamator There's an RfC going on at mediawiki.org for per template stylesheets. It's probably the best idea going forward, but it'll be a while before it comes to wikia, if it ever does.

        Loading editor
    • Dessamator: that's a great point. Sometimes it takes a bit to adopt a wikia, and only having the choice to use the default skin wouldn't be sufficient. Once we have a set of standards in place - something that can be replicated and modified reasonably simply - I'll put it on dev.wikia.com.

        Loading editor
    • Ducksoup wrote:
      Dessamator: that's a great point. Sometimes it takes a bit to adopt a wikia, and only having the choice to use the default skin wouldn't be sufficient. Once we have a set of standards in place - something that can be replicated and modified reasonably simply - I'll put it on dev.wikia.com.

      I guess you understood my point perfectly. Beyond simply adopting, the core philosophy of Mediawiki is colaboration. The Mediawiki namespace, Special:CSS, and Common.js need to be restricted because they  can have disastrous effects on every single page and even Wikia's servers. But regular pages shouldn't generally require admin supervision because that stifles creativity.

      There is also an incorrect assumption that all admins know how to edit their Special:CSS, meanwhile ignorant admins could cause havoc to dozens of pages.

      Cqm wrote:
      @Dessamator There's an RfC going on at mediawiki.org for per template stylesheets. It's probably the best idea going forward, but it'll be a while before it comes to wikia, if it ever does.

      Thanks for the heads-up. That particular RFC has been going for 2 years. Chances are they will not reach consensus any time soon. But it is good to know progress is being made.

        Loading editor
    • Cqm

      RfC implementations are dependent on a variety of things, which are often dependent on even more things. It's not all that surprising.

        Loading editor
    • Stretched images

      Option to resize images needed as svg images are sometimes stretched. Example (second image with caption "Signature"), Template source.

      Option for Admins

      As some editors/admins have stated that they don't have the need for mobile infoboxes why not keep both types so editors can choose the type to use and add an option in Wiki Features so Admins can choose if they wish to enable PortableInfoboxes.

      Sharing Your PortableInfoboxes

      I have started to add my PortableInfoboxes to the Template Wiki in the category PortableInfoboxes.

      I hope others will do the same or suggest other options to find PortableInfoboxes so that we are not all spending time creating similar ones.

      PortableInfoboxes How Portable are they really

      Is it not really the fact that if a wiki uses complex code in an infobox it may well break even using the new PortableInfobox tags‽

      How well will they function if an editor uses the "verbatim" tag to embed HTML code for example‽ (Time will tell).

      Universal App

      How about an Universal App that a mobile user can use to search for and view any available wikia. The App could also provided a more interesting viewing experience then the current plain text view we currently get.

      I'll shut-up Now

      Sorry for going on too long, think my ASD is showing ;-) Robcamstone (talk) 12:25, June 3, 2015 (UTC)

        Loading editor
    • Robcamstone wrote:
      ...some editors/admins have stated that they don't have the need for mobile infoboxes

      Emphasis added.

      That's good for them. What about the readers that the content is for?

        Loading editor
    • DEmersonJMFM wrote:
      Robcamstone wrote:
      ...some editors/admins have stated that they don't have the need for mobile infoboxes
      Emphasis added.

      That's good for them. What about the readers that the content is for?

      I hope others that read this will go and read my comment in context.

      Why not ask the ones that feel they have no need for mobile infoxboxes, I can't speak for them?

      As I see it an infobox is just a way to display a block of inforamtion quickly, it could be argued that infact the mobile website could just ignore all data within an infobox and just show the main data in the article or have a smiple tag system for data that should not be displayed on the mobile.

      Then creators of the wikias could create content that works on both mobile devices and PCs

      Possible Example

      <device=pc>
      {{infobbox book}}
      </device>
      
      <device=mobile>
      {{portableInfobox book}}
      </device>
      
      <device=all>
      == A B C Book ==
      It's about the alphabet.
      </device>

      Note: Above example is just an idea it will not work.

      I hope future comments will be more constructive and aimed at the individuals it relates to.

      Just being negative only damages/delays development of future resources.

        Loading editor
    • How was my comment "negative?" I just pointed out the problem with that line of thought.

      Going back to what you posted twice: Why duplicate the information/coding when the same goal can be achieved with half what you mention? Did you read/look at any of the above examples that have been posted? There's no need to hide infoboxes from mobile. This proposed markup improves them while maintaining previous infobox design for non-mobile if you chose to. What you propose will likely lead to more problems, one obvious one is the high likelihood information between the infoboxes won't maintain consistent information.

      If Admin had the choice to enable the new markup a similar situation such as people choosing to use the page previews (failure to do so constructively lead to the new layout changes) will likely occur.

      If there isn't something that can be done with the new markup you should specifically mention it so Staff can consider looking into it. Now that the markup is in beta, now's a great time to test any concerns you might have.

        Loading editor
    • Robcamstone wrote:
      [...] it could be argued that infact the mobile website could just ignore all data within an infobox and just show the main data in the article or have a smiple tag system for data that should not be displayed on the mobile.

      I'm not sure if you simply used the term data incorrectly to refer to something else, but I doubt anyone would want to see different data whenever they switch devices. The data (information in the infoboxes) should always stay the same independent of what device you use. I'd be surprised if you are able to find any admin, editor or reader who would want to see different data.

      Based on what you say in the rest of your comment, I assume you were actually referring to the styling of the infobox instead of the data. If I understand you correctly, with the ideas you were proposing you were trying to make it possible to have the infobox in the desktop site look different from the infobox in the mobile site. If that's exactly what you wanted, I have good news for you: it's already possible! :) Just check out the pages in my post above in different devices and notice the difference!

        Loading editor
    • Based on what you say in the rest of your comment, I assume you were actually referring to the styling of the infobox instead of the data. 

      There is one good point raised by Robcamstone. Sharing templates is really a nice approach to reducing time spent creating these. But styling  won't be carried over when these pages are imported.  For example, while the templates can be previewed in the templates.wikia, different styles won't be visible. Short of asking a templates.wikia admin to add a bunch of "stylish preset css", anyone looking at the default infobox theme would probably think that it looks particularly "old fashioned".

      It is a shame though that portable infobox code doesn't allow importing CSS from a page, aside from using Common.js or Special:CSS. This would make it simpler to easily import any templates along with default styling, and without worrying about asking "permission" from admins.Although, perhaps a javascript hack could add this functionality. Anyway,  while templates wikia serves as a perfect place to store frequently used templates perhaps dev wikia can serve as a place to store Portable infobox CSS. 

      Added: This brings me to another point. Template transclusion is only allowed from community.wikia.com. Perhaps if a namespace is added to Templates.wikia or community wikia for infobox templates, this would reduce the time spent creating these. In some cases such as the "book" infobox, there wouldn't be a need to change the tags, but only the css styling so transcluding the page would probably be enough.

      These could also be automatically imported when a new wikia is created.

        Loading editor
    • Dessamator wrote:

      Sharing templates is really a nice approach to reducing time spent creating these. But styling won't be carried over when these pages are imported. For example, while the templates can be previewed in the templates.wikia, different styles won't be visible. Short of asking a templates.wikia admin to add a bunch of "stylish preset css", anyone looking at the default infobox theme would probably think that it looks particularly "old fashioned".

      Sharing templates is indeed a good idea. However, I'm a bit puzzled why you consider it a bad thing that the styling won't be carried over when someone uses a shared template. I remember your talk about the different "layers" here. According to your logic, the templates shared on Templates Wiki are only the layer that contains what kind of data is stored. Users who copy over a Book template don't do it for the colors, fonts and other styling of the template in Templates Wiki (or are bothered by how "old-fashioned" it looks), they only care about the ready made code they can quickly use on book pages. The styling itself they can copy over from any wiki that is using the Portable Infobox and apply it to their own Book infobox, even if the wiki they copy from don't have a Book infobox.

      Dessamator wrote:
      Anyway, while templates wikia serves as a perfect place to store frequently used templates perhaps dev wikia can serve as a place to store Portable infobox CSS.

      Yes, it may be a good idea to have a central place where people can share different styling of infoboxes that people can copy over, independent of what template they use. That could also help people to see the different layers as separate.

        Loading editor
    • The layers still apply. The problem is that we can't just do something like :

      Scenario A:

      1. Go to templates.wikia
      2. Pick a nice template
      3. Add template information
      4. Look at different styling options
      5. Add custom style <infobox theme-source="w:c:templates:BookInfo/box_chrome.css">

      Scenario B: Currently the process is:

      1. Do 1 ->3 above, then think of CSS to use or ask someone to create one
      2. Beg an admin to add it to the global css
      3. Give-up and use old style templates or leave the default theme

      The problem is that in this case all these things are stored far away from each other, and it'll be quite hard to get them. Step 5 in scenario A can't be done using the current infobox templates, and likely won't ever be possible.

      Although, there is a possibility of adding such styles automatically using lua, but I'm not sure if the portable infobox doesn't simply ignore inline css.

        Loading editor
    • User:Dessamator and User:Ohmystars have both made important points about the styling problem when sharing templates.

      The other problem is any custom CSS would have to be modified again for each wiki it is to be used on to reflect that wikis' design.

      I wonder how much of the styling could be done uing the <div style> tag it could be one way around the need to share custom CSS.

      It seems styling is going to be the biggest problem for wikia engineers to over come while letting wikis' keep their individuality.

      My thanks to all for the feed back and helpful links about using custom CSS to style portableInfoBoxes.

      I guess I will have to start to learn CSS, which is a good thing it's good for the brain to keep on learning new things.

      I still believe the sharing of Portable Infobox Templates even without styling is important.

        Loading editor
    • If I understand you correctly, the user gets stuck when they have to: "Beg an admin to add it to the global css". I don't really see that as such a major problem.

      • Admins shouldn't feel bothered, since it's his/her duty to help other users and implement things that other users can't. And it's not even that much work if the user has the CSS ready that the admin only need to paste.
      • It might be even a good idea that admins are involved in the process, since CSS applied to an infobox widely used on hundreds of pages in a wiki can have great consequences. It would be a good idea if an admin reviews it first.
      • If the user gives up just because they regard the admin as such a a great barrier, then the user either has a bad relationship with the admins (a problem unrelated to infoboxes and something they have to solve themselves first) or the user knows the styling and/or stuffs in the infobox won't be approved by the admin, so even if it was possible to do step 5 in your scenario A, the edits would still be undone by the admins or other users.
        Loading editor
    • I wrote the post ^ above, but got logged out accidentally. It is directed to Dessamator.

        Loading editor
    • I was just indicating the major blockers, Styling, Collaborating, approving. If I want to change any Portable Infobox (potBox) as an admin I can simply go and mess around with Special:CSS. But the vast majority of users won't have this priviledge. Just to test out the potBox a normal user needs to :

      1. Go to Special:Mypage/common.css/or change it in their browser
      2. Add new css rule
      3. Test out different versions.
      4. Once done, one needs to print screen the new template, and show it to others to get get feedback, and they also need to do the same thing to get feedback on their suggestions. Imagine trying to show 5 or more suggestions.

      Beyond that, Special:Mypage/common.css is as equally restricted as Special:CSS, so other people can't simply look at someone's css and change it directly. They need to create their own pages/ or test it using their browser console, and once again submit screenshots. This greatly affects the workflow and collaboration.

      Unless of course a javascript hack is created that imports a potBox css from a common sandbox where everybody can go and mess around with it. But again, this is only possible with admin help, or everybody will need to import the js to their profile. The point is that testing the styling shouldn't be this hard, even with an admins help.

        Loading editor
    • People can use Community Test wiki to test infoboxes. Apparently, everyone has admin rights there so people would be able to update the CSS. They can create different versions  and show the pages to others for feedback. So yes, "people can simply look at someone's css and change it directly".

        Loading editor
    • Ohmystars wrote:
      People can use Community Test wiki to test infoboxes. Apparently, everyone has admin rights there so people would be able to update the CSS. They can create different versions  and show the pages to others for feedback. So yes, "people can simply look at someone's css and change it directly".

      That would work, except for the fact that infoboxes use lua modules,  a bunch of other extensions, tabber, and customized javascript (that could be affected by styling) that may or may not be exist in that wiki. People will have to figure out all the dependencies for a previous template,  and also the specific extensions to be added. As far as I know special:Export doesn't figure out which scripts are needed and export them too. They'd have to go through that hassle everytime they test an infobox with different requirements.

      Having contributors  use another wiki, even community wiki to just test styling seems excessive.

        Loading editor
    • Dessamator wrote: Beyond that, Special:Mypage/common.css is as equally restricted as Special:CSS, so other people can't simply look at someone's css and change it directly.

      False. You can go look at other people's personal CSS. For example, to use a random other user, you can see User:CzechOut/wikia.css just fine and can copy any you like. You can't edit it, but you don't need to edit it to copy and use it.

      Anyway, if you're planning on styling templates for wikis you're not an admin on en masse, or even if you want to change a lot of CSS on wikis you are an admin on but don't want to make things look worse while you're still trying out various things, then I recommend you get a test wiki. On your own test wiki, you can mess with as much styling as you'd like without interrupting others' editing, allowing you to try things out and have them fail without it hampering others. You can ask Staff to enable as many extensions as you need to properly test templates for your home wiki, and you can organise your CSS as you wish without having to worry about messing up any standards set beforehand. On top of that, if you write your CSS on separate pages in your test wiki, you can just get people to import the styling from your test wiki into their personal CSS to see what it looks like before approving it, or you could even just constantly restyle your test wiki to match the look of the wiki you're templating for so the admins of that wiki can view what the template looks like on your test wiki before approving the CSS. It is ridiculous how handy having a test wiki is.

        Loading editor
    • Imamadmad wrote:

      False. You can go look at other people's personal CSS. For example, to use a random other user, you can see User:CzechOut/wikia.css just fine and can copy any you like. You can't edit it, but you don't need to edit it to copy and use it..

      Well, that's a conditional statement. Look AND change, so it is true. It might have been false if I wrote, look OR change. The reason I bring that up, is because small differences like that affect programming, and even css changes. One fact that people always seem to forget is that the more you know the harder it is for you to do things in a simple manner. The arithmetic 8/2* 3 is a hard concept, but once one has learnt it, one can perceive it to be easy.

      The majority of wikia users are not programmers, nor are they knowledgeable of all the hacks and functionality and permissions you can use to get something "simple" working. To illustrate this point, a complete beginner can come to wikia look at a template see its syntax and instructions on how to change the color of text, simply change something from "yellow" to "green" in the source, preview it and post it with  0 knowledge of css.

      I consider myself a very advanced user of wikia, yet I didn't know the community test wikia users were all admins, nor would I expect a novice or the vast majority to know how to do all the things you describe.  One core principle of software design that developers sometimes seem to forget, is that you create software taking people's backgrounds and expertise into account. So despite supporting the core principle of this potBox design, I still believe that catering to the elite few is a basic violation of that principle.

        Loading editor
    • Imamadmad wrote: For reference:

      Based on Imamadmad's w:c:Imamadmad:MediaWiki:BCW_infobox_v2.css I have started a help page on one of my wikis' The Styling of a PortableInfobox. I hope it will help others and hope to improve on it as I learn more.

      My Thanks to User:Imamadmad for the code that got me started.

        Loading editor
    • Ohmystars wrote:

      Bruce A wrote:

      • It seems to take up too much vertical space
      • I feel it'll look better with a border around it. 
      • The lines that separate sections, I don't know, something about them doesn't feel right. 
      • The text size looks too big. Compare it to Wikipedia's info boxes
      Hey Bruce A, all the things you mentioned are all just a matter of styling. I know this thread is long and you probably didn't bother to read previous posts, but it is announced in #114 that custom theming of the infobox is now possible and several people have posted custom styling of the new infobox.
      • I've replicated 3 looks of infoboxes from top wikis: see my posts #72, #81 and #92.
      • I also helped out DEmersonJMFM with the styling of the infoboxes in his wiki, check out any page on his wiki for infoboxes using the new tags.
      • Imamadmad has also tested the infobox with a custom style (see #82).
      • The Elder Scrolls wiki is using the new infobox with a custom style.

      So feel free to create your own theme (or ask people to help you) and implement all the points you mentioned above. You can even make it look exactly like the infobox in Wikipedia if that's what you want.

      My point is, however, that we should try to aim for a default style that is good and doesn't really need to be re-styled, unless people really want to. 

      Since, as I said, the default style that appears to be what we're moving to isn't very good. And I feel that's a shame. 

        Loading editor
    • Bruce A wrote:

      My point is, however, that we should try to aim for a default style that is good and doesn't really need to be re-styled, unless people really want to.

      Since, as I said, the default style that appears to be what we're moving to isn't very good.  

      What is "good?" How do we aim for "good?"

      The default style works consistently great for mobile, that is good.

      The current default style (not associated with the new markup) of infoboxes isn't anything to be excited about either (very basic design, no color). At least Wikia decided to add some of the wikis' theme color to the new infoboxes automatically (a leg up on the old default style).

      The more styling you place into a default, the more likely the styling won't fit for a wiki and people will seek to change it (even if people were going to change it anyway). For some wikis, the default styling (with the theme colors) fits in well, but with the main wiki I edit, I didn't think that it worked so it was restyled (one of the problems with adding more to a default). If you have a specific objective, you will restyle to meet that objective (as Wikia did with the markup), regardless of the default. A default will not meet everyone's objective anyway.

      If people are not going to apply their own styling, how would you style a default that meets the objective of looking great on mobile consistently when loaded with information while also being the same default elsewhere?

        Loading editor
    • Good points overall. The only thing that I think they could do is add the ability to choose a custom preset styling, e.g. "<infobox theme-source="chromeDesignDefault"> </infobox>. This would automatically be imported to a infobox regardless of whether the style exists locally. 

      As far as that "chromeDesignDefault" is concerned, Wikia could have a contest, a competition or some other "event" to get a design that would act as a secondary to those automatically defined by the admin using theme designer.

      But like you said, chances are that there'll never be consensus on what a good theme design is, but at least there could be a "good enough/acceptable" design better than the current default one.

        Loading editor
    • Dessamator wrote:

      This seems like a lot of unnessacary work, just to customize this new template. If I'm understanding correctly, this bit of code is just for the headings. So if I wanted to add some more customization to various features of the template, I would need to type up more html(?) for each specific feature. Making templates was hard enough to learn, now you want to throw in more coding. Personally, I would prefer staying as far away from CSS as I can, while still having the ability to style templates anyway I want.

      That is simply a result of added customization the person wanted. But wanting to stay away from CSS while still styling templates, is like wanting to take a shower without getting wet. You can't have one without the other. Of course there are tools to make it as painless as possible but in the end you're doing the same thing.

      Anyway, I will concede to one point. Currently, the only way to style these templates is by changing the Special:CSS page. What this means is that ultimately only admins can affect the infobox styles directly, regular users can change their user css but never the infoboxes. This takes away control from the masses and gives it to the very few. 

      This in my opinion is a major oversight. If we consider a wiki where the admins/bureaucrats are absent, it would mean that they are stuck using a default infobox styles or simply use the old style templates. At the very least there should be a way to have some preset styles that allow css changes by non-admins.

      Maybe there could be customized infobox CSS style transclusion from Dev.wikia.com or another central repository. 


      The point was, as someone with probably the bare minimum in coding html/CSS, this is overwhelming. That person asked about customization, and was given an example based on headers; headers are just one piece of a template. Which would mean in order to change anything else I would need to add another set of code similar to that based on what I wanted, and pray that I didn't mess anything up so that it shows correctly. I've only used CSS on a wiki once or twice, and from what I remember, the response time is not great. So, on top of not allowing regular users the ability to style a template from the original wiki they're on. Adding the styling to the CSS has a bit of a delay.

      Hopefully these question can be answered; but I don't understand why the current template can't be tweaked, not completely overhauled, to display a better table than it already does on mobile. From what I can tell, it doesn't register separate tabs correctly, images in templates-or the wiki in general- appear larger than they're meant to be- regardless of what size is set for it, it doesn't register the styling for- not just the template- but the wiki in general.


      • But couldn't it just create another table for each tab? There seemed to be some level of collapsible feature on the wiki I'm most active on, despite the fact that those infoboxes don't have any collapsible elements to them.
      • Are images and styling going to be fixed afterwards? For images, is that a coding problem on the individual wiki's side?
      • What's the point of having styling appear for mobile users with the new infobox/template, if the rest of the page still looks like a default wiki?
        Loading editor
    • EternalLocket wrote:
      I've only used CSS on a wiki once or twice, and from what I remember, the response time is not great. So, on top of not allowing regular users the ability to style a template from the original wiki they're on. Adding the styling to the CSS has a bit of a delay.

      I'm sorry for being nitpicky, but I think there are some serious misunderstanding here as to what CSS means. It's not just this reply from EternalLocket, but the way many other users responded earlier.

      From Wikipedia:

      Cascading Style Sheets (CSS) is a style sheet language used for describing the look and formatting of a document written in a markup language.

      Somehow people describe it like it's some additional tool or feature that people can choose to use (like the Theme Designer) and that has a bad response time. It's not. It's a style sheet language. You don't "add styling to the CSS" (like it's a tool), you style with CSS (the language). When you say you "style a template" within the template page, then you are in fact styling with CSS in the template. Anything you place within style="" is CSS. Any other way you style things in your template, you most likely do that with CSS.* So if you say you used CSS only once or twice, then that's most likely false. You use it every time you change the styling in the template. And the so-called bad response time? You do use CSS within your template, and yet there's no delay! The "delay" has nothing to do with CSS (the language) at all.

      What people are actually talking about is the attachment of CSS into a separate stylesheet as opposed to including it inline in a template. When CSS is served from an external file, it is cached by your browser for performance (in case you didn't get: this is a good thing, as web pages load much faster), but the consequence of caching is that the CSS changes may not show its effects instantly for you (anyone else who didn't have the files cached yet could see the changes without delay).

      * Unless you still use the deprecated HTML tags like <font size="3" color="red">...

      EternalLocket wrote:

      From what I can tell, it doesn't register separate tabs correctly, images in templates-or the wiki in general- appear larger than they're meant to be- regardless of what size is set for it, it doesn't register the styling for- not just the template- but the wiki in general.

      [...] Are images and styling going to be fixed afterwards? For images, is that a coding problem on the individual wiki's side?

      Not sure what you mean with "separate tabs". Problems with "images appearing larger in all templates or the wiki in general" don't seem to have anything to do with the new infoboxes, the same with "styling for the wiki in general".

        Loading editor
    • "I'm sorry for being nitpicky, but I think there are some serious misunderstanding here as to what CSS means."

      Thanks Ohmystars. I was going to post something similar earlier, but I knew someone else (like yourself) would explain it much better than myself. I'll admit earlier I stated CSS wasn't in templates, though before I remembered inline styling is still CSS.

      "The only thing that I think they could do is add the ability to choose a custom preset styling, e.g. "<infobox theme-source="chromeDesignDefault"> </infobox>. This would automatically be imported to a infobox regardless of whether the style exists locally."

      I think that's an interesting idea giving users options of multiple default designs. Something like this could work. CSS of course could vary per design and not interfere with others. As stated before, recognizing the mobile view is still the priority and will unfortunately not satisfy everyone still that don't want/are afraid/don't know how to style infoboxes outside the template.
        Loading editor
    • @Ohmystars I don't have any formal training in html/CSS, which is why I described it that way. So to clarify: "I've only used the CSS function in the admin section on a wiki once or twice". So that is were I was experiencing a delay. The delay is a problem, as the one who may be styling it, I'd rather have instant feedback on what it looks like; instead of trying to find some work around.

      Either in the original post or somewhere in the comments, it was mentioned this new template was needed for mobile users because it couldn't handle complex things like: collapsible sections and tabs/tabber. One of the wikis I'm on uses a tab like feature for the images in the infobox, but they show up one on top of the other; instead of like they should with the tab feature.

      Considering they're fiddling with templates for the sake of the mobile users, I see no reason why they can't address these problems at the same time. As they do effect the template as well. In the original template, image sizes and styling in the template appear to be ignored. The general message was, "what's the point of a spiffy new template, if everything else for mobile users looks just as worse as before?"

      Regardless, they were questions directed at staff, as they would have more insight into why these are problems.

        Loading editor
    • EternalLocket wrote: @Ohmystars I don't have any formal training in html/CSS, which is why I described it that way. So to clarify: "I've only used the CSS function in the admin section on a wiki once or twice". So that is were I was experiencing a delay. The delay is a problem, as the one who may be styling it, I'd rather have instant feedback on what it looks like; instead of trying to find some work around.

      If you're editing your wiki's CSS through Special:CSS, then you just need to hit Ctrl+F5 to see the changes (as that clears your browser's cache). You only have to wait if you're editing CSS on a page which is then imported into Special:CSS, but I doubt you're doing that at this stage.

        Loading editor
    • DEmersonJMFM wrote:
      I'll admit earlier I stated CSS wasn't in templates, though before I remembered inline styling is still CSS.

      Yes, inline style is also CSS. However, heavy usage of inline CSS is actually considered bad practice in web design. As explained here, "Inline styles should only be used as a last resort, or set by Javascript code." Apart from better performance thanks to caching, attaching CSS to an external stylesheet also "provides a clear separation of markup from styling; produces cleaner HTML markup; is more efficient with selectors to apply rules to multiple elements on a page improving management as well as making your page size smaller."

      EternalLocket wrote:
      So to clarify: "I've only used the CSS function in the admin section on a wiki once or twice". So that is were I was experiencing a delay.

      You're talking about Special:CSS, which is not some "function", but just an editor that allows you to edit the MediaWiki:Wikia.css page. The editor itself does not cause any delay at all, your changes are live the moment you saved them and others can see them instantly. As I (and Imamadmad) said before, that what you experience as a "delay" is only your browser cache that needs to be refreshed. But if you really want instant feedback without having to save and/or refresh anything, you could consider using built-in developer tools in most modern browsers (Firefox, Chrome, Safari..) or if that's still way too advanced try the PortableCSSPad script.

        Loading editor
    • The problem with the "delay" may be just that one needs to save all changes to Special:CSS before being able to see how they will look like in the template. Inline styling shows up in the preview. However, as Ohmystars said, a simple solution is to edit the HTML page with browser tools and then copy everything into the stylesheet. Might be too complex for some people though.

      By the way, this is also the problem I have with templates in general. When I edit them, they usually require some complicated parameters that I can't set in the preview. I need to invoke the template, but my changes won't show up until I save it and purge the page. Sometimes I make mistakes and end up with a lot more edits than I needed. Or should I be happy about bumping up my stats?

        Loading editor
    • Nathan2000 wrote:

      By the way, this is also the problem I have with templates in general. When I edit them, they usually require some complicated parameters that I can't set in the preview. I need to invoke the template, but my changes won't show up until I save it and purge the page. Sometimes I make mistakes and end up with a lot more edits than I needed. Or should I be happy about bumping up my stats?

      That's unavoidable with bad template design, and a side-effect of overloading the usage of templates. When they were originally designed they were only meant to transclude text or simple figures. But as mediawiki required more and more things, they added more functionality into parserfunctions(PFs), breeding bad practices that will remain until PFs are dead and buried. Now Frankenstein  (PF-based templates) is too hard for mediawiki to control anymore. These bad practices run so deep that editors think nothing of adding some complex code like the image below.
      MarvelCharacterTemplate

      A good template would have to make use of dozens of templates to become readable. That's programming 101, each function/module should do just one task. Trouble is  that it will still have to transclude dozens of pages each making it take more and more time to load. My suggestion is that for complex templates one should ditch wikitext and use lua.

      Anyway, as far as CSS and these new potBoxes are concerned, the easiest way to test the styling on the infoboxes is to preview the infobox, copy the code for the infobox, paste it into a page, play around with it, and merge the css into the Special:CSS once you're done.

        Loading editor
    • Dessamator wrote:

      A good template would have to make use of dozens of templates to become readable. That's programming 101, each function/module should do just one task. Trouble is  that it will still have to transclude dozens of pages each making it take more and more time to load. My suggestion is that for complex templates one should ditch wikitext and use lua.

      How does using Lua fix the problems with testing parameters? Or is the answer "don't use conditional behavior" that severly limits the creators and still doesn't protect against typos?

        Loading editor
    • Nathan2000 wrote:

      How does using Lua fix the problems with testing parameters? Or is the answer "don't use conditional behavior" that severly limits the creators and still doesn't protect against typos?

      The testing of parameters can be automated. You can run 1000 tests easily using unit testing . Wikipedia, for example,  has some frameworks for it . It also hides away the complexity of the template in a module, which can in turn access 50 other modules for repetitive work. Conditional behaviours in templates always look untidy and tend to repeat themselves.The worst part of it is that it is one hell of a problem to understand them. So much so that the creator may find it difficult to make changes,document or explain how it works to others. 

      Even these new potBoxes can be easily debugged and tested with no problems.

      The short answer is that in the best case scenario most Frankenstein-based templates take much more time to create, debug, run and test, and contain a lot of repeated code for no good reason. 

      See Lua_templating/Converting_Wikitext_templates.

        Loading editor
    • I will say one thing in favour of these parser function based templates: They're much easier to learn than Lua. Wikitext templates with parser functions was the first touch of programming I ever had, and because it was relatively easy to learn, it whetted my appetite to look into programming further rather than scarring me off at the first hurdle. While parser function templates can turn ugly if used for purposes far beyond what they were designed, for most instances, they work perfectly well and allow users a friendly first look into things such as holding repetitive code in separate modules (analogous to functions/methods) and conditional statements, some of the foundations of programming. So I actually think that in most cases, wikitext based templates using parser functions are actually better than using Lua on smaller templates, which are in the majority of templates used, as it reduces the amount of hunting to find each needed part of the code, analogous to holding all methods of a short program in a single file. Just my two cents to add in defence of these "Franken-templates".

        Loading editor
    • Dessamator wrote:
      Unless of course a javascript hack is created that imports a potBox css from a common sandbox where everybody can go and mess around with it. But again, this is only possible with admin help, or everybody will need to import the js to their profile. The point is that testing the styling shouldn't be this hard, even with an admins help.

      So I've thought about what you said. What you propose is actually already possible without any hacks:

      1. A user creates a stylesheet page in the Community Test wiki, for example MediaWiki:Infobox Disney.css
      2. The admin of the Disney wiki then imports the stylesheet with importArticles() method in their wiki: "w:communitytest:MediaWiki:Infobox Disney.css"
      3. Now everyone can mess around with the CSS in the Community Test Wiki and the changes are applied live to the Disney wiki.
        Loading editor
    • Dessamator wrote:

      The testing of parameters can be automated. You can run 1000 tests easily using unit testing . Wikipedia, for example,  has some frameworks for it . It also hides away the complexity of the template in a module, which can in turn access 50 other modules for repetitive work. Conditional behaviours in templates always look untidy and tend to repeat themselves.The worst part of it is that it is one hell of a problem to understand them. So much so that the creator may find it difficult to make changes,document or explain how it works to others. 

      Even these new potBoxes can be easily debugged and tested with no problems.

      The short answer is that in the best case scenario most Frankenstein-based templates take much more time to create, debug, run and test, and contain a lot of repeated code for no good reason. 

      See Lua_templating/Converting_Wikitext_templates.

      I have no problem understanding my templates, thank you very much, and I'm not sure if the task of checking if three optional parameters render correctly before I commit the template requires learning a new scripting language and several testing frameworks, that will fail it anyway because they work server-side. No offence, but you offer an 88 mm cannon to someone complaining about mosquitos.

        Loading editor
    • Ohmystars wrote:

      So I've thought about what you said. What you propose is actually already possible without any hacks:

      1. A user creates a stylesheet page in the Community Test wiki, for example MediaWiki:Infobox Disney.css
      2. The admin of the Disney wiki then imports the stylesheet with importArticles() method in their wiki: "w:communitytest:MediaWiki:Infobox Disney.css"
      3. Now everyone can mess around with the CSS in the Community Test Wiki and the changes are applied live to the Disney wiki.

      Step 2 is the problem and limitating factor, getting permission to change simple styles. But anyway it is a nice idea in wikis where the admin is present and understanding.

        Loading editor
    • Imamadmad wrote:
      I will say one thing in favour of these parser function based templates: They're much easier to learn than Lua.

      Sure they are, because they are discrete functions addressing one problem at a time. If you design a module you have to understand quite a few things about programming. If the Franken-Templates were being used properly, I would agree. But personally, a Franken-Template would have an adverse effect on using wikia if I was younger. That whole soup of curly brackets, brackets, html tags is detrimental to pages. Especially when there aren't any conventions being followed. It is the wild west out there.

      So I actually think that in most cases, wikitext based templates using parser functions are actually better than using Lua on smaller templates, which are in the majority of templates used, as it reduces the amount of hunting to find each needed part of the code, analogous to holding all methods of a short program in a single file. Just my two cents to add in defence of these "Franken-templates".

      That's another problem altogether made worse by Franken-templates. Many people re-invent the wheel unnecessarily because they don't know a good solution that has been tested exists. Rather than wasting time re-inventing the wheel people should be using their time innovating, finding solutions for new problems.

      Wikia is/was working on making module transclusion a reality, and that could eliminate that argument altogether as global modules will be stored in a centralized repository.

        Loading editor
    • Dessamator wrote:
      Step 2 is the problem and limitating factor, getting permission to change simple styles. But anyway it is a nice idea in wikis where the admin is present and understanding.

      If an admin just add the import line before they leave the wiki, then anyone can change the styles without having to gain admin rights or having to adopt the wiki. And when the wiki is eventually adopted, the new admin can move the CSS rules from the Community Test wiki to the wiki's stylesheet. This is wishful thinking though, because the admins who leave usually don't care about such things.

        Loading editor
    • Cqm

      Sorry to be a buzzkill, but I would never recommend importing any CSS or JS from a place that is not 100% trustworthy. If you keep your CSS/JS on community test, then I can edit it to anything I want. If I can do that, so can everyone else. There's a reason it's kept in a separate namespace only admins can control and that reason is because people can do nasty things with both languages and render your wiki unusable.

        Loading editor
    • Cqm wrote:
      Sorry to be a buzzkill, but I would never recommend importing any CSS or JS from a place that is not 100% trustworthy. If you keep your CSS/JS on community test, then I can edit it to anything I want. If I can do that, so can everyone else. There's a reason it's kept in a separate namespace only admins can control and that reason is because people can do nasty things with both languages and render your wiki unusable.

      That's true. But it should be possible to restrict the changes and effects to one page. After all wouldn't the same apply if they manage to add template-specific css styling?

      The changes to that template will affect every single page that transcludes it, and if misused could cause widescale damage.

        Loading editor
    • Cqm

      It would still apply, but seeing as the MediaWiki devs have gone to lengths to make sure CSS and JS aren't editable by everyone and are acutely aware of security in their product, it's never going to be editable by anyone. It might come with a new user right or it might be tagged onto something else, but it's definitely not going to be unprotected.

        Loading editor
    • Not sure if there's a more efficient way, but I suppose you could use a <verbatim> tag to inject the CSS into a specific template only, like how I injected this in a template. But you're right, cqm, it's a big risk, even if the damage is limited to one template. I wouldn't recommend anyone doing it this way, it was just a method I thought of in response to Dessamator's idea of a central sandbox. I guess it might be useful temporarily if an admin wanted users to help out designing a specific template. After the design on a sandbox template is approved the admin could then move the CSS rules to the wiki's CSS, and remove any import from the Community Test Wiki.

        Loading editor
    • It is not really that hard to make it more secure. It is simple enough to create a structured page with styles, and have the javascript parse it, validate all the existing tags (ignoring everything else) in the page, then translate it to css and show it in a particular page.

      Of course the downside is that you'd have to create a syntax easy enough to use, and easy to parse. In fact it could even be made in such a way that it specifically targets the potBox tags and nothing else, but that will take some time and thought to get it right.

        Loading editor
    • Infobox resizing
      I found some small problem connected with the typography change from April. When I maximize the window, the infobox has the same width, but the font increases and some text annoyingly breaks. See here: Infobox character. I think either the text in the infobox should be exempt from resizing or the box itself should resize with it.
        Loading editor
    • Nathan2000 wrote:
      I think either the text in the infobox should be exempt from resizing or the box itself should resize with it.

      I agree, preferably if the text was exempt. Resizing the infobox can create problems if the infobox is meant to be a fixed width (in order to prevent images from artificially enlarging).

        Loading editor
    • Hello,

      Recently we are thinking about building tools that would increase adoption of new portable infoboxes among admins and communities. I've built a prototype of a tool that allows to preview how infoboxes could/would look like if particular syntax was used to create them.

      Please take a look at it here: http://infoboxpreview.appspot.com/

      I'm looking forward to hearing feedback, comments and ideas from you!

      (It was tested only on Chrome and at this moment works the best for killbill.wikia.com - reference to their CSS is hardcoded.)

        Loading editor
    • This looks quite nice. The biggest hurdle for adoption that wikia has, is reducing the difficulty of adding these tags, and some way of determining if the syntax is correct. Matching <data></data> tags is particularly difficult for a novice, especially when they don't understand why it is there, or that they sometimes don't come in pairs.

      Another point is that automatically indented code tags are more readable, even for complete novices.

      One thing about that site though, are we simply supposed to play around with killbill's templates or can we test other templates?

      I don't see any way of pushing data from other wikia domains or templates to that page..

      Edit: In short we need some clean way of reducing those tags, also, it would be nice if we can input some custom test data to make sure it will work properly with it.

        Loading editor
    • You just need to change value in fields Wiki domain (e.g. "saintseiya.wikia.com") and Template name (e.g. "Infobox/Seiya/Character"). In this particular case you will notice that images are not going to appear - that's because that template on that wikia is using "image name" as a key for image - so just change it source attribute of <image> tag in the infobox.

      The value here is that you can see a preview with real values that are actually passed on that wikia to that template (currently preview is always for up to 10 transclusion of the template but this can be changed).

        Loading editor
    • Dessamator wrote:

      One thing about that site though, are we simply supposed to play around with killbill's templates or can we test other templates?

      I don't see any way of pushing data from other wikia domains or templates to that page..

      It works for me. You need to type the wiki address and the name of the existing infobox (not necessarily "potBox", as you call it). It appears to be scanning for pages that use it and showing how they would look like after the migration, albeit with default colors.

        Loading editor
    • I just update Infobox Preview tool to use very simple XML editor instead of plain textarea. I think it will definitely help as it provides basic syntax highlighting, typing completion and support for proper code indentation (with tab key).

        Loading editor
    • I see. The problem is that there is a bug somewhere. My guess is that because most of the pages in my wiki that actually use the potBox are redirects. So it is attempting to get redirected pages and ends up with an error:

      Uncaught Error: Syntax error, unrecognized expression: #Lingot_store/Progress_quiz

      So the problem is likely related to redirects.

      Edit: I'll test it out once wikia's API refreshes and adds a new page with another infobox.

        Loading editor
    • Dessamator wrote:
      I see. The problem is that there is a bug somewhere. My guess is that beacuse most of the page in my wiki that actually use the potBox are redirects. So it is attempting to get redirected pages and ends up with an error:

      Uncaught Error: Syntax error, unrecognized expression: #Lingot_store/Progress_quiz

      So the problem is likely related to redirects.

      Please try again now (remember to clear cache before). If it still doesn't work please provide me with values that you are entering into "domain" and "name" fields. Thanks.

        Loading editor
    • Inez wrote:
      Dessamator wrote:
      I see. The problem is that there is a bug somewhere. My guess is that beacuse most of the page in my wiki that actually use the potBox are redirects. So it is attempting to get redirected pages and ends up with an error:

      Uncaught Error: Syntax error, unrecognized expression: #Lingot_store/Progress_quiz

      So the problem is likely related to redirects.

      Please try again now (remember to clear cache before). If it still doesn't work please provide me with values that you are entering into "domain" and "name" fields. Thanks.

      Its fixed.  My next suggestion is to import the template wikitext for the infobox automatically. If we leave the textfield empty, it doesn't fetch the template unless we add some potBox tag there, so it appears as if the preview didn't work. Just in case it isn't another bug caused by the wiki:

      domain :duolingo.wikia.com ; template:  StoreInfobox

      Edit: And maybe add a label indicating that that area is meant to contain infobox tags.

        Loading editor
    • Inez wrote:Recently we are thinking about building tools that would increase adoption of new portable infoboxes among admins and communities.

      Hello, nice to hear you guys are working on ways to make it easier to implement the infobox. I think the biggest stumbling block for the average admin is the coding. Some already get a headache just seeing the XML tags, so I doubt they would bother studying the instructions in the Help page and test it out in your preview tool. IMO, the best way to increase the adoption is to make the coding "invisible" during the creation process. Make a GUI tool that allows users to fill in the data label and source in input fields, create groups, then add a button at the end to generate the XML tags which they can copy and paste in a template. The more advanced users can always adjust the code if they want and/or know how.

        Loading editor
    • Ohmystars wrote:
      Inez wrote:Recently we are thinking about building tools that would increase adoption of new portable infoboxes among admins and communities.
      Hello, nice to hear you guys are working on ways to make it easier to implement the infobox. I think the biggest stumbling block for the average admin is the coding. Some already get a headache just seeing the XML tags, so I doubt they would bother studying the instructions in the Help page and test it out in your preview tool. IMO, the best way to increase the adoption is to make the coding "invisible" during the creation process. Make a GUI tool that allows users to fill in the data label and source in input fields, create groups, then add a button at the end to generate the XML tags which they can copy and paste in a template. The more advanced users can always adjust the code if they want and/or know how.

      While I do agree with your perspective. There's one thing people often tend to overlook, the vast majority of wikis use templates with more/less the same structure. Character, Books, item, episode, event, and few others. They merely add/remove things from it. So converting some of the popular infoboxes in template.wikia would probably greatly reduce the trouble. Very few people will try to reinvent the wheel when it works very well already.

        Loading editor
    • Dessamator wrote:
      [T]he vast majority of wikis use templates with more/less the same structure. Character, Books, item, episode, event, and few others. They merely add/remove things from it. So converting some of the popular infoboxes in template.wikia would probably greatly reduce the trouble. Very few people will try to reinvent the wheel when it works very well already.

      You may be right. (As an aside: I myself never used any template from Templates Wiki. I always create them from scratch, but that's probably just me.) Thanks for pointing that out, but I don't see how that contradicts with my idea of a GUI tool. We could add the functionality within the GUI tool to load an existing template, i.e. Book template, and then the user can adjust some labels or rearrange the order of some fields, then generate the tags.

        Loading editor
    • Ohmystars wrote:

      Dessamator wrote:
      [T]he vast majority of wikis use templates with more/less the same structure. Character, Books, item, episode, event, and few others. They merely add/remove things from it. So converting some of the popular infoboxes in template.wikia would probably greatly reduce the trouble. Very few people will try to reinvent the wheel when it works very well already.

      You may be right. (As an aside: I myself never used any template from Templates Wiki. I always create them from scratch, but that's probably just me.) Thanks for pointing that out, but I don't see how that contradicts with my idea of a GUI tool. We could add the functionality within the GUI tool to load an existing template, i.e. Book template, and then the user can adjust some labels or rearrange the order of some fields, then generate the tags.

      I similarly start from scratch with templates, and didn't even know the templates wiki was a thing. Even with wikitext infoboxes in the past, I usually scrap the default code and start again with my own classes etc. But I understand that many admins don't want to do that. I think that most admins should learn how to make basic wikitext templates, but I understand the reality is that they won't.

      Sample infobox builder
      The idea of making a tool which would simply add/remove data fields would probably solve most problems for admins editing infoboxes. It shouldn't be too hard to make in theory. The tool would put the basic structure in as default, with infobox, title, and image tags already set up. There would then be some sort of form where admins (or other users for that matter) could add extra fields, then fill in label, selector for filling in the information, and some sample data to show what the infobox would look like live. I've made a very rough mock-up in paint to show what I mean. The tool should allow people to drag data sets around as well as headings to fit their required layout, as well as delete data sets and heading they don't want. It would then be a really simple matter of generating the tags in the right order with the right data to make it work.
        Loading editor
    • There is no contradiction. But, my view is that the best way increase adoption is to first evaluate the main use cases, even before the gui is created. Once the new infobox caters well to most of them, then they can be converted to the new potBoxes, and it will be easier to create a gui. If the opposite is done with GUIs, chances are that we'll have lots of cases of broken potBoxes or users resisting change.

      As far as I can tell the only thing that it doesn't work well with is those gimmicks that people like to add, e.g. sliders, switch, and such. Another issue is that the episode/event navigation doesn't seem like it'll work well. Unless maybe the comparison tag is used. 

      One thing that would be nice though, is if the new prototype previewer also had some way of previewing the CSS changes on the fly, e.g changing color/border/etc, instead of the old change/save/refresh/preview.

      Edit: Also, I'm not sure but I think templates could be used to add parts of the infoboxes, for example, rather than writing : <infobox> <comparison><set><data><default>Stuff</default></data></set></comparison>.

      There could be a template that does this using:

       Template:CompareHeroes 
      
      <infobox> <comparison><set><data><default>{{{Hero1|}}}</default><data><default>{{{Hero2|}}}</default></data></set></comparison>
      
      
        Loading editor
    • Wow, Imamadmad! Good job you did with the mock-up of the tool, it is exactly what I had in mind!

      Infobox GUI 1

      Right panel: the parts that can be dragged and dropped in the left panel

      Taking into consideration what Dessamator said about "parts" of the infoboxes and the "main uses", I created another mock-up with some more ideas implemented:

        Loading editor
    • This makes one wonder where this will leave the infoboxbuilder. If the new potBoxes are used the infoboxbuilder becomes unnecessary, especially if it comes with advanced GUI tools. Anyway, chances are that the builder wasn't widely adopted so it is probably a non-issue considering that it is just a module at its core.

      @Ohmystars & Imamadmad 

      Great mockups !

        Loading editor
    • Dessamator wrote:
      This makes one wonder where this will leave the infoboxbuilder. If the new potBoxes are used the infoboxbuilder becomes unnecessary, especially if it comes with advanced GUI tools. Anyway, chances are that the builder wasn't widely adopted so it is probably a non-issue considering that it is just a module at its core.

      There's always going to be more than one way to do things, and more than one reason to have alternatives.

        Loading editor
    • This is probably the message posted above, but will ask a direct question for clarification. I have tried to use PortableInfoboxes via VisualEditor and get this message

      This template does not have fields to edit. Make changes to the template on its page.


      So how flexible will PortableInfoboxes be...

      1. PortableInfoboxes are only in beta stage and will be VisualEditor compatible when they go live?
      2. As PortableInfoboxes use modules, they cannot be VisualEditor compatible and can only be used via Source Mode?
        Loading editor
    • Hi TableWiz!

      This is known issue and we are working on solving it. When we finish fixing issues found during first experiments and implementing missing features (like table layout) we will start working on heavier integration with VE.

      Our goal is to make infoboxes as easy to use as galleries or images.

      Ohmystars & Imamadmad great mocks! Thank you for great input!

        Loading editor
    • FishTank wrote:
      Dessamator wrote:
      This makes one wonder where this will leave the infoboxbuilder. If the new potBoxes are used the infoboxbuilder becomes unnecessary, especially if it comes with advanced GUI tools. Anyway, chances are that the builder wasn't widely adopted so it is probably a non-issue considering that it is just a module at its core.
      There's always going to be more than one way to do things, and more than one reason to have alternatives.

      That's true. But chances are that wikia will eventually (in some distance future) deprecate the infobox class, which the infobox builder likely uses. That will render it unusable or it'll likely become awfully mangled in the mobile view. Or it could even make it mangled in the desktop view, that's one evil way to quickly speed adoption :).

      Of course we could always rewrite the back-end to support the new infobox syntax, but in its current state it is headed to oblivion.

        Loading editor
    • Dessamator wrote:
      FishTank wrote:
      Dessamator wrote:
      This makes one wonder where this will leave the infoboxbuilder. If the new potBoxes are used the infoboxbuilder becomes unnecessary, especially if it comes with advanced GUI tools. Anyway, chances are that the builder wasn't widely adopted so it is probably a non-issue considering that it is just a module at its core.
      There's always going to be more than one way to do things, and more than one reason to have alternatives.
      That's true. But chances are that wikia will eventually (in some distance future) deprecate the infobox class, which the infobox builder likely uses. That will render it unusable or it'll likely become awfully mangled in the mobile view. Or it could even make it mangled in the desktop view, that's one evil way to quickly speed adoption :).

      Of course we could always rewrite the back-end to support the new infobox syntax, but in its current state it is headed to oblivion.

      Which, not coincidentally, I started doing yesterday. Also adding HTML5 microdata support and per-item CSS classes while I'm in there. :-)

        Loading editor
    • FishTank wrote:

      Which, not coincidentally, I started doing yesterday. Also adding HTML5 microdata support and per-item CSS classes while I'm in there. :-)

      Excellent. I was planning to write a lua implementation of the new potBoxes myself, and did start doing it, but got lazy when I started thinking about the number of items that are included, and all the dependencies of each potBox tag. 

      Hope to see it in the dev wiki in the not so distance future :).

        Loading editor
    • Cqm

      @FishTank If you're writing that, I'd take inspiration from the mw.html library. It might even do the job anyway, I don't believe it uses a whitelist of classes or tagnames.

        Loading editor
    • Cqm wrote:
      @FishTank If you're writing that, I'd take inspiration from the mw.html library. It might even do the job anyway, I don't believe it uses a whitelist of classes or tagnames.

      It doesn't use a white list (I just tested it out a few mins ago). The only problem I see is that error handling for that library is atrocious because it reports errors in its library not in the calling function. Without a good use of pcalls, it may be more trouble than its worth.

        Loading editor
    • Using CSS Deck For Live View of PortableInfobox Styling

      Screenshot of using CSS Deck For live viewing of PortableInfobox Styling.

      Ref: the code for portableInfoboxes what is it's copyright status as I am current trying out CSSDeck to do live styling of portableInfoboxes but have saved it as a private block of code so only I can see and use it, but if the wikia code is covered by CC-BY-SA then I can make it public and post a link on this forum.

        Loading editor
    • Dessamator wrote:
      Cqm wrote:
      @FishTank If you're writing that, I'd take inspiration from the mw.html library. It might even do the job anyway, I don't believe it uses a whitelist of classes or tagnames.
      It doesn't use a white list (I just tested it out a few mins ago). The only problem I see is that error handling for that library is atrocious because it reports errors in its library not in the calling function. Without a good use of pcalls, it may be more trouble than its worth.

      I use mw.html extensively in other Lua modules, and I'm augmenting and altering the existing module / extension (which uses mw.html). Haven't had any real issues with error handling in other projects, but I doubt it will be a problem.

        Loading editor
    • Is it just me or did the unordered (*) and ordered lists (#) stop working in the new infoboxes?

        Loading editor
    • Ohmystars wrote:
      Is it just me or did the unordered (*) and ordered lists (#) stop working in the new infoboxes?
      Seems like it. But you can use:
      <<ul> 
      <li>Item 1</li>
      <li>Item 2</li>
      </ul>
      
        Loading editor
    • Hi! In our last update we have introduced a regression and the wikitext lists are no longer processed properly. We are working on fixing it.

        Loading editor
    • Inez wrote:
      I'm looking forward to hearing feedback, comments and ideas from you!

      I recently converted a template using the infobox previewer, and it was a smoother experience than expected. Some feedback:

      • Bugs:
        • Probably caused by another redirect: Uncaught Error: Syntax error, unrecognized expression: #Norwegian_(Bokmål)_for_English
      • Good features:
        • The code highlighting 
        • Auto completion of tags
        • On the fly editing & preview
        • Great keyboard shortcuts
      • Suggestions:
        • Auto indenting of code upon save.
        • Better error reporting - I'm sure this is on the todo-list
        • Simple parser/conversion tool - to pick up template arguments and use as data-source.

      I can actually code suggestion 3 myself using lua and page preview. This could probably gr