FANDOM


  • FishTank
    FishTank closed this thread because:
    This week's Content Portability Wikia:Office Hours have ended. Unanswered questions are rolled into the following week once.
    06:27, December 1, 2015

    Please feel free to fill in questions below - staff will be around to answer them at 4pm UTC on Thursday.

      Loading editor
    • Currently there are some features that seem to be working well for wikipedia, that might be useful if some of their elements were ported here:

      TemplateData ([1])
      A common framework for the parameters of templates is really a good approach to improving portability. For example, a template classified as quotation can be used to map parameters such as author or text or a navigation template can provide tips on bad markup being used. Are there any plans to port useful features from it?
      Structured data (wikidata )
      A simple json / module editor like the one used to create templateData could facilitate the creation of structured data in jsons and would allow even non-scripters to add "semi-structured" data to pages using lua. Any thoughts on deploying a simpler solution like this?
      Interwiki sharing ( modules )
      Currently, dev wiki serves as a great repository of knowledge. But most users are unaware that we have global templates in the form of lua that can greatly reduce problems with hacky solutions that don't render well on mobile. Are there any plans to improve portability by re-using a shared repository rather than adhoc solutions everywhere?
      Preset themes
      Theming is one of the biggest headaches of portable infoboxes. Great apps such as Winamp or VLC often come preset with themes and this is one of the best ways to showcase how great they can look. Are there any plans to have a discrete number of preset themes?
        Loading editor
    • Since we still have little or none other questions, I googled a bit and came up with a couple more:

       Content adaptability, structured data and caching
      While some components may get new widgets such as portable infoboxes. Others such as tables along with their meta-data are harder to create. It also makes it incredibly difficult to do basic calculations such as obtaining the average or the sum of values. Any thoughts on the discussion and how the table syntax could be adapted to make it easier to process its data? (See also: Autocalctable)
       Page components / content widgets ([1])
      This discussion even mentions wikia and has some thoughts on how portability can be further developed. What would be wikia's answers to some of the questions raised there, e.g. Can we restrict page components to a single DOM node?
        Loading editor
    • I'm going to ask a few portability questions, not directly related to infoboxes:

      1. Tables and data sheets. Similar to what Dessamator already brought up, table syntax isn't nearly as uniform in that they're often just added as MW tables rather than placed in templates. Aside from as structured data, are there plans to make them portable? And if so, will we be using different syntax to MW tables?
      2. Collapsibles and tabbers. I'm sure you guys are sick of hearing thephrase tabbers by now, but both these things have been given solutions within portable infoboxes, but outside of them, they rely on JavaScript, which doesn't load on mobile. They're often used for data tables in other places (and in our case, we also use collapsibles around spoilers so users can choose to hide them). Are there any plans for a standardised class or something, which allows these things to work on both mobile and desktop? (as long as it allows collapsibles within collapsibles, and tabbers within tabbers without forcing the <tabber> tab, it should be ok).
      3. Switches at the top of pages to see different versions. Some wikis add different switches that appear like tabs at the top of pages for navigation. I know the obvious example is Wookieepedia's canon and legends like so, and the other one I can remember is one I was shown, the Neptunia Wiki. Sometimes these are used just to navigate between subpages of a certain page, but I saw a similar switch used to change content displayed - namely, to hide spoilers if tunred on. Are there any plans for a non-JS version of this so the mobile theme can have it too?
      4. Finally, side icons/dingbats. To go back to the Wookieepedia example, one thing they also use is side icons on the page to indicate the era the subject belongs to. I know that the Fallout Wiki does this as well, and we do on the FFWiki, but we make them appear in the right rail. Is there any chance for something, possibly mixed with Flags, to replace this without use of JS?

      Probably noticed a theme...non-JS equivalents for commonly used JS things to work on mobile would be sweet! Also, if getting non-infobox tabbers (and some of the other things?) working on mobile using, I've brought up this idea before, a drop down switch on mobile and normal tabs on desktop, then the FFWiki would be fully ready to convert to portable across the entire site! I'm sure Dessamator will want to kill me for saying that. :P

        Loading editor
    • Finally, side icons/dingbats. To go back to the Wookieepedia example, one thing they also use is side icons on the page to indicate the era the subject belongs to. I know that the Fallout Wiki does this as well, and we do on the FFWiki, but we make them appear in the right rail. Is there any chance for something, possibly mixed with Flags, to replace this without use of JS?

      Actually, I've been meaning to suggest that for a very long time but always forget. In fact that was my first thought when I heard of "flags", I think they can be combined to convey simpler cues using icons, e.g. much like the Page_status_indicators feature that was recently added to mediawiki.

      I'm sure Dessamator will want to kill me for saying that. :P

      Not at all. Maybe staff or someone else can find a "reasonable" and user-friendly way of implementing it without cluttering the interface.

        Loading editor
    • TOR

      Oh wow, guys. You really went all out on questions regarding future plans this time around. And some of these are really far future, at least in Internet timeframes. ;) Not that that's a bad thing -- many of the things mentioned are interesting technologies and ides -- but...

      We're now in the middle of planning for 2016. And while we're happy to dive into portability-related topics and issues, the answer to questions about what comes after we reach portability (which is all of the data-related stuff) necessarily has to be a blanket one in the form of:

      Er... um... yeah... We don't know yet and/or have not decided yet. We'll let you know as soon as we can.

      Now with that blanket statement out of the way, we'll try to fish (no pun intended) for questions that we can answer with our current knowledge. ;) If you don't get an answer, assume it falls under this default of "Tor (nor anyone within earshot) doesn't know (yet)".

        Loading editor
    • Alright, let's have a go at something that may or may not be easier to answer...

      Any plans for <group>s within <groups>? I've brought up this idea before on Community Central, but the idea where you can wrap a group within a group, in order to prevent issues where people can't make a whole collapsible section with multiple rows of horizontal <data> tags.

        Loading editor
    • It is true that most of the questions are about the future. But the one about tables is a current problem because sometimes they may even have rendering problems on desktop devices because the standards aren't always followed by all browsers. So a simple question is : are there any guidelines to render these properly on most devices, the help page is too brief ...?

      One currently important question is also regarding the differences betweenbetween the regular mobile preview and the "?useskin=wikiamobile". This makes it quite hard to discern the mobile view if resizing the browser makes it appear better can we have this option, like google chrome's mobile preview tool?

      Another interesting technology that is currently available is the "https://github.com/Wikia/wiva" tool that could be rewritten as a javascript gadget to offer tips on how improving a regular page. Are those tips offered by it really accurate and worth adding it as a portability tool?

        Loading editor
    • Technobliterator wrote:
      Alright, let's have a go at something that may or may not be easier to answer...

      Any plans for <group>s within <groups>? I've brought up this idea before on Community Central, but the idea where you can wrap a group within a group, in order to prevent issues where people can't make a whole collapsible section with multiple rows of horizontal <data> tags.

      Sounds like an interesting use case for 2 layered groups. I think having more than that would cause issues.

        Loading editor
    • OK, so: portability questions. :-)

      Customizing different media outputs
      Currently, .portable-infobox styling only applies to desktop. How can (or will we be able to) create vibrant experiences for other media (like (but not limited to) mobile) without breaking Portability?
      Tables
      Infoboxes are only a part of Portability, and one common article element that does not work as well portably are tables. Limitations and rendering of Table-based layout is one of the reasons why PIBs were created. For tables, what is a good pixel-width to aim for or a good practice to scroll or collapse larger dataset tables (as are often seen in game wikias)?
      Lua invokes vs Wikitext Templates vs Parser Functions vs Tag Extensions inside Portable Infoboxes
      Not everyone realizes this, but most of the above are processed at different times "under the hood" and cause alterations or errors depending on which are used. Is there a preferred order or method for best results inside a Portable Infobox? Is there a speed difference in how fast the page renders or how difficult things are for the processor?
        Loading editor
    • TemplateData

      A common framework for the parameters of templates is really a good approach to improving portability. For example, a template classified as quotation can be used to map parameters such as author or text or a navigation template can provide tips on bad markup being used. Are there any plans to port useful features from it?

      We are working on unified category system for templates, including options for manual classification and under-the-hood, automated one (using magic & science). After we finish we will start working on making each category portable, trying make the process as automated as possible.

      We have considered TemplateData as a possible solution for describing identified template types, as it does great job with describing the input data of the template. Unfortunately it still doesn’t give us information about what template outputs, and as we know inside the template data can mutate a bit. :) We are keeping TemplateData as a potential solution to part of the problem, though as Tor said earlier, we do not have the answer yet.

        Loading editor
    • TOR
      Interwiki sharing ( modules )
      Currently, dev wiki serves as a great repository of knowledge. But most users are unaware that we have global templates in the form of lua that can greatly reduce problems with hacky solutions that don't render well on mobile. Are there any plans to improve portability by re-using a shared repository rather than adhoc solutions everywhere?

      Great question! We may have a library of components of some sort in the future.

      However, knowing the fierce independence of some of our communities, and drawing on my Wikipedia experience with Wikimedia Commons, I’m gonna say it’s probably not quite the silver bullet it appears to be. ;)

      We’re probably going to wait and see how dev wiki evolves and is used, now that it is a de facto global repository of JS scripts -- and there’s actually a way to sort of easily import them to your wiki, plus an incentive to use the global scripts to not have to go through JS review as often.

      So if you care about this idea, head over to dev.wikia.com and help out over there -- or better yet, convince your wiki friends to start using global JS scripts from dev. We'll be watching and taking notes. :)

        Loading editor
    • Content adaptability, structured data and caching While some components may get new widgets such as portable infoboxes. Others such as tables along with their meta-data are harder to create. It also makes it incredibly difficult to do basic calculations such as obtaining the average or the sum of values. Any thoughts on the discussion and how the table syntax could be adapted to make it easier to process its data? (See also: Autocalctable)

      Tables and data sheets. Similar to what Dessamator already brought up, table syntax isn't nearly as uniform in that they're often just added as MW tables rather than placed in templates. Aside from as structured data, are there plans to make them portable? And if so, will we be using different syntax to MW tables?

      Perfect timing! Today we have started discussion about how to make tables portable. The biggest problem with tables is not that they are not portable by nature. Classical tables, used for displaying data are super portable. In fact there is already existing XML schema for tables, our good old <table> tag. The problem with tables is distinguishing between tables used for presenting a 2-dimensional matrix of data (which mortals would call “a table”) and tables used for creating layouts or page design (which we call “abominations” ;)).

      We do not want to introduce another way of creating tables (right now tables are created via HTML or wikitext), but we are working on identifying which tables are used correctly to represent tabular data and which are misused pieces of article layout. After learning which are which, we will start analysing data and making decisions. And as FishTank pointed out, the first attempt of limiting the non-table usage of <table> tag was introduction of Portable Infoboxes.

      We are not planning to introduce calculated fields in tables, however in future would love to introduce separate data storage and ability to process and aggregate data in the form of tables or infoboxes in articles. We are just not there yet and I can’t say when we’ll get there, but this is one of the directions we are currently exploring.

        Loading editor
    • Brief question, is:

      <title source="name"><default>{{PAGENAME}}</default><format>[[File:FFXIV {{{name}}} Icon.png|{{{name}}} icon.]] {{{name}}}</format></title>
      

      allowed?

        Loading editor
    • Technobliterator wrote:
      Brief question, is:
      <title source="name"><default>{{PAGENAME}}</default><format>[[File:FFXIV {{{name}}} Icon.png|{{{name}}} icon.]] {{{name}}}</format></title>
      

      allowed?

      Yes. However on mobile we will only display the title. In order to ensure good look on mobile we are removing everything, but text from title fields (on mobile).

        Loading editor
    • Ahh, good idea. Fair enough.

        Loading editor
    • Preset themes
      Theming is one of the biggest headaches of portable infoboxes. Great apps such as Winamp or VLC often come preset with themes and this is one of the best ways to showcase how great they can look. Are there any plans to have a discrete number of preset themes?

      The truth is … I’m Iron Man. Ekhem. I mean yes, we have plans for these. We will experiment with alternative layouts and themes in built-in theming tool for infoboxes.

      We intended to introduce them sooner, but thanks to user feedback we found out that collapsible sections and tabbers are more needed :)

        Loading editor
    • Odd question: Tabbers inside PIBs can be used for images. On one game wikia that I can think of, they use this to show different images of a given character based on which game this character appeared in. They also use images of the game title as their sorting element. Can images be used as Tabber "titles"?

        Loading editor
    • I have only one question right now: When is the mobile skin preview on Desktop edit mode going to get fixed to match what the actual mobile skin renders?

        Loading editor
    • Thanksgiving morning for office hours? Seriously?

        Loading editor
    • Fandyllic wrote: Thanksgiving morning for office hours? Seriously?

      They're not based in the US. :P

        Loading editor
    • Fandyllic wrote:
      Thanksgiving morning for office hours? Seriously?

      Cheers from Poland!

        Loading editor
    • TOR wrote:

      Great question! We may have a library of components of some sort in the future.

      However, knowing the fierce independence of some of our communities, and drawing on my Wikipedia experience with Wikimedia Commons, I’m gonna say it’s probably not quite the silver bullet it appears to be. ;)

      We’re probably going to wait and see how dev wiki evolves and is used, now that it is a de facto global repository of JS scripts -- and there’s actually a way to sort of easily import them to your wiki, plus an incentive to use the global scripts to not have to go through JS review as often.

      So if you care about this idea, head over to dev.wikia.com and help out over there -- or better yet, convince your wiki friends to start using global JS scripts from dev. We'll be watching and taking notes. :)

      Another user and I have populated a whole page full of Lua modules (w:c:dev:luamods), and I  crafted extensive guides to help create lua modules. We are even using some global modules from there in this wikia. One idea is to provide a highly customizable bare-bones framework that users can import and change at will.

      I think that lua scripts are quite good because there's no need to convince anyone that they work. They can see loads of unit tests (see w:c:dev:links/testcases) that can help with "sane" testing. The only thing that is missing is some kind of LUA review system trusted users, e.g. code-editors review. Something similar to the JS review so that users don't get served problematic modules altered by ignorant users . Alternatively high use scripts can simply be protected or or added as libraries like mw.ustring, e.g. mw.quote. 

      There a quite a few javascripts I've created and submitted, but stopped this until we have a proper JS review in place. Maybe one day we'll eventually have a more vibrant coder community there.

        Loading editor
    • Technobliterator wrote:
      Alright, let's have a go at something that may or may not be easier to answer...

      Any plans for <group>s within <groups>? I've brought up this idea before on Community Central, but the idea where you can wrap a group within a group, in order to prevent issues where people can't make a whole collapsible section with multiple rows of horizontal <data> tags.

      I just thought of a better syntax that won't change existing infoboxes, and will still do what you want:

      <infobox> 
      <group layout="horizontal" collapse="open">
      <header>Tony stark </header>
      <data><default>War machine</default></data>
      <data><default>Iron Man</default></data>
      <header>Hope</header>
      <data><default>Dark Goddess </default></data>
      <data><default>Lady death</default></data>
      </group>
      

      The idea is that headers separate horizontal groups  by serving as delimiters.  That way you can still collapse the whole thing. So in the "code" above, we would have two horizontal groups...

      Currently the first header is swallowed, not sure if that's a bug or feature.

        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message