The Local interface

A brief overview of Local's design

Before designing your add-on, it's important to understand how Local is designed, and the context within which your add-on will be used.

Core UI

Local, at it's core, is crafted from a simple idea...that you should easily be able to create and manage your WordPress sites locally. The main navigation separates each core section of the app into tabs at this highest-level. Context deepens inside of these tabs, their specific layouts dependent on their content. This concept is illustrated below.

Local's standard Sites tab

Broader context to the left, narrower context to the right

This rule of "broader context to the left, narrower context to the right," is extended into the main area, which can include multiple levels of navigation and various layouts based on content.

One example is the "Local Sites" tab, which includes a "sidebar navigation" to select a site, and then a "main" section where content is variable. In the screen below, there is a "hero" area with "subnavigation," a two-column layout inside of the subsection selected in the subnavigation, and a "footer."

Local's Sites tab with Notes add-on

Complex layouts

Layouts can easily be more complex to support other types of content. For example, an even deeper-level of sidebar navigation (noted as "tertiary nav") is present within this section of the app.

This pattern is continued sightly differently in the "Connect to Flywheel" tab of Local, where the same "hero" and "subnavigation" are present, but there is no "sidebar navigation."

Key to creating a successful add-on is always thinking about task hierarchy. Are your actions and tasks visually located in the correct place? Is the information clearly communicating its level of importance?


Within Local, there is occasionally the need to create a higher-level of context within a specific state. If the main Local interface is the layer of context tied to actions around Local sites, Overlays help achieve a literal layer of separation between these strictly app-level actions, and those actions that interact with external concepts or files.

Full-width Overlay

We often use a full-screen overlay to enter settings for a new item being created within Local. For example, you can see this when selecting "Create New Site." Since this site does not currently exist, this additional level of separation from the application highlights that something new is being created, and focuses the user on that task.

Once the site is created, it shows up in the Local sidebar, and most further actions are tied into the main Local interface.

Drawer Overlay

Somewhat similarly to the full-screen overlay, when an action integrates with an outside service, but is triggered from a site-specific action, the drawer overlay is used. For example, this view is used when pushing or pulling a site to Flywheel. This is because, while you are interacting with your Local site, you're setting preferences and importing from (or exporting to) an outside service.

Note that each overlay provides a clear way to exit without completing the task within. This is key, as an overlay removes ability to interact with the interface below.


Traditional modality should be largely avoided, except in the few cases when it is appropriate to remove distractions and focus the user on making a decision.

When an additional interaction is required to complete a task, such as selecting where to push or pull a site, or confirming or denying an action, an overlay modal is triggered. These modals are kept as simple as possible, ideally limited to a singular concept required to complete the initial task. Always provide clear ways to both exit the modal, and complete the ask given within them.

Modals should not be used for actions more complex than answering a simple "yes," "no," or simple selection.