Defining a Technical Architecture Part 2: Automation and Rapid Prototyping

In Part 1 of Defining a Technical Architecture, we talked about information architects using spreadsheets to construct content models that a site builder or developer can implement. But why have the information architect declare all those fields in a spreadsheet, only to have a developer repeat the exact same declarations in code? Let’s cut out that redundancy with automation.

Automation!

We’ve taken the spreadsheet that defines our fields and turned it into a declarative interface that generates the code defining content types, vocabularies, and fields.

You can learn more about the technical details of this automated process in my colleague Scott Reynen's post Automating Drupal Configuration.

This automation has proved extremely valuable for several reasons:

  • Cuts down on tedious work for the developer, allowing them to spend more time on the more complex and challenging aspects of the project
  • Allows us to share content creation forms early with the client, connecting the somewhat abstract spreadsheet to the structure of the content and how it will eventually be displayed.
  • Enables us to iterate quickly as content models shift. When the process is automated, we can get the client entering content early. This allows us to more effectively tailor content to the exact needs of authors (eg: effective help text, logical order of fields) without killing the project budget.
  • Provides version control for changes to the content structure, which helps us notice patterns in our workflow that can be improved.
  • Trains the client early on, de-mystifying the CMS and also getting real content into the site for us to work with.
  • Reduces human error, which is important when engaging in a process in which specifications evolve quickly. This simplifies the process of keeping planning document up to date and making sure the developer receives the latest round of feedback (and in an intelligible way). The content structure is defined in one place and the code generated (and re-generated) accordingly.

Prototypes

While the wireframes and Technical Architecture document help clients think of their content in smaller, structured components, it is still difficult to review fields and content types until one can dig in and enter real content.

Thanks to this automated process for defining content structures, we can quickly build out a prototype that allows clients to enter content. For example, when an instructor adds a course to the site, it helps everyone involved see exactly what content we are working with. Now the spreadsheet ceases to be abstract and the client is in a position to provide meaningful feedback on the Technical Architecture document.

Structured Content in Action

By finalizing the content structure in the prototype phase, front-end developers have stable and authentic content to work with. Taking the example of a course page from part 1, the client now sees their content with the design applied:

Because the content is structured into discrete elements, styles applied to specific components of a course are applied throughout the site. Here is an example of the courses page that lists multiple courses:

By combining wireframes, spreadsheets and rapid prototypes we are able to define well-structured content early on in the project. This ensures that content types are highly tailored to the client’s needs and minimizes the potential for miscommunication. Even when there are changes to content structures, they tend to be minimal because the modeling of content is rooted in working with real content with real forms.

Try It Out

All of the resources mentioned in this series are free for use and customize. Feel free to try them out and share your thoughts. If you have your own process or tool you use to make structured content tangible, share it in the comments. We are constantly working to improve our process and love seeing what others are doing.

Original Article: