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.
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.
Last week there was a call for both notetakers and triage facilitators. The call is still open, if you are interested, leave a comment after these notes or announce yourself in the #design Slack channel.
@mapk let us know that the workaround full-site editing is moving forward. Several issues have been identified and Gutenberg designers are reviewing UX flows in relation to these issues.
Other specific works happening around Gutenberg include usability testing on Columns blocks, more work and design for Navigation block and global styles.
@karmatosed open discussion around WP 5.4. And the list created of items the #design team would like to include. The list is very optimistic and needs prioritizing.
We ask people to review the list and let us know in the comments what do you think should be worked out for 5.4.
We reviewed two tickets: #48850: Plugins Screen: introduce “Automatic updates” column/option and #49199: Introduce Automatic update opt-in setting for themes. Both tickets are part of the 9 priorities for 2019-2020.
We talked about options in text and toggles like “on/off”. See examples on the Slack chat. You can leave your thoughts on both tickets. @kjellr is back and retaking the topic of how themes work with Gutenberg. Follow up his experiments on the mentioned repository. In the future, there will be more updates in #themereviews and make/themes if people want to follow this topic.
As noted in an earlier Gutenberg design update, I wanted to communicate a proposed UX flow for rolling out the widgets-to-blocks interface changes. It’s a proposal and still up for discussion along with further communication in the Github PR, Add blocks in widget areas RFC.
The Github issues include: wp-admin interface and the Customizer.
Widgets are now blocks which require a new Gutenberg interface to help people transition to this new paradigm. What is the best way to introduce the new widget-block screens to users? How can we do this with the least amount of development time, use existing patterns, and clearly communicate the gradual transition to blocks?
I began by segmenting the use cases:
My initial work included using different menu items in wp-admin and the Customizer based on if the user had existing widgets in their site. A user with existing widgets would need more help transitioning to a new interface than a user without any prior widget paradigms.
After further investigation of this, I opted out. If the menu items segmented, it might cause more confusion because there would be some users with the new menu items while another may have the old. Documentation and internet tutorials could get difficult to follow at that point. I’d like to do this with the least amount of development time, and confusion on the user’s end.
To achieve a simple and non-confusing rollout, keeping the wp-admin menu items the same might be the best option. The user would still see “Widgets” under the “Appearance” menu item. When clicking that to view the widgets, the user would now get the new Gutenberg Widget Areas screen.
We’d need to make sure the proper messaging or tips are displayed on this page to help orient the user to the new layout.
This scenario would work similarly to the one above. When clicking into the Customizer, the user would still see “Widgets” as an option if the Theme provides it. This shouldn’t require any additional work on the part of the theme outside what is currently required. Once clicked the user sorts through the blocks and can add 3rd party unconverted widgets with the Legacy Widget block.
So that everyone’s aware, the discussions around why blocks are being introduced in the widget screens is already explained in the Github issues, and in comments on other sites. This is one of the 9 projects for 2019, and aims at helping everyone slowly make the transition to the block paradigm.
The feedback I’m looking for here is:
As you may remember, back in December a small group of curious-minded people embarked on a research study with the aim to learn more about how end users think about site building.
Since the results have been out for a little while now, @jarahsames and I are going to be hosting a walkthrough of the results as well as a Q&A session, live on video! Join us at 19:00 UTC, Monday, 18 March to learn more and ask all your burning questions.
The session will cover:
The session will be recorded and shared here, so if you can’t make it live, you can always catch up later. It should take around an hour, depending on how many questions there are. If you can’t make the session or would like to pre-share your question(s), please drop them in the comments below, and Sarah and I will be sure to answer them during the Q&A portion.
The Zoom link for the session is here, and will also be shared to #research just prior to the session. See you Monday!
User research is key to ensuring that software meets users’ needs. With user research efforts ramping up across the project, now is a great time to get involved!
You don’t need to be a designer (or a developer, or a tester!) to become a researcher. All you need is a curious mind and a desire to help improve products for users.
With the site building study wrapped up, the next research efforts will be focussing on usability testing of new features. Coming up this month:
Anyone can become a researcher! You can start as a silent observer. This is the easiest way to get involved. You join the call as a silent, invisible participant to see how it works, and you can share your observations with us in Slack after the session.
If you’re ready for the next step, you can help by taking notes or even running a session. You can also help by contributing your observations after the fact, watching video recordings, or compiling results. There are guides and support available for all of these tasks, as well as lots of friendly faces in the #research channel in Slack to answer any questions you may have.
If you’d like to be involved in one of the research studies listed above, please comment here or ping myself, @sarahmonster in Slack, and I’ll get you set up and ready to go.
Yesterday, @lukepettway was kind enough to sit down with me and walk through my and @melchoyce‘s initial ideas for a menu block design, in order to catch any areas that could be problematic from an accessibility standpoint.
Video recording and transcriptAfter collecting feedback and discussing areas of the problem individually, @melchoyce and I have circled back to a proposed combined direction for the navigation menu block.
Building navigation menus for a website is a fragmented process that’s difficult to understand and visualise. It relies on a pre-existing understanding of the model WordPress uses to organise menus and doesn’t map to users’ understanding of how navigation menus should work. There are multiple different ways to create a menu (Customizer, Appearance > Menus, widgets) that all offer slightly different experiences, increasing confusion. Creating a link to certain parts of the site often requires manual work.
The core principles followed here:
There’s a great deal of complexity that goes into a navigation menu (multiple levels of nesting, mega menus, social links, etc), but the majority of users require a very simple menu—a collection of links to the main sections of their site.
After a productive discussion in the #design meeting of 13 February, Mel and I decided to create slightly different experiences for core interactions and advanced interactions. For the majority of users, everything they’ll need to build a simple menu will be available in the block interface itself. Smart defaults help users get up and running as quickly as possible, so they may only need to make a few small adjustments to the out-of-the-box configuration of the block. For advanced users who want fine-grained control of complicated menus, a suite of advanced tools is available in the Inspector.
You can see how these interactions are classified in this diagram:
When you first add the navigation menu block, Gutenberg will use some underlying code-magic to try to automatically generate a menu for you, based on a number of different factors including any pre-existing saved menus, where you’re inserting the menu on your site, and what content you already have set up.
Once you’ve created a menu, you can delete items quickly using the delete on your keyboard, or you can delete them using the traditional block settings ellipsis menu.
To rearrange elements in your menu, select the menu item you’d like to move and either use the drag handle or the “move left” and “move right” buttons to shift it. Advanced options and hierarchy management exists in the inspector.
One level of hierarchy is visible in the block itself. By default, sub-menus are hidden in the block interface, but they can be toggled on and off using the drop-down icon. For more complex hierarchical structures, an inspector panel opens and allows for legacy-style reordering and nesting of navigation items.
To add an item to your menu, start typing or use the “+” button. The placement of the “+” button shifts depending on which item is currently selected, so you don’t need to add new items at the end and then move them up.
Adding a new menu item pulls up a search interface, similar to adding an inline link or a button. The search returns all relevant content across your site, regardless of what content type it may be. Icons are used to provide additional context as to what type of content is being returned. From here, you can also opt to create a new page or enter the advanced mode to browse your content and bulk-add items.
If you’d like to dive more deeply into the finer points of discussion, there are a series of Github issues for discussing different parts of the interaction:
There’s also a Figma prototype that you can play with or leave comments on directly. Note that it’s under construction, so not everything works perfectly yet.
At this stage, broad feedback would be extremely useful.
If you have feedback on a specific element or interaction, it’s best to leave that in Github or Figma. If you’d like to remix or improve this work, please feel free to create a new page in Figma, or duplicate the whole document itself, and share here in the comments.
These designs are a work in progress and will be iterated on based on your feedback as well as usability testing results.
@lukepettaway and I will be meeting up later this week to do a walkthrough of the proposal and identify any potential accessibility problems in this design.
Mel and I will be working on a plan for usability testing of this prototype. If you’d like to be involved or sit in, please join us in #research at 18:00 UTC tomorrow, Tuesday 26 February for a text chat. More details will be posted here once those details have been hammered out. If you’re interested in helping with usability testing, there will be lots of opportunities to get involved!
#gutenberg, #menusThese are the results of a user research study investigating mental models related to building and customising a website. Results are split across five posts:
Background | Segments: Bloggers · Small Businesses · Site Builders | Conclusions
The research group sorted participants into three segments, based on their current understanding of how people use WordPress. These segments are based on a handful of data points and warrant further study to confirm the categories. For now, these segments allow researchers to group WordPress’ extensive userbase into behavioural categories and learn characteristics specific to each group.
For this study, we focussed on three segments: bloggers, small businesses, and site builders (people who build sites for others). Today we’re going to learn more about site builders.
Site builders are people who make sites for others. Site builders often start as bloggers or small businesses. Having taught themselves to build websites, they are now progressively leveraging their skills to earn additional income. They tend to work for friends, acquaintances, or people in their professional networks and often barter or don’t charge much for the websites they build.
Let’s learn more about site builders!These are the results of a user research study investigating mental models related to building and customising a website. Results are split across five posts:
Background | Segments: Bloggers · Small Businesses · Site Builders | Conclusions
The research group sorted participants into three segments, based on their current understanding of how people use WordPress. These segments are based on a handful of data points and warrant further study to confirm the categories. For now, these segments allow researchers to group WordPress’ extensive userbase into behavioural categories and learn characteristics specific to each group.
For this study, we focussed on three segments: bloggers, small businesses, and site builders (people who build sites for others). Let’s learn about small businesses next.
Small businesses are the most varied group since businesses range widely depending on their nature. This is a difficult group to generalise about and researchers observed a diverse range of experiences.
Let’s learn more about small businesses!These are the results of a user research study investigating mental models related to building and customising a website. Results are split across five posts:
Background | Segments: Bloggers · Small Businesses · Site Builders | Conclusions
The research group grouped participants into three segments, based on their current understanding of how people use WordPress. These segments are based on a handful of data points and warrant further study to confirm the categories. For now, these segments allow researchers to group WordPress’ extensive userbase into behavioural categories and learn characteristics specific to each group.
For this study, we focussed on three segments: bloggers, small businesses, and site builders (people who build sites for others). Let’s learn about bloggers first. (Hat-tip to @jarahsames who studied this segment!)
Bloggers wear many different hats: they are the writers, admins, and IT for their websites.
Learn more about bloggersThese are the results of a user research study investigating mental models related to building and customising a website. Results are split across five posts:
Background | Segments: Bloggers · Small Businesses · Site Builders | Conclusions
Results have been compiled from the sitebuilding research conducted at the end of December, and a report is ready. Make a cup of tea, it’s a long one! 🍵
Huge thanks to @jarahsames, @alexislloyd, @bengrace, @benrearick, @bph, @cathibosco, @chrisvanpatten, @designsimply, @evawong, @johngough, @joshuawold, @karmatosed, @lilibet, @lonelyvegan, @mapk, @melchoyce, @mkaz, @msdesign21, @nao, @paaljoachim, @pento, @thedezzie, @tmmbecker, @tobiasziegler, @xarisgn, and Melissa Vander Wilt for helping to make this happen. Research like this takes a village, and it was fantastic to have so many people jumping in to lead sessions, take notes, share insights, and sift through all the data. Thank you for all your hard work! 🌟
If you have any questions about these results or would like to conduct your own research, please drop into the #research channel in Slack and say hello.
With that said, let’s dive into the full report! There’s a lot of information to digest, so this will be split into five sections (see discussion), to be shared here over this week and next.
Background information
