Arranging elements: stacking, tabs, sidebar and resizing

The storm night that broke the dashboard. Picture a storm response center at two in the morning. Someone built a dashboard with fourteen elements: a map, outage counts, crew lists, a chart of calls by hour, and more. Each element was useful on its own. On the big screen, though, the map shrank to the size of a postage stamp. The count of customers without power sat below the visible part of the screen, where nobody scrolled. The data was right, but the layout hid it. Operators went back to their spreadsheets. This lesson fixes that problem. You already know how to add a map and indicators. Now you'll learn to arrange them so the most important thing on the screen is also the biggest and easiest to find.

What you will learn. Here are the three things you'll be able to do by the end. First, move elements around the layout by docking them next to each other, and stack related elements into tabs so they share one space. Second, add a sidebar and use it to hold selectors and filters, so they stop taking space from the body of the dashboard. Third, resize elements so their size matches how much they matter to the person watching. We'll work through a water main break dashboard for a city utility, and we'll use a little arithmetic to plan the sizes before we drag anything.

How the layout places elements. The dashboard body works like a set of panels that snap together. When you're editing, each element has a handle for dragging. As you drag it over another element, drop zones light up along the top, bottom, left and right edges, plus one in the centre. Drop on an edge and the element docks beside or above the target, splitting that space between them. Drop in the centre and the two elements are stacked in the same space. Think of it like arranging windows on your desktop, where every window snaps to its neighbor instead of floating. You never type coordinates; you drag, watch the highlight, and let go.

Stacking turns elements into tabs. Let's try a worked example on our water main break dashboard. It has a list of open breaks and a bar chart of breaks per repair crew. Both answer the same question: where do the repairs stand right now? So instead of giving each its own panel, drag the chart and drop it in the centre of the list. Now they share one space, and a row of tabs appears above them, one tab per element. The viewer clicks a tab to switch. You've just freed a whole panel for the map. Stacking works best for elements people look at one after another, not for ones they need to compare side by side.

Naming tabs and choosing what to stack. The tab labels come from the name you give each element in its settings. So name them for the tab, not for yourself. "Open breaks" and "By crew" read better than "List element one" and "Serial chart copy". So what belongs in a stack? Good candidates are alternative views of the same thing: a list and a chart of open service requests, or this week's and last week's outage details. Poor candidates are anything the viewer must see without clicking, because a tab hides its content until someone chooses it. Keep each stack to two or three tabs. Past that, people forget what's behind them.

The sidebar holds your selectors. Selectors are the controls that filter the dashboard, such as a dropdown for district or a date range. You'll build them properly in a later course, but it's worth planning where they go now. ArcGIS Dashboards gives you a sidebar for exactly this. You add it from the layout settings, and it runs down the left edge, separate from the body. Selectors placed there filter the elements in the body, without eating into the map's space. You can also let viewers collapse the sidebar, so on a wall screen it tucks away and the map fills the view. The header can hold a few selectors too, which suits one or two quick filters.

One dashboard, three regions. Here's the plan for our water main break dashboard, drawn as a tree. The whole dashboard splits into three regions. The header holds the title and a date filter, so a supervisor can switch between today and this week. The sidebar keeps two selectors: one for the repair crew and one for the district. Then the body gets the map, which is the star, next to a stacked pair: a list of open breaks and a chart of breaks per crew. The list shows by default, and the crew chart sits one click away. Sketching this tree before you open the editor takes two minutes and saves a lot of dragging.

Resize to match importance. To resize, hover over the border between two elements until the cursor changes, then drag. The neighbor grows or shrinks to match. The rule is simple: the biggest element answers the most important question. For an outage center, that's the map. Let's plan the sizes with a little arithmetic. The screen is nineteen hundred and twenty pixels wide, and the sidebar takes three hundred and twenty, so the body width after the sidebar is sixteen hundred pixels, by nine hundred high. The map gets sixty percent of that width, which is nine hundred and sixty pixels. The remaining six hundred and forty pixels form the column for indicators. Divide the height by three, and you get three indicators each three hundred pixels tall. You don't need to hit these numbers exactly; they just tell you roughly where to drag the borders.

Check it on the screens people use. A layout that looks perfect on your laptop may look very different on the wall display in the operations room, or on a field supervisor's phone. On narrow screens, the dashboard stops placing elements side by side and lines them up one under another. The order roughly follows your layout, starting from the top left, but don't take that on trust. Confirm it yourself: make your browser window narrow and wide while viewing the dashboard, and watch what happens. If the phone view opens with a crew chart and the map is five screens down, rearrange until the most important element comes first.

Common mistake: hiding the key number in a tab. Here's the mistake I see most often. Someone runs out of space, so they stack the "customers without power" indicator behind a tab with the crew list. It looks tidy. But during a storm, nobody clicks tabs to look for a number they don't know is there. The executive glancing at the wall screen sees crew names and assumes things are fine. So set one rule before you stack anything: the numbers people must see are always visible. Stack only the supporting views, like detail lists and extra charts. If you're still short of space, make elements smaller or move filters to the sidebar, rather than hiding essentials.

Recap. Let's pull it together. First, dragging an element onto another's edge docks it beside that element, and dropping it in the centre stacks them as tabs, which suits alternative views of the same question. Second, the sidebar and header hold selectors, so the body stays free for the map and the numbers that tell the story. Third, resize so the biggest element answers the most important question, check the layout on a narrow screen, and never hide a must-see number behind a tab. With these three habits, your dashboards will read clearly at a glance, even at two in the morning during a storm.

Your exercise. Before the next lesson, open the dashboard you built in lessons two and three, with its map and indicators. Add a list and a chart of service requests, then stack them into tabs and give each tab a short, clear name. Add a sidebar from the layout settings; it can stay empty for now, since we'll fill it with selectors later. Then resize so the map takes roughly sixty percent of the body width, beside the sidebar, with your indicators in a column next to the map. Finally, narrow your browser window and check that the map or your key indicator still comes first. Next time, we'll save and share it.