Getting to know Page Builder (part 1 of 2)

Last week, ITS released our 2.0 version of the UT Drupal Kit. It adds quite a lot to the University web developer toolkit, supplementing the centralized CMS ecosystem that has so far consisted of the University Blog Service and the (now legacy mode) UT CMS.

What, exactly, does it add? In addition to the UT-branded theme we’re calling “Forty Acres,” it has a custom, drag-and-drop interface for assembling pages, whose functionality was developed by Springbox. We’ve dubbed our broader re-tooling of this “Page Builder.”

So what, exactly, does Page Builder do?

First, a bit of technical background. If you’re using a content management system for your website, you primarily work within an interface that allows you to manipulate site data. This is called a CRUD (create-read-update-delete) interface, and its fields are usually not too different from the actual data model that stores your site content. This is often referred to as the abstraction layer, as it is a abstract representation of what the website will actually display.

However — and this is the important bit — this interface looks completely different from how the data is actually presented to someone viewing your site. That part is called the view or presentation layer.

It’s fairly straightforward for a CMS to provide a single view for a single data model. For example, a “blogroll” view might provide a list of most recent blog titles with teaser text and a read more link; the “blog page” view would provide a full post with a link to the author; and a separate “author” view would display a bio of the author.

What’s not so straightforward is finding an intuitive way to manipulate display on a per-page basis. What, for instance, should the content creator’s experience be for placing certain sidebar content on one blog page but different content on another? Or for setting yet another blog page not to display a sidebar at all?

One approach is to let the user create lots of micro-content, then create completely separate pages to which that content can be assigned (this the the approach used in Drupal’s “Panels” module). The advantage is that micro-content can be easily re-used across pages. The disadvantage is that the micro-content is inherently disconnected from the actual page, and as a site grows, can be harder and harder to manage.

Another tack: let the user create many different view “templates” that set fields/widgets to show up in various, predetermined locations (e.g., Drupal’s “Display Suite” module). Then, on each page, let the user assign one of these templates. This solves the issue of content bits being disconnected from the page, but it comes at the cost of rigidity: variability in page display is limited by the number of templates available.

Add to this that the existing solutions — whether the WordPress interface used by the University Blog Service, or Drupal’s Panels or Display Suite modules — are not intuitive. The act of designing where content should appear is disconnected from seeing what it actually looks like.

So. Question: how do you bridge the gap between abstract data and its presentation in a user-friendly way?

Hypothesis: could you just drag and drop data pieces where you want them to go, directly in the view?

Answer: Page Builder.

With Page Builder, you start by creating a new page — no pre-assembly of micro-content required (you can, however, add pre-assembled content with Page Builder, as I’ll discuss later). You then choose one of the available layout templates:

Next, you start adding fields that will appear on the page. The UT Drupal Kit comes with quite a few.

While other approaches stop here — you’ve chosen your template, you’ve created your data, and that’s what you get — Page Builder goes one step further. While looking at the actual view site visitors will see, you can now drag and drop fields into any available region in the chosen template:

Closed is the interface gap between data model and view, and just as importantly, page design variability is multiplied by factorial: with 11 templates (you can add your own, too), each of which have up to 6 layout regions (main content, sidebar top, main content bottom, sidebar bottom, etc.) and with 14 separate field widgets to assign to any of these regions, thinking of page design as “Which layout do I choose?” is no longer useful. Instead, on each page, you can ask, “How do I want this page to look?” And here are just a few examples of how it could look:

• http://drupalkit.its.utexas.edu/content/landing-page-template-1
• http://drupalkit.its.utexas.edu/content/landing-page-template-2
• http://drupalkit.its.utexas.edu/content/landing-page-template-3

So, we have a much more intuitive interface for designing pages. Are there any trade-offs?

The answer depends on what you are trying to accomplish. Page Builder lends itself to building unique page content on each page. It is not the fastest approach if you want to reuse content bits across many pages (e.g., a sidebar you want to appear on a certain subset of pages). Content redundancy versus uniqueness is an information architecture decision that depends on the site, and depends on how users are going to interact with your site.

For full documentation and a link to download the Drupal Kit, go to https://wikis.utexas.edu/display/UTDK/UT+Drupal+Kit

See also Getting to Know Page Builder, Part 2: a deep dive into how Page Builder is implemented in Drupal.