"Cached" layer/sublayer visibility settings in WAB 1.3 apps calling AGOL Web Maps - MAJOR BUG?

[BarnabyRockwell]

In apps made with WAB 1.3 (AGOL) and WAB Developer Edition 1.3, zoom level, geographic location, and layer visibility settings are saved in the browser "data cache" (?) across browser viewing sessions.  These settings are maintained even if browser data and memory caches are cleared.  This major change was apparently conceived as a nifty way to allow users to "resume" viewing sessions.

I have an AGOL Web Map with many layers.  These layers have very complex visibility settings for sublayers, sub-sub layers, etc.  These visibility settings were set in the mxds before the services were published.  I have not changed any of those settings in the Web Map.

I noticed today that if a user toggles layer and sublayer visibility in an app in a browser, closes the browser, reopens it, and returns to the app, ALL layer/sublayer/sub-sublayers in the app are TURNED OFF except for the ones which were on when the previous session was closed.  This unfortunate, show-stopping problem occurs in WAB apps generated on AGOL or WAB Dev 1.3 which call the AGOL Web Map.

It appears to me that the visibility settings of ALL layers/sublayers in the app should be saved to the "data cache," not just the settings of the layers which happened to be toggled on when the app viewing session closed.  Or, there should be a "Reset" button in the app which resets it to "factory default" settings in all regards.

This show-stopper of a problem is preventing me from distributing links to WAB 1.3 apps which call AGOL Web Maps.  All WAB 1.2 apps are fine in this regard.

Is this a bug, or is there a simple workaround that would enable a user to reset the app's layer visibility settings to the default (meaning those shown in the Web Map)?

[Anonymous User]

Barnaby,

Yes, precisely. This is a great new feature. Many of our users have requested this actually and so I love the WAB Team added it. But as you mention it needs a 'reset'.  As I proposed, there are two ways they could do this: 1) build a "reset layerlist/extent" button into the Layer List widget or 2) make a new widget, perhaps called the "Memory" widget or something, and it would be a simple toggle button that user can click. In other words a widget that you'd put in one of those 1 through 5 slots below the geocoder, as the dev.  Maybe the widget icon would be green when on, and red when off, or has the words on/off as the icon, or something. And if they click it off it also resets these.

WAB suggestion: ability to configure remembering layers/extent by end user

I will finally get around to submitting this on Ideas as Derek said.

[BarnabyRockwell]

Kevin,

The "remembering" functionality is quite nice, but is ruined (for me) by the auto-toggling of visibilities for layer/sublayers which weren't even touched in the last viewing session.  It looks like a bug to me, and a major one.  All they need is a Reset button embedded in the app by default as I mentioned.  A Reset button would be great in the Layer List as you mentioned.  Or they could just modify the existing Home button to clear the "data cache," resetting extent and all layer settings to default.  Home button is best kept as simply an extent reset, but you could query the user after Home is clicked, asking if the layer settings should also be reset.  Simplest is best IMO.  I don't think a widget is a good idea for this, as it takes up a widget slot for something that should be built in.  But if a widget is all they come up with, I'll take it.

[RyanKelso · Accepted solution]

If I understand it correctly, there is a known bug with the Layer List widget and this new saving of the app state functionality.  It is causing those sublayers of group layers to be turned off.

You can disable the saving of the app's state (extent, zoom level, layer visibility) by commenting out a few lines in the app's MapManager.js file.  This change took care of the bug for me.

Refer to this thread for details on the fix, I think if you pay attention to the posts that were marked helpful and starting around mid-December then you should be able to take care of it!

[BarnabyRockwell]

Excellent, Ryan!!!!  Many thanks for the info and link.

Cheers,

Barnaby

[Anonymous User]

Well, there is also the bug or design decision where if a sublayer is in a group, which is also in a group, the user has to click 3 times to turn on a single layer.  Our users do NOT like this.  To the point that when they see our incredible flagship WAB viewer, they say "I'm not using that. Too complicated."  I am not exaggerating. Now of course, once I convince them to use it by showing them all the wonderful things it can do, they warm up to it. But they are still frustrated with the Layer List having to click many groups to turn one layer on. For example a water line in the Water folder under the Utilities folder. 3 clicks to show it.   The 'fix' for now is I have the groups checked 'on' but not the layers in the group.  This is an ugly hack though because since the groups aren't expanded, they are 'on' when in fact nothing in them is on. I have to train the users about the workflow. This again is a reason why checkboxes should show STATE. (a partial mark for a group with only some layers on inside it, not a binary check on/off but a third state showing a partial 'check' mark i.e. https://css-tricks.com/indeterminate-checkboxes/ )

