I don’t have a good desk chair

I don’t have a good desk chair.

I can’t sit in my not-good desk chair for very long. It’s not really a desk chair, even, other than that it’s a chair, and it’s at my desk.

It’s just an $80 IKEA side chair, “walnut,” which I feel probably needs to be in quotes since it’s from IKEA. At least it is solid wood, not a hardened slurry of glue and sawdust covered in a “veneer” that’s actually just a paper sticker with wood grain printed on it. Which is a factual description of some IKEA furniture (that does exist in the house of a couple who are on the verge of 50). This chair is undoubtedly real wood.

But a wooden chair is not a good desk chair.

It is not a good desk chair even when it has a memory foam cushion on it. Not even when that memory foam cushion is on top of a silicone honeycomb cushion, although now we are getting somewhere. (But where is that? One of the Amazon reviews of the cushions praised its effectiveness in the wheelchair of its buyer’s nonagenarian grandfather.)

I don’t have a good desk chair.

But do I really want a good desk chair? Over the past year I have converted my workstation to a fully portable setup. I’ve worked with a laptop as my sole computer for over a decade, and now my second monitor is an iPad. I can bring my two-screen setup anywhere.

For years we’ve been told that sitting at a desk all day long shortens our lives. I hate sitting at a desk all day anyway. And years of working in offices, where someone else paid for the series of various “real” (and surely quite expensive) desk chairs I used, taught me that there is no such thing as a good desk chair, at least not for me.

I do not sit with perfect posture. I do not sit in one position. I do not sit back in my chair, so lumbar supports are pointless. Except when I do sit back in my chair, in which case I am usually sprawled low, and the lumbar supports are again pointless.

But sitting perfectly in a precision engineered desk chair all day is still sitting at a desk all day. And when you do that, YOU DIE.

I don’t want a good desk chair.

And I really don’t want a standing desk.

(Neither do my feet, especially during one of my bouts of plantar fasciitis, such as the one I’ve been enduring over the past month as I write this.)

I just want to move around.

I am self-employed, and I have a mobile workstation. So I spend part of the day in my not-good desk chair. I spend part of the day in a lounge chair (IKEA) in our bedroom, with my feet up and the laptop living up to its name. Or that midcentury modern chair (a rare splurge from West Elm) in the living room, again with my feet up and the laptop laptop. Or — now that the weather is finally nice — sitting under the big umbrella at the cafe table we have on our deck, as long as I can find the perfect spot where its metal mesh top is unwarped and my laptop doesn’t wobble with every keystroke. Or in one of the Adirondacks* on the deck, in the afternoon when they’re shaded. Or sometimes even standing (!) with my laptop on the countertop of the pass through between our kitchen and dining room.

I’ve got options that don’t involve a good desk chair.

If I had a good desk chair, I would feel compelled to use it all the time. And then… YOU DIE.


*That would be a molded plastic Adirondack, of course. From Target. We are in our late 40s and still nearly every piece of furniture we own is from either IKEA or Target.

WordPress development in the Gutenberg era: Threading the needle of Block Theme development

As described in several of my recent posts here, I have been working for the past month or so on building my first “all-in” Block Theme for WordPress.

After nearly 4 years of adamantly resisting “Gutenberg” and the new Block Editor revolution — not because I disliked the block concept, but because I disagreed philosophically with the core team’s approach (to what constitutes a block, which types of blocks are important, and which technologies are used to manage the UI of the editing screen) — I am finally accepting that if I am to continue making a living primarily as a WordPress developer, I need to give up on my Classic Editor, Advanced Custom Fields “Flexible Content” approach, and embrace that the Block Editor is now The Way.

One of numerous challenges I’ve faced in this process (on top of the learning curve of a completely unfamiliar method of constructing themes, the dearth of adequate and up-to-date documentation, and the core team’s willingness to allow very unfinished versions of functionality to roll out in public WordPress releases) is figuring out the best way to approach some of the more complex design structures I am used to dealing with via ACF’s Flexible Content fields.

My biggest hurdle is recognizing that what I think of as a “block” is not what the WordPress core team thinks of as a “block”

Here I will admit this is a shortcoming of my own approach. I have been “opinionated” in my development approach (well, about everything, really), and created large-scale and complex “blocks” that, in Gutenberg/Block Editor terms, would really be “groups” or “block patterns,” not blocks. Gutenberg blocks are more granular.

Gutenberg blocks are also static, in that they generally do not interact with database content, or if they do, it is in very limited “bloggy” ways that don’t align with my use of WordPress as a general-purpose CMS.

