Pagebuild Case Study

Pagebuild allows non technical users to build websites very quickly and easily. It was built on top of Drupal, with the idea behind it being to provide an editing interface that is so simple, even an adult could use it. This is a explanation of what we did and how we went about doing it (and why).

Motivation

Spoon Media has been building Drupal sites for the last 6 years. We generally do mid to large size projects and pretty quickly we noticed how often we were turning away business from companies with modest budgets. That wasn't great for them, because most low budget web solutions are pretty ordinary and it also meant we were sending small jobs elsewhere. This was the main motivation for building Pagebuild - we wanted to let small business get a great website at a inexpensive price but still retain a high standard of product.

High Level Architecture

Pagebuild as a product consists of two main systems which we've dubbed front-end and back-end.

The front-end is the software that allows customers to edit their Pagebuild site. This consists of a series of custom Drupal modules and a whole lot of JavaScript that provides the easy to use WYSIWYG experience.

The back-end is the software that allows customers to signup, create and manage their websites. Aegir is used to provision and manage sites and custom Drupal modules provide a simple customer interface to the site provisioning and management process, as well as the standard account and billing settings.

Both the front-end and back-end are powered by their own Aegir platforms.

Of course we use a bunch of great Drupal community modules across both systems. More on that follows.

Front-end

In order to provide an incredibly simple site editing interface it was clear from the beginning that the bulk of the work on the front-end would involve using JavaScript to implement the desired UX.

jQuery, jQuery UI and a series of jQuery plugins are used extensively.

I'll explain the motivations and provide some light implementation details for selected features.

Editing

It was very important for us that the editor was truly WYSIWYG. It wasn't enough that a heading was a heading and bolded text was bold. We needed headings to be styled exactly the same whether the user is editing a content area or viewing it. As a result we threw out the idea of using IFrame based WYSIWYG editors such as CKEditor or TinyMCE.

Another requirement was that users should be able to freely drag and drop images from our Media Manager into the content area. Doing this with an IFrame based editor was not possible.

After much back and forth we settled on Twoism's reviser as the base for the WYSIWYG editor. I say base, as significant Pagebuild specific changes were made in order to get it work just so.

The result is that we are able to provide a true WYSIWYG editing experience that is completely tailored to the Pagebuild Way.

One of coolest features of Pagebuild's editing would have to be the ability to drag images from the Media Manager toolbar and drop them into the content area at a position that makes sense visually. Unlike other drag and drop solutions in web WYSIWYGs, Pagebuild won't allow you drop an image in the middle of a sentence. With jQuery UI's sortable plugin we are able to force the image to be moved around the content area and dropped in sensible drop zones.

Blocks and regions

Of course it's not enough for users to be able to edit the main content area. In order to allow the user to create unique and flexible page layouts we leverage Drupal's regions and blocks to make this happen.

When editing a page regions can be shown or hidden, and blocks can be added to regions. This all happens via AJAX, and creating/editing/deleting blocks happens on the page itself to prevent interrupting the editing experience. As an added bonus existing blocks can be dragged from one region to another.

Themes

We provide a number of free themes for customers to choose from. All Pagebuild themes are Zen subthemes. On top of being a great base for our themes it was required in order for our JavaScript to work, as we need all DOM classes and IDs to be consistent across themes.

When a user selects a theme from the Switch theme toolbar we simply set that theme to be the default for all users, and make sure the block visibility remains the same.

I'll talk more about how themes are put together a below.

Back-end

Where the front-end development was largely JavaScript backed up by Drupal modules to make the magic happen, the back-end is true to its name in being largely the work of Aegir and custom Drupal modules.

Provisioning

From a customer's perspective the Pagebuild adventure begins with sign-up. Here we capture the customer's details, process the payment and provision the site.

We use Aegir to provision new sites automagically when the customer has finished signing up. Aegir, being as wonderful as it is, makes this incredibly simple. All you need to do is create a node of type site, and it will be added to Aegir's task queue.

After sign-up the customer is automatically logged in and presented with the Pagebuild Dashboard. Once the site has been provisioned (which usually happens inside of 60 seconds) they can login to it and start editing right away.

In order to implement a Single Sign On the back-end acts as an OpenID provider. Our custom Drupal install profile adds an entry into the authmap table allowing them to login to their site without having to re-enter their login details.

The custom Drupal install profile on the front-end communicates with the back-end database to setup themes, roles, filters, pathauto and imagecache settings, amongst other things.

Once a customer has signed up they can add new sites to their subscription with a simple single page form.

Domain settings

When a customer first signs up they are asked to enter a subdomain for their website. Initially the site is provisioned as example.pagebuild.net.

Once the site is provisioned though, the customer has the option to use any domain of their choosing for their site.

