You don’t need edit access to use the Figma libraries, you can copy components from there into your own drafts. If you’re a contributor with the ability to grant edit access, please be mindful, and downgrade to view access once the initial need for edit has waned.
In this post I’d like to talk about the Table BlockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. and propose several improvements and enhancements. Many of these changes require implementing one important feature: multi-cell selection. Others, like improving the initial placeholder state, could be addressed independently.
If you want to check out all the designs mentioned in this post, here’s the Figma file that contains all the designs covered below, along with some explorations and references. I’ve also opened a tracking issue on GitHub to organize the work around this block.
I’ve centered my work around these five main areas:
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 UIUIUI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. 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.
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).
TinyMCE
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 (which combines a group of cells into one single element), as shown in the example below.
Google Spreadsheets also offers the option of “unmerging” a previously merged group of cells, which is a way to reconstruct the previous structure of a table. This is an advanced use case that we don’t probably need to cover, at least initially.
Splitting
Microsoft PowerPoint also allows to customize the splitting of cells. In our case, we could offer two options for splitting: horizontal or vertical. 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 them the option to pick the method they prefer.
SidebarSidebarA sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme.
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:
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 (which means that those previews should be generated using code).
These styles set and combine basic elements like stripes, and the presence of headerHeaderThe header of your site is typically the first thing people will experience. The masthead or header art located across the top of your page is part of the look and feel of your website. It can influence a visitor’s opinion about your content and you/ your organization’s brand. It may also look different on different screen sizes., 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, as 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.
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 gives access to all the available actions, we could group them by categoryCategoryThe 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging..
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:
Notice that, in the case of the four insert icons, the weight of the elements indicates the direction (before or after) in which the action will take place, while the current icons use the plus symbol instead. This is a delicate distinction that probably requires some careful consideration. Please, share your opinion and ideas in the comments of this post or in this GitHub issue.
And here’s the full set of icons (again, an initial exploration) that also include the Split, Merge, and Remove cells icons.
You must be logged in to post a comment.