The discussion has basically not really resolved anything or even made any substantial compromises other than 'I want full screen width maps'.

Is it acceptable to allow dynamic maps to be sized to an individual contributors personal viewing preferences?

I would continued to advocate no. We should allow freedom to extend the dynamic map width up to 500 pixels if required by local geographic considerations. In all cases the map must be right justified. Andrewssi2 (talk) 13:50, 22 June 2014 (UTC)Reply

What do we do with the map aspect ratio of pure east-west itinerary (such as Trans-Canada Highway)? It's not very tall, but it's 8000km wide. K7L (talk) 14:09, 22 June 2014 (UTC)Reply

And the Trans-Siberian Railway which BTW will be put on the Ftt pedestal in two months. ϒpsilon (talk) 14:15, 22 June 2014 (UTC)Reply

A quick look shows that those maps are 600 pixels and 620 pixels respectively.

I'm fine for alternative suggestions for a pixels limit that works for most outlying scenarios (again, if a custom dimension is required by the geography covered).

A quick test User:Andrewssi2/Scratch suggests that a map of 500 pixels is acceptable on a 1024 pixel width screen and a map of 700 pixels is about acceptable of a 1280 pixel width screen (Only the first map renders, however we can see how the text fits to the left in each pixel version) --Andrewssi2 (talk) 14:37, 22 June 2014 (UTC)Reply

I'll reiterate my support for default size unless absolutely necessary, right aligned in all cases. My suggested limit was 550px. Texugo (talk) 16:08, 22 June 2014 (UTC)Reply

I absolutely disagree - the map size should be appropriate for the area depicted and editors should use their own judgement. Sometimes 400x400 is OK, sometimes 1000x600 would be justified. Right-alignment should depend on the width of the map - I could agree 500px is the maximum width at which right-alignment should be used. PrinceGloria (talk) 18:12, 22 June 2014 (UTC)Reply

Indeed, as long as we have itinerary which runs pure north-south or pure east-west, no "one size fits all" policy will do anything useful. K7L (talk) 20:02, 22 June 2014 (UTC)Reply

I agree with Texugo - maps where the default size doesn't work are the exception rather than the rule. If the area is oddly shaped, use a different size and note the reason in the edit summary, but aside from those uncommon cases let's request that people always use the default size and alignment so that every map addition doesn't become a subjective exercise dependent on the preferences of whoever happens to be editing the article. -- Ryan • (talk) • 20:56, 22 June 2014 (UTC)Reply

I try never to exceed 800 pixels. 1000 pixels, when you add to it the left sidebar and other UI accouterments, could very well be too wide for some screens. Powers ^(talk) 21:25, 22 June 2014 (UTC)Reply

800 pixel is a reasonable limit for the width. I think that a lot of articles benefit from a custom shape. It is important that the maps of city districts roughly match the shape of the district. Otherwise readers may not realise that they should be looking in another article for details of something that appears on the map. I know that mapmask is the real answer to this, but it is a lot of work to create one. AlasdairW (talk) 22:07, 22 June 2014 (UTC)Reply

So can we agree that the default size should be used, except on an exception basis agreed on the article's discussion page?

For example, the Siberian train route between Berlin and Beijing would be an obvious exception. A map of a square city center should not be an exception ? Andrewssi2 (talk) 23:52, 22 June 2014 (UTC)Reply

I don't want to codify that you have to start a talk page discussion before you can set the map size at anything other than 420×420px. Too many talk pages on this site have one or zero watchers.
Thatotherperson^talkcontribs 00:37, 23 June 2014 (UTC)Reply

I still vehemently oppose any policy that says maps should always be right-aligned. Some maps need to be long and narrow. Others have brought up itineraries already, and we can't ignore the fact that we're on the cusp of dynamic maps becoming usable at all levels of the geographical hierarchy. They are already usable for lowest-level regions, and will be usable for mid/high-level regions and countries once we can draw color-coded shadings. What are the maps at Aleutian Islands and Tennessee going to look like if we insist on using square-ish map frames? Do we want our map of Tennessee to show most of Kentucky and half of three other states for the sake of being square? We absolutely need the flexibility to use long, narrow maps in some situations, and when the long direction is east-west, we need to allow center-alignment.

I do agree that we don't want 800×800px maps dominating the screen – considering there's a link for a separate full-screen version – but a center-aligned 800×400px map that doesn't take up much vertical space is a different issue altogether. What if we set a width limit of 550 or so pixels for right-aligned maps only and then recommend that if a map needs to be significantly wider than it is tall, like that map of the Trans-Canada Highway, it should be turned into a stripe map: center-aligned, widened to about 800 pixels, shortened height-wise if possible, and placed either at the bottom of the 'Get in/around' section or after the opening paragraph of it (to limit the awkwardness of the whitespace on the sides). That way we can set the shape of the map however we need it, up to a little more than twice as wide as tall, while limiting awkward displays on as many screen resolutions as possible. (I changed my screen resolution setting to 1024 pixels and an 800 pixel-wide map doesn't require side-scrolling.)
Thatotherperson^talkcontribs 00:37, 23 June 2014 (UTC)Reply

We have established that exceptions are required. We have moved beyond 'one size fits all' earlier so there isn't a reason to concern that point. Noone is asking that every single map needs to be square.

I don't mind how the process of an exception is done. If noone comments on the talk page of an article then you have sufficient basis for your exception.

For non-exceptions, I personally just want a standard size to be used and right justified. Any suggestion for the very maximum size of a standard square map would be appreciated. Andrewssi2 (talk) 01:35, 23 June 2014 (UTC)Reply

Some maps can't even resemble a square though, hence the need to allow center-alignment. My point about the talk pages wasn't that it might be impossible to gain consensus, but rather that you shouldn't have to post a talk page message no one is going to read before making a tweak. As a perfect example, I just went to add a map to Central Utah and found that I needed an extra 50 pixels height to show the whole region at zoom level 8, where 13 out of 15 POIs are shown and only two are stuck in a cluster. You could use the default size at zoom level 7, but there would be massive gray areas and only 4 out of 15 POIs would be visible outside the clusters. This type of common sense tweak shouldn't be written into policy as something that requires talk page approval when so many of the discussions would be decided by just the one person anyway. Also, I'm not sure what you mean by "For non-exceptions, I personally just want a standard size to be used and right justified." That's why we have a default size and alignment coded into the mapframe template. I thought we were having this discussion specifically to decide what exceptions people are allowed to make.
Thatotherperson^talkcontribs 02:17, 23 June 2014 (UTC)Reply

My previous comment stated "Noone is asking that every single map needs to be square". Sorry, I can't make it any clearer.

The origin of this discussion is for maps such as Berlin/Mitte which do fit into a square, and for which an exception is not obvious apart from the purely personal preference of the contributor. Andrewssi2 (talk) 04:52, 23 June 2014 (UTC)Reply

Go one zoom level lower on Berlin/Mitte and tell me the map is of any use then. Can we be serious here? PrinceGloria (talk) 04:54, 23 June 2014 (UTC)Reply

Yes, I think we can be serious. In order to shoot down the hyperbole around the 'sea of yellow plusses' I hereby provide the screenshot to the right.

You might personally prefer a massive map breaking the flow the article, however the screenshot actually does look better and proves clearly that dynamic maps do work fine and actually look better in their standard size for normal city articles. Andrewssi2 (talk) 05:34, 23 June 2014 (UTC)Reply

How so? I see about as many yellow +'es as actual POI's. K7L (talk) 11:28, 23 June 2014 (UTC)Reply

I guess then we have an impasse. The point of yellow plusses was to make the map more navigable given a high number of POI's. Do we accept that the reaction every time to avoid these yellow plusses is to place a massive map in the middle of the article and basically break the flow?

