Welcome! This all-volunteer team needs designers of various kinds. See our handbook and drop into #design once signed up for volunteer opportunities.
Our vision is to be the go-to resource for design for other teams across the WordPress open source project.
Here’s a recording of my stream going through what Windows 10 high contrast mode is, and how you can design for it:
Most of the time you don’t have to think about it, but there are a couple of handy tricks to be aware of.
The block directory will be a place where blocks can be perused and installed. Think of it as a plugin directory limited to single blocks.
Back in December, @melchoyce proposed a prototype for a block directory. That prototype is still 100% viable for the block directory. It is likely the simplest to implement as it’s pretty close to the existing plugin directory with a few nice systematic updates to patterns used across wp-admin.
When I picked up this project, it made sense to me to try a variation of what @melchoyce created . I decided to see what a block directory might look like if it shared Gutenberg’s design language. To accomplish this, I tried using similar patterns and styles to what is seen within Gutenberg since the block directory and Gutenberg are so closely tied together. I also have been keeping block patterns in mind when designing.
This is a hopeful proposal and none of what I propose here is set in stone. I would like higher level feedback around the interactions. Do the interactions make sense? Is it clear what you’re looking at? What are the designs missing or lacking? What could be improved?
I’m not looking for detailed design feedback like hover states or border colors. Those are important for sure and that type of feedback will be needed during implementation.
Here is a rough Figma Prototype that shows a handful of the views in the block directory. Take note of questions you have as you look through it and please share in the comments below. I hope most will be answered as I break down each of the primary design patterns and views.
The block card is designed to be a recognizable design pattern that, even without a preview, will convey that it is a block. You can see we already have a similar card proposed for implementation in Gutenberg’s block directory search.
I tackled this in a few places. To start, I identified block cards that can convey the most important information about a block at a glance. This is where I started diverging from the existing plugin directory.
I deviated from using a plugin icon and plugin header for two reasons.
I trimmed down the amount of information present on the card. In this mockup, I show the Block Name, the Author, Rating, and Number of Ratings. I may add an indicator of active installs. Everything else will be shown on the Block’s Details View, which a user will need to navigate to in order to install a block.
The preview is a square because the block’s example can vary widely in its aspect ratio. We will need to do some work here to figure out the scaling and overflow details of previews.
Mel designed an iteration of the wp-admin page header that makes great use of space, order of interactions, and hierarchy. I made very minor modifications to it resulting in what you see below. Ideally, this pattern could be used across all wp-admin sections.
It’s very simple. It has a page title, a description, primary actions, and secondary actions. The page title and description are exactly what you would expect. The primary actions are below the description and, in this case, include a search bar and upload button. The secondary actions are the help and settings buttons.
The directory view is a combination of the header and groups of block cards.
Like the current plugins directory, the blocks will be in categories with “See all” links for folks who want to peruse a specific category.
The CTA banners Mel designed are ace so I expect we could use them as a way to highlight any number of topical subjects. Perhaps they could be used to promote block collections if we decide to go down that road at a later date.
The block details view shows all the information surrounding a plugin. The current details view for a plugin relies heavily on a sidebar. Much of the sidebar information seems directed at plugin developers.
The most useful information for a user is at the top. It includes ratings, active installations, compatibility, the block version number, and the install button.
The Demo section is an example of the block that a user can interact with. It is important the user gets a clear idea of what they’re about to install. The editor itself will be an instance of Gutenberg with some slight customization. The inspector will remain visible because many blocks rely on the sidebar controls.
The Reviews section shows two reviews along with rating totals. I would like your thoughts as to which reviews should show.
There are still some remaining pieces of information I would like to incorporate including contributors, a changelog, and a support section of some sort. This is also missing the Advanced View. Perhaps some of those missing items will fit better there.
These designs include patterns that could be used elsewhere in wp-admin. For example, we could use the directory header pattern on the other directories and perhaps on all wp-admin pages. This would be one of several steps to align the design language of wp-admin and Gutenberg.
This week’s meeting will be held at 18:00 UTC on Wednesday in the #design channel of the WordPress Slack and Zoom. You can join the Slack channel by following the instructions in our handbook.
As being this the last Wednesday of the month we continue with Show & Tell. If you are working on a design project for WordPress and want feedback or just want to show us, please add a comment here. If not, just show up at the meeting and we will give you some time.
The Zoom link will be announced in Slack on Wednesday right at the meeting time.
In September, the design team chose to shorten meetings length, remove one triage as results were varied and some people were feeling overwhelmed, finding it hard to follow everything. This was done as an experiment while the team figured out what other items could be added to the make/design team.
As it was discussed during design team meeting, the problems raised in the conversation are:
What suits one person may not suit someone else. This post is designed to bring the Slack conversation to a wider audience and start working on some opportunities to adjust the communication flows and find the right combination for the team. That ‘one thing’ might of course be multiple optional things, let’s find out together!
The team primarily communicates via Slack, GitHub or Trac and uses this site for agendas, notes. This has changed over time, but is the current state right now. Here is a summary of what happens right now as far as organised sessions are concerned:
Scheduled meetings:
Un-scheduled sessions:
Make/design posts:
Let’s now dive into some of the ideas that came up during the meeting.
Along with the above, here are some additional ideas pulled from the post when meeting times were adjusted:
There is a lot of information to process, so this post will be open for a couple of weeks, to gather ideas. It will also be a topic in the meeting after the next, as next week’s meeting is a show and tell session. A post will be written up summarising action points, ways to get involved after discussion has reached a point and ideas have been gathered.
It would be great to have a continued discussion in the comments. To begin that, here are a few starting points.
This post was a summary of the meeting points from 21/10/2020 and collaborated with @estelaris, @hedgefield. Thanks to @chaion07 for the review. Props to everyone that attended the meeting and over the past few months given their input on ways to iterate the way this team works.
My idea is to increase the number of posts in the make/design blog. It could be something like this:
1. Meeting agenda
2. Meeting notes
3. Subject matter post (anything WP-design related. Could also be x-posts from other make/teams that are design-related)
4. Design Trac summary (once a month)
5. Video posts of ad hoc meetings
6. x-posts for Gutenberg
7. x-posts from other make/teams requesting design help (we don’t control this)
These are in no specific order and besides the meeting agendas/notes, none of the posts is a must every week, but I would recommend scheduling each category at least twice a month.
I think it’d be interesting to have focused design sessions. For example, if we want to spend an hour talking about Global Styles, then whomever is closest to that focus could facilitate a discussion around it. It would also be neat if the focus shifted each meeting.
And while I like video discussion, if we were to go that route we would need to have a dedicated notes person to summarize the meeting accurately.
These are the weekly notes for the design meeting that happens on Wednesdays. You can read the full transcript on our Slack channel and read the meeting’s agenda here. You can join the Slack channel by following the instructions in our handbook.
We have an open call for note-takers and triage facilitators. These both are great ways to get involved for new contributors but everyone is welcome to help out. Let us know if you are interested in the comments.
Next week is Design Show & Tell, a monthly Zoom meeting where you can showcase or update any project you are working on or ask for input on anything you are contributing. It is open to all design contributors.
@melchoyce let us know that Twenty Twenty-One is in Beta and the team would appreciate any input. You can test it in WordPress trunk or download the theme directly from GitHub.
@shaunandrews is looking into several floating (+) buttons, understanding their function, the problems they solve or create.
@anyssa and @elmastudio are designing the About page for release 5.6.
@karmatosed @estelaris have been moving 5.6 tickets and PRs.
@paaljoachim ran a successful Design Feedback session on Wednesday early morning. These may continue every other week, switching between early mornings and late evenings to allow for contributors in different time zones to join.
@mapk is working on the Query block:
The design team held a discussion about the use we are making of the Make/design blog, triage and meeting. While we have been running an experiment on trying to contain the surplus of information, we have also noticed that we are missing opportunities and the blog has turned into a list for meeting agendas and notes.
We had several ideas that could help us improve and there will be a post about this.
hi dear
can you tell me more information for install ?
for servermax.net
This week’s meeting will be held at 18:00 UTC on Wednesday in the #design channel of the WordPress Slack. You can join the Slack channel by following the instructions in our handbook.
Here are the suggested topics:
If there is anything you would like to see added to the agenda, please leave a comment also.
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. You can join the Slack channel by following the instructions in our handbook.
We have an open call for note-takers and triage facilitators. These both are great ways to get involved for new contributors but everyone is welcome to help out. Let us know if you are interested in the comments.
Gutenberg contributors have gathered lots of feedback on the new Widgets screen. It is being aggregated into issues now, most of which will hopefully be resolved for WordPress 5.6.
Also lots of work is happening on theme/plugin auto-updates for 5.6, to really polish up the initial implementation. If you’d like to help out, drop by #core-auto-updates on Slack.
@paaljoachim has started facilitating design feedback sessions in our #design channel on Slack. These will be informal, meaning the time and format can vary, and will likely happen in the morning for the EU timezones. That means we’re covering new times in which otherwise meetings don’t often get scheduled. It helps create more moments for focused design discussion The first session was run right before this meeting to great success. Stay tuned for more.
This week’s meeting will be held at 18:00 UTC on Wednesday in the #design channel of the WordPress Slack. You can join the Slack channel by following the instructions in our handbook.
Here are the suggested topics:
If there is anything you would like to see added to the agenda, please leave a comment also.
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. You can join the Slack channel by following the instructions in our handbook.
We have an open call for note-takers and triage facilitators. These both are great ways to get involved for new contributors but everyone is welcome to help out. Let us know if you are interested in the comments.
Lots of good things happening with Gutenberg. There wasn’t anybody around to recap at this time, but keep an eye out for the next update on the Core Make blog.
There is an amazing team of designers working on the release of WordPress 5.6, there’s some good work happening there too:
As part of the 5.6 release process, we also have several bug scrubs scheduled that require testing. Here is the schedule in case you are interested: http://wayback.fauppsala.se:80/wayback/20201031000546/https://make.wordpress.org/core/2020/09/01/bug-scrub-schedule-for-5-6/
@ibdz is working on iterating on Admin Color Schemes together with #core-css, helping with testing the reduced color palette proposed last week to clean up all those runaway colors.
@manzwebdesigns is working with #pluginreview on detecting plugins not meeting standards such as gifs in the backend.
@mapk is, among other things, taking a crack at the UX of the Query block, with @hedgefield also diving into that particular conundrum to offer advice.
@hareeshpillai requested feedback on the following tickets:
@joyously raised the point that the design meeting could use more focus to get people to own design tickets. Before we ran out of time, we talked briefly about how design happens at different paces for each contributor, and that some things don’t always make it to the meeting. It was suggested she makes a list of tickets that she feels have slipped through the cracks and we can review them next week.
I love that you’re posting this on make/design! Really good stuff.
Directory view
In the prototype, it felt like you had two page headers going on, but after reading further, it looks like one is a CTA banner and the other is a header. The CTA banner is a visual distraction for me right now, but probably just because it doesn’t contain anything useful in the mockup. If we don’t have a CTA banner, this page gets simplified quite nicely. Overall, I like the direction of the block cards, and really focusing on the blocks more than a plugin graphic. Good call!
Block details view
The “Install” button wasn’t obvious to me at first. I wonder if it should be positioned elsewhere though?
I also see star reviews at the top and in the middle. Is there a way to combine these? Maybe in the right side?
What happens if there are more than one screenshot? If the plugin wants to include screenshots of the block in the Editor and on the frontend?
I’m not sure what you’re asking here. Like should you show only 5 star reviews as the top two? Or most recent reviews? Or the highest and lowest reviews?
They aren’t necessarily screenshots. They are a generated image of the block’s example.
Good question. I’m wondering which two reviews we show. Are they the two most recent? Two chosen by the author? Two random ones? Some basic algorithm that picks two within the overall rating range (if it’s 4.5, show four or five star reviews)?
Plugin Rep weighing in – We cannot allow developers to pick the reviews. As much as I would love to, they’ll abuse it by having sock puppets or (worse) their own people leave reviews and picking those 🙁 It’s still a problem.
We need someone to come up with a basic also that takes into account:
That’s about what I expected there. Thanks for adding some ideas to the criteria algorithm!
This is great stuff, Michael 👏
Page header
I found the upload button next to the search field a bit confusing, particularly because there’s no label, so I wonder if some will think that it’s a submit button instead.
Block details view
I agree with @mapk that the ‘Install’ buttons could be in a different place. I wonder if having it next to the block title on top might make it more obvious?
I LOVE that there is a demo section, that’s really nice!