• Well this was a nice surprise. Something I'd been trying to do for a year or so suddenly fell into place after Desz got me thinking and also because Tooltips now work in a certain way (or I just realised they could be used that way).

    Turns out it was very easy and elegant code!

    So I finally picked up my crafting tools to bring my Clothcraft back up to cap, and create the necessary pages to do so. In making Category:Clothcraft/Expert, I've made a couple of new templates:

    • {{I}}: 'I' for 'Iconned Item' or somesuch. I wanted to keep the title brief, as I envisage it being used often in summary lists.
    • {{In}}: 'In' for 'Inline Iconned Item'. Again, a brief title.

    {{I}} uses #dpl to automatically apply the 32x32 icon infront of an Item Article link, as long as the icon id is declared in {{Item Statistics}}. It then uses #lst to create a mouseover tootlip of the Item Image section (it could use #dpl instead if the Item Image was within {{Item Statistics}}, but I gather we've just spent the last couple of years moving the Item Image outside of that template! It would work either way.

    {{In}} does the same, but with a 16x16 icon, and hence is useful for when items are in sub-lists (like recipe ingredient lists).

    I think I'm going to add a |noicon parameter, so that the templates can be used for the mouseover tooltip without the icon if needs be. Any other comments or observations would be appreciated. Not sure if it would be appropriate or even possible to roll this out site-wide via automation.

      Loading editor
    • Hmm... That's an interesting way of using DynamicPageList. I've looked at it before as a possible replacement for the category tables, but I hadn't considered using it like LabeledSectionTransclusion. I also didn't know it was enabled on this wiki. When were all these extensions added and not used? I need to browse through Special:Version, apparently.

      One thing that might be an issue is that Wikia recommends to avoid using DPL more than once or twice on a page, but I'm not sure if that applies to this kind of use or not. It's a single result, with an include similar to LST (which we're already using a lot at this point), which is very different from the usual use case. The only real difference from using LST in this case is that DPL parses the page looking for a template parameter, which may or may not be costly depending on how it retrieves that information. But, just going by how fast the query is (using %DPLTIME% in the resultsfooter), it looks like it's at least as fast as retrieving by labeled section, if not faster.

      As a side note, there are two ways that you could use DPL to get the item image from a page:

      • | include = {Item Image}:1 (template param; includes just the file name param)
      • | include = Item Image (labeled section; includes the whole section like LST)

      My other concern is that this is a lot of content/images to be adding to some already fairly large pages. We should probably do a larger test before rolling it out completely, just to make sure it doesn't cause any issues for slower machines/connections (or hit the server too hard with all those LST/DPL calls).

      As far as rolling this out with a bot - it's possible, but it would have to be in certain contexts, like job pages or merchant pages. It could also be added to the recipe link template (with the "noicon" param), though that has the same concerns as the recipe pages, especially for items that are used in a lot of recipes.

      Overall, very cool. I like the large icons, but I may have to get used to the small icons. I kind of find them distracting rather than helpful, but that also might be because it's Clothcraft and not a craft I'm more familiar with (and the line spacing is smaller in Monobook, which doesn't help).

      Edit: Oh, and what do you think about renaming {{In}} to {{Iin}} or {{IIn}}?

        Loading editor
    • LST in Nov 2011 and DPL in Feb 2012 as part of 1.18 and 1.19 respectively? In a list of a hundred other extensions, I wouldn't even have known what I was looking at let alone where to find them and what they could do. I got there backwards by having a design in mind, then trying to find out how I could make it possible!

      I thought the same about processing cost - as the #dpl call is 'targeted' and not crawling the entire 50k articles of the wiki (like my previous effort at {{SeeAlso}}), it should have no deeper impact than a single pageload server-side at most for each.

      I noticed, though I'm not sure what/how it works, that on the {{Tooltip}} there's an 'ajax' option that ensures tooltips are only loaded on mouseover, not on pageload. Could that go someway to mitigating server impact? Each Item Image is average about 75KB though.

      I was wondering was how much, since Mediawiki came about and these extensions were designed, the real effect of costly code such as this has, both on the end user and on Wikia's servers.

      Considering the former, I know I often run two MMOs, TV streaming, remote desktop, two video streams, browser/app use on 2-6 devices and Discord all concurrently without my minimum-spec broadband batting an eyelid. I'll find a couple of larger 'summary' pages and place the templates in them to see if there's any slowdown.

      Considering the latter, I'd be surprised if in the six years since they rolled it out, Wikia haven't upgraded their own hardware substantially (especially with the FANDOM redesign and the tendency to spread other sites' materials around); I also think that as one of the lesser-visited sites and what with their objective to actively encourage every user to set up a Fandom wiki to any tiny aspect of popular culture, we should accept that they can handle anything we throw at them until the day they send us an e-mail about it! :)

      Apologies for not looking at this in Monobook (or Mobile for that matter). I shall endeavour to see if there's a way to grant it slightly more appeal, though cross-format display is something I've yet to even start to look at past my initial fumblings to have tables represented better on Red Mage - I've certainly not delved into the css of it.

      Last - I chose 'I' and 'In' simply because, if used, it would be used a lot, and that's less keystrokes and screen space for editors! I have no problem with renaming it, if that's your preference.

        Loading editor
    • I've added in a couple-hundred item icons manually in order to support a sandbox version of the Cooking/Craftsman (61-70) Recipes.

      I figured this would be a good test of the preload and also might work as content you're more familiar with, so you could see if the ingredients icons assist rather than distract.

      Let me know what you think!

        Loading editor
    • Wow, I didn't expect it to make that much of a difference - being familiar with the items really helps.

      I tested it on my tablet over wifi and my phone over 4G (bypassing the mobile site) and it seems to load quickly enough regardless of skin. There's a slight delay before some of the images show up in Oasis due to the lazy loading, but it's bearable. So yeah, it seems good!

      I think we're on the same page with processing cost/server load. I just wanted to talk it through since it could be a fairly widely used template and DPL has a reputation for being expensive. I think you're right that Wikia will probably be able to handle anything we throw at it without slowing down the site too much, as long as we're relatively careful about it.

      Oh, and I really like what you're doing with your sandbox. The HQ change in particular is quite nice.

      I hope you don't mind, but I made an edit: I used the "flush-list" class and put the ingredients into description lists (the lists with ":"). This adds a little bit of spacing between the items in Monobook and doesn't seem to change anything in Oasis (I added styling to flush-list remove the usual margin around the top and bottom of the list in Oasis).

      I also think the old gray background works better than the blue, since it doesn't blur together as much for some reason, but the border you added between the cells mitigates that issue a lot. There's also something to be said about not having the specify background color on every row.

        Loading editor
    • I had a looksee on my own mobile whilst out and about earlier. There was certainly a delay of 2-3 secs when I scrolled down - it seemed to want to load all of the images in one go rather than piecemeal. I've seen that behaviour on other sites too.

      Sorry about the blue background - I defaulted to class=ffxi-table. In the back of my mind, I was thinking that these recipe tables either need their own class with the grey, or to instead begin to rely on table backgrounds rather than the cells for the visual cue.

      The border between cells is the use of style="background-image: -moz-linear-gradient(left, #<color>,#<color>); background-image: -o-linear-gradient(left, #<color>,#<color>); background-image: -webkit-linear-gradient(left, #<color>,#<color>); background-image: linear-gradient(to right, #<color>,#<color>);" to create a background. The gradient is much easier on the eye than a solid background or solid border, if the colours used complement each other.

      Since my attempt at the zone article redisgn, I had been thinking that colour-coding tables with such backgrounds might be a better alternative than using classes to set separate header/row colours for given table types, thus keeping most tables under ffxi-table.

      Distinction and consistency is very important though, so I've used it on a couple of pages that I look at regularly whilst playing to get a long-term feel.

      Red Mage#Job-Specific Equipment

      • Flipping the existing pink colour out of the table and into the background with a diagonal gradient (compare to Blue_Mage#Artifact_Equipment which has the original colours)


      • Using a horizontal, brown gradient. Crafting has always felt brown to me...

      Veridical Conflux 4

      • Using a horizontal, purple gradient. I'm standing in Walk of Echoes, sorry. So much purple.


      • As part of my zone page redesign for the Caskets - an example where two contrasting colours can work thematically.
        Loading editor
    • I think you're on the right track with the gradient backgrounds - I'd prefer to limit the number of CSS color backgrounds we implement, so using table backgrounds for more diverse color coding is an appealing idea.

      Another idea is to use standard cell backgrounds for the body of the table, but color-code the headers - it's something that was done on the recipe pages, but isn't terribly effective there.

      I like all of those examples, but the Red Mage table is the least palatable to me - I think it's because it's not as gradual/subtle of a change. I also don't like the missing cells - I'm assuming you don't like the look of empty cells, so maybe use gray cells and put an em dash (—) or en dash (–) in them?

      Just some constructive criticism, though - it's looking good!

        Loading editor
    • Yeah the Red Mage tables were me seeing if a triple-change on the gradient looked good, but I agree - it's not subtle and hence impacts on the readability of the information. I've changed it to two shades of the original pink header.

      I felt that empty cells were unnecessary, as it's additional code for no data. I've added them into those tables for now, so I can get a feel for how they look over a few weeks whilst I use the page.

      I think my rationale there is that data tables are created with each row (record) having a column (field), whether that be zero-value or not. In these cases, blank cells or cells with '-' in them are suited.

      However, when tables are used for the primary purpose of displaying information in an aesthetically pleasing way, I wouldn't raise the blank cells.

      Now, what you consider the aforementioned JSE tables as is possibly another matter. Personally, I think that it would be appropriate for any 'data table' to be classified 'sortable', as that demonstrates the record/field relationship (whether that's practical in a given case, ie tables with one or two records, would determine whether it was appropriate). However, any that would never be sortable are hence geared toward display and so blank cells could be omitted.

      Thanks very much for the feedback!

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