WordCamp Milano testing the Gutenberg tests

At WordCamp Milano contribution day the tests recently written about here. Thank you to everyone that helped. @emanuelblagonic gets a shout out for helping co-lead on the day.

So, what happened? Well we started by running the tests. They were self run by people who hadn’t done the tests before. We had about 3-4 people doing this. From there others split into testing on another person and also into even testing on mobile.

It’s worth noting this is a brief overview, as the tests are run through bugs will be reported and enhancements made. However, it’s good to report early as this was a test of the tests.

The stats:

  • Task C: 2 tests
  • Task B: 4 tests
  • Task A: 3 tests

Videos collected: we have 9 videos collected from the testing. These are still being processed. One test was on mobile, the rest desktop.

The test changes

Based on the feedback we got a few things were changed:

  • Wording was made more explicit.
  • The image to make up itself was changed and copy provided as this was big piece of feedback as an issue.
  • Task B was easier than task A so we modified this.
  • Video uploading was an issue and we now have a Google drive to use.
  • The age range was better at 50-60 and then 60+

Gutenberg changes from test

One major thing was adjusted, the block toolbar was put back by the block, over being fixed. This was something previous tests had suggested worked, but in testing it really didn’t. We still have the switch and more A/B testing needs to happen with a wider audience.

Interesting feedback

One ‘food for thought’ feedback was this that when saying ‘make this image’ one user looked for a block that looked like that. It is important to note and see if this is common. We could direct more, but we maybe can hold this to review.

Thanks to everyone that helped run the tests, your work counts and by testing we make Gutenberg a better product.

Don’t forget there is going to be testing happening at WordCamp US. If you are attending, please sign up to help with the tests or come along and discover Gutenberg for yourself. We’ll be sure to post here the findings.

Writing my first Gutenberg Block

Inspired by a comment I read a week or so ago, I wrote my first Gutenblock. Here are my impressions of that process.

I initially planned on copying an existing block, but quickly found the example in the blocks directory README.

This is the ultimate result, you should open the example and the result to follow along how things changed.

Getting from one to the other was not too tricky, but did have a handful of surprises and confusing bits.

I started with changing the block name, which caused the first problem – I got an error that it needed to be namespaced. That was easily rectified.

Changing the title was easy enough, but I didn’t know what I should change the category to. I got an error when I left it blank, so I set it to common.

Next up, changing the attribute definition. Changing the type to ‘int’ was a lucky guess, there was nothing to suggest what the valid types are. source confused me for some time, as I didn’t really know what it needed to be. I figured I needed to store the value as a data attribute on the HTML that Star returned, so I wrote a basic version of the Star element, and tried to save it there. It… didn’t work. I tried several variations of this before noticing in the docs that source is optional. So, I tried deleting it, and it worked! That bit of magic made me smile, but I was a bit annoyed I spent so much time on a non-problem.

Writing the setStars() method was easy enough, even without really knowing what the props.setAttributes() call did.

Trying to add the Stars render to the children array gave me a weird error, complaining that the element needed an identifier. I tried adding an id attribute to the HTML that Stars rendered, but that didn’t help. Googling the error message showed me that I needed to set the key attribute, which was kind of weird, and I didn’t understand why it was necessary now, when the example didn’t need it. But it worked, so I moved on.

Adding the input element to children was also easy. I got the same error as before about needing an identifier, so I added a key attribute to that, too. I added all the extra attributes for fun, but realised when defining the min / max attributes that there was no nice way to validate the data being put into the stars attribute.

It was around this time that I discovered the Stars element wasn’t actually rendering, the problem was that I didn’t know how to put the text inside the div element. Did I need to append it? Was there a createTextNode() method I needed to call? As it turns out, it just magically accepted the string, but I only found that out by guessing. (Excuse the hacky math to add the “½”, I got a little carried away.)

One annoyance throughout was that every time I changed the attribute definition, or the output of Stars, Gutenberg threw a warning about the format changing. It seems like this warning would show whenever a plugin upgrade included a block change, though I didn’t test that.

And that’s about the sum of it – I found it to be a generally pleasant experience, it was nice that I could do this all without needing to compile from JSX, but I knew that option was there for if I wanted it. It’s still a bit of a raw experience, but it shows a lot of promise for creating a delightful development experience.

Widgets, Menus and Customize Changesets

Earlier today “converted” a Squarespace user, sat there and watched them struggle with hierarchical categories, pages (and why they don’t show on the site), then creating a menu and adding to it. Then widgets… At the end had to explain how all these work, they were pretty happy to set and use them.

