Behind the scenes look into the Mercury Editor with Justin Toupin of Aten Design

Agiledrop is highlighting active Drupal community members and interesting projects through a series of interviews. At the recent DrupalCon Prague, I had a great conversation about the Mercury Editor developed by Aten Design Group with their CEO Justin Toupin.

We’ve recently already featured Justin in an interview and he already spoke about the Mercury Editor then, but the opportunity to learn more about it from Justin in person was too great to pass up, and I’m excited to be able to share our insightful conversation with our readers.

 

1. What is the Mercury Editor and what were the main reasons behind the decision to create it? 

Mercury Editor is a tool built in Drupal, on top of Drupal, for really easy-to-use, low-code or even no-code, drag and drop editing. It's built on Paragraphs, so it's built on systems that a lot of Drupal developers are already familiar with.

And something that I feel is really important, is that it still embraces this idea of structured content. So it's still following the same model that exists in Drupal of entities and fieldable entities. It's not doing something else to manage the content, it's still adhering to structured content.

What led us to start investing in developing it was, in my view, the lack of a good authoring experience using structured content. And if not the lack of a good authoring experience, maybe a better way to put it is just the fact that what we're offering authors right now in Drupal is really complicated, really hard to use. It just doesn't stand up to other tools like WordPress or SquareSpace, where literally everyone has a story. 

With Drupal, we have a lot of flexibility and a lot of capability from a technology perspective, but often at the expense of the authoring experience. And so that dynamic is something that we've been concerned about for a really long time. 

And I think now several years ago, right at the beginning of Drupal 8, and actually in Drupal 7 as well, we started looking at ways to improve that and try to build a more flexible component-driven approach to editing and managing content. 

Fast forward several years, we started thinking that Paragraphs could be the basis for this. Combining layout with paragraphs and developing this really flexible, easy-to-use approach then led to Layout Paragraphs, which is a module available on drupal.org that combines the layout API and enables easy management of layouts with paragraphs.

And then on top of that, we have further built this authoring experience that we're calling Mercury Editor. To clarify a little bit about what that is: for us, Mercury Editor is still open source. It's a collection of Drupal modules, plus customization, targeting specifically the needs of each client's project, each client site. 

 

2. Is there a story behind the name “Mercury Editor” – why “mercury”?

The big thing is, mercury the metal, it being super fluid, just kind of works well with the idea of a fluid editing system. We even played with the word ‘fluid’ directly. We ended up moving away from that for a few reasons. 

But the idea is, this very flexible metal seemed to play into some of the themes of the editor. Over the years, our own agency brand has developed into a lot of space themes, exploration, kind of future-forward explorations. We find some of the humanistic themes and space exploration to be pretty interesting. So Mercury the planet kind of works for that too. 

So that word seemed to work well for us to convey some of the properties of the editor itself. And the logo itself reflects it as well, featuring this kind of shapeless, yet shapeful iconography. 

 

3. Is there a specific market which you think that the Mercury Editor is best suited for? 

That's a great question. The ideal customer, the ideal user for Mercury is marketing and editorial staff. A couple of years ago, I was doing a demo with a large public university in the States, right in our area. There were half a dozen people on the call, all but one of them Drupal developers. And then there was one marketer. 

And we went around the room at the beginning and everyone was saying what they do and why they're there. And of course, each Drupal developer was like, well, I’m a Drupal developer, I'm really interested in what the thing would do for our Drupal ecosystem. 

And we got to the marketing person and they said, oh, I'm in marketing, I'm all about content. This stuff is all going to go over my head. I'm just here to listen. This is not for me, I'm just here to listen. 

And of course I'm thinking, this actually is for you. And we did a demo and after the demo, the conversation completely changed and that person was asking all the questions, super excited about what this meant for them, their department, their ability to own the authoring experience – or rather, their ability to own the content, their ability to have autonomy about creating content.

Suddenly it's like, oh, I don't have to call a developer every time I want to do something a little bit different. I have a lot of flexibility with how I publish content, which, given the year we're in, is where publishing tools should be. 

And I think that too often we think about the developer experience, the total final capabilities of the system, and don't give enough consideration to people who want to tell a story. That's what a content management system is here to do – empowering those personas, those people, to do that kind of work. 

