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.
If you didn’t get to attend our meeting in Slack this week, don’t worry! That’s what these notes are for. You can see the previous agenda, and follow the Slack chat log.
There are so many great data points and insights here from the research the team has done with WordPress. It’s a treasure trove, thanks to everyone for the work, and it’s well worth checking out. We discussed having a walkthrough of the work. Keep an eye out for that!
We’d love to hear some thoughts on this post. We had a great meeting last week, and a thorough followup, walking through where we’re at with icons in WordPress, and where we can take things from here.
Create style guide for future WordPress pages
Tremendous work has gone into giving a guide for designers or developers to quickly create new pages based on work that’s been done previously. This is really helpful! We discussed in our meeting the work involved to convert the guides to Figma files, as the WordPress design team is able to use Figma for free, and it supports more collaborative design work.
Gutenberg Nav block
We’d love your feedback on all the hard work the team has put into suggesting various approaches to creating a Nav block in Gutenberg. For clarity the work has been broken into five individual issues for discussion.
Feedback on any and all of the issues is welcome. The biggest challenge right now is trying to fit all the complex interactions of a navigation menu into the block area. The team is also trying to follow the principle of putting as much in-context settings next to the block area, and avoiding too many settings in the sidebar.
A great point was brought up about ensuring accessibility is thought of and included in these early stages. We briefly discussed what this could look like, and the design team wants to continually be proactive in soliciting feedback from the accessibility team.
Discussion about bringing it all together (Slack link)
We discussed some of the challenges with making complex Nav blocks, and where the different settings should sit. If you have time, feel free to jump into Slack and read through it; these thoughts are very much in progress, so additional feedback is welcome!
We’d love feedback on a new WordCamp PWA proposal.
First, a little history–the first icon set used in WordPress was a png/bitmap sprite. The sprite couldn’t scale, which became a problem as display resolution increased. To solve the scaling issue, WordPress version 3.8 introduced a vector-based icon set packaged in an icon font, which was the most common approach for the time.
Icon fonts are now an outdated format. SVG icons present a number of advantages in terms of performance, accessibility, scalability, and ease of use. There have been attempts to convert Dashicons to SVG, but that hasn’t happened yet.
Modifying Dashicons requires using third-party tools and command-line processes, making the contribution process hostile to new contributors. Adding a new icon and updating the font requires several time-consuming and complicated steps. The desire to keep Dashicons as lean as possible for the sake of performance means any new icons must be considered by the core teams to determine if they are warranted. As a result, there are often requests for new icons that don’t get met, meaning that people aren’t able to access icons they need.
Instead of building something new from scratch or converting the icon font, we can leverage work already done in Gutenberg to bring a more modern toolset for admin icons to the whole of WordPress. Gutenberg introduces an SVG icon system that includes a process for extending icon sets. This makes it easier for plugin and theme developers to incorporate any icons they’d like and allows for the tried and true Dashicons to remain part of WordPress’ future.
The design team would like to extend Gutenberg’s icon system to the rest of WordPress. An open source and actively maintained icon set such as Material Icons would serve as a base set. This will give us an established set of icons to work with right away, which can then be built on to accommodate WordPress admin, plugins, and themes. This will make it easier for everyone to access the icons they need while bringing a consistent experience across the entirety of WordPress.
The design team needs your input. Right now, we’re trying to determine if this is the right direction, and then we’ll focus on implementation details. Let us know what you think!
As we all know that the PHP 5.5, 5.6 and 7.0 has hit the EOL (End of Life) and is no longer actively supported, PHP 7.2 and 7.3 are now actively supported. The #core-php team is working on a page that spreads awareness about upgrading the server to supported PHP versions for the purpose of performance and security.
Work has been going on for a while, the #core-php team is working on this and they have built a page right now which can be viewed here.
There were a few designs that were created back in May 2018 and will have to be reworked on to accomodate the new fresh content. The page has a chunk at the top which gives a clear message if the server needs to be upgraded or not.
The current design is single column and does not have the ‘Table of Contents’ like the one implemented in the live page. There also needs to be a more design-wise seamless integration of the chunk at the top which gives a clear message if the server needs to be upgraded or not.
This page is currently live but needs improvement in terms of how it educates the user by clearly telling that the upgrade is required. @flixos90 and myself are working on this page. Contributions and thoughts are welcome and you can reach out to us or #design channel to discuss this.
This week’s meeting will be at 19:00 UTC tomorrow in Slack #design.
Here are the suggested topics:
If there is anything you would like to see added to the agenda, please leave a comment.
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). 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
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 informationThe research group has a report ready to share as part of the sitebuilding research. Since it’s quite long, the group would like to choose the best place to publish it.
This report should be stored with other research results in the future, since these are likely to build upon and enhance one another. It’s best if these resources are easy to find and access. They should be something that everyone contributing to WordPress can refer back to in coming months and years.
This was discussed in Slack, but let’s open the conversation to more people.
Where should this type of content live?
This research is ready to publish, so please share your preference by leaving a comment on this post no later than Thursday, 31 January 2019. Thank you!
This week’s meeting will be at 19:00 UTC tomorrow in Slack #design.
Here are the suggested topics:
If there is anything you would like to see added to the agenda, please leave a comment.
The WordPress showcase is a portfolio of inspiring and innovative sites built with WordPress. It features some of the nicest sites in the world that are built with WordPress. It should feature all of them 🙂
There’s a post on the Make/Marketing blog that outlines the project, it contains slightly more than just features and design, so let me re-iterate those here.
We’d like to add:
The design currently looks slightly dated, especially on the single pages. The current design also doesn’t work too well on mobile and actually has a double hamburger menu, which is confusing.
Ping @joostdevalk on Slack and/or respond here. As this is quite a chunk of work, we are looking if a company is willing to sponsor a designer for this, so we can move forward at a high pace. We will then form a working group and start iterating.
Some of you may have heard of the Health Check plugin – It’s a very useful tool that shows people how their website is doing technically. It displays all the relevant technical information about a WordPress installation and offers tips on what to improve.
The intention is to evolve this plugin into something really awesome where (parts of) it can be merged into core. The main issue is that it needs a UX and UI overhaul. Right now the plugin mostly consists of grey pages with lots of words and numbers on them, some of which are SO long that I had to crop the screenshot by half to get it to upload:
(Click to enlarge)
There are lots of good tools there, but we need to make sure people know how to use them, and why they should. So even before making any designs, we should think about the UX of the plugin as a whole. Questions like:
The improved Site Health Check is aiming to be ready for WordPress 5.2, which is roughly estimated to come out in Q2 of 2019. That’s not loads of time, and we are a very small team at the moment (@clorith, @miss_jwo and myself), so we’re looking for any input on the above questions.
I’ve started a central issue on the plugin’s Github repo to discuss the UX, any contributions are welcome there: https://github.com/WordPress/health-check/issues/227
I’m hoping to work out new layouts and flows in the next few weeks, and then start designing the final look at the end of February at the latest. That’s around the same time 5.1 is slated to come out, and should give us enough time to implement everything.
Worth noting is that we want to try to apply the Gutenberg style to this. It would be a nice test case of what WordPress’ intended new design direction will look like outside of the editor, and it matches nicely with previous design work done around this project.
Like I said, feel free to drop by the Github issue to help us come up with a great user flow. We have an opportunity to reshape the UX of this thing, so I want to get as many eyes on it as are willing and able. Sketches, thoughts, reference material to look at, it’s all good. I’ll be dropping more sketches there in the coming days, any feedback is welcomed.
You can download the current stable version of the plugin to try on your own WordPress site from here: https://wordpress.org/plugins/health-check. Note that that doesn’t include the new actionable traffic-light-based site status section you can see in the screenshots above. Of course, if you know what you’re doing you can compile a build from the develop branch on the repo to see the latest progress.
There is also a section in the Handbook that describes how to use the Site Health Check Plugin: https://make.wordpress.org/support/handbook/appendix/troubleshooting-using-the-health-check/
And at the link below you can find a comprehensive post about the research @miss_jwo did that led to this point, and the broader context of this plugin in the Site Health project:
I’ll try to keep you updated on our progress roughly every week here on the design blog.