Maybe I'm the only one seeing this as a problem, in which case consensus would have to direct me to give up and accept that massive dynamic maps are now a rationale reaction whenever a few yellow pluses bother a contributor. I think the quality of our site is poorer for this. Andrewssi2 (talk) 11:42, 23 June 2014 (UTC)Reply

(edit conflict - responding to K7L above) Yellow pluses would only be a problem if the map were not dynamic. But the map is perfectly usable at the default size, and if you were going to start checking out the details of street names and/or relative positions, you're almost certainly, in either case, going to end up zooming in further and scrolling around anyway, so there is really no advantage to basing the map size on how closely POIs are clustered and sacrificing article flow in the process. Logically, compared with our static maps, very very few of which we have felt to need to present at a huge size in the center of the screen, having these nice, easily-manipulable dynamic maps should allow for us to have fewer giant blown-up space-hogging centered maps, not more. Texugo (talk) 11:48, 23 June 2014 (UTC)Reply

Well, Andrewssi2, you're obviously not the only one. Texugo (talk) 11:49, 23 June 2014 (UTC)Reply

Thanks Texugo Andrewssi2 (talk) 12:59, 23 June 2014 (UTC)Reply

Texugo and Andrew, you see "disturbed flow of text" as a problem, and you two are the main contributors in this discussion. I would say the rest of us doesn't, and we rather see the "sea of yellow pluses" as a problem. I think we are in an impasse, and as such, I would say we will not reach a one-size-fits-all prescribed solution. Let us focus on agreeing what we can agree upon, e.g. the max width of map where right alignment should be used as opposed to centering, and maximum width and height of the MapFrame. PrinceGloria (talk) 13:03, 23 June 2014 (UTC)Reply

Ryan and AndreCarrotflower have also agreed with us, so I don't think it fair to posit your position as some majority that includes "the rest of us". At any rate, any problem from the so-called "sea of yellow pluses" can be resolved with a mere 1/4-cm movement of the index finger, and as mentioned, once they start looking at the map, most people will already be zooming in and out and scrolling around anyway, no matter what the original map configuration. On the other hand, the chasm across the middle of the article, the interruption in the text flow, and the generation of wasted white space cannot be resolved by the user at all, so any situation where Berlin/Mitte is all it takes to justify interrupting the article with a giant square flanked by white space is completely unacceptable to me. Texugo (talk) 13:18, 23 June 2014 (UTC)Reply

Also, I'd like to point out that by saying "let us focus on agreeing what we can agree upon", all you're really doing is telling us we should concede the points we don't agree on, with the expectation that lack of consensus means you can do things your way. That seems a bit disingenuous to me. Texugo (talk) 14:48, 23 June 2014 (UTC)Reply

Actually, a lack of consensus means that the infamous status-quo bias applies. You seem to be fine with that when it suits your purposes (such as with the ongoing deadlock regarding links to Wikipedia) but now it's somehow an issue? K7L (talk) 15:18, 23 June 2014 (UTC)Reply

On the contrary, status quo would suggest that, sitewide, images of any kind have only very rarely been centered, and those rare cases have always involved panoramas with aspects of about 5:1 or higher, and that no image even approaching the vertical dimensions of one of these maps has been centered in any article. An approach such as PrinceGloria's, which sets a low bar for centering big tall images, allowing them to proliferate across the site, is undoubtedly the novel proposal in this case. Texugo (talk) 15:30, 23 June 2014 (UTC)Reply

(edit conflict) I think the last time we had any agreement on this subject the decision was to use the default size unless there was a clear reason not to do so - see Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment ("4. Use the default map size (width/height) unless there is a specific reason for using a different size, in which case the reasoning should be explained in an edit comment or on the article's talk page. Zoom should be modified as appropriate."), and the discussion behind that decision - Wikivoyage talk:Dynamic maps Expedition#Are we ready to start deploying dynamic maps across the site?.

That said, what is the counter-proposal being made in this discussion? To always have map sizing be subjective? With the exception of the argument above about using a larger size to eliminate yellow pluses, the only argument I saw for non-default sizing was in cases where the geography didn't suit a square map, and that should already be allowed given the "unless there is a specific reason for using a different size" caveat in the existing guidance. I think the status quo is actually what the majority of people in this discussion are arguing for, or am I misunderstanding what has been written? And if I am, can someone please summarize? -- Ryan • (talk) • 15:31, 23 June 2014 (UTC)Reply

My interest here is that I have been formatting maps in the articles I edited quite carefully to make sure: 1) that as many POIs as possible are visible 2) that the default view is actually useful without the user having to zoom in or pan out, or scroll to get a good overview of the area. The dynamic features are just great for further digging into the map, increasing level of detail, or panning out to see how far the POIs described are from larger-scale stuff not in the map as presented, but the map should also be illustrative as it is opened, not just a random window with stuff - otherwise, we might have just as well placed a link to OSM without any MapFrame, or simply told people to go to Google Maps and stop being such wimps.

I do not want the carefully formatted maps to be right-justified and resized to 420x420 just because "this is the standard". I see no benefit in this particular standard for the traveller, it just satisfies the anancastic tendencies in some of us (and I admit we all have them, I guess I exhibited them at other occasions). This is why I oppose standardization of size and shape here - I believe we gain nothing from that (except for avoiding horror vacui). PrinceGloria (talk) 16:21, 23 June 2014 (UTC)Reply

There are no anachronistic tendencies involved here, so there's no need to bring up that accusation. It is simply that any advantage of your approach — i.e. ensuring that the dynamic functions of dynamic maps are ostensibly unneeded for a cursory overview of the relative arrangement of some unlabeled numbers, even though any further investigation will undoubtedly require using those dynamic features anyway — is marginal in comparison with the drawbacks in layout consistency, flow continuity, and economy of space. The only advantage of your approach is that it saves the user a fraction of a scroll of the mouse in a situation where they will probably be scrolling the mouse anyway, and that is not worth throwing our consistency and good layout sense out the window for. Texugo (talk) 17:19, 23 June 2014 (UTC)Reply

Let me address these:

1. Layout consistency - given the number of different devices and browser a reader may use to browse our content, and the possible settings etc., there is no achievable layout consistency. I don't think having maps 420x420 will change much - for some viewers, a 420x420 map will fill the entire screen, for others it will be 1/3 of page width.

2. Flow continuity - I believe placing the maps between sections does not hamper flow continuity even if they are centered.

2.1 We are also not writing a novel - my assumption is that most readers will not be reading our entire guides as a continuous work of literary art, but rather using it as a reference, accessing the sections they need and reading whatever they find interesting. Unless we break a continuous paragraph of text with a map with blanks on the sides (which I believe we shouldn't, see above), I see no harm done.

3. Economy of space - this is an online guide, space comes for free. And when it comes to printing our guides, guides where it makes sense to make the maps go over 420x420, like Berlin/Mitte, would print on over a dozen pages anyway. Devoting one page to a map does not seem a problem to me - if anything, I hate print guides which have too small maps. I'd rather do away with unnecessary verbosity in a guide, but one is useless to me without a proper map.

PrinceGloria (talk) 18:03, 23 June 2014 (UTC)Reply

PS. Anancastic, or anankastic, not anachronistic. Just to make sure - used in a jocular way, not implying anything personal.

You are conflating inconsistency of source with inconsistency between devices, but currently pages viewed on a single device are relatively consistent with one another. Your proposal would be adding a second layer of inconsistency. You can also say that stopping the article, putting a big tall image flanked by white space, and the restarting the article underneath it does not interrupt the flow, but you would be wrong. It is plain poor layout, whether it's a novel, a newspaper, a website, or a travel guide, and increases the amount of scrolling needed to refer back and forth to the actual listings and diminishes any chance of have the map and text relevant to it on the screen at the same time. "Devoting one page to a map does not seem a problem to me" - me neither - it is best viewed as an entire page, just a mere click away, and for anything else a mere roll of the mouse scroll is very much more than simple enough. I don't know why you feel the urgent need to try to approximate the full giant map within the article too. Texugo (talk) 18:26, 23 June 2014 (UTC)Reply

I am not seeing our articles as consistently laid out - we have a general structure of having a banner at the top and some headings that are typical for a given type of guide, but each guide is different. I have no problems with that, and certainly not with different map sizes. I actually do format my guides with my experience in mind - as I have yet to be able to access somebody else's. And my experience is that a large map in an article helps me, and I like to pause reading the guide and just look at the map without any scrolling to get an idea of the place, rather than resize, rezoom or open in a new window. For individual POIs and such, I just click the icon and jump out to another window/tab to see its precise location. But it is a bit meaningless before I get a good spatial orientation of the area that the "MapFramed" map affords me. The way the map is shaped and framed also gives me an idea of the place's spatial orientation and its limits. This is my experience. Yours, I understand, is different. PrinceGloria (talk) 18:45, 23 June 2014 (UTC)Reply

PS. To me, a guide that squeezes a map somewhere on the side of the page and tries to make it half the size required has poor layout. With modern DTP techniques, you can have your map as large as you need, in any shape that your page size allows. I like (print) guides, who have no reservations about breaking text with large maps. I don't like (print) guides, who stuff little illegible maps at sides of pages, which are usually useless and I have to consult a different map anyway (not very useful if you're trying to find your way in a city). Finally, I hate guides whose editors think it is great to have text "flow" around a map or article making it fit a narrow column I find hard to read. Again, my personal experience.

