Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Aug 23 2022
Aug 23

Websites can do far more than just present information. Many business applications have moved onto the web, and with a CMS like Drupal in the back end, your website itself can be an integral part of your business.

Drupal in particular is a great platform for building business applications. Here are a few scenarios that we've implemented:

  • A yacht club manages its moorage database, a guestbook kiosk, waiting lists, events, regulatory compliance for electrical inspections and insurance documentation for its members
  • Staff directories, with staff being able to manage their personal information and get associated with multiple locations
  • E-Commerce and Membership sites, managing wholesale customers with multiple buyer accounts buying for multiple customer locations
  • Checklists that result in a report that may be shared with customers, with details for each item
  • An application to help insurance brokers select the correct carrier from a database of thousands
  • Website calculators to calculate greenhouse emissions

So many of these can be built with normal Drupal and its thousands of contributed modules. But sometimes that results in a confusing user experience, and it's time to get creative to make your application easier to use.

Problem 1 -- Select the right term

For one client, a simple hierarchical selection was not going to do the trick. This client has a database of thousands of insurance carriers they have built up over decades, with specific contact and submission instructions for each one. The problem is, picking the right carrier is not simple. Many carriers have similar sounding names. Some have regional offices to direct requests to. Others are handled by particular brokers. Still others have very specific submission steps.

Looking over the options for selecting taxonomy terms, there are several different modules to help show parent/child relationships, using multiple select widgets, searching auto-completes, tree widgets, and others -- but none show any additional information related to each term.

We made a custom widget to solve this problem. You start typing in a search box and get an auto-completed list of carriers containing matching words.

Once you have selected a term, a box shows up with the term's description, showing information for users to determine whether they selected the right carrier.

With this search, you might find a "parent" carrier, which then loads a second dropdown showing its children. Or, you might find a "child" carrier which also loads the parent -- in either case, you can see the help description for both.

Problem 2 -- Complete a checklist

We love checklists. When we launch a new site, we run through a checklist with over 100 specific items to check. Most of these are shared across all sites, but as part of our process, we will add specific items for each site as well as remove others that are not relevant.

Having an easy way to check items off a list, optionally adding notes, is a game-changer for us. We can now easily create a new checklist for each of our new monthly products, and use that to build a report, train a new user, or ensure that all steps are complete.

Solution - Create custom Drupal fields and widgets

For both of these problems, we decided that "traditional" approaches of using stock field types and widgets was not sufficient. Using one of the newer front-end toolkits like Vue.js or React, we can create an entirely new user experience that hugely streamlines data entry, and improves the quality of the end result.

We chose Vue.js to build these widgets as progressive enhancements, designing the user experience entirely within the browser. They then load and save data back to Drupal using Drupal's built-in JSON:API interface, or as part of Drupal's regular form posting.

Make your forms better!

Web applications use forms to collect data from users, and there's a ton of different elements available to choose from when building out a form. Progressive Enhancements can do even more to improve the user experience, pulling context-aware information from wherever you can think of, to help users fill them out correctly the first time.

If you need a custom widget, or calculator, or other form improvements for your site, reach out!

Jun 12 2019
Jun 12

Glitzy websites are all the rage these days. Everybody seems to be looking for easy ways to create multimedia-rich pages with ease. Yet there is a big downside to the current trend of page builders -- if you're not careful, you might end up making your long term content management far harder than it should be.

WordPress 5 made its Gutenberg "Block editor" the standard for all WordPress sites going forward. Drupal 8.7 added a new "Layout Builder" in its core, adding sophisticated layout capabilities. Both of these are playing catchup to Software-as-a-Service (SaaS) offerings like Squarespace and Weebly -- and a whole bunch of 3rd party modules and plugins that have been filling the gap so far.

The goal for all of these is to make it easy to interleave text with photography, video, galleries, and animations using something approaching a drag-and-drop interface. Yet how they go about doing this varies drastically under the hood. In broad strokes, you can group all of these layout builders into one of 3 categories:

Broad categories of layout builders

  Field-Oriented Repeating Templates Embedded Layouts Module or Plugin

Drupal "Layout Builder"

Drupal Panels, Panelizer

Display Suite

Custom themes, page-type templates

Drupal "Paragraphs"

Field Collections

Entity References/Inline Entity Form

Commerce Variations

WordPress Gutenberg

Drupal Entity Embed

Vast majority of WP layout plugins

