Discussion/Infoboxes

Call for comments: As mentioned below in the Format discussion, if no one has any further comments about what should be included in the location infoboxes and how they should be integrated into the page, I'll start rolling them out. (I think there is discussion left to be had on several issues, so please comment!) --Starwed 20:35, 11 November 2006 (CST)

Since no one has commented, I'm going to start the process of including location infoboxes on all pages which warrant them. --Starwed 15:46, 18 November 2006 (CST)

Back to Discussion.

Location Infobox Rollout

I put infoboxes on most of the location pages. Notes on adding infoboxen:

• I used the Safe Adventuring list as a guide to finding locations, so anything not listed there I might have missed.
• The hedge maze looked really weird w/ one, so I left it alone
• I didn't add them for dual areas, which include:
  • pirates cove, hippy camp, orcish frathouse
  • dungeons of doom
  • Misspelled Cemetary
  • The Bugbear Pens
  • The Battlefield
  • Crimbotown
• Didn't add any for Boss areas (quite possibly we could use a special boss infobox)
• Should the Daily Dungeon have one? It's got monsters and noncombat, but it's obviously a very special case.

My current thought is that, where two completely seperate sets of adventures are listed on the same page, that a special dual infobox template be used. --Starwed 18:09, 18 November 2006 (CST)

I've implemented the dual infobox, and added it to a few of the pages. --Starwed 12:42, 30 November 2006 (CST)

Tasklist

• Hammer out what infoboxes should look like. This should probably be uniform across different types.
• Where should infoboxes be used?
  • Monsters, locations seem a natural fit. --Starwed 01:38, 16 October 2006 (CDT)
• Get a list of what information should be included in each type of box.
  • Need an indicator for physical immune monsters. --Quietust 08:31, 16 October 2006 (CDT)
  • Now that the infobox templates have official pages (Locations and monsters), I guess it would make sense to dicuss what's needed on a per template basis. --Starwed 04:04, 17 October 2006 (CDT)
• Decide where (if at all) database like methods should be employed.
  • Probably not for locations. --Starwed 01:38, 16 October 2006 (CDT)
• Actually start implementing the concept.
  • Locations will be simpler, and there are less of them anyway. --Starwed 01:38, 16 October 2006 (CDT)

Format

What format should the infoboxes have?

Sample of what one could look like can be found here.