Once again, your justifications rely on ignoring all dynamic aspects of the dynamic maps and pretending they are useless unless you make them huge, which is not at all true. While we're repeating ourselves, I'll go ahead and sum it up once again: the entirety of your approach amounts to encouraging drastic, unnecessary, inconsistent layout changes at whim in order to save an insignificant 1/4-cm mouse motion that will in all likelihood be executed regardless. Texugo (talk) 18:56, 23 June 2014 (UTC)Reply

It seems like there is a fundemental difference of opinion with how the site should be used. PrinceGloria is a passionate advocate for evolving the site and this engagement is to be encouraged.

At the same time, we should recognize that as individual's we do not 'own' individual articles and that we need community buy-in before establishing new practice where there is no article specific reason for an exception. Andrewssi2 (talk) 00:19, 24 June 2014 (UTC)Reply

You and Texugo are the ones proposing new restrictions, it's up to you to find consensus for these changes. As for "an insignificant 1/4-cm mouse motion", how does one do that on a paper copy? An .ePub? A .pdf? Current policy is that the print version matters and I don't see consensus to change that. K7L (talk) 00:22, 24 June 2014 (UTC)Reply

Please take a look at any static map, for example Manhattan/Chelsea. You will note that these are smaller and right alligned. If the print version matters then when are they not enlarged and centered in the same way that is now being attempted with Dynamic Maps? Andrewssi2 (talk) 00:32, 24 June 2014 (UTC)Reply

Yes, I believe it has already been established that maps, whether dynamic or static, big or small, are always better printed out separately. And K7L, you've actually got it exactly backwards. As Ryan pointed out above, the status quo written guidance on the subject says

Use the default map size (width/height) unless there is a specific reason for using a different size, in which case the reasoning should be explained in an edit comment or on the article's talk page

and as I pointed out, the status quo practice which has been in place for years has basically been to never center anything but the occasional high-aspect-ratio panorama image. So actually Andrewssi2 and I are simply defending the status quo, and the new idea that requires consensus here is this suggestion that we start sizing and centering maps at the whim of the editor at the time. Texugo (talk) 02:45, 24 June 2014 (UTC)Reply

I was under the impression that the maps in articles were supposed to be sufficiently high-resolution to be usable if simply printed as part of a page. Please pardon me if you addressed this above, but do you disagree with that? Ikan Kekek (talk) 03:05, 24 June 2014 (UTC)Reply

I'm not sure that is written down anywhere, and actually I think the idea was slightly different: that such maps should be usable (online) without having to click on them to expand. Either way, it is fairly reasonable guidance for static maps like File:West End map.png. Static maps have, well, static text which cannot be read if the image size is too small - i.e., in the case of static maps, image size affects the resolution. This is not an issue for dynamic maps, which a) only show the POI names when you click on each one, b) automatically size the other text to be legible at the viewed size, and c) do not have their resolution affected by resizing anyway. Texugo (talk) 03:16, 24 June 2014 (UTC)Reply

Here is Greenwich Village as exactly represented in the Manhattan/Greenwich_Village article. Is this sufficiently high-resolution to be usable if simply printed as part of a page? I would suggest not, and this appears to be the typical presentation format so far.

I think the point is whether the map is sufficiently high resultion enough when opened at full size in another window and then printed. Andrewssi2 (talk) 03:27, 24 June 2014 (UTC)Reply

it's kind of a moot point anyway, since dynamic maps are not fully usable enough to see which street/block thePOIs are on until you zoom in to about 17, which is not remotely practical as a default zoom level anyway. Texugo (talk) 03:36, 24 June 2014 (UTC)Reply

(ec)My impression is the same as Ikan's -- maps are supposed to be sufficiently high-resolution to be usable if simply printed as part of a page -- it's certainly been in my mind every time I've drawn a map the last few years. Perhaps it was an ideal to aim for, if rarely achieved. Unfortunately, I don't recall where those discussions took place, it may have been part of the regions map discussions as opposed to city maps.

420px is actually pretty small for a city map. Manhattan/Chelsea, referenced above, is 440px. Most of the maps drawn for Chicago, Washington, D.C., Baltimore, Bangkok and Bali that have an east-west orientation are at least 500px. Many are 600px. They're not all readable on-screen, but it's been standard practice for many years, at least among some map makers, to have static maps in the 500-600px range. Centering maps is very rare though, the only exceptions I found are Baltimore/Inner Harbor and Washington, D.C./National Mall. -Shaundd (talk) 03:38, 24 June 2014 (UTC)Reply

Take Berlin/Mitte for example. Blowing it up so you can afford to zoom in another notch does eliminate some of the pluses, but there are still some pluses and even for the individual POIs that you can see, you cannot really tell what street, what block, or sometimes even what side of the street they are on, so gains in usability are really minimal. And it would be impossible to frame that map so that it shows everything at a truly usable size, so this usability angle is really kind of pointless. Texugo (talk) 03:45, 24 June 2014 (UTC)Reply

I am of a very different opinion regarding usability. With the current zoom level in Berlin Mitte, you can make out the street grid, the most important places, the river and such. Sure you can't make out detail such as the side of street the place is on, but this would be impossible unless we zoomed to 17 or 18 - this is now what the map is for. The map is for getting a general idea about the layout of the district or city. For detailed navigation, if required (most POIs can be made out from the other side of the street, so if you are on the "wrong" side, you just cross it), one should use a GPS device or a large print map one can get in a bookstore or from tourist information. That is why we still provide addresses and add directions to POIs. If anything, the only gripe I have with the Berlin/Mitte map is that the name of Unter den Linden won't show, but that's the peculiarity of the map layer we use.

Regarding static maps - their readibility is very much dependent on resolution, but their aesthetic effect on the layout is dependent on screen resolution. In my screen that I am using now, the map of Greenwich Village is too small to conveniently make out the text - I'd rather it was zoomed some 30-40% for the descriptions to be legible. But then if I did so and later changed for a smaller resolution screen, I'd find the map unnecessairly blown up to a huge size, and totally squashing the layout of the article (a 600px wide map provides for a narrow paragraph of text if right-aligned and displayed in a screen that allows only 800px for the article body). Dynamic maps have some of such issues too - this is why I would recommend to center them when they are over 400 or 450, because we NEVER know what device and browser window size the reader will use, and it's better if they are abhorred by some white space then if they can't read a paragraph of text - but they seem to work better with different resolutions than static maps.

