Applications and the One EPA Web Template

One of the key themes of the One EPA Web is that all EPA web pages must share the same look and feel. Content managed in the Drupal WebCMS automatically inherits the One EPA Web look and feel with all of its attendant benefits. EPA web applications are separate from the Drupal WebCMS. As a result, it is the responsibility of the application owner to ensure that all public content pages and application result pages use the One EPA Web look and feel.

A key piece of application maintenance is keeping its look and feel up-to-date. Poorly maintained content, with an outdated look and feel, is not acceptable. All applications must include all elements of the most recent version of the One EPA Web look and feel: headers, footers, color scheme, mandated links, etc.

It is the responsibility of the application owner to match the One EPA Web look and feel for their application. This page helps you understand when to use the standalone One EPA template, how to use it, and how to maintain it.


What Drupal is and What it is Not

It is important to understand the capabilities of Drupal and the Drupal WebCMS prior to making a decision on what approach to take with your application.

Drupal is an extremely extensible open source Web content management system that is primarily designed to facilitate website management and user interaction with that site. It is not an application-hosting environment like Domino or Cold Fusion or Oracle.

The Drupal WebCMS is a single Drupal application that has been customized to meet EPA’s One EPA Web content management needs. It is not a platform onto which tens or scores of existing applications will be bolted. However, it is feasible and likely that the Agency will allow database queries (to your database) from within the Drupal WebCMS. The technical details of each instance will have to be determined on a case by case basis.

We are not telling you to move your application content into Drupal WebCMS, but there may be advantages to using Drupal, particularly for pages that explain or launch your application. The point bears repeating: Drupal WebCMS is never required; you can always keep running your sites in Domino/CF/whatever. But you pay for that, and it will increasingly get more expensive. Continue reading to figure out what to do with your application.

Top of Page


Does my Application "fit" in Drupal WebCMS?

Every application requires some analysis to determine its current functions and how it might fit with the Drupal WebCMS.

We distinguish technically between "data" and "content." Data (i.e., structure data) is information that is pulled from a database, on demand, through a query or other software command, to create tables, graphs, charts, maps, etc., and displayed in a specified format. "Content" is information (i.e., unstructured data) that is specific to specific web pages. Content can be text, tables, graphs, etc., too, but they are more static, only updated when a particular page is updated by the editor. "Documents" are even more static content that is shared on the EPA Internet, primarily in the form of PDFs.

So, if your application has a backend database that is queried and delivers structured data, charts, graphs, or maps on the fly, we consider it data. This data presentation may be through Drupal WebCMS (and JavaScript), or it may be through an application server (such as ofmpub, cfmpub, yosemite, etc.).

If your application has a backend database that delivers paragraphs of text, images, etc, that are rendered as web pages: that content should be moved into Drupal WebCMS (and the application decommissioned)—if the content is part of your organization's Web plan.

There are three primary types of application integration approaches that can be taken:

Approaches for your Application
Approach Description Good for Example
Assimilation Move the managed content into Drupal WebCMS and decommission the application Content management or document management / databases that delivers paragraphs of text, images, etc, that are rendered as web pages Bristol Bay (formerly content in Domino)
Integration Drupal WebCMS front end with application results presentation Database queries Air Data concentration plot (potentially)
Standalone Drupal “anchor page” with links to the stand-alone application, which uses the standalone One EPA Web template Application that has a backend database that is queried and delivers rows and columns of structured data, or charts or graphs The search engine, ECHO

Determining the Appropriate Application Integration Approach

  • Is the application a part of a topic that is included in your organization's web plan? You should not begin migration / integration work on an application that is not included in that plan.
  • What type of application is it? Categorize the application into one of these broad categories:
    • Content management: Does the application just manage web pages? Assimilation: Transform the content to One EPA Web and decommission the application.
    • Document management: Does the application just manage documents? Most likely assimilate, but depends on the number of documents and the nature of their metadata.
    • Database query: Are the results sets just rows and columns of information? Consider #2: host the query in Drupal WebCMS and pull in query results with JavaScript.
      • If the results are more complex, you'll probably put your application into the standalone template and host your static "context-setting pages" in Drupal WebCMS.
  • Another factor is the technology, and we offer these guidelines:
    • Domino: By and large, Domino managed content can/should be transformed into Drupal WebCMS-managed One EPA Web content. This is because most Domino applications are, at heart, content management solutions.
    • ColdFusion: depends on the application entirely. ColdFusion should be considered a "legacy” platform and no new applications should be developed in it. Use instead your own instance of Drupal, Java, or Oracle Apex.

Top of Page

Advantages of Assimilation or Integration

