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

#css

Theme editing

#editing

Plugin editing

#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!

Format

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

Reporting

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:

 

Notes:

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.

Also:

“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

Editor, Media: Inline image toolbar obscured by selection, copy edit toolbar, iOS

Taping an image to bring up the inline toolbar results in a selection box around the image and the cut-copy-paste toolbar popping up. Depending on where you tap, the image toolbar can be unusably obscured. Tapping through to the buttons doesn’t always work. Editing posts that contain images is very frustrating on iOS devices. I often accidentally insert individual images into posts instead of galleries thanks to the media modal defaulting to individual insertion. Removing twenty images from content while dealing with the inline image bar is joyless.

Contrast with Android, which is well behaved.

 

#android, #editor, #images, #inline-image-toolbar, #inline-toolbar, #ios, #media, #phablet, #phone