View Types: Sections, Masonry, Panel, and Sidebar

Every one of Lovelace's four views, Start, Office, Climate, Admin, and Diagnostics, needs a genuine layout engine deciding how its cards actually arrange themselves on screen. This lesson covers the four view types Home Assistant offers, Sections, Masonry, Panel, and Sidebar, and which of your five planned views genuinely deserves each one.

What a view type actually controls

A view type genuinely governs one specific thing, how cards flow and resize across the available screen space, nothing about which cards you can use or what entities they display. Choosing the right view type is entirely a layout decision, made once per view, while card type, covered in the next lesson, is a completely separate decision made once per entity or small group of entities within whichever layout the view type provides.

Sections, this course's default choice

Sections organizes a view into genuinely named, clearly bounded groups, each with its own heading and its own internal grid of cards, and reflows those groups responsively between a phone's single column and a desktop's several columns automatically. This view type maps directly onto the grouping work your plan table already did back in the previous lesson, a Climate section, a Lighting section, and so on, each one becoming a real, visually distinct Sections group rather than an abstract note on paper. For exactly this reason, Sections is genuinely this course's default view type for every Home and Admin view built across the rest of this module.

Masonry, quick and considerably less structured

Masonry, Lovelace's original default view type, arranges cards into flowing columns purely by height, packing each new card into whichever column currently has the most free space, with genuinely no formal grouping or heading structure at all. It's fast for quickly testing a handful of cards, but as a view grows past a dozen cards, Masonry's lack of real sections makes it considerably harder to keep organized compared to the same content arranged deliberately in Sections.

Panel, one card at full width

Panel dedicates an entire view to exactly one single card, stretched to fill the full width and height of the screen, genuinely useful for a large history graph, a floorplan-style picture card, or a media player that deserves the whole screen's attention without competing for space against anything else. This view type is deliberately rare across this module, most views genuinely need several cards working together, but it's worth knowing for the occasional entity that truly earns a screen entirely to itself.

Sidebar, a technical layout for dense information

Sidebar splits a view into a narrow side column and a wider main area, letting a persistent navigation or filter card sit alongside the primary content rather than scrolling past it. This view type genuinely suits information-dense technical screens more than everyday household viewing, and while this module doesn't lean on it heavily, it's worth recognizing by name for the day a genuinely complex Admin view might benefit from that same persistent side column.

Where the view type is actually chosen

Opening a view's own settings, reached by its pencil icon in edit mode, reveals a genuinely simple dropdown listing all four view types, switchable at any time without losing the cards already placed inside that view, though Sections' named groups don't carry over automatically if you switch away and back. Because switching is nearly free, it's genuinely fine to try a view as Masonry first and switch to Sections later once you're confident about its actual card count and grouping.

View type versus card type, don't conflate them

It's genuinely easy early on to mix up "what type of view is this" with "what type of card is this," since both use the word "type" and both get chosen from a similar-looking dropdown menu. Keep the boundary clear, a view type decides how cards flow across the whole screen, a card type decides how one specific entity or small group of entities gets displayed within whatever space the view type has given it, two entirely separate layers of the same overall layout decision.

This course's recommendations by view

Start, Office, Climate, and Admin all genuinely use Sections throughout this module, their content is naturally groupable and benefits from clear visual boundaries between concepts. Diagnostics, carried over from Module 12, could reasonably use either Sections or Masonry, this course keeps it in Sections too for consistency, so switching between any of your five views never requires relearning a genuinely different layout behavior.

Mobile and desktop: why Sections genuinely wins

Sections was genuinely designed with responsive behavior as a first-class concern, collapsing gracefully to one column on a phone while spreading sections across several columns on a wider desktop screen, all from one single underlying view definition. Masonry technically also reflows responsively, but without named section boundaries, a Masonry view that looks organized on desktop can feel like an unlabeled wall of cards once squeezed into a phone's narrow single column, exactly the outcome Sections is genuinely built to avoid.

A YAML example: the Office view in Sections with tile cards

A minimal Sections view definition includes a type of sections, a title, and a sections list, each entry with its own heading card and a cards list beneath it, one section for Climate holding the temperature sensor and threshold slider, another for Lighting holding the LED tile. Reading this structure directly in YAML, even if you build it entirely through the UI editor, reinforces exactly how sections nest inside a view, mirroring the vocabulary lesson's dashboard-view-section-card chain in real, working configuration.

What genuinely not to do

Don't use Panel for a view meant to hold several unrelated entities together, and don't default every single view to Masonry purely out of habit once Sections is available and genuinely better suited to nearly everything this course builds. A view type chosen out of familiarity rather than fit is precisely the kind of small early decision that quietly makes a dashboard harder to maintain months later.

An exercise: view type and one sentence of reasoning

For each of your five planned views, write down its chosen view type and one honest sentence explaining why that type genuinely fits, not simply "because the course said so," but your own reasoning connecting the view's actual content to the layout behavior you've just learned. This habit of writing a one-sentence justification, small as it seems, catches the rare case where a view's real content doesn't actually match this course's general Sections-everywhere recommendation.

