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."


 * ✅ 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)


 * Ernie's abbreviations of "basic|most|all" would be meaningless to me, even though I'm familiar with what services can be found in most outposts versus in most towns. I've done some data compilation, and there's simply too much variation for them to have a very consistent meaning anyway.  Among Prophecies locations, the only 2 standards I can see are:
 * All staging areas have Merchant and Storage
 * Except for PvP areas (Arena outposts), which have neither and have a Priest of Balthazar instead
 * Except for Pre-Searing areas, which have no Storage
 * All Towns also have Armorer, Weaponsmith, and Traders
 * Except for Ascalon City, no Rare Scroll Trader
 * There's nothing in between that would constitute a "most" category. "Basic" would be Merchant and Storage, but that's only saving you 1 line.  "Full" would be difficult to define in the first place, and would be extremely ambiguous to the reader - would "full" mean 1) what I said above for towns (in which case you have to except Ascalon City), or 2) what you can find in the "most complete" towns like Lion's Arch?  1) would probably be the most useful definition, but then you lose the original meaning of the word "full", because place like LA are "more than full".  2) is the most accurate definition, but then you have to make exceptions for nearly all non-port towns.
 * As for icons, there are too many services that don't appear in the Guild Lord's list. What do you use for Artisan, and how do you differentiate it from the Rare Material Trader when they are both concerned exclusively with rare materials?  Hero skill trainer vs. Skill trainer?  What do you use for Pet tamer?  Collector?  Costume maker?
 * The biggest question, in my mind, is how do we expect our readers to react to all this new jargon? I know that if I were a semi-regular reader of GuildWiki, I would be very confused by either of these changes.  &mdash;Dr Ishmael Diablo_the_chicken.gif 15:49, 15 January 2011 (UTC)
 * Using the Guild Lord icons is a good idea, and I think that should could cover TEF's basic/full service levels; anything above that is rather rare and could be spelled out until a creative genius comes along and provides icons for them. (Can't be too hard to have a pet tamer icon?) --◄mendel► 22:59, 15 January 2011 (UTC)


 * I left out Armor crafter, which is quite common; Collectors are everywhere; and even Artisans aren't exactly rare. The rest tend to appear in the most prominent locations, i.e. major towns.
 * I'm also still not convinced that our readers would appreciate this. The shift to use crafting material icons was different &mdash; any given GW player will be familiar with them since they appear in the inventory, and armor crafting is an integral part of developing a PvE character &mdash; but these NPC icons are nowhere near as prominent.
 * On the other hand, I accede the point that a collapsed list defeats the point of an infobox. In the interest of moving forward, I say we just stick with a plain list for now.  (I've previewed it on both Kodash and LA, and it really doesn't look that bad.)  &mdash;Dr Ishmael Diablo_the_chicken.gif 22:18, 16 February 2011 (UTC)

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...
 * — Tennessee Ernie Ford ( TEF ) 17:16, 12 January 2011 (UTC)

Cartographer percents
I've added support for the pixel-areas of locations as discussed on Talk:Grandmaster cartography guide. There's an outstanding issue from there that needs to be addressed: how to handle mission/explorable pairs. Suggestions on how to improve this implementation (property/parameter name, display format) are also welcome. &mdash;Dr Ishmael 20:01, 18 February 2011 (UTC)


 * This is great stuff; thank you for walking the whole of Tyria (pixel by pixel) and providing the details. — Tennessee Ernie Ford ( TEF ) 20:25, 18 February 2011 (UTC)

Mission/explorable pairs
Ideally, before addressing mission/explorable pairs, it would help to list all the possibilities and see how often the following situations occur:
 * No significant differences in carto (outside of when the area becomes available).
 * Mission = explorable + extra; i.e. can map explorable and not worry about mission
 * Explorable = mission + extra; i..e can map mission and not worry about explorable
 * Cannot fully explore without visiting both

