UESPWiki:Archive/CP Maps in place articles

Maps in place articles

Discussion continued from 

The issue is that map images are too small to be useful on the place articles, and they are usually given random sizes so the whole thing looks like a mess.

Ideally you would want to be able to see the map and the description (e.g. boss at location marked H, quest item at location G etc.) at the same time, instead of constantly switching between the map file and the place article. So what I propose is to use much larger images in the articles themselves.

You can see an example here (a copy of ). The images are enlarged to twice the thumbnail size selected in your preferences. This isn't too large with the default thumbnail size (the images in the Dunroot Burrow article are about the same size), so I'd prefer to make them even larger, but then they become a bit too large when you select a larger thumbnail size. An alternative is to use a fixed size. 

Also, copy this css code into your monobook.css then go here and tell me what you think about those. The map key will appear when you hover the map or the label in the last case. --   / talk'' 14:06, 1 February 2010 (UTC)

: I definitely like the popup key idea. Having the key within each map works well. Ideally, I'd have it outside the image rather than overlaying it, but unless there's something clever that can be hacked with negative margins, I can see how that's unlikely.

: My first reaction to the larger maps was roughly "Gosh! Those are very large!" and I was far from keen. I run with thumbnails at 300px so the maps on that page are big. The map for zone 1 doesn't even fit vertically on my screen. After I played around with several different maps on several different pages, though... I think I've grown to like them that size. It's a bit of a shock at first, but it certainly makes them easier to read. There are minor problems with wide maps (like this) and tall ones (like this), but then the   param could be used to tweak as necessary. I suppose you could even use the   function to auto-tweak to some extent - something that's been at the back of my mind since we upgraded to 1.14.

: In summary, I like the change. The original fixed sizes weren't random, but I agree that they don't work so well. What worked with smaller monitors a couple of years ago definitely doesn't work with the resolution I use today. rpeh  18:35, 1 February 2010 (UTC)

::I know the fixed sizes are based on how large the zone is, but it looks random when you open up a page. I originally made the scale 2.5, but lowered it to 2.0 because they become really large at 300px (300*2.5 = 750, that's about half the content area even on a 1680 monitor). And I agree that a single number doesn't work with all the maps. I've added some more to my sandbox and tried to tweak the scale to suit them.
::Are the file sizes all relative to the zone sizes? If so we can use them to tweak the scale automatically, e.g. group them into categories based on size, with different scale parameters for each category.
::BTW, I read this discussion, and both Nephele and TheRealLurlock have a point, sometimes you don't want to load the large images, though I don't think bandwidth is that much of an issue, with the default thumbnail size, file sizes of the large images are roughly twice the size of normal thumbnails, but that's still less than 50kB, with 300 px they approach 100kB. But if this prevents the user from loading the file description page, because they can see what they want on the page, then you also save some bandwidth there. And the larger images are very useful if you are printing the page. --   / talk 20:01, 1 February 2010 (UTC)

::: In most'' cases, the dimensions of the image should allow comparison of the zone sizes. I grabbed most of the maps and did them all (except possibly the first couple) at 1680x1050. Nephele's maps, though, were grabbed at 1024x768 so they will be on a different scale. In SI, Vesna and SerCenKing did a lot of the maps and I don't know what resolution they used. Yeah, we just like making life difficult for you ;-) rpeh  20:58, 1 February 2010 (UTC)

::::I think rpeh showed a good example on how the widths of the various maps can differ. I don't think we can circumvent using multiple scales for the map images. While 1:2 can be used for the large images, for some others it may not be enough. While making the map images for the Oblivion Worlds I used a 1:3 scale, mostly because maps like this tend to be very cluttered. 
::::Would it be a good idea to add the scale (e.g. "map scale 1:3.0") to all the map image descriptions on the articles? 
::::In seeking the balance between a readable article with enough space for text, and large enough map images to be readable, I tend to lean to the larger map images side. Sure you don't want an article with images that are too large, but usually people visit place pages to check what good loot can be found there, where the maps and details provide the best combination of info. 

::::Using negative numbers (for top and left) should allow you to position objects outside their parent objects. --Timenn-  14:59, 5 February 2010 (UTC)
Overlapping doesn't work because of this:
 

In . Also, I don't like this part either:

 
According to the comment: "Move headings to a lower z-index so their horizontal rules are behind floating images and tables". The horizontal lines of headings are supposed to stop before the image, so this workaround shouldn't be necessary. --   / talk'' 15:42, 5 February 2010 (UTC)

I've seen a similar discussion elsewhere. The basic dilemma seems to be page layout vs. instant details. How about we put the map thumbnails in a vertical sidebar? You would still need to click on them for the detailed view, but you wouldn't have to scroll down to get at them.

Also, there are opinions and guidelines in several places and some map issues remain unresolved. (like multi-level single-cell maps, water, levitation, bosses, connections etc) It might be a good idea to give map layout its own page and move all the info and discussion over there. And discussions that keep resurfacing could be resolved with a vote instead. (i don't know if there's a mechanism for this in the wiki) Marcel 22:13, 8 February 2010 (UTC)