Designing for GovCMS

A typical GovCMS project, as with any other website project, should involve a number of “design” aspects coming together to produce a finished product. These will include information architecture and graphic design amongst other things. In the case of GovCMS these aspects should be undertaken with a solid knowledge of the target platform GovCMS. This article is for designers, including UX designers and information architects, who are wondering how to start conceptualising working with GovCMS.

The rubber hits the road where the design is implemented. For GovCMS this happens when the site is being built and theme implemented. Drupal site builders and themers must translate the designs to a working site using the tools they have available. During the build it is vitally important that the codebase is able to support the design. The codebase for GovCMS is locked down, meaning that it is not possible to add new modules or custom code to a website. All we have to work with is the codebase and the functionality it provides. We must work with the features we have available and know that we will be constrained by code which we cannot add. A successful design phase will be conducted with knowledge of where these boundaries lie.

Thankfully, we are able to implement a custom theme to bring the graphic design and other components to life. The theme is the one area where implementors are able to exert the most influence. There is a lot that can be achieved, with a lot of flexibility being available at the theme level. However, the theme must mediate between the patterns of Drupal of the site and the design. A successful site will have the structure and graphic design working in harmony so that the theme is able to be implemented cleanly and simply.

This article will take a look at these various “design” aspects and how they relate to the structure and patterns within GovCMS. As such, the article hopes to inform parties who may be developing these components, including design and digital agencies who have had limited experience with Drupal. Government agencies may also find it helpful as it provides some helpful tips for how to think about GovCMS builds.

Some standard Drupal patterns

Drupal sites are comprised of a fairly standard and well known set of elements. Understanding how these all work is part of climbing the Drupal learning curve. 

GovCMS makes use of these standard elements which include: 

• nodes, 
• users, 
• terms, 
• fields, 
• menus, 
• views, 
• blocks, 
• regions,
• roles,
• permissions,
• view modes,
• image styles
• rules
• and a variety of other more esoterically named things such as beans. 

These components are the building blocks of a Drupal site and every page you view in Drupal can be decomposed into these components. Informations architects, content strategists and designers should take some time to understand these basic components to best understand how they can design for Drupal sites.

Guidance for information architects and designers

Information Architecture

Information architecture is about organizing and labelling websites. GovCMS has things covered for Information Architects providing a broad range of tools allowing them to do their job in a very comprehensive way. Some of the highlights include:

• a comprehensive range of field types for defining properties
• the ability to create new content types to model classes of things
• a robust taxonomy system suitable for classifying content in various ways
• entity references for relating objects
• a main menu which forms the main tree of objects defining the site
• other menus for more specific tasks
• user roles for handling permissions.

Basically the tools are there for information architects to do their job.

Successful sites tend to have the following characteristics

• a vocabulary targeted to persona to help with delivering content to users
• consistent use of vocabularies such as tags and content across all content types to aid retrieval across the whole corpus
• sensible use of properties to avoid an explosion of content types
• a main menu with a sensible and understandable tree of objects which can guide the users
• adequate cross linking through classification and reference to help users navigate horizontally within the site.

Graphic design

A Drupal page is comprised of components. Components work together to form a region, a page, a section or the entire site. Designers should be aware of the various components in play and their scope. The best designs target components, rather than pages. This ensures that designs are consistent and easily maintained.

Example of typical components, ranging from the widest to the narrowest, are as follows:

1. Base: h1, p, ul, li, table
2. Site: header, footer
3. Page: main, sidebar
4. Widget: block, paragraph, form
5. View modes: teaser, tile
6. Atoms: field, image style

The components available on a site will generally emerge as wireframes from the results of the discovery phase and the information architecture. When designers are converting these designs to graphics, it should be remembered that the components should act in a consistent way. Design for components, don’t design for pages.

These kinds of ideas are reflected in the SMACSS approach to designing CSS. 

Style guide Driven Development

Style guide driven development is a theming technique which makes use of components by stubbing out simple versions of them in HTML and then styling them up with the actual CSS which will be used on the site. The resulting artifact is a set of static HTML pages which succinctly capture the essential features of the component and the CSS required to achieve the look.

Morpht has added a style guide to the Govt Demo GovCMS website demonstrating a style guide working together with the various components.

Nailing a design is all about nailing the components and the style guide is a way of validating that before the Drupal site is even completed.

Working this way may be a new approach for design firms who are used to having graphic designers set the standard to which developers and themers must attain. This new approach encourages all parties to be on the same page and to be in agreeance on the components to be developed before they are designed. This really does bring Information Architects and designers onto the same page. Even better if a GovCMS expert is there to also guide the design process to ensure that the resulting designs are achievable within the confines of GovCMS.

Conclusion

GovCMS is a system which is based on a fixed codebase. However, there is a lot which can be done with the carefully selected set of contributed modules which act as the building blocks for the site. Information Architects and Designers should not be overly constrained when it comes to designing. The toolset allows a create deal of freedom in data structures, layouts and design possibilities.

It is important to remember that in order to get the most from Drupal it is important to understand the patterns which are in play and work with them. We recommend that both IAs and designers which work on GovCMS projects have an understanding of these patterns, or at least have access to a Drupal consultant who is able to guide them in the planning process.