Random Thoughts on…Six Months of Using Gutenberg

It's been a little over six months since I wrote my first post in Gutenberg (and it was about Gutenberg). In that time, I've published 18 posts using Gutenberg. It still has ways to go before I think it's going to be great, but it's continuously solving my needs on this site. When I originally posted my comments, I posted a mix of ideas, bugs, oooh-moment features, and reactions. Some of them are worth revisiting:

  • It’s pretty. And Fast. I never thought of the post editor as being slow, but there is something about Gutenberg that makes it feel fast.

    This is still true! Overall I’m still impressed with how fast things feel.  And as some of the clutter pieces have been removed, it’s gotten even prettier. 

  • There are a lot of rough edges. It’s hard to know what is a bug, what is intentional,  what just hasn’t been done yet, and what hasn’t been thought of.

    It is becoming clearer what is a bug (and they still exist), what needs another riff, and what is just new to me.

  • The default state is likely my favorite “Distraction Free Writing” implementation in WordPress yet. I’m simultaneously able to focus on my content, and yet I have all the tools I need for writing. I don’t yet have all the tools I need for content creation.

    Creating content in Gutenberg has only gotten better.

  • I need to take my hands off my keyboard more than usual. Adding a paragraph after a list isn’t easy to do with just a keyboard.

    It’s more keyboard friendly, but still has steps to go before I can really not use my keyboard. 

And now for some new thoughts:

  • I like the direction Gutenberg continues to head in, but there are a number of edges that continue appearing rough. Some of those are the micro-interactions that continue to be iterated on, while others are the result of bugs (copy and paste right now is rough). 
  • Developing software in the open is hard. I'm continuously impressed with the Gutenberg team's ability to take critism and turn it constructive. 
  • Once better documentation is in place, I think we will start being at a point that we can consider when Gutenberg is merged into Core. I view the lack of great documentation as being a blocker for that discussion. Until it's easy for plugin developers to support Gutenberg, they can't build much and until things are built, it's hard to figure out when Gutenberg is ready to ship.
  • I think the documentation is going to need to tackle things from multiple points of view:
    • How to use all the various extension points. 
    • How to create automated tests
    • Advice on making decisions/Philosophy of what extension points to use (I'm hoping some designers write this)
  • I'd like to see some iteration around the taxonomies in the sidebar. In part to make custom taxonomies easier and in part to see if there are ways to make it easier. 
  • I'm going to be building something for production in February and am seriously considering building it in Gutenberg so it's more future proof.
  • This post was the first time I needed to use the classic text block. Blockquotes and paragraphs inside list items might be an edge case, or perhaps the list block is too rigid. 

I'm going to try and remember to post more thoughts on Gutenberg in another six months. I think it will be in WordPress core by then, but I'm not sure if 5.0 will have been released. For others that have been using Gutenberg for a while, how has your opinion changed? 

Random Thoughts On….Product Engineering

For the past 5.5 years, I've been a part of the product engineering leadership at a couple of organizations. While I'm not sure if these ideas translate to client services, I know that they have all been valuable to me as I work long term building products and brands.

  • It's important to periodically reevaluate your tooling and process. Iterating on the process can be just as important as iterating on features. As a team, you are able to take all that you have learned about how you work and try to improve upon it.  It's important to not do this too often though, otherwise, you are spending your time chasing something shiny rather than building something that solves problems. 
  • Users over business requirements. Users over short-term wins. Users over everything. If you aren't building for people, your motivations are wrong and you need to rethink what you are doing. Always think about users. If you are discussing working on anything and no one has asked how it benefits users, ask that question. 
  • Implementors need to have control over either the schedule or the scope of a project. Giving up both leads to burn out and/or low quality work. Implementors mean everyone actively contributing, and not just the engineers. 
  • Design is more important than you think. Design is not done at a specific point. Designers need to be involved in everything. Yes, even the most underhood back-end project. Design thinking is undervalued. I've yet to see it be overvalued.
  • Share your work and ideas internally early and often. Even when they are half-baked or you don't think they are very good. 
  • It's important to understand that what is a high priority for you, isn't always a high priority for the team. That said, every member of the team should have at least one personal priority accomplished on a regular basis.
  • At least once a quarter, you should do a sprint focused on developer experience, refactoring, and bug features. Keeping the code easy to work with shouldn't be forgotten.
  • Do things that don't scale, but make them scale if you keep doing them.
  • There are a lot of things you can optimize for and deciding what you want to optimize for is a challenge. Sometimes you need to optimize for Time To Launch, others you want to optimize to make it easier to iterate on the UI. Figure out what's important on a project by project basis.
  • Don't forget any of Akin's Laws of Spacecraft Design, especially number 1.
  • At the end of the day the rules for success are 1) keep the site up 2) faster is better than slower 3) experiment with everything else

