Kill the PageType

The web is dynamic in nature and there are many reasons the idea of a PageType does not scale for what’s on the horizon in web development.

I come from a background in search engines and when I first entered web development I found it surprisingly static and page-centric. Compared to what I had previously done, it seemed like a step backwards into an analog world. Web pages were nicely drawn out in Photoshop and printed on paper before handed to us developers for implementation. I found the capturing of dynamic web data on a static piece of paper ridiculous at first, but over the years I sort of got used to the idea.

How it fails today

The problem with this kind of thinking is how flexibility and optional components tend to multiply, and one ends up with vast versions for things that are almost identical. Only not quite so. In code, and for the editors, this problem manifests in one (or both) of two ways:

  • A myriad of almost identical page types, each with a specific usage in mind. You have ArticleWithoutSidebar, ArticleWithGallery, ArticleWithoutTeaserArea, and so on. When this way of solving the problem is applied to all your page types, they are multiplied, and the editors (and developers!) have a hard time dealing with keeping changes consistent, finding the right template to use in each situation, finding and fixing bugs, and so on.
  • Just a few page types, but each page type contains a lot of properties that are hardly used, and a lot of logic that if so-and-so is set, and also this-and-that is present, then show something to the user, and else show something different. The code soon gets unnecessarily complex, developers lose track of what goes on, editors grumble about how difficult it is to use, and it’s all a big mess. To the point where multiple page types would have been a better option.

Error by design

In complex sites, I have witnessed how some of the many variants in pages types are actually coming from errors in the design – the designer has made an update to an element, but forgot to let the change propagate to all instances of the element, thus ending up with two versions of the same thing. The sketches have then been approved by the customer, and the developer is bound to make two different versions of this element, simply because of a glitch in the design process. When this happens several times in the same project, it’s easy to understand how these little variants make the page types multiply.

Usage vs. intent

Another problem is that the concept of page types is not as obvious to editors as developers. I have no count for the many times editors have asked me why they cannot get a certain piece of information on a particular page, and I have had to explain to them that that kind of information is only available on the Section page type, while the page they are working on is of the Article page type, and that the two are very different and not to be confused with each other. This happens especially often with editors new to EPiServer. While one can argue that nothing is truly natural or intuitive, I find that EPiServer is moving in the direction of making the user experience easier for editors, and much closer to how most editors are already thinking about their content.

Designing for Blocks and Content Areas

With blocks and content areas, one could in principle create a whole site with only a couple of page types (only separated in layout), and then let editors place the content on the pages as blocks. Designers, however, tend to freak out when presented with this idea, because they have to give up all control in how the UI will manifest itself to the user. The designers will be the first to complain that this kind of flexibility in the hands of the editors is almost a guarantee for failure, as the editors often lack the understanding of what kinds of blocks that will work and look good together. I see their point, and to some extent I agree.

There are two ways to make sure that the site will still look and work great when it is extensively based on blocks:

  • It has to be designed that way! Right from the start, from the very first sketches, the idea of a block structure must be present in the minds of the designers. The building blocks that are used to create the site must work somewhat like Lego blocks, fitting perfectly together in multiple ways.
  • Solid guidelines for the editors! If blocks are named, stored and sorted in an easy to understand manner, and there are guidelines of what kinds of blocks to use in the various situations, the editors will be able to get it right most of the time.

Some constraints are good

Not using blocks, locking down everything, and giving the editors very little freedom, is something done out of fear that the editors don’t know what they’re doing. I think they do, I even think they are struggling to make the site as beautiful and functional as they possibly can. However, some locking down of options are done to make things easier for the editor. When EPiServer 7 launched, I was surprised to see that there is no locking mechanism in place for the content areas. What I’d like to see, and what I hope EPiServer will implement soon, is a way to specify what block types that can live in a particular content area, i.e. that the sidebar area only contains sidebar-type content.

Of course blocks can have multiple views, and thus be suitable for various content areas. But in my opinion, it would be good to be able to restrict the options to help the editors use the site effectively.

Modular thinking

Thinking in modules instead of pages have advantages in many of the phases concerning web site creation. From a UX or design perspective, a certain type of functionality should only be described once, and be reused around the site, making the design of the components less work than drawing them again and again in all the places. Especially when making updates or changes to a component, thinking in modules will dramatically reduce the required time and effort necessary.

  • From a backend developer’s perspective (my perspective), the site is required to be broken up into components anyway, but if this modular thinking has been prevalent also in the design process, there will be a closer relation between the design sketches and the final code, making changes, updates and bug fixing much easier.
  • From a frontend-developers’s perspective, making a site responsive is much easier if it is broken down into smaller modules. The various components should possibly be rendered regardless of screen size, but their individual placement on the page may change depending on what device is used for rendering.
  • From a tester’s perspective, a modular approach to web site design makes everything much easier. When module or component has been tested thoroughly, we can trust that it behaves as it should in most situations.
  • For both frontend and backend developers, a modular approach to web site design also increases the possibility of code re-use. When a contact person block or image gallery block has been created, why not reuse it on other sites? Only the styling of the block needs to change, the functionality will often be the same regardless of what site it exists on.

The PageType does not scale for the future

Even for layout, which seems to be the most important reason for splitting a site into page types, there are limitations, especially when thinking about responsive design. Sites are already created in ways so that they adapt to several screen sizes (typically grouped into desktop, tablet and mobile) and resolutions (in the continuum between retina and non-retina). I’m sure we’re soon entering a world were we cannot – and will not – care about the screen size of the rendering device, there will simply be too many options and variants.

Allowing for blocks instead of page types is a step in the right direction, but I believe this is only the beginning of a much bigger mind-shift in the way we will be – and should be – thinking about designing and building for the web.