Specifically, marketers and editorial staff in universities and university settings – a lot of universities are moving to distributions with Drupal, where they use a single distribution and then spin that up for different internal customers in the university. 

Mercury or at least Layout Paragraphs is the perfect solution for that; it gives a lot of autonomy, a lot of flexibility to each internal customer in that sense. I think publishing sites, clearly, can make use of this kind of thing, as well as cultural heritage institutions like museums – anyone who needs to tell a flexible story. 

And it's still easy to create components and to create a library of components and have some governance and limitations around what can be created. So it's both giving autonomy to people who care about content while also doing it in a structured, predictable way. 

 

4. Did you face any challenges in creating the editor, first in the discovery phase when you were finding the “how”, and also later in the implementation phase when you started putting everything together?

Of course. Early on we were pushing Paragraphs pretty hard with clients. And there were a few clients, one in particular comes to mind, who pushed back quite hard. As developers, we could see the capability and flexibility of everything Paragraphs could provide for them.

But for the people on their team who care about content, it was just too complicated, to the point where eventually the client was like, stop talking to me about paragraphs, it's too complicated. This solution isn't going to work for us. 

And honestly, that got me thinking, it's true, this thing that we've been pushing, it works, the capability is there, but it's not a good authoring experience. So that was one of those early challenges that pushed us to go further and to try to build more sophisticated tools on top of Paragraphs.

The deal with Paragraphs is that it already provides this really solid approach to structured content – fields, fieldable entities, all these structures already exist in Drupal, and all that functionality comes along with that. 

That was one thing early on. Also, just as an agency, we exist to serve clients. The needs of our clients are all very different. As much as we try to reduce the amount of custom work to the greatest extent we can, just for efficiency's sake, the needs of each project are still unique and different, and we're always pulled in different directions. 

So, anytime an agency ends up trying to develop a product, there are challenges inherent to that. We have to go where the client work is. It's not always in line with where we're trying to take this thing. That said, since we are so focused on people who care about content and our clients care about content, it's worked for us and against us in some cases. 

 

5. You're very likely aware that there are alternatives that already exist in similar ways, no-code, low-code solutions. Did you learn about those too, or did you just say, let’s leave it, let’s not fill our heads with what someone else did, and just start from scratch?

That's a great question. I would say yes, we have explored what else is out there, of course, especially in the Drupal universe. And there are a lot of other great tools out there. Gutenberg, which started as a WordPress plugin, has been in Drupal for a while. It’s a really great system for this block-based, what-you-see-is-what-you-get editing experience. 

The challenge for us is, Gutenberg or CKEditor 5 or any of these open-text WYSIWYG editors end up stepping outside of some of the very strong structured content principles in Drupal. So you lose fieldable entities, you lose all of the APIs that are built on some of those low-level systems, and you end up having to build something else for governance, for permissions, for migration, etc.

If you build, say, a testimonial widget in CKEditor 5, and it's just going to save the content in line with this template that you created as markup in the database, if the format of that changes later, you have to somehow account for that in future migrations and develop some kind of consistency. It's not just built in.

Whereas if you're working within fields and fieldable entities, it's not perfect, but a lot of that's taken care of for you. So it's much easier to get those mappings right in the future.

And that's what we were most interested in – leveraging some of those concepts of structured content that exist in Drupal and that are already so well executed in Drupal rather than doing something else.

 

6. Why is drag and drop such an important feature in modern digital experiences, besides the obvious marketer need that we’ve already talked about?

I like that question a lot too, because in reality, I'm not sure that it is that important, And what I mean is, I don't think it's drag and drop exactly that's important, but I think it's what drag and drop represents.

It's really like the low-code, no-code piece. It's the idea that there should be tools for an editor to seamlessly, easily, in a very expressive way create the content that they want to create and be focused on the story.

I was just talking with somebody yesterday about this who found that their editors don't actually like drag and drop. They want to be able to move things around with the keyboard. Or they want more interactive tools.

Everyone understands drag and drop. So when you say, hey, it's drag and drop, they at least understand what you're saying, that it's not writing code and it's flexible and they can use a mouse and a keyboard to make it happen. 

