Category: Uncategorized

What PeakZebra offers is more than a theme. Actually it’s a lot more, but the “lot more” actually is varies from one blueprint scenario to the next. And a given blueprint could actually look a lot of different ways. Yes, what you’d normally call the “theme” is tied pretty closely to what the site does, but it’s still possible to vary that theme in lots of different ways.

So how to show the differences among blueprints, while also showing what kinds of variations in look and feel are possible within a given blueprint. With two blueprints and basically no pre-set variations, that’s not really a problem.

But there will be more and more blueprints over time. So what’s the best way to get all those options up on the home page without creating total confusion and chaos?

Right now, I think it’s about having a top level choice of blueprint scenario without showing any thumbnails of page design. So first you choose whether you’re a paid newsletter client, a help resource client, a SaaS builder, a “real” contractor type builder, and so on.

I think maybe it drops down from that choice, but maybe it actually jumps to another page. I think I just decided it should jump, which should help keep us all sane.

And you know what? Isn’t this exactly the kind of scenario where the answer is a Custom Post Type? Let’s have a post for each… each what? Should it be one post per blueprint or one post per variation, grouped by categories that reflect the different blueprints.

This is the classic stuff of WordPress application development, which is probably worth discussing, but for the moment I’ll leave it that I think it’s probably one post per variation. Somehow or the other I’ve got to come up with a way to indicate which is the primary variation, but that seems doable, possibly just by using another category that reflects exactly that. Yup, that’s it.

I hope to have a stab at this new approach in the next few days. Specifically by November 10, which is my self-imposed deadline for my current group of tasks and projects.

I’ve gone back and forth a ridiculous number of times about what, exactly, PeakZebra should be. What was the offer? What was PeakZebra going to sell and how was it going to sell it. I’ve had to learn a lot of self discipline when it comes to avoiding the distractions of new shiny ideas and things.

As of this week, though, PeakZebra has a wonderfully clear vision: we sell LiveThemes.

A LiveTheme is like a traditional WordPress theme in that it provides a design template for a WordPress site. But it’s a lot more than that. It’s a site that’s fully configured to carry out a specific function. In other words, it does things.

Our first “site that does things” is a LiveTheme for running a free+premium newsletter. You can think of it as Substack without having to hand over 10% of your revenues, though it also has some additional cool features up its sleeve.

If you’re thinking about launching a newsletter, or if you’re running one on Substack or Beehiiv.com, I’d encourage you to take a look at the LiveLetter LiveTheme.

“Buying” a LiveTheme means having PeakZebra set up a preconfigured site for you. It’s got all the text and images and forms and payment gateways you need to run the business, but in a theme-like stand-in text format. You’ll want to replace most or all of the placeholders.

It’s a WordPress block theme (based on a Kadence theme), so it’s the “new era” approach to WordPress and you can change things to your heart’s content using the WordPress built-in editor.

If you don’t want the hassle or don’t want to be forced to learn WordPress right away, though, you’ve got options:

For $445 we’ll work with you to get all the placeholder text and images changed out to your liking. This usually takes a week or two.

Thereafter, you can subscribe to “request queue access,” which means that you can use our bespoke application to request a wide variety of changes to the site. You can request as many things as you like, we work on queue items one at a time. You’re sharing the queue with other clients, but our aim is that no request takes more than two business days before it’s filled. Given that this costs $70 a month, it’s a terrific value.

And you can pause the queue access subscription whenever and for as long as you like if you aren’t in need of changes.

We’ll be ramping up slowly so that we can keep a close eye and manage the queue response time (two business days!). This means we won’t take on more new clients than we can handle, so if you want to jump in sooner rather than later, you’ll want to be quick about it.

If you have questions, you can reach me directly at robert — at — warmhearted-tortoise-fa7261.instawp.xyz.

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:

1. It allows users with accounts on the site to bookmark their favorites. Each user has their own set of bookmarks.
2. 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…