Pagebuild allows non-technical users to build websites very quickly and easily. It was built using Drupal, with the idea behind it being to provide an editing interface that is so simple, even an adult could use it.
The back-end allows customers to sign up, create, and manage their websites. We use Aegir (Hostmaster) to provision and manage sites. 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, and we use a bunch of great Drupal modules for both systems.
Spoon Media has been building Drupal sites for the last six years. We generally do mid- to large-size projects. 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 provide small businesses with great websites at an inexpensive price, while still retaining a high standard of product.
Pagebuild was in development for about two years. We used an agile project-management method, developing new features in iterations as we went. A lot of the functionality was the result of building something and then discovering a usability issue that required us to rethink that particular feature. The iterative method allowed us the flexibility to chop and change things as required.
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 was 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. It wasn't possible to do this with an IFrame-based editor. After much back and forth, we settled on Twoism's reviser as the base for the WYSIWYG editor. I say base because we made extensive Pagebuild-specific changes to get it to work just so. The result was that we were able to provide a true WYSIWYG editing experience that is completely tailored to the Pagebuild Way.
One of the coolest features of Pagebuild's editor is 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 to drop an image in the middle of a sentence. Using the jQuery UI module'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. We leverage Drupal's regions and blocks to allow the user to create unique and flexible page layouts.
When editing a page, regions can be shown or hidden, and blocks can be added to regions. This all happens via Ajax. Creating/editing/deleting blocks happens on the page itself, to prevent interrupting the editing experience. As a bonus, existing blocks can be dragged from one region to another.
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.
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 automatically 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 within 5 seconds), they can log into 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 customers to log into their site without having to reenter their login details.
The custom Drupal install profile on the front-end communicates with the back-end database to set up themes, roles, filters, Pathauto and ImageCache settings, amongst other things.
Once customers have signed up, they can add new sites to their subscription with a simple single-page form.
When customers first sign 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, customers can use any domain of their choosing for their site. Again, Aegir makes this very simple. When customers submit 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 that the A record points to the correct IP address, we create a migrate task in Aegir, which renames the site.
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, users can alter every aspect of the design from their browsers. They can then save their theme with a new name, effectively forking it from the pre-built theme we provided. Both Drupal Gardens and the Sweaver module use this concept; however, both of those implementations allow so much freedom that they could confuse a non-technical user. We have made it harder to do silly things to your theme by restricting what HTML elements you can actually modify. While this limits the power of the theme editor, on the whole it results in a better theme when a novice uses the system.
While we provide free themes for customers to use on their sites, we also allow them to purchase a customized design. This is not automated, and involves the customer talking with a designer to get a result.
To greatly simplify the process of creating Pagebuild themes, 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.
Using the Token module, we then 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. A complete Zen sub-theme is automatically generated and copied into sites/all/themes, ready for use.
Permissions on individual theme nodes ensure the theme is available only to the customer who purchased it.
Custom themes are currently only available to designers with whom we have an existing relationship. In the future, we plan to open this feature up to more designers. We will eventually open the feature to customers themselves.
Initially, we tried using Ubercart, uc_recurring and various payment modules for the checkout and subscription payments. This added an unnecessary layer of complexity to the system: the Ubercart product wasn't meshing well with the existing Aegir and Pagebuild node 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 looked promising, but we needed to move quickly. Rolling our own system allowed us to do that. Another benefit of making our own payment system: it's tightly integrated with the rest of the Pagebuild system, letting us avoid having to work around the assumptions inherent in Ubercart, uc_recurring and the payment modules.
During 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.
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. For example, 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 GNU Debugger.
Despite the additional effort involved in rolling our own WYSIWYG editor, we are very happy with the experience we've managed to produce. To see Pagebuild in action, sign up for a free trial, or visit some of the live sites built with Pagebuild:
We took over maintenance of the Ajax controller module on drupal.org: http://drupal.org/project/ac/