So I’ve found myself falling back on ACF. I like its server-side approach. I’m more accustomed to dealing with PHP and MySQL. I use JavaScript (mainly jQuery) a fair bit for front-end interactive elements, but I don’t build complex functionality in JavaScript and I avoid AJAX if I can help it.

You can see I’m destined for a strained relationship with the Block Editor.

A concrete example: “Tiles”

One of the most idiosyncratic elements of my old ACF approach is the block I call “Tiles.” It’s a way of creating a set of small blurbs to link to other pages/posts. There are numerous options for appearance: number of tiles per row, relationship between the image and text in a tile, etc. And there are also numerous options for the content source: a specific page or post (with the title, featured image and excerpt automatically pulled in), a dynamic feed from the blog or a specific category (likewise with the info pulled in automatically, except this one auto-updates when there’s a new post), or a completely custom-built tile, where you manually select the image and enter the text and link.

Here are screenshots of the ACF-based editing tools for my Tiles block.

I tried recreating this entire setup as a new ACF-based Block field group. It worked, to be sure, but the complex ACF editing layout really did not feel right in the new Block Editor interface, either in the sidebar (eek) or in the main content area. It felt like a cop-out.

Then I considered creating a block pattern. I knew this would lack some of the benefits of my ACF-based Tiles block, but one in particular: the option to dynamically pull in the details of another page/post, rather than manually entering the text. But as a starting point, I decided to recreate the “custom” tile type.

That, also, worked. But it was finicky and didn’t apply well in a lot of different places. So I realized that instead of creating a Tiles block pattern, I needed to create a Tile block pattern. Just one tile. Instead of a monolithic block that was really a group, users would insert each individual tile into whatever larger structure they want (e.g. columns).

The end result was a block pattern that looked like this (screenshot instead of live code because, well, you really don’t want to use this):

I was really proud of myself for using the new “lock” feature to force the elements to stay in a particular order, but to allow the user to remove elements they don’t need, such as the image, lead-in text, or CTA button.

Still… I didn’t like it. And it didn’t allow for dynamic sources.

Along the way I also finally came to grasp another fundamental limitation of the Block Editor and Block Patterns. Since all of the parameters of the blocks are stored as HTML comments right in the post content, you (the theme developer) can’t update the design of a block pattern once it’s inserted into a page/post. The Block Editor isn’t dynamically inserting content into a template when the page is rendered. It’s making a one-off copy of the template and storing it right along with the content at the point when the content is inserted into the page/post.

This seems, to me, to be a fundamental flaw in the entire Gutenberg/Block Editor approach. It’s bad enough that if I were building it myself, I’d have stopped right there and taken a completely different direction. Maybe there’s a long-term plan to address this limitation, but for now it appears to be here to stay. Which led me back to ACF.

Threading the needle

And that was when I had my insight into the true nature of the problem. It was the fact that what I think of as a “block” is larger-scale than what the Block Editor treats as a block.

So I went back to my Tiles ACF field group, stripped out the repeater functionality and created a Tile ACF field group. Now you’re building one tile at a time, it has all of the previous benefits of ACF’s dynamic integration of content with template functionality, it seems to correctly fit the definition of a “block” in the WordPress sense, and you can still have a flexible presentation of multiple tiles in a group… just using Block Editor “groups” to achieve that.

I still have more to learn and questions to answer (followed by more questions to ask and then answer), but I feel like this was a major step forward in finding a way to merge the benefits of ACF with the… inevitability, I guess, of the Block Editor.

Writers, learn to write

I have decided that my new ultimate pet peeve in writing is people using “formally” when they mean “formerly.” It takes the place of the equally annoying use of “of” in place of “have” (as in, “should of”).

Both of these errors seem to indicate a purely aural (as opposed to vocabulary/grammatical) way of understanding language. Which is OK for an average person; I’m not trying to be an obnoxious pedant. I don’t care so much when I see these errors in informal writing, but when you’re paid to write for a reputable (?) publication, you should know better.

Then again, this issue maybe only happens online, where these supposedly reputable publications a) don’t pay their writers enough to spend time polishing their work before submitting it, and b) don’t bother running these posts past editors before publishing.

Dreaming of a vacation at a Dutch suburban office park in the winter…

OK, so, first off… yes I am a nerd who watches city planning videos. But this is really, really good and eye-opening to anyone in the U.S. or Canada who has ever hated their soul-sucking commute to a soul-sucking job inside an absolutely spirit-crushingly ugly suburban office park. (Raises hand.)

It doesn’t have to be the way it is here. I seriously think I would enjoy taking a vacation that consisted of nothing but hanging out at this suburban office park in the Netherlands. It’s so much nicer than almost any developed place in the U.S.