Design ticket triage (focusing on WP/meta): Monday 16:30 UTC in #design Design ticket triage (focusing on Gutenberg): Tuesday 16:00 UTC in #design Design weekly meeting: Wednesday 18:00 UTC in #design
Block patterns – Work is happening to breach into how to organize/design block patterns. This has been a long time discussion, and lot’s of dev-side improvements have been happening. An issue will be created shortly to get the design discussion going.
Gradients in buttons – Another Pull Request that needs design review for preset gradient functionality in the button block.
Usability testing videos – Last month usability testing was conducted, and the videos from that will be shared as a post in the next day or so.
Discussion
About pages
There’s been a post that proposed creating structure and strategy around the About pages. The goal is to have a smoother process around these pages, and they are an opportunity to showcase great design.
Ideally we could use Gutenberg in future releases to create the About pages for those releases. The obstacles seem to be dev related in terms of time needed. Lookout for a post sharing next steps this week.
WordPress 5.3 design feedback
There are several Trac issues that need design feedback for the next release of WordPress. The first one implements darker form field borders throughout WP-Admin. The second issue proposes some new, more accessible, button treatments. Ideally these should be evaluated together. Some discussion was shared on Slack, and further thoughts can be dropped into Trac.
Block Directory
There’s an issue to discuss where search should live in the block directory. Some additional discussion was shared in Slack, further ideas can be dropped into the Github issue, feedback is absolutely welcome!
Color swatch discussion
A question was raised in Slack related to selecting a color within the Color Settings of a block. When a color is chosen it’s hard to tell what the color is because the checkmark takes up most of the swatch area. In particular this makes it hard to tell if the selected swatch is a gradient. An issue was opened to discuss further.
User-selected default styles & Circle cropping option for images:
Navigation block
@tinkerbelly wrangled a great Navigation block discussion earlier this week in the #design slack channel. The Nav block has a bit more direction but is still in need of some feedback on this particular issue.
As mentioned before, the Gutenberg team is working to make sure there are a clear set of weekly priorities. These priorities are brought up during each #core-editor slack meeting. This week’s set include:
Regarding the architecture work preparing the editor to handle multiple entities, @epiqueras shared the framework changes. Now we need designs for template selection/creation, and post block save flows, etc.
Background color for the cover block was merged and released.
There’s a new About Page in every WordPress release. @karmatosed posted an article to discuss this page. Please leave your thoughts in the comments at the bottom of the post. We will discuss this further in next week’s meeting.
@estelaris started gathering requirements from notes and Github and is ready to make mock ups of some templates. She has some questions about the use of the anchor tag on the title: does it need to be visible? @melchoyce and @shaunandrews say yes, they use it to easily bookmark the url. According to Estela, the docs team is not aware of this use. A short discussion follows, and @itsjonq shows a great example of how this is used on Github. The people attending the meeting suggest proposing this as an alternative to the # that’s now used. If you have thoughts or idea’s on this, please leave them in the comments of this post.
Github shows a link icon when you hover a title
Mobile view issues for Helphub
The mobile view homepage for the helphub has issues, due to the large space that’s taken by the blue search section. There appears to be nothing else on the page. @mapk proposes to look at this site-wide, as other pages have this issue too. We therefore need a broader solution for mobile display. According to Mel Choyce, every instance of the blue banner is a different code base. If you have thoughts on this, please leave your comments here or in the ticket for this issue.
For each new major WordPress release, a unique “About” page is created that showcases features from that release cycle. It’s a chance to provide an overall summary of what’s new. As a fairly self-contained project (in scope as well as time), the About page could offer an opportunity for design contributors to support the release of a new iteration of WordPress.
However, there are currently some challenges in the process of designing this page:
The code of the About page is complicated and limiting. This means that the designer working on it often has to partner with a front-end developer aware of the various constraints, and not many front-end developers with that knowledge are available.
Each new release’s design is often done by one designer, without a unifying guide. This can result in either stagnation of style, or huge stylistic changes between releases.
There is also very little documentation on how to get involved and work on the About page.
The design and development happens in Trac, so you either need to find the ticket there or spot it in a core chat, to know the process is underway… and then you need to be comfortable working with Trac.
It’s hard to contribute, both for the reasons above and because often, the page is created in the last week of the release cycle.
This all sounds a bit bleak, so let’s talk about how we could fix it!
Let’s start by having a discussion about what we, as a design team, can do to make this process streamlined, clearer, and easy to get involved with.
I have a few discussion points to get us thinking:
What if the CSS system was rebuilt from the ground up, using components, so it’s easier to develop each release?
What if we used a unified style or theme for design moving forward? Maybe it could draw on the WordPress jazz heritage?
What if that style was translated into a style guide anyone could use in the future?
What if, at the beginning of every new release cycle, a call for an About page designer was put out?
Your awesome idea here!
Let’s continue the discussion in the comments. In a week, I’ll summarize the discussion and post the next steps.
The usability tests are being conducted weekly. One thing I’ve noticed frequently is the lack of ease when placing images along side other images or text. Sure we’ve got blocks that make this possible (which is awesome!) but it’s not quite as discoverable yet.
I submitted an issue a while back regarding how we might make this better. We’d allow users to drag a simple block (Image block) onto another simple block (Image block) which would then automatically create a complex block (Gallery block).
The discussion was around whether tips are intrusive and have a negative impact on the user when trying to get to the editor since there is data that users close them as soon as they appear. The #design team agreed that it is a good idea to keep on trying things and that inline tips for users should continue with the idea that tips would eventually disappear.
A new problem was introduced by merging this new control (icon) to the alignment group of icons since it relates to the full-width and wide formatting. But these icons are now all collapsed into a dropdown. This new formatting option can be selected in addition to the other options like full-width. Now we need to offer the ability for users to multi-select options in the dropdown.
And do we show both selections in the toolbar if there are two options selected?
The highlight of the discussion focused on the name, icon, and utility. Since it is “full-height” equivalent of “full width”, @sarahmonster suggested to call it “full-height” instead of “expand to viewport” which is a bit technical. The wording is important because it doesn’t refer to the document’s full-height, but to screen height.
@melchoyce also mentioned that the icon is used as “flip image” in the image editor, so they would need a new icon. There are no plans to request a new icon.
We also agreed that wide/full width belong to sizing and not alignment and that would be a better separation. Under sizing, there could be different combinations: full size, wide, fullscreen, etc. This option would avoid the need for multiple selections.
@blaidalfo was looking for clarification on the workflow with Figma libraries + Gutenberg GitHub repo. He followed the instructions posted by @davewhitley: