Make WordPress Design

Keyboard Shortcuts | Hide comment threads

Proposal: a consistent spacing system for WordPress

Much like a type scale, a spacing system enforces consistency and simplifies decision making for UI design. This post aims to standardize one for WordPress.

What is a spacing system?

Spacing is the atomic element of an overall spatial system. A spatial system includes spacing, grid, and layout. Spacing is the foundation on which the others are built.

A spacing system is simply a set of predefined values and guidelines for how to apply them in the UI.

Show full post

What benefits does it provide?

“The organization of space is key to every great design. Spatial systems, grids, and layouts provide rules that give your designs a consistent rhythm, constrain decision making, and help teams stay aligned.”

Space, Grids, and Layouts by Elliot Dahl
A diagram comparing an interface with no spacing system to one with an 8px spacing system.
Diagram by Elliot Dahl
  • For designers/developers: less decision making and guesswork. Developers can implement designs faster with a shared spacing system.
  • For end users: a more consistent product with better legibility and information hierarchy.

Spacing system proposal

This spacing system is based on the popular 8px grid system. It has become the standard because of how easy it is to work with. Bryn Jackson’s 8-Point Grid post goes over benefits and implementation in detail. I’ll also add that it plays nicely with a 4px grid for typography. Currently, all of the line-heights in the proposed type scale are divisible by 4.

This spacing system was designed to provide just the right amount of options while not being too restrictive.

Name px rem
Grid Unit 0.5 4px 0.5
Grid Unit 1 8px 1
Grid Unit 1.5 12px 1.5
Grid Unit 2 16px 2
Grid Unit 3 24px 3
Grid Unit 4 32px 4
Grid Unit 5 40px 5
Grid Unit 6 48px 6

Alternatively, here is a visual representation:

The spacing system visually represented as rectangles.

By using a naming convention that is based on the actual spacing value, we can make it easier to remember and use. For example, you can remember that “Grid Unit 2” is equal to 16px, as long as you know that 8px is the base unit.

Here’s an example of the spacing system implemented with CSS custom properties:

:root {
    --grid-unit: 8px;
    --grid-unit-05: calc(0.5 * var(--grid-unit)); // 4px
    --grid-unit-10: calc(1 * var(--grid-unit));   // 8px
    --grid-unit-15: calc(1.5 * var(--grid-unit)); // 12px
    --grid-unit-20: calc(2 * var(--grid-unit));   // 16px
    --grid-unit-30: calc(3 * var(--grid-unit));   // 24px
    --grid-unit-40: calc(4 * var(--grid-unit));   // 32px
    --grid-unit-50: calc(5 * var(--grid-unit));   // 40px
    --grid-unit-60: calc(6 * var(--grid-unit));   // 48px
}

