New Experience Builder update (06/2023) - map zoom is jumpy, not smooth.

[TanGnar]

Since the most recent update in Experience Builder (June 2023), my maps in experience builder are very jumpy when zooming. The zoom experience was pretty smooth before the update. It also causes the basemap to flash when zooming. The same map zooms smoothly in Map Viewer.

[Philip_Ohlinger]

This causes another unintended experience, that I couldn't figure out why this was happening until I found this thread. Before this update, using the scroll wheel on the mouse the zoom levels would follow what I have set up for the scales on the basemap. This was nice because when using the print tool, I could set it to "Current Map Scale," and then my prints would have scales that were usable for measuring off of (like 1:1200, 1 Inch=100 ft). Now, when zooming with the scroll wheel, the zoom extents are arbitrary. It no longer keeps the scales of the basemap levels, which make the printing scale useless for measuring off. 

When I use the +/- buttons it keeps the original scale steps. 

Can you please make this a setting to turn on and off at least, to maintain the scale levels? Or allow us to customize the zoom level steps? This makes it difficult to use the map for creating prints with usable scales for measuring.

[JonathanLee]

I read this briefly so I'm not 100% certain this is the same thing but I noticed the zooming with mouse scroll wheel was jarring as well and I think it is also due to the available zoom levels (there are less of them when using scroll wheel).

Strangely, there are more zoom levels when you use the map's zoom widget. Why are these different?

Example: https://experience.arcgis.com/experience/4cd8558f43024d1398bb0071a259d1e6

[AdamGaudet]

I would strongly prefer to not have animations for zooming in/out unless it is very smooth and responsive (like Google Maps, where its zooming animation is in near-synch with a turn of the mouse wheel) and not slow and clunky (like ArcPro, where zooming animation lags (why Esri?) after a turn of the mouse wheel). From a productivity standpoint, the "jumpy" zooms are my preference - I know where I'm going on a map so I don't need an animation to gently place me there. That said, the scale jumps right now are way too large - I don't know at exactly what ratio, but it seems almost 1 to 4 (or at least feels this way), where every turn of the mouse wheel changes the scale ratio by a factor of 4. Personally I think the sweet spot is 1 to 2, where turning the mouse wheel either doubles or halves the scale of the current extent. I'm hoping Esri will fine tune this or at least provide an option for developers to do this.

UPDATE: I just opened and played around with the map in Experience Builder and noticed that the zoom +/- buttons do zoom at a 1:2 ratio when clicked (again, that "sweet spot" zoom ratio), while the mouse wheel zoom was in between a 1:4 to 1:5 ratio which is way too much of a jump - most users will be zooming in/out with the mouse wheel and not the zoom buttons, so I'm not sure why it was designed this way, or if this was unintentional how it slipped past quality control. I know I will have colleagues whom I'm designing these map apps for be complaining about issues like this and how it can grind on their productivity (and they would be right), and all I can do is shrug my shoulders and say "Sorry, it seems like an easy fix but it's something I cannot do". I do expect better because I see this feature as a baseline user experience.

UPDATE 2: It's been a few days from my previous update post and it seems like the zoom ratio has been changed - it looks to zoom more at a ratio of 1:2 (or slightly over?) which again I think is where it should be. Don't know if my post had anything to do with this or it was just a coincidence, but I appreciate the change.

UPDATE 3: Looks like it's back to the 1:4 ratio when viewing these maps in Firefox though 1:2 when in Chrome. Strange.

[Philip_Ohlinger]

I'm still experiencing this issue with experience builder. Zooming in with the mouse wheel zooms at a different step interval than zooming with the +/- buttons in the map. This is only really a problem because I want the print tool to use the zoom levels I had setup for my basemap, so it prints at scales that can be nicely measured off of (1:1200, 1 inch=100 feet). See the attached GIF to see how the zoom levels differ if you are using the mouse or if you are using the +/- buttons on the map. Is there a setting in experience builder to force certain zoom levels?

[BenjamenWetherill]

Can somebody explain how to fix this in Experience Builder?

[ZachBodenner]

As far as I can tell, you cannot fix it. I spoke with an ExB team member at the UC this week and seemed unsure of the reason for it and, hopefully, will be reaching out to me after he looks into it.

[SebastienPelletier]

A bug has been recorded for this problem, I hope it will be fixed in the next update

BUG-000169595 for ArcGIS Experience Builder (esri.com)

[MattiasEkström]

Is there any news to this problem? I agree with @Philip_Ohlinger about problems when printing. But it is also that we use our own basemaps that are cached in certain scales and thats the scales they look the best, they can get a bit blurry when the zooming doesn't follow the maps scale levels.

My users are also used to have the current map scale visible as text, so I've made a widget for that, but that gets messy with scales like 1:857339 instead of 1:400000.

[alex_friant]

@SebastienPelletier - Thanks for sharing that Bug report. I think I kind of figured out why Experience Builder (XB) is screwing things up with Scroll zooming after black boxing this issue.

First, I created a global "Level of Detail" (LOD) layer (shared publicly so you can try) so I could see what standard Level of Detail (0-23) you are between while at any particular arbitrary scale.

Second, if you use that layer in a Map Viewer map, you can see clearly that Map Viewer respects each "Scroll" event as a single LOD step.

Third, if you use that same layer in a map consumed by XB, you can see that XB is doing something different, but what?

To figure that out, I changed my Windows 11 Mouse settings under Scrolling to change the number of "lines" a scroll event would scroll a document from the default of "3" to "1" line.

Back in XB, you can see instantly, while scrolling now, that the LOD has some arbitrary scale steps configured that are much "narrower" than the standard LOD scales. There appears to be about 4 scale steps between each LOD cut off. To be precise, there are exactly 94 scale levels utilized by XB.

If you're using Windows 11 or 10's default Mouse Scroll "3 line" setting, you'll usually end up (depending on where you start) with about 1 or 2 scrolls to change from one standard LOD to the next in XB. But this is not true in Map Viewer! Map Viewer doesn't care what your OS Mouse Scroll Settings are set to - it only looks at whether or not your mouse scrolled once.

The bug, it appears, is twofold:

1. XB has 94 scale steps, not the standard 24
2. XB isn't respecting mouse scrolling events as single LOD step changes like Map Viewer does, rather XB is receiving its scrolling events from the "# of lines" setting in the OS (or mouse driver).
   1. (The following is speculation) This difference between Map Viewer behavior and XB behavior is probably due to Map Viewer JavaScript listening to 'scroll' events, and XB is listening to 'wheel' events and having the setting "event.deltaMode === 1", which has the app listen to the OS settings.

[ZachBodenner]

That's some awesome investigation!