Experience Builder Tips and Tricks

I have been asked on multiple occasions for help with registering a custom widget in ArcGIS Enterprise. My answer has always been, "I don't know. My Enterprise is still on 10.9.1." Well, that is changing. We are upgrading to Enterprise 11.3 and now that our testing portal has crossed the threshold into that magic 11.X world that allows for hosting custom widgets, I have hosted some widgets. So, I'm going to walk you through the process and what I learned along the way.

The first thing I did was pull up the official documentation, which was rather good in this case. Ordinarily, I'd drop a link here, but the document is imbedded within Enterprise itself on an internal server. I found it by opening Experience Builder, scrolling down the Insert Widget Pane and hitting the question mark next to Custom. Also, note that the box with the lines on it will take you to the Item Page on your Portal, so if you want to make your own documentation for your custom widget, that would be the way to find it. Nice touch, ESRI.

So we have our recipe, what's on the ingredient list?

• ArcGIS Enterprise 11.0 or higher
• Administrator privileges on your ArcGIS Enterprise
• A web server
• A custom widget
• Experience Builder Developer Edition
• Love (I mean it's not specifically needed for this procedure, but everyone needs love, even if they are too big and brave to admit it. If you are feeling low on your love supply lately, don't be afraid to reach out to someone. More people genuinely care about you than you even know.)

Step One: Prepare Your Server

I'm copying in steps 1-4 on the official guide and chances are, you won't have to do them.

1. Enable anonymous access to the virtual directory that is hosting your widgets.

The hosting location must be anonymously accessible.

 

2. Enable HTTPS.

Enable HTTPS access in your web server to avoid creating mixed content. Experience Builder does not allow mixed active content caused by loading HTTP under an HTTPS connection. In addition, your server should have a valid SSL certificate issued by a certificate authority to establish the HTTPS connection.

 

3. Enable Cross-Origin Resource Sharing (CORS).

Experience Builder runs under your portal domain, which may be different from the domain of the web server hosting your custom widget. You need to enable CORS in the web server so that access from your portal domain is allowed.

 

4. Add a JSON handler to your web server.

Each widget consists of a JSON manifest file that describes widget properties. Some web servers do not recognize the JSON file extension by default. In such cases, you need to add it to your server as a new MIME type at the application level or a higher level. The MIME type should have .json as the file extension and application/json as the MIME type.

At this point, I would like to remind everyone, I am not an Administrator. I'm also way dumber than I appear. I'm just a monkey who's really good at knowing which buttons give me bananas and which ones give me electric shocks. I don't know how to get your server set up if it's not done already. But chances are you, or whoever set up your server, already did all of these things, so you can probably start at the next step and if it doesn't work you will need to change something on your server.

Step Two: Compile Your Widget

This is the step in the process that is probably where most people slip up. Here's a truth that might be hard to swallow, that code you wrote that you worked so hard on, will never actually be used by your final application. The code in the your-extensions/widgets folder runs through a compiler converting it from TypeScript and React into pure JavaScript. It is also minified. This is the actual code your application runs and this is the code you will need to host your widget. So, even if you are just downloading a completed widget from the Custom Widgets Group, you will still need to put it through Developer Edition first.

The other way compiling can go wrong is a version mismatch. Each version of ArcGIS Enterprise has a corresponding version of Developer Edition. For ArcGIS Enterprise 11.3, the corresponding Developer Edition version is 1.14. Experience Builder can run widgets written in earlier versions, but it can't handle widgets from a newer version. And this limitation also matters for what version it is compiled in. So if you have a widget that was written in 1.12 but compiled in 1.15, it will almost certainly fail in Enterprise 11.3, but if you use 1.14 as a compiler, it should work.

