FANDOM


  • This wikia is starting to take shape, but I find that although we have a lot of pages discussing infoboxes they aren't easy to find. This is necessary to provide examples, and maybe a sandbox where we can experiment with them.

    So this discussion is about how , where, when to store infoboxes:

    • Which infoboxes would be nice to import here?
    • Do we create a single page listing them all or list them within different sub-pages?
    • How do we categorize them?
    • How do we differentiate between lua / portable or classic infoboxes, maybe using a banner?

    We have Portable infoboxes and classic infoboxes but no lua infoboxes, this may make it hard to explain what they are about and how to use them. 

    Thoughts?

      Loading editor
    • Well, let's cluster what we'd want to host here:

      • Documentation
        • Portable Infobox (in depth)
      • Layouts
      • Programming / Functions
      • Styling
      • Marketplace for Help / Conversion
        Loading editor
    • FishTank wrote:
      Well, let's cluster what we'd want to host here:
      • Documentation
        • Portable Infobox (in depth)
      • Layouts
      • Programming / Functions
      • Styling
      • Marketplace for Help / Conversion

      Agreed, some points though:

      • Programming/ functions have clear areas where they'll be stored, either templates or in modules.
      • Layouts and styling is where we need to find a good approach.
      •  I guess we can use the forum for help and conversion requests. Maybe set up a new board for that.

      It is hard to convey how exactly these can be imported easily to other wikis easily. It is not a simple matter of copy and paste. Do we store the css in a separate subpage or simply on the same page? Currently our only theme looks disorganized, and hard to understand.

      Depending on how popular conversion requests may become, we could even request a new namespace just to store those conversions, because cluttering the template namespace with infobox conversions may not be the  best way to organize them.

        Loading editor
    • Programming and Functions are not necessarily best kept in Templates and Modules, since there would be naming conflicts. They're most likely better off in <source> tags in an article. I wonder if we can use the transclusion function of Documentation to do this a little differently, storing in a structure like "[[Wiki]]", "[[Wiki/PIB.css]]", "[[Wiki/Infobox_whatever]]". That assumes that whatever we're showcasing is centered around a given wikia. What other ways would we do that?

      As far as the disorganized theme (and its eventual siblings), let's make a best practice guideline.

      I initially wanted to do Theme in a different namespace, but let's hold of on requesting anything until we've got some other organization squared away and have more content.

        Loading editor
    • FYI, someone started Where to find stuff, but with external links currently. So, try to populate it with internal links you think are appropriate.

        Loading editor
    • FishTank wrote:
      Programming and Functions are not necessarily best kept in Templates and Modules, since there would be naming conflicts. They're most likely better off in <source> tags in an article. I wonder if we can use the transclusion function of Documentation to do this a little differently, storing in a structure like "[[Wiki]]", "[[Wiki/PIB.css]]", "[[Wiki/Infobox_whatever]]". That assumes that whatever we're showcasing is centered around a given wikia. What other ways would we do that?

      As far as the disorganized theme (and its eventual siblings), let's make a best practice guideline.

      I initially wanted to do Theme in a different namespace, but let's hold of on requesting anything until we've got some other organization squared away and have more content.

      Well, centering these "tools" around a wiki has the drawback of replicating the same work if someone asks for a similar but somewhat different request. There may be custom requirements that a wiki may have maybe for css, but the beauty of the portable infoboxes for example is that they create a uniform way of styling and creating elements. 

      Maybe the best idea is to evaluate the general request, and in cases where the request is generic, we can simply create a generic infobox, and apply the specific customizations for whoever asks for it. So rather than having DevWiki/Infobox Books TemplateWiki/Infobox Books,  we have one "infobox books", and simply change it slightly to suit devWiki or TemplateWiki. 

      As far as the disorganized theme (and its eventual siblings), let's make a best practice guideline.

      Agreed. I think we can also take the opportunity to create two best practice guides, one for  infoboxes (e.g. use <image> tag rather than <data> tag ) and the other for styling (e.g. use link rather than import).

      I initially wanted to do Theme in a different namespace, but let's hold of on requesting anything until we've got some other organization squared away and have more content.

      Agreed.

        Loading editor
    • Dessamator wrote:
      Well, centering these "tools" around a wiki has the drawback of replicating the same work if someone asks for a similar but somewhat different request. There may be custom requirements that a wiki may have maybe for css, but the beauty of the portable infoboxes for example is that they create a uniform way of styling and creating elements. 

      Maybe the best idea is to evaluate the general request, and in cases where the request is generic, we can simply create a generic infobox, and apply the specific customizations for whoever asks for it. So rather than having DevWiki/Infobox Books TemplateWiki/Infobox Books,  we have one "infobox books", and simply change it slightly to suit devWiki or TemplateWiki. 

      So, then it would be [[Infobox/Book]], or [[Infobox/Character]], or [[Infobox/Episode]] as starters? Interesting. Actually, that could be done for most of the standard Schemas, which would give us a place to start. And a way to integrate microdata or structured data right from the beginning.

      I think we can also take the opportunity to create two best practice guides, one for  infoboxes (e.g. use <image> tag rather than <data> tag ) and the other for styling (e.g. use link rather than import).

      Agreed.

        Loading editor
    • I like the JSON-LD description used at schema.org. Very clean, but maybe not appropriate for here.

        Loading editor
    • Fandyllic wrote:
      I like the JSON-LD description used at schema.org. Very clean, but maybe not appropriate for here.

      Definitely not. More like this.

      <infobox itemtype="http://schema.org/Book">
        <title source="name" itemprop="name">
          <hint lang="en">The title of the book.</hint>
        </title>
        <image source="cover" itemprop="image">
          <format type="file" />
          <hint lang="en">An image of the cover.</hint>
        </image>
        <data source="ISBN" itemprop="isbn">
          <format type="number" maxlength="13" mask="###-#-##-######-#" />
          <hint lang="en">The ISBN of the book.</hint>
        </data>
      </infobox>
        Loading editor
    • Yeah, I know. I just like the readability of JSON. XML is kind of clunky.

        Loading editor
    • FishTank wrote:

      So, then it would be [[Infobox/Book]], or [[Infobox/Character]], or [[Infobox/Episode]] as starters? Interesting. Actually, that could be done for most of the standard Schemas, which would give us a place to start. And a way to integrate microdata or structured data right from the beginning.

      Yes, that's better. Most people don't realize it, but there are only a few "types" of infoboxes being used out there. Most of the complication comes from minor customization that builds up over time. So those ones will make things much simpler.

        Loading editor
    • Something we're working on in Council (it's not Wikia driven, but user driven, so it's not under NDA) is an idea springing from one of the Connect presentations, which will separate some more abstract schemas from actual Infoboxes (in other words, all structure and no presentation). When we've got a syntax going, ideally we'll have the actual schemas in a separate namespace. So, we're looking at another gallery and help section here for Schemas, and a way to gel Schemas and Infoboxes.

        Loading editor
    • FishTank wrote:
      Something we're working on in Council (it's not Wikia driven, but user driven, so it's not under NDA) is an idea springing from one of the Connect presentations, which will separate some more abstract schemas from actual Infoboxes (in other words, all structure and no presentation). When we've got a syntax going, ideally we'll have the actual schemas in a separate namespace. So, we're looking at another gallery and help section here for Schemas, and a way to gel Schemas and Infoboxes.

      That will be interesting to see.

      Anyway, as a first step to organize the infoboxes, perhaps we should create a page similar to w:c:dev:List of Lua Modules

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message

Ad blocker interference detected!


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

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