[00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley.
Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the blocks, the themes, and in this case using Gutenberg to build the Awesome Engine SaaS app.
If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcasts players.
If you have a topic that you’d like us to feature on the podcast, I’m very keen to hear from you, and hopefully get you all your idea featured on the show had to WPTavern.com forward slash contact forward slash jukebox, and use the form there.
So on the podcast today we have Steve Bruner and Timothy Jacobs.
Steve has been active in the WordPress community for the past 17 years. He’s a WordPress developer, co organizer of the WordPress NYC meetup, and has organized many word camps in New York City.
Timothy is a WordPress core committer for the REST API, and has been a WordPress developer for over 10 years. At StellarWP he leads development of the iThemes security plugin.
What brings them together is that they’re both founders of a SaaS app called Engine Awesome, where Steve is the CEO, and Timothy is the CTO.
What has this got to do with WordPress, you might ask? Well, they’re here today to talk about Gutenberg, but not how you might expect. It’s Gutenberg outside of WordPress, but Gutenberg, nonetheless. Like all of WordPress, Gutenberg is open source. You are free to download it, modify it and use it in whatever way you like.
When Steve and Timothy began working on their new project and needed a way for their clients to interact with it, they found Gutenberg was the perfect tool for the job.
We talk about what benefits they’ve gained by using Gutenberg. How it saved them time, and how it’s fast becoming a stable and mature product which is easy for non-technical users to understand.
We get into the details of which parts of Gutenberg they used, and which parts were not suitable for their app. They’ve been building their own blocks, which work well in the UI, but which are more suited to the kinds of data that they’re gathering.
The discussion then moves on to what Awesome Engine actually does. It’s an app builder in which you can construct your own data containers and theme them so that it displays in any way you like. They tell us about the features, which they have so far, as well as the items which are on their roadmap.
Towards the end we talk about their commitment to continue contributing back to the Gutenberg project, and how they feel that it’s in everyone’s interest if the project gets better from any updates that they have made.
If you’re looking to build your own SaaS app, or you’re just curious about how Gutenberg is being deployed outside of WordPress, this podcast is for you.
If you’re interested in finding out more, you can find all of the links in the show notes by heading to WPTavern.com forward slash podcast, where you’ll find the other episodes as well.
And so without further delay, I bring you Steve Bruner and Timothy Jacobs.
I am joined on the podcast today by two gentlemen. I’m joined by Steve Bruner and Timothy Jacobs. Hello.
[00:04:23] Steve Bruner: Hey Nathan. Nice to meet you.
[00:04:24] Timothy Jacobs: Hey.
[00:04:25] Nathan Wrigley: Steve. Firstly, did I pronounce your surname correctly?
[00:04:29] Steve Bruner: You did absolutely.
[00:04:30] Nathan Wrigley: First try. Yeah, that’s great. Well, thank you for joining us on the podcast today. We’re going to be talking about something which we literally haven’t covered in any way, shape, or form at all. We’ve talked endlessly about Gutenberg and the Block Editor, and blocks and patterns and all of that. But we’re kind of staying away from that, despite the fact we’re going to be talking about Gutenberg. Because we’re going to be talking about an app which has been built on top of Gutenberg, but really not that connected to WordPress. So buckle up. This will be an interesting episode.
We like to orientate the listeners as to who you are so that when they’re listening, they know that you are an authority on what you’re talking about. So can I take you in turn? Can I go Steve, first? Would you mind giving us your little potted history of who you are, what you do for a living, where you live, and what your relationship has been with WordPress?
[00:05:18] Steve Bruner: Sure. So back in my previous life I was in like marketing and sales. I embraced technology back then and using spreadsheets and eventually Microsoft Access, I was able to do more than anyone else on my team, right? I could do 10, 20 times the amount of work, just writing macros in Excel or, do database config in Microsoft Access.
And I loved playing with technology and started playing with HTML, and a friend of mine about 17 years ago, 18 years ago, introduced me to WordPress, said, this is pretty cool, you may want to check it out. And I really loved it. It was easy and it was hackable and it was a lot of fun.
Eventually somebody asked me to build them a website. Somebody else offered to pay me to build them a website. And that just grew over the years until I became a full-time, I guess, solopreneur. I have an agency, but I do hire out contractors on a regular basis. I have relationships with many contractors who I’ve been using now for over a decade.
I also ended up back then taking over the WordPress meetup in New York City. It was about 400 members, now it’s 9,000. That really gave me a good introduction to WordPress. It introduced me to a lot of people, and I learned. In the very beginning of a meetup, for those of you who are trying to start one, if you don’t have somebody who will present, you are the presenter.
So for the first year, year and a half, I presented every month, third Tuesday of the month. Did that for a year and a half until we started getting more presenters in. So that grew and yeah, I’m a full-time WordPress developer now.
[00:06:56] Nathan Wrigley: Isn’t it curious how, if you have been using the internet, let’s say, and building websites for anything like 20, 30 plus years, you kind of more or less fell into this job. I’ve yet to come across anybody of my age, shall we say, who’s been doing this for that length of time who sort of decided from the outset, that’s what I’m going to do.
The story is always the same. I was doing something else and then I discovered HTML and played with CSS and realized, oh, I could actually make a living with this. What fun.
[00:07:23] Steve Bruner: That’s exactly right. The fact that WordPress is open source. You can run it locally. I learned how to code, and this is not an uncommon story, right? I learned how to code by changing code in WordPress. By commenting things out and changing things, and just seeing how it worked.
[00:07:39] Nathan Wrigley: Yeah. A verified tinkerer. It sounds like a man after my own heart. Okay, so let’s move on to Timothy. Timothy, same question really. Give us your background story and particularly your relationship with WordPress.
[00:07:52] Timothy Jacobs: For sure. I’m also based in the New York City area, so you can guess how I met Steve at the WordPress New York City Meetup Group, which I also help co-organize. But aside from that I’ve been working with WordPress now for about ish 10 years or so. My day job is I work over at StellarWP on iThemes security. So I’m the lead developer over there.
But I also have yeah been involved with the WordPress community for a bit. I’m right now a WordPress core committer. I help work with the REST API in WordPress Core. And then also try and, you know, work with the Gutenberg team as well on REST API things and bringing the two together and helping everything work.
[00:08:29] Nathan Wrigley: Well thank you. At the outset of this podcast it might be useful if you are listening to this and you’re anywhere near a computer. Just pause for a moment and go to the URL engineawesome.com. It is exactly as you’d imagine. There’s no funky spelling there, engineawesome.com.
Go and have a poke around because I feel that the context that you’ll get from doing that will put you in a good position to enjoy this podcast episode more. So come back and we’ll get on with the ride. So first of all, whoever wants to answer the question, what is Engine Awesome? We should probably clear that up straight away.
[00:09:03] Steve Bruner: Great. So yeah, I can answer that. Engine Awesome is a SaaS application, and for those interested it is built using Gutenberg, but Gutenberg using Laravel, not WordPress. But it’s a SaaS application that allows you to build applications for your business with absolutely no code, just using blocks. You could build your own CRM. You can build an order management system, a donation system, project tracking, to-dos. Anything you want in the config that you need.
[00:09:33] Nathan Wrigley: So the ability to do that in SaaS software, there’s probably a multitude of apps that we could go to that offer, I guess, something fairly similar. You know a no code tool which allows you to build something custom. But the unique bit which has got you on this podcast today is the fact that you’ve chosen to do that outside of WordPress, but still using Gutenberg.
And I want to know why. I want to know why was it that you decided to take that on board? I can imagine there’s a whole bunch of reasons, but they would be guesses. So let’s delve right into
[00:10:09] Timothy Jacobs: Yeah, so I think one of the big things is that the user experience that the block editor provides, while there’s always places that it can be improved, is really excellent. There are so many tools out there where the first years of their development are, how do we build a good UI for dragging things onto the screen and making it look like you would expect it to look.
And how do we, you know, have settings that adjust things and make tweaks and have visual changes? And how do I navigate to different areas, and how do I present blocks of content? I think WordPress, the block editor in Gutenberg, isn’t really the only block based system that’s out there. Lots of different tools have come to realize the power of the block.
But the block editor in Gutenberg being open source, lets us have tons of customization ability. So it really gave us a great headstart for building out an application user interface, where we could get right down to the meat of it, instead of worrying about all of the bits that go into building a WYSIWYG block editor interface.
[00:11:13] Nathan Wrigley: It’s almost like the use case for using WordPress to build a website in a way, isn’t it? Because it does a bunch of the heavy lifting for you. You don’t have to invent all the user permissions yourself, and write all of that code. You can get yourself off to a flying start by implementing something which is freely available and ready to roll.
[00:11:31] Timothy Jacobs: Exactly. It gives you that same kind of headstart. And it also provides like a great prototype experience. The first prototype that we built out was just by building some custom blocks in a WordPress, Gutenberg system. Not even with a whole Laravel side of things. It’s just a great place to prototype.
[00:11:48] Nathan Wrigley: So Steve, I don’t know if you have anything to add to that, but basically why Gutenberg? If you’ve got a different answer than Timothy’s, go for it.
[00:11:56] Steve Bruner: Tim’s the CTO, so his is a little more technical. Mine would be a little more business oriented, I guess. First off, the Gutenberg UI is proven, right. It’s a proven UI that works well, and millions of people and millions of websites use it every day to build websites. So not having to deal with that, not having to work on a UI and go through the whole trial and error process really was appealing to us.
Gutenberg gave us, we probably would’ve taken two years, three years to build this out if it wasn’t for Gutenberg. So having that head start, having a UI that’s proven, that works. And if you’re coming from the WordPress world, you’ll feel natural. You’ll feel comfortable in Engine Awesome, because it’s Gutenberg, right? We have some custom blocks and some custom workflows, but at the heart of it is Gutenberg, and you will, you’ll feel very comfortable using it.
[00:12:48] Nathan Wrigley: So given that Gutenberg itself has been how to describe it? It’s been tumultuous over the last few years. You know, there’s been a lot of changes, a lot of rapid iterations. I guess that’s slowed down a little bit more recently when the whole project seemed to move over to full site editing and all of that. Is that a concern of yours? Have you frozen your version of Gutenberg in time? Or are you keeping up with the very latest and greatest that that project offers?
[00:13:13] Timothy Jacobs: We are keeping very up to date. I think we are one version of Gutenberg behind usually. And that’s where we like to keep it at. But yeah, just a couple of weeks ago, we added support for fixed positioning. Which was a feature that the main Gutenberg team had just introduced. So we see that the, like, iteration speed of Gutenberg is a benefit.
A big thing is that as Gutenberg is maturing, and now we’re seeing Gutenberg with the isolated block editor project and coming to the wordpress.org forums. And of course what Automattic is doing with Tumblr, that the core WordPress Gutenberg packages, while they are moving very fast and you do have to keep up with them, they are kind of stable enough that you can build on top of them in this way.
And they have to be so that those projects don’t just keep breaking. And so WordPress.org doesn’t just keep breaking. While it is not as stable, let’s say as WordPress Core pre 5.0, and just building on top of the WordPress Core PHP. I think it’s stable enough to build on top of, for sure.
[00:14:19] Nathan Wrigley: Did the nature of what you were trying to achieve, and we can dig into exactly what it is that you are solving in a little while, but did the paradigm of blocks fit pretty neatly? In other words can you. atomize your workflow inside of Awesome Engine into a collection of blocks basically? Drag in blocks, reposition blocks, fill in data into blocks, and that’s essentially what the app is doing.
[00:14:43] Timothy Jacobs: Yeah, I think so. At its core in Engine Awesome, each field, each bit of data that you’re putting into your, let’s say CRM or invoice management system, each one of those fields is a block that you create. So starting from that level of, hey, we have a block, which is a field that data can be entered into. And it doesn’t just look like, let’s say a plain text field, it looks something a bit more of a rich application user interfaced.
The field and the block being like that common low level bit that we build on top of. Yeah, it does make, I think the block-based paradigm a good fit. There are some struggles with a block-based paradigm, and achieving some more complex layouts where things aren’t just neatly stacked in rows and stacked in columns, like a grid.
But that is something that’s getting more and more possible to with Gutenberg every few releases. But I do think that the block-based nature, being able to map over to every block as a field did make it a good match, of philosophically in that sense.
[00:15:45] Nathan Wrigley: Yeah, right from the outset. Matt Mullenweg ages ago, I don’t exactly know when, he had this, what felt like a really almost crystal ball gazing idea that Gutenberg as the editor would become almost synonymous with entering data across the whole internet. It would become something which was used everywhere.
Gutenberg itself would become bigger than WordPress and all of that kind of thing. Do you see this? Do you see people doing what you are doing out there? In other words, does the Gutenberg interface, is it increasingly cropping up in places just like Engine Awesome?
[00:16:20] Timothy Jacobs: I’m not sure if I’ve seen many cases. There are some that are out there. There is a Laraberg, as I believe the combination of names and how they landed on that one of combining Laravel plus Gutenberg, more for like a page editor context. The same way that is used in WordPress Core.
As well as I believe there’s a Drupal integration. And I think a couple of other things. Of course, there’s the isolated block editor project and what Tumblr is doing. I haven’t seen a lot of people though that are doing it to the degree that we are doing it, in terms of, hey, we’re letting you build an application as opposed to letting you design a webpage.
And so I don’t think we are there yet. But I think the stabilization over the past year has made it more of a possibility for projects who are looking to adopt Gutenberg in that way absolutely can, and I think it’s something worth looking into.
[00:17:10] Nathan Wrigley: How much of the core Gutenberg blocks do you bring along? And how much of it is bespoke work for your application? I’m presuming, I mean, you alluded to it earlier. I think you said you’ve got some of your own custom blocks in there. Do you bring almost everything along for the ride, including, I don’t know, the Vimeo embed block or whatever it may be? Or do you pull out a certain amount and keep a certain amount only?
[00:17:32] Timothy Jacobs: Yes, this is actually, it’s a really interesting question in terms of how functionality in Gutenberg these days gets divided. So we don’t bring in any core WordPress Gutenberg blocks. But what we are able to do is, as we’ve had the introduction of global styles in the full site editor experience. There’s been more of a separation of, what are things that are really blocks and what are things that are settings that your blocks can opt in to.
So for instance in Engine Awesome, you can use the margin tools, and the padding tools, and the sizing tools, and the colors, and the text sizes. All of these different systems. And the way that we support that in Engine Awesome is we just say in our block.json, hey, we want this feature. Gutenberg, render me the UI for it. Build me the styles. Save all of it to the block metadata information.
Gutenberg, you handle all of that. And what I’ll do is I’ll render the part that you see in the canvas, the actual block UI. But core Gutenberg is able to handle those types of controls. So that’s where we’ve really made the delineation, is that we don’t use the core blocks, but we use all of the features that the core blocks use. And are able to pull them in without having to copy thousands of lines of code. So we for instance, have a text block and a group block, and they’re a few dozen lines of code that are really just implementing the WordPress core APIs around layout and around rich text.
[00:19:09] Nathan Wrigley: Yeah, it’s interesting because I’m looking at your homepage now and there’s a video on there showing what is obviously to me, the Gutenberg interface. I guess to your customers maybe they’ll recognize it as that, maybe not. But it shows the inserter, the panel on the left opening up, and it really does look the same.
And so I made the mistake of thinking they were core blocks because many of them map really similarly. You know, you’ve got a text field and then you’ve got a URL and the iconography looks remarkably similarly. You haven’t really tweaked that in any way. It really, really looks like the interface right down to the colors and everything is exactly the same. Black text, black icons, blue buttons, looks similar. That’s a curious choice that you decided not to fiddle with the design of it.
[00:19:54] Timothy Jacobs: Yeah, I think the design of the block editor, like Steve was mentioning, is really well proven. And I think there are places where maybe in the future that we do more customization, based off of how our users are going to be using Engine Awesome. And the differences between the block editor in WordPress Core for designing pages and the block editor in Engine Awesome for designing applications.
But I don’t think we wanted to take an approach of, well, let’s just redesign it for the sake of redesigning it without knowing hey, here are these specific UX benefits that we want to change and we want to improve.
The other aspect of it, to be honest, is that some of these components are harder to tweak than others. Like the inserter, for instance, is a very complex component. So we don’t want to just say like, okay, let’s rip it all apart. That’s one of the aspects where I think you can get into a little bit of trickiness with the rapid pace of Gutenberg development. Is that if you rip everything and everything and everything down to its very bare bone bits, then it is a lot harder to stay up to date with Gutenberg and to be on the latest versions. It makes each upgrade a little bit more of a chore. Whereas for us upgrading Gutenberg isn’t very difficult.
[00:21:15] Nathan Wrigley: So I guess if you’re a listener to this podcast, the chances are that you’ve played with Gutenberg in the past and you’ve experienced how it works and this whole process in Engine Awesome will be really familiar to you. But it also raises the question, you know, in WordPress there’s a whole ton of different blocks out there now. If you, you know, you can go to the internet and download thousands, possibly tens of thousands of different blocks. And, so you are using that block methodology in your application.
It feels like we’ve sidestep the, the most important question, which is what on earth, what an earth does this SaaS platform actually do? So it might be a good idea to bring Steve back in at this point and ask what is Engine Awesome? What is it doing?
[00:21:56] Steve Bruner: Yeah. So like I mentioned before, I’ve been running a small business for almost 20 years. Full-time for, you know, close to 10. And I’ve tried every piece of software out there to help you run your business, right? I’ve tried every CRM. I’ve tried every project management tool and to-do list and anything you can imagine, I’ve tried.
And to be honest with you, I haven’t loved any of ’em. And anybody I’ve spoken to has said the same thing. Usually when you try these out of the box solutions, you feel like you’re overpaying for a product where you’re only using 50, 60% of the features. And they keep loading it up with more features and they keep raising the price.
With Engine Awesome you get to build exactly what you want. You build the CRM that you want in the way you work. The way your team works. The way your business works. We have had clients that have taken paper forms that they’ve used in their business and replicated them in Engine Awesome. And their employees just log in and they know how to use it. There’s nothing strange here anymore. They see the same form they’ve been using for years, it’s just a digital version. So training comes down and training costs come down.
Now, there are other no-code platforms out there. We realize that there are others that are doing this. Our goal is to make it simple. To make it really, really simple for you to get your application up, right. Tim and I always talk about getting our clients up and running in minutes, not months. You don’t have to know anything about databases to use Engine Awesome. You don’t have to know about key fields and indexing fields. You don’t have to know how to build relationships. You don’t have to do any of that stuff. Engine Awesome takes care of it for you very easily. Just drag and drop some blocks, check a box, press save, and you’re ready to go.
[00:23:55] Nathan Wrigley: I’m seeing when I’m on your homepage, I’m seeing what looked like the two UIs. I’m seeing the Gutenberg UI, which obviously has a purpose, but I’m also seeing like another UI where I don’t know what’s going on there. Is it, do you have a UI to build the blocks themselves and then they’re created inside of Gutenberg to drop in whatever data it is that you need to put into that particular block?
[00:24:18] Timothy Jacobs: Yeah, so we have two different base points. They’re both Gutenberg. But the first step of building your Engine Awesome application is deciding what fields that you want to support. So what data you want to collect. And this is just dragging from the inserter, a URL, or a name, or a color, and bringing them into a separate editor where you see all the list of fields that you’ve created for this particular, what we call an object type. For WordPress users it would kind of be most analogous to a custom post type.
And so your contact, for instance, might have a name field, a phone, an address, things like that. Those fields that you define when you’re editing your object type, make up the inserter, make up the block library when you then edit your layouts. So you first define your kind of data that you’re looking to collect. And then you can define as many different user interfaces that you want to show that data or collect that data. And Steve can give some good examples of how that interface building portion happens.
[00:25:19] Steve Bruner: Yeah, so a lot of our clients come from using spreadsheets, for instance. Just giant spreadsheets. 30 columns, thousands of rows. And it’s really easy for them to work with Engine Awesome, right. So as Tim mentioned, first they define their object and then they literally are transferring those fields from a spreadsheet to Engine Awesome using the blocks.
Then they go and start creating their layouts. And the layouts are, they could be forms, right? Where you’re entering data. They could be tables where you are viewing data. They can be queries where you’re searching for data. And those layouts also are conditional.
They can change based upon data that’s entered. So, for instance, if you have quote that you provided through an Engine Awesome system, and that quote is in maybe an open status, you will see certain fields that are there. But once that quote gets changed to an approved status, those fields will be locked, right?
You’re not changing the quote after it’s been approved. So fields are locked. Nobody on your team can enter data or edit data anymore. And then you can move through a process. And again, I just want to reiterate, that is not a set process in Engine Awesome, that’s a process that somebody would’ve built, right? Everything is custom.
So those layouts, change in Engine Awesome. One other UI I guess that we have. We recently brought in the full site editing experience, or I guess the full, Tim can talk more about this, but the full site editing UI as the actual application UI. So when you are building your object and building your layouts, you see the inserter, the settings, Gutenberg like everyone is really familiar with it. But when you’re using the application, when your team is using the application, when they’re in the field or in the office, we are using the full site editing experience with the full site editing menu. And Tim, maybe you want to elaborate on that?
[00:27:20] Nathan Wrigley: Yeah, please.
[00:27:21] Timothy Jacobs: Yeah, so you can kind of see this, if you go into our post, Engine Awesome has a new look. And you can kind of see that delineation there. Basically the Gutenberg team introduced a really fantastic collection of navigation elements. And so we were able to use those to say, here’s how you navigate between different views, between different object types, between different sets of data. And use that navigation experience that the core Gutenberg team provided.
[00:27:48] Nathan Wrigley: Yeah, I will link to that post. But anybody listening, there’s a blog post. Currently it’s linked in the footer, but I imagine over time it will disappear from the footer of the main homepage. It’s called Engine Awesome has a new look and you can see the site editor panel on the left and all of that. Yeah, that’s a really interesting implementation.
So you build out the structure of the data you want to consume, you then have the option to display that. Presumably there must be a whole piece of making that data interact with other data points.
So, you know, you just mentioned that something is marked as approved. So certain fields get locked up. But presumably there are relationships, child, parent relationships, one-to-one, and so on and so forth, that bind the data together. Otherwise, you’re looking at a spreadsheet, aren’t you, really? So there must be something more in here.
[00:28:35] Timothy Jacobs: Exactly. So when you edit your object type, you can set up a relationship between another bit of data, and then when you do that by dragging a block. So you’ll see in your inserter, for instance, let’s say that you are editing a contacts object type, and you already have a company’s object type set up.
The only thing that you need to do is drag a block that says that this contact has one company and then Engine Awesome takes care of the rest. And so then when you’re building out a layout, let’s say for a company, you can easily display a list of all of the contacts that are associated with that company or vice versa.
When you’re editing a contact, you can say, hey, here’s a snapshot of information about this company. Maybe their address, their website, a photo of them. Just to give that contextual information. So you can set up all of those object types and all of those relationships just by dragging a block into the block editor.
[00:29:29] Nathan Wrigley: Steve, it sounded like you wanted to chip in there.
[00:29:31] Steve Bruner: I was just going to give you a couple of use cases so you can get a good understanding of how people are using Engine Awesome. So recently a non-profit provided us a spreadsheet, a thousand rows, 26 or 30 columns, and they were tracking their donors in it. And it really is not the best way to do that. In five minutes, and I really mean this, I’m not joking.
Five minutes, maybe six, on a Zoom call with this prospective customer, I built an application for him where he was able to enter donors and then keep a record, a log of donations. See those donations, filter those donations, and get a good understanding of what’s going on. So it was really really quick and is going to change the way he does his job and his team’s job, and everyone’s just going to be, everyone’s life is going to be easier.
We have a home cleaning service, a residential home cleaning service. Tim has done a great video, you’ll find it on our YouTube channel about how to build a service business application, and in 30 minutes, and this is a live video that Tim did, and you’ll go through it. Tim is not going quickly at all.
But in 30 minutes he built an application that tracks this home cleaning services clients. The jobs they do. Their team members and their teams. They go into people’s homes, they bring up Engine Awesome on their phone. They view their jobs. They mark their job cleaning when they’re starting to clean, and then they go through this whole process.
And when they’re done, they mark it done. Eventually they’re going to be taking credit cards using Engine Awesome. So, we have a Zapier integration where when the job is done, the client will get an email automatically with a payment link. And this is changing her business, right? Right now, she deals with cash or check or Zelle. Sometimes people forget. And it’s just making her life much easier.
Even something crazy like a marketing company that has displays in Home Depot stores. They are going to be doing a test in a couple of hundred Home Depot stores. And they built a UI in Engine Awesome that tracks stores and products and promotions and using our web hooks and API, they’re going to be pushing data to those stores, to those displays, and managing it all in Engine Awesome.
So ideas that we never even thought of, people are starting to use Engine Awesome for some really, really creative ideas. You know, at the core of it, Tim and I really are passionate about helping businesses be more productive every day. And I think these use cases give a good, broad example of that.
[00:32:06] Nathan Wrigley: I don’t know if either of you have ever used a piece of software called Airtable? But Airtable came around, I don’t know, maybe five or six years ago and it felt like a really, quite an interesting piece of technology at the time, in that you could put data in, it was basically a spreadsheet, but then it could show you that data, back at you in a variety of different ways.
So that leads me to the question, is that possible here? It sounds like the answer’s yes. So, as an example, let’s say that I’m a real estate agent and I’m updating data about houses on my roster. And I’ve input all the fields. I’ve got images. I’ve got prices and descriptions and maps of floor plans, all of that kind of thing.
Is it possible for me to create bespoke layouts of that data? So rather than it just being an Airtable, which looks like, well, a spreadsheet, you’ve got other options in there, but basically a spreadsheet. Is it possible for me to, I don’t know, float images right? Or highlight this particular aspect of the text? Make this a heading and you know, add iconography.
In other words can I make the data engaging to look at? And further to that, can I bind those presentation layers to members of my team? So for example, could the sales director see a different layout of different data and somebody who’s in marketing, front of shop, might be able to show data to a customer that walks in the store? That kind of thing.
[00:33:23] Steve Bruner: Yeah, so it’s interesting you brought up Airtable, right? Because Airtable is a no-code solution that, like you said, is mostly a spreadsheet. And I want to get back to that because I think Tim and I, we feel a little differently than the way Airtable and some other no-code solutions do their business.
But to answer your question, yes. You can build really compelling, beautiful layouts using Engine Awesome. Because you’re using the Gutenberg design tools, right ? So you’re essentially designing a webpage, but it’s a, you know, maybe it’s a form or tables or some type of layout. But yes, you can float things, right? You can float through things left. You can bold, change colors. We have themes. We brought in themes as well. So with one click you can change the color and style of your application.
In terms of different team members using Engine Awesome and seeing different things and seeing different items. This is a really important point, right. Tim and I are actually going through this right now. How we want the user roles and capability system to work i Engine Awesome. Because our goal, and this is the goal we’ve had since day one. I think this is also what makes us different from a lot of no-code solutions out there, is that we want your entire team using Engine Awesome.
We don’t charge per user, and I think that’s a really important point, right? We really are charging per organization or per team. We want everybody, we want your part-timers to use Engine Awesome. You want the CEO to use Engine Awesome. Everybody in between. You shouldn’t have to pick and choose who needs to use an application. We really believe at our core that when your entire team is on the same page and uses the same application, and can see the same data, your life’s going to be better. Your business will be better. Everybody will be more productive.
So we’re working really hard to make sure we have this roles and capabilities system that allows to do exactly what you’re talking about, and really fine tune it. So that everyone is on the same page.
[00:35:28] Nathan Wrigley: Timothy, anything to add to that?
[00:35:30] Timothy Jacobs: Yeah, I would mention one thing, which is that right now we have things set up so that you can have different levels of permission. So you can have and invite users onto your team that can just read data, for instance, or who can just edit data, but they can’t make changes to your application. But yeah, the next big thing is figuring out what it looks like and how do you make it intuitive for users to set up an application where they consider different things like permissions and capabilities?
There are some tools that, the kind of permission system is really just visibility. And if you’re a developer, you can sneak under the hood and they throw warnings all over the documentation that, hey, you know, even though you’re, you think you’re hiding this data, you’re not actually hiding this data. Because it still gets sent to every user’s browser or something like that.
So thinking through ways to make it very intuitive for users to say, hey, how do we actually set up our permission model, is the thing we’re exploring.
[00:36:28] Nathan Wrigley: Will it be possible to change the data on, for want of a better word, the front end? In other words, if you’ve input the data in one UI, but then you’re looking at the way it’s presented, the theme, if you like. Is it possible for, and again, user permissions, we’ll assume that that’s coming down the pike, but is it possible to have people change the data in the different displays? Or do you have to always return to the, if you like, WordPress post to amend that data?
[00:36:55] Timothy Jacobs: Yeah, so you can edit the data everywhere. This is a trend that we’ve been seeing with a lot of these different tools. Is that they give you different layouts that can present your data, but at the core of it, they all have a data mode where you’re basically looking at a spreadsheet or a very, I’ll say charitably, a plainly designed form that doesn’t have a sense of hierarchy or related bits of information. And then you can present it in any way that you would want.
For us though, the first thing that we wanted to tackle was to make sure that when you presented and created a beautiful layout, that your users could also edit the data in that layout. So right now we don’t have, for instance, a separate kind of raw spreadsheet like view into your data. That’s something that is on our roadmap. But our main actual priority is for users to be entering in data through the rich UIs that you create.
[00:37:48] Nathan Wrigley: I feel that’s one of the, one of the great advances recently. The ability to change it wherever you are. I think that would be really good. Because it is frustrating if, well, you’re looking at the data that you want to amend and then you have to, in WordPress parlance, click edit post and then go and find that field and amend that field and then click save and then go back and make sure it looks how it ought to look. That’s just one of the best things about this whole approach, isn’t it? Is that you can do it right there on the front end.
Just moving slightly. Obviously you’re a SaaS app. You’re consuming all sorts of data. Probably you can imagine where this question’s going. If you are consuming, I don’t know, email addresses, images, all sorts of financial information, whatever it may be. How are you storing that? Where is that data being kept? If I’m in the EU, do you have it in a certain jurisdiction? Is it encrypted? Let’s just leave it at that.
[00:38:41] Timothy Jacobs: Yeah, that’s a great question. So right now we don’t have a separate EU instance for instance. Unintentional rhyming there. But the way that we’ve set this up is, we are using MongoDB as our database system. And each team that gets created gets their own, essentially database inside of MongoDB to themselves.
So right now that’s all centrally part of Digital Ocean’s managed database service and their encryption at rest and so on and so forth. And there are a lot of great security practices. In the future though, what that means is that we’ll be able to support teams having data that is in a different data center, depending on what their needs are.
And even for potentially more enterprise customers, the need to be able to self-host their own database. Engine Awesome is set up to be able to connect to different database applications. But right now all of that data is stored in Engine Awesome, in Digital Ocean.
[00:39:37] Nathan Wrigley: Okay, thank you. You mentioned enterprise there, but also Steve earlier was talking about examples of local charities and things like that. So is this software basically open to everybody? And on the website, forgive me, it may be that I’m just not looking all that carefully, but I can’t see a price. So I don’t know if that’s a function of you haven’t worked out your pricing yet. Or if it’s a contact us, and we’ll talk through what it is that we think you’re going to need, and we’ll work out the pricing accordingly. But are you aiming at all the people all the time. Enterprise, just small mom and pop stores. How are you launching and what is the pricing model?
[00:40:14] Steve Bruner: So right now most of our clients are small to medium size businesses. We’re not writing off enterprise, we just realize that enterprise may need other features that we don’t have yet. Like single sign-on or maybe a, you know, a dedicated SLA or something of that nature.
So we’re not there yet. Obviously we’re happy to talk to enterprise. There is one larger company that expressed an interest in Engine Awesome, and we’ve been talking to them. But right now, all of our clients have been small to medium sized businesses.
The pricing model we’re still playing with. Again, we don’t want to charge per user. So we’ve been playing with all sorts of ideas. The number of records you use. Or the resources you use. Our goal is to get you and your entire team on Engine Awesome, and we’re willing to do whatever it takes to get you there.
So, right now we have a manual onboarding process. If you sign up for Engine Awesome, you’re scheduling a Zoom call with me. So we have a talk. I find out what your needs are, how you plan on using Engine Awesome, your pain points. And we talk it through.
And at that point we start working out where Engine Awesome fits into your plan. For smaller teams, we’re in the $10 range a month, $15 range a month, $20 a month. But we’re not really going much higher than that right now.
[00:41:42] Nathan Wrigley: Are you going to be making use? So we’re in phase three of Gutenberg, which is for want of a better word, concurrent editing. Think Google Docs. Are you going to be making use of that? I mean, I can see that being incredibly useful if it’s pulled off. But is that something that you are thinking about implementing?
[00:42:00] Timothy Jacobs: I would love to. It’s something that I’m seeing, and I’m really, really excited to see how that evolves. I’m really curious how the core Gutenberg team is going to approach designing that. I think there’s a lot of UX patterns that are going to be challenging. And seeing them pull that off is going to be really interest.
And then seeing how that connects to WordPress. Is it going to be like peer to peer? Is it going to go through WordPress, as the PHP backend? What is all that going to look like from a technical perspective I think will also be fascinating. For us, I think one of the benefits of being a SaaS application is that it makes it a little bit easier for us to do that kind of orchestration, because we control what the backend is.
But of course with WordPress, when we’re building for WordPress, we’re building for like 45% of the web. So the technical requirements are a lot more of a challenge. Yeah, I’m keeping a keen eye on that and I’m really excited to see how that progresses. Because, yeah, I think that’ll take Gutenberg to high Peaks, and will be something that a lot of different people building on top of the block editor, on top of the Gutenberg project will be able to utilize.
[00:43:07] Nathan Wrigley: That was kind of like a roadmap question, but in disguise. Let’s just ask it outright. Just outline for us in the near future, we’re recording this towards the middle of February, so depending on how long it takes this podcast episode to actually make it out into the public, some of these things may have come a along already. But just outline roughly, maybe let’s go for six months, eight months, something like that. What’s the plan? What are you hoping to implement?
[00:43:32] Steve Bruner: Well, our customers are always giving us ideas, right? So things do change like you mentioned. Our priority of right now is user roles and capabilities. Once that’s integrated, and that’s going to take a little bit because not only do we need to plan it out and how it’s going to work technically. We also need to make it super simple to implement, so clients can do this and feel comfortable that the right people are seeing the right data. So that is going to take a little bit of time.
E-commerce would probably be our next big focus. Our clients want to start taking payments from their clients, right? The cleaning service is a great example. Right now the plan for her is to email a Stripe payment link to her clients, but we want to make things a little bit easier.
Also that feature would, currently being done through Zapier. Which is an additional charge. So we want to bring that into Engine Awesome, where we can make it seamless and where our clients won’t have to pay any more for that.
Those are probably the two major features that we want to roll out in the next six months. There are other things we want to do. We want to do, you know, we want to add scheduling. Again, a lot of our clients are service businesses. So scheduling is a big part of that, and they’re using services like Calendly, and if we can do something better or bring it into Engine Awesome , make it easier for them to use, then we want to be able to do that as well.
[00:44:55] Nathan Wrigley: The introductions at the top of the show made it pretty obvious that you’ve got a history of giving back to WordPress. So, forgive me if this question sounds ill placed. But given that you are leveraging quite a lot of the Gutenberg project to build out your SaaS app, I’m just wondering what your posture is in terms of giving back from Engine Awesome. Back to Gutenberg. Again caveat emptor. Sorry, I know that you both do more than enough already, but I just wondered if that was part of the ethics of the business.
[00:45:28] Timothy Jacobs: Yeah, I’m a big believer in that I think the Gutenberg project gets better the more different use cases that we have. Historically, my contributions to WordPress have been mainly focused on the REST API, and how Gutenberg interacts with the REST API. But I hope to be able to dive in more and more into the core Gutenberg project.
So I think being good stewards of the open source community is a key aspect to building on top of an open source project. Both from, this is the best thing to do from a kind of community standpoint. But I think also everyone should really be thinking about how they contribute back to Gutenberg. So that we have a say in shaping how Gutenberg moves forward.
There’s a lot of work to do, and we all have different pet features or things that we might want to have changed or improved in Gutenberg. And, really the long and short of it is that there’s more work to do than there are contributors to do the work. So the more of us that can contribute back to the Gutenberg project and the WordPress Core project, the faster we’re all able to go.
[00:46:39] Nathan Wrigley: Thank you, Steve. Anything there?
[00:46:42] Steve Bruner: No, Tim said it all. Tim said it best. He’s been a core contributor for a long time. Our goal from day one, like you mentioned, we’ve been contributing to the WordPress community in both code and education for a very long time and we want to continue to do that.
[00:46:57] Nathan Wrigley: Yeah, that’s a nice answer to hear actually. That’s very heartening. Thank you. Should anybody have been listening to this podcast, had their interest peaked. They’re either interested in talking about what you did with Gutenberg from a technological point of view, because maybe they’re thinking of adopting Gutenberg in their own platform. Or they just want to actually find out what they can do with Engine Awesome themselves.
I don’t know if you want to answer this question separately or combined, but where is the best place to get in touch? Is it a contact form? An email address? Is it, dare I say it, Twitter.
[00:47:30] Steve Bruner: Right now our website is really the best place to contact us. So engineawesome.com. On the homepage if you are interested in signing up, or just getting on a Zoom call with me to learn more, there’s a input right there where you can put in your email address and sign up for that.
And we also have a contact form where if you have questions about Gutenberg and how we did this and you want a more heavy developer talk, you want to chat with Tim, then that’s the place to let us know.
[00:47:59] Timothy Jacobs: Yeah, you can also always find me on the make make dot WordPress Slack. That’s also a great place to reach out.
[00:48:05] Nathan Wrigley: Okay. Thank you Timothy Jacobs and Steve Bruner. Thanks for joining me on the podcast today to talk about Engine Awesome. I really appreciate it.
[00:48:13] Steve Bruner: Thank you, Nathan. I really, I really enjoyed this.
[00:48:15] Timothy Jacobs: Thanks for having us.
pic.twitter.com/k9NJSy05Xd