WordPress Core Committer Stats: 2017

2017 is coming to a close, and unless someone commits something very soon, WordPress Core development is at rest (since we have an API to do that now). This is the third year I've compiled these stats, see the 2016 committer stats for some of the background information. I'm going to share the stats and then share my reactions to seeing them.

An important caveat, in the post I'll mention employers but we need to remember that people change jobs and that not everyone works on donated time. In fact, the vast majority of WordPress core committers are volunteering their time when they review, write, and commit code to WordPress.

2017 will end the year with 1731 changesets to trunk.  This is down from 2967 last year.  These changesets were committed by 35 individuals, down from 37 in 2016.

2017's most prolific committer was Sergey Biryukov who was responsible for 20.57% of all WordPress commits. He takes this crown from Dominik Schilling.  In raw numbers, Dominick had 4 more commits in 2016 than Sergey did in 2017. This is the first time since I started keeping these stats that a non-release lead has had the lead.

Other notable committers (by volume of commits) in 2017 were Weston Ruter (18.14%) and John Billion (11.84%). 

The employer who was most responsible for WordPress commits this year was Yoast with 24.67%. 14 different employers (grouping all the self-employed individuals into a single group for this purpose). This is down from 20. In 2016, Automattic was first with 14.66%. 

Thoughts and Reactions

The number of higher volume committers is down substantially. In 2016, 17 commiters had at least 52 commits, in 2017 it was 11. Only 3 individuals had over 100 commits in 2017, while in 2016 it was 11. 

The number of core commits and committers continues to fall, but that's in part due to projects like the rest-api and Gutenberg being developed outside of Trac. If WordPress continues to move away from the monolithic repo model, I think this trend will continue. Additionally, with only 2 major releases and no new default theme, there was less to do in core (and many people that were active in Core development have devoted themselves to Gutenberg, the new hosting team, and other WordPress efforts).

I also don't think that it can be ruled out that as a complex piece of software with moderate (at best) automated test coverage, people tend to be cautious and risk-averse. Increasing the automated test coverage should help with these efforts. 

Finally, WordPress does continue to improve. It had two major releases in 2017 bringing some long requested changes to a large swath of the internet. Commit numbers is far from a perfect metric. Some people it takes one commit to get right, sometimes it takes 3 commits to not break the build when landing something. Looking at it and watching it in context of everything else, we can see that WordPress is setup for an incredible 2018.

A Sabbatical from Speaking in 2018

Normally, when a year comes to a close I start to brainstorm about talks and presentations I want to give in the coming year.  I copy over a doc in Simple Note and start pruning off talks I've already given or ideas that no longer excite me and add in new ideas where I feel like I have something to add. This year is a bit different since I'm going to focus my energies elsewhere and will not be giving public presentations in 2018. I still intend to contribute to the conversations around technology, but in a different way (read on to find out more).

What's driving this decision

I came to this idea after spending some time re-evaluating how I spend my time. The talks that I prepare generally involve about an hour for each minute I present. In 2017 I gave presentations at WordCamp Lancaster, Pressnomics, WordCamp DC, and WordCamp Philidelphia. Overall, I spent nearly one hundred hours preparing for and delivering these talks. When I think about my hopes for how the web moves forward, I wonder if those 100 hours couldn't be spent doing something with a bigger impact.

Additionally, I don't bring a lot of diversity to the table. I'm a mid 30's cis-gendered white-passing male.  There are plenty of us in technology. If I move out of the way, that can hopefully make space for someone to bring a different viewpoint to the conversations.

What I'm doing instead

I still love public speaking and want to help some newer speakers give great talks. I thus intend to volunteer and donate my time helping some speakers. If you have enjoyed any of the presentations that I have given and think I might be able to help you, please send me a DM on twitter (my DMs are open). I'm going to give preference to people that bring some diversity that I don't bring to the table. I'm hoping that as 2018 comes to a close, I can say that I spent 100 hours helping new voices in the conversations around technology.

My WCUS 2017 Watchlist

I didn't make it to nearly as many WordCamp US Sessions as I would have liked. This year was packed full of quality talks.  Rather than leave a bunch of tabs open, I'm going to list out all the talks I hope to watch here.


There are more talks that still need to be uploaded, so this list may grow.

Check out the rest of the WCUS 2017 videos, you just might find something that inspires you. 

Getting started with Jest

