This is the official blog for the WordPress open source project’s design and UI. Follow along and/or participate as we post about what we’re currently working on, meetings, and big picture items. Glad to have you!
This is the second weekly call for updates for those contributing to design, as outlined here.
The idea of these it to keep all designers connected. If you are contributing to design please add your reply as a comment to this post by Thursday 23:00 UTC. All comments will be combined into a weekly update post on Friday for the design team.
Not a designer but you have something you’d like us to work on? No problem, you can also leave a comment. Just tell us what it is, if a specific team or skill also tell us that.
Just reply to the following:
Everyone is welcome to comment, adding names of all that commented last week and were at summit – your name will be added to list as you give an update (so we can include everyone).
cc: @melchoyce, @michael-arestad, @folletto, @mapk, @sonjaleix, @saracannon, @liljimmi, @joen, @empireoflight, @joshuawold, @rileybrook, @celloexpressions, @joyously
At the Community Summit, we took a bit of time to chart the story of a contributor. We did this to find our problem areas, where in the contribution cycle we lose contributors, and how we could improve. Our focus was on the issues, and getting actionable solutions. Each action item was assigned an owner. We also all agreed to some tasks, which we’d like to encourage all design contributors to join us in.
Each task has one or more person leading it, however, more contributions are welcome in those areas. Some are larger and may grow into bigger projects. The idea of assigning tasks was just to make sure someone takes ownership, so these tasks are actually completed.
This is the start of the journey. We looked at ways we could reach more people, to show them that design is happening in WordPress. We also realised we had a lot of designers involved, but very little support for those designers.
Once someone discovers the team, we discussed how we could better retain them.
Once someone is contributing, the story doesn’t end there. We need to work to not have them drop off. We need to be constantly mindful of their experiences.
Being a design lead can create a range of issues, and lead to problems like burn out. We all agreed we had to support and do our best to avoid this. We concluded design lead shouldn’t mean a solo mission, that way leads to issues in itself. We have been supporting each other unofficially, but that should be more transparent.
Whilst we had no specific tasks, we discussed that some people bounce in and out of contributing. This is actually not unhealthy, we should allow for life to happen and be OK with this. It is important to welcome back in and check just to see if people are OK when they’ve been gone for a while.
We looked finally at why people leave and stop contributing. How can we help that?
To track and address these issues, we’ve created a design team Trello board. We can iterate, but for now this is where we can get an overview of what is going on. Want to help?
Thanks!
This is the first weekly call for updates for those contributing to design, as outlined here.
The idea of these it to keep all designers connected. If you are contributing to design please add your reply as a comment to this post by Thursday 23:00 UTC. All comments will be combined into a weekly update post on Friday for the design team.
Not a designer but you have something you’d like us to work on? No problem, you can also leave a comment. Just tell us what it is, if a specific team or skill also tell us that.
So, lets start the first design team individual updates! Just reply to the following:
Everyone is welcome to comment, adding names of all summit attendees first – your name will be added to list as you give an update (so we can include everyone):
cc: @melchoyce, @michael-arestad, @folletto, @mapk, @sonjaleix, @saracannon, @liljimmi, @joen, @empireoflight
As of today we have a new design rep, @empireoflight! Ben brings a different area of design focus to the rep team, so please join me in saying congratulations to Ben.
Props to @empireoflight for notes. This post is just the notes, in the second post later today we will include the actual tasks broken down.
Props to @folletto for the sketch during our discussions and @saracannon for the photograph.
The next few weeks are going to see a lot of posts as those of us that went to the Community Summit and WordCamp Europe update you all. This is the first of many, this time focusing on the weekly meetings and way we keep up to date with each other.
During the summit communication and support were strong themes, along with how we can all work across teams, making design better for the entire project. A few decisions were made and we would like to try them. As with anything, we should consider this something that can be iterated on.
Wow that’s a lot we are going to do! The hope is this really gives options for people to join in. The #design on Slack is not going anywhere, you at any point can drop in there and ask for help or discuss design – please do!
As already mentioned, lets see this as an experiment and review in a few months.
As of this week the weekly design meeting format is changing until at least July – we can evaluate after that. Instead of a structured meeting, there will be an office hours format. The first of these will be on Thursday 1st June 20:00 UTC. This means that if you want anything looked at or to discuss, just pop into the channel, but we will have no formal meeting.
This change will allow for upcoming travel and give us all time to focus on the core focuses and their design tasks. If we do need to discuss anything, we can always call a meeting.
As always, if you want help with something, or to contribute, the #design channel on Slack is always there. Feel free to drop in and join the conversation.
On 13th April 2017, I ran a user testing session at the Brisbane WordPress meetup to test out the Gutenberg editor. In the process, I also took the opportunity to reflect on the user test itself. Here are my notes on testing the test.
The user test, created during WordCamp London contributor day (a big shout out to @martinlugton, @j-falk, @lucijanblagonic, and @karmatosed for the hard work) consisted of 18 tasks. In my session, the set of tasks took around 21 minutes to complete on average.
The test was set up as an observational user test. The script gave the participants a task on each page, and asked them to rate the experience on a scale of 1 (bad) to 5 (good) scale. There was also an area for comments to be typed in. A sample question is shown below.
In my session, I ended up with 3.5 hours of video footage, which took about 20 hours to process.
The tasks were very clear and unambiguous, perhaps with the exception of Task 2: You want to change the heading to a subheading. Some participants got hung-up on trying to make a heading, and inserting a sub-heading below it, but overall, this was a really minor issue.
Another minor suggestion is to remove the leading phrase “You want to…” from each task description. This is purely to reduce the number of words in the instructions, so that it takes a little less time for participants to process what to do.
After running through a few participants, it became clear that the first few tasks were the hardest in the test. I’d suggest re-ordering the tasks to give a few easy wins for the participants, before throwing them into the more challenging waters.
Suggested task order: Task 1, Tasks 5-9, remaining tasks in order.
The test was quite long, however, I don’t think this was an issue in the administration of the user tests… only in the video post-processing phase.
To make the video processing a little easier, it would help to make each question a different colour. This would make it a easier to find the right video segment when looking at each participant’s reel:
While it is always really tempting to include survey style questions to give us immediate feedback and nice, easy to graph results, I am not a big fan of including this type of question in observational user tests.
The reason for this is that there is often a big disconnect between how a user performs a task, and the rating that they assign to the task.
Looking at this particular testing session, here are some interesting discrepancies:
Participants really hate getting things wrong, or disappointing the tester, so will tend to rate things higher. Although it is more time-consuming, I personally find that you get a lot more insight from observing, and really listening…
“I would like to see the [heading] options go to H6 to be totally honest… in my experience, I generally probably only use H1 to H2… H3… very rarely will you go down to H6.”
It’s not unusual for participants to claim that they must have a feature, or can’t live without something, only to tell you a moment later that actually, they never use it!
Congratulations to the WordPress folks who put this test together. While I have some nerdy, fine tuning suggestions and changes, it is a really well thought out test and made for a great and enjoyable testing session.
Happy Testing, everyone! If you are new to user testing, or just getting started, check out my tips here.
After a break we are back with weekly meetings. This week’s chat is happening today 20:00 UTC.
This weeks agenda is:
Feel free to leave a comment and we can discuss anything people want.
Development on the new editor for WordPress is steaming ahead towards a big reveal at WordCamp Europe in June this year. Last week, I tested the Gutenberg prototype using the community-created Gutenberg testing script (a big shout out to @martinlugton, @j-falk, @lucijanblagonic, and @karmatosed for the hard work on this!).
Here are the insights from the analysis of the 3.5 hours of user test footage. Being a total UX nerd, I also took the opportunity to test the test.
As the user test script contained 18 tasks, the detailed observations and video footage make this for a very long post. If you are after a quick summary, the main takeaways are that participants love the overall minimalist and modern direction of Gutenberg (kudos to all the WordPressers!) and they find the general concept of blocks and contextual menus really intuitive to use, confirming earlier user test results.
The main insights from this user test session pertain to perfecting the finer, detailed-level interactions:
Although some of the things involve some re-learning, so to speak, once people see how to do something in the new editor, the uptake is almost immediate. I don’t think that being different, and involving a little re-learning, should be seen as a deterrent. It’s an interesting tradeoff. People are really excited about the new and modern changes, and I think they will absorb some re-learning.
Participants were presented with the following setup and asked to complete the task as set out in the instructions were placed on the left. The changes were to be made in the Gutenberg editor window on the right. On average, participants took around 21 minutes to complete the 18 tasks in the instruction set.
A total of 7 (+2) participants took part in the test. All participants were WordPress users or developers with a wide range of experience. Two of the participants were in groups of two, the first group was a WordPress developer and his novice user client (both aged 30-50); the second group were two experienced WordPress developers (both aged 20-30). The remaining participants were a mix of WordPress developers (the first aged 20-30, the second also aged 20-30), experienced WordPress administrators (the first aged 30-50, the second 20-30), and a WordPress novice (aged 50+).
Participants really liked the clean, modern feel of the Gutenberg block style editor. There were no observed barriers to using the editor in a general sense: participants were able to get in there and change text to complete task one without any major issues. They commented favourably about the contextual (floating) menus and were able to “get” these quite intuitively.
Yes, I like this… the required tools up the top… so the tools are coming to me instead of me having to track them down.
Contextual menus make things easy.
In the second task, there was some confusion about the meaning of “sub-heading”. We thought that it perhaps detracted from the task at hand. Some participants focused on creating a heading, and adding a sub-heading rather than changing the heading level of the existing heading, as was intended by the task.
Some participants noted (and were confused) by the H-zero label on the top level heading, while others took a while to understand that H0, H1, H2 corresponded to different levels of headings. One participant made the suggestion that these should be called Heading, and Sub-Heading as these terms have meaning to people who write blog posts (as opposed to designers and developers).
I’m not used to seeing H0… to me, you have H1, and your entire universe lives below that.
Does H1, H2 make sense to people? If you are in publishing or in web, it’s very familiar but for “my mum”, would she get it? NO. Sub-heading, heading are more useful terms than H1 H2.
The interactions in this task began to highlight the importance of getting the fine-level behaviors perfected. As an example, throughout the user test there were cases where clicking in the block, or highlighting text in a block, did not activate the contextual menus. This observation led a lot of participants to look for these menus in other places. We lost a lot of people down the “right click menu” rabbit hole – in my tests, the right click menu was the default Safari browser menu, which turned out to be the source of a lot of confusion.
A second example that can be seen if you look at the footage closely is that participants were not making the distinction between block-level menus (the dropdown that switches between block types) and the content-level menus (the buttons that apply actions to blocks). This is evident in the footage from this task when you look at how many people click on the drop-down list in an attempt to create a sub-heading.
This task proved to be surprisingly difficult. Almost all participants expressed that they were expecting the blocks to be drag and drop enabled. Many intuitively looked to cut and paste as a way to move blocks around (the expectation was that keyboard shortcuts and/or right-click menus would work).
I believe that overall, much of the difficulty in this task is attributed to the cognitive displacement that happened when the block-move arrows were clicked. Participants were quite confused as to what happened when they clicked the up and down arrow. It’s possible that the right kind of animation on block move will help to reduce the displacement and improve the move experience. Adding drag and drop, and keyboard shortcuts for cut and paste are likely also must have features.
As a general observation, block insertion was really hard for participants. In this task, participants were unable to insert a paragraph at the top of the page. When prompted, they alluded to wanting some kind of element that would let them insert a new block – either at the top of the page, or more generally, between blocks. A number of participants can be seen exploring the move block arrows to see if there is a way to add a block above/below the current block from this element.
I am looking for something up here [top of the page] to add it [new heading block] in… so is that the only way to add things in? To add them to the bottom and then keep pressing up, up, up?… that’s less than awesome.
For the participants who were able to add in a new block, a number can be seen to not notice that a new block has been inserted – to many it just looked like an extra whitespace, not a new block. Once again, the detailed level interactions of inserting a block, and possibly giving it a stronger default presence and/or animation on insertion would help to improve the issue.
Oh… the new block is not focused when added, so it just looks like an empty whitespace.
This task was completed with no observed issues. There was an expectation that the keyboard shortcuts would work, which they did!
This task was completed with no observed issues. Only a few participants noticed that two returns created a new block. One participant tried backspacing to see if the blocks would join back up again – which they did, as expected.
This task was completed with no observed issues. Participants expected keyboard shortcuts to work. A few wanted the ability to test the link to see that it was correct.
This task was completed with no observed issues, however, all participants selected the text, then clicked align. No one noticed that “align” was a block-level action.
This task highlighted the power of the block editing concept. The interaction with the image block, complete with the placeholder text for the caption was totally intuitive to use.
There was a glitch that was noted by one of the participants in the caption field – when they tried to backspace, the cursor jumped to the end of the word.
This task was completed with no observed issues, however, a few participants raised questions about how this would work with themes. A few expressed surprise that the image changed size, but I suspect this was related to the terminology in the task instructions related to “alignment” versus “wrapping.”
I expected it [the image] to keep it’s size. It was simple to do [right align] but had an unexpected result for me
A number of participants noted that the image looked really strange when floated right next to a heading block, as this created a bunch of white space. One suggested that some blocks should be made “full-width”, i.e. not allow images to be floated next to them.
Although this was not directly mentioned by the participants, I suspect that they would have found image resize handles quite natural in this block.
This task should have been quite trivial but raised a couple of interesting observations. Firstly, tooltips are needed on all buttons. Almost all the participants can be seen pausing before clicking on the full-width button. Some directly expressed that a tooltip would have been welcome.
…I wonder how this would work outside of this… how this would work with templating, most templates would have a wrap around the entire contents section… I don’t know how this would work with most themes, or anything with a side-bar as well. So I think that’s a pretty cool feature but I wonder how that would work in real-life templates
Some participants struggled with understanding what full width meant, in the context of the text being presumed as being full width already. I suspect that a slight terminology change could resolve this issue, perhaps full-bleed or hero image (we’d have to test these :-).
I guess that’s full width… it’s funny… I thought that this part down here kind of counted as full width, not the full page… so that was a bit unexpected
This task was completed with no observed issues. One participant pressed backspace twice and deleted the whole image, which raised the issue of keyboard shortcuts for undo.
This task proved to be a little hard as participants had trouble finding the quote that they were supposed to edit. For those that found the quote block, changing the text was not difficult.
This task highlights again the lack of distinction between block level and content level contextual menus – you can see participants exploring the block type switcher dropdown and the two quote type buttons and being unsure about what these are.
A number of participants also noticed a glitch in the link part of the quote block. Clicking into the link part of the quote did not always show the link button in its active state, and sometimes, did not display the URL in the add link dialog.
This task was conceptually easy to complete, but without exception, proved to be really fiddly as editing the last digit did not include the edit in the existing link. This caused all manner of fiddling around by participants. Kudos to @spocke for implementing the new link boundary feature coming soon to TinyMCE which will (hopefully) eliminate this user angst forever!
This task was conceptually easy, but re-surfaced some of the glitches around link insertion. From observations of the user tests, it would be really handy if a first click in the attribution link section selected the entire link. This should be the case with the updated link boundary in the next release of TinyMCE.
This task was completed with no major issues – most participants had already noticed the quote style buttons and changed the quote style easily. There were a few participants that did not get the quote style buttons, and proceeded to jump right into the right click menu rabbit hole. You can see some using the font menu to apply italic font, and marking their task as completed with success.
This task should have been completed with no issues, however, it re-surfaced the difficulty that participants had in creating (inserting) a new block.
“Now this is where it will get more difficult as I still can’t see an easy way to get text [a new block] in…”
Participants liked the pre-defined structure of the quote, although found it tricky to click into the attribution section. Some managed by tabbing into the field.
This task was completed with no observed issues. However, only two participants noticed that the conversion from quote to paragraph made them lose the text that was in the attribution field. One of the participants remarked that it may be a good idea to concatenate the text from these fields, rather than lose it.
As a side observation, this task raises the question of whether it makes sense to permit block transformations that can result in data loss? For example, converting a paragraph to a quote makes sense, but does the opposite (quote to paragraph) make sense, or will it lead to unintended angst over data loss?
If you’d like to conduct your own user testing session, follow these setup instructions from the Make WordPress Design team. To learn more about how to conduct user tests, and what pitfalls to avoid when testing, check out my post here.
