As per community consensus, the Spanish Wikipedia community would like to request that their Katographer configuration be amended to make their maps dinamic, disabling static maps and static thumbnails.
Vote sponsor mentioned that this should be the same configuration that Wikimedia Commons use.
Thank you.
Related task: T269984
Change 723689 had a related patch set uploaded (by MarcoAurelio; author: MarcoAurelio):
[operations/mediawiki-config@master] [eswiki] Disable static mapframes
I think the above patch will make eswiki behave like Commons with regards to Maps. I'm tagging Maps here so they can review both Task and Patch. Thanks in advance.
In eswiki, this option - direct interactive map, without static thumbnail and full screen requirement - is fully functional in edit-preview mode, being deactivated when saving the edit. In case it's useful or orients the resolution.
Change 723689 merged by jenkins-bot:
[operations/mediawiki-config@master] [eswiki] Disable static mapframes
Mentioned in SAL (#wikimedia-operations) [2021-10-06T18:31:57Z] <legoktm@deploy1002> Synchronized wmf-config/InitialiseSettings.php: eswiki: Disable static mapframes (T291736) (duration: 01m 17s)
Done. Please note that it won't take effect immediatelly as the parser cache needs to expire in order for the new dynamic maps to appear. Please let the wiki do so automatically. Best regards.
Reverted in https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/726950/
Reason for revert: Loads large JS/CSS dependencies client-side.
After some discussion with @Krinkle on IRC I'm reverting this for now:
11:34:21 <Krinkle> eh, wait, disabling static thumbnails is a feature? 11:34:39 <Krinkle> Does this mean it's loading that whole OOUI and map backend interaction and canvas rendering on page load? 11:35:12 <legoktm> https://es.wikipedia.org/wiki/Madrid has an example in the infobox ... 11:36:53 <Krinkle> mw.loader.findReady('oojs-ui-widgets') 11:36:53 <Krinkle> 0: Array [ "ext.kartographer.dialog" ] 11:36:57 <Krinkle> oojs-ui-core as well 11:37:17 <Krinkle> and -styles, and -windows 11:37:22 <Krinkle> that's half a meg or so 11:37:44 <legoktm> ohhh 11:38:11 <Krinkle> findReady is my custom script. mw.inspeect() is another way to see it more easily 11:38:28 <Krinkle> the top 10 largest modules on that page are mapbox and ooui modules 11:39:22 <Krinkle> anyway, perhaps kartographer could be improved to be more usable from its static version. e.g. HiDPI and feeling more interactable. I'm assuming the community vote came from it not being clear that the feautres are available, it feels too indirect. 11:39:29 <Krinkle> good reason for product to think about :)
I agree that it makes more sense to figure out what specific features are wanted in static mode and implementing them in a performant manner rather than disabling it altogether.
(I don't have an opinion on whether this should be open or declined, I think the underlying request of better features is valid, but the implementation still needs work on the MW side)
If I understand the community argumentation well, one of the primary reasons this was desired, is because static map generation is a bit buggy. They point specifically at T269984: Defective static thumbnail, generated in page preview using an empty GeoJSON layer, is cached for long time after saving
As only Wikipedia seems to use static maps and the sister sites don't, they reasoned it wasn't critical to have static maps. This of course forgoes the enormous audience size difference that we generally see between Wikipedia and the sister sites, especially on pages like "Barcelona". All that extra JS does matter, even when late loaded.
perhaps kartographer could be improved to be more usable from its static version. e.g. HiDPI and feeling more interactable.
I don't see how. First, it's already HiDPI, and I don't see how to improve interact-ability without something being interactable... but if anyone has particular suggestions.
Change 773883 had a related patch set uploaded (by Krinkle; author: Krinkle):
[operations/mediawiki-config@master] List Kartographer static map exemptions and document+flip default
Note that the static mapframe configuration does not give the performance improvements hoped for above—see T149855: Don't add geojson to livedata for wikis with snapshot on. For example, inspect the es:Madrid article now with a static map thumbnail. Mapbox and other modules are still being loaded, and the wgKartographerLiveData has been loaded (via the document head!).
Were there any performance measurements motivating the eswiki config revert? I ask because I'm curious whether the deployment caused any impact on the client or on the Kartotherian service.
@awight I'm not familiar with the inner workings of this feautre. It sounds like you're saying that the static map rendering feature is not working as I think and that it does not avoid notable UX or performance overhead.
When opening es:Madrid, I see an infobox with a static image that renders right away. I see no heavy JS payload, no white flashes, no downloading and rendering of individual map files. After the page load settles, mw.loader.getState('ext.kartographer.frame') still returns registered (thus not loaded). Calling mw.loader.load() on it results in the aforementioned 350KB payload, an additional 400KB in map tile downloads, and white flashes while a map is being re-drawn.
This suggests to me that the feature is working as intended and indeed having a significant improvement in user experience and performance. This is the reason the feature exists and was enabled on Wikipedia many years ago. This task tracked a request to disable this, which we promptly reverted once the impact and prior decision was remembered and understood. I kept the task open as reminder for me to update wmf-config with a trail for future reference.
@Krinkle , regarding the significant improvement in the performance experience, I'm not saying anything, but regarding the improvement in the user experience I don't agree that it's a significant improvement for the user. Having to open a window, full screen, to consult a map; leaving the narrative or documentary context to place it on the map isn't an improvement, of any kind, in the user's experience. Of course, thi's just my opinion.
Thanks, you're right about the mapbox module correctly lazy-loading--I'm not sure what I was seeing the other day, but I can confirm that the module is not loaded by default for either anonymous or logged-in users. This alone is a huge performance benefit and justifies the configuration.
The only remaining issue is that maps with a lot of inline data are still loaded into JS in the head, which is already tracked as T149855: Don't add geojson to livedata for wikis with snapshot on. See this article which loads JSON.stringify(mw.config.get("wgKartographerLiveData")).length = 94k of map data, which is unused until the user enters the interactive map.
"Having to open a window, full screen, to consult a map; leaving the narrative or documentary context to place it on the map isn't an improvement"
I've heard this argument a couple of time, but I don't fully agree, unless the map in question is significantly larger than our common sizing of side elements (around 220px wide).. No one wants to interactively explore a map the size of two postal stamps either. You look at it, you glance at it, but interacting with it at that size is just a pain, especially on mobile.
I think one of the reasons why ppl come away with this feeling, is that (as I've noticed) on es.wp the map is used in addition to other (manually crafted) maps that already communicate the position of a location. This leaves the 'interactive map' as very much a tertiary addition, where only the 'interactive part' adds any value and not the initial mapframe (unlike with many other Kartographer mapframe usages). I'd argue that in such cases a design like English Wikipedia's, Template:OSM_Location_map might be more suited, which presents a link to open the interactive map just below a static map.
I'd love to better understand how interactive thumbnail maps are used. It's possible that we can improve the static mapframe experience, for example by overlaying an image map that lets the user hover and click on markers.
Change 773883 merged by jenkins-bot:
[operations/mediawiki-config@master] List Kartographer static map exemptions and document+flip default
Marking as resolved for the tasks' original scope and purpose. Making maps better sounds great. Feel free to re-open if I missed a question.
Zooming on the building, and (much less often) interacting with the markers.
Wouldn't it be possible to load the interactive thumbnail when the mouse is over the map or would it load too slowly? On mobile it's useless anyway, as already mentioned by TheDJ.
On :fr, we use the https://fr.wikipedia.org/wiki/Projet:Scripts_et_gadgets/Notices/CarteInteractive gadget to make all maps interactive.