OEI believes it is extremely advantageous for application owners to consider moving your application, or at the very least, your "context-setting" pages into Drupal. The benefits include:

  • Required metadata is added and accessible.
  • The content is more easily indexed and searched. Having content in Drupal WebCMS reduces complexity for the EPA search team, thus assuring fewer problems.
  • Pages are more easily discoverable by other content owners and more easily integrated into related Resource Directories.
  • Pages are available for inclusion in dynamically-generated lists (that will eventually abound on www2).
  • Pages can adapt to any device the user is using--they are responsive. It is conceivable that the output from an application might not need much of the chrome/wrapper from the standalone template, depending on the output. By moving all the static pages into Drupal, the application owner then has a reduced burden for keeping look/feel aligned with the rest of the EPA web site.
  • Unless the application is by design a content-management application, updates to those context-setting pages can be done in Drupal without requiring application-developer effort and changes to the app itself. This benefit might be small, but accrue substantive changes over time. Federal staff could do this without engaging the developer at all

Top of Page


Standalone Template for Applications

We maintain a Standalone One EPA Web Template, based on the Drupal WebCMS theme. It is this template that you'll use for all data and content that is not in the Drupal WebCMS. It serves the same function that "Template 3" and "Template 4" did: you wrap this template around your application code, outputting the title, the content, and any other custom content your application outputs.

Additionally, we have done significant work to ensure that this standalone template works with Oracle APEX applications.

This One EPA Web Template is for applications on their own servers. We are *not* requiring organizations to move their data into the Drupal WebCMS—it's not always an appropriate fit. Although the "front" pages on an application—the home page and pages that explain the features of the application—need to reside in the Drupal WebCMS, your application will output its data into the standalone HTML template. For example, the Cleanups in my Community web area (to be published), managed in the Drupal WebCMS, has links to the Cleanups in my Community web application, which will be using this standalone template instead of the version 4 template it's using now.

How to Use the Standalone Template

If you have an application, test the standalone template on your staging server. In the standalone template, you'll also note links to a variety of assets on the www2 domain, like CSS, images, and JS files; please do not remove these. In this regard, this template is no different from Templates 3 and 4, which you may have used in the past.

This template is different, however, in that it is responsive, meaning the layout changes depending on the size of your screen. How that affects your application and the HTML it outputs is unknown and should be part of your testing. It's also different because the number of changes to the HTML will likely be more significant and frequent than the changes we've made to Templates 3 and 4.

A high-level overview of your process:

  1. Request that a new web area be set up in Drupal WebCMS. This web area will hold your "context-setting" pages: pages that explain what NCSEP (for example) is and how to use it, etc. If your application is really part of an existing web topic already in Drupal WebCMS, you can set up your applications context-setting pages within that web area.
  2. Build your context-setting pages in this web area (e.g., the home page, the About page, the Quick Tips page, About the Data page, etc.)
  3. Link to your dynamic pages from this web area. You can build forms in Drupal WebCMS to allow people to search your application.
  4. Wrap your application result/dynamic pages in the standalone template.

Top of Page

Keeping up with Changes to the Standalone Template: Email List

Send an email to web_cms_support@epa.gov requesting that you receive update notifications, and we will add to you an email list. If you're doing work with the standalone template for your application, you should be on this email list. We have a private repository at Github, with a read-only copy of the Drupal WebCMS code, but access is restricted to EPA staff and authorized contractors.

Top of Page

Rules and Exceptions for Using the One EPA Web Template

The One EPA Web Team will determine on a case-by-case basis how much leeway applications will have regarding styling. We recognize that applications may have different needs than our "static" content.

EPA online applications that present information via a web interface (e.g., to the screen) should:

  • Use the standalone One EPA Web template
  • Conform to Section 508 accessibility requirements. No exceptions.
    • These requirements are built into the standalone One EPA Web template and the look and feel standards. If an application diverges from EPA standards, it must still be accessible.
    • When using colors in an application:
      • Rely on the standard color palette. Do not create new variations of existing colors in the EPA palette. We tested these colors to ensure visibility for all.
  • Ensure your application outputs data responsively (e.g., do not use fixed widths).
  • Local styles can be used to improve presentation of application data if necessary. As local styles are not allowed on EPA.gov sites, they must be first approved. Submit requests for exceptions to web_cms_support@epa.gov with a justification of how existing styles do not support the application's requirements.
    • Examples of what is standard and cannot be changed:
      • Buttons
      • Boxes
      • Exit EPA Disclaimer
      • New! Icon
      • PDF disclaimers
      • Form and form elements
      • Lists
      • Tabs
      • Text and text color
    • Examples of what might be non-standard:
      • Tables: EPA standard tables might not work for all data presentation from applications.
      • Images: In the EPA standard template, images are constrained to a max-width of 100%, meaning they will never break out of its containing box. This directive might not work for application images.
      • Responsiveness: in order to present data in a format that is not fully responsive, i.e., a format where some or all data is not displayable on phones, tablets and other mobile devices, you must demonstrate that you have no mobile visitors at all.
      • Complex application layouts: Pages that provide complex presentations, such as for example a map, summary table, and detail table all on one page. Such pages must still maintain their responsive design and Section 508 compliance in all cases.

Top of Page

Included Files

You will find the following files as part of the standalone template:

  • jquery.js
  • js.js
  • s.css
  • standalone.html
  • If you're using APEX, there are a variety of assets included in the apex directory.

Top of Page


Questions?

Contact Web CMS Support (web_cms_support@epa.gov). We're happy to help.

Top of Page