nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Trouver plus de publications taguées avec

ArcGIS Online

Accepted answers

Anonymous User

@TanGnar Thanks for your help. I get what you meant now. We need to use decimal zoom level to

get the best real-time extent synchronization of multiple maps for the recent release.

All comments

ZachBodenner

That's some awesome investigation!

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:

XB has 94 scale steps, not the standard 24
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.

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.

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)

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.

BenjamenWetherill

Can somebody explain how to fix this in Experience Builder?

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?

ExperienceBuilderZoom3.gif

Print Screen Shot 1.jpg

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.

ZachBodenner

I'm experiencing the same thing and I really miss the animation/stepped zoom in by scale that still occurs with the zoom buttons but not the mouse wheel. Is there a setting in the downloaded files from developer edition that can switch this back at all?

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

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.

TanGnar

That's it right there, you nailed it. So previous to the update, ExB zoom included the animation, which I think is a nicer user experience, and seems to be kept in place for Instant Apps. The 'jumpy' is indeed the un-animated zoom between levels. Is there a reason ExB needed to use decimal instead?

iSpring

Hi @TanGnar For the above app, I don't feel obvious jumpy experience.

Before 06/2023 update, zoom level in ExB MapView was an integer, which caused animation during zooming. This is consistent with MapViewer behavior.

After 06/2023 update, the zoom level in ExB MapView is decimal, which results in no animation effect during zooming.

I create two demos with the above web map and pure JS API to show the difference.

zoom without animation (ExB behavior)
- https://codepen.io/Qun-Sun/full/JjeEBzG
zoom with animation (MapViewer behavior)
- https://codepen.io/Qun-Sun/full/ZEmLwOK

So I am not sure if the jumpy experience that you say is referring to the missing animation of map. Could you try the above two apps and tell me your experience ?

Thanks

JianxiaSong

@TanGnar , thanks for sharing the app.However we could not see the problem in Chrome with a mouse on Mac. Could you please contact Esri Support?

TanGnar

Hi @Jianxia, sure, here is a public app where using the scroll wheel on a mouse produces a jumpy experience.

https://experience.arcgis.com/experience/368c6b8ebc164f21877eda6aa3aa4fcf/page/fishing/

Zoom in and out buttons zoom smoothly, however. All is smooth on mobile. So really it's a scroll-wheel thing, I guess. Issue exists in Chrome, Edge, and Firefox.

Another issue that may or may not be related... when I hover my list now (same app), it flashes each list item. Sometimes you can see the underlying list markup (e.g. {field_name}). Hovering the list did not used to produce that effect.

Thanks!

JianxiaSong

@TanGnar could you provide a reproducible sample while contacting Esri Support to help us investigate it?

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.