Skip to content

Build your first dashboard

Build your first dashboard

Your first dotBlast dashboard should answer one simple question for the people looking at the screen. What do they need to know right now? Start with that answer, add only the widgets that support it, and test the result on the actual display before you expand.

Target audience: new dotBlast users, workspace admins, and teams setting up their first shared dashboard. Goal: go from signup to a working dashboard on a screen. Key assumption: you have access to a dotBlast account and permission to create dashboards in the workspace.

<screenshot: empty dotBlast workspace with create dashboard button>

1. Create a workspace or open your existing workspace

Sign in to dotBlast and open the workspace where the dashboard should live. If your team already has a workspace, use it instead of creating a duplicate. Dashboards, integrations, and device pairing usually belong to a team or organization, not a personal test account.

Choose a workspace name that people will recognize. For example, use the company name, team name, or location name. If you expect several dashboards, keep names practical: HQ Lobby, Sales Floor, Support Queue, or Engineering Status.

<screenshot: workspace switcher with a selected workspace>

2. Create a dashboard

Select the option to create a new dashboard. Give it a short name based on the audience and location. A clear name makes device pairing and troubleshooting easier later.

Good dashboard names:

  • Lobby Welcome
  • Operations Wallboard
  • Conference Room Schedule
  • Customer Support Queue
  • Daily Team Status

Avoid names such as Test, Dashboard 1, or New Screen. Those names become hard to manage when more devices are added.

<screenshot: new dashboard form with name field>

3. Choose the screen goal

Before adding widgets, write down the dashboard’s job in one sentence. This is not a product setting; it is a content decision that keeps the layout focused.

Examples:

  • “Show visitors what is happening today and where to go.”
  • “Show the support team queue health and shift coverage.”
  • “Show office staff the room schedule, weather, and company announcements.”
  • “Show leadership the key metrics for today’s operations review.”

If the goal has more than one audience, split it into separate dashboards. A lobby screen, a team room screen, and an executive review dashboard usually need different content.

4. Add your first widgets

Add one widget at a time. Start with the most important information, then add supporting context. For many first dashboards, three to five widgets is enough.

Common starter layout:

  • Calendar widget for today’s events or room schedule.
  • Weather widget for local context.
  • Iframe widget for an approved status page, queue, or report.
  • Text or announcement area for a short message.

After each widget is added, preview the dashboard. Check whether the screen still reads clearly from across the room. If a widget requires small text or frequent scrolling, it may not belong on a shared display.

<screenshot: widget picker with calendar, weather, and iframe options>

5. Configure integrations

Some widgets need integration setup before they can show live data. Calendar widgets need access to the calendar source. Weather widgets need a location. Iframe widgets need a URL that can be embedded or proxied through the supported dotBlast path.

Use the integration settings to connect only what the dashboard needs. Avoid connecting broad accounts if a narrower calendar or source is enough. If your organization has approval rules for third-party tools, confirm permissions before adding production data.

For iframe content, test the URL early. Some websites block embedding for security reasons. If the page is blank, use the iframe troubleshooting guide instead of repeatedly changing the dashboard layout.

<screenshot: integration setup screen with calendar and weather options>

6. Arrange the layout for the real display

A dashboard that looks good on a laptop may not work on a TV. Preview the dashboard at the target aspect ratio and screen size. If possible, connect the display before you finalize the layout.

Use larger widgets for the highest-priority content. Keep dense tables, tiny charts, and long paragraphs out of the first version. People usually glance at wall displays while walking, waiting, or working on something else. The dashboard should make the important state obvious.

Check the edges of the screen. Some TVs crop content slightly. Leave enough margin so important labels and controls are not cut off.

<screenshot: dashboard editor with widgets arranged for a 16:9 screen>

7. Preview and publish

Use preview mode to confirm the dashboard renders as expected. Look for missing data, widgets stuck in loading states, overlapping content, and text that is too small. If the dashboard includes time-sensitive data, wait long enough to confirm it refreshes.

When the preview is ready, publish or save the dashboard changes. The exact action may depend on your workspace settings, but the goal is the same: make the display view available for pairing or browser rendering.

<screenshot: dashboard preview mode with publish or save control>

8. Show the dashboard on a screen

For a quick test, open the dashboard display view in a browser and enter full-screen mode. This proves the content works before you configure dedicated hardware.

For a permanent screen, choose a device path:

  • Browser kiosk for the fastest pilot.
  • Raspberry Pi for a low-cost permanent display.
  • dotKiosk or managed kiosk tooling for fleets and remote management.
  • Chromecast or Fire TV for lightweight casting and simple screen attachments.

Pair the device if your display path supports pairing. Pairing helps dotBlast know which dashboard belongs on which screen and avoids relying on a signed-in editor session.

<screenshot: dashboard running full-screen on a mounted display>

9. Validate with the audience

Leave the dashboard running for a day and ask the intended audience what they noticed. Did they use it? Was anything missing? Was anything distracting? A good first dashboard is not the one with the most widgets; it is the one people actually trust.

Make one round of edits after the first day. Remove clutter, enlarge the most useful widget, and fix any data source that was unreliable. Then document the dashboard owner and the device it runs on.

Build one focused dashboard and run it on a real screen before adding more devices. Once the first screen is stable, use the display device guide to choose hardware for permanent rollout.