Pagebuild Homepage

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.

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 sites. This software 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 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.

Why Drupal was chosen: 

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.

Describe the project (goals, requirements and outcome): 

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.

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. We used jQuery, jQuery UI, and a series of jQuery plugins.

FRONT-END

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 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.

Themes
We provide a number of free themes for customers to choose from. All Pagebuild themes are Zen sub-themes. On top of being a great base for our themes, Zen enabled our JavaScript to work, as we required 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.

BACK-END

Whereas Pagebuild's front-end largely consists of JavaScript backed up by Drupal modules, the back-end uses 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 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.

Domain settings
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.

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, 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.

Custom themes
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.

Subscriptions
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.

Challenges

Internet Explorer
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.

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. 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.

Outcome
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:

Intrinsic Interiors
Learn Microsoft Excel
Barbara Mordini

Modules/Themes/Distributions
Key modules/theme/distribution used: 
Why these modules/theme/distribution were chosen: 

We used jQuery and jQuery UI to create a simple, customized WYSIWYG editor. Using Zen sub-themes allowed our JavaScript to work uniformly across themes. The Token module simplified Pagebuild's theme-building process by replacing Pagebuild theme tags with Zen markup to make sure the theme works with the Pagebuild editor. We used the Ajax Controller module to handle all Ajax requests that are made while editing a page.

Community contributions: 

We took over maintenance of the Ajax controller module on drupal.org: http://drupal.org/project/ac/

Team members: 
Project team: 

Spoon Media
Susie Johnston

Pagebuild Content Area
Pagebuild Image Dragging
Pagebuild New Site Building
Pagebuild Theme Editor

Comments

Congratulations! Your project looks really well done.
We debated to start a similar project, and we came really close to doing so, now we are glad that we changed our minds to focus on more traditional web hosting for basic sites!
Congratulations once again, your project looks very well done.

You guys are quite genius. Very well put together, however, I am a novice designer with a focus on solutions for small to mid-size business with modest budgets. The more I grow as a developer, the less my work becomes "ordinary". How about saving some of the market share for the little guy trying to make a living. If these "point and click" Drupal "pretty picture" sites continue, I'll have to put more time into my own bright ideas and less on dev.

too many projects not enough time

While this website looks good and impressive, I think there will always be some space for us, little freelance developers.

In my point of view there are people with limited web knowledge willing to do all themself, reading doc, understanding how it works, and these solutions are great for them. Still there are a lot more who don't want to understand, they just want to use a tool and that's where we make the difference by taking care of most parts and carrying them exactly to what they want to do themself (login > click on that link here > modify your content > save > you're done !)

The human relationship between your customer and yourself is what make the difference !

Thank you Krem. I appreciate the motivation. indeed you are right.

too many projects not enough time

Of course, it is better for all of us that a service like this that based on Drupal, and thus potentially contributing back to the tool we're also using, than say an entirely proprietary technology.

Good point Babbage.

too many projects not enough time

This site looks nice and clean. I just want to know how many users does this website has? And how much is the estimated price for launching such website and service like pagebuild.net? Including all customizations.
And when a user pay $30 per month for hosting his website, is there any limitation for maximum number for visitors according to the bandwidth or CPU usage of it?

Doubt is the father of invention..... Hubmesh | download converter