Creating a website involves the coordination of different technological and design systems. This primer is aimed at demonstrating the steps and what is involved with developing websites using content management systems.

Technological Systems

Technology development begins with building blocks of systems that must integrate with one another in order to be successful. These building blocks exist discreetly, and some of those discreet systems have additional 'modules' (units of functionality) that cannot stand alone, and that build onto the skeleton of the larger system that they provide specific functions for.

There are five types of development work associated with the building of these systems to suit the needs a project.

Initial Installation of the Technology Units

The initial installation of the technology is the first step, and involves getting the basic systems of technology onto the server itself. The hosting servers (hardware) and associated registration of the Domain Name Server are typically not included in most technology estimates, unless stated. In addition, the purchase of Security certificates, where necessary, is not included in typical estimates.

Configuration

Once the base installation of the main systems of technology are up and running, the configuration phase takes place. This involves a combination of using the 'backend' user interface to modify and manipulate different functions and configurations that will be specific to each sub-project, and which will require the intelligence and involvement of the larger project team. Because this stage is iterative, the intelligence of the technology that mirrors the intelligence of the system will grow and change as our understanding of the specific needs of the project evolves. This evolutionary understanding is typically activated in iterative chunks to make the scope of the project manageable.

Customization

In the implementing of the solutions mentioned above, there will be instances where the needs of the project will require changes to the codebase of the software itself, or the creation of additional modules that will interact with the existing technology to produce the results that are desired. This development typically requires an expanded project team of developers. The cost of this development is included in estimates for the project, but sometimes might need to shift depending on how well the project stays within it's initial scope.

Updating

Because technology as a field is a moving target and continuously improving, and also because of the degree to which this movement is fueled by hackers who are always finding new ways to break into this technology, software updates will be needed for the duration of the life-cycle of this technology implementation. That said, there are parameters within which these updates are made. The initial implementation of the core systems will exist within a 'version' for this system. For example, many websites being developed now are powered by drupal version 6. One website might start out using drupal version 6.3 (the '3' being a sequential release or update of the version). Over time, as security and other improvements are made to the version, those upgrades will become available for implementation. While the website might have begun development using drupal version 6.3, it might have been upgraded iteratively to version 6.7 by the time it launches. Upgrades of releases within versions are relatively straight forward. Moving between versions is considerably more involved (and happens much less frequently) than the upgrades that occur within the versions themselves.

There are a number of hosts that will upgrade the 'core' versions of drupal as they are released, and others that will require the upgrades to be driven by their clients. This is also something that you should keep in mind when thinking about how this will be done for your organization, as it has implications on the types of staff you will need later to maintain your site.

A maintenance contract typically exists separately from the core proposal/contract and will outline an understanding of the maintenance involved both with respect to continued regular maintenance, and also with respect to adding additional units of functionality.

Design Systems

The design interface of the technology can also be broken down categorically.

Core design assets

The core design assets of a project consist of a core identity, brand or logo, and internal design conventions. Typically, these have been created and are in place before the technology is contracted, and are not usually covered in the scope of technology proposals – unless specified.

Design assets include but might not be limited to images and photographs, logos, font styles and types, and other design conventions that come together to form a brand.

Looks Like / Feels Like

Once the core design assets are in place, they will need to be developed into a looks like / feels like visual format that will specify how the core design conventions will come into play within the architecture of a page. There are some ways that traditional graphic design can translate into a website. Without knowledge of the way that the 'wire frames', other block elements, and web conventions operate, a typical graphic designer will create a comp that is not implementable, or whose implementation costs would be much higher. When designers are contracted, they should know and understand web technology specifically.

Implementation

Once the looks like / feels like comp has been created, the visual design is translated into a combination of CSS and PHP template files, and associated images towards the development of a unified theme. This 'theme' enables web pages to hold the integrity of the brand in tact, and also prevents the developers from having to duplicate work, as a collection of different themes are implemented once. The internal code translates these base files into consistent web pages regardless of what specific content, lists, or forms are being displayed.

Training Systems

As mentioned above, you should be able to expect training materials for different stages of the project and aimed at different categories of users on the site. These training materials can exist on the site itself when appropriate, and as a document as well. They instruct different categories of users in managing and participating in different ways on the site. In addition, face to face trainings should be included in estimates. The goal in creating websites is to create a system that is user friendly enough that anyone with the ability to purchase books on amazon.com or work in a typical word-processing environment will be able to create content and make changes to the site. The litmus test of that usability is the extent to which confusion arises in testing and training. When this happens, your developer should include it as the basis of the next iterations of development.

Content

Any non-design related content is typically not included in the scope of estimates for building websites using Content Management Systems, although the coordination of creating that content mgiht be managed according to the project deadlines. This is namely because the majority of that content will need to be developed by other workgroups in the project, and because of the embedded training opportunities presented by the core stakeholders manipulating and adding content themselves.

The goal is to create a user-base that is not dependent on a technologist. Where ever possible, decisions should be made throughout the project that will favor the training of the user base as opposed to creating dependence to outside technologists.

If there is a need to import content into these systems (contact information for a base set of users, for example), and that import (data conversion) is straight-forward, it can sometimes be slipped into the project, but typically this will cost extra. If there is a need for a more involved data conversion, this will typically need to be estimated at the time that the need surfaces, and depending on it's complexity.