From this user (well, hoping to find more “uninitiated” soon), it looks like a good thing would be to tie creating pages with adding them to the menu. Also adding to the menu on the separate Categories and Tags screens.

Apparently the separate widgets screen was easier to grasp for a first-timer, possibly because it’s all about widgets/not that overloaded with all kinds of (new) things.

Menus were easier as soon as a menu was added to the proper location. However the flow of making a page and then needing to add to the menu so the page shows on the site sucked. It was even more confusing when I tried to explain that a tag can be created and then added to the menu and it will show an “archive” of all the posts that were tagged with it. The separate Tags screen makes this somewhat clearer, and having an “Add to the menu” button/link for each tag would probably be a winner.

Thinking that we need “Annoyingly Aggressive Help” for new users 🙂 Maybe something like a modal overlay when they go to a page that is full of new concepts and “things” (of course that modal will also need “Don’t show again!” button).

I’ve been looking at the discussions around Customize Changesets. They seem like a good idea at first look, but IMHO they are an advanced feature that only few users need, and only a fraction of these users will understand and use. Helping out this person earlier made me think that what we have is already hard enough 🙂

Page revisions

Additional CSS


Theme editing


Plugin editing


Better Dogfooding Tips

This was originally written by @karmatosed. I’ve adapted it for WordPress.org.

Dogfooding is a great way we can use WordPress and test our features. By testing WordPress ourselves, we get to unearth all manner of bugs, issues and fun things. Try setting up a new site from scratch, especially thinking about specific use-cases like a new photoblog, or a company website.

I thought it would be great to come up with some tips for so new folks doing dogfooding can have a resource to start with. So, without further ado here’s just that!


How you present the post really helps for people to read and also how we can use later on. A rough format for reporting your observations via video that works is:

  • Title: Make sure your title has the word “dogfooding” in it somewhere, so it’s easy to scan. Also include what feature you’re testing in title. ex: Dogfooding: Theme Setup
  • Use the more tag to shorten posts. It helps keep the p2 streamlined so it’s easier to scan.
  • Talk about your perspective as a user, and what you’re trying to accomplish.
  • Embed the video in your post.
  • Under the video, pull out any key points at minute marks. ex: 01:00: here’s where I spent a whole minute trying to search for directory themes from my installed screen. Keep this list short; don’t worry about pulling everything out, as if this is long, people will be less likely to read. Just make sure to list the biggest finds.
  • After that, it’s often useful to chop up the video (if it’s very long) and pull out significant clips. Making clips like this is useful for bug reporting and summaries. Clips can go after or next to minute marks, and also next to bugs for easier visual reference. Just consider that not everyone will want to watch your entire video. 🙂
  • Bugs: List out any bugs you found while testing. You can even do a fun thing by putting the bug emoji at end to make them stand out: 🐛
  • Summary: Summarize the main issues and conclusions you found from testing. ex: I stumbled a lot with the theme installation process because… If we did x or y it might improve this feature…
  • Tags: Tag it #dogfooding and anything else relevant.

Here’s what the above would look like laid out:

  1. Dogfooding: Feature You’re Testing
  2. As a user, I’m trying to accomplish x
  3. Video embed
  4. 1:00: something amazing, 2:00: something else amazing
  5. Significant clips
  6. Bugs 🐛
  7. Summary
  8. #dogfooding


If you see a bug, report a bug. It’s important we follow through on the bugs and don’t just leave them on this p2.

The same goes for things you think are issues, or even enhancements. Sometimes you may think of something awesome nobody else has thought of before, and it could become something that changes the life of our users. Pretty cool right? That’s why it’s very important to report on trac.

Enjoy and please dogfood 🐶


This has also been x-posted to make/design.

Shiny Updates User Testing – update-core.php

Originally by @mapk posted on Slack

The first user test on update-core.php:



1. Great confirmation to the recent changes we’ve done.
2. She provides some alternate ideas on how to order the updates in the list: by importance, or by update release date.
3. One of my concerns was whether or not it was easy to identify the different types of updates now that they’re all included in the same list. She was able to find a “plugin” to update just fine once she realized they weren’t all plugins.


“It was a super easy update process”
“if this is the way it is, you should keep it and never gonna think about changing that”

#shiny-updates, #upgrade-install

Deleting a site with iOS app 6.1, iPhone 6+

With the April 4th TestFlight build.

#app, #ios, #phablet