Bespoke Functionality and CMS Extensions

The InForm engine is great at managing content. You can use it to simulate complex data structures by being consistent on how you mark up your information from page to page. However there is always a case for having a custom database structure that actually models the real-world data that your site is about. In this case you may want a Bespoke CMS Engine.

A bespoke CMS adds in custom page types that represent different classes of data. Theses custom page types understand both information about the class of data, and the relationships that it may have to other classes of data. Once we have modeled this information then it is possible to automate the generation of pages utilising this information.

For example, the Granta website has dedicated page types for Issues, Stories, Authors etc etc. This therefore lets us generate lists of all the contributors and a bibliography for an author leading to one of their articles in a given issue. It would be possible to create a site with quite a lot of this functionality in InForm, but it would be cumbersome and implementing functionality such as an advanced search that utilised these models would not be possible.

Bespoke as an extension of InForm

If we are building a bespoke CMS then it doesn't mean that we have to give up all of the freedom of InForm. If it is appropriate for the project, then we can configure the CMS so that every custom page can contain the full range of InForm pages, e.g. an Author page could contain a series of content pages about the author, a news feed of press relating to them or an events listing of when they are going to be doing book signings.

Each custom page will also generally have general purpose documents as well as the database meta-data on. You can therefore utilise all the markup styles that are possible with an InForm site across the whole of Bespoke CMS deployment.

Development and Cost

Bespoke CMS sites are always more expensive to construct than an InForm site. Initially we will have to model the data that people want the system to maintain and the constraints and restrictions on how this data can interact.

Once we think that we understand what the client is after then depending on the complexity of the project we will do one or more of the following:

Paper Functional Specifications

I am not a huge fan of paper specifications as I find that they can easily get out of hand in terms of scale, and it can be hard to read a large technical document (functional specifications of >100 pages have been seen in the past!) and keep a model of the site that is being described in your head.

However sometimes a clear functional specification is a requirement, especially in fixed price jobs so sometimes this is the only course of action...

Wiki Mockup utilises redmine for project management and this includes a wiki for each project. This can prove very valuable as a lightweight way of documenting and providing rough mockups of what is required for a bespoke project.

InForm Mockup

As mentioned above, it is possible to manually create a version of a bespoke site inside InForm. It can get cumbersome as the data set gets larger, but for rapidly mocking up how people expect a bespoke site to work with a few examples of each page type it can be a very rapid and useful way of mocking up, and therefore documenting, how a bespoke site is going to work.

We particularly like the fact that once a client has learnt how to use the InForm CMS (which they are going to have to do at some point) then they can assist in the design process by creating a mockup of what they expect the system to be able to do. This minimises the assumptions that the above methods make - ie we assume that when we say "X" that the client sees a big "X" in their perception of the site, but this is not a given and sometimes you build something and turn out that both parties had something completely different in mind which leads to problems. The closer the functional mockup / design is to the finished object, the more likely that both parties are thinking along the same lines which minimises the chances of unpleasant surprises down the line.

Functional Build

At some point we will build some custom code and supporting SQL database structures to implement the bespoke CMS. At this point we don't worry too much about the visual presentation of the functionality, more just to get it to the point where people can sign off that it is doing what everyone wants it to do. Once this is complete and signed off then we can make a second sweep through the code and bring it into line with the look and feel of the site design.

For all but the most trivial systems, one would have expected to have performed at least one of the above scoping and documentation phases, and one would hope that the functional implementation that is delivered is what people expect. However client's perception of their requirements can change during the lifespan of a project and there can also be misunderstandings as to what people mean on both sides leading to us building something that isn't what is required.

It is therefore frequently beneficial to split the build up into smaller elements and take stock at each stage as to whether or not it is on track with everyone's perception as to the deliverables for the project leading to a more Agile development process...

And cost?

Once you think through the possible implications of the various steps outlined above, it becomes clear that the only way to provide a fixed price cost for a project is by mapping it out accurately enough that the level of work and therefore the cost is predictable.

Unfortunately, there are multiple points where this may potentially break down and therefore to protect against working for free, one has to build in a large degree of contingency into any fixed priced quote which can be a disadvantage to the client if everything goes smoothly.

We therefore prefer to work on an hourly rate, and if fixed prices are required then to do a fixed price per iteration where an iteration is 3 - 4 days work and therefore predictable to a fair degree of accuracy. We are happy to endeavour to work inside fixed price budgets by vetoing functionality that is suggested during the development process that is not feasible within the target budget, but we have found that client's expectations and requirements change and evolve hugely during the development process and therefore quoting for a job at the beginning frequently proves inaccurate and leads to conflicts during the development process.