We've made it easy to powerfully integrate your ideas into Local. This section is all about how to craft the best experience around your ideas. Following our standard UI conventions will help ensure your Add-on feels less like an addition, and more like a true part of Local.

The most important step in the Add-on design process is taking the time to define exactly what your Add-on is going to do. What goal is it trying to achieve? What problem is it trying to solve? Who is it for? Once you know the answers to these questions, you can start creating your Add-on with confidence and clarity!

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.

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."

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" tab of Local, where the same "hero" and "subnavigation" are present, but there is no "sidebar navigation."

Overlays

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.

Modals

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.

A natural place for Add-ons is right alongside where you manage your current Local sites. Whether you want to add functionality to an existing tab or create a new one just for your Add-on, we've got your back!

Adding-on to existing UI

Does your Add-on expand existing functionality? Do other controls related to its context exist already in Local? For these sorts of Add-ons, you can easily integrate with the existing Local structure!

Examples of Add-ons inside of pre-existing Local context are the Notes and the Xdebug + PhpStorm Add-ons. Notes is located in the "Site overview" tab, because conceptually, it makes sense for it to be front-and-center, on the first screen you encounter, that happens to be focused on managing high-level site details. The Xdebug + PhpStorm Add-on creates quick access to managing certain site settings, so it makes sense for that control to live in “Utilities.”

Creating new UI

Is your Add-on a standalone concept? Does it need a large amount of space or multiple sections of information to be useful? Then a new tab may be the best place. These tabs should be added to the dropdown underneath the "More" tab inside of a Local site.

Examples of existing Add-ons with their own tabs are Stats and Volumes. These Add-ons have deep functionality that also conceptually stand on their own.

Interaction

Once you know what your Add-on is going to do and where it makes the most sense within the app, you can start to think about how the user will interact with it.

Local is built on the premise of making complicated tasks simple. To achieve this, we work hard to design and build consistent and clear UI focused on achieving goals. To help you create these sorts of interactions, alongside this guide, we've provided various layout and UI components to help build your interface.

Before you even start building, think about which layout best fits your Add-on's goals, which components make the most sense for the goals your user is trying to achieve, and how you can maximize these early decisions to set your Add-on's audience up for success. When in doubt, opt for clarity over complexity!

The "Sites" tab

Your Add-on can integrate with any part of Local, however, the most popular way will be adding on to the "Sites" tab. There are three core layouts within this section that you can use to build your Add-on's interface.

Full-width layout

Full-width layouts are great for disseminating lots of information, containing multiple sections of content, or for rich interactive experiences. Tables, for example, work really well in this layout, as it has the most horizontal space available for columns of information.

Left column layout

Left columns are generally reserved for tabbed navigation.

Right column layout

Whether you're creating an experience inside of its own tab of the site or expanding an existing tab, the right column is great for creating a secondary level of content hierarchy. Due to its relative size, the larger left side will always appear as more important hierarchically, so use a right sidebar for secondary or supplementary content.

The title bar

Regardless of where your Add-on lives, it's important to create context around its functionality. Add-ons located inside of existing views, such as the table view, are naturally more likely to communicate their presence by default. For other situations, such as when placing an Add-on inside a right sidebar column or on its own tab, always use the title bar. This helps not only remind the user what functionality they're seeing, but in the case of an Add-on inside a new tab, it becomes a useful way-finding device.

Responsiveness

Local is responsive, to a point. These are the current interface dimensions.

To get you up and running quickly, we've provided a robust set of components for use in your Add-ons!

Visit our styleguidist documentation for the complete library.