Talk:Infobox

From IcehouseOrg
Jump to: navigation, search

New Semantic Wiki Stuff Means New Structure

(David Artman 16:43, 29 June 2009 (UTC)) I appreciate the work that's gone into enabling semantic wiki via the Infobox. Now, however, it's time for a pretty serious revamp of its scheme, to enable full semantic support:

  1. We need BOTH a "stashes=" and "sets=" enumeration, much like how What Can I Play? is split into those two major headings. For many games, these values will NOT be the same, so it's important for the transition to Treehouse-source collections and for legacy support of Icehouse-source collections.
    Mneme 15:41, 30 June 2009 (UTC)1. Very much agreed on stashes/sets. It also could be used to source the stashes/sets breakdowns automatically, which is a big win.
    David Artman 20:55, 30 June 2009 (UTC)So shall we Just Do It, which will mean grinding through page's InfoBoxes to tweak them? Once done, though, you're right--it will make What Can I Play? far more automatic.
    (DA)Although... WCIP isn't supposed to list a game until it's done; would that mean we don't "let" folks put InfoBoxes on incomplete/in-testing games? WCIP is supposed to be a selling point page, not just a library catalog (that's Existing Games and Games In Dev).
    (JK)In theory, we could do a query like "all DONE games that match <xyz>" criteria. So as long as people didn't mark games as done until they were, well, done...
  1. Some of the parameters can not be answered with a numeral, and as such, those parameters should somehow be coded to "permit" (or at least ignore) non-numerical entries. For instance, for "number of players" many games can answer "Any" or the equivalent of "N" where N is the number of available stashes or stacks or even just players who want to play (e.g. Zendo).
    2. I suspect the best way to handle the non-numeric params is to have a numeric and a descriptive version, either of which can be blank. Alternatively, if we have some of the cleverer wikifunctions, we can just have the template autodetect and Do the Right Thing. (my comment on parser/stringfunctions on the main page is apropos).
    (DA) The clever functions is the bit for which I was hoping. Or, at the least, get folks using "Any" and "One per set" or "One per stash" as standards for scalable-population games. But then you have odd problems like "One per stack and Martian Coaster" (Wormholes) or just "One per stack" (Zamboni Wars, Treehouse) where "stack" is a nest/tree of the same color. And enforcing such standard verbiage will be... fun. This is all why I REALLY wish the InfoBox was actually "built" as a report from a form-driven database engine, so that we could restrict data entry with drop-down lists, checklists, and the like.
  2. The "mechanics" and "theme" and "other equipment" parameters needs to support multiple responses; or, if they do, we need to know what separator character to use. This is because many games combine mechanics/themes/equipment or can not be classified by a single, overarching mechanic/theme. (Yes, this could be more of an indictment of what we consider a "mechanic" or a "theme," but that's a larger battle I suspect than making code that supports multiple entries.)
    3. I believe this is also a function thing, as the semantic way to do multiple values would be to have multiple value entries, so the template needs to do it.
    (DA) That's a bitch, UNLESS we can get it to hide unpopulated fields, not make a weird 'code you're missing' curly braces line. Then we could have, oh, five "Theme" fields, but if only one or two are used, there's not a lot of blank rows.
    (JK) There's nothing magical about infoboxes -- they're just templates. So if we have good logic in the infobox template (with good extensions letting us build that logic; see *functions), we don't get blank rows or whatnot. I'm thinking of stuff where you use a separator on input and there's only one row (with multiple magic semantic wiki values in it).
  3. Anything that could have a range should have a "minimum" and "maximum" parameter. Checking my own games, that seems to be "number of players" and "playing time."
    4. Yes, definitely.
    (DA) As with 1 above, shall we Make It So? Monkeying with a template means one often has to fix every instance of its use (especially here, where "participants" might not show up for years on end). That's why I hit up the Icehouse List--hopefully, we'll get more than two of us here to work on it, and a job shared is a job soon done.
    (JK) I think for both, "make it so" (as I did with the semantic stuff to begin with) is the only reasonable approach.
  4. Regarding "playing time," we might want to advise folks (here, on Main Page, on Site conventions page, etc) to use a standard break-down of time units AND consistent units (minutes): 1, 5, 10, 15, 30, 45, 60, 90, 120 (...whatever) minutes. Otherwise, games that list "1 hour" and those that list "60 minutes" don't end up on the same results page, which is unfortunate.
    5. Actually, as befits the name, Semantic Mediawiki supports multiple unit types within a field. If we define the relationships correctly, we can have 1 hour be 60 minutes, etc.
    (DA)Good to know. you can make that so and we don't even have to hit up the InfoBoxes. Although we DO need to get rid or ranges of time, unless you can figure out a way to parse both times as valid values (but it sounds like this is the same as the Themes problem). So... "Minimum Time" and "Maximum Time" and we have to scrub. hey, at least we can scrub for all of these min/max/stash/set values (and Theme re-listing) at the same time.
  5. BGG Link will always be unique, so having it "semanticized" is pointless--only one game, ever, will be on any given BGG Link results page. A better way would be to have the BGG Link semantic link point to a category page (or similar) that shows all the games with BGG links.
    (DA)No reply to this? It really should either be de-semanticized or made into a static link to a single page which, in turn, is built of of a simple boolean operation ('does the page have a link to BGG on it?'). It's kind of silly to have a link to a generated page of one game (which is all they will EVER be, excepting foreign language translation pages).
    (JK) I had one, but forgot to insert it. The value in having a link here is that we can use it to source list pages -- one could produce a page that had, say, Icehouse games with BGG pages with their BGG links. A pseudo-value rather than a pseudo-category, basically.


Ideas for how to do any/all of this? I can do 1, 4, and 5 (by fiat), but I still don't have a handle on semantic stuff.

Numerals versus number names

Hmm. I think we need to decide if we're going to list numbers in the info box spelled out (one minute, Stashes: Two), or in numerals (1 minute, Stashes: 2). I had initially begun using numerals everywhere for consistency, since I didn't want to write "twenty–thirty minutes", but maybe it would be better to use numbers spelled for numbers less than 10? I don't know, what do other people think? Oh, BTW, I like the new Infobox_Game_Sandbox. -- Lambda

I like the rule "spell until you reach a dozen", in general. It also connotes less precision (imho) to say "two minutes" than "2 minutes", for what that's worth. Rootbeer 08:28, 29 Apr 2005 (GMT)
My College Comp. Prof. said that you write it out until after ten, but that's for writing papers. However, I think numerals are more appropriate here. Go to a game shop and look at the side of boxes. The majority use numerals for their "infoboxes."--Tophu 16:21, 29 Apr 2005 (GMT)
I think that numerals are more appropriate, since they are easier to scan quickly, and that's the point of the infobox. -- Lambda 15:41, 1 May 2005 (GMT)
Well, we have two votes for numerals an one vote for spelled out when it's a dozen or under. Should we implement an actual voting process, or just say that it's been resolved as is? I'll go through and change everything to numerals if there's no objection. — Lambda 21:46, 2 May 2005 (GMT)
Actual voting? The horror! Don't make me sign up for extra accounts. :-) You can change every Infobox to numerals if you want. (You make a good point about infoboxen. And some details were meant for footnotes.) Of course, somebody else can change them all back tomorrow, as the next verse of the wiki song goes. I'd rather have you put the effort into adding content, if it were up to me, but let Do as Thou Wilt be the whole of the wiki law. — Rootbeer 21:58, 2 May 2005 (GMT)
Yeah, actual content would be better, but I can casually scan and brainlessly fix formatting, while actual content takes time and effort. And you're right, some of the details were meant for footnotes. — Lambda 22:07, 2 May 2005 (GMT)

This discussion is trumped by the work to make the InfoBox Semantic-Wiki-enabled. To do that numbers must be numerals. --David Artman 15:36, 29 June 2009 (UTC)

New Infobox design

We've learned a lot about wikicraft since the first Template:Infobox Game was posted. It has served us well, but we don't have to stick with that design, as the history of Template:Infobox Game Sandbox shows.

One thing we've learned is that there is no good way to add to the required list of template parameters once the template is in use. But we can, with some effort, now make a section of a template optional now if it's not needed in every game (e.g., mechanics, awards), so you don't have to have an entry like "Mechanics: Unknown" if you want Mechanics on some game pages.

The next step in revamping the Infobox is deciding what parameters we're going to require for every game, so that we can do all the template edits at once. Since anything else that comes along gets stuck down in the {{{footnotes}}}, and since we can't make any additional optional sections (like use_awards) without potentially editing every game page again, it's best if we add the new parameters all in one lump. Here's the list of current parameter candidates, with some commentary from me, as I see them:

  • subject_name (should be called "name_of_game"?)
  • designer
  • awards (not used unless use_awards is True)
    • use_awards (must be True or False)
  • image_link (any text to embed an image)
  • description
  • players
    • nonplayers (only needed for Zendo and tournaments? Probably better to add this under players.)
  • stashes
  • other_equip
  • setup_time
  • playing_time
  • complexity
  • strategy
  • random_chance (what do we want with this?)
  • mechanics (do we want this?)
  • theme (what do we want with this?)
  • prev_game (used with next_game for linking all games)
  • next_game
  • release_date (might be nice to know)
  • footnotes (anything else you want to say)

I would like somebody else to kick this list around a little and post a better version of it. Rename these, add some more, throw some out. Tell us why your changes make it better (not hard to do, since I haven't tried to make this list the best it can be). And we'll see whether somebody else can improve on your handiwork.

Unless, of course, you think it's perfect as it is. Then we can move right on to the contest phase, in which we compete to design the prettiest infobox that uses no more than the available fields. (You can choose to omit some fields entirely in your infobox, if you don't ever care about Mechanics, say. You merely can't add any new fields not in the list we come up with here, which is why I'm calling for discussion.)

Please post your variant parameter lists below, so that we can discuss them. Thanks! — Rootbeer (Tom) (U | T | C) 20:26, 5 Jun 2005 (GMT)

Well, if nobody else has any suggestions, here's what we'll go with as the official parameter list. All pages using the new infobox (whatever it looks like) will supply data for these fields:
  • name_of_game
  • designer
  • awards
    • use_awards (True or False to enable awards)
  • image_link
  • description
  • players
  • stashes
  • other_equip
  • setup_time
  • playing_time
  • complexity (May appear as "stars" or similar in the infobox; must be a multiple of 0.5 from 0 to 5)
  • strategy (same)
  • random_chance (no longer used)
  • mechanics
  • theme
  • prev_game
  • next_game
  • release_date
  • footnotes
Any changes before we start the Infobox design contest? — Rootbeer (Tom) (U | T | C) 13:31, 2 Jul 2005 (GMT)

Number of stashes

Now that the Treehouse Revolution is underway, I think we should revisit the stashes= part of the infobox. Make it more generic like pyramids= (examples: pyramids=4 stashes or pyramids=8 nests or pyramids=14 larges and 6 smalls). Perhaps it would help to do this in combination with the requisite number of colors, colors=. Your thoughts? - Cerulean 14:21, 28 Jun 2006 (GMT)