But in reality, the piece that I think is so important has less to do with the specific interaction of dragging and dropping and more to do with creating an experience that allows content writers, people who care about content, to create exactly the kind of content they're interested in in a very easy way.

So that's what drag and drop represents. To me, it's more a low or no code authoring requirement.

 

7. Do you have any interesting case studies to showcase the Mercury Editor?

Mercury has been a part of a lot of client projects at this point and it's in a lot of client projects that are ongoing, such as the Florida State University Libraries, the Guttmacher Institute and Tufts Now.

One thing I've been working on recently that's been really interesting is a decoupled implementation of Mercury, for Quadient. Seeing Layout Paragraphs in Mercury work in a decoupled environment has been really cool. And using this Drupal construct to drive a VueJS experience has been really interesting.

And it's also given us a chance to start creating some best practices for how we interpret layout in that front-end system. It's been interesting to validate one of the reasons that we went down this path and that we wanted to use existing constructs in Drupal, things like JSON:API, which is, of course, pushing out the entity content – it just works. 

We just get all the layout information in JSON:API. We can easily interpret that in the front end and do whatever we want to with it. So that's been really cool. We're talking to some universities about using this in their distros, which is also really exciting. And hopefully by next DrupalCon we'll have more specific cases to show off. 

 

8. Besides the obvious content authoring benefits for clients, what are the other benefits for users, also in financial terms – does this mean that they get more for less?

Absolutely. First off, it means reducing ongoing development costs. An organization can define the components that are appropriate for their content ahead of time, at the time of build.

They can define their library of components. They can set up the governance rules around what can be published in what way, and then turn that over to their authors, to their writers. And they don't have to keep going back to the development team to keep adjusting to the needs of content moving forward. 

Right now, often, when editorial teams or marketing teams want to create something that looks a little bit different than the last thing they created, they're calling developers. And that can really drive cost.

And this means cost in two ways. One is just the financial cost of having to involve an agency or your development resources, which are often in high demand. But the other cost is in time, having to wait to get on some schedule, to get on a specific team’s agile backlog, and wait until the priority is just right to have your piece of content created. There's an expense there in terms of time.

Mercury saves money in terms of reducing development costs. Actually, even the upfront cost for Mercury is not terribly significant when compared to all the other custom approaches in Drupal. So, it reduces the ongoing development cost and it reduces time to market, because marketers can move and create exactly the kind of content they want really quickly.

 

9. How do you see the future of Drupal in the context of low-code / no-code?

The future of Drupal is a big question. I don't even know where to start. The developments in Drupal 8 and beyond are really exciting. Composer-based architecture, pulling in third-party libraries, just generally making it easier for developers to collaborate. There's been a lot of focus on the developer experience, and that's awesome.

I'm hoping that we also start to see more and more focus on the authoring experience. And I think we're seeing some of that; we see it with Claro now being the default admin theme, and it's such a huge improvement from what we had before, seeing the work that's happening with the Gin admin theme on top of Claro. 

And as you said, there are lots of tools, there are lots of people investing in this authoring space. Again, I think the developer persona has been first and foremost in Drupal for years, since the beginning. And I think we're starting to see more and more attention paid to the marketer and editorial staff, the writer, the journalist, the storyteller persona. 

Hopefully that continues to be a direction that Drupal focuses on. That's certainly the direction that my agency is focused on and where we want to take our work with Drupal. 

And then I think as far as how low code or no code plays into that, when we're not talking about a developer persona, no- and low code is very important, as we're talking about people who have very pressing, important work to do – and it's not coding. 

And for us Drupal people, that's often hard to get our heads around – like, what do you mean, pressing work is not coding? But for people who care about content and have important stories to tell, the work is the content. And the mission often is the content. And so in order to get that right, we have to be thinking in terms of low and no code.

 

10. I remember the Driesnote from Portland and one thing that really resonated with me back then is that Drupal should be for ambitious site builders. A couple of years ago, we talked about ambitious digital experiences, which involved predominantly back-end work. And now that’s shifted to ambitious site builders. 

This could be understood as moving more into low code – not yet no code, though, since site builders typically still need to do some basic coding. But this is something that also needs to be taken into account, how Dries and the Drupal Association see Drupal evolving.