Finally, I like to add pictures to both Get in and Get around, especially the latter - those are very useful pics, as they are usually public transportation schematic maps and such. If they clash with the right-aligned map when the screen is resized or if they get pushed towards a different section, it truly does nothing for "article layout". PrinceGloria (talk) 05:27, 24 June 2014 (UTC)Reply

The thing is, your subjective concept of usability, or anyone else's, is still fully available at default size and alignment with just a minimum of mouse movement. Everything else is just you saying "I prefer big wide maps", which is not an argument.(No, the print version has nothing to do with it, because if you're printing, you need to print out a larger map anyway.) And yes, I am aware that different screens display differently - that has nothing to do with it, as it is a logical fallacy to say "attribute A varies based on X, therefore we should multiply further variations of Y in as well". That just compounds the unpredictability at the user's end even further. To your third point, centering images has never been an acceptable way to deal with an overabundance in any section, and at any rate, if the city is complex enough to require a transport map, surely it should have at least a couple of paragraphs of accompanying text in the Get around section, which should be plenty to keep it from being pushed far into the next section. Texugo (talk) 11:51, 24 June 2014 (UTC)Reply

We seem to have two slightly different instructions on how to use dynamic maps, depending on the page you read:

1. . Wikivoyage:Dynamic maps Expedition says (as Ryan pointed out above), "Use the default map size (width/height) unless there is a specific reason for using a different size, in which case the reasoning should be explained in an edit comment or on the article's talk page. Zoom should be modified as appropriate."
2. . Wikivoyage:How to use dynamic maps says, "nnn is the width and height in pixels that the embedded map will display at on the page. 470px wide is a good width to ensure that it does not overflow the righthand gutter on small, standard width screen resolutions of 800px. Optional - default is 420px for both height and width."

How to use dynamic maps seems to imply that users are free to use a width other than the default 420px, although it goes nowhere near 600px square maps or centering maps. I'm not trying to stir the pot further here (despite what it looks!), but this would muddy (to me) what the status quo is with respect to map size. At the very least, lets apply whatever final policy wording is determined below to both pages so our policies are consistent. -Shaundd (talk) 03:57, 24 June 2014 (UTC)Reply

The advice on Wikivoyage:Dynamic maps Expedition#Stage 3: Broader deployment was added after a lengthy discussion, while the second item in the above list appears to have been added unilaterally without discussion and should thus be changed to match the "Dynamic maps Expedition" advice. -- Ryan • (talk) • 04:47, 24 June 2014 (UTC)Reply

Ok, I've updated Wikivoyage:How to use dynamic maps to remove the reference to 470px being a good width. I also changed the text regarding default zoom so it says it is 14, which seems to be the current default. -Shaundd (talk) 05:39, 24 June 2014 (UTC)Reply

Thanks Shaundd, although we should be careful before changing wording yet as there appears to be great vibrancy to this discussion. Andrewssi2 (talk) 05:47, 24 June 2014 (UTC)Reply

I agree, and I don't usually change things that quickly. In this case though, one item was developed by consensus and the other was added later without discussion -- well meaning, I'm sure, to help explain how to use the dynamic maps -- but it was at odds with the existing policy. So for clarity, I think it's best to align them based on the current standard and then change both pages as needed when this discussion is finished. -Shaundd (talk) 06:05, 24 June 2014 (UTC)Reply

I do agree what you did, Shaundd, was the only right thing to do - I wonder how these offhand notes came about. I don't agree with having to "update both" though - we are mixing an Expedition, which is a collective workspace for interested Wikivoyagers, with a guideline/policy page. The problem is that many people are unaware that this is the policy page (and we only need to make changes to it). We might use some kind of a signpost to all existing policies (or perhaps there is one that I am not aware of - it needs to be promoted better then), and announce major policy discussions and changes in the Pub (rather than use it to discuss policies and whatnot as we often carelessly did in the past). PrinceGloria (talk) 06:10, 24 June 2014 (UTC)Reply

It's unfortunate that one or two users seem to want to turn this into a policy page and amend it in such a way as to impose new restrictions on Wikivoyage editors. Most of what we have about dynamic maps is documentation, and even that is a moving target as the ability to display these maps is a capability still very much under development. My concern is that someone will slip an arbitrary restriction into these today ("Dynamic maps may not be used at the region level") based on the current software limits on ability to draw different-coloured regions on a dynamic map, pass it off as a "clarification" instead of new policy so that it slips under the radar, then use it a week, a month, a year or however long from now once a subsequent version of the dynamic map software gets the ability to display multiple coloured regions. Wikivoyage policy is a very inflexible beast (as evidenced by the ongoing deadlock on links to other Wikimedia projects, where we're still hamstrung by policies imported from WT) and it's much easier to create these new, pointless restrictions than to get rid of them once this instruction creep is doing more harm than good. At least Wikipedia marks its project pages with huge templates to indicate what is policy, what is a guideline, what is merely an essay, one person's opinion or a sarcastic joke, and what is Help: documentation. Here, any page can be twisted and used as a policy stick to beat future editors, which is unfortunate and likely unintended. K7L (talk) 14:54, 24 June 2014 (UTC)Reply

Once again, there is nothing at all here that involves imposing new restrictions — users on WV have never been free to oversize and center images at whim. The rest of your rant is just rather off-topic generalized complaining that doesn't really belong in this discussion. I've mentioned to you elsewhere, your opinion may be "I don't like rules therefore I oppose this rule", but that does not offer any constructive argument that others can engage with. Texugo (talk) 15:07, 24 June 2014 (UTC)Reply

Au contraire, you have tried to take a documentation page, titled "Project: How to use...", turn it into a policy page and amend it to impose additional restrictions for which there is no clear consensus. The onus is on you to justify this proposal to the rest of us. K7L (talk) 15:13, 24 June 2014 (UTC)Reply

(edit conflict) I partially disagree with Texugo - guidelines on images are just guidelines and should be ignored if there is a good reason for doing so (and if that reason is stated) - but I think it's still think it's very important to state what our best practices are and apply them in the majority of cases. There have been a few comments that this discussion is an effort to "impose new restrictions" or that we would revert edits of non-default sized maps as being "against the law". Hopefully others are not arguing for such rigidity, but are instead just trying to agree on (and put into writing) some best practices for dynamic maps so that we don't have to have a massive discussion (like this one) when someone simply thinks a bigger or smaller map "looks nice". If there is a reason for using a non-default size then state it and do so, but if it's simply a matter of someone preferring bigger maps or center-aligned maps in all cases, let's come to an agreement on what the common case should be and put it into writing. That process of documenting best practices is very common and even vital on any wiki that has a large community. If I'm misunderstanding the concerns being raised about this particular discussion please clarify, but K7L's concerns about general inflexibility of the community notwithstanding, I don't think that agreeing on some standards is a bad thing. -- Ryan • (talk) • 15:23, 24 June 2014 (UTC)Reply

The restrictions were already there for various elements such as images and static maps. We are taking the 'how to use' page to make a more flexible policy with regards to dynamic maps. It is overdue.

Rather than making charged statements such as 'the onus!' (this is collaboration after all), perhaps you can can contribute as to what you would like to see in terms of policy? Andrewssi2 (talk) 15:26, 24 June 2014 (UTC)Reply

I'm not sure that we really disagree much, Ryan. I am certainly not arguing for "no exceptions ever". I am only concerned with having the guidance give us a clear bias in favor of an uninterrupted layout in cases that boil down to no more than someone's simple preference for big honking maps, because in the absence of extenuating factors of shape, etc., no amount of discussion in the world can negotiate a compromise between "centered and huge 'cause I like it that way" and "right-aligned and undominating, as an element of consistency and flow". With static maps so far, we have apparently found the exceptional need to center in exactly 2 cases out of our 26,000 articles — why would new dynamic maps which actually increase viewing possibilities at smaller sizes suddenly result in a situation where we make such exceptions for every third city?

