Template talk:Coord

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Better icon?[edit]

Hi. The current globe icon (WMA button2b.png) looks kinda terrible (to me, on my screen); jagged and fuzzy due to bitmap scaling and transparency. How about using the SVG version (WMA button2b.svg) instead? And, frankly, I don't get the point of the downward-pointing arrow on the icon, so how about just using the source image (Erioll world 2.svg)? Or maybe get someone to design a stylized 2D globe/map icon in black and white for even better legibility (the 3D color globe image is beautiful at full size, but doesn't really scale well to really small sizes; a flat low-color one would). --Xover (talk) 17:22, 16 September 2016 (UTC)

The globe isn't added by this template, but a piece of Javascript, whose name escapes me. The globe didn't always have an arrow - it was added, I believe, to indicate that clicking the globe took you somewhere else (WikiMiniAtlas), and not to the same page that the coord link proper takes you. --Redrose64 (talk) 22:58, 16 September 2016 (UTC)
I… see. I never knew the icon would take you otherwhere than the link; it just looks like one of the MediaWiki external links or file media type icons (who are also decorations on an otherwise plain link). Having finally discovered the WikiMiniAtlas after you pointed it out, I understand why the arrow is there: the map appears as if it was in a drop-down menu, so the arrow is trying to indicate "hey, I'm a drop-down menu". That also explains why they use the semi-translucent (rather than the fully opaque) globe: they need the background to be lighter so that the down arrow shows up against it (i.e. this only works in MediWiki skins that have a white or very light page background color).
Oh well. Trying to track down the relevant script and finding the right place to give feedback about the UI and interaction design issues with this is a bit more effort than I'm prepared to put into it right now. Thanks for the explanation Redrose; at least now I know of the existence of the WikiMiniAtlas thingy. --Xover (talk) 05:29, 17 September 2016 (UTC)
@Xover: After some digging, I've found that the script is m:MediaWiki:Wikiminiatlas.js and it was created and maintained by Dschwen (talk · contribs) although the last four changes were by Krinkle (talk · contribs). --Redrose64 (talk) 21:14, 17 September 2016 (UTC)
@Xover: The globe was previously used without the downward arrow. I added the arrow as an indication of its function of openeing a dropdown after people complained that the globe alone does not look like it is a fucntional UI element. In my opinion the SVG version is a little too contrasty, but that is a matter of taste (and accessibility , I guess :-) ). --Dschwen 23:21, 28 September 2016 (UTC) Ugh, you already answered most of this yourself :-)

──────────────────────────────────────────────────────────────────────────────────────────────────── @Dschwen: Thanks for the explanation. However, I think you miss the mark when you point to "taste" and oh-by-the-way-also-accessability as the key issues. I would say that the key issue is one of usability, discoverability, and the interaction model.

The icon, when viewed in isolation, is not optimal because

  1. It tries to cram too much (visual) information (detail) into too small a size, making it impossible to discern more than a vaguely green blob rather than the globe that might give you some idea that it is related in some way to maps or cartography.
  2. The arrow overlay, which is also very hard to discern visually, does not really signal "dropdown" so much as possibly "download" or something like that.
  3. The totality of the icon does not signal that it is a UI widget or that it is in any way an interactive element; nothing about it suggests there is any reason to try to interact with it.
  4. Which in turn is exacerbated by being combined with the text link from coord because the learned association with such a pairing are the link decorations that indicate "external link" or "link to PDF file" and so forth.

Which latter issue overlaps with the problem with the totality of this feature (MiniWikiAtlas in combination with the coord link): there are two "interactive" elements for an article's coordinates, that are located close together but uses different UI widgets, and which behave in fundamentally different ways (indeed, are implemented entirely separately). The discoverability and usability problems of it is magnified by being combined with the other feature.

