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
- Does my Application fit in Drupal WebCMS?
- Standalone Template for Applications
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.
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.
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:
|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.
- 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.
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
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:
- 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.
- 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.)
- Link to your dynamic pages from this web area. You can build forms in Drupal WebCMS to allow people to search your application.
- Wrap your application result/dynamic pages in the standalone template.
- Want your application pages to look like a microsite (with sidebar navigation and breadcrumbs) or resource directory (with hublinks)? Then you need to ensure you have the correct class on the body opening tag, as well as the code for sidebar, breadcrumbs. You can view the source of existing pages in the Drupal WebCMS to see how they're laid out: Lead (a microsite) home page and basic page; CFLs (a resource directory) home page and basic page.
- You must also follow the basic One EPA Web Guidelines: Best practices must always be used, so even if there isn’t a sidebar, there always needs to be clear navigation. Content must always be written for the web. Tabs should not wrap on to a second line. Link standards are the same.
Keeping up with Changes to the Standalone Template: Email List
Send an email to firstname.lastname@example.org 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.
It's important that you're on this list. Periodic changes to the HTML will occur, and if you've saved local versions of the included files, you'll want to update those, as well.
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 (download this HTML file—it's all you need)
- 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 email@example.com with a justification of how existing styles do not support the application's requirements.
- Examples of what is standard and cannot be changed:
- Exit EPA Disclaimer
- New! Icon
- PDF disclaimers
- Form and form elements
- 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.
- Examples of what is standard and cannot be changed:
You will find the following files as part of the standalone template:
- If you're using APEX, there are a variety of assets included in the
Contact Web CMS Support (firstname.lastname@example.org). We're happy to help.