The early hurdles for PeakZebra mostly had to do with getting tables to display in a sweet, full-function way on the front end. My take is that we completely crushed that particular challenge.
The next hard thing was harder, though. It was the complex problem of how to create custom logic and computation within an application that was build from blocks. Since PeakZebra is all about building apps with Gutenberg blocks, the obvious thing was to reate a block, or group of blocks, that represented the logic flow.
That’s a lot harder than it may sound, though.
In the end, the solution was three initial blocks, featuring a back-end UI that let you select things like the piece of information you wanted to work with by presenting a list of possibilities, rather requiring you to remember the right field (and spell its name correctly).
The three blocks are:
Calculation — Perform some math on data elements, or combine some text strings.
Trigger — Make a comparison that determines whether actions need to be taken. You might compare a person’s age to the minimum age for legally buying alcohol in a given state or country.
Action — Do something that isn’t a calculation (since there’s already a calculation block for that). You might move some info to a task in the task table, for example. Or you might make a new entry in the calendar table.
There are a couple of further blocks in the works right now, but you can do a shocking amount with just the above (heck, Zapier pretty much does everything it does with just triggers and actions, right?).
We’ll be publishing a whole set of recipes for ways to make good use of these special blocks and we’re always ready to work with you to get the application you need.
I’ve known in the back of my head all along that, while there was a place for the multi-field form blocks I was building to capture things like customer names and addresses, the “pure” way of attacking my block-based application building project was to create a bunch of generic fields. This is what existing WordPress forms packages have done for years and it gives you more or less infinite flexibility.
Of course the situation with forms builders is a little different. They let you create forms and then the forms get dumped into an email or a per-form collection of data. You’re not really building an application, but rather a data collector, and something of a disconnected one.
What I knew I’d have to put together at some point was single fields that were not only Gutenberg blocks, but also fields that knew how to interact with each other. You can put any mixture of these fields anywhere you like on a page, drag a “submit” button out there to join them, and then all the collected data needs to be submitted to the correct parts of the underlying database.
Because, yes, there’s an underlying database. This is what gives you the magic application-building capabilities. And it means you aren’t just piling up disconnected data form entries, but that the data winds up in a relationship to all the other data you’ve collected.
I’ve built a couple of prototype single-field blocks in the past couple of weeks and, honestly, it’s cooler than I thought it would be. That’s because I’m free to use React components on the front end. I’m using a library of components from a company called MUI, and their stuff is just prettier and more versatile than you’re out-of-the-box HTML form elements. I’m not saying it’s not doing pretty much the same stuff, but there are all sorts of small flourishes that I frankly just plain love.
While these collections of fields do operate in the same basic way that forms do, there are some differences (in a good way). For one thing, you can collect data that’s headed off to different data tables in the same form and it’s completely seamless from the user point of view (actually from the designer’s point of view as well–you don’t have to do anything for it to work).
Since all these components use a REST API to talk to the WordPress backend, each field can, if it needs to, validate the input to a field by sending the proposed data input to the server to be looked at. So, to take a somewhat contrived example, normal client-side vetting for an email address just checks to make sure the basic format is right (there’s an @ character, there’s a .com or .whatever). But you could, if you wanted, send the email back to the server, which could ping the mail server to make sure it was really there. Not saying this is generally worth the trouble, but it’s nice to know you have the option to do some actual sanity checking as you validate field input.
I’m not quite sure when the individual field blocks will be ready for release, but I’ve been surprised by how well some of the trickier-seeming parts of this have been going, so I think we’re talking a small number of weeks. It’ll be pretty groovy to roll this stuff out.
At roughly a week into my September “sprint,” the contents of the next update are becoming clearer, so I thought I’d share some details.
First, there will be a very lightweight CRM application, which I seem to be calling LitelyCRM. It’s absolutely aimed at providing a base to build on, not at providing the full array of functions you might find in, I dunno, Salesforce.
To make the “building on this” part easier to see, I’m making a screencast video that walks through putting together a version with a couple added capabilities. It’ll help you keep disciplined about staying in touch with contacts you share this or that interest with on a regular basis.
Also up for end-of-September release is a very small app that stores a curated library of links to web resources. Two things of interest about this:
It allows users with accounts on the site to bookmark their favorites. Each user has their own set of bookmarks.
It;s organized by tags, and rather than reinvent the taxonomy wheel, this integrates with the existing WordPress taxonomy functionality.
Finally, at least one “logic block” will be released, probably a pretty straightforward block that displays a calculated value (you supply the calculation).
Logic blocks are where the PeakZebra concept gets complicated (from the perspective of designing and developing the features), so there will be more to say about that in upcoming posts…
I’m banging away on what I guess you could call the second sprint of PeakZebra blocks (except that it’s just me, so it’s a pretty thin scrum), but it’s hard to work on applications like CRM (built from blocks) without thinking about onboarding.
Onboarding is an enormous opportunity for WordPress, just because so many (including the core team) do it poorly or, more often, not at all.
If you are brand new to it and load a fresh install of WordPress on that hosting account you just signed up for, you’re almost certainly about to be royally confused. There have been a couple of slight improvements in the 6.3 release that just came out, but basically you end up looking at the admin back end, perhaps without even knowing that there is such a thing, and if you find your way to a view of the front end, you’ll be wondering how you accidentally loaded a “blog about philosophy” when you were trying to load a blank WordPress site.
If you survive this onboarding (designed to weed out the folks with no grit), dealing with new plugins can be rough, too. Most of them just load and then wait around for you to find the configuration page and do something. Some of them are clever enough to go ahead and jump to that page, but you may have very little idea what you’re supposed to do at that point and what effect different settings will have on your site.
Yes, there’s lots of documentation, but the prevalent experience in the computer and internet world these days includes at least a little in situ onboarding. There are surprisingly few tools for this in the WordPress space.
Now, I’m as big an offender as any, at least so far. But I want to work on making it easy to get rolling with the fairly large set of blocks I’m putting out into the world.
And it occurred to me, maybe each of the primary blocks should be capable of creating a popup that can be customized to provide an onboarding experience. There are a few key variables in the PZ block system that are essentially persistent (for a session) global variables, so why not have one that tells the block to do the onboarding thing.
I haven’t built this into blocks or given it a test to see if it really provides anything useful, but I think I’m going to try to sneak at least a small test of the concept into the current, um, sprint. I’m letting all the scrum members know about it right now.
As mentioned in previous blogs, the arrival of the WCUS conference was a self-imposed deadline for me to actually launch PeakZebra as a set of app-building blocks, even if it was a soft launch.
While I did meet the minimal requirements for the goal I’d set, it’s also fair to say that it turned out to be an exceedingly soft launch. Like, this is only just barely a product soft.
So I’ve got a growing list of things that really, really need to be there. If somebody rejects the thing as it stands, that doesn’t yet really tell me much. Maybe they didn’t want it because they don’t think they want to build applications using drag-and-drop components. On the other hand, maybe they don’t want it because they can’t quite imagine getting where they want to go with the currented blocks and the one application template (project management) that I’ve put together.
It’s only a couple of days since I got back from WCUS, but I’ve been pretty focused on setting the next internal deadline and figuring out how to get to an MVP that actually satisfies me (and, I hope, you) as quickly as possible.
The good news–genuinely good news–is that there are a few things that, once added, will cover an enormous portion of the gap. And those are things I think can be in place within a couple of weeks.
Because what I need are more template applications that put the various blocks through their paces in a way that makes it clear how a client gets from a template to, say, a client relations management workflow that’s custom tailored to their business.
I’ve also decided to set aside some time to talk about the development process and various ways to push the envelope in WordPress development, which I hope will be of use to folks, especially agency folks who might want to deliver bespoke apps using these tools.
The next couple of weeks should be interesting. If you want to be hooked in when the blog/screencast/tutorial thing (not quite sure how to characterize it yet) makes its debut, sign up here. I’ll give you a heads up but I won’t clutter your inbox otherwise.
My original vision fro PZ Blocks was that they would be relatively low cost and that they would require minimal interaction with PeakZebra once you’d downloaded. You know, if you’re not charging a lot, you simply can’t afford to spend a lot of time tweaking things for individual customers.
My thought was that you’d get your various blocks and then just drop them into your various pages. Only very minimal configuration would be needed.
I suppose it’s still possible that this vision will eventually be delivered. While I still think the block system is very approachable, it’s become clearer to me that for each client to build what they really want and need, rather than making do with something straight off the shelf, more back and forth, more interaction, is required.
The clear upside to this is that you get the applications you need–even if they are quite complex–quite quickly. We’re starting from existing components and templates and we’re intimately familiar with how they work, so as you describe your needs, we can realize them fast. You have a whole family of blocks at your disposal, but you don’t have to figure out all the possibilities and combinations that this menagerie of blocks offers.
The core goal–getting bespoke applications into your hands at a cost that’s a mere fraction of hiring an agency or your own developer. Plus, the more PeakZebra works with the blocks, the more we see how to make them simple and intuitive to interconnect. We move, by degrees, toward that initial vision of just handing you the set of blocks.
Meanwhile, the communication channels are open and we want to hear what you’re doing and building. Let’s get together and innovate!
I’ve been working on PZ blocks for a good long while now, but sometime early in the summer I realized I needed a deadline. Or, to be perfectly honest, it was my therapist who realized I needed a deadline. Once the suggestion was put to me, it seemed obvious that the deadline had to be Wordcamp US, toward the end of August.
What would happen when I hit the deadline? Well, the PeakZebra blocks would be for sale here on the site, as a package, rather than as assorted pieces of consulting projects. The store would be open, and I’d give away some small, plush zebras, each with a QR tag dangling from one ear.
And that day is coming in five days as I write this. I’m going to pull it off.
The point of the exercise
The deadline is a way to tighten my focus, right down to the essentials. As the deadline approaches, it gets increasingly easy to see what’s reasonable to do and what really isn’t. It’s easy to see what changes have to be made to the game plan (mostly cutting things out and saving them for later) to arrive punctually with something, whatever may have been sacrificed, still delivers the key objectives.
So, five days left as I write this. The lesson for me right now is that it’s not just about having the first set of blocks ready for you to build applications with, but also having the right pieces of supporting infrastructure.
It doesn’t have to be perfect, but there has to be some documentation. I don’t have to have a sophisticated checkout process, but I do need to make sure I can handle the few variations in what people might sign on for.
The question is always: will the package deliver clear value if I cut out this or that. It’s really startling how often the answer is: it will, at least for starting out.
For me, the really huge payoff for reaching the deadline is that it establishes a point at which the first release was done. It draws a line between the mess of trying to create something and having arrived at a version of that creation. You can’t slide backwards from there once that line is drawn, you can only fill in features and head toward the next deadline.
It keeps the anxiety in check to remind myself that on the 24th the WordPress world will be focused on Wordcamp, not at all (not yet) on PeakZebra and what the PZ blocks have to offer. I’ll get up early and drive down to National Harbor. There’s a whole bunch of sessions I’m excited to check out.
Here are the slides from my presentation at WCPHX, Using Blocks to Build Applications. Note that most of the presentation was a live demo. I’ve included the backup slides I made in case the demo went south– a series of screen shots that captures much of what I showed.
A lot of the third-party activity around blocks these days is centered on putting together sets of blocks, and one of the more widely used sets out there is Kadence blocks, which has a free and a pro option. For a recent project I spent quite a bit of time working with the Kadence Pro Blocks set. So I have some views on the Kadence block set itself, but it also brought me to some realizations about the state of WordPress blocks in general.
The takeaway is that Kadence blocks are mostly good at what they do, though a couple of the fancier blocks have some rough edges that gave me fits trying to bend them to a particular design I’d been given. I’m going to tackle my discussion of the world of Kadence this in three parts. (Previous looks at other block sets are here and here.)
In this post, I’m going to talk as much about why you want to move beyond the core blocks that WordPress installs with and why block sets like Kadence’s include “copies” that seem to do roughly the same chores, like adding headers and images. In the second, I’ll drill down on some of the blocks in the set that are common in the world of “fancy” blocks, like testimonial sliders and masonry displays of blog post titles. In the third, I’ll look at some of the blocks that, while they may not be unique to Kadence Blocks, are nevertheless not as common (and we’ll look into whether they’re worth the trouble or not).
Replacing the core blocks with Kadence blocks
One great thing about Kadence blocks is that the free version has all the same blocks as the pro version, as far as I can tell. If you bump yourself up to Pro, some of the blocks do more complex things. For example, the Advanced Text block will give you the ability to add text from dynamic sources.
As with other collections of blocks, Kadence has a group of blocks that are improved versions of things that come stock with WordPress, but it also has a group of blocks that are more the sort of thing you get with pre-block-editor page builders. In the first group are things like Advanced Text and Advanced Image. In the second group is a Testimonial block, some options for displaying blog posts in masonry format, and other odds and ends like a Timeline block.
In the project I mentioned above, I needed to match an agency created design fairly closely, so exact font sizes and content widths and so on became issues. While I have in the past been somewhat suspicious of block sets that seem to duplicate much of what the native WordPress blocks provide, the need for better blocks was something that the project hammered home for me.
Group and Section and Full-Width Designs
Let’s talk just about organizing basic layout issues. If you’re trying to do something even remotely better than just dumping blog posts down the middle of the page, you are almost immediately pushed out of the supposedly no-code WordPress block editor. So here’s a Canva website template:
It’s an image with some text and a button laid over it. If you swing a dead firefox on the internet, you’ll hit a page that has this.
Now, that’s a full-width image. To get a full-width image in native WordPress blocks, the simplest approach is to insert an image block and use the menu to set the block to full width.
That’s easy peasy, though the block editor doesn’t really show you the full-width result (there’s a way to make it look more like the finished widescreen result, but I’ll save that for another post):
Now, you probably already realize that we’re stuck here. You can’t overlay text blocks on Image blocks. So you want to do something like put this image inside a Group block as the background of the Group. Alas, you can set the color of the background, but you can’t use an image.
Cover Block, anyone?
You’re already thinking to yourself: There is a native block designed for this sort of thing: the Cover block. With the Cover block we can put the picture in the background and put items such as columns and text as an overlay to the picture. The block throws in a couple of extras as well. You can, for instance, have a color that overlays the picture. In this example, I’ve got a black color overlay at around 40% opacity:
This isn’t quite right, compared to the original, though it’s close-ish. The button in particular is wrong compared to the original. And the original button, to my eye, is way better looking.
There’s also the matter of the fonts not matching the design. In this particular example, the main text is a fairly generic sans font, so the default sans font in the WP theme I’m using is a reasonable substitute. The company name in the upper left doesn’t grate too much, either, but it’s wrong if you look at all closely.
In a situation like this, the solution lies in setting the right default fonts for the theme, which has nothing to do with either native or Kadence blocks. But there are certainly times when you need to throw in a one-off font – maybe a special landing page that uses entirely different fonts, or you need a crazy display font for the heading of an article. You can set a specific font for a specific block instance using either the native or the Kadence Advanced Text block, but the Kadence block makes it vastly simpler, largely because it gives you a dropdown of all the Google fonts, which is fine for an awful lot of use cases.
There’s another important thing wrong here that you can’t fix with native blocks, at least not in a no-code way, and that’s the spacing of the columns across the image. Note that in the original, the company name text slightly overlaps the main text below. My block version has the main text considerably further to the right. (It occurred to me as I was writing this that there’s a more accurate way to do this with native blocks where you use only two columns and align the company text left, but center the main text, both in the left-hand column. But that works more because it just happens to in this case, not because you actually have fine control over it.)
My point is that it would be nice to have some ability to drag the column widths. Thus: enter the Kadence Row Layout block. It does what the Column block does, but with considerably more finesse. We can go full-width with it and we can adjust the width of the columns on the fly.
But before we really get into it, here’s a nice example of things that are going to frustrate the crap out of people just plunging into the block editor, particularly if they used to use third-party page builders…
Let’s say that I want to keep some organization in place for the different parts of the page. To do this, I might decide to throw this piece of the page inside a Group block. So I insert a Group block and use the toolbar that appears atop the block to pick the full-width option.
Maybe I want a background picture for this area. Well, all the Group block does, really, is put a <DIV> wrapper around everything nested within the Group. That’s handy if you’re going manipulate the area using CSS classes. But we don’t want to do that, because we’re after a no-code editing experience.
Well, I can get a background image if I nest a Section block within the Group block, because the Section block supports it. The thing is, Section doesn’t inherit the full-width setting. Instead, it uses the inner content width for the theme. To my way of thinking, that’s not what you’d intuitively expect and you can’t set the Section block to full-width the way you can with other blocks.
Ultimately, this isn’t a problem, because we don’t actually need the Section block to get our background image in place, but it’s the sort of “one block does it but another doesn’t” aspect of blocks that can be pretty aggravating at times.
I said you didn’t need the Section block. You can instead use the Kadence Row Layout block, which you can set to full width and set up with a background image. Row Layout works like the native Column block, but has some bells and whistles. One really great addition is that you can drag the columns wider and narrower in five percent increments.
But ach, here’s another inconsistency: that dragging and resizing thing only works up through three columns. Bump it up to four columns and you’re locked into the default split. The Kadence documentation doesn’t spell this out, though there’s a new feature request that explains it. I was mystified as to when I could drag column widths and when I couldn’t.
For the sample page we’ve been working on, it actually made more sense to just have two columns, but I did drag the “person” part of the image wider so the text sat a little further to the left.
Space control in Kadence blocks (and elsewhere)
What separates the native blocks from sets like the Kadence blocks is some frilly blocks that do countdowns and the like, sure, but the thing that you really need better blocks for is margin and padding controls, plain and simple.
Consider a situation like this:
Some clever designer has placed a logo such that it overlaps the three-column block just below it. On the plus side, you can use the Advanced Image block Kadence provides and adjust the margin values so that the left margin is pushed far over to the right and the top margin so that it’s negative and pushes the image down into the next block’s space. In fact, the screen shot above is what it looked like in the editor after I had done that.
There are situations where this works just fine, but actually this isn’t one of them. That’s because Kadence wraps the <IMG> tag inside a <DIV> where it sets some of the classes it uses to set up default behavior in CSS. Without belaboring the details, it looks like this when published:
I thought, hey, no problem, I can just set the Advanced Image to align right. But that results in an image the size of a pinhead. There are ways to handle this sort of thing using the CSS translate/transform combo, but again, I’m trying to avoid having to muck around in the CSS.
Or, honestly, what I’m doing is manipulating the CSS directly whenever something tricky needs to get done. And that’s how it’s going to be for the near term and, who knows, maybe forever. CSS is the tool that’s built for these sorts of tasks.
Consistency needed
Right now, though, I think the issue is consistency across blocks. Is it Kadence’s fault if one of their blocks doesn’t handle stuff like negative margins? Well, yes and no. Probably there are things they could do to make the experience more seamless. But at the end of the day, there’s always (well, almost always—not in the advanced button control) an “advanced” section of controls that lets you type in a custom CSS class name, letting you tweak the block from CSS. Kadence makes it very easy to add custom CSS for a page or the site, in fact.
Specifically for relocating blocks relative to each other, though, I’d prefer if Kadence gave me direct control over the CSS transform property from within the GUI. Divi, quirky and old-school though it is in many ways, does this cleanly and even fairly intuitively.
But despite my first example being one that doesn’t actually work, having finer grained control over things like margins and space between lines in text and image overlays and so forth—all this is powerful stuff and once you find a block that does it the way you want, you’ll have trouble using many of the core blocks again. That’s the main point here: you can’t really do design work unless you control margins and padding on a block-by-block basis.
I have quibbles, but Kadence gives you that control, whether in pixels, ems, rems, or percentages. It also gives you a number of useful specialty blocks—a testimonial carousel, for instance—but we’ll tackle the good and the bad in these fancier blocks next time.
Let’s check out some more WordPress blocks. Third-party blocks.
On our last outing we looked at blocks that work together for a specialized purpose—JetFormBuilder, which is a forms package that builds forms using a block for each field.
The people that make the widely used Astra theme have built (and continue to expand) a set of blocks that help you build fancier, prettier pages than you can if you restrict yourself solely to the blocks that are native to WordPress. Initially, this set of blocks was called Ultimate Addons for Gutenberg (or UAG), but now it’s been renamed as Spectra.
By my count, there are presently 30 blocks in the package. Some of them are blocks that duplicate blocks in other third party collections (not surprisingly), but there are quite a few that are pretty interesting and that I haven’t yet seen elsewhere.
The time of your life
One block that lets you get a something pretty onto a page that would otherwise take a lot of work is the timeline block. I found it a tiny bit quirky, but it works just fine on the page. You add each date over in the context sidebar and then directly type your descriptive text within the block. You wind up with a series of stacked blocks connected by a vertical rule that fills with color as you scroll down through the timeline. It’s nice, and all the colors and backgrounds are configurable.
The Spectra timeline. The green line shows that we’re mid-scroll. Not sure it really adds any information, but it’s kind of cool.
There’s a “search” block that inserts exactly what you think it would, except that it’s a somewhat different design than the native block – it seems clear that an important aspect of many third-party blocks is going to be that they duplicate the basic function of a native block, but with some desirable design differences.
Heads up
Another block that I like a lot and that shows, I think, how blocks will add “behind the scenes” functionality without a lot of fuss and bother is the “Inline Notice” block. At one level, it’s just a design element that let’s you visually identify things like warnings and notices. And just for that it’s pretty useful and highly configurable. But an additional touch is that you can allow users to dismiss the notice by clicking on an X icon, plus you can cause this action to set a cookie to track how many days have passed since the notice was dismissed. If you set it for, say, three days, then the notice will reappear after three days. So you can let a user effectively say, sure, I got that, but when they come back six months later, you may think it’s prudent to show them the notice again as a reminder.
A table of contents block generates a box that contains links to all the header tags on the page (though you can set it to pay attention only to higher-level headers, H1 through H3, for example). You can configure the table to initial display collapsed, which is how I’d be inclined to use it. I’ve had to implement this sort of thing with plugins in the past and this certainly seems easier to drop where I want it without a fuss.
Schema
A final thing I want to mention is that there are three blocks that facilitate the addition of structured data to your pages. There’s a FAQ block that lets you build an accordion of the sort one sees everywhere, but it also adds structured data to the page meta as you build. I’m still going to charge extra for that, of course.
Another block lets you build a “How To” page that adds the structured data Google will be looking for—this is really a nice thing for those creating content that can take advantage of it. A similar block for product reviews makes sure you’ve added all the necessary schema components like SKU and brand and that you’ve included a product picture. If you’re bothering to do reviews, you should bother to do this. Which suddenly makes me think that these walkthroughs are, frankly, reviews. So I should use this block.
Mix and match
One thing I’d forgotten and been reminded of as I’ve started my world tour of the block-a-verse is that one of the big points of Gutenberg was to create a standard way for third-parties to create interoperable blocks. And I mention this to say that in this new era, it will be totally normal for website creators to decide to use a few blocks from this set, plus another block over here, and so on. And a nice feature that a couple of the blocksets out there have added (including this one) is the ability to turn off the blocks you don’t want to use. Love it.
Final point: this group of blocks is put together by the people who make the Astra theme. They’ve sort of built on this by creating a direct interface to drop in fully designed page templates from the block editor. The world up there in the top bar of the editor may well become hopelessly cluttered over time, but I still kind of like that you can grab a page so effortlessly, then make all the changes you want to make it yours. That’s one of the things that I’ve liked about the Divi page builder—I like it here too.
Pressing the Templates button gives you the below interface for importing page designs and block patterns…