My suggestion for how to approach this is firstly to "pick one", and secondly to "design the hell out of it". That is, an article's coordinates should trigger one feature, and that feature should expend significant effort on being designed well for usability and visual acuity. A possible point of reference might be the the preview "cards" that can appear when you hover over an internal wikilink, which are, I think, turned off and on in user preferences as a "Gadget"; the link works either way, but when enabled the Gadget provides additional functionality (value) in the form of a preview of the link you're about to click. MiniWikiAtlas could appear when you hover over a coord link (or its icon) in a "card" like form, and provide UI widgets (i.e. "buttons") to either zoom to the full browser window (ala. the media viewer) or to open the Geohack service. Whether clicking the link (rather than hovering) should open WikiMiniAtlas or go to the Geohack service is a matter for debate (at least, I don't see that one or the other option is clearly the right one); but having two entirely separate features piggybacking on the same coordinate without integrating and coordinating them leads pretty much only to a poor user experience.

And finally, decorating the coordinate link with an icon is fine (bearing in mind the above), but the icon and the text should behave the same and the icon needs to be visually clear and clearly communicate to the user what it is. My suggestion would be to reduce level of detail (because it doesn't get through at small sizes and only serves to reduce understanding) typically by using an icon that is more stylized (less realistic) and flatter (the faux depth of 3D is detail that adds no value and decreases ease of understanding when viewed at small sizes). That is, something along the lines of these rather than the current one: Antu internet-amarok.svg (or in a pinch: Edge-firefox.svg FY1415EmailGlobe.png). Since both the icon and link (if both are shown rather than just one of them) behave identically, and trigger on hover rather than click, you no longer need an arrow symbol to indicate the dropdown, and the icon can be clearer. (BTW, despite the laudable goal of representing the global south that shaped these icons, I would recommend going for the silhouette of America for maximum recognisability as that's what users will be used to from other contexts; at these icon sizes, other concerns must take a back seat to legibility).

Anyways, that was about four paragraphs worth more brain cycles than I had planned to expend on this, so hopefully it'll be in some way useful when you (the collective "you") next sit down to redesign any of these aspects. Cheers, --Xover (talk) 10:00, 29 September 2016 (UTC)

Xover I really appreciate any effort that leads to an improved discoverability and usability of the WMA. So thanks for expending these brain cycles. Leasing my argument with taste was merely reflecting your first comment in this thread. I will certainly not stand in the way of a redesign. --Dschwen 11:58, 13 October 2016 (UTC)
I've generally been quite fond of the simpler de-wiki solution (flat OSM map, and corresponding OSM icon—verses the WMA grayscale rendering and weirdo-ratio-alien-persepctive on en-wiki). If an icon still isn't working, how about testing   [map▼]   to match the commonly-recognised footnote, citation, and inline-flagging style. —Sladen (talk) 00:45, 30 November 2016 (UTC)

Support for + sign[edit]

It could be worth modifying the template to support a leading plus (+) sign for the latitude and longitude values. At present only a leading minus sign (−) is supported. A plus sign would make the northern hemisphere and east latitudes explicit. For example:

{{coord|+44.112|−87.913}}

Currently, the above example yields:

44°06′43″N 87°54′47″W / +44.112°N 87.913°W / +44.112; -87.913

The plus sign in the rendered output is unnecessary and redundant and should be suppressed for consistency. Best wishes. RobbieIanMorrison (talk) 14:20, 11 December 2016 (UTC)

National grids[edit]

Is it acceptable to use the |notes= parameter to insert national grid references into the title line? In countries which have an established national grid system it is often shown on maps and is an easier way to define locations, whereas lat/long may not be shown on road atlases or hikers maps. I've tried using |notes=, {{gbmapping|TQ 74019 68065}} on St. Margaret's Church, Rochester as an example. The comma is needed to force a space between the lat/long and the word "grid". I think this mainly applies to the UK and to Eire, at least they appear to be the only countries with national grid templates listed in category "Coordinates templates". Martin of Sheffield (talk) 09:35, 7 January 2017 (UTC)

Maybe, we could suggest that the Coord template is modified so the gbmapping could be given as a single input parameter, instead of lat long, and it would generate the lat long, and produce the render you desire. For instance {{Coord|gbmapping="TQ 74019 68065"|display=title}} would automatically produce. Coordinates: 51°23′06″N 0°29′58″E, grid reference TQ 74019 68065.
There is an interesting point here related to editor recruitment and retention: templates should assist the newbie in entering fact into WP, not present them with another arcane barrier that hinders them. The sort of reference books a group of U3A members will use reference a new article, will use the OSGrid- what we want the template to do, is to convert information in a format they are familiar with, into the format needed to produce the encyclopedia we are familiar with. In the case of articles that are likely to be of interest to a specialist group (Watermill hoppers for example), we need a simple format that displays the information they would find in an equivalent printed text.
We need to consider output manipulation as it Convert output parameters with
order=flip
, and other options. Just a few thoughts for others to play with. ClemRutter (talk) 11:41, 7 January 2017 (UTC)
Absent a community consensus one way or the other, this would appear to be a matter of personal opinion, so the word "acceptable" doesn't apply. I wouldn't do it, for the following reasons:
(1) The grid ref is already in the infobox as a separate |osgridref= parameter, introducing a data redundancy. Data redundancy is generally something to be avoided.
(2) Creates an added degree of clutter, both in the wikitext and on the rendered page, just to save the reader having to locate the grid ref as the first item in the infobox, not at all hard to locate. That's a poor trade-off in my opinion.
(3) It's impossible to follow the common practice of showing the coordinates as |display=inline,title, as that would display the grid ref twice in the infobox, unless you removed the |osgridref= parameter.
Worldwide, I think the readers using grid refs are in the minority; I never use them for example. (Just because a reader lives in a country that uses the grid refs doesn't mean they necessarily need it to make effective use of the Wikipedia article.) I simply need something I can click on to get to the interactive map facility, and the coordinates work as well for that purpose as grid ref or anything else (it could just as effectively say "click here for map"). The relatively few readers who actually need to know the grid ref can find it in the infobox.
If an infobox template lacks the |osgridref= parameter, I don't think it would be that difficult to get it added. ―Mandruss  12:15, 7 January 2017 (UTC)
@Mandruss: I accept that St Mags' is a poor example because the grid ref is in the infobox in this case. It was seeing the change to {{coord}} that started me thinking about the general case. Clem's suggestion above though carries real weight if the conversion is automatic. In my first post I specifically mentioned that this only applied to those countries where there is an established national grid system. You may only ever look at online maps, but here in the UK it is far easier to locate a feature on the OS map using a grid ref rather than trying to use lat/long; after all it is taught in schools (or at least used to be) and organisations like scouts and cadets, let alone hill walkers. Regards, Martin of Sheffield (talk) 12:51, 7 January 2017 (UTC)
Points taken. Nevertheless, |osgridref= can be added where needed, as I said. I don't doubt the problem, I question your solution to it. You are proposing the introduction of a new, second way to provide the grid ref, when the existing way would work just fine. Why add that degree of complexity as a mere matter of expediency? ―Mandruss  12:59, 7 January 2017 (UTC)
Hi, Mandruss, great to talk again. I am starting to look at all of our procedure from the POV of newbies who are enthusiastic enough to attend an editing course but fail to edit. I am looking at the problems from the POV, of the enthusiatic retired academic who really wants to add a few articles but is put off by our modus operandi. Take one example, call her Prof X, who came to a course with a pile of books and a disk of unpublished material. She had written the books, and the files on the disk. We got over the problem of edit/edit source, then we hit references-- and we lost her, her source text was marked up in the way she had done for Oxford University Press, and instead of saying to her 'put all of that in <!-- -->so we could sort it later', we attempted to explain our systems!. That was a step too far and we haven't seen her since. We have to keep the publishing learning curve simple, to gain the confidence of retired academics. We have to start at their starting point if we are going to recruit them.
So applying that lesson to coordinates- I have been around long enough to really appreciate the 'pass by reference' (Old Pascal term) Templates that we use. But to Prof X, they are an unnecessary hurdle- it is data entry we need to keep simple, and we leave it to the templates to transcribe that into what we want. The bullet needs to be bit! In chunks of the world OSGridrefs are the normal way to locate an object. In other places they are unheard of. In the UK, in 1960- 2000, they were taught in every school to any 11 year old who hold a pencil. I was taught Lat and Long as a theoretic system by an enthusiatic maths teacher demonstating base 60 counting, may be when I was 15 hard to say)- but every large scale map in the house had a OS grid. It is the natural way for two generations of potential editors to locate a point, and using another method is a hurdle. We need a method whereby Prof X, and AN Other (retired) can input a Grid Reference- and all our software needs to convert it to something defaulting to Coordinates: 51°23′06″N 0°29′58″E, grid reference TQ 74019 68065
I was immediately convinced about your argument about (1) data redundancy and (2) clutter, until I thought about it. In the normal life history of an article written by a newbie, the infobox isn't written to very much later, and more often added to an article by a future editor. Placing a {{Coord|gbmapping="TQ 74019 68065"|display=title}}, would be a task that took place before the article was switched from Draft to Article space. Later we do need to transfer |gbmapping= {{Coord|gbmapping="TQ 74019 68065"|display=title, inline,clipped}} into the Infobox template, and I would suggest that new syntax is used to allow a bot to clean up cases of conflict. The essential thing is that ifexist_gbmapping then the infobox autofills the lat long boxes, the inline reference is clipped to remove extraneous text and caluculations. Whatever happens and however, the output format should be what we 'Wikipedia lifers' expect and the input is simple enough to help and not confuse the newbie.
The clutter argument I agree with entirely- but which is the clutter? Personally I am too embedded in WP to want change- but I think what we must do is either switch it off with a display tag |display=title, inline, noGB}} or |display=title, inline, nolat}} or |display=title, inline, abbr}}
It is an interesting topic, and worth a bit of thought- the prize would be more editors? ClemRutter (talk) 16:07, 7 January 2017 (UTC)
Hi, Mandruss, great to talk again. - We have spoken before? lol - and I thought I had a good memory for usernames!
I was unable to follow everything you said, but it sounds like you propose using grid ref to isolate editors from having to understand and use coordinates. This despite the fact that online mapping tools such as Google Maps use coordinates, not grid refs. I entered TQ 74019 68065 in Google Maps and it said "We could not find TQ 74019 68065". Then I entered 51°23′06″N 0°29′58″E and it displayed a map of Rochester, Kent, with a marker at St Margarets. Since everybody who has a computer with Internet access has access to Google Maps, I submit that geocoordinates are the more universal of the two systems. For any spot on the planet, one can use Google Maps to obtain the coords by right-clicking on the spot and choosing "What's here?". They can then choose either format, and they can adjust precision per WP:OPCOORD. Your automatic conversion cannot do either.
Anybody with an IQ above about 95 is capable of learning to use coordinates, and some do so because they find it interesting and rewarding. Others don't find it interesting or rewarding, so they do other kinds of Wikipedia editing. Nobody is required or expected to do everything well or at all.
Regarding editor retention, I feel that issues such as you describe pale in comparison to the problems of (1) hostile environment and (2) unnecessary complexity resulting from a misguided desire for editor freedom (e.g. five names for the same template or guideline, several ways to handle user talk conversations, etc.)—and the community has yet to make a meaningful commitment to improving either area. ―Mandruss  12:02, 8 January 2017 (UTC)
I think we all need to remember that this was proposed as an addition to help readers, not a replacement. If you are viewing modern maps online, then lat/long does make more sense. Paper maps and historic maps are a different issue. I grabbed the bunch of maps which happened to be lying on top of a filing cabinet. The OS maps Pathfinder (2.5"), Explorer (2.5") and Landranger (1") all show lat/long as small figures on the extremity of the map. To find a location you would need to lay out the map on a table and use a straight edge. The only non-OS map I picked up is from Nicholson (part of Harper Collins) using the Bartholomew mapping at 1.6 miles/1". No lat/long is shown at all. Although unlabelled the grid is OS though (determined by comparison with the equivalent Pathfinder). Out of interest I've just grabbed the road atlas from the car (A-Z) and guess what: no lat/long only the national grid. We all tend to use what is familiar. I'd never dream of using lat/long except for Wiki and when at sea. Conversely a North American reader just wouldn't understand the point of the grid. Let's try to keep all our readers happy. Martin of Sheffield (talk) 12:41, 8 January 2017 (UTC)
There's a mapping website called Streetmap, which allows OS grid references to be input in the search box - try entering TQ 74019 68065 there. There was another (I forget its name) which allowed the same technique, but it was taken over by another outfit, which in turn was swallowed up by Bing, and the feature disappeared along the way. --Redrose64 🌹 (talk) 12:51, 8 January 2017 (UTC)
(edit conflict) Thanks for that Redrose. I've seen and used Streetmap before but had lost sight of it. BTW, of course if you click on the coordinates GeoHack thoughtfully translates to a grid reference, and the top maps are OS maps! Martin of Sheffield (talk) 13:11, 8 January 2017 (UTC)
@Martin of Sheffield: As I said prreviously: I don't doubt the problem, I question your solution to it. So work to get |osgridref= added to the relevant templates, most important ones first. If it will help, and it very well might, go to WP:VPR and seek a community consensus that this is a Good Thing; I'll support you there unless I see convincing arguments that it is a Bad Thing. You can then reference that consensus on template talk pages where you request the new parameter. You might even recruit one or two template-qualified editors to make the changes, as I did with Wikipedia:Coordinates in infoboxes.
Often, the easiest solution to implement is not the best solution; I feel this is such a case. I always think long term, and it will benefit neither reader nor editor to have two ways of specifying and displaying the same data point. They might inquire as to the reason, and your answer will be, "Well it would have been too much trouble to add the parameter to all those other templates. And now it would be even more trouble to change it back. Sorry." I don't think they will find that answer very satisfying. ―Mandruss  14:17, 8 January 2017 (UTC)

more tracking[edit]

can we track spaces in the 'region/type' field? for example, I just fixed this problem. Frietjes (talk) 16:11, 22 January 2017 (UTC)

How to extract longitude degrees from a Coord template?[edit]

If you know how to extract the longitude degrees from a {{Coord}} template, please offer some assistance at this discussion. Thanks. – Jonesey95 (talk) 05:33, 24 January 2017 (UTC)

I responded there, but for anyone who is just reading here we have {{#invoke:coordinates|coord2text|{{Coord|..}}|long}}. Frietjes (talk) 16:01, 24 January 2017 (UTC)