Again Aegir makes this very simple. When the customer submits the form we check that the domain they have specified points to our IP address. This prevents the site from being unreachable if the A record doesn't match. Once we've checked the A record points to the correct IP address we create a migrate task in Aegir, which goes off and renames the site.

Thanks Aegir!

Theme editor

Customers are able to choose from a set of free themes or they can make their own theme.

Using one of our themes as a starting point, the user can alter every aspect of the design from their browser. They can then save their theme with a new name, effectively forking it from the pre built theme we provided. This concept is used in both Drupal Gardens and in the Sweaver module, however both of those implementations allow so much freedom as to be confusing to a non technical user. We have taken the concept and made it harder to do silly things to your theme by restricting what HTML elements you can actually modify. Whilst this limits the power of the theme editor, on the whole it results in a better theme when used by a novice.

Custom themes

While we provide free themes for customers to use on their site, we also provide them with a service whereby they can purchase a customised design. This is not automated and involves the customer talking with a designer to get a result.

In order to greatly simplify the process of creating themes for Pagebuild we implemented a simple templating language that allows designers to write minimal HTML and as much CSS as they require to get the look right. Each theme only requires a single theme template. This is about all it needs to be:

[START]
[REGION:header]
[NAVIGATION]
<!-- #masthead, #masthead-inner -->
<div id="masthead">
<div id="masthead-inner" class="clear-block">
[LOGO]
[SITENAME]
</div>
</div>
<!-- /#masthead-inner, /#masthead-->
<!-- #main, #main-inner -->
<div id="main">
<div id="main-inner" class="clear-block">
[BREADCRUMB]
<!-- #content, #content-inner -->
<div id="content">
<div id="content-inner">
[REGION:top]
[PAGENAME]
[CONTENT]
[REGION:bottom]
</div>
</div>
<!-- /#content-inner, /#content-->
[REGION:left]
[REGION:right]
</div>
</div> 
<!-- /#main-inner, /#main-->
[REGION:footer] 
[END]

Using the token module we replace the Pagebuild theme tags with the Zen markup required to make sure the theme works with the Pagebuild editor.

Designers upload the template file, a CSS file and whatever images are required and a complete Zen subtheme is automatically generated and copied into sites/all/themes ready for use.

The permissions on individual theme nodes ensures the theme is available only to the customer who purchased it.

Custom themes are currently only available to designers we have an existing relationship with. In the future we plan to open this feature up to more designers. Further down the track we will open the feature to customers themselves.

Subscriptions

Initially we tried using Ubercart, uc_recurring and various payment modules for the checkout and subscription payments. It turned out this added an unnecessary layer of complexity to the system. The Ubercart product wasn't meshing well with the existing Aegir and Pagebuild CCK types. Eventually we replaced the whole thing with a simpler custom built payment and subscription module.

The uc_hosting module to integrate Aegir and Ubercart looks promising, but we needed to move quickly, and rolling our own system allowed us to do that. Another benefit is that the payment system is tightly integrated with the rest of the Pagebuild system. This allowed us to do exactly what we need to do without working around the assumptions inherent in Ubercart, uc_recurring and the payment modules.

Main challenges

Internet Explorer

The the first half of development we aimed to support IE7+ for page editing. After considerable effort we decided to ditch native IE support, and instead create a simple UX for the customer to install Google Chrome Frame.

We are really pushing the limit of WebKit and Gecko browsers when it comes to building WYSIWYGs, and we decided that a superior experience was preferable to a lowest-common-denominator one.

The UX we provide for customers to install GCF is as simple as possible, and we doubt it will deter customers.

Of course, GCF is only required for customers when editing their site. We support IE6+ as well as the proper browsers when viewing Pagebuild sites.

Content editable

Instead of using an IFrame based WYSIWYG editor we decided to use a feature of some browsers called content editable.

While we believe this provides a superior editing experience, the cost is in the fact that it is not uniformly supported across all browsers. Worse, some implementations are particularly bad. Anecdote alert: In order to fix a bug caused by Firefox's implementation of document.execCommand we were forced to build a debug binary of Firefox and step through the rendering code in gdb.

Despite the additional effort required in rolling our own WYSIWYG editor, we are very happy with the experience we've managed to produce.

Outro

So that is about it. If you want to see it in action you can sign up for a free trial at https://my.pagebuild.net/signup/demo or take a look at some of the live sites built with Pagebuild:

• Intrinsic Interiors
• Learn Microsoft Excel
• Barbara Mordini

We are really interested to hear what people think about it so please leave us a comment and we will reply. We are constantly developing the product (we roll a new release weekly) and so genuine feedback is really helpful and may even end up becoming part of the product.