As to K7L's insistence that he gets his way if no consensus is established, I have to reiterate that he is flat wrong. If we have never allowed images to be oversized and centered at whim, then it is no more than a bald attempt to win on a technicality, and quite a stretch at that, for him to claim the right to oversize and center these maps whenever he sees fit simply because policy does not explicitly spell out that the same approach we've taken with other maps, images, and content elements applies to dynamic maps as well. Texugo (talk) 15:43, 24 June 2014 (UTC)Reply

Reading through the discussion, I think these adapted guidelines are agreeable to most people? If you would like to make changes, please copy and paste below, making your edits to the origional text clear.

Suggested adaption for dynamic map guidelines: (Bold are added words by me, strikethrough are removed words by me)

• 1. Only add dynamic maps to articles at the lowest level of the article hierarchy (city or district).
  2. Dynamic maps should usually be added to the top of the "Get around" section. If a map is added to a different location be sure to explain the reasoning in an edit comment or on the article's talk page.
  3. Do not add a dynamic map when a Wikivoyage-style static map is already present.
  4. Use the default map size (width/height/allignment) unless there is a specific reason for using a different size such as a unique shape of the city or district, in which case the reasoning should be explained in an edit comment or on the article's talk page.
  5. Zoom should be modified as appropriate and show the majority of POI's in the article.
  6. Itineraries may have flexibility to use appropriate dimensions as required to display the subject area. Center allignment is also allowed for large maps in this category.
  7. Do not add more than one dynamic map without discussion on the article talk page.

Andrewssi2 (talk) 00:19, 24 June 2014 (UTC)Reply

BTW, please leave point 3 "Do not add a dynamic map when a Wikivoyage-style static map is already present." alone. This is not the place to discuss that point. Andrewssi2 (talk) 00:23, 24 June 2014 (UTC)Reply

I support these suggested clarifications. Texugo (talk) 02:48, 24 June 2014 (UTC)Reply

I really don't know how #3 came about, I believe our previous discussions actually pointed towards something totally opposite, and I don't know why we shouldn't discuss it. I also don't understand why we should have such a verbose and restrictive policy - are we writing the tax code or guidelines for people enjoying themselves while contributing to the greatest travel guide that evolves with their contributions? Finally, I don't understand why itineraries should be treated any differently than other articles with regards to what is "allowed". PrinceGloria (talk) 05:14, 24 June 2014 (UTC)Reply

Point 3 is part of existing policy and nothing to do with map dimensions so it won't be discussed. Your distaste for not being able to apply whatever feels best for your own personal preference has been noted already; however feel free to contribute constructively. Do you wish to extend the standard size perhaps? Andrewssi2 (talk) 05:44, 24 June 2014 (UTC)Reply

I also don't understand why itineraries are being called out or odd-shaped city maps can't be centered. What about:

2. Use the default map size (width/height/allignment) unless there is a specific reason for using a different size such as a unique shape of the city, district or itinerary, in which case the reasoning should be explained in an edit comment or on the article's talk page.

4. Center alignments are allowed for maps that have a width of 700px or more. (note - I just pulled that 700px out of a hat as a suggestion. I do think a hard number will help minimize future discussions rather than saying a "large" map).

-Shaundd (talk) 05:56, 24 June 2014 (UTC)Reply

I am quite surprised to see point 3 here as I remember as discussing removing this kind of rule, but I guess I have to find this discussion. This is the problem with overpolicing everything - we now have so many guidelines and policies that one needs a WikiLawyer to keep track of what has been formally decided and what didn't, and discussions may result in a reasonable consensus which however does not get recorded in all appropriate places and then somebody cries "but it's a against the law!" and we're back to the drawing board.

I do not want a standard size. I want users interested in a given article to be able to determine the best size, layout and placement of the dynamic map in the talk page of a given article, not a prescribed solution that simply won't work. Sure this will lead to me being the only one determining that if I am the only editor of an article, and this is the case with many of us and many articles for now, given the number of contributors. But then this may spark the interest of somebody else appalled by the "white chasms" in the article, then we discuss, then the other user gets to know the destination and gets involved in the article and the article benefits as a whole. Applying blanket policies like "let's disallow XYZ" or "let's format this like that" results in a string of mechanical (manually performed still) edits to a number of articles without any deeper involvement of the user in this article. Had we continued discussing this in the talk page wherever this originated (I have forgotten where it was), I am sure the article would have benefitted greatly. Now we have a featured-guide-size amount of hot air in a policy/guideline talk page many users are even unaware of. I am not sure we are improving Wikivoyage in any way here. PrinceGloria (talk) 06:00, 24 June 2014 (UTC)Reply

