Weeklog for the 43th week (Monday, October 25 – Sunday, October 31)
Here’s a review of some of the things I worked on during the past week.
Background editor improvements
I finished a draft for the post for the Background editor exploration that Channing and I worked on a while ago. We’ll probably publish it this week, but there’s a copy in that Figma file that you can read now.
I also created three walkthroughs that explain the concepts and ideas of that exploration. Click on each of the following images to launch the prototypes.
Sidebar inspector
I also continued my exploration of the Inspector sidebar components. My goal is to document and extend the work that Shaun has done on the Inspector sidebar and make a comprehensive list of all components to simplify and organize the sidebar sections.
Talk for WordCamp España 2021
I finished preparing my talk for the upcoming WordCamp España. It’ll be an extended version of the one I gave at WordCamp Europe about how to start designing for WordPress. The talk is scheduled for this Thursday 4 at 18:15 CET.
Issues
Here’s a list of some of the issues and pull requests I helped with:
Site editor – make it easier to get back to the dashboard #36021
I offered an idea on how to integrate a back button to the WP dashboard from the site editor menu.
Table Block: Add Cell preview to Table Block Placeholder State #35084
I reviewed the PR and designed the responsive versions of the Table block placeholder.
Use SearchControl component inside site editor menu #36011
I helped with a PR to fix the styling of the SearchControl component inside the editor menu.
I also helped with the release of some improvements for the Multi-Entity UI.
Force remount LinkControl when moving between links within same richtext block #34742and Make Link UI inactive if selection extends beyond format bounds or encounters new link #35946
Finally, I reviewed a couple of PRs that attempt to improve the way the LinkControl handles the previews when selecting links.
Weeklog for the 41th week (11th to 15th of October).
In the last week I helped with some minor issues, I continued working on a blog post to explain the Background Editor improvements Channing and I suggested and started preparing my talk for Wordcamp España 2021.
Here’s a review of some other the things I worked on:
I enjoy illustrating articles, and even if the main elements of work are pieces of the user interface and not drawings, these kinds of assignments are always fun and interesting.
I also think that explaining the changes and improvements of a new release and communicating them effectively and excitingly is very important. So I hope I can continue increasing the quality of those posts.
Also, a behind-the-curtains kind of thing that could be interesting to share here is that whenever I create assets for these posts, I avoid using screenshots: I always recreate the UI using the WordPress Design Library. This gives me a lot of control, and I can show exactly what I want however I want.
Improve treatment of custom values in Gutenberg form fields
Kjell created an issue to improve the way we show custom values inside the input fields of the Gutenberg UI. Right now, if a theme uses calc(), min(), max(), etc., to calculate padding or margin values, the input fields will just show an empty element.
I proposed the following designs to indicate that the values behind those fields are being calculated dynamically.
Initially I proposed to include the eye dropper inside of a new header. The header could allow moving the popover around and would present a title to indicate where the color will be used (a background, a link, a placeholder, etc.)
Since there could be places where there isn’t really a title (besides the generic and non-very informative “color”), I offered a second version without the header.
I also added a quick design for the zoom element. The EyeDropper API doesn’t currently support that piece of the UI, so it will probably take some time before we can customize it.
I also worked on a Figma template. I discovered myself replicating the same file structure, linking to the same libraries, and using the same basic components to present the designs all the time, so I decided to create a file that I can now easily duplicate.
This will save me a lot of time setting up projects and help me delivering the designs in a consistent way.
If you want to use it yourself, here’s the Figma file. I’ll continue to evolve it in the future.
In this post I’d like to present an exploration of the Color panel and Color picker and a proposal for their improvement.
This work is based on the designs of the Inspector Sidebar that fellow WordPress contributor Shaun Andrews is currently carrying out. If you haven’t done this yet, I encourage you to read these two posts:
There is also exciting work being done in the context of Global Styles by Matías Ventura (Lead architect of the Gutenberg project) and Pablo Honey (Design Lead at Automattic) that share many of the same objectives and principles. Aligning these projects will be essential to reach a cohesive design and an easy-to-understand & use system.
Before I present my designs, let’s look at the current state of the UI to select colors and then see how the changes I propose could solve several issues.
Here’s a screenshot of an actual Color section that will haunt you at night:
Despite being an extreme case, the evident problems with the previous interface are a product of the underlying solution we have in place.
More realistically, here’s a collection of screenshots that reflect the different kinds of the color UIs:
Depending on the type of block users are customizing, the panel will present more or fewer options. For instance, the Paragraph Block allows changing the text, background, and link colors, while the Separator Block only allows changing the line color.
As you can see in the image above, the general interface presents several problems:
The color panel takes a lot of space and is quite noisy ❶: even when it only presents a single color ❷ there are many distracting elements competing for the user’s attention (like the solid and gradient selector, and the custom color & clear links).
When there are more colors to customize, that amount of elements is multiplied by the number of additional colors. And the problem is compounded when the user selects a gradient, because we present the UI inside the sidebar ❸.
The preview elementisredundant in the expanded sectionand when it gets closed ❹ it doesn’t give helpful information.
The clear button is always visible and clickable ❺, even when you can’t clear anything.
In general, the UI doesn’t scale well (please refer to the cursed image above). Adding more background options (like an image background, or a new kind of gradient) or displaying sets of custom colors, would require a significant effort on design and implementation.
How can we fix this?
In our respective explorations, Shaun and I have been trying to reduce the amount of information that the sidebar displays and moving secondary controls inside flyout menus. We’ve also worked on making the individual controls more compact and easier to read.
Here’s a simple screen with a redesigned color section:
You can read that section as follows:
The text color is blue and can be reverted to its original value.
Links are green by default (we’ll see why there’s a dropdown there in a minute)
Since the color combination could be difficult to read, we suggest a couple of simple fixes.
If one of the items doesn’t have a default image or a color (as it’s usually the case with the Background item), we’ll render something like this:
Contrast this UI with the current one, much more complicated to read because of all the elements fighting for the user’s attention.
Customizing the links
In a past Show & Tell, Shaun wondered how could we offer more ways to customize certain things, like the color of the different states for the links. Here’s where the dropdown I mentioned earlier comes into play:
Users can expand the Links option to show and customize its different states
In the previous image, if users expand the Link item, they’ll be offered a list of states (the names come from the official pseudo CSS classes :link, :visited, :hover and :active, but I renamed :link to default).
If the inner colors are modified, the Link item will show a list of colors:
We show the colors for the different link states (grouped by color)
This is similar to the collapsed state for the color section, but since the context is more specific here, it’ll be more helpful for the users.
Picking colors
When the user clicks on a color, a color picker will appear beside the sidebar:
Here’s a breakdown of its different elements:
The section at the bottom of the color picker contains two collections: Themecolors and Customcolors. Users can save colors using the plus sign from either collection (but the colors will be always added to the custom one). After doing that they’ll be offered an input field to name the color.
We could use a name color API to suggest an initial value (although those libraries usually only contain English words). If that were difficult to implement, we could simply insert the word “color” plus a consecutive number.
Allowing users to define and manage their own palettes could be a great feature for users. This idea is also present in the Global Styles Interface.
The dropdown at the top of the menu, allows changing the type of background, and it’s also a new component:
Three iterations of the type selector
I explored different variations and chose the last option because:
It shows a label and its value in one row.
It can be read as a dropdown.
I gives enough space for internationalization.
Image picker
If the user sets the type of background to Image, we’ll show this UI instead:
In this case, there are three possible actions:
Drop an image.
Click the icon on the top of the menu to open the Media library.
Click the drop area to open the File browser.
Once an image is loaded, we offer more options:
The dropdown for the display settings is a bit special and also gives the option to fix the background. This helps to reduce the flyout menu footprint and groups the display options together:
Gradient picker
Following the same logic of reducing the overall footprint of the UIs as much as possible, I split the interface of the Gradient picker in two.
When users select Linear gradient, they’ll be able to customize the basic gradient settings by moving the color handlers and setting the overall opacity. Then, if they click on a color, the menu will reveal a new interface to either edit the color or remove it from the gradient.
This separation of tasks allows us to offer a custom collection of gradients and a custom collection of colors.
We could use a similar UI for other types of gradients.
Color combinations alerts
Finally, I’d like to share some ideas to improve the alerts we show when the color combination has a lower contrast.
The first simple fix could be just showing the instructions in a list, so the message is easier to read. We could also explicitly show the problematic combination rendering the affected colors, and, finally, we could inform about more types of problems for people with different kinds of visual impairments.
Updated on Sep 21st: Here’s a related issue for these alerts.
Related issues
Here’s a list with some GitHub issues related to the designs and ideas presented in this post:
In this issue Matias proposes to expand the capabilities of the Cover block (and other blocks that use background images) “to empower users to achieve more varied visual effects easily”.
In this post, I’ll be exploring how to implement the suggested functionalities from the original issue (repositioning, resizing, and setting a background color), plus also three other functionalities (which in the context of this feature could have a lot of sense):
Cropping
Rotating
Tiling
A couple of caveats
The cropping, and rotating controls already exist in the Image block, but I’d like to explore an alternative way to work with these tools, closer to the way software like Figma, Sketch, or Framer does.
Although I think many of this designs will work in smaller viewports, I haven’t designed a responsive version yet.
Edit background
As suggested by Matias in the original issue, users could invoke the background editing options via a new toolbar item called “Edit background”. However, to avoid having very wide toolbars, we could use an icon instead.
When the user clicks on “Edit background”, the toolbar changes and presents a new set of options, including one that allows setting the display mode (Fill, Fit, Crop, Tile), a button to exit the Edit mode, and another one to revert the applied changes. In the Cover block, entering in this mode will also fade out the overlay text and its background.
The current Image block requires applying the changes made in the Crop mode explicitly. In this exploration however, every change is automatically saved, and the modifications applied to the image can be reverted completely.
Fill mode
From the default display mode (“Fill”), the toolbar gives access to the Focal point picker and allows fixing the image (an option that is currently accesible from the sidebar). Those two options appear in the toolbar so it’s possible to manage every background setting from a single place.
Crop mode
Options to zoom and rotate the image are also available in the Crop mode through a new toolbar at the bottom of the block.
This is how this mode works:
When the user drags the image, the cropping indicators will disappear, a grid will be overlayed, and the interface will show a label with the x and y coordinates.
Users can also move the image with the arrow keys (for extra precision, shift + key could also displace it in smaller increments).
Every part of the image that lays outside of the boundaries of the block will have a lower opacity, indicating that that part of the image won’t be visible in the published version.
If the user clicks on the image, we’ll overlay the cropping controls.
Tile mode
The Cover block has a setting for “Repeated background” in the sidebar that I propose to rename it to “Tile” and place it in the toolbar with the other display modes.
If the user has that option enabled, the size control will affect the size of each tile and the image will fill the area defined by the cropping handles. In this mode, rotation is also available.
Background
Finally, the color icon in the toolbar gives access to setting the background of the block, and it’s managed through a popover that allows switching between a solid color or a gradient.
Here’s a Figma file with the designs for this exploration.
I’m opening this issue to propose several improvements and enhancements to this block and also to track existing Table block issues (you can find them at the end of this post).
This post is quite long, but I’d like to present the whole picture here and create the necessary new issues later so that the initial conversation can be more focused and centralized.
Many of the proposed changes require having multi-cell selection first. Others, like improving the initial placeholder state, could be addressed independently.
Here’s the Figma file that contains all the designs covered below, along with some explorations and references.
I’ve centered my work around these five main areas:
The placeholder state
Multi-cell selection
The sidebar
The toolbar
Icon improvement
Placeholder
The current placeholder state is simple: users can set the number of columns and rows they want their table to have.
But these two numbers don’t give a clear picture of the kind of table the user is about to create, and since we don’t have a quick way to add new columns or rows (more on that later), creating the right table from the start is really important.
To solve this problem, we could offer an automatic preview that reflects the information entered by the user so that they can immediately see what the shape of their table will be.
Here’s an example of how this interface could look like:
The table in the preview gets updated whenever the user adds or removes rows and columns.
The height of the preview window is fixed, so the input elements below won’t move.
If the user creates a large table, we can show an ellipsis implying that the table contains rows or columns that are not being shown.
Another idea based on this UI is the possibility to resize the table using the preview interface itself: if the user hovers the cells and then clicks one of them, the table gets resized automatically.
Multi-cell selection
This is the biggest change in the Table block and would allow creating more complex designs than the ones that are possible right now.
Adding this feature would require refactoring the block and use inner blocks, so that cell is a block of its own. There’s been some talk around this topic in this issue.
To illustrate how this feature could work, here’s how Google Docs and TinyMCE do multi-cell selection.
Google Docs
The nice thing about multi-cell selection in Google Docs is that it’s possible to select one single cell. However, it’s not possible to select the entire table in an easy way (except, obviously, by highlighting all the cells with the mouse cursor).
In contrast, in the TinyMCE editor it’s possible to select the whole table by clicking on it. Strangely, you can’t select just one single cell.
I believe our tables should support these two basic use cases: single-cell selection and the highlighting of the whole table. That would make the styling process much easier.
Two other handy features we could offer would be: merging and splitting.
Merging
Some apps like Google Spreadsheets offer several types of merging: horizontal, vertical, or full merge, depending on the direction in which the cells get merged.
I think we could start by offering the full merge, as shown in the example below.
Google Spreadsheets also offer the option of “unmerging” a previously merged group of cells, which is a way to reconstruct the previous structure of the table. This is an advance use case that I don’t think we need to cover at this moment.
Splitting
Microsoft PowerPoint also allows to customize the splitting of cells. In our case, we could offer two options for splitting: horizontally or vertically. The reason to offer two ways and not automatically divide rows horizontally and columns vertically, is to support the case where a user just want to split a single cell. In that case, it makes sense to give the option to the user to pick the method they like.
Sidebar
Right now is only possible to change the text and background colors of all the cells at the same time. If we had mulit-cell selection in place, users would be able to customize their tables in many different and interesting ways.
These are the sections I think we should include in the sidebar:
Styles
Table Settings
Border Settings
Typography
Color
Advanced
Let me review each the first five of them:
Styles
This section could show four several common table styles. Instead of using gray to color the cells, we could use the default main color defined by the current theme.
These styles set and combine basic elements like stripes, and the presence of header, and footer rows. In the case of the last one (‘Left column’), it also sets the background color of a group of cells.
Table settings
In this section, I would add a controller to modify the dimensions of the table, since the only way to do this at the moment is using the toolbar (and that requires two clicks to add or remove a column or row of cells), which makes the process of modifying the dimension of a table a bit tedious.
Besides this section, another handy way to add more rows to a table could just be pressing the tab key in the last cell, like other apps do. I would also allow using the Tab key to traverse the cells.
Border Settings
This section would allow users to change the border settings for each cell or if it’s selected, the whole table.
With the idea to allowing to style tables in many different ways, we could also offer a special control (similar to the padding one) that would allow setting the width of each of the selection borders independently.
Color settings
Instead of changing the color settings of the whole table, this section would only affect the selected cells. This section would also offer the possibility to create a zebra-striped table (important thing though: the user could still overwrite the stripe color setting the background color with the control above).
Typography
Nothing shocking or revolutionary here: we should allow changing the style of the text for each cell and the table caption.
The toolbar
If we were to implement all these changes we would end up having at least 10 actions that could go in the toolbar. Instead of having one single option that give access to all the available actions, we could group them by category.
We could have three categories: insert, remove, and cell operations.
Insert would give access to all the additive operations: insert row before, insert row after, insert column before, and insert column after.
Delete would give access to all the destructive operations: delete row, delete column, and delete selected cells.
Cell operations would give access to merge, and split horizontally & vertically.
Icons
I’m also proposing to update several icons to make them faster to read and use the same kind of design language (i.e.: border radius, line widths, etc.) as other current icons. Here’s a first exploration:
And this is the full set of icons (again, an initial exploration) that also include the Split, Merge, and Remove cells icons.
Features
[ ] #30096 Add controls for font sizes
[ ] #18766 Add background colors to individual cells, rows, or columns
### Feature: merge + range selection
[ ] #15821 Merge/Unmerge cells (+ trac)
[ ] #12115 Not possible to select range of cells for formatting
[ ] #16294 Allow selection of entire rows and columns
[ ] #18768 Should we use InnerBlocks?
Enhancements
[ ] #29833 Recognize Markdown when pasting a table from Google Sheets
[ ] #16478 Add ability to disable Color Settings on Table Block
Bugs
[ ] #24393 Table Headers shouldn’t default to break-word
[ ] #12525 The RichText within the table cells shouldn’t have role=textbo…
[ ] #31237 Various Block Bug Report Thread
[ ] #8401 Scrolling is not evident when a browser/device hides scrollbars
[ ] #30876 Figure table’s figcaption HTML is not persistent when pasted
[ ] #31261 Continued enhancement of color options
[ ] #30468 Stop Offering “Block Recovery” for HTML Blocks
[ ] #30091 Performance with large number of rows
[ ] #13154 Ability to add ordered and unordered lists to tables
[ ] #23617 Make wrapping tables in figure tags optional
[ ] #26716 Setting Default Style in Button block doesn’t make post dirty
[ ] #12294 Layout fixed has 100% width
[ ] #28714 Edit table actions are unclickable after inserting a new table
To organize
[ ] #27480 Image caption styles global styles support
[ ] #24205 Finish resolving accessibility issues with Table Block
[ ] #18622 Option in panel to set horizontal to vertical orientation a…
[ ] #16355 Consider bringing in layout options to table block
Here’s an early exploration to improve some aspects of the save flow.
In the video above, I show some improvements in the highlight of items, and also present more granular options to independently save and discard the state of the individual items.
Javier Arce 