Filtering Experience Builder ESRI
To improve the appearance of the filters in Experience Builder and reduce the amount of space they take up, you can try the following approaches:
### 1. **Compact Filter Design:**
- **Switch to a Dropdown Filter:** Use a dropdown style for your filters instead of full panels. This can significantly reduce the amount of space the filters occupy.
- **Inline Filtering:** If possible, place the filters inline horizontally instead of stacking them vertically. This can help save vertical space and make the layout look more streamlined.
- **Custom CSS:** If you have access to CSS customization in Experience Builder, you can apply custom styles to make the filter panels more compact and visually appealing.
### 2. **Collapsible Panels:**
- **Use Collapsible Widgets:** Set up your filters in a collapsible panel or accordion widget. Users can expand or collapse the filter options as needed, which keeps the interface clean when the filters are not in use.
### 3. **Tabs for Filters:**
- **Tab-Based Filtering:** Group related filters into tabs. For example, you can have one tab for geographic filters (Region, Chapter, County) and another tab for time-based filters (Year). This will keep all filter options accessible without cluttering the interface.
### 4. **Floating or Flyout Filter Menu:**
- **Floating Menu:** Consider using a floating or flyout filter menu that users can access via a button or icon. The menu can slide out when needed and hide away when not in use, freeing up space on your main screen.
### 5. **Responsive Design Considerations:**
- **Adjust Filter Layout for Different Screen Sizes:** You can set up responsive layouts that change the filter arrangement based on the screen size. For instance, on larger screens, filters can appear inline or in a sidebar, while on smaller screens, they can be hidden behind a menu button.
### 6. **Minimalistic Approach:**
- **Reduce the Number of Filters:** If possible, consider whether all the filters need to be visible by default. You might hide less frequently used filters behind an "Advanced Options" button.
Would you like detailed guidance on implementing any of these approaches in your specific Experience Builder project? I can also assist in setting up the filters in a more compact and user-friendly layout if that would be helpful.
#experienceBuilder
#filters
#exb
Pending List | Custom | Auto Layout
#experienceBuilder #layouts
#custom
#pendinglist
I totally see why this gets confusing, and you're asking the right questions. Let’s break it down to clarify the workflow and why (or when) you might want to use **Custom Mode** versus relying on **Copy and Pending List**.
### The Role of **Auto Mode**, **Custom Mode**, and the **Pending List**
1. **Auto Mode**:
- This mode tries to do the heavy lifting for you by automatically adjusting layouts across different screen sizes. It’s good for when you want a quick, responsive layout that works "well enough" across devices without too much manual tweaking.
- You’re limited in terms of fine-tuning. Things like widget size, positioning, and visibility for each device type (desktop, tablet, mobile) are handled automatically, and any advanced layout control needs to be done in Custom Mode.
2. **Custom Mode**:
- In **Custom Mode**, you gain manual control over the layout for each screen size. You can adjust specific elements for desktop, tablet, and mobile views. This is useful when you need different layouts for different devices. The trade-off is that you can accidentally lose these settings if you toggle back to **Auto Mode**.
- You would use **Custom Mode** when you need to make fine-tuned adjustments that **Auto Mode** can't handle, like resizing widgets, repositioning elements, or hiding/showing specific widgets based on the device.
3. **Pending List & Copying Layouts**:
- When you’re in **Auto Mode** and try to make changes that can’t be applied, Experience Builder puts those changes in the **Pending List**. The **Pending List** reminds you that you need to switch to **Custom Mode** to apply those changes manually.
- If you're in **Custom Mode**, you can **copy the layout** from one device type (e.g., desktop) and apply it to another device type (e.g., mobile) to avoid redoing the layout from scratch. This creates a **second generation** layout that you can adjust as needed.
- **Copying** saves you time by giving you a base layout to start from, which can then be **further customized** for the new device. However, it won't work for all situations since sometimes the copied layout still requires fine-tuning for things like widget sizes, spacing, and visibility.
### When to Use Custom Mode vs. Copying from Pending List:
- **Use Custom Mode** if:
- You need granular control over the layout, and you want each device view (desktop, tablet, mobile) to have its own specific design.
- You’re making changes that **Auto Mode** can’t handle, like advanced positioning, fine-tuning widget sizes, or hiding widgets on specific screen sizes.
- You’re building out layouts that need to look perfect for every screen size, and automatic adjustments just won’t cut it.
- **Use the Copy/Pending List** if:
- You’re mostly satisfied with the layout from one device type and want to reuse it on another device with only minor tweaks.
- You want a faster workflow and don’t want to build each layout from scratch.
- You’re okay with making a few adjustments after copying, but you still need control over certain custom elements.
### How Much Can You Change in Copy/Pending?
- When you copy a layout to another device view, you’re creating a **starting point**. From there, you can:
- Resize widgets
- Adjust positioning (move things around)
- Hide/show specific elements based on the device
- Align or space widgets differently to fit the screen size
- Adjust text sizes, margins, and paddings
However, some device-specific changes might still need **manual intervention**, and that's where **Custom Mode** shines. For example, a mobile layout might require more drastic changes like simplifying the UI (hiding complex elements or stacking content vertically instead of horizontally).
### Why Use Custom at All?
If you only use **Copy/Pending**, you’re still dependent on Auto Mode’s initial decisions, and sometimes it doesn’t handle responsive layouts perfectly. **Custom Mode** allows you to **fine-tune** these decisions, especially when Auto Mode gets things wrong or doesn’t fit your design requirements.
In short:
- **Copy/Pending** is great for speeding things up, but it’s not as flexible for deep customizations.
- **Custom Mode** is for when you need full control over layouts on each device and want to avoid the limitations of Auto Mode.
Does that help clear things up a bit more?
Outputs from widgets
#experienceBuilder
#outputs
In ArcGIS Experience Builder, the "Outputs" section you're seeing in the data selection panel represents the result of actions or processes derived from other widgets or tools within the app. These outputs often come from calculations, queries, or statistics created by other elements in the app, like charts, filters, or data processing widgets.
### Simple Examples:
1. **Chart Widget Output**:
You create a bar chart that shows the total number of fire alarms installed per region. The chart aggregates this data, and the output would be a summary of those total counts per region. You could use this output to populate a list widget showing top-performing regions or any statistics summaries.
2. **Query Widget Output**:
If you set up a query where users can filter the fire alarm data by date, the output of this query is the result of the user’s selection. For example, it might return all installations from 2020 to 2023. The output could then be used to display results in a table or list.
### Fancy Examples:
1. **Dynamic Chart-Driven Filtering**:
Imagine you have multiple linked charts showing various aspects of fire alarm installations—number of alarms, types of homes, and population demographics. The output of these charts (totals and statistics) could then be used to dynamically filter other widgets like a map or table. For example, clicking on a segment of the chart representing senior homes would filter the map to only show locations with senior residents.
2. **Custom Calculations Using Arcade Expressions**:
If you're running custom calculations within widgets using Arcade (a scripting language in ArcGIS), the result of these calculations can be used as an output. For example, if you calculate the percentage increase in fire alarms installed year-over-year, the output could display this trend in a text widget or be used to drive conditional visibility in the app (e.g., showing alerts when the installation rate drops below a certain threshold).
3. **Conditional Actions Based on Outputs**:
You could configure a list or map to trigger different actions based on outputs. For instance, if a user filters the data to show only homes with children, the output from this filter could update other widgets to display child-focused safety information, or open a pop-up with recommendations for child-safe fire alarm installations.
By using outputs effectively, you can create highly dynamic, responsive applications that offer users more control and insights based on real-time data and interactions.
Data Views - Map Instances
#dataviews
#experienceBuilder
#urlparameters
To prevent filters from one page in ArcGIS Experience Builder from affecting charts on other pages, even though the filters are correctly referencing the right chart widget, you'll need to manage the data source and filter configuration more granularly. Here are a few strategies to help:
1. Use Separate Data Views:
- Create separate *data views* of the same map for each page. This way, even though the map data source is the same, each page interacts with its own data view, ensuring that filters applied to one page won't carry over to the others.
- In the data source settings, configure different views for each page and link them to the respective filters.
2. Use Page-Specific Data Sources:
- If you don't want to use data views, another option is to duplicate the data source (if applicable) so that each page has a unique data source. This will ensure that the filters applied to one data source won’t affect another.
3. Widget Action Triggers:
- Make sure that the trigger actions (filter triggers) for your charts are only set to affect the specific widgets on the current page. Check the actions configuration of each filter widget to ensure that the filters are only linked to the correct charts on that page, rather than the global data source.
4. Session Storage for Filters:
- ArcGIS Experience Builder supports using session storage or URL parameters to control which filters are applied at the page level. Consider configuring filters so that they are tied to the URL parameters for each page, allowing them to stay independent from one another.
Try implementing separate data views first, as it's typically the cleanest solution. Let me know if you need help setting up any of these!
If data views haven't fully solved the issue, let's explore a more robust approach to ensure your filters stay isolated on each page:
1. Disable Global Filter Influence
- In ArcGIS Experience Builder, there is a default behavior where widgets connected to the same data source can influence one another across pages. You need to ensure that each filter's actions are strictly limited to the widgets on the current page.
- Double-check that "Filter by Extent" is disabled for both the map and charts unless needed for that page. This can prevent unintended interactions.
2. Custom URL Parameters per Page
- Use URL parameters to control which filters apply to each page individually. Configure the filters so that each page has a unique URL with specific parameters passed into it, ensuring that filters are applied at the page level, not across the entire application.
- This way, the URL for each page will dictate the filter settings, preventing carry-over to the other pages.
3. Action Triggers per Page
- Configure the filter widget's action triggers carefully. Even though you may have connected the filters to the correct charts, it’s possible that some filter actions are still tied globally. Go to the Action tab of each filter widget, and make sure the actions are page-specific and not affecting widgets on other pages.
4. Session Storage for Filter Isolation
- Use session storage to create page-specific filters. This technique involves storing the filter state for each page individually, ensuring that the session (user's interaction state) for one page does not interfere with another. You can use this to maintain isolation, and it will be persistent while navigating between pages in a single session.
5. Script Injection for Custom Behavior (if allowed)
- If you have access to inject custom code in your Experience Builder, you can leverage JavaScript to handle the filter state. This approach could be more advanced but provides full control over filter behavior across pages, ensuring that once a filter is applied on a page, it won’t affect other pages.
Combining custom URL parameters and ensuring action triggers are tightly controlled should give you the cleanest solution without too much extra complexity. Let me know if you'd like a detailed walkthrough on one of these methods!
You're right—when dealing with multiple maps (or different iterations of the same map) in ArcGIS Experience Builder, the challenge of managing filters across pages becomes more complex, especially since the Map Widget doesn’t support embedding map views directly.
Here’s a more nuanced approach that can help mitigate the issue:
1. Use Separate Data Sources for Each Map:
- If possible, create a duplicate of your map in ArcGIS Online or Portal. Even though it’s the same dataset, by having separate map items for each page (e.g., one map for filters, one for timeline, and another for charts), you can completely isolate them.
- This method avoids shared filter states because each map is treated as its own entity in Experience Builder.
2. Duplicate the Data Views:
- If you're already using data views and still encountering issues, duplicating the views with slight variations might help. For instance, create two distinct data views for the same map—one for page 1 (filters) and one for page 2 (timeline). Though tedious, this ensures full separation.
3. Utilize Different Map Widgets:
- Instead of embedding the same map across pages, try setting up completely different map widgets for each page (with the corresponding data view). Even though they use the same underlying data, having independent map widgets linked to different data views may prevent filters from one page from affecting others.
4. Custom Filtering Logic (Advanced):
- If you're comfortable with more advanced configurations, look into custom Arcade expressions or custom JavaScript solutions (if allowed). These can give you more granular control over how filters are applied on specific maps or pages, overriding the default behavior in Experience Builder.
5. Global Filters vs. Local Filters:
- Ensure that you’re distinguishing between global filters and local filters in Experience Builder. Sometimes, filters are applied globally by default. Try to limit the scope of each filter so that it applies only to the local context (the specific page and map view), and avoid affecting other pages or widgets.
While Experience Builder has limitations, these workarounds, especially duplicating the map and using distinct map widgets, should help you maintain control over filters and ensure each page functions independently. Let me know if you'd like any additional details on how to implement these steps!
Why not use Enable Client Side Query. Best practices?
In ArcGIS Experience Builder, "Enable Client Side Query" is a powerful feature, but there are scenarios where it might not be the best option. Here's a breakdown of why and when you might want to avoid using it, along with some best practices:
Why Not Use "Enable Client Side Query":
Large Datasets:
If you're working with large datasets, enabling client-side querying can result in poor performance because the entire dataset is downloaded to the client (i.e., the user's browser). This can lead to longer load times and excessive memory usage, especially if the dataset is extensive.
It can also put a strain on the client device, leading to performance issues such as slow interactions and crashes.
Device Constraints:
Users accessing the application on lower-powered devices (e.g., mobile phones, tablets, older computers) may experience issues with large data loads. This can result in a poor user experience as their device struggles to handle the large amounts of data.
Dynamic or Real-Time Data:
If your data is updated frequently, client-side queries may not be ideal because the user will only have access to the data loaded when the app was first accessed. Server-side queries ensure that users always receive the most up-to-date data without having to refresh or reload the entire dataset.
Security Concerns:
When the entire dataset is loaded client-side, all the data is potentially accessible to the user, even if certain parts should not be visible. This can lead to inadvertent data exposure, especially if you have sensitive data or need to limit what data specific users can see.
Best Practices for Queries in Experience Builder:
Use Server-Side Queries for Large Datasets:
For larger datasets or frequently updated data, server-side queries are generally more efficient. These queries only pull the necessary data based on the filters applied, resulting in better performance and reduced load on the client.
Leverage Client-Side Queries for Small, Static Datasets:
Client-side queries are beneficial for small datasets that don't change often. In this case, loading the data once to the client allows for quicker interactions without re-querying the server.
Pagination for Large Data:
When working with large datasets, consider using pagination (loading a portion of data at a time). This way, the user is not overwhelmed with a massive data load all at once, and the app remains responsive.
Optimize Data Loading:
Use filters, extents, and other constraints to limit the amount of data that needs to be loaded. You can use server-side queries to initially limit the scope of data, and then enable client-side queries for smaller, manageable datasets after the initial load.
Data Sensitivity:
Be mindful of what data should be exposed to the client. If you need to control access to certain data, use server-side queries with user authentication or data permissions to ensure only authorized data is shown.
Consider User Devices:
Think about the devices your audience will be using. For a mobile audience, server-side queries with optimized data loads are typically a better option to maintain good performance across all devices.
Caching and Preprocessing:
If applicable, you can cache common queries or preprocess data on the server to improve performance and minimize repeated heavy queries.
Conclusion:
Client-side queries are not always a bad option but are best suited for smaller, static datasets where performance won't degrade and users don't need real-time updates. Server-side queries are generally more scalable and efficient for large, dynamic datasets. Balancing the two based on the nature of your data and user requirements is key to building performant and user-friendly applications in Experience Builder.
4o
You said:
Why not larger static?
ChatGPT said:
ChatGPT
Even for larger static datasets, using client-side queries in ArcGIS Experience Builder can still introduce challenges. Here's why larger static datasets might not be ideal for client-side querying, even though they aren't changing frequently:
1. Performance Impact on Load Time:
Initial Load Time: When using client-side queries, the entire dataset is loaded into the user's browser at once. If the dataset is large, the time it takes to download all that data can result in a long initial load time. Users may experience a delay before they can start interacting with the app.
Processing Time: Once the dataset is loaded, the browser has to process and render it. For large datasets, this can lead to sluggish performance as the browser processes the data for display and interaction.
2. Browser and Device Limitations:
Memory Consumption: A large dataset can consume a significant amount of memory, which can cause issues on lower-end devices (like mobile phones or older computers). The browser may crash, or the app could become unresponsive if the dataset is too large for the device to handle.
CPU Usage: Processing large datasets client-side requires computational power. This can lead to increased CPU usage on the client machine, making the browser slow and the device hot, especially on mobile or older devices.
3. User Experience:
Responsiveness: The larger the dataset, the slower the app becomes in terms of interactions such as filtering, zooming, or panning the map. Even if the data is static, the user experience can degrade significantly as they try to interact with the loaded data.
Slow Searching and Filtering: If users are trying to search or apply filters, client-side queries on large datasets can result in long delays between user actions and results being displayed.
4. Data Transfer Limits:
Bandwidth Concerns: Even if the data is static, downloading a large dataset to the client may exceed certain network bandwidth limits. Users on slower internet connections may have an especially frustrating experience waiting for the data to load.
5. Browser Limitations:
Limits on Data Handling: Browsers have limits on how much data they can handle efficiently. Loading a very large dataset into memory can hit these limits, leading to errors, crashes, or warnings in the browser.
Compatibility: Different browsers handle large datasets in varying ways, which can introduce compatibility issues across different devices and browsers.
6. Updates and Data Distribution:
App Updates: Even if the dataset is static, any updates or modifications to the dataset or app require reloading the entire dataset when a user revisits the app. This means they might need to download the large dataset again, impacting the overall experience if updates are frequent.
CDN and Caching: Although using a Content Delivery Network (CDN) can help distribute the load, large files may still need to be cached on the client side, which requires storage and impacts performance.
Best Practices for Larger Static Datasets:
Use Server-Side Queries with Caching: Even for static datasets, it’s often more efficient to handle querying server-side and cache the results. This allows the server to deliver just the subset of data the user needs based on filters or extents, improving performance.
Paginate Data: If the dataset is large, consider paginating the data so that only a small portion of it is loaded at a time. This can reduce the memory footprint and improve responsiveness.
Use Extent or Filter-Based Loading: Instead of loading the entire dataset client-side, load only the data relevant to the current map extent or based on user filters. This way, you’re not overwhelming the browser with unnecessary data.
Conclusion:
Even for larger static datasets, it’s better to use server-side queries because they allow for more efficient performance, reduce load on the client’s browser, and improve the overall user experience. Loading large datasets directly into the client-side can cause significant performance issues and degrade the functionality of your application.
Search and Near Me Combo
It all begins with an idea.
Use the search widget to find an address then use the Action “Record Selection Change” of the search widget to populate and trigger the Near Me Tool.
Feature Set Success
It all begins with an idea.
Feature Set Success - For some reason I have had a great deal of difficulty in pulling data from two layers for one pop-up. This was one and only time I got it to work.
/* This is my test to pull features from two different layers - this is the
first time it has worked! */
// Define the FeatureSet for each layer
var layer1 = FeatureSetByName($map, "Wildfires 10,000 acres plus", ["CalculatedAcres"]);
var layer2 = FeatureSetByName($map, "Current Wildfire Incidents 10k+", ["Injuries"]);
// Filter to match the current feature
var wildfire = First(Filter(layer1, "OBJECTID = " + $feature.OBJECTID));
var incident = First(Filter(layer2, "OBJECTID = " + $feature.OBJECTID));
// Extract values from both layers
var acres = wildfire.CalculatedAcres;
var injuries = incident.Injuries;
// Construct the final sentence
return "This wildfire covers " + Text(acres, "#,###") + " acres and has caused " + Text(injuries) +
" injuries.";