Where items are stored Individual fields are in individual database tables/columns `Multiple entities are linked together to build up a page Everything is dropped into a huge text field Best for Managing huge numbers of similar items Keeping content and presentation separate, to allow re-skinning down the road, while still making rich authoring relatively easy Very easy authoring Drawbacks Slightly less flexible -- harder to change up the sequence of rich elements Not as organized as field-based layouts, harder to extract, search, and aggregate information Very poor at reusing information on other pages, inconsistent look across the site, hard to update overall look and feel, finicky to use and get "just right", often has accessibility issues

That's the summary. Now let's take a look under the hood...

How do layout builders store their data, and why should I care?

Which is the best tool -- Excel or Word? Entirely depends on the job you're trying to do, of course. Yet these layout builders are as different as Word and Excel -- some are excellent at creating long documents with lots of variation, while others are far better at preserving data so you can show it in a chart, do math, and more. You wouldn't pick Excel to write an essay, for example, and you shouldn't pick Word to track your finances.

If you are creating a rich landing page for a campaign, a layout builder that takes the Embedded approach can get you there quickly. Lots of support for drag-and-drop, lots of ways to quickly get a result. You can build 5 more while you're at it -- but now try to compare things across 50 of these one-off pages -- now suddenly not having a template and simple fields to fill in makes the job much harder. You create pages for a bunch of products, and then you go to create a product comparison chart, and you're building that table by hand, cut-and-paste.

Or say for example you are a research institution, publishing research papers from dozens of contributors. You can make a nice landing page for each paper, with sections for the author's biography, the category, methodology, supporting organizations, and various other items -- but if you don't put each of these in its own field, it gets a lot trickier to build a nice search interface that will help your visitors find what they are looking for.

What is Content Management?

There are plenty of definitions of Content Management out there, mostly by vendors looking to sell you on a specific system, or pedantic descriptions of how big companies (Enterprises) need all this sophisticated stuff. While we are a vendor trying to sell you on something, let's take a moment to clear away all the B.S.

Website Content Management is about creating, maintaining, curating, and cultivating on your website for the entire life of the website. The problem with this focus on Layout Builders is that all the focus is on that very first step -- Creating. It ignores the rest of the lifecycle of your content.

At Freelock, we believe the longer you keep good content on your website, the more valuable it becomes. And keeping old content maintained and relatively fresh is a big part of that job. A Content Management System can help you keep your old content fresh -- keeping it looking consistent with rest of your site, bringing in new traffic, guiding people down your sales funnel to become customers, providing reputation and longevity that assure your customers you're not just another fly-by-night operation.

Embedding all of your rich content into one-off pages hampers this very process, especially when you want to change the look-and-feel of your website -- or find, re-use, or change the overall experience of your oldest content. Let's drill down into these different types of builders to see how they compare, for the longer term.

Field Oriented Layout Builders -- the Excel approach

Drupal Layout Builder Adding a custom block to a page using Layout Builder

Drupal excels at information architecture, and so the layout builder Drupal chose to include in its core supports this way of thinking about content. With the ability to easily create fields on different content types, and aggregate content using the powerful "Views" module, Drupal is all about information reusability.

There are dozens of different kinds of fields out there, and an even larger number of ways to use each one. For example, if you add a date field for an event, you can show it on a list of upcoming (or past) events automatically. You can show it on a calendar view. You can show it in a list, or a set of cards.

Add a geolocation field, and now you can show it on a map -- and you can filter that for upcoming events near me. Add a price and now you can create a "facet" that lets you see items between certain price ranges. All of this power builds on all of the other kinds of information stored in fields, and makes it easy to manage hundreds, thousands of similar items.

The new Drupal Layout Builder lets you easily create a template for showing each of these fields in a particular spot on the page, create multiple columns, drag-and-drop items around. In addition, you can create one-off blocks to highlight certain items, and reuse that on other items -- change up the layout entirely on a single item, if you wish.

Managing field layouts in the future

Down the road, if a product is no longer a special snowflake, hit a button and it reverts to the same layout as all the rest of your products -- the layout is stored in "just" another field on the item.

If you want to show a Google Map or a thumbnail linked to a file, you would have a field for the location to show and another field for the media. Then when you place the location field on the layout template, you would pick the "map" renderer to show a map for the field, and when you want to show the downloadable file, you could specify the size to generate the thumbnail and place it where you want it -- and it will look consistent across all the items in your site.

Want to change your design? Swap out the Google Map renderer for OpenStreetmaps, and all of the maps on your site use the new service immediately. Change the thumbnail size for the document, and move it to the left sidebar, and it's done across your site.

Embedded Layouts - the Word approach

Gutenberg in action Gutenberg editor in action

The new WordPress Gutenberg editor is the poster child for the opposite way of creating rich layouts. Instead of having a field for each kind of data, you start with a blank page and a collection of blocks you can drop into it.

Honestly, I like using Gutenberg -- once you figure out the basics, it's mostly fun to use. Its killer feature is management of "Reusable Blocks" -- create a chunk of boilerplate, save it as a reusable block, and then you can reuse it on any other Gutenberg page. You can keep it in your page as a "reusable block" or you can convert it to a regular block and edit it.

You can create entire templates this way.

This... this is awesome for creating proposals! Or reports, or anything you need to do once, and don't care much about how it will look in 5 years.

It's very rapid for creating pages, and if you are constantly editing some key landing pages, Gutenberg seems like a fine way to go.

However, for content that's going to stick around for years, especially through a site redesign, it's going to be a bit of a nightmare. And right from the start it stops being useful for a huge number of scenarios modern sites are trying to support.

Very little design control

One thing a CMS attempts to do is make your site look consistent. One challenge with Gutenberg and other approaches that largely dump styles as well as content into a big text area is that it makes it much easier to violate your site's design, leading to ugly, confusing, jarring sites. Having spent several years as a professional writer, seeing garish colors and inconsistent fonts and font sizes makes me shudder. I don't want to have to think about what it looks like -- I just want to write it and trust the designer to make it look good.

Useful data is embedded, hard to reuse

I see blocks for "Product Comparisons" for Gutenberg. Wow, drop these in and you get some boxes where you can enter stuff -- cool!

But... you have to enter that stuff. And it already exists, on the product pages. Wait a second -- I thought this was supposed to make my job easier? And... hey, I have a new product that just varies in two of these areas. Which page did I put that product comparison on?

Managing changes in the future

Back to the earlier scenarios, now I want to switch from Google Maps to OpenStreetmap. To make this change, I need to do a search and replace -- find every map on my site, and generate a new widget from the new map provider. Lots of manual work. Maybe I can find or create a script, but even so, it feels a little brittle -- if I chose a different map style on one page, I might not find that one. And change my document thumbnail to move it to the other side of the page and shrink the thumbnail? Geez, I have dozens of those to do now.

This is the big "mistake" of embedded layouts -- managing content down the road.

And this is not new to Gutenberg -- the vast majority of page builders for WordPress essentially work the same way, embedding "short codes" into the body, and the only way to find them is search.

This is part of why I've heard many shops say you just need to start over and redo your website from scratch every few years.

If you've kept your content separate from the design, that is entirely not true -- having to rebuild your site is entirely the result of having your design too entwined with your content.

Repeating Templates -- a Hybrid

Nested Paragraphs Nested Paragraphs

In between these two extremes, there is a third way. The best current example of this approach is the Paragraphs module for Drupal.

Compared to field-based layouts, you can easily make pages with a bunch of varied layouts, changing the layout as desired, one row at a time. If you do this very much with a field-based layout, you end up with a bunch of blocks hanging out that can clutter other parts of your CMS, and you end up constantly tweaking the design to get a result that looks good.

Compared to Embedded layouts, your content is still entirely separate from the design, making it easy to re-skin down the road. And you can still use fields that can be extracted and compared/searched/reused, although doing that effectively takes a fair amount of upfront planning.

We typically create a set of paragraph types, such as:

  • Plain text
  • Pull quote
  • Image and text (image to the left or right)
  • Photo Gallery
  • Large media (video or image)
  • Columns, cards
  • Tab set, Accordion set
  • Slide carousel
  • Embed a view

When creating your content, you can add these in any order you like. We can provide particular classes for color variations, locked down to your brand's style guide.

The design remains very tightly controlled. Data is not necessarily easily reused -- but you can have a section of Paragraphs on content that still uses fields for all of the data management scenarios you like.

Because everything is templated, a re-skin of the site can make changes to one of these templates and it instantly applies everywhere it is used.

So which layout type should I use?

Should you use Excel or Word? Well, of course, you should use both, if you need them. There are very compelling reasons to use fields -- they are essential to Content Management, and many, many ways they make your work much easier. But there are times when dashing out a quick document, or web page, is needed right now.

By making Gutenberg its default editor, WordPress has gone entirely to the right side of that table -- they are trying to focus on being a good page builder, potentially at the expense of content management. Do you need content management? Depends on how much content you have to manage! If you're only talking about having a nice brochure site, and a steady stream of blog or news posts, this is all fine. But the more sophisticated your needs, the more you're starting to go against the grain. You can add fields to WordPress, and create views of content -- but this involves either creating some code or finding plugins that will help you do this -- many of which are not free/open source (a discussion for another post).

With Drupal, on the other hand, you can choose all three. You can even have all 3 on the same website! We are already using Gutenberg in Drupal on some sites, and we're using Paragraphs almost everywhere. Meanwhile we are very impressed with the new Layout Builder, and find it just the thing for making attractive layouts for certain types of content. You can have your Word, and your Excel too!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web