In the past, my automated testing for javascript was done in either QUnit if it was a browser app or Mocha if it was a node app. On a new project, I decided to kick the tires on Jest and thus far, I really like it. It did have a bit of a learning curve through to get it up and running, but now writing tests in it feels natural and is going well. Here are a couple of things I've learned thus far.

Jest defaults to an outdated version of jsdom

.jsdom added support for HTMLElement.dataset in a recent version. However, due to minimum node version support differences, Jest by default uses an older version of jsdom.  Switching to the latest version though turned out to be fairly easy. I installed jest-environment-jsdom-latest and changed my package.json to run jest with "testEnvironment": "jsdom-latest". Alternatively I could have used --env=jsdom-latest.

Steal Configs From elsewhere

It's really easy to run down the rabbit hole of learning everything about how to set up a tool before learning if you want to actually use it. To get started, I stole some of the config from an ejected create-react-app application and looked at the docs for using jest with webpack. That was all I needed.

Use .resolves() for your promises

Unwrapping a promise and using .resolves() allows me to easily unwrap promises and keep my expectation in a single chain.  It feels as much like magic to me as promises did the first time I used them.

Additional Resources 

Overall, I'm excited to continue playing with Jest. 

Three Years as a WordPress Committer

Three years ago today, I changed three lines of code in WordPress and did it without someone else signing off.  In fact, I didn't write the code that went into WordPress that day.

I've not been a high volume committer in my three years ( I've made 283 total commits), but I have had the pleasure of working on user-facing features such as Shiny Updates for plugins and "Logout everywhere" along with helping to maintin multiple underlying components. I also had the honor of being a deputy release lead for WordPress 4.7.

Here's to three years of helping to democratize publishing 🍻

Falsehoods Programmers Believe about Versions

