Template talk:LocationInfo

Initial RFC
Awright, I'm finally getting back to SMW stuff. Here's my first draft for the location infobox. Mostly, I just took the old {location box} and added properties where they would be useful. Which, as it turns out, is basically what PanSola did with {location box2}.

However, I deliberately left out the "Services" section he had included, because that could get extremely cluttered for larger outposts and towns (case in point, The Kodash Bazaar). I almost want to cut out "Neighbors" as well, but since that's been in the box since the beginning, I figured it would be bad form to drop it without having a discussion on it. My reasoning on this is that these two data sets are multi-valued lists that can be given in a more appropriate layout, and with additional information (direction of exit to neighbor, name/location of service NPC, etc.), as sections within the article. Which we already do anyway.

Also, I left out a good bit of the extra coding that PanSola had included. The recursive PropertizePartOf stuff that he was using is unnecessary, since that can be handled more efficiently on the other end, when performing a query.

Finally, I set this up specifically for sub-region-level locations. Regions and continents could be stuffed into this template (I actually had that coded at one point), so that's open for discussion. Landmarks, however, should definitely have their own infobox. &mdash;Dr Ishmael 03:55, 29 December 2010 (UTC)
 * Assuming the services section was represented using an icon grid and not a text list, wouldn't it possibly fit? It would still be very cluttered on the variable end, granted... but depending on the image size, it wouldn't break the rest of the box or drag on forever. — ı  z  ǝ  Ⅎ  05:22, 29 December 2010 (UTC)


 * What icons would we use? There aren't any, AFAIK.  &mdash;Dr Ishmael Diablo_the_chicken.gif 14:47, 29 December 2010 (UTC)


 * Here's a few. The rest could probably be filled in using inventory or UI icons. — ı  z  ǝ  Ⅎ  02:10, 30 December 2010 (UTC)

Services
I think we could abbreviate services data appearing in the info box as follows:
 * Outposts
 * Minimal/Outpost level (e.g. Xunlai); applies to outposts.
 * Complete/Town level (e.g. all the usual services)
 * Extended/City level (e.g. Port Cities, capitals, alliance owned...)
 * Custom (doesn't fall into above patterns)
 * Explorable areas; there's no easy standard, but only a few service types are helpful to players typically, so: use icons for only the most interesting:
 * Merchant
 * Crafter
 * Collector
 * Other

I agree that it's not useful to include more details than this in the info box. And even this much detail might not be needed. — Tennessee Ernie Ford ( TEF ) 18:26, 11 January 2011 (UTC)


 * I took a little inspiration from Wikipedia (specifically, the Chembox template, in-use example here) and incorporated collapsible frames for the Neighbors and Services lists. That way, they can still be in the infobox, but the lists are hidden by default.  Thoughts?  &mdash;Dr Ishmael Diablo_the_chicken.gif 17:39, 12 January 2011 (UTC)


 * Perfect! (I like using icons over names, but I trust your judgment to what works/fits best.) — Tennessee Ernie Ford ( TEF ) 18:26, 12 January 2011 (UTC)


 * Honestly, I'm worried that the icons would confuse more people than they would help. I doubt very many players spend a lot of time looking at their Guild Lord's list of services, and only a few of them are instantly recognizable (rune and dye trader).  &mdash;Dr Ishmael Diablo_the_chicken.gif 20:33, 12 January 2011 (UTC)


 * "I trust your judgment to what works/fits best."

Images (maps, too)
— Tennessee Ernie Ford ( TEF ) 18:26, 11 January 2011 (UTC)
 * Since the info box is a fixed size, why not limit the map and image sizes?
 * GWW allows for multiple maps in the infobox, which I think is appropriate. They also separate the image from the caption. Ideally, I think we should do both. (If this is meant to be an iterative process, it can wait for the next iteration, o/c).
 * If you want to limit the number of maps, it could be: map of area, getting there map, bosses, collectors
 * GWW also allows for multiple non-map images; also useful.
 * Could be limited to e.g.: scene, resident, denizen, world-map scene, ...


 * Yeah, that would make more sense.
 * I actually don't like how GWW has all the maps in the infobox. If I go to an area's page and scroll down to the list of bosses to read what elites are available there, I don't want to have to scroll all the way back up to the infobox to find the boss map, I want it right there with the boss list.
 * Non-map images are generally non-informational and thus don't belong in an infobox. They should be used as "flavor" images in the rest of the article or organized into a gallery section.
 * &mdash;Dr Ishmael Diablo_the_chicken.gif 19:25, 11 January 2011 (UTC)


 * Ok, so we agree on limiting the info box's image sizes (and separating captions), but disagree about where to put images for local color/flavor and bosses. I think an image for local color makes sense (usually the screen load image) &mdash; would that be ok? And I disagree about the convenience of the boss maps (the [HOME] key is my friend), but I would support an alternative standardization (so that boss maps appear in the same section, use a standard size, ...).


 * Neither GWW and GWiki have getting there maps, which I would like to see (esp. for outposts). I think they belong in the info box, but my guess is you would want them placed in the appropriately named section.


 * What about dungeon maps? There are anywhere from 1 to 5 (plus alternative routes). Probably, it would be worth discussing what data belongs with the dungeon and what belongs with the associated quest. Again, I probably would put them in the info box, but I can see you suggesting that they belong elsewhere. And, again, I would support an alternate standardization. — Tennessee Ernie Ford ( TEF ) 19:58, 11 January 2011 (UTC)

Other
GWW's template also has room for chest, quest, and party size. Of those, I think quest is the most critical (and perhaps quest-giver, so that people don't have to switch pages to see where to get the quest). (I think in region could be simply, region.) — Tennessee Ernie Ford ( TEF ) 18:26, 11 January 2011 (UTC)


 * Party size would probably be a good thing, yes. It obviously would only apply to outposts, because you're only restricted at the time you form the party (cf. caravan vanquishing from ToA).  I only mention this because I noticed GWW lists party size for dungeons, where it doesn't make sense.
 * I'm not as sure about chest and quest, but... eh, sure. I don't think I'll propertize them, though, since both are explicit 1-to-1 relationships.
 * "Region" as the property name would mirror the way we already use "campaign," so I'll go with that. I was mostly re-using PanSola's property names so I didn't have to do too much work on that front.  I did change "Has neighbors" to "Neighbor of" because I don't like using "Has x" as a property name unless there's no alternative (it could be mistaken as a simple boolean, "Does y have x?" instead of the intended, "Which / What kind of / How many x does y have?").
 * On that note, if you can think of a better name for "Has services," that would be great. &mdash;Dr Ishmael Diablo_the_chicken.gif 16:15, 12 January 2011 (UTC)


 * ✅ Party size.
 * ✅ chest & quest &mdash; let's at least keep quest, since it makes a huge difference to people when they are forming groups, deciding where meeet etc.
 * ✅ Region and neighbor of...
 * ✅ Has services: suggested alt names (brain dump):
 * Services: y/n
 * Services: [list]
 * Services offered: [list]
 * Services: [basic|full|custom] (outpost); [merch,|craft,|armor,...] (explorable)
 * Split up standard from unusual AKA custom
 * Outpost services: [[basic|most|all]
 * Custom services: [y|n]
 * (I'm not sure your intent wrt services: list them all? compact list? ) — Tennessee Ernie Ford ( TEF ) 17:16, 12 January 2011 (UTC)