Talk:Diving the Cape Peninsula and False Bay/Whittle Rock

There have been quite a few versions of the map. The video shows an animation of the map development since 2014. • • • Peter (Southwood) ^(talk): 18:23, 2 May 2021 (UTC)

Whittle Rock map timeline

Star nomination

I think this topic is ready for Star nomination, so will be working through the checklist below and will nominate when I think it is complete. • • • Peter (Southwood) ^(talk): 08:08, 24 January 2022 (UTC)

Star status criteria for dive site

(Copied from Wikivoyage:Dive guide article status criteria#Star status criteria for dive site, presumed still valid until shown to be otherwise.)

Wikivoyage criteria:

• Covers the topic fully. Bleeding edge of currently available information.
• Layout and listings either match the manual of style exactly or are the exception that proves the rule. Have not noticed a deviation from recommended Dive site style.
• Prose is not only near-perfect grammatically but also tight, effective, and enjoyable. Looks good to me but I admit possible bias, as I wrote it. Others opinions welcome, preferably with actionable comments.
• At least one good-quality photo or illustration accompanies the article. Complies. All photos were actually taken at the site, ie: authentic
• If practical it has a map identifying relevant destinations. Map is still under construction as it is a big job and I have been working on it for years already, but it is already adequate for the popular areas. There is no better map available until I do more surveys, and it gets updated as often as I can get to dive there.

Diver criteria:

• A diver competent to dive the site but without any local knowledge should be able to plan a safe and enjoyable dive using the information provided (in conjunction with a regional diving guide if applicable.) Complies as far as I have been able to determine. User (divers) feedback received so far does not suggest otherwise.
• Conditions during the dive should come as no surprise. Complies to the best of currently available knowledge.

Checklist:

Leader paragraph

• The site is named
• Type of site specified
• Geographical location given in general terms
  • Nearest major landmark, near
  • Nearest City in
  • Region in
  • Country.

Understand

• A map showing the position and layout of the site in some detail, preferably to scale.
• Reason/s why one would choose to dive the site.

Position

• GPS position for the site. Should put a diver at least somewhere on the site, specify where if possible Listed positions are mostly tested. However errors are possible.
• Alternative range and bearing or cross bearings to well defined and reasonably close landmarks. Photos of landmarks desirable. Not applicable, site is several kilometers offshore, and no bearings combination would be useful in practice.
• distance from launch site or harbour for boat access (km or N.miles). Distance should be along the usual route, not as the crow flies. Distances in km from all reasonably likely departure locations.

Name

• Optional image of whatever the site is named after. (particularly desirable for wreck sites, where a photo or painting of the vessel or a similar vessel is preferred.) Not available.
• Explanation of origin of the site name, translation if applicable.

Depth

• Maximum depth to be expected on the site Detailed depths available from chart in popular arreas.
• If applicable, shallowest point of the site
• Average depth of a dive can be added if it will be useful. Too variable to be useful. Some indication given in route descriptions, and can be estimated from chart for the popular areas.

Visibility

• Range of visibility to be expected when conditions are generally considered suitable for diving. Best available information.

Topography

• Description of the layout of the site With contour map
• General idea of slope, profile and rugosity Very variable, but described in some detail for major features, and partly indicated by map contours. More detail could be given if there is consensus that it is necessary or desirable.
• Description of major features and landmarks Done where the information is available, like the popular areas.
• Condition of wreckage if applicable Not really applicable. Anchors are described or shown in photos where available.No other wreckage known.

Geology

• Only for rocky reefs
• Type of rock, (geological age, name of formation optional)
• Strike and dip optional if applicable Not applicable, intrusive igneous rock.

Conditions

• What weather conditions will result in good diving conditions. Best available knowledge.
• Any specific weather conditions which will result in unpleasant or hazardous diving conditions. Best available knowledge.
• Any special oceanographic or weather conditions the site is known for. (sudden offshore winds, upwellings, currents, plankton blooms, thermoclines etc) if applicable
• Information sufficient to allow a reasonably competent diver with a moderate understanding of the local weather and climate to forecast conditions during a planned dive over a short period (3 to 4 hours) when on site. Best available knowledge.

Facilities

• Generally only for shore access dives Not applicable.
• Facilities must be in close walking range of parking area or entry points Not applicable.
• Facilities appropriate to divers and accompanying family only.(parking, ablution, fast food, dive services, picnic areas, security, beach, shade, etc) Not applicable.

Get in

Shore entry

• Adequate directions to reach the site Not applicable.
• A map or aerial photo indicating the position of entry/exit areas (only for shore entry ) if the main site map is not sufficient. Not applicable.
• Sufficient text for a person who has no local knowledge at all to find the site and identify any access areas with confidence. Not applicable.
• Photos of the standard entry and exit points if applicable. Not applicable.

Boat entry

• Location of slipway/harbour/launch site/pickup area.
• Distance of boat ride and/or duration of boat ride.

See

Marine life and/or Features

• Photos of at least three organisms or features one may reasonably expect to see at the site
• Photos of organisms that are special in some way may be included even if not frequently seen, but it should not be suggested that a visitor is likely to see them
• Description of what a diver may see during a dive
• if the photos were not taken at the site this should be mentioned.

Photography

• advice on photographic equipment (macro/wide angle, need for external lighting) if appropriate.
• photographic opportunities that may be expected or hoped for if applicable.

Suggested Routes

• generally at least one suggested or recommended route, with an indication of what the diver may expect to see. This may be a drift dive if applicable. "Follow the divemaster" is not really a route and will only be accepted if there are really good reasons, which are adequately explained.
• Some indication should be given of how long a dive on the route will take, and if it is a long route, an approximate distance. This is not essential if it is shown to scale on a map.

Stay safe

Hazards

• Site specific hazards of any kind, including access hazards if applicable. "No site specific hazards known" is null default, and implies that the local hazards are adequately described in the regional article.
• Comprehensive listing of site related hazards (not regional hazards already in regional guide, ordinary diving hazards nor obvious sea/weather condition hazards). Advice on mitigation is optional.
• security problems and land based hazards may also be mentioned if applicable. (theft/mugging risk, animals stealing food etc) Not applicable.

Skills

• Skills, competence or certification level required for diving at the site, if any.
• Skills recommended for diving at the site, if any.
• "No special skills required/recommended" is null default, this implies that a person trained to dive in the region will be able to handle the normal conditions for diving at the site.

Equipment

• any equipment beyond the standard equipment listed for the region in the regional guide, either required or recommended for the site for safety of convenience. Reason should be specified if not obvious.
• "No special equipment required/recommended" is null default, and implies that divers trained to dive in the region, or who have some experience diving in the region will know what is needed.

The map

@SHB2000, Pbsouthwood: There is now a smaller file at Commons (thanks for that), still high enough resolution, but probably small enough for mobile users. However, the link to that file was commented out when the {{Regionlist}} with a regionmap parameter was added. The regionmap link goes to the huge file only.

I added an other_versions parameter to the file description pages at Commons, but I don't think most users will note that link. I don't know how to best make the moderate resolution map accessible for those who need it.

–LPfi (talk) 12:23, 21 March 2022 (UTC)

LPfi, Still playing around with Template:Regionlist. It does not seem to like having wikilinks in the display text (or something). If all else fails, I will switch to the not quite so high res map, as that will work fine for everyone except for getting a high res print. Not many people will be printing the map on A0. Cheers, • • • Peter (Southwood) ^(talk): 13:03, 21 March 2022 (UTC)

Apparently there is an old bug mentioned here that messes with the functionality on mobile. • • • Peter (Southwood) ^(talk): 11:21, 22 March 2022 (UTC)

Tweak

Andyrom75, this is the specific problem. The content below is copied from Diving the Cape Peninsula and False Bay/Whittle Rock#Understand

I want this content to display only in desktop:

Map of the Whittle Rock main reef — switch to interactive map

Map of the Whittle Rock main reef

This content to display only on mobile:

Map of the Whittle Rock main reef.
Click here for higher resolution for mobile.

This content to display at all times:

See also: Diving the Cape Peninsula and False Bay#Understand

and the rest of the section

• It would seem that I have found a solution. Some skill, luck, and poking things with a stick in the dark were involved. Cheers, • • • Peter (Southwood) ^(talk): 10:16, 25 March 2022 (UTC)

• • Ah! That one should solve it. –LPfi (talk) 10:33, 25 March 2022 (UTC)

Discussion copied from Star nomination page

I have been working on this one a long time. Though the site is still being surveyed in the outer reaches, the page has pretty much all the information needed and currently available. A certain amount of stylistic development has occurred over the years on dive site articles, and I am interested in feedback regarding how fit it is for purpose. It will be some years before the surveying is complete, as I get to Whittle 10 to 15 times in a good year, and consider my time well spent if I get 500m of good contour or perimeter on a dive. The popular areas are adequately mapped – I am mostly exploring places no-one has dived, or at least no one has dived and reported on diving there. I have used the checklist for dive site star assessment used on several previous star dive sites on the article talk page, and there is a little video clip there showing how the surveying has progressed over time. Cheers, • • • Peter (Southwood) ^(talk): 15:46, 28 February 2022 (UTC)

• Close some comments from me.

• There's a lot of images about marine life. Should they be put in a gallery?

Fair question, but how would a gallery improve matters? Do you mean a gallery section on the page or a gallery sub-page? I have tried to place the images at or near the relevant text, but variability of page size can affect what the reader sees on the day. • • • Peter (Southwood) ^(talk): 08:28, 1 March 2022 (UTC)

I see. I was just thinking of using galleries like we use for our cuisine articles (e.g. Bush tucker or Georgian cuisine), but I agree hat the page size can have effects. --SHB2000 (talk | contribs | meta.wikimedia) 08:45, 1 March 2022 (UTC)

I just counted. Only four of the images are about marine life. Most are about local features which happen to be overgrown with marine life and are placed as close as possible to the relevant text, but may show up further down the page due to rendering variations on different creens. I have doubts that putting those four into a gallery will improve the appearance, but willing to try if you think it worth the effort. • • • Peter (Southwood) ^(talk): 14:41, 1 March 2022 (UTC)

Found another, and decided to gallery both marine life and features. Let me know if you think it an improvement. I am OK with it. • • • Peter (Southwood) ^(talk): 12:30, 21 March 2022 (UTC)

• In the Get in section, it says you can only access by boat. Do you need a private boat, are there tours, and maybe linking to some of the operators may also be beneficial for the traveller

If you read the main article on Diving the Cape Peninsula and False Bay you will see that there is are large sections giving detailed explanation of all the stuff that is common to the whole area or major subdivisions of it. Whittle Rock is classified under offshore dive sites of False Bay. There are also sub-articles on each of the launch sites mentioned (already linked), and a section on the charter boat services, (not currently linked). This has been standard for many years, as the alternative is to say basically the same thing on hundreds of dive site articles. In a nutshell, there are charter boats which can take a traveller to any of the dive sites in the region, and they vary from time to time, and most operators only launch from a limited number of launch sites, which limits the dive sites they visit. Visits to a dive site also depend on the weather and are generally not predictable or bookable more than two to four days in advance. This information is centralised in the main article, but it may be useful to link back to those sections from the "Get in" section. This will be a new feature, and may be a significant improvement in utility for the traveller if it works and is allowed. So I will give it a try. • • • Peter (Southwood) ^(talk): 08:28, 1 March 2022 (UTC)

Oh, makes sense and agree that information is best centralised than duplicated. I was probably biased here since I just went straight to reading the article as opposed to a normal reader who hypothetically would be navigating thru the breadcrumbs. --SHB2000 (talk | contribs | meta.wikimedia) 08:45, 1 March 2022 (UTC)

Nevertheless I think it should be discoverable no matter how you get to the page. I will be working on this and will let you know when I think it has been adequately addressed. This is valuable feedback. • • • Peter (Southwood) ^(talk): 09:14, 1 March 2022 (UTC)

SHB2000, I have made this edit to provide links to the appropriate page and sections. Does this seem sufficient? • • • Peter (Southwood) ^(talk): 09:34, 1 March 2022 (UTC)

Looks good to me. SHB2000 (talk | contribs | meta.wikimedia) 09:44, 1 March 2022 (UTC)

Thanks, I will give it more thought and may make a template to add to all the site articles in the "Get in" section. • • • Peter (Southwood) ^(talk): 14:27, 1 March 2022 (UTC)

• The only dynamic map listed is in the § Nearby section. Should the static map be made toggleable? (ping me if you need some assistance with it)

Do you think that an additional dynamic map will materially improve the article? Are you suggesting that the static map which provides a large amount of very useful information for dive planning be toggleable with a dynamic map which would show basically what is shown on the map in the "Nearby" section? • • • Peter (Southwood) ^(talk): 08:28, 1 March 2022 (UTC)

I have added a dynamic map to the new "Do" section, which just shows the "do" and "see" markers' relative positions. It seems to be an improvement. • • • Peter (Southwood) ^(talk): 02:55, 9 March 2022 (UTC)

SHB2000, I would like to learn how to make toggleable maps as you suggest above, so pinging you as suggested.• • • Peter (Southwood) ^(talk): 10:09, 21 March 2022 (UTC)

There's a quick guide on Template:RegionStats, but I actually learned how to make them by simply looking at the format used on Portugal#Regions. I'll add it in a sec. SHB2000 (talk | contribs | meta.wikimedia) 10:16, 21 March 2022 (UTC)

@Pbsouthwood: Done. SHB2000 (talk | contribs | meta.wikimedia) 10:39, 21 March 2022 (UTC)

SHB2000, thanks, that is a really cool feature. Knowing the name of the template is half the problem solved. I will look at it and maybe tinker a bit to see what can be done. I might want to put the mobilemax map link back in the caption. Cheers, • • • Peter (Southwood) ^(talk): 11:18, 21 March 2022 (UTC)

It certainly is. I was first interested to find out that feature too but unfortunately I'm not that good at static mapmaking so region maps I make more look like the ones seen in Adelaide#Districts. SHB2000 (talk | contribs | meta.wikimedia) 11:21, 21 March 2022 (UTC)

SHB2000The switch feature does not seem to work on mobile for me. Can you get it to work? • • • Peter (Southwood) ^(talk): 14:38, 21 March 2022 (UTC)

Not sure how it works on mobile. I don't usually use voy on mobile. SHB2000 (talk | contribs | meta.wikimedia) 20:18, 21 March 2022 (UTC)

There is an old bug in the wikimedia software mentioned here that affects the function on mobile. The question now, as I see it, is whether to optimise for mobile or desktop, or make a kludge so that both mobile and desktop users can get what they need, at the cost of possible redundancy of images. Does anyone know if there is a way to markup content so that it only gets shown on desktop XOR mobile? Cheers, • • • Peter (Southwood) ^(talk): 11:31, 22 March 2022 (UTC)

• Videos are not permitted per the Wikivoyage:Image policy.

Pretty much so. --SHB2000 (talk | contribs | meta.wikimedia) 08:45, 1 March 2022 (UTC)

Is this reply in the right place? • • • Peter (Southwood) ^(talk): 08:11, 8 March 2022 (UTC) [Reply] function put this question in the wrong place, so I manually fixed it

The video is on the talk page, which is not subject to the same rules as mainspace. I am not aware of a ban on videos on talk pages. If there is one please link me to it. • • • Peter (Southwood) ^(talk): 08:28, 1 March 2022 (UTC)

Yeah the section about videos is not very clear except and only has a one-line mention in Wikivoyage:Image_policy#Other_media. --SHB2000 (talk | contribs | meta.wikimedia) 08:45, 1 March 2022 (UTC)

I just noticed the broken video link in the article and removed it. • • • Peter (Southwood) ^(talk): 09:14, 1 March 2022 (UTC)

• I don't think the Wikipedia link in § Read is permitted per Wikivoyage:Links to Wikipedia

Fair point. I will read the fine print again. • • • Peter (Southwood) ^(talk): 08:28, 1 March 2022 (UTC)

Wikivoyage:Links to Wikipedia stipulates that: "Links to the relevant Wikipedia and Wikidata pages should be added to these fields in listings whenever possible. Inline links to Wikipedia are otherwise generally not used in mainspace pages on this site, to avoid their being mistaken for internal links to other Wikivoyage articles." I suggest that a link in the "Read" section displayed as "False Bay on Wikipedia" is unlikely to cause any confusion whether clicking the link would leave Wikivoyage, and also that it is a form of listing, where external links, including links to Wikipedia, are explicitly permissible and recommended. • • • Peter (Southwood) ^(talk): 08:56, 1 March 2022 (UTC)

I think the traveller comes first regarding that link, but as it goes to the False Bay article, shouldn't it be listed there instead? WP has an article on Whittle Rock, why isn't that chosen? It might be useful also to point to Diving the Cape Peninsula and False Bay#Read. –LPfi (talk) 09:27, 1 March 2022 (UTC)

LPfi, The link to False Bay has been there since before I started the Whittle Rock article on Wikipedia. It seems that I forgot to link it from here. Both these suggestions for additional links are good, but as there is a lot of relevant and interesting stuff in the False Bay article, I see no harm in keeping it too. It is still a short section.• • • Peter (Southwood) ^(talk): 09:49, 1 March 2022 (UTC)

I'm just afraid it might be read instead of our False Bay article, which is the reason why Wikipedia links are discouraged. Linking to the Read section of that article and linking Wikipedia from there seems more useful. I still trust your judgement. –LPfi (talk) 11:08, 1 March 2022 (UTC)

I didn't know we still have a False Bay article. Apparently it was kept as a valid region article, and is about the cities in the bay area, not the water itself, so not really relevant for information about the offshore diving environment, whereas the Wikipedia articles fill in the gaps which would be too detailed or otherwise out of scope for a dive-site article. • • • Peter (Southwood) ^(talk): 14:23, 1 March 2022 (UTC)

OK and oops. I used False Bay (also) as a shorthand for Diving the Cape Peninsula and False Bay, so what I said might have been confusing. I figured that the Wikipedia article on the False Bay would be as relevant for those diving other parts of the area. That's just based on the names, though, as I cannot judge what is relevant for a diver. –LPfi (talk) 18:44, 2 March 2022 (UTC)

The Wikipedia article on False Bay is relevant for those diving other parts of the area, so will make sure it is also linked from the Diving the Cape Peninsula and False Bay article. • • • Peter (Southwood) ^(talk): 08:28, 4 March 2022 (UTC)

I found some more places where linking back to the relevant section in Diving the Cape Peninsula and False Bay could be useful to a reader who got to the page via an alternative route, or is not particularly familiar with the regional page, so added some "See also" hatlinks. • • • Peter (Southwood) ^(talk): 06:13, 4 March 2022 (UTC)

This seems to be a good improvement and I have applied it to all the dive site articles in the region as new default style • • • Peter (Southwood) ^(talk): 10:09, 21 March 2022 (UTC)

• Something that is not concerning but thought I might mention it, but some of the text in the static map is too small to read and I have to zoom in. As static maps aren't a requirement for star articles anymore, not an issue to fix.

The map can be zoomed to show all useful detail at a legible size. There is a lot of very useful detail on the map which cannot be shown any other way that I can think of. Increasing the text size enough to read at the displayed size will make the map extremely cluttered and possibly unusable. It is of course possible to add zoomed in map excerpts for each area discussed, but I think that would be overdoing it since the detail is all available by zooming the current map, and having to update dozens of excerpts every time the map is updated would be a bit impracticable. If there is a way to make the map zoomable inside a constant size frame like the dynamic maps I would like to know how to do that as it would be a great option. • • • Peter (Southwood) ^(talk): 08:28, 1 March 2022 (UTC)

Yeah, after some thought, if the text were to be expanded, it would obstruct some useful info, so I guess zooming in is the only solution for now. --SHB2000 (talk | contribs | meta.wikimedia) 08:45, 1 March 2022 (UTC)

Perhaps the possibility of zooming should be mentioned, perhaps with a link to instructions. I don't see any way to zoom, but to go via the Commons page and use the browser's zoom function. The options at Commons are limited: 2,560 × 1,811 px is still a bit small, 14,040 × 9,930 px is a bit much. Firefox's zoom function also is not that good: from 30% to 500% (of the full resolution or the resolution that fits the window), while I'd like a broader range for this image. I think I'd use some hack or external software if I were to use the article. Is it just me missing something obvious? The Commons image viewer? –LPfi (talk) 09:41, 1 March 2022 (UTC)

LPfi I entirely agree with you. It is a bit of a problem not having an intermediate resolution. The full resolution prints out as a very nice paper map on AO, which was the intention for the large file size. Desktop and high end smartphones will read the full resolution, and you can zoom in as far as anyone would reasonably want to go, but many cell phones will not. I don't know what to do about it.• • • Peter (Southwood) ^(talk): 14:23, 1 March 2022 (UTC)

I have put links into the map caption for the two highest resolution versions, but I don't really like it as a work around. I will make some enquiries at commons and see if other resolutions could be made available. • • • Peter (Southwood) ^(talk): 18:31, 2 March 2022 (UTC)

I think it is enough just to specify that resolution for the image and preview the result. The servers would create the requested file and save it for future use, available through the file description page. –LPfi (talk) 18:47, 2 March 2022 (UTC)

LPfi, That should work, but there seems to be a limit below the needed resolution. There is a bug report about it open on Phabricator, and I am waiting for a result, I may have to work around it. • • • Peter (Southwood) ^(talk): 06:13, 4 March 2022 (UTC)

See https://phabricator.wikimedia.org/T302979 • • • Peter (Southwood) ^(talk): 07:33, 4 March 2022 (UTC)

There seems to be a Debian default limit of 3200px for width and height (amongst others) for the ImageMagick converter. It looks like I will have to upload a manually resized image under another filename and link to that. • • • Peter (Southwood) ^(talk): 06:53, 5 March 2022 (UTC)

I have uploaded a lower resolution image for mobile and linked in the caption. It uploads on my phone and zooms in to adequate resolution for text. YMMD. let me know if it also works for you. • • • Peter (Southwood) ^(talk): 07:25, 5 March 2022 (UTC)

Thanks, that should work, will check later. I am a bit confused though: "32KP" would seem to mean 32,000 px rather than 3,200 px. Perhaps it is the memory limit that is the limiting factor, and that varies according to algorithms used etc., so hard to translate to a specific size. Anyway, it seems the limit is too small, and the new upload should be a sufficient workaround. –LPfi (talk) 20:16, 7 March 2022 (UTC)

You are right, I misread that. Confirmation bias I guess, as 3.2KP would have fitted in perfectly with my experimental data. Also my eyes not great for small print. So it goes... Maybe I will dig a little deeper. • • • Peter (Southwood) ^(talk): 08:05, 8 March 2022 (UTC)

That's some from me. That being said, it's a very detailed dive article, and it's a nice read. --SHB2000 (talk | contribs | meta.wikimedia) 06:35, 1 March 2022 (UTC)

Thanks for the comments SHB2000. If I may ask, do you dive? • • • Peter (Southwood) ^(talk): 08:56, 1 March 2022 (UTC)

Unfortunately I don't dive regularly, but I have done some diving before at the Great Barrier Reef, but it was quite some time ago. SHB2000 (talk | contribs | meta.wikimedia) 09:00, 1 March 2022 (UTC)

Thanks, that calibrates you nicely in terms of where you fit in my target audience. Cheers, • • • Peter (Southwood) ^(talk): 09:49, 1 March 2022 (UTC)

• Support I see information and details about the region for every angle of the destination, up to this contributor's usual high standard of dive articles. Since there's a static map and it's a dive guide, the lack of coordinates for POIs doesn't concern me. I think this is another one of our star quality dive guide articles and therefore support its nomination. --Comment by Selfie City (talk) (contributions) 22:01, 6 March 2022 (UTC)

  Thanks for the support SelfieCity, but which POIs sre you referring to? As far as I know, all from this site, (the drop points for the dive spots and the anchors with known positions) have "Do" marker coordinates listed, complete with text [Hdd°mm.mmm'] format positions, which is the local standard for GPS work, and can be seen on the zoomable "Nearby" section map with grey markers. It is the nature of offshore coordinates to be on a featureless background of sea, so I have not displayed them in the "Understand" section of the article, though it would be trivially easy to add another map if there is consensus that it is sufficiently helpful in some way. Cheers, • • • Peter (Southwood) ^(talk): 13:11, 7 March 2022 (UTC)

  SelfieCity, Now you have got me thinking. Do you mean having "Do" markers for all of the PoIs listed in the "Topography" section? If I did that instead of listing them under "Positions" and just describe the general position of the reef in the bay in "Position", I could then put "See" markers in the "Features" section for the anchors, with a short description and photo where available. I rather like the idea. It would be a new format for dive sites but should not take too long to arrange, most of the groundwork is already done.• • • Peter (Southwood) ^(talk): 13:26, 7 March 2022 (UTC)

  I have started to rearrange based on the idea above, and I think it will be good. It may take a day or two for the basic reshuffle, and there may be a bit of unforeseeable consequences, so a few more days may be required before it is stable again. I will post to let you know, but feel welcome to comment on the work in progress. Cheers, • • • Peter (Southwood) ^(talk): 15:34, 7 March 2022 (UTC)

  Rearrangement has been completed, though more tweaks may happen if/when I identify the need. I think the layout is stable again. • • • Peter (Southwood) ^(talk): 02:55, 9 March 2022 (UTC)

  By POIs, I mean the particular dive sites. I don’t know if there’s a more technical name for them I’m forgetting. --Comment by Selfie City (talk) (contributions) 17:20, 9 March 2022 (UTC)

  SelfieCity, Dive site drop points would be points of interest, as would major features one might want to go look at, like the assorted anchors at this site. Points of interest is an adequate generic term, I would think. Anyway they are all now united with their geolocation markers and show up on the dynamic map against a featureless background of sea. One day maybe I will find out how to overlay my bathymetric charts on the OSM and get them to work as a background layer. It must be possible, but I don't know how to do it. Cheers, • • • Peter (Southwood) ^(talk): 11:41, 10 March 2022 (UTC)

• I think I have addressed all outstanding issues, to my satisfaction, at least. Please let me know if they are not to your satisfaction too.
• Feedback from more people would be nice, and could lead to further improvement, which would also be nice. Cheers • • • Peter (Southwood) ^(talk): 10:09, 21 March 2022 (UTC)
• I think I have found a suitable workaround for the map toggling problem on mobile.
  • The toggleable map now only displays on desktop, and clicking on the map takes you to the high resolution map the usual way.
  • An alternative map with a caption link to the not-quite-so high-resolution map that downloads reliably on mobile, now displays only on mobile, so it works as well as currently possible for both platforms.
  • The hack is extremely simple, so probably robust, but If anyone can get it to break, let me know. Andyrom75, please take a look at Diving the Cape Peninsula and False Bay/Whittle Rock#Understand and let me know if you see any potential problems. Cheers, • • • Peter (Southwood) ^(talk): 10:12, 25 March 2022 (UTC)

Peter (Southwood), that's what I have in mind when we discussed in lounge. However, the implementation shall be manged inside the template, not in the body of the article, because an editor "has the right" to not be familiar with HTML tag and CSS classes.

Last thing, in my opinion is useless to state "Click here for higher resolution...", because every image can be clicked to make it bigger. Furthermore the URL you have added, doesn't help at all the template implementation. --Andyrom75 (talk) 11:37, 25 March 2022 (UTC)

Thanks Andyrom 75, Now that I know how to do it, coding a template is practicable, and will make it easier for all to use. I am one of those editors who is not very familiar with HTML and CSS, and getting this done was at least a full day's work altogether, since at first I had no idea of if or how or it could be done or even what to start looking for. Saving myself and the next person all that hassle is totally a good thing in my book. I was thinking of two templates: Template:Mobile only and Template:Desktop only, since those names should be easy to remember or even guess.
Do you have any suggestions about the url? I don't understand the problem. Cheers, • • • Peter (Southwood) ^(talk): 11:59, 25 March 2022 (UTC)

Maybe I should explain why I did that, and maybe you can suggest a better way. In mobile view, if you click on the image, a low res version is loaded and does not zoom in enough to read the map text - you have to click your way through to Commons and then select the 7kpx wide file. Some people dont know you can do that. The url in the caption links directly to the high resolution original image file which does zoom in enough to read the text, but takes more bandwith. Cheers, • • • Peter (Southwood) ^(talk): 12:27, 25 March 2022 (UTC)

Peter (Southwood), my idea is to change Template:Regionlist implementing inside that template the logic to adapt the output to the used device (in reality, to the used skin). --Andyrom75 (talk) 13:14, 25 March 2022 (UTC)

Andyrom 75, I had the less ambitious and more versatile intention to make the more generic templates which could be used in a wide range of applications, including wrapping Template:Regionlist for only desktop display. It appears from my experiment that this should be possible. I am already experimenting further, Template:Mobile only appears to work as intended, and manages fine with the debated url, and I am about to start on Template:Desktop only. I will report back here what I find out. Having the function/s inherent in Template:Regionlist may have advantages as it will not require the user to know about these problems and is therefore more user-friendly. In many cases there will be no issue with the resolution problem I have, but sometimes this problem does occur, so best if it can be accommodated. Allowing a null alternative for mobile display in Template:regionlist should work. Cheers, • • • Peter (Southwood) ^(talk): 14:02, 25 March 2022 (UTC)

Andyrom 75, Template:Desktop only now also exists and also does exactly what I expected it to as far as I can tell. They have both been used in Diving the Cape Peninsula and False Bay/Whittle Rock#Understand to replace the HTML/CSS markup. Cheers, • • • Peter (Southwood) ^(talk): 14:49, 25 March 2022 (UTC)

Peter (Southwood), personally I don't like this approach because goes against output standardization that in my opinion is a must. --Andyrom75 (talk) 14:52, 25 March 2022 (UTC)

Andyrom 75, In principle I am also generally in favour of standardisation, but I don't understand your point. What output standardisation does it go against? • • • Peter (Southwood) ^(talk): 15:22, 25 March 2022 (UTC)

Peter (Southwood), in your way, everyone can change the output, so it's not flexibility, but anarchy :-) The right way to do it, is to change the template. In this way we'll avoid to introduce two more templates and a more elaborated syntax. Furthermore the change will be transparent to any editor. --Andyrom75 (talk) 16:12, 25 March 2022 (UTC)

Andyrom 75, As long as we can do what needs to be done to provide what the traveller needs, I am not too fussy. Likewise as long as standardisation does not prevent us from providing what the traveller needs, not too fussy. I favour utilitarian standardization over Procrustean standardization. However I do not have the skills to make the standardised template work, so I will use what is available until Template:Regionlist is available to do what we need it to do. Ideally that would be for it to work as intended on mobile, but I don't see that happening anytime soon. Cheers, • • • Peter (Southwood) ^(talk): 16:23, 25 March 2022 (UTC)

@Pbsouthwood, I'm not sure I've understood your point. Andyrom75 (talk) 16:36, 25 March 2022 (UTC)

Andyrom 75, I don't object to standardising output provided that it is adequately functional and available. I prefer less optimal tools if they exist to theoretically better tools that do not exist or are crippled by something we cant fix. I would prefer to continue using the templates Mobile only and Desktop only until a better template is available. When that is the case I no longer care whether those templates are discarded as redundant, because I was able to get the job done. As an engineer, I tend to be pragmatic. Cheers, • • • Peter (Southwood) ^(talk): 18:18, 25 March 2022 (UTC)

@Pbsouthwood, I still disagree on the approach but I admire how you are proud of being an engineer, I'm not able to do the same :-D Jokes a part, I've modified the template as explained above. --Andyrom75 (talk) 20:05, 25 March 2022 (UTC)

Andyrom 75, I assume by "the template" you modified, you refer to Template:Regionlist. I will take a look and see if it will do what I need. I am not sure exactly what it is that you mean by "still disagree on the approach", but that may become clear if it has any practical effect on anything. It is not so much that I am proud of being an engineer, but that I recognise that reality does not always match up with preferred policies and that perfection at an unpredictable future time is the enemy of good enough for now. Getting the job done often requires compromises. Cheers, • • • Peter (Southwood) ^(talk): 02:09, 26 March 2022 (UTC)

Andyrom 75, I have checked the function of the template on desktop and mobile for Diving the Cape Peninsula and False Bay/Whittle Rock. On desktop it is fine, when one clicks on the map it opens on highest resolution and the text is clearly legible. On mobile when one clicks on the map it opens at the largest thumbnail, which does not zoom up enough to clearly read the map text. This is not standardising the output, the mobile user gets a degraded experience. From personal discussion with users, it appears that most users that I have spoken to access the map on mobile, often when out at sea on a boat, and need to read the map text. How does the user know that there is a higher resolution version available but they must click through to Commons to find it? • • • Peter (Southwood) ^(talk): 02:46, 26 March 2022 (UTC)

I think the fixed image width now used for the mobile view is causing the hatnote to render in a narrow column on the left side, which did not happen on my phone with the thumbnail at default size. • • • Peter (Southwood) ^(talk): 04:08, 26 March 2022 (UTC)

@Pbsouthwood, sorry for the ambiguity, I meant that I disagree on using the two templates you created, in my opinion both shall be avoided for all the reasons explained above.

Regarding the hatnote, this is the normal behavior of the text that in Wikimedia projects surround the images but the DIV tag you used forced a different behavior. Also in this case there are two different standard approaches to be used. The first is the one commonly used in en:voy that consist in applying the template:see also at the beginning of the section (in you case is enough before the image). The second, commonly used in it:voy is to use the template:clear after the image. Andyrom75 (talk) 06:50, 26 March 2022 (UTC)

Andyrom 75, Ok thanks, I now understand the hatnote behaviour, I will go with the en: standard. it will push the image down a little in the desktop view, but not enough to be a problem. Clear below the image would have big influence on the appearance of desktop view. That narrow column of text beside the image is poorly legible and looks bad, so must be avoided, but a huge whitespace on wide screens would be as bad, maybe worse. Cheers, • • • Peter (Southwood) ^(talk): 07:10, 26 March 2022 (UTC)

@Pbsouthwood, yw. If now the template is inline with your needs I suggest to broaden the discussion and check if on the other articles there's no negative impact (i.e. remain the same or improved). When all is fine and confirmed, the content of this sandbox template can be poured into the official one. Cheers, --Andyrom75 (talk) 08:08, 26 March 2022 (UTC)

Andyrom 75, Thanks for your efforts so far. The template appears to be significantly improved for cases where it is not necessary to link to the high resolution original file from mobile, and I think that is a MediaWiki problem, so I cannot reasonably demand that you fix it, if indeed it is fixable from our side. I will still have to find some way to work around this, as I am aware of several users who have not been able to work out that a high res file even exists, and think that the one they get is all that is available. This limits the utility of the mobile site to most of the users who use it for these dive sites with large and detailed maps. Let us throw this open for general testing and other comments, and see if anyone else remarks on the same problem. This may be an edge case important only for dive sites, in which case a solution only for dive site articles would be appropriate, but that would have to only display on mobile. Cheers, • • • Peter (Southwood) ^(talk): 10:49, 26 March 2022 (UTC)

@Pbsouthwood, as you guessed, since this is the standard way the images are managed by Wikimedia, the template shall be kept the way it is, but for specific cases similar to this one, you can add (outside from the template) a text with the sentence you added initially that includes the link to the hi-res image. It's like when you add to a listing the official website, but inside the description you can add a link to a specific page of the website. --Andyrom75 (talk) 06:23, 27 March 2022 (UTC)

Andyrom 75, In a Star class article we expect the user to be able to find a linked item that they need by using the same procedure that would be used on any other correctly formatted page. In this case, the normal procedure on desktop is to click on the image to get the larger image. Clicking directly on that larger image loads the high resolution version, which can then be zoomed in, and the cursor indicates that this will happen by having a little "+" symbol. This is intuitive and requires no special knowledge of using Commons. Mobile currently works very differently. A user wanting the highest resolution is likely to tap (touchscreen click equivalent) on the default image displayed by the template. This has a predictable result of opening a larger image. It is not obvious that tapping again on the larger image will not work the same way as on desktop, and that an even larger image that is actually legible might or might not exist on a different site, and to find out you need to tap on a button at the lower left labelled "Details", after which you have to inspect the fine print under the displayed image to see what alternative sizes are available, recognise that the text at the end of the list below the thumbnaii displayed indicates the largest available image, and that it is a link that will open the image if tapped. Ideally the high resolution image would be opened by tapping/clicking directly on the image rather than going through all this relatively complicated and not at all intuitive procedure. An ordinary user is unlikely to guess that there is a high res image to be found, so is likely to stop looking almost immediately. Therefore we must firstly inform the user that the image they need exists, secondly we must put this information where they are likely to look (ideally where they are already looking), and thirdly, we should provide a direct link to the correct image file, and if it is not at the place the user is currently looking, we need to tell them where the link is. Since the mobile platform appears to fail to provide a user-friendly experience as a default, and there is no indication that it will in the foreseeable future, we must make our own hacks. The one I wrote, while far from ideal, did the job better than any other currently available. Your upgrade of the Template:Regionlist is a great improvement for most applications, but does not work for dive site maps of moderately large areas. Adding information about how to find the right map in the text is a poor workaround, as readers will not find it when they have no reason to know they need to look for it. Adding a big button under the image saying "Click here for high resolution map" would be more effective, and having the link in the map caption seems to me likely to be the most effective solution, even if it requires a different template. You may have some alternative which would work just as well, and I would be happy to use it, but I don't know what it is. Cheers, • • • Peter (Southwood) ^(talk): 06:04, 28 March 2022 (UTC)

@Pbsouthwood, if not already nowadays, sooner or later all the user will be familiar with the standard Wikimedia Commons behavior on mobile view (that in your case means two consecutive clicks). I understand your concern for those that are not yet confident, but my only suggestion is the one previously stated. --Andyrom75 (talk) 06:38, 28 March 2022 (UTC)

Andyrom75, I don't think we should be basing policy on the assumption that readers must learn to deal with our obscure arbitrary technical details, or must guess that something is there to look for. That is a way to lose readers. In my experience they don't bother to look for things they do not know exist. When I discuss it with them they already complain that the site is too much hassle.
As this is the discussion for a Star nomination, I will request comment from the reviewers.
SelfieCity, LPfi, SHB2000. As I see it, my current options are to
(a) fail to provide reasonably user-friendly access to a legible map to mobile users (I would rather lose the star)
(b) use non-standardised templates or markup to work around the problem, allowing a link in an intuitively discoverable place (the map caption) to a significantly more useful high resolution map that readers have no obvious reason to know exists, and are unlikely to spend time looking for it for that reason, or
(c) revert to separate static and dynamic maps, which feels like going backwards, but may be the only compromise that everyone accepts. Cheers, • • • Peter (Southwood) ^(talk): 07:46, 28 March 2022 (UTC)

tbh I really don't have an opinion on this, but if anything, I favour b. SHB2000 (talk | contribs | meta.wikimedia) 08:10, 28 March 2022 (UTC)

@Pbsouthwood, as explained above you should list also (d) that actually is (b) but outside the caption. --Andyrom75 (talk) 08:24, 28 March 2022 (UTC)

Fair enough, but it should be directly below the frame in that case so that it is obviously referring to that map. Outside the frame is less likely to be correctly understood or even noticed, so should be more conspicuous. Inside the frame in the caption is pretty clear that it refers to that specific frame. Outside the frame would require something like one of the rectangular button templates on English Wikipedia. There is also the matter of coding the template. I am limited in my skills to mainly wikimarkup and a little bit of HTML and CSS. No Lua. Inside the caption and frame puts it in the best position to be seen and understood. • • • Peter (Southwood) ^(talk): 16:05, 28 March 2022 (UTC)

If this is a common problem in dive guides, then I don't see why we couldn't make a specific template for them, which includes a parameter for the alternative image to be linked. That way we could keep the difference inside the template, but also provide the link where it is most easily found – as I assume from the above; I don't have much experience of the mobile site, and experimenting I would probably behave in atypical ways. –LPfi (talk) 11:58, 28 March 2022 (UTC)

This is how I would want (b) to work and look. I expect it to be a fairly common problem in dive guides. Possibly becoming more common in the future, but cannot say for sure. Sometimes things change unexpectedly. It would mainly be a problem where there are several sites in a region small enough to have a common map, but big enough that there is quite a lot of detail to go on the map. • • • Peter (Southwood) ^(talk): 16:21, 28 March 2022 (UTC)

Due to a glad unexpected event I'm starting to have soon not su much time, so I hope to finish this task quickly to completely support you. Here my suggestion. Let's widely discuss to approve the current sandbox template. Once Template:Regionlist have been updated, I can draft a dedicated template for scuba articles. --Andyrom75 (talk) 06:59, 29 March 2022 (UTC)

Andyrom75, That is a kind offer, Do you want to open a RfC on Template:Regionlist?
The Dive site map toggle template does not need all the region listing display with colour coding and keys, but it would be useful to be able to display Marine Protected Area borders, and allow user options of listing, see and do markers, which can be seen in the dynamic maps in "Nearby" sections of dive site articles. • • • Peter (Southwood) ^(talk): 15:26, 29 March 2022 (UTC)

Peter (Southwood), I don't know the procedure here in en:voy. In it:voy we just talk on lounge/bar. My idea is to create a "scuba template" that use the "regionlist template" (as you said) without activating the legenda, but to do that, I need to consolidate the sandboxed template. --Andyrom75 (talk) 19:42, 29 March 2022 (UTC)

Andyrom75, The pub should be fine to open the discussion. Please ping me when you do. Cheers, • • • Peter (Southwood) ^(talk): 19:57, 29 March 2022 (UTC)

It's where I open a bunch of template for approval threads and no-one has ever been concerned about that so it should not be a problem. SHB2000 (talk | contribs | meta.wikimedia) 21:25, 29 March 2022 (UTC)

SHB2000, Selfie City and LPfi, Do any of you see any outstanding issues? I would prefer wider comment, but if none is forthcoming we should probably wrap this up. Thank you for your contributions, they have been helpful, and have led to what I consider significant improvement. Cheers, • • • Peter (Southwood) ^(talk): 04:18, 9 April 2022 (UTC)

In the absence of further comment, promoting to Star, Thanks to all of those who contributed to this discussion. • • • Peter (Southwood) ^(talk): 10:10, 19 April 2022 (UTC)