SPLK-1004 Creating a Prototype

Creating a Prototype Detailed Explanation

1. What is a Prototype?

A prototype in Splunk is a mock or preliminary version of a dashboard or report. It’s built to test:

• Layout structure

• Search logic

• User interaction

• Visualization choices

Prototypes are typically shared internally for feedback and iteration before full-scale deployment to production users.

Creating a prototype allows developers and stakeholders to:

• Experiment with ideas

• Validate logic and usability

• Save time by preventing rework after full deployment

2. Elements of a Prototype

A good prototype mimics the real user experience, even if it uses test data or simplified logic. The key components include:

a) Panels

Panels display data in visual or tabular form. They may include:

• Tables (tabular summaries)

• Charts (bar, line, pie)

• Single values (KPIs)

• Maps or custom visualizations

Each panel is linked to a search, which may be a base search or post-processed search.

b) Inputs

Inputs are interactive controls that allow users to dynamically adjust the data shown. Common input types:

• Drop-downs (select host, status, region, etc.)

• Text boxes (enter user ID or search term)

• Radio buttons

• Multi-select lists

• Time pickers

Inputs set tokens (e.g., $status$) that are referenced in panel searches.

c) Base Searches with Tokens

To optimize performance and modularity, prototypes should be built using base searches that are reused by multiple panels.

Example:

<search id="base_search">
  <query>index=web_logs status=$status$</query>
</search>

Panels can then apply post-processing like:

<search base="base_search">
  <query>| stats count by uri_path</query>
</search>

This:

• Reduces repeated data fetching

• Improves dashboard performance

• Keeps logic centralized for easier maintenance

3. Best Practices for Prototyping

Creating a good prototype involves both technical efficiency and user-centered design. Below are the most important best practices.

a) Use Base Searches and Post-Processing

Base searches allow:

• Sharing a single dataset across panels

• Faster rendering (only one search runs)

• Cleaner XML structure

Use base and ref attributes in dashboard XML to separate data gathering from visual presentation.

b) Design with UX (User Experience) in Mind

Good UX makes dashboards:

• Easy to understand

• Visually consistent

• Intuitive to use

Tips:

• Use clear labels and descriptive titles

• Align charts, legends, and tables consistently

• Use color schemes that match your org’s branding

• Group related panels into sections or tabs

c) Use Sample Data When Live Data Isn’t Ready

If your data isn’t fully indexed or finalized yet, use inputlookup to simulate events.

Example:

| inputlookup web_logs_sample.csv

This allows you to:

• Build logic and visuals with mock data

• Test interactions and token behavior

• Share a working demo before data pipelines are in place

d) Keep Logic Simple at First

Start with:

• Basic panels (top errors, active users, request volume)

• Few filters

• Short time range

Then gradually expand based on feedback.

e) Gather Feedback Early

Once your prototype is functional:

• Share it with key users

• Ask about layout, terminology, and usability

• Refine searches, inputs, and visuals before finalizing

Summary Table: Prototyping Essentials

Element	Description
Panels	Tables, charts, single values to display results
Inputs	Drop-downs, text boxes, time pickers for user control
Base Searches	Shared searches reused by multiple panels
Post-Processing	Additional transformations on top of base search results
Mock Data	Sample datasets used before live indexing
UX Design	Clear labels, visual alignment, logical grouping

Creating a Prototype (Additional Content)

1. Token Behavior and Default Values

Tokens are placeholders used in dashboards to pass values from inputs (like drop-downs, text boxes, or drilldowns) into searches, titles, or visual behavior.

Default Token Configuration

Tokens can be initialized with default values to ensure dashboards function correctly on initial load.

Example:

<fieldset submitButton="false">
  <input type="dropdown" token="status" default="200">
    <label>Status</label>
    <choice value="200">200 OK</choice>
    <choice value="404">404 Not Found</choice>
  </input>
</fieldset>

This ensures that:

• The dashboard displays data even before any user interaction

• A consistent experience is provided for all users

Token Scope

• Global tokens: Available across the entire dashboard

• Panel tokens: Scoped to the specific panel

Use depends or rejects to control token behavior per panel.

Submit vs Auto-Refresh

• submitButton="false": Inputs trigger search updates automatically on change

• submitButton="true": User must click a submit button to update panel tokens

Choosing the correct behavior improves usability and performance.

2. Token Chaining (Inter-Panel Interaction)

Dashboards become more dynamic when panels interact through tokens. A common pattern is drilldown-to-token interaction.

Example Workflow:

1. User clicks a row in a table:

<drilldown>
  <set token="clicked_uri">$row.uri_path$</set>
</drilldown>

2. Another panel uses the selected URI:

<query>index=web_logs uri_path="$clicked_uri$"</query>

This enables:

• Interactive filtering

• Multi-panel exploration

• Context-sensitive analysis

Best Practice: Always verify token fallback behavior for empty or invalid selections.

3. Performance Optimization Tips for Prototypes

Prototypes should load quickly and predictably, especially in shared environments.

Recommended Settings:

• Use searchMode="fast" or searchMode="smart" in base searches

• Add sampleRatio=0.1 to test heavy panels with smaller samples

Example:

<search searchMode="fast">
  <query>index=web_logs sampleRatio=0.1 | stats count by uri_path</query>
</search>

• Limit time range to recent data:

earliest=-15m latest=now

• Minimize real-time panels and use static inputlookup where possible for mock data

4. Prototype Review Checklist

Before sharing a prototype, use the following checklist to ensure it's production-ready:

Review Item	Checked
Base searches are reused and efficient	Yes
Inputs are clearly labeled and functional	Yes
No panels show errors when inputs are missing	Yes
Tokens are used properly and reset as needed	Yes
Default time range is performance-safe	Yes
Sample data is removed before production delivery	Yes
Dashboard loads quickly (under 3s target)	Yes

This checklist can be used during peer reviews or sprint demos to validate quality and maintain consistency.

5. Dashboard Studio vs Classic Dashboards (Simple XML)

Classic Dashboards (Simple XML)

• Configuration is text-based

• Supports base search and post-processing logic

• Ideal for SPL-heavy dashboards and technical users

• Easier for prototyping complex token logic

Dashboard Studio

• Visual editor with drag-and-drop functionality

• JSON-based behind the scenes

• Allows absolute positioning, advanced layout, embedded media

• Lacks full support for post-processing base searches as of now

Summary:

Dashboard Studio is best for final polished designs, while Classic XML is ideal for iterative prototyping and advanced SPL control.

Conclusion

When building prototypes in Splunk:

• Focus first on layout and logic using base searches and mock data

• Use tokens wisely, with default values and drilldown interactions

• Optimize performance early, especially for multi-panel views

• Document and test each prototype using a structured checklist