WHAT
A splash page is a temporary, pre-map screen designed to inform, orient, or prompt users before they begin interacting with a spatial app. It’s commonly used in public-facing apps, internal dashboards, or data portals where context, legal disclaimers, or user expectations are critical. While it doesn’t carry any interactive spatial logic itself, it plays an essential UX role in setting up the experience.
WHEN
Splash pages are most valuable when your map’s purpose or structure isn’t self-evident. This includes apps that contain policy-driven content, legal constraints, sensitive datasets, or advanced tools. The splash page acts as a bridge between the user’s arrival and the app’s first impression—filtering out confusion and setting a tone of clarity and intention.
The best splash page is one that isn’t needed! Splash screens can be a bad idea for several reasons, particularly in the context of user experience and modern web development:
- They delay user access: Splash screens force users to wait before they can start using the application or website, which can be frustrating, especially if the splash screen is too long or frequently encountered.
- They can be perceived as annoying: For regular users who open the app multiple times a day, repeatedly seeing a splash screen can quickly become irritating.
- They may not serve a real purpose: While they can offer a brief loading period or display branding, users may not always appreciate or need this delay.
- They can hinder accessibility: For users who rely on screen readers or other assistive technologies, splash screens using older technologies like Flash may not be accessible.
- They can suggest poor design: A prolonged splash screen might indicate that the app requires extensive loading or explanations before the UI can be displayed, which could be a sign of inefficient design.
The following list provides examples when a splash page may be necessary:
- The map visualizes policy-relevant data such as zoning codes, voting districts, or environmental impact zones
- The user must accept terms of use, acknowledge data limitations, or agree to a license before continuing
- The spatial content is event-based or temporary, such as natural disaster response or live infrastructure outages
- You’re targeting non-technical users or the general public, and the interface includes multiple layers, filters, or actions
- The map will be embedded in multi-agency platforms or shared across departments, requiring usage boundaries to be defined upfront
WHY
In spatial applications, users often arrive without full awareness of what a map represents or how to interact with it. A splash page can help to eliminates that ambiguity. It frames the map’s purpose, establishes trust, and ensures users know the boundaries—legal, functional, or interpretive—before engaging.
Reasons to implement a splash page:
- Clarifies the intent of the map: especially when visualizing nuanced spatial data like parcel records, utility zones, or health-related metrics
- Introduces data provenance and disclaimers: essential for maintaining transparency when using provisional, model-based, or third-party spatial data
- Defines interaction expectations: explains whether users can pan, search, export, or simply view
- Establishes access controls: particularly important in apps that segment users by department, role, or jurisdiction
- Creates a professional first impression: especially for apps launched in collaboration with government, non-profits, or research entities
HOW
Be intentional in the use of a splash page. Splash pages should be lightweight and quickly dismissible, but thoughtfully designed to communicate essential information. They should not block access longer than necessary and should defer to the map’s performance and loading priorities. As an alternative to a splash page, consider using the landing page.
Implementation guidelines:
- Display once per session, or on first visit—using browser storage or authentication logic
- Contain a short headline, a one-paragraph description, and a clear call to action (“Explore the Map,” “Agree and Continue”)
- Include key metadata: publishing entity, data source summary, timeframe, or contact email
- Optionally include links to deeper documentation, disclaimers, or help guides
- Ensure full accessibility: keyboard navigation, focus order, screen-reader support
- Mobile-responsiveness is non-negotiable—users must be able to dismiss or interact with the page on any device
EXAMPLE
The Watershed Health Viewer, built using ArcGIS Experience Builder, displays real-time water quality data across multiple basins in the Pacific Northwest. Because the app includes provisional monitoring data and uses hydrologic modeling, the landing splash page prompts users to agree to a data disclaimer before entering. It explains that the data should not be used for regulatory decisions and links to the full methodology and metadata. This short interaction prevents misinterpretation while keeping the entry point smooth and informative.