Site Studio: No-Code Drupal For Marketers

As one of the first agencies to get their hands on Acquia’s Site Studio tool (and also one of the first certified Site Studio partners), now is a good time to share our initial impressions. 

Site Studio is a fascinating contender in one of the toughest spaces in the enterprise content management game; the perfect middle ground between out-of-the-box and enterprise.

I’ll admit, I was skeptical Acquia could pull it off. Products like Site Studio have emerged before, and the results are pretty much always mixed. 

With that said, let’s take a look at how Site Studio has tried to crack this oh-so tough nut, and why both developers and marketers should pay attention to the latest addition to the Acquia arsenal.

What is Site Studio?

Simply put, Site Studio is a paid product you put on top of a base Drupal site. 

It bills itself as a way to have a powerful, extensible, enterprise-grade, and brand consistent site that you can also build fast and cheap.

It adds a new editing interface, reminiscent of many of the out-of-the-box site building tools like Wix and Squarespace. It also allows you to define components for content entry, and change how the site’s design system looks. In summary, it’s an end-to-end site building layer. 

A base Drupal Core site install, with the Site Studio module turned on, gives you everything you need to launch a live Drupal site. That’s it. 

And, get this, you don’t need to write a stitch of code!

That’s right folks: Drupal + Site Studio = a no-code, fully custom, branded site.

It’s All In The Theme

As our director of frontend and mobile Chris Bloom is fond of saying, “line for line, we write more CSS and JS than anything else in our projects.” 

Well, of course! When you need a frontend that is perfectly tailored to your brand, content, and the third-party products you integrate with, that’s going to be a lot of code. As a company, we’ve gotten really good at building that. The state of modern frontend development, whether you love it or hate it, is undeniably complex and optimized. And it is that way because building a big frontend is a lot of work.

BUT, Site Studio asks; what if you didn’t write frontend code? What if… you had a UI?

I’m probably about to lose a lot of you, but bear with me for a minute. 

There’s two types of people that should care about this approach: developers and marketing teams. Let’s talk about why this is interesting for both groups. 

The Tyranny of Deploy

Hey marketing folks. How often have you been at the mercy of a developer’s time and deployment schedules? I’m guessing more than once. Probably a lot more. Also, how many times have you glanced longingly at alternatives like Squarespace and felt a bit envious? 

It’s the dark secret of enterprise grade CMSs, but there’s something to be said for those off-the-shelf alternatives. They are fast and easy to make new shiny content with. 

Site Studio thinks you should have that power and convenience with your Drupal CMS too.

Site Studio asks, What if you didn’t need a developer to make new and exciting content?  What if you could update the look and feel of your brand and content but do it on a secure, enterprise-grade system?

By putting the theme development, including new components, into a UI, Site Studio gives marketing teams who are CSS aware complete power over their content and brand. 

This is enablement at a level that most enterprise builds don’t even come close to. And that’s not an accident - with great power comes great ability to break stuff. Site Studio gives you a few more guardrails than just raw HTML and inline styles. It’s still fundamentally a design systems thinking approach, and there are some pretty hard rules to keep you in line there. What the design system looks like? That’s up to you though. 

Yes, you! Not the abstract, “Someone who works at the same company as you.” Neat, huh?

Do You Even Code?

Remember where the bulk of our custom Drupal site code is written? That’s right - our themes and design systems.

Let’s think about that for a minute. What’s conspicuous here isn’t that there’s lots of frontend code. What’s conspicuous is that there isn’t a lot of code for backend structure. How is it that a complex data architecture in enterprise Drupal sites doesn’t require me to commit piles of code?* We used to do that. But Drupal is, in no small part, a UI for defining database schemas and relationships. And it’s much faster than doing that by hand. Much, much faster. 

Are there trade-offs? Of course, but we’re really no stranger to building machine generated code with a UI. Is it that crazy to bring that approach to the frontend? 

Yup. It is. But it works surprisingly well. If you are all about component based design, I’m here to tell you Site Studio gets it. And the details of that really need a dedicated deep dive - some other time, I promise. In the meantime, yes, you can write CSS in a UI, and It Just Works™.**

What’s The Catch?

This is a fundamental architecture decision. If you are going to use Site Studio to build a Drupal site, you’re saying hasta luego to decoupled frontend architectures. No JAMstack for you - not without a very serious refactor. This is a monolith Drupal site with a capital “M”, make no mistake. 

That’s not necessarily a bad thing, but you are committed once you start.

Deployment workflows are going to change a bit too, but Site Studio does store all those settings and changes as yaml***, so you can still check-in your changes to the repo and deploy up like you would with other config. And while you might question whether that’s the most sensible workflow if all you are doing is moving config yaml around, we recommend tackling that debate over some pizza and a frosty beverage.

Lastly, our early Site Studio testing has raised a few concerns about accessibility, though there’s a lot more testing we need to do to come to any hard and fast conclusions there.

In Summary

Site Studio does what it says on the tin: put up Drupal sites fast and easy without the need for a huge dev team. Keep an eye out for more updates as we continue to explore the product and its use cases.

*Well technically I do, it’s just yaml I made the bots write.
** Yup, it also becomes yaml. Long live robot food. Also this is not a real trademark.
***Annoyingly it’s one file instead of the neatly split up config conventions that core uses. Dear Cohesion team, if you are reading this: feature request!