Ok, that's what not to do. What to do? There are two ways to get the compiled version. If you've already built a project and hit Publish since putting the widget in your-extensions. It should already be compiled. (Not sure if you need to use the widget in your project, but I don't think so.) If your widget isn't already waiting for you in the client/dist-prod/widgets folder, stop your Client server and run npm run build:prod on that directory. 

Step Three: Deploy Your Widget

Go to ...fileStructure/client/dist-prod/widgets in Windows Explorer and copy the folder containing your widget. Paste that folder onto your web server. Get the full URL to the manifest.json inside that folder. Open up your Enterprise Portal and go to the Content Tab. Click on Add Item and choose An Application, then Experience Builder Widget. Here is where you should enter that URL to the manifest.json. Finish completing the Add Item Wizard. You don't need me to tell you how to do that, do you?

Now, you'll want to Share it with your co-workers. And I encountered something odd on this step. The first time, I hit the big blue Share Button at the top of the Item Page. For some reason, this duplicated my widget both within My Content and Experience Builder. One version was Private and the other was shared with the Organization. On my other widget uploads, I used the Share Edit Button further down the page and didn't get a duplicate. So use the little button, not the big button.

Open up Experience Builder and say hi to your new widget, ready for your whole organization to enjoy.

In Experience Builder (ExB), the Dynamic Content feature within the text widget allows you to create data-driven, interactive content. While it's a powerful tool, it doesn’t yet offer the same ease and flexibility that ArcGIS Dashboards provides—especially for features like dropdown filters.

As someone who values visual impact and quick, insightful data for users, I’ve integrated indicators into many of my applications. Dashboards’ indicators are far more refined and user-friendly compared to ExB’s options. Esri has suggested that the dynamic content in ExB’s text widget could help replicate the functionality of Dashboards indicators. However, after experimenting, I realized the gap is much larger than I expected. A key limitation is the inability to easily filter Dynamic Content—for example, to only show incidents in “City A” or, in my case, monitor a specific tree species in my city.

To address this limitation, I found a simple workaround: build the indicators in Dashboards and embed them into Experience Builder. Below, I’ll share my process using a real-world example from my city’s Tree Viewer.

Our city is actively addressing challenges with Ash trees and wanted an easy way to track the number of Ash trees left in our inventory. My dataset has a field for species, containing hundreds of different tree types. When I tried to create an indicator in ExB to filter for Ash trees, I realized I couldn’t do it directly. Here's how I worked around this limitation.

Step 1: Create Your Indicator in Dashboards

1. Open ArcGIS Dashboards and create a new indicator.
2. Add a filter to isolate the data you want to track. In my case, I filtered for planted trees and every type of Ash tree in our inventory.
3. Configure the indicator to show the count of Ash trees only.
   • Customize the appearance to highlight the key number in an impactful way.

The result? A perfect indicator showing just the data I needed. This was something I couldn’t achieve natively in ExB!

Here’s what my Dashboards indicator looked like:

Step 2: Embed Your Dashboards Indicator into Experience Builder

1. Open your existing Experience Builder project (or create a new one).
2. Add an Embed Widget to your layout.
3. Use the URL option in the widget settings and paste the URL of the Dashboard containing your indicator.

Step 3: Check Sharing Settings

Before you publish your app, ensure your Dashboard’s sharing level matches the intended audience of your ExB app. For example:

• If your ExB app is public, make sure the Dashboard is shared publicly.
• If it’s for internal use, ensure both the app and the Dashboard are shared within your organization.

The Result

Now, my Ash tree indicator seamlessly appears in my Tree Viewer application! Users can see the current count of Ash trees at a glance, with the refined design and filtering functionality of Dashboards embedded directly into Experience Builder.

My first real, released to the world Experience Builder project was called Park Finder. It was designed for the citizens of Arlington to go in click some filters and find out what parks meet their criteria. Let me give you a quick tour and explain a little about how I made it.

In the lower right of the map, is a custom widget for switching between two basemaps made by importing the Basemap Toggle Widget from the Javascript API. At the time I was working on this project, the Experience Builder Basemap Gallery Widget did not exist and the Basemap Tool had too many choices. Plus, there is a simple elegance to how the Basemap Toggle works. Could I have used multiple maps within my Map Widget to achieve the same effect? Yeah, I guess so, but it was easier to just make my own Widget than to configure multiple maps and all the Actions to make it all work. All in all, I'd rate this custom widget as technically reproducible in Online, but it would be nice if it was a standard widget.

Now, let's look at the right side of the screen. Up at the top, there's a search bar, but it's not actually a Search Widget. It's a List Widget, but I've used CSS to hide everything but the search bar. I don't entirely remember why I did it this way, but I think it was mostly about that annoying Results Panel that wouldn't go away after a search. As of a few days ago, that Results Panel is now optional. So, I'll mark that design as functionally replicated in ArcGIS Online.

Moving down the right-hand column, we get to the filters. The first set of filters are tied together with an OR statement and are using geographic labels in the data to filter by area. Down below, we have filters tied together with an AND statement that allow the users to filter by the amenities the parks have. So of course, I needed to use a custom widget to make such complicated filters, right? No, those are just OOTB Filter Widgets. Ok, not quite. I did use some CSS to make the buttons closer together and change the highlighting color when they are selected. But, functionally they are just two Filter Widgets.

Shortly before we went live with this application, someone in the Parks Department asked if the filters could filter themselves as the user made their choices. At the time, the answer was no. And it was deemed too much work for me to make my own filter widget and re-build the entire application around it, so that idea didn't happen. But now, yes, filters can filter themselves. So all-in-all, I wish the Filter Widget had some more design options, but it's at least advanced functionally.

Now, let's look over at the left side of the screen. That List Widget is not a List Widget. It is a built from scratch custom job. Mostly so I could make those little icons that show what amenities each park has. Until we get an option to put a List Widget inside another List Widget, an idea that is never going to happen because it would be an absolute nightmare to code with a billion possible unintended consequences, that isn't going to be possible in ArcGIS Online.

Across the top of the custom list are a set of buttons that sort the list in several different ways. And finally, after all that introduction, we are finally getting to what this post is really about. While I was working on this application, the first version of Near Me was released. The release of this application was actually delayed so I could incorporate Near Me into the design. And then, I didn't. It just didn't work in this design. Instead, I built my own geographic sort, an incredibly complicated process that I never fully got all the bugs out of.

I've written about what I really wanted out of Near Me before and how with later updates, it became possible. If you haven't read that post before, I'm going to need you to do it now. The rest of this post is going to start where that one left off and won't make much since without that context. Go on...I'll be here when you get back.

Ok, you're back. So at the end, I said:

The big downside is that I can't find a way to make my List Widget a list of all parks in absence of a Near Me search.

Well, there is sort of a way around that now. We can put our Near Me Output List into a Sidebar and have it open when the Search Widget is used. The Sidebar would physically cover a second List Widget that contains all the parks. This second List Widget would have been the one displayed when the app opens. The net effect is that the app appears to have one List that handles both all parks and nearby parks. Hey, why did I use the past conditional grammatical tense back there? Did it not work? No, it works. It's a viable build, but it's not exactly the one I stuck with. See after making the one List over the other, I couldn't stop there. I had to test out the filtering filters which exposed a flaw in that design. If the user changes the filters after Near Me does its thing, it won't trigger Near Me again and the List will not match the filtering criteria. So in my final proof-of-concept application, I made it so my Near Me Output List covered the Filter Widgets instead and I have an always displayed "All Parks" (But Not Really All Parks Because Its Affected By Filters) List Widget and a "Closest Parks" List Widget that only shows up when Near Me is triggered. So if you want that single List feel, it will be similar to, but not exactly what I'm about to describe building. And now, after all that secondary introduction, we can get to what you really want, the how to part...

I've already put my Output List into a Sidebar. We'll call this the Output Sidebar. I've also previously wired up a Near Me Widget in an unopenable Sidebar (We'll call this the Near Me Sidebar.) and set it up so Near Me is triggered by the Search Widget.