Users expect very fast response in interfaces these days, which is understandable. People have things to do. They want to get "in" and out of our map viewers, to get some info, then get back to their main work functions, whether it be utilities work, environmental management, traffic engineering or etc. One thing about this, is creating map viewer user interfaces that are simple and intuit what the user wants to do.  To turn a map layer on should not require multiple clicks, too much thinking, or looking at a complex tree to determine why you aren't seeing a layer. The layer list is a very important part of the WAB.  It is perhaps the single most important part. At least for our users and viewers, it in fact is.  I potentially will have hundreds of WAB users effective today and hundreds of thousands, once we deploy it to our public site www.sagis.org as a code foundation. I hope by that time the Layer List and this extent/layer on/off and the Group on/off visibility are addressed. I conducted several training classes so far with dozens of people for our WAB viewer and these Layer List comments here were shared by all the users regarding the Layer List.

[RyanKelso]

Yeah Kevin, I really dislike that kind of stuff.  Controlling the organization and display of our data is as important as any other feature that is being built into WAB and ArcGIS Online.

I'm not sure I understand how you think it "should" work when you have layers inside of group layers inside of group layers.  But I tested this idea in my app and found that I can have any combination of the layers/groups turned on by default, I just have to save it the way I want it in the ArcGIS Online map that gets consumed by the WAB app.

Your description of the problem does sound like the same bug that Barnaby ran into.  So if you haven't looked into it, there is a workaround.  The obvious problem is, you have to disable the saving of the app's state (extent, zoom level, layer visibility) and I see from a previous reply that this is a welcome feature to you.  I guess for now you'll have to decide what is more important to your implementation and then hopefully ESRI will have the issue fixed with the next release, since they are aware of the problem.  I think they also mentioned that they may create a toggleable option for saving the app state, which would be a great addition.  I strongly dislike the feature and even though I've had a couple of users express interest in such functionality, I find it pretty irritating that it was forced on in the latest release without an easy way to control it in the configuration.

[Anonymous User]

Hi Ryan,

Oh I haven't used WAB 1.3. That feature without an Off is a mission-critical road block. We can't go forward until that is resolved. We are on 1.2  Users will inevitably forget which layers were on or off etc and call and I will have to have them clear cache, which may lose things on their other sites they wanted to keep, etc etc.  Without an "Off" and also a "Reset layers/extent"... we can't upgrade.  I suggest an On/Off for remembering layers and extent inside the Layer List. Or a separate 'button' widget, perhaps a red/green icon that says On/Off with some kind of icon that makes sense. (can't think of one for now. Maybe a 'brain' icon for memory? Half kidding)

What I meant by groups is that if I have a water line inside the Water folder inside the Utilities folder, that's 3 cicks to turn on. I just heard about that being a nonstarter from our stormwater people. 3 clicks, forget it, can't use the site.  Now... I 'engineered' a way around it, by having the Groups on by default. BUT this is a BAD interface... because since the Group is not expanded, it is just a check in the checkbox. On.  Well, no...Not all layers in the group are on. But with a simple Check, users may not realize that, and therefore think to expand the group.  THIS issue can be solved with partial state checkboxes.  ESRI needs to add partial state checkboxes to ArcGIS Desktop (ArcMap) and to the JS API and Layer List in WAB.  I say need, because it's really a need. A serious need, which could make a big difference.  It's a universal metaphor in any app.    Indeterminate Checkboxes | CSS-Tricks   Nevertheless even with that, I still believe that Groups should turn on, automatically, if you turn a sublayer inside them on.  Like AGS JS TOC widget. Table of Contents (TOC) Widget for ArcGIS JavaScript API: Examples   If you would like I'll get some screenshots to describe but I wanted to just get it all out in writing here as a brain download.

So, many interface ideas. I have trained hundreds of users on our viewers and these ideas have all been expressed to me many times, so I am speaking not as a developer here but as an end user(s).

Also we'd like ability to do transparency on each sublayer too.  And a pony. A pony for every Esri user. No in all seriousness, we really love the Builder and our users are already doing good things with it.

[BarnabyRockwell]

While some users like the "cached" app state feature, most do not.  Few users need to be returned to the state/extent of the last session, and it confuses people who expect to see the original extent and layer visibility settings, as they have to figure out how to go back to default extent.  And of course, the original visibility settings for all the layer/sublayers in the app are gone, and will remain gone until all cookies are removed.  Disabling the state saving for the app removes these issues.

It is interesting to note that if the LocalLayer (LL) widget is used for a WAB Dev 1.3 app, avoiding AGOL Web Maps, the "cached state" works just for the extent of last session, and original layer/sublayer visibility settings as set in the LL widget config are maintained.  This is how I would expect the "saved state" to work in apps calling AGOL web maps except that it would be better if the visibilities of ALL layers/sublayers in the Layer List would be maintained across sessions.  Of course, the state saving should be optional and configurable in the WAB editing GUI, as I'll bet will be the case in the next WAB update.

[BarnabyRockwell]

Note that a floating "button" for an optional "click to enable saved app state from last session" has already been implemented in AGOL WAB viewers.  It is safe to assume that this excellent new feature will be available in WAB Dev 1.4.  When is WAB Dev 1.4 scheduled to be released?