I agree with that. That idea worries me a little bit also because I think sometimes it's almost like we try to make the wrong things easy in Drupal. Creating a front end for Composer, for example, where developers, the people who are often using Composer to manage dependencies, are very comfortable using it.

It's the same with Git. Who uses a UI for Git? I mean, there are some good ones out there that people use a little, but just about everyone uses the command line for Git. There’s no need for more than that.

I’m more concerned with clients and organizations, especially in larger organization settings, e.g. a university where you have a core web services team who is managing the web presence for hundreds, sometimes thousands of websites across the university and trying to serve those internal customers.

Where I want to see things go is where the people who own those sites, who are writing content for those sites or actually have to maintain them, are excited about the capabilities of this thing that they have.

Often that's not quite the case. Often it's the site builder providing those services who's excited about that. And maybe that's just it. Maybe “Drupal's for ambitious site builders” is like a starting point, or it's along the way on that journey toward embracing those non-developer personas.

Because at the end, it's all about content. It's all about publishing content. And the people who are actually publishing content, who have the important things to say, need to be empowered to actually do that.

 

11. I almost feel like we’re going in this direction that maybe we as a Drupal community or people from Drupal agencies don't listen to marketing people enough. Or am I wrong here?

No, I don't think you're wrong. I think that's true. We still tend to live in this very developer-centric, developer-led world – let's call it the IT world. It's not per se the IT world, but let's say the complexity of Drupal would be better appreciated by an IT person as opposed to a content author or a marketing team.

And this could cause friction because we did get buy-in with the IT team. But in the end, the IT team probably won't decide the how, what & who, because it’s usually marketing budgets that decide on which way to go.

I think we're too driven sometimes by the sheer capabilities of the product rather than how well it meets the needs of the people who are actually going to be working in the product, creating the content, pushing the content out.

And often, the people who are getting most excited are the more technical personas or the CTO type – so, the technology segment in an organization; and the marketers or the writers are like, okay, I guess I can make this work. 

“I can make this work”, that tends to be their response. And I'd love to see it go further where it's an exciting and joyful experience for people who are actually creating content to do their work, to create the content.

And there are other systems out there that are doing that. When people are evaluating Drupal versus WordPress, for example, we often hear them say, we don't need all that complexity in Drupal. WordPress is so easy. Our authors just get it.

And I feel like we could be there with Drupal and that's the direction we want to head in. That's kind of what's wrapped up in this product for us.

 

12. That's a perfect wrap up for Mercury. It's like buying a sports car. It's nice, I guess. But if you're stuck in traffic, it doesn't make a lot of sense. You can have, I don’t know, 800 horsepower and 22 inch wheels – but the car behind you is a 99 Toyota, and you’ll both get to your destination at the same time.

It’s basically what we touched on now, with the complexity and the capabilities – excellent, but I can make do with a Toyota (okay, maybe not a Toyota 99). But it makes sense that if your clients are telling you, I need a Toyota 2022, I don’t need a Maserati 2022 – this is where you should work.

I think we have to make sure that we're listening to the right people and that we're paying attention to the right features. And that's not always happening – sometimes, again, because the developers were focused on a different set of features. 

And can we make this, again, using kind of the raw capabilities and making things work with, like, nested references, three levels deep. Does it work? Sure. Is it flexible? I guess so. Is it easy to use? No, and that's the problem.

 

13. Drupal as a whole and even a lot of sales people in the Drupal community have an engineering background. They tend to get sucked into that. And once presenting to the client about what Drupal can do, they forget about the client and just focus on all the benefits, all the capabilities, and everything that you can do with it. 

But the client wants it really simple, they’re not focused on back-end capabilities because they don’t need them. And somehow, that engineering background of different people who are now in different roles, becomes an obstacle. 

For us, during presentations and pitches, when we show what’s possible with Mercury, if we're focused on the marketer, the writer persona, those presentations go so much better. 

And then it's easier for somebody to accept, okay, I get it. I get all these features around security, governance, best practice, scalability, structured content, all the stuff that Drupal is great at, that we get excited about.

What we've seen to be a really effective selling tool for it is – is it easy to use? Is it easy for my content to use? That's the part that people are most excited about. To me, it all comes back to creating tools for the people who are actually creating content and keeping them front and center.