We'll start making our changes in the Search Widget. In the Action Tab, I have added a Open Sidebar Action to my existing Record Selection Changes Action to open the Output Sidebar. I also deleted the Zoom To Action I previously configured. Apparently, in the last update, a default zoom action was added to Near Me. Having a zoom action on the Search Widget and Near Me was causing a nauseating bouncing effect as the Search Widget first zoomed in then Near Me zoomed back out a bit. In the Content Panel, I scrolled down and opened up the Search Result options to use the new option to turn off the Result Panel. I will be putting the Search Widget under the Output Sidebar later and turning off the Result Panel prevents a visual glitch where the Result Panel clips through the Sidebar.

In the Map Widget, I went to the Style Tab and added 400px spacing from the left and right side of the screen. My map is now centered with space on each side for more stuff. Into the empty area on the right, I dragged a Column Widget. I used the Full Height option and manually set the Width to 400px and gave it a Background color to match my Theme. Then, I hit the Snap To Right button. Next, I used the Duplicate button to copy my Column and used Snap To Left on the new Column. In the right Column, I added a Text Widget to make a heading and a new List Widget to display a list of all the parks.

In the left Column, I assemble a delicious parfait with Text Widgets to make headings, my previously configured Search Widget and two Filter Widgets. 

I set up some filters using our filtering filters trick. And at this point, I must ask you not to judge my "final" application too harshly. This is a proof-of-concept, not a real application. There are design choices I would not make in a real application. I haven't even looked at anything but the Desktop view. And most glaringly, my data isn't really configured to take advantage of the filtering filters properly.

Almost done, I promise. Go to the Output Sidebar and set the Size to 400px, Overlay on, Resizable off, Default State Collapsed and Collapse Button off. I also gave the Left Panel a Fill color to match our Theme. This prevents the Output Sidebar from being see-through and showing the filters below. With these options set, there will be no way for the user to interact with the filters while looking at the Output List, preventing the inaccurate data issue discussed above.

Ok, so the user has set their filters and typed their address in the search bar. The nearby parks have been found by Near Me and sent to the Output Sidebar that is no preventing them from changing any more filters and now what? They're stuck. There's nothing more they can do with this application. So, let's give them a Button to close the Output Sidebar and get back to the controls.

Temporarily drag the Output List out of the Left Panel of the Sidebar Widget and drop a Column Widget in its place. Make the Column Widget Full Size. Add a Button Widget and another Text Widget for a heading into the new empty Column and drag the List Widget back inside. In the Button Widget, go to the Action Tab and Add A Trigger > Button Click > Output Sidebar > Toggle Sidebar. You'll also want to give your Button a meaningful Text value.

All this is to say, Experience Builder has come a long way in the last 18 months. Maybe it's not easy or intuitive, but there is a viable no-code path to re-creating an application that took some serious coding not that long ago. So, has ArcGIS Online caught up to Developer Edition? No, not really and it never really will, but the fact that it's a question is seriously impressive.

Back in June, when ArcGIS Online was last updated, I went through the update notes and wrote about what I thought were the most impactful changes to Experience Builder and what you might be able to do with them. Well, you guys seemed to like that, so I guess this is a regular feature now. As before, I will not try to document every change. If you want that, the official What's New Page is here. And I have done very little testing, so don't blame me if something doesn't work the way I say it does.