Column count and how Sections decides it

Sections genuinely calculates how many columns fit based on the screen's actual width and a configurable maximum, meaning a phone reliably gets one column while a wide desktop monitor might comfortably show three or four sections side by side without you ever specifying an exact number yourself. This automatic behavior is precisely why this course leans on Sections so heavily, the same view definition genuinely looks appropriate on every device without a separate mobile-specific configuration, a topic later lessons in this module still explore in more depth for cases where automatic behavior alone isn't quite enough.

Reordering sections and cards without fear

Both sections within a view and cards within a section can genuinely be dragged into a new order directly in the visual editor, with no risk to the underlying entities or automations they display, exactly the same disposability this module's opening lesson highlighted about dashboards in general. Feel free to experiment with a Climate section above or below a Lighting section, moving things around costs nothing but a few seconds and often reveals a genuinely more intuitive order than whatever you first guessed while planning on paper.

Why Panel still earns a place in this course's toolkit

Even though Panel appears rarely across this module's actual views, it's genuinely worth trying once with a history graph of the office temperature sensor, stretched full screen, to feel directly why some content benefits from having zero competing cards nearby. A later lesson on charts revisits this exact scenario, and having already felt the difference between a cramped chart squeezed into a Sections column and the same chart given an entire Panel view to itself makes that later lesson's recommendations considerably more intuitive rather than abstract.

Sidebar's narrow niche, explained a little further

Sidebar's persistent side column genuinely suits a scenario like a filterable device list sitting beside a detailed entity view, letting you click through several devices without the filter itself scrolling out of view each time, a pattern considerably more common in general-purpose admin panels than in a personal smart home dashboard. This course's Admin view stays in Sections instead, since the number of genuine categories, Automations, Helpers, ESPHome, Zigbee, Batteries, Service, is small and stable enough that a persistent filter column would add more visual overhead than it saves.

What can genuinely go wrong

A genuinely common mistake is building an entire view in Masonry, getting comfortable with its layout, and then switching to Sections expecting the exact same visual arrangement to carry over automatically, when in fact Sections requires you to actively define section boundaries the Masonry view never had. Plan to spend a few minutes re-grouping cards into sections immediately after switching a view's type, rather than assuming the switch alone finishes the job.

Revisiting the plan table with view types in mind

Add a genuine view-type column to the plan table built in the previous lesson, now that all four options are properly understood, confirming each of your five views' assigned type actually still makes sense once you've seen every alternative laid out clearly side by side. It's entirely fine, and even expected, for this pass to change your mind about one view compared to your very first instinct, that's precisely what a deliberate second look is genuinely for.

Section headings as a genuine form of documentation

A section's heading is genuinely more than decoration, "Climate" or "Diagnostics" printed clearly above a group of cards tells anyone glancing at the screen exactly what that group is for, without needing to read every individual card inside it first. Writing these headings thoughtfully, matching the exact grouping language already used in your plan table, keeps the dashboard and the notebook describing the same underlying structure in genuinely consistent words, rather than drifting into two slightly different vocabularies over time.

A hands-on exercise: build the Office view in Sections

Set the Office view's type to Sections directly in its settings, then add two empty sections named Climate and Lighting, matching exactly the groupings your plan table already identified for that room. Leave both sections genuinely empty of cards for now, this exercise's whole point is practicing the view-type and section-naming mechanics cleanly, before the next lesson introduces the actual card types that will finally fill them in with real, working entities.

Why this lesson stayed deliberately abstract

Notice this entire lesson discussed layout, columns, sections, and responsiveness, without ever specifying what a single card inside those sections should actually look like, and that's genuinely deliberate rather than an oversight. Separating "how does the screen divide itself up" from "how does one entity get displayed" mirrors precisely the same separation of concerns this course has practiced since automations first split trigger from condition from action back in Module 11, one concept at a time, cleanly layered on top of the one before it.

A closing thought on choosing structure deliberately

Four view types genuinely exist so that different kinds of content can each get the layout behavior that actually suits them, not so that you'd feel obligated to use all four somewhere just because they exist. This course's own heavy lean toward Sections is itself a deliberate choice made for a genuinely specific reason, responsive, named, and consistent across every single view, and recognizing that underlying reasoning is considerably more valuable going forward than simply memorizing "always pick Sections" as an unexamined, thoughtless rule.

One last note on view types across the whole course

As future modules introduce energy monitoring, security, and multimedia, expect this exact same four-type toolkit, Sections, Masonry, Panel, and Sidebar, to keep serving every new view those modules eventually add, since the underlying layout problem these four types solve never genuinely changes even as the entities filling each view certainly will. Trust the same reasoning process walked through here, audience, content shape, and responsiveness, rather than needing to relearn view-type selection from scratch each time a new module introduces a genuinely new category of entity.

Key takeaways

What's next

With every view's layout type genuinely decided, the next lesson surveys Lovelace's built-in card types, tile, entities, button, gauge, history graph, markdown, and conditional, and when each one genuinely fits an entity from your plan table.