PS. Shaun - I mostly agree with you (though still don't agree with being so specific and restrictive in general), but I would go with 500 px as the limit for right alignment given my experience of viewing Wikivoyage on smaller-res screens. Otherwise, viewing Wikivoyage on 800x600 with text flowing left to the map will be a disaster with maps 500, 550, 600 and such wide.

I recall the discussion around Point 3. I believe the static map people did not want to lose the primacy of their format and therefore this was the compromise that apparently still stands. Andrewssi2 (talk) 06:17, 24 June 2014 (UTC)Reply

Shaundd , the point is that a city or district never have a reason to be so large as to need to be centered. Itenaries can span continents hence the call out. Andrewssi2 (talk) 06:15, 24 June 2014 (UTC)Reply

You will need to tell that to cities and districts then, Andrew. I am not sure if they would be open to your policy proposal that tells them to contract and fit into 420x420. Frankly, I believe we are fighting a losing game here - we seem to need to adjust to them, not tell them to adjust to us. PrinceGloria (talk) 06:21, 24 June 2014 (UTC)Reply

Zoom function. That is all. Andrewssi2 (talk) 07:17, 24 June 2014 (UTC)Reply

Zoom function does not work in print. It also will not show the entire district that doesn't fit in 420x420 - it will only show you a fragment. Finally, the most important feature of the dynamic map is not that you can zoom it (you can do it with a static map as well), but that POIs will appear on the map dynamically, as they are added / edited by a user requiring just some short instruction. This is why they were developed and why I prefer them over static maps, not because you can move and zoom - you can move and zoom Google Maps as well, but they don't include references to our guides. A map in the article should be informative and clear, and not fit 420x420 just because. If we tell people to zoom and scroll, we may just as well only include a link, not a clumsy problematic MapFrame. PrinceGloria (talk) 07:40, 24 June 2014 (UTC)Reply

Really sorry to break this to you, but dynamic maps were never designed for printing (Hence the magic interactive elements such as panning, zooming and clicking). As previously noted you can't even cheat all the yellow pluses by ever increasing the map size. It will always be a bad solution. In the meantime you have broken the flow for everyone else for this misguided idea. Andrewssi2 (talk) 08:02, 24 June 2014 (UTC)Reply

If dynamic maps are not designed for printing, doesn't using them conflict with this site's commitment to printability? Ikan Kekek (talk) 13:51, 24 June 2014 (UTC)Reply

Just because they are not as useful when printed as-is within the article (even at the larger sizes proposed) as they are when printed separately at a larger size does not mean anything much in that regard. The same is true of the static maps anyway. We may want to have a good, usable print version, but our commitment is not necessarily to always have an unadjusted direct print-out of the on-line version. Texugo (talk) 14:19, 24 June 2014 (UTC)Reply

Yes, it's often a problem with static maps, too, and I have a problem with that. I've greatly enlarged a lot of static maps for exactly that reason. Ikan Kekek (talk) 14:25, 24 June 2014 (UTC)Reply

It is true, Dynamic Maps have never actually fitted the goal of having a usable print version. Dynamic Maps are interactive elements and as such will never be ideal for printing because interactive elements (to state the obvious) do not print on paper.

I am a strong supporter of dynamic maps, and mostly for the fact that it lowers the barrier to contributing to WV (i.e. you don't need cartography skills). We do need to accept however that blowing a map up across a large desktop screen is unfortunately just 'lipstick on a pig', and at the cost of the article's readability. Andrewssi2 (talk) 14:57, 24 June 2014 (UTC)Reply

Any other comments on my proposed policy change at the beginning of this section would be appreciated. Andrewssi2 (talk) 14:57, 24 June 2014 (UTC)Reply

Earlier I suggested that when printed, the map as a full screen should print as a separate appendix at the end of the guide, at the size of a full page. If you take a random article, click at Printable version in the sidebar and compare them, they are already slightly different (absence of banner, no sidebar, little larger font, URLs spelled out etc.). Would it really be that hard to add a map as based on the dynamic map as specified in the Geo parameter as an additional page? That would solve the problems for users who wish to have their maps printed.

The Mapframe maps are chiefly there to get an overview of the destination, right? And as many have already said, you can zoom and move around. If the map that is embedded in the guide would be intended for general navigation it would both have to cover the whole area of the city stretching maybe 5km in each direction with an appropriate zoom level to distinguish the four sights, main department store, four restaurants, five bars and two hotels that are located around the same three blocks in the very heart of the city - as is very often the case. To really achieve that, the map would have to be absolutely monstrous, so why even try? I don't think it's so hard for readers to understand how to zoom and scroll, online maps have been around for a while.

For the most part I support the revised version of the policy. But, I would suggest that limits to the maps are given as maximum width and maximum height instead of standard size, so that they could be horizontally or vertically narrower if needed. ϒpsilon (talk) 15:33, 24 June 2014 (UTC)Reply

Regardless of whether the map is printed where it is placed in the text or as a separate appendix, it needs to be formatted properly. Otherwise, we will be printing autoformatted rubbish. 420x420 does not cover all cases. Some maps will be OK at 500x300 at zoom 14. Others at 300x600 at zoom 13. And yet others will only make sense at 800x500 at zoom 15. There is no blanket

I also believe that the fact that the print version looks different from the online version is the fallacy, not feature, of PediaPress. The best solution for easily editable content is always WYSIWYG. I will certainly be addressing this with the PediaPress regarding out banners and such, but only once I establish whether this isn't our own work, i.e. using "noprint" where we shouldn't.

I must also state my "preference for big honking maps" for the very reason. I believe we should provide a good overview of the place, not a link to the map. My print guides, at least the good ones I bought, have had good, carefully edited maps that showed just the area I needed to understand. They did not simply contain the instruction to buy another map. And if they had a separate fold-out map, I considered them impractical - I want my map right there in the guide and formatted the way it allows me to use the guide to get an idea of the place.

To make it clear - the above is regardless of print issues. I want a well-formatted map in a Wikivoyage guide I read that gives me a good overview of the place. Later on, I will zoom in and out, scroll and whatnot. But first, I need a good picture of the place. This is easier in even more than 1/3 of the cases as invoked above with using large, centered maps than 420x420 right-aligned ones.

Having said which, if the policy would only state maximum width and height, rather than prescribe a size (which is prescribed in MapFrame's standard settings anyway), I am a happy camper. I believe this is best decided case-by-case in talk pages. In some articles, right-alignment of a small map will work. In others, it won't. That's what we've got the talk pages for - to discuss. The discussions are sometimes heated, but my experience is that we more often come to constructive conclusions in talk pages, where all what we discuss is creating the best guide for a destination we care for, than in policy pages and such, where we discuss theoretically.

Kind regards, PrinceGloria (talk) 17:38, 24 June 2014 (UTC)Reply

The "good overview of the place" is right there. The answer, as you've been told many times before, is very very simple: zoom. Others might equally consider a good overview to be a wider zoom level that more clearly shows the main thoroughfares, stripping away the extraneous sidestreets. Luckily zoom works great for them too. And it's is extraordinarily simple. This is not "later on I will zoom in and out" when I get enough energy. This is not even extricating a folded map glued into the back cover of your print guide. It's not hard. You're again just saying that your laziness to roll the mouse scroll over a notch to reach your preferred view outweighs every concern about the layout, flow, and usability of the rest of the article. Texugo (talk) 18:00, 24 June 2014 (UTC)Reply

(edit conflict) If I may say, the most comfortable solution would actually be something similar to Wikipedia's WikiMiniAtlas that would pop up when you click on the POI icon in a listing. As of now, when I read about something in a listing, I prefer to have the fullscreen map in another tab that I can access with a click rather than having to scroll back and forth to the small embedded map in the Get around section - which in practice is as separate from the See, Do etc. sections as any other separate map. ϒpsilon (talk) 18:12, 24 June 2014 (UTC)Reply

(edit conflict) It would be brilliant if you could not value my experience and preferences as inferior to yours, and also accuse me of laziness. This discussion is getting quite inappropriately personal.

We have discussed that zoomed out maps gets hard to make out when there is a lot of POIs in them (regardless of whether they are clustered or not - a mass of POIs simply covers the area. Sure we can zoom, but then we can't keep the entire area in the MapFrame window. I believe for most districts and cities it is possible to choose an area the map should cover by default and make a dynamic map out of it - just like people make static maps of cities. And I prefer this approach to a small window you have to zoom in in in order to see anything.

Back on topic of aesthetic preferences - which are naturally subjective. I see absolutely nothing wrong with a centered map, and I dislike paragraphs of text squashed by 420px wide or large maps. I find them hard to read and, if anything, this is what disturbs the flow of text and makes it hard to read for me, as this does not concern separate sections, but actually continually flowing paragraphs of text. Some of them have listings and such, and given that our guides are viewed on different screens, it is sometimes hard to predict which bits of text will be affected. I find this actually aesthetically undesirable and making our guides inferior to read. 200px standard sized (or are they 225px?) thumbnails pose such problems much more rarely, as it is rare that the screen is narrower than 600px - and if it is, it is usually a mobile device displaying a different version of the page. PrinceGloria (talk) 18:20, 24 June 2014 (UTC)Reply

PS. I quite like Ypsilon's idea, but I still believe we need an in-article map in a very prominent position. And this is still an idea, not sure if we can implement that quickly. We have to sort out the MapFrame and Dynamic Maps as they are.

Call it laziness, call it unwillingness, nothing personal was meant in pointing out that you seem to think avoiding that tiny finger movement to reach your preferred view is more important than any concern over layout or flow. And I'm not at all prioritizing my preferences over yours. I'm saying that your stated usability preferences can easily be accommodated by very simply using zoom and/or the full-screen map, without stomping a canyon across the middle of the article. The opposite case, that of doing things your way yet still being able to in any way accommodate a preference for upholding our traditional values of formatting, flow, and consistency, does not hold true by a long shot. Texugo (talk) 18:38, 24 June 2014 (UTC)Reply

You seem to have not understood the gist of what I am saying - I want a dynamic map that works like a static map, i.e. there is a picture that is properly formatted for the area in question and depicts it well. This is not because I fear for anybody's fingers that may get tired, it is because zooming in and out and scrolling in a 420x420 finger is not the same as being presented with a picture of the city or district. You can eventually make out the city by exploring the dynamic map by zooming it in and out and scrolling, but this is not the same as being given a clear overview. Again, please accept this as a personal preference which I feel about very strongly - you may not require this, but I find it paramount for a guide to be useful.

And before you cry foul that this is not a dynamic map - to me, the "dynamic" in the dynamic map is about the long term, i.e. that the map evolves with the guide, new POIs are automatically displayed once coordinates are given, the ones modified or removed are also rendered accordingly, and the map tiles are maintained centrally regardless of the state of the article. The fact that the map can be moved, zoomed etc. is only a nice, and obvious, side benefit to the maps being dynamic. The clou of the dynamic maps is the fact that they are automatically updated and easy to modify without specialist knowledge and with minimal effort, which is great for a collaborative project like ours. So this is why I prefer dynamic maps over static maps, even if I call for them to be used to display a ready-to-use static picture in our guides. PrinceGloria (talk) 21:13, 24 June 2014 (UTC)Reply

I'm not satisfied with the wording changes proposed above. First, why are we scrubbing the option to explain yourself in an edit summary instead of on the talk page? This wasn't even under discussion. Second, itinerary maps are not the only place we need to allow center alignment. I'll refer back to the example I linked above at Wendover; the town is arranged almost entirely on a single eastbound/westbound street. The POI field is more than 2½ times as wide as it is tall, and thus, if it were squeezed into a right-aligned map at a lower zoom level, would leave big empty patches in the upper and lower thirds of the map.

Here is my specific proposal for a wording change:

• Only add dynamic maps to articles at the lowest level lower levels of the article hierarchy: cities, districts, and regions that are not further divided into additional regions. Dynamic maps are not currently usable on articles with sub-regions due to technical limitations.
• Do not add a dynamic map when a Wikivoyage-style static map is already present.
• If the default size does not frame the destination well, try to limit any height or width increases to the minimum amount necessary. Do not set the width above 550px (to preserve the readability of the text to the left of the map on smaller screen resolutions).
  • If a destination is significantly longer east-to-west than it is north-to-south, consider using a center-aligned horizontal map with a width of about 700-800 pixels instead. These maps should have the height reduced as much as possible to limit the break in the article text.
• Use the default map size (width/height) unless there is a specific reason for using a different size, in which case the reasoning should be explained in an edit comment or on the article's talk page. Zoom should be modified as appropriate and show the majority of POI's in the article.
• Dynamic maps should usually be added to the top of the "Get around" section. If a map is added to a different location be sure to explain the reasoning in an edit comment or on the article's talk page. For maps that must be center-aligned, it may make more sense to place them at the bottom of the "Get around" section or, if the section is very long, after the first paragraph.
• Do not add more than one dynamic map without discussion on the article talk page.

That first change should be a no-brainer at this point. Check any sub-region of Nevada to see how well dynamic maps now work for lowest-level region articles. The last guideline about not using two dynamic maps on the same article can be deleted because it isn't even possible to add a second map.
Thatotherperson^talkcontribs 01:48, 25 June 2014 (UTC)Reply

There are some good points here, although the problem is that it appears to still allow for center aligned maps with no clear criteria. I guess the wording could be worked on?

I sort of see your point in Nevada about 'lower' levels rather than lowest, but it won't be obvious from that wording. I'll give it a go.

I didn't think scrubbing the 'edit comment' would be controversial. An edit comment can't be discussed, and if someone wants to change the map later they will have no obvious reference that this was done or even why.

I just tried Wendover at a preview at 550 pixels (your suggestion) and it is perfectly usable. We just need to be clear that a rectangle shaped area is not a carte blanche for dimension sizes Andrewssi2 (talk) 02:53, 25 June 2014 (UTC)Reply

I had another go integrating some point (but not everything). I removed required for noting changes in eigher edit comment or talk page.

• 1. Only add dynamic maps to articles at the lowest level of the article hierarchy: cities, districts, and regions that are not further divided into additional regions. Dynamic maps are permitted at a regional level in order to illustrate towns and settlements.
  2. Dynamic maps should usually be added to the top of the "Get around" section. If a map is added to a different location be sure to explain the reasoning in an edit comment or on the article's talk page.
  3. Do not add a dynamic map when a Wikivoyage-style static map is already present.
  4. Use the default map size (width/height/allignment) unless there is a specific reason for using a different size such as a unique shape of the city, district or region. If dimension changes are needed then try to limit any height or width increases to the minimum amount necessary. Do not set the width or height above 550px unless an exception is required by the area's exceptionally wide or high geography.
  5. Zoom should be modified as appropriate and show the majority of POI's in the article.
  6. Itineraries, Travel Topic and Region articles may have flexibility to use appropriate dimensions as required to display the subject area. Center allignment is also allowed for large maps in these categories.
  7. Do not add more than one dynamic map without discussion on the article talk page.

I like the direction we're going here. However, I still don't like the idea of using article type – itinerary, travel topic, region – as a criteria for whether or not a map can be elongated and center-aligned. Maybe we could establish a minimum width-to-height ratio (2:1?) or maximum overall height (400px? 380px?) for horizontal maps to ensure that center-alignment only gets used for appropriately-shaped places. (I'm not sure what you're seeing at Wendover, but if I set the width at 550 and keep the zoom level at 14 it cuts off portions of the central tourist area, and if I set the width at 550 with a zoom level of 13 it leaves about 70-80% of the map as empty gray space.) Also, I notice you deleted the stuff about center-aligned maps being placed somewhere other than the top of the "Get around" section. Any particular reason? I think it looks a lot more awkward if the break in the article text is between a section header and the opening line of that section.
Thatotherperson^talkcontribs 05:38, 25 June 2014 (UTC)Reply

In terms of article type (and please anyone correct me if I am wrong here) I had the understanding that there was generally more freedom when working on specialized travel topics. For example, Paris and its districts are main destination articles and should generally adhere to a Wikivoyage form (not a ridged structure, but a general form that can be customized but still be familiar to readers), whereas a travel topic such as Eating and drinking in Paris is more experimental in nature, and the contributor has more flexibility to execute their creative vision.

I removed the reference to centered maps in the other sections only in the sense that Ryan's proposed functionality below would make it moot. (i.e. both types of map could co-exist in the 'Ged Around' section) Andrewssi2 (talk) 01:01, 26 June 2014 (UTC)Reply

Re #2, if we're going to include dynamic region maps in the policy, we should note they are typically placed in the Cities section (assuming they're being placed there because that's where the corresponding icons are). How does this sound:

2. Dynamic maps of cities, districts or parks should usually be added to the top of the "Get around" section. Dynamic maps of regions should usually be added to the top of the "Cities" section.

-Shaundd (talk) 05:11, 26 June 2014 (UTC)Reply

Good point about specifically mentioning the different placement for regional maps. Andrew, I don't see how the Javascript feature being added makes it any less important to put center-aligned maps lower in the "Get around" section. Expandable maps won't get rid of the break in the article text – in fact, they will make it larger, increasing the benefit we would see from moving center-aligned maps away from the section header.
Thatotherperson^talkcontribs 06:42, 27 June 2014 (UTC)Reply

If I'm understanding correctly, we all agree that there are times when the geography of a location makes the default size problematic, and in such cases the default sizes can be changed to fit the geography. The main point of disagreement is about preferences for larger maps that do not need any manipulation but break up the article flow, vs. smaller maps that do not break the article flow but may need some user manipulation. What about the following possible compromise (subject to verification as to whether it is technically feasible):

1. We adopt the #Policy wording change as proposed by Andrewssi2 for the default case.
2. We add Javascript that provides an option on maps to dynamically expand the map to full article width for those who want it. Similar to the current TOC collapsing logic, once you have expanded a map a cookie will be set on your browser to remember your preference, and future articles will load with the map expanded. Conversely, if you then collapse a map the cookie will be updated so that you then see maps displaying at the default size in the future. Since this functionality is implemented using a cookie, it won't matter whether you are logged-in or not, the preference will be remembered.

Would that address most concerns? Maps can then be large and immediately readable for those who want it, and can be out of the way but available for manipulation for those who would prefer such a solution. If there is interest in this idea I can try to put together some code that would allow the capability. Caveat: I am relatively confident that this functionality can be implemented, but sometimes resizing iframes is problematic so there is a chance it won't work. -- Ryan • (talk) • 21:35, 24 June 2014 (UTC)Reply

That sounds quite cool and helpful if it's possible (I like larger maps but not the white space centered maps create). A couple of questions off the top of my head are (1) would it expand proportionately or just width-wise (i.e., height remains the same), and (2) would the expanded map use the same zoom setting as the small map? -Shaundd (talk) 21:49, 24 June 2014 (UTC)Reply

I'm not sure if the zoom level can be modified via Javascript, but will look into it. As to width/height, I was assuming the aspect ratio of the map should stay the same, which would mean expand width AND height proportionally. -- Ryan • (talk) • 22:09, 24 June 2014 (UTC)Reply

So it sounds like a default square map would likely end up being vertically larger than the screen on a wide-screen device, less so on an old square-ish monitor and not a problem in portrait mode on a mobile/tablet. I wonder if it would be better to expand it width-wise only, or apply a 16:9 ratio (if that's even possible). -Shaundd (talk) 22:29, 24 June 2014 (UTC)Reply

I get nervous whenever we have the potential for registered users to see the article differently from non-registered users (or from certain other registered users). It makes it hard to ensure the page is aesthetically pleasing. Powers ^(talk) 00:03, 25 June 2014 (UTC)Reply

It sounds like a good compomise that recognizes that different people want different things from the desktop view.

As an additional bonus, could this be the default setting for the printable mode, even for non-registered users? Andrewssi2 (talk) 00:10, 25 June 2014 (UTC)Reply

Powers - I wasn't clear enough above. This change would be cookie-based and thus would be no different for an anonymous or registered user, just like the current "collapsed/expanded" preference for the table of contents. -- Ryan • (talk) • 01:29, 25 June 2014 (UTC)Reply

Our ToCs are in our pagebanners now, so I'm not sure what you mean. Anyway, you were perfectly clear. The problem is that with the option to expand the map we have no way of knowing whether any particular user has done so or not. Powers ^(talk) 12:04, 25 June 2014 (UTC)Reply

See Culver City#Get around for an example of the expand/collapse functionality - click on the link in the map caption. Apologies for enabling this on a mainspace article, but POIs didn't work when I tried using a userspace page. Per the suggestion above the height is limited to a 16:9 aspect ratio. I haven't yet added the functionality to persist the expanded/collapsed preference but will get to that if there is interest in implementing this functionality. -- Ryan • (talk) • 05:55, 25 June 2014 (UTC)Reply

When expanded, it's very hard to use the mouse wheel to scroll the article (versus the map). Powers ^(talk) 12:04, 25 June 2014 (UTC)Reply

It's a bit more difficult to scroll because the map covers much of the screen, but it's not hard. The same principle applies on other websites with these kind of windows, Yahoo's World Cup live game commentary is a current example, so hopefully positioning the mouse on different parts of the screen to scroll the various elements won't be new to most users. I think it's an acceptable trade-off if it helps address the concerns discussed above.

Overall, I really like it. It worked smoothly on my desktop and laptop (Firefox and Chrome). My cell phone (Android) was touch and go. The first couple of times I tried it, it expanded the frame but not the map. But when I repeated it, it worked fine in both Opera and Chrome. I was working off a weak wifi signal so that may also explain why the map was slow to expand. -Shaundd (talk) 21:32, 25 June 2014 (UTC)Reply

Update - I've tested it on IE 11 and Safari now, and it worked fine. The only thing I've found is that sometimes the map doesn't always fill the expanded frame. I can't pin it down exactly but it seems to relate to how fast the page loads and how quickly I expand the map. If I wait a few seconds (which is probably the more normal usage), the map works fine. -Shaundd (talk) 04:33, 26 June 2014 (UTC)Reply

I'd say it is very difficult to scroll, since you basically need to place your cursor in the grey Wikivoyage left hand menu bar to avoid the 'pointer catch and zoom' effect.

If the people in the 'large map' camp are fine with that tradeoff then this is a good functional proposal. Andrewssi2 (talk) 01:06, 26 June 2014 (UTC)Reply

Well, if there's one thing that can be said for this discussion, it seems clear that one person's "difficult" can be another person's "very acceptable". I can't speak for others (hopefully they'll chime in), but I'm quite happy with the tradeoff for a larger map. Thanks for the offer below for added functionality if required. -Shaundd (talk) 04:33, 26 June 2014 (UTC)Reply

There seems to be lukewarm (at best) support for the dynamically expanding/contracting map proposal so far. Is this option still something worth pursuing? It seems to me like it might be a nice enhancement for those who prefer larger maps by default, and for those who don't there isn't any impact beyond a link in the map caption, but I don't want to spend too much time finishing it if it isn't something people would want to see put into use. -- Ryan • (talk) • 16:13, 28 June 2014 (UTC)Reply

RL caught up with me and I was unable to participate in this heated discussion as much as before, but I just wanted to indicate that I do support this proposal and find it worth pursuing if you have the capacity to do so. If I may, I would suggest adding zoom, latlong and width/height parametres for both the collapsed and expanded versions to make sure what is displayed is useful and meaningful, and not just a random slice of the map. I also support the notion voiced above that the print version should contain the expanded map by default. PrinceGloria (talk) 17:50, 28 June 2014 (UTC)Reply

I have similarly been unable to participate in the conversation as before, because I was unexpectedly hospitalized on suspicions of a very serious blood problem. For four days, I was facing a strong likelihood that I would be diagnosed with a life-threatening illness, and was told that that even on the offchance that I was not, I was almost certainly going to have to cancel my 2-week Europe trip and remain in the hospital for some time. Most thankfully, this morning, a completely benign diagnosis was reached, and I was quickly cleared to go have some beer while watching the Brazil game, cleared to travel tomorrow, and sent on my way. Sooo, before I finish my quite interrupted travel preparations and disappear from WV for another couple of weeks, I would just like to take this opportunity to thank Ryan for this suggested compromise and to finally agree 100% with all the points PrinceGloria expressed just above. This sounds like a great idea. I may pop in from time to time during my trip to see how this discussion is going, if I have the time. Texugo (talk) 19:03, 28 June 2014 (UTC)Reply

I take it your are 100% fine Texugo ? If I understood that correctly then great to hear!

I support the change proposed by Ryan Andrewssi2 (talk) 01:43, 29 June 2014 (UTC)Reply

Nothing a little over-the-counter medicine and a little time won't fix. Thanks! Texugo (talk) 02:31, 29 June 2014 (UTC)Reply

The Javascript feature is nice, but you may want to run another test first, this time on a map that has all three links in the caption instead of just one as Culver City had. The only examples I know of right now are Virgin Gorda and Singapore/Chinatown. Once we have a plan for what the map caption will look like with all four links, I'm fine with rolling out expandable maps site-wide.
Thatotherperson^talkcontribs 02:24, 29 June 2014 (UTC)Reply

Thanks for the responses, it sounds like there is enough interest to continue this work so I'll try to get the preference for collapsed/expanded set in a cookie ASAP. If there are any other maps that have edge cases like what Thatotherperson mentioned let me know so I can make sure the code works with them. As to modifying the zoom level or other parameters when expanding, I'll have to investigate whether or not that is possible - I haven't looked closely at how it is implemented currently. -- Ryan • (talk) • 03:34, 29 June 2014 (UTC)Reply

Can we talk a little about the expanded size? On my screen when expanded to full width it was more than a screen tall, really dominating my entire browser window. Is there any way to mitigate that? (It also might help with the scrolling issue.) Powers ^(talk) 17:33, 29 June 2014 (UTC)Reply

Currently the code is set up to expand the map to 100% of the available width. It had been suggested above to allow a maximum width:height ratio of 16:9, so in some cases the height will be reduced to fit within that ratio (so if the original map is 400x400, the expanded map might be 800x450). Would it make sense to also set an absolute maximum width of around 1000px? Is there another number that would work better, or another solution that might be preferred? -- Ryan • (talk) • 19:20, 29 June 2014 (UTC)Reply