Honestly, I feel a bit underwhelmed by this update, which is weird because this update contains five of the most commonly requested updates on the Ideas board (and maybe a small something from one of the Ideas I posted): text support in the Draw Widget, Express Mode for making app creation simpler, users can build their own SQL queries in the Filter Widget, starting an Edit session from a popup, and de-selecting a feature with Zoom To on can un-zoom. So why am I unimpressed? I don't know. Maybe, it's because Batch Editing got pushed back to the next update. Or maybe, I'm just bitter that ESRI is going to make Experience Builder too easy and put me out of business? I don't get paid for this. That should be a good thing. Anyway, if you aren't seeing your chance at international fame slipping away in front of your eyes, you should be happy about this update.

Action Updates

• Edit Action - This new action allows for starting an edit session from another Widget, including popups in the Map Widget. My understanding of this update is that if you place an Edit Widget in a Widget Controller, editing is turned on and off automatically when the Edit Widget is opened or closed. Last week, @ZachBodenner showed us how to use multiple Edit Widgets to prevent accidental edits, now we can use Widget Controllers to take that idea a step further and make our data even safer from whoopsies.
• View In Table Action - A Table Widget can now target itself, meaning you can select stuff in one Sheet and send your selection to a separate Sheet.
• Some Message Actions now prompt you to select trigger data. - Honestly, I'm still struggling figuring out what this means and how to use it. But I think, it means you can choose for some things to not have a certain Action.
• Show On Map Action - The graphics generated now appear the the Layers Tool and Map Layers Widget, where the user can find them to hide them more easily than that tiny trash can. The tiny trash can still exists as well, but you know maybe it shouldn't, maybe we could design this better, ESRI? The Map Widget also has a new Set As Operational Layers option that will turn them into real boys Feature Layers.
• Zoom To and Pan To Actions - Un-selecting a feature can optionally return the Map Widget to its default extent. Use this with caution: I tried it for a bit and I did not like the way it felt as a user.
• Widgets in the Pending List cannot be targeted for Message Actions. - Should make setting up an application for multiple screen sizes less confusing, but I worry about unexpected behavior if the screen-size changes.

Data Source Updates

• Support for Subtype Group Layers.
• In the last update, the Feature Info Widget got an upgrade that automatically added all the layers from a Map Widget at once, this option is now available in every Widget that would benefit from it.

Express Mode

Instant Apps for Experience Builder. Templates designed to get you from start to finish much faster and easier with a simplified Builder Mode. You can start in Express Mode and then go to the full-featured version if Express Mode isn't enough. Official introduction blog post here.

Style Settings

Borders for the sides of Widgets can be set separately. Want a line between Widgets in a Column? Throw a top and bottom border. No need to mess with a Divider Widget.

URL Parameters

Use URL parameters to select some features and zoom to them. You can select features by id, geometry or with a SQL where clause.

Widget Updates

• Accordion Widget - It's a new. It allows you to stack multiple Widgets into a menu that the user can open up when they need it. Much like musical accordions, design accordions are often hated. Design experts caution against using Accordions as they are not good for accessibility and users frequently do not notice/understand they can be expanded. The general rule of thumb is to never hide vital information inside an Accordion. With that said data-heavy/GIS applications, often need to break general principles of web design to be useful. Use Accordions with caution.
• Basemap Gallery Widget - Add your own basemap by URL.
• Bookmark Widget - More options for how your Bookmarks appear with a reportedly more user-friendly Builder interface.
• Business Analyst Widget - More options for calculating travel times.
• Coordinates Widget - I can't quite wrap my head around what this sentence means, but I pretty sure its important.You can use the new Use transform forward setting to specify whether you want to perform a datum transformation in the forward or reverse direction.
• Chart Widget - So many updates it needs a submenu. If only I had an Accordion...

1. Use the layer symbology to color a chart.
2. Bar and column charts support time binning.
3. Line charts can be continuous or discrete.
4. You can turn off axis labels.
5. You can hide empty data.
6. Auto generated titles that can also be changed manually.
7. Breaking Change Alert!

Additionally, the Chart widget no longer supports using ID fields for statistics other than count. If you have an existing chart that does this, the chart may fail and you should reconfigure the widget.