With luck, one of the four possibilities predominates, so we can create a standard text and note exceptions. — Tennessee Ernie Ford ( TEF ) 20:25, 18 February 2011 (UTC)


 * I'm going to somewhat re-clarify the situations. Anything not listed in the table is a 1 (12: 3 Proph, 2 Factions, 7 Nightfall).
 * mission = explorable (most common in Nightfall)
 * mission < explorable (most common in Factions)
 * mission > explorable (rare)
 * mission <---> explorable (rare)
 * {| class="stdt"

! Location || Case || Notes Chahbek Village || 2 || Jokanur Diggings || 2 || Consulate Docks/Pogahn Passage || 3 || Gandara/Consulate are split, but Pogahn can access all Kodonur Crossroads || 2 ||
 * Minister Cho's Estate || 2 ||
 * Zen Daijun || 2 ||
 * Nahpui Quarter || 4 || M and E are separate parts of same area
 * Tahnnakai Temple || 2 ||
 * Arborstone || 2 ||
 * Boreas Seabed || 2 || 1,000 Knives GH only accessible in E
 * Sunjiang District || 2 ||
 * Unwaking Waters || 4 || M and E are separate, but mostly overlap; only the spawn point of M is unmappable from E
 * Raisu Palace || 2 ||
 * Churrhir Fields
 * Boreas Seabed || 2 || 1,000 Knives GH only accessible in E
 * Sunjiang District || 2 ||
 * Unwaking Waters || 4 || M and E are separate, but mostly overlap; only the spawn point of M is unmappable from E
 * Raisu Palace || 2 ||
 * Churrhir Fields
 * Unwaking Waters || 4 || M and E are separate, but mostly overlap; only the spawn point of M is unmappable from E
 * Raisu Palace || 2 ||
 * Churrhir Fields
 * Churrhir Fields
 * Churrhir Fields
 * Fahranur, the First City
 * Fahranur, the First City
 * Gandara, the Moon Fortress
 * Gandara, the Moon Fortress
 * Dejarin Estate
 * Dejarin Estate
 * }


 * &mdash;Dr Ishmael Diablo_the_chicken.gif 20:58, 18 February 2011 (UTC)


 * The Eternal Grove and Wilderness of Bahdza can be explored during their respective missions. Grove is empty of enemies, and if you kill all the other Luxons but leave the last Siege Turtle alive, you won't have to worry about the Tree Singers dying while you're exploring.  Bahdza is sparsely populated by plants, but the Bastion will probably be overrun before you can explore the whole area.   &mdash;Dr Ishmael Diablo_the_chicken.gif 19:14, 26 February 2011 (UTC)


 * Here's what I've come up with for displaying a note for instances that can't access the entire zone: (example would be for Consulate Docks mission)
 * 164244.5 (note)
 * The actual text of the note would be given as a parameter, of course. Based on the presence of this parameter and whether the location type is "mission," the code would set an additional SMW property so that the regional queries on here can exclude them from the sum. The second condition is necessary so that we can include notes on the explorable articles for Nahpui, Unwaking, Gandara but still have them included in the total.  &mdash;Dr Ishmael Diablo_the_chicken.gif 17:54, 28 February 2011 (UTC)
 * The actual text of the note would be given as a parameter, of course. Based on the presence of this parameter and whether the location type is "mission," the code would set an additional SMW property so that the regional queries on here can exclude them from the sum. The second condition is necessary so that we can include notes on the explorable articles for Nahpui, Unwaking, Gandara but still have them included in the total.  &mdash;Dr Ishmael Diablo_the_chicken.gif 17:54, 28 February 2011 (UTC)

Display format
Do you have something in mind? Are you primarily concerned with the info box? The facts notes at the bottom of page? Or a standard phrasing for Notes? — Tennessee Ernie Ford ( TEF ) 20:25, 18 February 2011 (UTC)


 * Graphic design. Is it ugly? etc.
 * The Facts about... is a standard SMW feature and should be discussed separately from this template (if, indeed, any discussion needs to be had at all). &mdash;Dr Ishmael Diablo_the_chicken.gif 16:50, 23 February 2011 (UTC)

Pilot
I have rolled-out a pilot of this infobox to all locations in Ascalon, except for missions. Questions / comments / cries of anguish are now being accepted. &mdash;Dr Ishmael 16:55, 23 February 2011 (UTC)


 * Template:Location_box2 is still on several Vabbi locations, if you want to extend the test of this box, maybe choose these? --◄mendel► 00:15, 26 February 2011 (UTC)


 * In the complete absence of any questions/comments/CoAs, I was just going to do a complete roll-out tomorrow for all of Tyria and Elona. If I can finish the Canthan per-location areas tonight, I'll include Cantha, too.  &mdash;Dr Ishmael Diablo_the_chicken.gif 19:13, 1 March 2011 (UTC)

Missions
I guess that's another question: should we adapt this template to include missions as well? We haven't had an infobox for missions before, and I'm not sure if it would be better to stuff them into this one or to create a separate one for them. &mdash;Dr Ishmael 16:55, 23 February 2011 (UTC)

n/a as display
I'd prefer to see something other than "n/a" when something isn't applicable or information isn't available. Perhaps:
 * Something new (to be used in place of "not applicable" &mdash; and another icon for "not available," if we should have the need)
 * Something new (to be used in place of "not applicable" &mdash; and another icon for "not available," if we should have the need)
 * Something new (to be used in place of "not applicable" &mdash; and another icon for "not available," if we should have the need)

— Tennessee Ernie Ford ( TEF ) 00:52, 3 March 2011 (UTC)