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)


 * I hadn't thought of dungeon maps. Although, wouldn't the best solution be to combine the multi-level maps into a single image?  (e.g. Bloodstone Caves)  I'd think that would be easier on our readers, so they don't have to click back-and-forth or open multiple tabs for individual level maps.  But I don't really use the maps anymore, so I'm not 100% certain what a "normal" user would think.  &mdash;Dr Ishmael Diablo_the_chicken.gif 15:37, 13 January 2011 (UTC)


 * I thought of an alternative that combines the best of what we both want to see, but I don't know if it's practical (possible or worth the time/effort to setup): the info box will continue to use a single input each for the map & caption, but instead of being an image, it would be a template that collates the n-images for the maps.


 * People need only click once to see all maps expanded to a single tab.
 * People (like me) have the option of separating the maps.
 * This solution can also accommodate situations in which there are multiple routes for a quest, to a boss, or to an outpost.
 * Keeps the infobox contents relatively simple; hides complexities, while allowing non-technical contributors to be able to contribute updates.


 * I expect the inputs would be something like, with N = 1, 2, 3, 4, 5 &mdash; the number pointing the template to a widget that arranges the maps based on N. (e.g. 2 would be side-by-side).  — Tennessee Ernie Ford ( TEF ) 20:09, 13 January 2011 (UTC)


 * Frankly, that sounds like it would be impossible (or at best impractical) to implement within the wiki. Multiple routes can be shown in a single image - either take the time to walk them all in-game (like I do with the Nick maps) or just draw them in.  I know GWW has a lot of multi-route maps like that, using different-colored dots (I've tried doing that, but the paint-bucket tool seems inadequate for re-coloring the dots, and I don't know how else to do it).
 * Since you brought up bosses: Having multiple images does make sense for NPC/bestiary articles, since they often show up in different locations, but that's a different infobox.
 * The existing location box only allows a single map image, so I think we should roll ahead with that for now, leaving the discussion open for possibly including multiple maps in the future. &mdash;Dr Ishmael Diablo_the_chicken.gif 20:08, 14 January 2011 (UTC)


 * ✅ We stick with the easier-to-implement single map solution (for LI template) and we can worry about making it easier to update maps later.


 * Side note: I think you misunderstood my idea about the multi-image widget: the idea would be that it could be used to replace any [[File:Image]], not just for maps in the LocationInfo box. I'll see if I can mock up something, since, pseudo-ironically, a picture of a multi-image widget would be worth 1000 words. (And yeah, I realize naming the template consolidated map gave the wrong impression.)


 * Side note: I also think that it's unrealistic to expect that any single contributor is going to want to walk an entire dungeon just to fix one LoD on level 2. (I can tell you that I have avoided that myself more than once.) However, I agree that we can wait to worry about it. The priority should be on stabilizing this iteration of the LI box so we can start using it. — Tennessee Ernie Ford ( TEF ) 20:37, 14 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)
 * What about a collapse/show for the lists? 72.148.31.114 10:11, 15 January 2011 (UTC)


 * If "services" appears in the info box, then I think something should be visible besides show, otherwise folks are forced to click (defeating part of the purpose of an infobox, i.e. data at-a-glance). So, something like one of the following:
 * Services: Basic ← the word basic would be a show link
 * Services: Basic [show]
 * Services: 5 [show]
 * Services: Basic ← the word basic would be a link to the Services section of the article
 * Services: Basic [link-to-Services-section]


 * Each example offers some data; the user can click to get/find the details. — Tennessee Ernie Ford ( TEF ) 11:15, 15 January 2011 (UTC)
 * I like having a "show" button there - makes it not clutter up the page if you already know about basic services, but allows you to check if you don't - good idea --  Random Time  11:19, 15 January 2011 (UTC)
 * To know about the party size is uninformative if it's standard (e.g. 8 in Elona, or 2 in Pre-Searing). Couldn't the size be inherited from the region if it's not specified? And not displayed in the infobox if that's the case?
 * Services could well be represented by icons, that would allow for a large number to be discerned at a glance, and a complete listing in limited space. Since the NPCs representing the services are still listed on the article (one hopes), a "show" link is superfluous (or could be a link to the standard heading for the NPC section). --◄mendel► 13:43, 15 January 2011 (UTC)