This also makes it easy to create exceptions by using something like calc(10 * var(--grid-unit).

I’ve found that abstract naming like t-shirt sizing (lg, xl, xxl, etc.) is not scalable, and arbitrary numerical values can be confusing if they don’t relate to the actual value.

How do you apply a spacing system?

A diagram showing how the spacing values can be applied to UI

Generally speaking, you can apply these values to padding, margin, height, and width. The most commonly used values are divisible by 8 (e.g. 32, 24, 16, etc.). Occasionally, more control is needed over typography, icons, or some elements within a component. For this reason, 4px and 12px have been included.

In his excellent article, Space, Grids, and Layouts, Elliot Dahl describes two methods of applying a spacing system — element first and content first.

  • Element first: in this method, the dimensions of the element take priority over the content inside. For example, the height of a button, text input, or select should all have a fixed value (e.g. 32px). The content doesn’t change the height.
  • Content first: in this method, the content takes priority. Instead of setting a fixed height or width, the content dictates the dimensions. We use a value from the spacing system to determine the padding.

A note on grids

Grids and spacing are tightly coupled. As explained in the intro, grids and layout are composed using a spacing system. There are two types of grids — regular grids and a layout grids.

Regular grids can be thought of as simple graph paper laid on top of your design. They can be helpful when you’re trying to adhere to an 8px spacing system like the one I proposed. You can easily set these up in your design tools (Figma, Sketch). There’s even a simple 8px grid style available in the WordPress Foundation Figma library!

Regular grid from the Sketch documentation

Layout grids are rooted in traditional graphic design and are made up of columns, rows, and gutters. In web design, they are closely related to breakpoints and responsive web design. These can also be set up in your design tools (Figma, Sketch).

Because of the complexity of layout grids and implementing them in WordPress, I suggest we start with the proposed spacing system. Eventually I’d love to see a comprehensive, consistent layout grid in WordPress.

Layout grid from the Sketch documentation

A note on density

Density can be used to change the spacing based on the needs of the interface. Have plenty of room on the page? Use looser spacing. Need to process and take action on large amounts of information? Use dense spacing. I believe there’s an opportunity to create a simpler system to address density consistently.

Right now there are large, normal, and small buttons.

Large, nomal, and small WordPress buttons.
Currently, WordPress has large, normal, and small buttons. You can see that they are very similar.

We can consolidate those sizes into twoNormal and Dense. The current sizes are pretty similar, and it’s not clear when to use each one. Using Normal and Dense has several benefits over the current sizes:

  • Reduces overhead of maintaining button styles and alignment with surrounding elements.
  • Makes it clear when to use each one. Normal is the default, but Dense can be used when space is tight.
  • By using the proposed spacing system, we can increase the tap/click area on buttons and other elements.

If we take that concept a step further, we can apply Density to more than just buttons. We can apply it to text inputs, selects, tables, and more. Here’s a simple example of what we could implement:

An example of density being applied to UI

Implementation

Integrating the spacing system doesn’t need to happen all at once. Start small, and use it as a part of your design process. Adding Sass variables or CSS custom properties will make using this system easier. I also suggest that you change your default “nudge” amount to 8px in the design applications you use (Figma, Sketch).

Lastly, I’ll add that iterative steps are already being taken to address alignment and spacing (e.g. Trac ticket #48420). That ticket from @afercia is a great first step to thinking more about spacing holistically.

Next steps and feedback

Luckily, some parts of WordPress are already using the 8px spacing system, but its use has not been documented yet. Gutenberg is already using Sass variables with 8px values. Next, we should document this system if we decide to proceed. Then we can work on adding variables to both WordPress Core and Gutenberg.

I’ve been using this spacing system with several projects and it seems to be working well. What do you think?

Like the proposal.
Looking forward to the step by step implementation.

For people who are interested, a baseline grid is a common practice in traditional graphic design, but it’s much harder to achieve on the web because of the way line-heights and text boxes are measured.

12_baseline_example

Some design system like Material use a true baseline grid in which things are measured from the baseline of text.

mio-design_assets_1XfS9DMhlPihgJmjRFH7r9OYpLbZJGF6A_type-setting-baseline

Other design systems like Polaris measure from the edge of text boxes.

a58cbc6bc33beb4fadae7b041acf8635-typography@2x

A traditional baseline grid on the web is admirable for smaller projects, but I suggest we work with the web, instead of against it.

Exciting!

If all layout and typography is based on a constant value (8px), would that provide scope to gracefully adapt the scale of the entire experience by simply changing that initial value?

I’m thinking about super-wide screens where additional spacing would add a lot of value. Or perhaps even a personal preference for scale, similar to the Mac OS display option:

Perhaps that’s better left to the browser though… I dunno, I’m just excited! 😀

Yes, if everything is set up to use variables, and if you’re using rems or ems that is possible. Not sure what would be best for WordPress though!

Design meeting notes for Oct 30 2019

These are the weekly notes for the design meeting that happens on Wednesday’s. You can read the full transcript on our Slack channel and find the meeting’s agenda here. You can join the Slack channel by following the instructions in our handbook.

Firstly @karmatosed would like to know if we are all OK with the design meeting time staying at 18:00 UTC in the winter. So far it seems so.

Next, @mapk reports that Gutenberg 6.8 is out with a performance boost and some cool new features. A monthly post detailing the next focus tasks will now also be published, with the post for November Gutenberg dev focus being up. Also, there is news about the efforts to support full site editing with Gutenberg.

@drw158 would like some feedback on a proposal to improve the button design that was merged in WordPress 5.3. Looks like an improvement already, but there are some factors to consider. Good discussion was had, results will be posted in the linked trac ticket.

@itsjonq has done work on designing a page header component, something in the Gutenberg style that could be used by folks using the wordpress/components library.

Finally, @boemedia wonders if there will be any remote contribution at this year’s WCUS. @karmatosed will write a post about that later. Everyone that will be at WCUS in person, have fun!

#meeting-notes

Design meeting agenda for Wednesday 30th October

This is the agenda for the weekly design chat meeting on Wednesday, 30th October 2019, 18:00 UTC.

  • Housekeeping
  • Updates from any specific focuses
  • Discussion
  • Open floor

This meeting is held in the #design channel in the Making WordPress Slack.

Leave a comment if you would like something reviewed, design help or something added to the agenda.

#meeting-agenda

New button styles were introduced in 5.3; a much needed improvement and a great effort to get that merged. Now that those changes are in Core, how can we iterate and improve button styles? I’ve created some ideas for improvement in this ticket. I’d like to receive feedback on it, thanks!

Gutenberg Phase 2 Friday Design Update #38

Happy Friday! Let’s take a look at some of the design updates going on in Gutenberg recently.

Merged

In progress


Get involved

Now’s a great time to get involved. While the work on this project is intense, it’s always important to glean new perspectives from other WordPress users and community members. Just drop into any of the links provided above to read up on the details and contribute.

Thanks for reading, staying informed, and contributing anywhere you can!

#design, #gutenberg-weekly, #phase-2

Design Meeting Notes for 23 October 2019

These are the weekly notes for the design meeting that happens on Wednesdays. You can read the full transcript on our Slack channel and find the meeting’s agenda here.

Updates

Gutenberg updates

There are not many updates on Gutenberg as Gutenberg 6.8 RC will be ready next Monday 28 October, according to @mapk

@karmatosed worked through lots of cleanup on the Tightening Up Project Board, it is a great project for people to get involved.

HelpHub

@estelaris mentioned a post published last week regarding the new design on HelpHub for Home and Category pages. The post had very good comments and the changes were incorporated to the HH Homepage re-designed by the team at WC Valencia, lead by @AnaCirujano. The new design will be based on Valencia’s design with a few details added. You can leave your comments on Figma (if you do not have access, please ask in the Slack #design channel.) The plan is to finalize both the Home and Category pages for mobile and desktop this week and present them to #docs next Monday.

Open Floor

New Type Scale for WordPress

@davewhitley shared his proposal for a new type scale for WordPress. So far he has applied the type scale to 3 screens: posts, settings, and the editor. See images below:

Comparison Posts
Comparison Settings

Comparison Settings caused some discussion due to the type becoming smaller on large sentences.

Comparison Editor

The gifs will be added as comments on the post for more visibility. There were questions as to how other languages would be affected by the type scale, for example in languages with long words like German. One solution would be to make the admin menu a little wider to accommodate other languages, but that is a different discussion.

The type scale, if accepted, would be applied to all the WordPress application: WP Admin, customizer, editor, etc.

Another two feedback points from the post that were discussed:

  1. There is no documentation yet on when or how these styles should be used.
  2. The “label” style which is all caps. Currently, there are headings that use all caps in WP Admin.  The #design team argued against the use of all caps due to accessibility issues. And because we don’t want it to be a blocker for the type scale, it can be removed.

Secondary Button Styles

There have been several discussions about the new secondary button and how it looks too similar to text input styles. This needs to be solved in the future. As of now, @davewhitley is gathering good and bad button examples and input fields on a Figma file. There is also the design systems repo, where people can find examples.

WordPress Design Guidelines

@itsjonq created a new site with design guidelines for WordPress with a GitHub included where you can leave comments or issues. The site has support for internationalization and it may be available for WC Tokyo.

Border Radio

There seems to be a concern that border-radii varies quite a bit. All small interactive UI elements should use the same border-radius, we believe this was the result if fast integration and someone must have missed or not accounted for something.

#meeting-notes

Design meeting agenda for Wednesday 23rd October

This is the agenda for the weekly design chat meeting on Wednesday, 23rd October 2019, 18:00 UTC. @boemedia will be the facilitator for this week.

  • Housekeeping
  • Updates from any specific focuses
  • Discussion
  • Open floor

This meeting is held in the #design channel in the Making WordPress Slack.

Leave a comment if you would like something reviewed, design help or something added to the agenda.

#meeting-agenda

I’d love to talk about this thread in slack: http://wayback.fauppsala.se:80/wayback/20191101162143/https://wordpress.slack.com/archives/C02S78ZAL/p1571336383267500

@jjj brings up some concerns about the various `border-radii` throughout the form elements and buttons.

There has been a lot of feedback around the input and button styles, specifically the “secondary” button style and the default input style looking visually similar. The recent new button and input styles have brought this to light. I’d like help on collecting other examples from other web apps as a starting point for discussion. Can be good or bad examples.

I’d like to share an update on the new proposed type scale. I’m going to share a few examples of the type scale applied to WP Admin. It would also be nice to go through some of the feedback in the post comments.

Gutenberg Phase 2 Friday Design Update #37

There’s a lot of talk about Full Site Editing right now with Gutenberg. Let’s take this opportunity to get caught up on the work that is happening. Initially, Phase 2 was about bringing the editor to various sections within the current WordPress interface (ie. Widgets screen, Menu screen, Customizer), and it still is, but Full Site Editing kind of reverses this by bringing the rest of the site into a single unified editing experience. This is a big project that will take some time, thorough design thinking and collaboration.

Full Site Editing

The future of WordPress was explored in a post recently by Matias Ventura. Key concepts to help shift the editor interactions include:

  • Block areas help organize blocks within a full page, but also differentiates global (navigation, site title, etc.) and local elements (the content).
  • Full-page editing will provide a full view of the site, or various editor views of each Block Area.
  • Entities & Sources explain the way in which global content can be edited, saved, and then displayed across all areas on the site.
An exploration into full site editing

The majority of the work can be found on GitHub under the label, [Feature] Full Site Editing.

  • Editing other content in the block editor [13489]
  • Exploring the editor outside post_content [16281]
  • Adding a default template with post title and content blocks [16565]
  • Custom entity sources [17368]
  • Site block [16998]
  • Block Templates [17512]

Modes

Modes are ways in which people can change the context of their editing experience within Gutenberg. For example, if you’re editing content, the tools available to you in that mode may differ than when editing the layout.

With the introduction of a Navigation mode for keyboard users, and the existing Code Editor mode, it’s important to see how these work within a mode system as well.

An exploration into modes
  • Selecting vs. Editing blocks [17088]

Block Patterns

Block Patterns are layout patterns. These can be full-page layouts with blocks preset in desired well-designed layouts, or they can be partial layout patterns that can be added to various pages.

An exploration into block patterns
  • Block patterns [17335]
  • Suite of post blocks [15623]

Get invovled

Now’s a great time to get involved. While the work on this project is intense, it’s always important to glean new perspectives from other WordPress users and community members. Just drop into any of the links provided above to read up on the details and contribute.

Thanks for reading, staying informed, and contributing anywhere you can!

#design, #gutenberg-weekly, #phase-2

Design meeting notes for October 16, 2019

These are the weekly notes for the design meeting that happens on Wednesday’s. You can read the full transcript on our Slack channel and find the meeting’s agenda here. You can join the Slack channel by following the instructions in our handbook.

Gutenberg

Gutenberg 6.7 was just released. Lots of bug fixes, a few experiments, and button gradients.

@mapk shared priorities for this week, feedback is :

  • Gradients: Theme support, classNames, custom UI
  • Full site editing: Site Title block, rendering engine, temporary template editing UI and start working on the multi-entity saving UI
  • Improvements to the link UI
  • Complex block interactions, which also require improvements to the selection mode, and better drag and drop

Storybook

During the chat @itsjonq brought up a discussion about storybook, which is a UI development environment. It’s a bit dev heavy, but for those interested you can learn more on the Storybook site. Q shared a great example of a date picker.

WP design guide

Q received some wonderful feedback last week about the importance of adding internationalization to the guide. It’s now been updated to support multi-lingual. You can checkout the starter Japanese one.

Anyone who is interested can reach out to become a contributor on the project. Just let @itsjonq know.

Gutenberg version in Core

@mapk would like feedback on whether we should state “Gutenberg version” or “Block Editor” version. Feedback would also be helpful on the best place to put that.

Repurpose ‘Hello World’ post

@nrqsnchz would love feedback on an issue about making a Gutenberg tutorial from the default Hello World post.

Testing WordPress 5.3 Release Candidate

@joyously shared an issue with select dropdown arrows having some visual issues. Slack link. A great reminder that during RC it’s helpful to test as broadly as possible. If you’re able to test that’d be awesome!

#meeting-notes

Design meeting agenda for Wednesday 16th October

This is the agenda for the weekly design chat meeting on Wednesday, 16th October 2019, 18:00 UTC.

  • Housekeeping
  • Updates from any specific focuses
  • Discussion
  • Open floor

This meeting is held in the #design channel in the Making WordPress Slack.

Leave a comment if you would like something reviewed, design help or something added to the agenda.

#meeting-agenda

👋Halloo!

I have an update on my proposal to create a new WordPress Design Guidelines site.

Based on feedback last week, the biggest feature request would be to add i18n support, specifically, to translate pages for WordCamp Japan coming up (if possible).

I just merged an update to the project that unlocks i18n generation of pages 😀

http://wayback.fauppsala.se:80/wayback/20191101162143/https://github.com/ItsJonQ/wordpress-design-guidelines/pull/7

New Design for HelpHub: Home and Category pages

Since WordCamp Europe 2019, the #docs team is leading the update of the Codex now known as HelpHub. As part of the update, a new design was requested.

This is the first post on HelpHub and will cover the HelpHub Home and the Category pages for desktop. In the coming weeks, WordCamp Valencia will work on the mobile versions of the same pages during Contributor Day. Other posts will be added for Article and WP-Version pages, both mobile and desktop versions.

HelpHub Homepage

The old version is set on a grid that presents several design issues like not being able to list all the topics in each category due to space, created strange white blocks due to the fact that not all categories had the same number of topics, and most importantly, the category icon/title was not underlined for accessibility purposes.

  1. The homepage list allows listing all the topics in each category
  2. There is no blank space in between categories due to the number of articles listed

HelpHub Category Pages

  1. The list will allow topics to show on one page (max two pages, if needed) making it easier to find the article needed by the user
  2. The short/long excerpts will not affect the alignment of as seen on the “before” image 
  3. The links are underlined in the title only, instead of having to highlight the entire paragraph, as seen in the “before” image
  4. There will be no weird grid when the number of topics is not a multiple of three

Before we implement the design, we would like to hear your feedback, please leave it in the comments.


If you want to get involved in the design of HelpHub, reach out in the #docs or #design teams Slack channels.

#helphub

Hi @estelaris,

Thank you so much for all the effort. HelpHub needs a lot of design love.

I’m very much favoring the list view for archives instead of grid and love the breadcrumbs.

I do miss category title on category archive. At this moment we can see it only in sidebar. I think, semantically, it would make sense to have it as a page title. Perhaps even including category description.

For the Home page I have similar feeling. Perhaps the blue section with large heading and search bar occupied too big a portion of the page. I can agree with that. But I would still appreciate some form of page title. Especially because it’s under “Support”, together with Forums. “HelpHub” is really working title of the project and won’t be facing any end user parts of wordpress.org.

Everything else looks great to me. Looking forward to see mobile versions and the rest of templates. Dev crew of docs team is eager to start working on this.

Thank you again and keep up 🙂

First of all, congrats, @estelaris! It is good to see HelpHub receiving some design love 🙂

I’m not a designer but I’ll second @milana_cap. For the category archive, I miss the cat title and description. I know it is already in breadcrumb and sidebar but IMHO it makes more sense as a title. Perhaps it makes more sense as an a11y concern too, IDK.

The same goes for the homepage. Including cat descriptions (something we currently have and we’d miss in the new design) would explain things a bit and reduce that everything-is-underlined side effect.

I love seeing the language dropdown there, by the way. Thanks and congrats for this beautiful job!

I agree that page titles are good to have.
I don’t like the Home page having the links all in one line. (It looks like a sentence.) I would prefer to give each its own line, or at least separate from the others, by more than a `|`. That’s a lot of lines, in two directions.

I agree, maybe some CSS Grid and/or Flexbox could help us achieve this with the different number of links per section…

I agree, too.

For Homepage, I prefer ‘usual’ user manual style such as
http://wayback.fauppsala.se:80/wayback/20191101162143/https://www.php.net/manual/en/

  • All articles are structured as like as books
  • Each article per each line with multiple indentation

Left side bar should be has the same one as like as our Handbooks. This is different from Categorized pages. To share my image, please refer migration page candidate list that was organized in such way:
http://wayback.fauppsala.se:80/wayback/20191101162143/https://docs.google.com/spreadsheets/d/1It2w9pEv6X4CzIOFUilN5KnUxT06rI863750hjNdDvs/edit#gid=625788042