Inspired by the list of falsehoods programmers believe about names and falsehoods programmers believe about time, here are some Falsehoods programmers believe about Versions and some examples of the falsehoods.

  1. Versions are always numbers
  2. When versions are numbers, they will always be sequential (See PHP 6)
  3. Software never changes how they use versions (see Firefox)
  4. When Software uses X.Y. Z , X is always the major version number (see WordPress
  5. Versions always use periods to separate numbers 
  6. Version numbers never decrease
  7. Semver is the only versioning standard
  8. 1.0 is always the first public release
  9. 1.0 is always a stable release
  10. There will never be a time when the second or third number in an X.Y.Z. version exceeds one digit. 
  11. Major version number changes always mean backward compatibility changes.
  12. Minor version number changes never mean backward compatibility changes. 
  13. Version numbers are never adjusted due to superstition
  14. Version numbers are never based on mathematical jokes (See TeX)
  15. Internal version numbers are always the same as external version numbers
  16. No two releases will ever have the same version number
  17. Version numbers are always base 10. 

Why I love Captioning for Conferences

I had been to conferences with live transcription before, but SRCCON 2014 was my first time seeing them at a mainstream conference. The transcription services even inspired a battle between a debate champion and the captioner. Three years later, and I’ve gone back the transcripts a few times a phrase or remind myself of the conversation. I am generally a person without any hearing related disability. I’m sure years of playing music, working concerts, and listening to headphones has left me with some hearing loss, but in general, I can hear at conferences. Except sometimes the room is loud. Or a person near me is talking. Or the mic isn’t held close enough to the speaker. In those cases, I’m reminded of one of the top reasons I love live captioning for tech conferences.

Anyone in the room can become a non-hearing person

Anyone has been to a conference has sat near someone that needed to comment on the presentation while it is going on.  I’m sorry if that person was me for you. Having the ability to see what was said, helps me when I miss something that was spoken. Real-time captioning also allows the audience to be less focused on taking notes since the talk is already available in text. Some people are less auditory of learners and thus the written record allows them learn using a method that works better for them.

Transcripts allow the speaker to see what we said

Like many speakers, I have verbal ticks that I fall back on. Transcripts allow me to see how many times I say “you know” or begin a sentence with “so”. The live transcript can also be utilized to help create a blog post from your talk.

People need it to attend

As much as captions help me, they can make the difference between someone being able to learn at an event and someone not being able to learn. 360 million people have disabling hearing loss. Captioning of conferences can help make it possible for that otherwise could not participate to participate. The other day, a video made the rounds of a man being gifted Enchroma glasses and experiencing color for the first time.  Helen Hou-Sandí asked the question “What if we thought about web accessibility work as bringing these moments to people?”  What if we also thought about event accessibility as bringing these moments to people? The right to learn is the right to earn. Education, both formal and informal, is the foundation for advancement. Captioning can break down a barrier that prevents people from learning. By enabling all people to learn, we enable all people to earn.

Gutenberg and Publishers: unconference notes from WordCamp for Publishers

At WordCamp for Publishers, I hosted an unconference session on "Gutenberg and Publishers". There were forty people overflowing a conference room who worked at agencies, publishers, universities, hosting companies, as freelance developers and writers, and one person who described their affiliation as "I left my backpack at the bar last night and lost my name badge, and that's representative of my professional career."

The people in the room had all largely used Gutenberg in some way before the session. Almost the entire room had at least 5 custom meta boxes on the editor screen, over two thirds had at least 10 custom meta boxes, and a few had more than 20. The vast majority used custom taxonomies, many of which had at least one using a UI other than the default taxonomy UI. 

After everyone introduced themselves, I gave a brief introduction to Gutenberg, including demonstrating some of its features. I also explained the block based approach, the desire to eliminate mystery meat, and that Gutenberg is still in very active development with things changing all the time.  After that, I kicked off the discussion.

What do you view as the biggest challenge for publishing companies in making the editor better?

  • Long form layouts. Even with something like short cake to render short codes, you still don't get the full-width experience that you do in a full post. A lot of bouncing back and forth to compare sizes.
  • Everything hooked on to save post and how that negatively impacts the actual saving experience.
  • Collaborative editing and the work around to collaborative editing, which is moving from a thirdparty tool, Google Docs, some other workflow. Bringing that integration into WordPress.
  • Allowing users to preview a prepublished preview version of the post in, the home and the category views. Platform Preview: How do posts look different on different size devices, different platforms, whatever.

What are the customization points that matter most Publishers for the editor? On your site, what's the most custom part of the editor in your eyes?

  • Probably our biggest anxiety around Gutenberg, what is the fate of that metadata management system under the new Gutenberg regime.
  • Taxonomy customization comes in multiple forms:
    • A taxonomy that's a single value, a drop down for it.
    • A taxonomy that can have zero or one with radios and a "clear" button.
    • We'll group multiple taxonomies together in a single meta box that maybe has a repeating field either an autocomplete or a drop down where you select. So there might be five taxonomies which each can have multiple terms.
    • I've had numerous times is where I want a hierarchical taxonomy, but I wanted to limit to two levels. And another is a really long list of taxonomy terms. And so I want to get an audit complete. And then when you select one, it adds to the list of ones that are selected. And have a check box next to the ones that you decide you want to do later. So there's a whole bunch of different ways to do taxonomy.
    • We end up doing a lot of custom validation around taxonomies. We check this one taxonomy, you can check three other of this other type, or X, Z, Z. And right now, I think there isn't sort of a builtin validation mechanism to do enforcement on the layout or on taxonomy.
    • So a couple that I've used as well, in addition to the ones mentioned, is where taxonomies can't be you can choose taxonomies, but you can't add new ones. I think that's probably fairly common.
    • Taxonomies where you must select one, but there's no prepopulated one. There's no default. And taxonomies where you have to select one before you can save the post as well. And it has to pass a save checklist validation thing.
  • I think just validation in the editor as a whole is a wonderful thing that can help us, as developers, make richer experiences. So I can think of other use cases beyond taxonomies. But say like someone has a rich media embed. Is it tagged correctly extremely in another place? Say someone has a citation they're using. Has it been factchecked? Has it been proven? Validation is currently very difficult. Unless you're doing something extremely custom. Which takes a lot of time and a lot of maintenance.

What other hooks for validation do people think are needed?

  • Knowing which block is above and below in some way so that you can enforce not stacking seven videos on top of each other. It's really easy to write a beautiful post in Gutenberg and it's really easy to write a horrible post too.
  • We work with a lot of news agencies. And something that they have been asking us about is how to handle packages. This article has a sub, a side bar. This article has eight photos connected to it. Plus, a graphic, plus, an opinion piece. It would be really great to be able to create that kind of content, either taxonomy or association for future output. 
  • Per context, content. Because for us WordPress is the entry point for web, mobile, and print. So right now we have a tabbed interface with multiple tiny MCE editors to prepare content for all three. Videos make no sense for print. So with Gutenberg to switch over and see the printenabled blocks, but not see the webenabled ones. Or native. Because native will only support certain things too.
  • One opportunity Gutenberg might have is less developercentric and more journalistic is, so if you decide on an atomic unit of writing called the Block, you could annotate this. And you could preserve reporter's notes as to the source of the information. This was from an interview. So a year from now, that reporter is long gone. Right now the source material is lost, scrawled into paper notebooks and stuff like that. So I like that opportunity for this. Each Block could have a source that is published or not published or whatever.
  • One point to accept further on your note about comments within block level, it would be awesome if there was a hook to create additional kinds of data. So not just comments, but also, again, I'm thinking back clarifications. I'm thinking custom meta about meta. Which is weird to say, but it's useful, because at some point when we have to look at this, if a copy editor comes in and wants to look at the posts and validate or triple check, whatever that might be, having a starting point or a place to view all that information, that doesn't sit there baked on the side under the context menu. But you can view that directly next to it.
    • That opens up possibilities around having blocker paragraph levels. Like this has been signed off by the copy editor. Like the collaborative features. The photo editor signed off on a picture. And then you can easily view what paragraphs haven't been signed off. Or if a paragraph changes, the sign off automatically turns off and it needs to get resigned off on.
    • And if there are tasks associated with that article that have to go through revisions or approval or whatever might be. Those become part of the dashboard. An article requires work? Who has to do that work? You can associate more information beyond just the article. Even though we currently do this in our own individual workflows, some of the workflows can be sussed out by having the additional information.
    • Kind of along those lines, the side effects of editing a block. One thing I want to point out. It's built with React and Redux. If you're not familiar with Redux, when things change, you can see the actions that have been changing. And you can hook into those changes and do something else in WordPress, right? So you have a block or let's say somebody is typing a paragraph and you just find that, okay, this is for a publisher, we need to factcheck every paragraph. Whatever. You can have that, as they finish the article, use Redux to send that off to validation server as they're writing the next block. And if it doesn't pass validation or fact checking, maybe the state changes and it's highlighted red.
    • And actually, I can't validate that you talked to this person. And they respond on a different system using the heart beat API or whatever. And within 15 seconds, you my light that, they're off working fact checking. I'm still working on content.

Data Storage

  • Would it be a good idea to maybe have an ability to save this in a JSON format and keep that all together with its own components being stacked? So I think that might help a lot of us. Especially if you're doing things that are WP API based. And headless. 
  • The HTML comments as structured data is Shortcodes reloaded. It's too easy to break. 
  • It's certainly possible to store data elsewhere and then hydrate it for the editor. 

Other Observations and thoughts

  • We do have prototype support for WPGraphQL for Gutenberg. It uses the blocks parser to transform the content. 
  • Gutenberg opens up the possibility for front end editing in the customizer since it's also essentially a sidebar and main content area like Gutenberg. 
  • We had an idea we played with in shortcake for a little bit which was contextual rendering of the short code so, for instance, to say it's a YouTube embed that's being rendered under the RSS view. Maybe you don't want us in the iFrame. You want the YouTube API and get an image instead to replace it. I feel there's a lot of adaptive content ideas you could play with around that.
  • For us, posts end up being three different pieces of content. So if they need to fix a typo in one, it's three spots currently. With something like that, if you had context for a block, it would be the same source of truth. If they change here, the context is just a visual thing.
  • I don't know if this is being thought about but right now you go to get a new post and you basically, have a blank screen, a blank canvas. And if you have task workers you want to, give them a bunch of different things to fill out. I don't know if that's part of the vision to be able to create those task worker forms as well.
  • And another is kind of adaptive posts where you start entering things in and depending on what you select, I'll use the term "Post type" here. But I don't mean specific post type. You select certain fields and get different subfields that you would be able to fill in.
  • There were two ideas that came from a workshop yesterday. I wanted to share these with you. One of them was, building in the blocks themselves rules and best practices. So, you know, that could include things like a link catcher sort of validation process. Another one was to integrate context into distribution. This block will work better at this time. Or in these conditions. 
  • I think a lot of what we're talking about with the blocks with, deciding AMP versus mobile, what it all kind of boils down to is setting specific custom meta for the blocks individually and then saving them as a whole. That would allow you to do your different views because you would be filtering out based on just, I want to see just the AMP version of this. So anything that is either not flagged general or AMP, I'll just not put in. But I have no idea how that would work elegantly in the comments. The current system.

Closing Thoughts

After the session, a few of us chatted further.  One of the ideas discussed was a "Block Council", essentially a group to collaborate on blocks so that there aren't 15 different Facebook blocks floating around (i.e., issues we all see with widgets and plugins). Overall, there is a lot of anxiety around the unknowns of Gutenberg, but most of the people are excited for what Gutenberg offers. There is a lot of work remaining, but the more people that can be involved, the more likely Gutenberg is to be successful.

This post would not have been possible without the transcription by Amanda Lundberg from White Coat Captioning who live captioned the session. Most words are direct from the speaker's mouth. Some have been lightly edited for easier reading.