Wikipedia uses some CSS classes to style their infoboxes, it would probably be good to simply copy those onto this wiki. (They're located in main.css, and are all clearly labeled as for infoboxes.) Obviously this is an admin's call. ^_^ --Starwed 08:05, 16 October 2006 (CDT)

Is this what you are looking for?

(snip CSS which is now found in monobook.css)

--SomeStranger ^(t|c) 17:36, 16 October 2006 (CDT)

Yup, that's it. Is there any objection to just copying all that into the wiki's CSS? (Of course it takes an admin to actually do so.) --Starwed 04:30, 17 October 2006 (CDT)

I added it to the monobook.css page which works just as well.....--SomeStranger ^(t|c) 20:03, 18 October 2006 (CDT)

Thanks, that streamlines the templates nicely, and properly formats the individual cells and rows. Any comments on how monster infobox at my userpage looks? You seemed bothered before about how it messes up the centering of the page; is there any way around this issue? --Starwed 12:19, 19 October 2006 (CDT)

I proposed a slightly difference format at Template talk:TestInfobox removing the redundant name listing and listing physical resistance.--Dehstil (t|c) 12:36, 19 October 2006 (CDT)

Ah, I'd missed that somehow. For some reason I thought that position:relative didn't work in IE, but since I see that it does we should indeed use that instead of float for infoboxes. I'm not sure if we want to remove the name entry or not; the standard on wikipedia seems to include the name in an infobox even if it's a bit redundant. Take a look at Wikipedia:Lime to see how it's used with fruits, for instance.

There are all sorts of tweaks to the basic infobox that we could make, especially changing the color scheme. I'll leave that up to the admins, since it looks like you need that sort of access to update the CSS pages. Right now I'd like to go ahead with implementing basic infoboxes for adventuring locations; it's much smaller in scope than doing it for monsters. I started a list of what I thought should be included on the talk page. --Starwed 16:24, 19 October 2006 (CDT)

Looks like using CSS positioning to place the infoboxes can run into problems; it will overlap onto the text of the article. There might be something I'm missing, though. Because it would be the most elegant way to add these infoboxes. ^_^ --Starwed 00:22, 20 October 2006 (CDT)

I've slightly revised how the infoboxes look; you can see that for locations and monsters. (Color!) The big issue, I think, is: how should infoboxes fit into the flow of the page? If they're stuck in as on wikipedia, then the image of the monster/location at the top is no longer centered. Using CSS instead of float solves that problem, but then the infobox can overlap the text of the article. Another option is having the infoboxes appear underneat the image, to the right of the text, but that looks a little funny. Anyone else have any thoughts on this, or about how to make them look better in general? --Starwed 10:01, 24 October 2006 (CDT)

• I think that the infoboxes should definitely be at the top. I'm pedestrian at best in dealing with these issues, but perhaps we could incorporate a mini table into {{battle}} that holds the image and the "You're fighting a ..." text. Then the two tables would sit side-by-side and avoid overlap problems. --Gymnosophist 01:58, 25 October 2006 (CDT)
  • The problem becomes one of long infoboxes. (Not so much a problem for locations, but there's a lot of info to included for monsters.) Ideally, we want the image to be centered, the infobox to be at the top right, and the text to start directly under the image, flowing around the infobox. To get the text to flow around the iBox, I'm pretty sure its necessary to add float to it, rather than using CSS positioning. This causes the image to become uncentered, but you can use CSS positioning on the image to force it into the center again. If you're not careful this will mess up where the text starts, but by placing a dummy div of the right height, this problem can be avoided. It's a little convoluted, but it's the only way I could think of to get the correct effect. I might be wrong, but I think a table wouldn't allow the text to wrap around the infobox.--Starwed 02:13, 25 October 2006 (CDT)
  • Damn, can't get the method I mention above to work in IE. If it was up to only me, I'd just live with uncentered images. It doesn't really look bad if the infobox is long enough; then the image is centered relative to the first block of text. (Honestly, I'd probably put the image directly into the infobox, as is commonly done on wikipedia, but it seems there's a preference for having pages appear like they do from within KOL.) It would be nice to get other peoples comments on this, as it's probably the last "blocker" that I see for rolling out infoboxes on location pages. --Starwed 07:58, 26 October 2006 (CDT)
• I really like seeing the singleton image included as part of the location (and had almost suggested doing just that). However, it can be a problem for locations with multiple images like The Haunted Bedroom, Right Side of the Tracks, etc. Maybe we could set up the template so that including the image is optional? If so, are people OK with having two slightly different approachs to locations? I think I would be. We might also consider doing the same thing for monsters, although this would mean a more radical departure from our "Wiki adventures should look like ingame adventures" standard. --Gymnosophist 05:24, 27 October 2006 (CDT)
  • The template is already set up to show the image cell only if an image parameter is set. Full zones like the Right Side of the Tracks aren't a problem, as they'd need a different sort of infobox anyway. But I hadn't noticed that there were adventuring locations like the haunted bedroom... Presumably there are only a handful, so I guess we could just make little mini images for them that are the right size. (Assuming that the consensus is for images in infoboxes. I'm still now undecided on which looks better.) --Starwed 05:58, 27 October 2006 (CDT)
  • It would be good to get a few more comments on this one; there's really no reason not to go ahead with the location data, at least. I think the least intrusive change would just be to add floating infoboxes, without the image in them. So if no one else comments in the next few days, I'll take that as tacit approval and start adding them to pages. ^_^ (As SomeStranger says about the item data pages, otherwise the project will just stagnate.) --Starwed 15:51, 6 November 2006 (CST)

Dual locations

Sometimes there are effectively two locations on one page. This happens when the adventures change depending on your outfit or quest completion. My gut feeling is that we should have two, separate infoboxes on the page; what do others think? --Starwed 10:44, 10 November 2006 (CST)

• Technically, we should move these to a separate page called "Area name (in disguise)", since the game itself does distinguish them as separate areas. --Quietust (t|c) 12:15, 10 November 2006 (CST)
  • That sounds better to me; I had assumed that having them on the same page was policy. But I don't think the Mispelled Cemetary distinguishes in the name itself; is that the only odd case? (edit: Bugbear Pens has the same problem.) --Starwed 13:06, 10 November 2006 (CST)
  • Having them on the same page is policy. But that doesn't mean that the policy can't be changed. The best place to discuss such a change might be over at Discussion#Adventure Sort Order, which has been awaiting feedback for some weeks now. For myself, I'm against having two separate locations or having two separate infoboxes. The single infobox could just say something like "Disguise Adventures: Yes". --Gymnosophist 14:47, 10 November 2006 (CST)

I came up with a "dual infobox" which should work for these pages. You can see it here... any commments? --Starwed 15:47, 27 November 2006 (CST)

Metadata issue

Should we use /Data pages to create an effective database of monster stats?

Pros:

• Allows standardization and easy update of data which is used in multiple places.

Cons:

• Could add lag to the wiki.
  • Why would this cause any more lag than a normal template? Updating metadata for one monster/location would only force a few pages to update. --Quietust 08:39, 16 October 2006 (CDT)
    • As someone who knows nothing about how the wiki actually works, I only know that this claim was made. If no one believes this to be the case anymore, strike it from the list! ^_^ --Starwed 12:08, 16 October 2006 (CDT)
• Harder for new users to update.

Initial Discussion

I thought it might be a good idea for infoboxes to be introduced for some categories of article. (Like how wikipedia does for albums, for instance.) Monsters especially: it would be nice to see the level, statgain, elemental, and so on right at the top of the page. Locations could use this too, having safe moxie, avg monster level, clover adventure, and so on in an infobox. I don't know how to set any of it up, but I'd certainly be willing to help with adding these once the ball was rolling. Thoughts? --Starwed 10:18, 10 October 2006 (CDT)

• I would like to see this information somewhere for the monster pages...hopefully in the near future.--Dehstil (t|c) 20:32, 10 October 2006 (CDT)
• I want to see this information on the individual adventure pages as well (I think monster combat messages could be pushed way down the page), so I'd like to see examples of possible templating. --Jonrock 21:19, 10 October 2006 (CDT)

It seems the standard way of doing this requires that a certain stylesheet be in use, with all the "infobox" declarations. I've copied the declarations by hand into a sample infobox: Template:TestInfobox. It would obviously be more elegant to include them in a common style sheet. --Starwed 16:27, 12 October 2006 (CDT)

I've mocked up what this could look like at my user page. It seems to me that it would be nice if all the data associated with a monster could be stored on one page and then called via templates everywhere it's referenced; I don't know if that's possible or even desirable, but since all the information we'd want in infoboxes is already mentioned elsewhere it would be nice to have uniformity. --Starwed 16:43, 12 October 2006 (CDT)

I've experimented a bit, and it is entirely possible to keep seperate subpages for each monster with the data in it. That data could then be reused on any page it might be useful (right now, probably individual monster pages and the monster summaries on adventure pages.) It's quite possible that this would slow down the wiki, but it's at least technically feasible. ^_^ (You can check out my userpage to see how this works.) --Starwed 16:14, 13 October 2006 (CDT)

• Yes, it's feasible to have autoupdating metadata for different stuff, but it'd be a huge drag on the wiki. See Talk:Best Drinks, {{plural}}, and Discussion/archive3#A Companion for .7B.7Bplural.7D.7D.--Dehstil (t|c) 16:27, 13 October 2006 (CDT)
  • Actually, this particular technique probably would have resulted in less lag than {{plural}} currently does, and it would allow storing not only plural forms, but also singular forms (for stuff like Item #13) and image names (to be automatically included by {{item}} and {{useitem}}). Updating the 'infobox' template would still cause just as much lag as before, but updating stats for a single monster/item would not cause any significant extra load on the wiki. I've created an example at {{test/acquire}}. --Quietust 16:32, 13 October 2006 (CDT)
• The database administrator in me likes this idea but the usability consultant in me hates it. Typical. I'd want to make sure that the "data page" for a monster is clearly linked to its main page (or talk page), so that it doesn't require "wizard skillz" to make modifications. We're already having troubles in that templates themselves don't have "preview", so they take much more care to make work correctly. --Jonrock 19:28, 13 October 2006 (CDT)
  • Is it be possible to have an "edit" link in the infobox itself? Also, we're mostly talking about data that has to be pretty carefully gathered in the first place; the sort of people who could alter it reliably are probably the same who wouldn't find editing a template too tricky. --Starwed 20:05, 13 October 2006 (CDT)
    • If you show me what the heck you want it to edit and where you want it to go I can whip up an edit link in a few minutes.--SomeStranger ^(t|c) 23:31, 13 October 2006 (CDT)
      • I messed around a bit and seem to have come up with a workable solution for infoboxes. (Simply a link to edit CURRENTPAGE/Data) Unfortunately I can't grok how to get the pagename of a template from within that template, which would be the nicest solution here. (Using the CURRENTPAGE functions renders the page the template is called from; which makes sense but is unhelpful. ^_^) Still just using my userpage as a sandbox. If there's real interest in adding infoboxes (with or without the metadata templates) maybe we should start a proper discussion page? --Starwed 02:33, 14 October 2006 (CDT)

I quite like the general concept of using Infoboxes for combat adventures, locations, etc. The example Infobox looks pretty good, and, with some formatting tweaks, will look even better. I also like the implementation, despite having something of a reservation over it's complexity. I share Jonrock's concern that ordinary users are increasingly finding that making even basic edits is becoming prohibitively difficult. That said, I definitely see the value of having the data in a /Data page, at least for data that will be used in multiple places, (like the monster data). But all in all, I think the benefits outweigh the additional complexity. We'll just have to do a good job on documenting the usage. On locations, or any other type of data that will probably be used only once, I think it may be better that we not use the /Data page approach and instead use a simpler, more straightforward template wherein we simply drop the data values directly into the instance of the location Infobox template on the location page. Starwed, great idea, and thanks for your work so far in illustrating it. --Gymnosophist 04:31, 14 October 2006 (CDT)

• In the past when a user has been unsure about how to use a template/format a page they have either posted on the talk page with the information they wish to be added, or attempted to add it and an admin/someone who knew what they were doing fixed it. I believe that first and foremost this wiki needs to be useful to those who don't edit at all, the vast majority. If you want to edit you can find your way. (Besides most large updates are usually made by the admin, while the references/notes are edited by everyone else.)--SomeStranger ^(t|c) 09:09, 14 October 2006 (CDT)
  • I agree wholeheartedly that first and foremost the Wiki needs to be useful to those who don't edit at all. However I couldn't disagree more with the implied contention that the admins should be the users doing all the heavy lifting of non-reference edits. That's certainly not how Wikipedia runs things, nor should it be the way things are run here. I also strongly disagree with the viewpoint that documentation is a lesser priority. My own view of the role of being an admin is that we should be activly participate in developing policies and standards. Additionally, part of my concern with things becoming more complex is that it also has the unwelcome side-effect of making the Wiki more insular and less open to newer and less experienced editors. This is ranging a bit far from the original topic of Infoboxes, but here we are.  :) --Gymnosophist 20:00, 14 October 2006 (CDT)
    • I don't necessarily believe that admin should be doing all the work, but that in order to acheive a global standard they end up doing most of the work along with a few select editors. Why do we use templates? So that formatting is easier. The problem is that learning how to use templates is not always very easy. I think that documentation is pretty good at this point (I know that all the templates have it anyways) and that most people learn from example (they copy previously made pages). Removing templates in order to create "simplicity" just makes it harder for admin and those select users who have to go back and format pages constantly. I think the way we do it now is pretty straightfoward, the only exception being the plural template, I find it pretty damn intutive that variables named "name" and "itemid" correspond with an item's name and id respectively.

Oh, and back on topic, HOORAY FOR INFOBOXES! Yeah....--SomeStranger ^(t|c) 20:21, 14 October 2006 (CDT)

• • • • I almost feel like we're talking in circles here - I generally support the use of templates, and am not suggesting that templates be removed in favor of "simplicity". And yes, templates are generally well documented and intuitive to use. What I was trying to make clear (and was apparently failing to do) was to note the fact that the /Data pages are a new wrinkle and would need to be clearly documented. Hopefully, my positions on these matters are now pellucid.  :) P.S. - Not all the templates are documented - that would make a good project sometime. --Gymnosophist 03:24, 15 October 2006 (CDT)

Metadata Storage

The infobox method being discussed involves using metadata pages to store relevant information. This same method could be used for pages like items and effects, where certain metadata is repeated in numerous places throughout the wiki (such as images, and especially plurals). A bot could probably manage creating and populating metadata pages for all item and effect pages on the wiki, eliminating the need for the horribly laggy {{plural}} as well as centralizing the specification of item/effect images. As noted above, I've already adapted {{acquire}} (into {{test/acquire}}), and updating {{AcquireEffect}}, {{item}}, and {{useitem}} would be trivial. Tracking pages lacking metadata (whether lacking individual fields such as plurals, or missing the page itself) could be accomplished with conditional categories using #ifexist for page detection and a generic 'getMeta' template (currently implemented as {{test/field}}) to try and fetch metadata from an object. If anything, using this for plurals would be only slightly slower when updating pages that use {{acquire}} (since it would have a few more templates to parse), but it would be immensely faster when updating plurals (since it would only have to update the pages that refer to acquiring that particular item). --Quietust 17:49, 16 October 2006 (CDT)

• My only concern relates to those who parse the plural list for use in scripts, etc... Instead of being able to parse one list they would have to hit the wiki multiple times to find all their data. I'm not particularly worried, but well...it certainly must be considered. Furthermore, we need to decide how to display data on the data pages. I am not thrilled about using