layout

80 notes in this subject, read out of this brain and free to use. This is page 2 of 2.

Context region purpose and constraints

The context region informs the current section where a person is located, such as showing ':owner / :repository' for repository pages. It is not a full-path breadcrumb and works alongside local navigation and other in-page navigation components. Custom interactive elements such as dropdown selectors or buttons should not be included in the context region.

Repository context in context region

Repository context in the context region should be represented as ':owner / :repository'. Do not use the context region to show the full page path like ':owner / :repository / Issues'; a selected 'Issues' item in local navigation should provide the complementary context.

Owner context in context region

Owner context (organization or users) in the context region should be represented as a single item ':owner'. Do not use the context region to show the full page path like ':owner / Projects'; a selected 'Projects' item in local navigation should provide the complementary context.

Owned categories context in context region

Objects other than repositories should be represented as sub-items of a category in the context region, such as ':owner / Projects / :project'. Do not display the full page path like ':owner / Projects / :project / Insights'; the page should use local or in-page navigation elements to provide such context.

App footer presence and exceptions

The app footer containing useful links and legal information should be present in all core pages. It remains 'after the fold' in smaller pages to keep focus on main content. Experiences requiring rich interactions, such as manipulating large amounts of data, may opt out of the app footer.

Full page layout type

Full page layouts are the classic page design of GitHub where both content and pane regions appear horizontally centered to the viewport. Page layouts generally limit their maximum width to xlarge (1280px) so content regions do not render paragraphs with too many words per line.

Split page layout type

Split page layouts are suitable for pages with side navigation, filtering, or list-detail patterns. They separate the viewport into two areas, allowing the pane to have an independent scrollable area. The pane region is always flushed to the left; right-aligned flushed panes should not be used as their scrollbar may conflict with the page scrollbar. The content region may have a maximum width and tries to remain horizontally centered if space is available.

Interstitial page layout type

Interstitial pages are used for signing-in experiences, password verification, loading states, or other long operations. They usually have an xsmall (320px) maximum width.

Header region purpose

Headers appear at the top of the page and include a page title alongside optional actions, summary, local navigation, and metadata.

Content region purpose

The content region is used for displaying the main subject of the page. Other regions support the content with additional information, either about or related to it.

Left pane region purpose

The left pane region displays navigation, filtering, or an overview for entities such as users, bots, and apps.

Right pane region purpose

The right pane region displays item metadata, details, and other auxiliary information.

Footer region purpose

The footer region is used to display less important information such as references or links to other pages.

Layout design principles for GitHub

Layout design should strive for focused experience with clean, calm, uncluttered pages. Pages should adapt to smaller screens without loss of functionality with multi-column layouts designed for scenarios where not all columns fit the viewport. Design should leverage existing mental models from GitHub, the web, and other software, using familiar patterns and conventions to create rationally understood experiences.

Visual processing and layout parsing

Humans process visual information by breaking down shapes and colors, parsing colors and textures in parallel while parsing shapes and forms one at a time. Layouts composed of shapes are therefore parsed linearly, so layouts should be organized to create the least amount of friction for users.

Layout consistency and mental models for navigation

People rely on their natural reading order (top-to-bottom, left-to-right in Latin script) and acquired mental models from previous interactions to discover what they are looking for. Consistent layouts throughout the platform allow people to focus on tasks rather than learning new models, helping them navigate with ease and confidence.

Semantic clarity improves accessibility

Constructing a layout that is visually and semantically clear improves how people digest content and aligns with accessible implementation. Assistive technologies such as screen readers and keyboard navigation rely on semantic markup to understand page structure and translate it into accessible interaction.

macOS menu bar placement

On macOS, the GitHub Desktop menu bar sits at the top of the screen, disconnected from the GitHub Desktop window. The system menu bar is used.

Windows menu bar placement

On Windows, the GitHub Desktop menu bar sits directly on top of the GitHub Desktop UI with no separation or ability to disconnect it. The menu bar is custom-designed.

Desktop system-generated UI elements

The following UI elements in GitHub Desktop use system-generated code that has not been customized or styled: context menus, tooltips, dropdowns, and the menu bar on macOS (Windows uses a custom menu bar).

Give your agent this brain