• Draw Widget - Text!!!!!!!!!!!!!!! With many font choices, the OOTB Draw Widget is now officially a better Write On A Map Widget than my uninvited collaboration with @RobertScheitlin__GISP. (Although, we still have the official widget beat with freehand drawing and post-drawing editing support.) Drawn graphics can also appear in the Map Layers Widget or Tool.
• Edit Widget - Enable Tooltips can be turned on by default. (Could help fill the gap left by the WebAppBuilder Traverse Widget?) Show and edit vertices. (Is that really a new feature? We didn't already have that?)  Hide Edit/Create Features panels to the user if not using them.
• Filter Widget - Users can take control of their own destiny and make their own SQL queries.
• Map Widget - In addition to other stuff mentioned in other places, you can also choose where to dock docked popups.
• Map Layers Widget - Popups can be toggled on/off on a layer by layer basis. Users can turn off popups for that one layer that super annoying and not very helpful, but covers your entire map.
• Near Me Widget - View Related Records in Near Me. Find intersecting polygons. Find features in invisible layers. Cancel slow searches. More Data Action support. Sounds like Experience Builder's most hackable Widget just got even more hackable.
• Query Widget - Query spatially with stuff added from the Add Data Widget.
• Search Widget - Should be easier to set up for new Experience Builder designers, but I paradoxically if you know what you want and what your doing, it seems to be a clunkier building process. Every step through setting up a Search Widget answer I have ever written is now wrong. The Result Panel that covers up half your screen and doesn't hide itself after a search is now optional.
• Text Widget - Additional formatting options.
• Timeline Widget - Increased precision and an option to start with filtering on or off.
• Widget Controller Widget - There are new options for when there are too many Widgets for your Widget Controller Widget to control all your Widgets. They can be scrolled through with arrows or have the overflow compacted down to a single button. Making a Widget Controller one button wide and using this second option could be a valid design choice. The Manage Widgets Panel allows you to make an Accordion within a Widget Controller. It's not mentioned in the What's New document, but the took my advice and added box shadow options to the buttons. I would have preferred that they listened to the border and bigger buttons parts of that suggestion instead. You can also make the icon colors different for every Widget in the Widget Controller. Don't do that. But you can do that.

There it is. My most highlights from the November 2024 ArcGIS Online Experience Builder Update. Have a great day to everybody, except whoever spilled their coffee on the ArcGIS Online servers this morning.

This little trick will help tame some of the complicating features of the new Edit tool and create a safe location for editing small numbers of attributes.

I want to make a tool where users can select one or more counties and easily see the calculated total area. So I added a Text Widget, turned on Connect To Data, found my Counties layer, and switched to the Selected Features View.

With the Text Widget selected, I clicked the stacked circles to make some Dynamic Content. In the Statistics Tab, I select the Sum Operator and the Field containing my area. Every polygon is required to have one, and by default, this usually looks like SHAPE.AREA().

I hit Insert and it works. The user can use the Select Widget or the Select Map Tool to pick some counties and instantly know their area. But, when they don't have anything selected, it looks like this... 

Bad, ugly. We can do better.

Instead of using the Statistics Tab, go to the Expression Tab. And here's the trick, that unlabeled text area above the unlabeled text area where you write your Expression, that's what gets displayed when nothing is selected. So I make my Expression like this...

And here's how it looks when nothing is selected...

I'm just going to put a link here to this epic comment by @fpolia21. Take an Experience Builder project from Developer Edition and register it as an Online or Enterprise Item. Or download it from your Online/Enterprise and edit it in Developer Edition. 

https://community.esri.com/t5/arcgis-experience-builder-questions/deploy-exb-developer-edition-to-po...

I've done something rather silly, but also possibly useful. I'm just going to put this idea out into the world and you can decide if you want to do something with it. I did this more to see if it was possible than being convinced it would be helpful. Combining a Sidebar Widget with multiple Section and Button Widgets, you can build your own version of a Widget Controller.

This method relies on several new features from the ArcGIS Online June 2024 Update, so it is not currently possible in any version of Enterprise. It's a little bit of a brain-melter to set-up. Certainly more of a hassle than using the OOTB Widget Controller. But, I do see the following potential advantages:

• Placing your widgets in a Sidebar might be more aesthetically pleasing in your design than the Panel options provided by the standard Widget Controller.
• Far greater design and placement options for your buttons than the Widget Controller provides. That ugly thing that some of you really seem to like from WAB where all the buttons are different colors, you could do that. Don't do it. But you could do it.
• The ability to open/close multiple related Widgets simultaneously. For instance, the user might want to view both the Map Layers and Legend Widgets at the same time.
• The last ArcGIS Online update brought us an Action to open a Widget in a Widget Controller, but not a Close Widget Action. This method could simulate that missing function.

Some key concepts behind this build:

• A Button Widget placed in a Section Widget can control the Section Widget it is placed in.
• The Set Link Option can control multiple Section Widgets at the same time.
• The Button Widget (and only the Button Widget) has access to both the Set Link Option and the Button Click Action. It can do both simultaneously. 

With all that preamble, let's get into this stupid, maybe useful build.

Step Zero: Add a Sidebar and Map Widget

Add a Sidebar Widget. Set the Default State to Collapsed and turn off the Collapse Button.  You could set the Default State of your Sidebar to Expanded, but you would have to configure the Sections later on so that the default widget is set up to close itself. (That sentence should make sense later.) Removing the Collapse Button is important so that your Actions will not fall out of sync, as they would if the user clicked the Collapse Button. I will also add a Map Widget to the always open side of the Sidebar and connect it to a webmap. The map isn't really part of this build, it and the Widgets in the Sidebar are just here for the aesthetics.

Step One: Make A Button That Can Change Itself

For my demo, I will make a controller for three Sections in the Sidebar: one with a Map Layers and Legend Widget, another with a Basemap Gallery and the last with a Bookmark Widget. I will also make some stylistic choices I wouldn't do in an actual application. I will make my Buttons considerably smaller than the Sections they are in. I will make the backgrounds of the open sidebar views white and the close sidebar views black. (In an actual application, I would make the Buttons fill the Sections and the background colors would be irrelevant.)  I will also make the open widget buttons blue and the close widget buttons red with different text for each. (In an actual application, I would make the color variation much more subtle and no text variation.) I would recommend using some clear visual difference like color or text while you are making and testing this build and then changing the style after you have made sure this works. This will get confusing if you don't leave yourself some obvious hints.

1. Add a Section Widget and make its Fill color white.
2. Add a Button Widget inside the Section Widget and give it the blue Quick Style.
3. Use the Duplicate View Button to copy this View with the Button. Rename View to Open Layers and View 2 to Close Layers.
4. In the Close Layers View, change the Fill color to black and apply the red Quick Style to the Button.
5. In the Content Tab of the red Button, Set Link to a View then select the Open Layers View and change its Text to Close Layer Information. 
6. In the Action Tab of this red Button, add a Button Click > Sidebar > Toggle Sidebar Action.
7. Go back to the Open Layers View and select the blue Button.
8. In the Content Tab, change the Text to Open Layer Information and Set Link to View > Close Layers.
9. In the Action Tab, add a Button Click > Sidebar > Open Sidebar Action.

So that was a bunch of steps and what did we get out of it? A Toggle Sidebar Button that changes its color and text. Worth it on its own? Probably not. What else could you do with a Button that changes its own function?

• Guide users through a specific workflow.
• Guide users through an interactive slideshow, StoryMap-type experience.

Let's keep going and finish making our own widget controller.

Step Two: Add Some Stuff In the Sidebar

1. In the collapsible side of the Sidebar, add a Section Widget and make it Full Size.
2. Make two new Views and rename our Views, Layers, Basemaps, and Bookmarks.
3. In the Layers View, add a Column Widget (for neatness) then put Map Layers and Legend Widgets inside the Column.
4. Add a Basemap Gallery Widget to the Basemaps View and a Bookmark Widget to the Bookmarks View. (I selected the third bookmark template and switched its Direction to vertical.)

We now have some Widgets to control. Now we need to make the buttons.

Step Three: Make The Buttons

1. On the Section Widget, hit the Duplicate button twice. This should make two additional copies of the Section Widget, including all the Views, Buttons and Actions we have already made. 
2. In the new Section Widgets, rename the Views to Open/Close Basemaps and Open/Close Bookmarks.
3. In the Section Widget with the Buttons for controlling the Map Layers and Legend Widget, click on the blue Open Layers Button.
4. Click Set Link and set it with Close Layers, Open Basemaps, Open Bookmarks, and Layers. This set of links should switch the Layer Button to the close Action, get the Bookmarks and Basemaps ready to be opened, and open the Sidebar to the Section containing the Map Layers and Legend Widgets.
5. In the same Section Widget, go to the other View and click on the red Close Layers Button. Ensure that the Set Link is set to Open Layers and all the other Sections are blank. Note: If you have followed along, you shouldn't actually have to do anything on this step. This link should already be made for this View.
6. In the Section Widget for the Basemap Buttons, go to the blue open Button and change the Text to Open Basemaps.
7. Change the Set Link Options to this pattern: the Sidebar Section to the widget you want to open, the Section containing the Open Button to the Close Button View, and the other Button Sections to the Open Button Views.
8. Switch to the Close View and click on the red Close Button. Change the Text to Close Basemaps. In the Set Link Options, set it so that its own Section goes to the Open View and all other Sections are blank.
9. Repeat steps 6-8 for the Bookmarks Buttons.
10. Save. Go to Preview Mode and test. You should be able to click any of these Buttons in any arbitrary order and get a logical response. At any given time, you should see the Sidebar closed with three blue, open Buttons or the Sidebar open with the selected Button in the red close Button state, the correct Widget open, and the other two Buttons in the blue open state.
11. Fix up your presentation. I'm leaving out the details here, but here's how it looks after a little re-design.

I'm sorry if that is the most confusing thing you have ever read. I tried my best. Let me know if you try this out in a real application or one of the other suggestions for a self-controlling Button. Do you have any other uses for a self-controlling Button?

Last week, we took the Experience Builder project from the Make an Impact with Modern GeoApps MOOC from drab to fab. But @AndreaB_ wasn't satisfied with the way the fact that the observations in the Feature Info Widget don't filter by the map extent. And she's right, adding in some Actions could make this app an even nicer user experience. So let's do that.

I am going to set up Actions so that the data in the Table and Feature Info Widgets only show what is currently in the Map Widget. I will be using two different methods, an easy way and a more complex way involving a Data View. We will start with the easy way on the Table Widget.

The Easy Way To Filter By Map Extent

1. Go to the Map Settings Panel Action Tab.
2. Add an Extent Changes > Filter Data Records > Native Vegetation Action. (Native Vegetation is the name of the layer used in the Table Widget.)

That's it. The Table now filters itself every time the Map changes. Let's make it harder on ourselves...

Filtering By Map Extent With A Data View

1. Go to the Feature Info Widget Settings Panel Content Tab.
2. Click Observation. (That is the name of the layer used in this Widget.)
3. Open the dropdown menu under Observation and select Create A View.
4. In the window that pops up, Add A Clause and set it to something that will not filter anything. OBJECTID is not blank should do the job of not doing anything.
5. Change the name of this Data View to Map Extent to clarify why it exists.
6. Apply Changes. Then, open up that dropdown menu under Observation again and select Map Extent.
7. Go back to the Map Settings Panel Action Tab.
8. Click on the Filter Data Records Action I made earlier. Then, click Select Data.
9. Select Observation to add an additional layer to filter. Then, hit the X button at the top of the Select Data Panel.
10. This should bring you to the Action Settings Panel. Under Observation, open the dropdown menu and select Map Extent and de-select Default.

Now, the Feature Info Widget should filter as we zoom around the Map.

Sequel Bait for a Part Three of This Series to be Written Ten Years From Now When ESRI Offers Me More Money Than I Can Refuse and Ruins the Artistic Integrity of My Work

Was there any point to building that Data View? Doesn't it just do the same thing? Why bother with a ten step method when I could have done it in two?

In this application, as it currently is, creating that Data View was a total waste of time. Making my application more complicated than it needed to be and increasing the chances that I messed up somewhere along the way. But now that I've done it, I could add more stuff to my application that doesn't get filtered by the map extent. For example, I could add a List Widget set to the Default Data View of the Observations layer that would show every animal observed with an Action set up to Zoom To that part of the Map.

Until ESRI destroys it, you can see what this version of the app looks like here.

I have been taking part in the Make an Impact with Modern GeoApps MOOC. Overall, it's a great course. Make sure you sign up next time it comes around. The last week is on Experience Builder. I'm sure we are going to make something that works and looks great. It works perfectly well. How does it look?

WHAT DID YOU MAKE ME DO, MOOC?

This is not acceptable for the public facing application, it is supposed to be. I wouldn't even allow this on an internal application. We can do better. We should do better. We must do better.

Look, I am not a designer. I'm barely a programmer. But I have been making websites for a couple years now and I think I'm starting to get the hang of how stuff should look. So with the whole I don't know what I'm doing thing out of the way, let's see if we can make this look better. It's hard to see how we could make it any worse. Let's give this MOOC a facelift. 

First, let's change the Theme. The blue buttons are not doing it for me in this project. The map has a lot of green and project is about nature stuff, so let's make our Primary Color some sort of Army or Forest Green. This project also has a problem with too many fonts. You should try to limit yourself to only one or two fonts on a page. For my Theme font, I will stick with the default, Avenir Next. I am picking this font for two reasons. First, it's a easily readable font and it looks nice. Second, this font is also used in that prominent Feature Info Widget in a place that cannot be changed from within Experience Builder, so if I'm trying to limit the total number of fonts I'm using, it makes sense to match to a font I can't change.

Next, I'll work on the Header. Headers and Footers are intended to be used within multi-page applications to allow you to reuse these elements over multiple pages. If you are making a single page application, DO NOT use a Header. You will be creating headaches for yourself down the line if you do. Use a Row or Fixed Panel Widget instead. The instructions say that this will be a multi-page application, so the Header can stay, but it still needs a makeover.

First, I'll change the Fill color of the Header to my Theme green. Ariel is not a well-liked font by the design community and we are trying to reduce our number of fonts. So, I'll switch my title font back to Avenir Next. There is not enough contrast between my dark green background and the black text, so I make the text white. With a big column of text and the prominent title all on the left side, the visual balance of the page is skewed way too far left and the text is way too close to the edge of the screen. So instead of snapping the Text Widget left, I will snap it right. Actually, I'll give it padding of 2% from the right of the screen. Further along in the design process, if tools and menus get added to the Header, it could go back to the other side. There really should be something else visually interesting, like a logo or buttons, in this Header, but I don't have anything right now, so this will have to do.

Here's what it looks like now and I don't hate it anymore. But, we can still do better.

According to the instructions, I needed to make my Feature Info Widget 530px high, but this cuts off the bottom of all the pictures. With some developer's tricks and experimentation, I found 600px works better. Ideally, you would be using consistently sized pictures and could hone this height precisely so that no pictures are cut-off and there just a little white-space under the pictures, but that is not possible with this set of pictures and may not be practical with real-world data.

Now, let's look at the Bookmark Widget and it's title. There are borders here around both the Text Widget and the Bookmark Widget. Borders are meant to separate one thing from another and here we have two borders, and some white-space effectively making a third border, between a title and the thing it is supposed to be titling. That is going to disconnect these things in your user's mind. Lately, there has been a very vocal group of design advocates saying we should have more prominent borders, but I would vote against that design principle. Borders can be useful sometimes, but everything tends to work together better when you remove borders or make them as unobtrusive as possible. So, I will remove the borders around the Text and Bookmark Widgets and the Feature Info Widget, too. I will also center the text in the Text Widget to get it off the edge of the screen and make it more clear it's a title.

Now, let's address the awkward spacing between everything in this column. Here's how it looked when we got started. The gaps between the Feature Info, Text and Bookmark Widgets are all evenly spaced, so each widget is effectively equally connected to each other, but the relationship here is not equal. The Text and Bookmark Widgets are linked to each other and the Feature Info Widget is not related to the other widgets. There is also the huge blob of emptiness at the bottom.

I was going make some additional changes to this column, but looking at what we currently have, I feel pretty good about it. The white-space under the picture and the change in background color underneath the Feature Info Widget clearly communicate these are two sections without the need for borders and the column is now long enough to fill the entire screen.

...Or is it? Dun, Dun Dunnnnnnnnnnnn!

I've switched my browser to the dimensions of an iPad Pro (large enough to be considered a desktop by Experience Builder, but more square than my widescreen monitor) and the big awkward blank spot came back. One of the biggest challenges in web design is making something that works on every size and shape of screen. Whoever made this design, clearly only built it for the dimensions in the Builder. Live View is fine for testing functionality, but if you want to know how your design will actually look, you need to use Preview Mode at least...Wait, did I say I turned my Windows Desktop into an iPad Pro? How did I do that?

It's time to learn a developer's trick that everyone using Experience Builder should know. In your browser right now, is the power to make your monitor into any device in the world or at least the most common and most unusually sized ones. You don't need any special tools or software you just need to know where to click. The following instructions are for Google Chrome, but the tools are available on all major browsers.

1. Open Preview Mode.
2. Right click anywhere that isn't a map.
3. In the menu that pops up, hit Inspect.
4. In header of the sidebar that appears, click the picture of the laptop and phone in the upper left.

Once you are in this screen use the rectangles at the top to reshape your simulated window to various generic desktop/laptop/tablet/phone sizes or use the dropdown menu to switch to brand name devices. Also, be aware of the rotate button.

Here is where you should go if you really want to know if your design will hold up to different screens. Based on this I know, I still have a problem with 4K monitors and big tablets. So, let's see if we can fix that.

Back in the Build Mode, I switch the Bookmark Widget from a fixed height in pixels to Auto. And when I look at the iPad Pro size now, it looks great. The 4K monitor still has a lot of dead-space, but as it displays the whole Bookmark Widget now, it looks fine. None of the other sizes are broken by this change.

For the Widget Controller, ideally I would remove the background and border from around the Widget Controller buttons and apply borders and/or box shadows directly to the buttons and maybe make them a bit bigger to keep them from blending into the map, but that is not an option in Experience Builder. So this is actually a good place for a border and the grey looks fine, but I will change it to the same dark green of the buttons.

The last thing I will change is the Table Widget. The columns are too narrow. Under Table Options and Column Sizing there is a Fit To Data button, but the data is way too long to fit in any reasonable configuration. But, we at least need to make the column headers fit. Ideally, these columns would have an Alias with shorter, more readable names, but that is not something we can control here. Setting the Column Sizing to Fixed with a Width of 300px is enough space for all the headers and the column controls. Now, I'll drag and resize the Table Widget so that the columns fit.

This Table is only three columns wide, if it were one column wider I could not stand it being in a Widget Controller and I would have to put it in a Sidebar Widget that opens as a bottom drawer.

But why will the user open the Table Widget, there is nothing inviting them to do so. No indication what will happen if they do. Let's give them some subtle encouragement. I add a Button Widget to the Column Widget between the Feature Info Widget and the Text Widget and give it an Action to trigger opening the Table Widget. I'll give this button a title of Explore Habitats. Using strong action verbs on buttons peaks curiosity and encourages user interaction. For a Tooltip, I put Search Data in Tabular Form. This further explains what will happen if the user clicks.

I'll start from the solid dark green Quick Style, but I can't leave it there. Right now, the button is a rectangle extending all the way across my column. It looks more like a section divider than a button. We need to make this button more button-y. In the Style Tab, I set my Width to 90% and use Align Center. The default height of 50px looks good, so I keep it. In the Content Tab, I switch on Advanced. In the Default and Hover Tabs, I set the Border Radius to 20px. This will round the corners of my button. In the Hover Tab, I will give the button a glowing effect when the user hovers their mouse over the button. I set the color to one green lighter than the main button color with a Blur Radius of 10px and a Spread Radius of 2px. Why these values? Because, I messed with them until I liked it.

Here's my final version of this design.

...Or it would be, ESRI Community isn't allowing me to upload another screenshot right now. Until they delete it in a week or two, you can view my application here.