The Department of Energy's Mobile First Strategy

Brad Wade
#Mobile | Posted

Last week the U.S Federal Department of Energy(DOE) announced the launch of their new responsive site. We are really excited about the release and what it means for the DOE, to be one of the first federal agencies to launch a responsive web platform. Earlier this year, Joshua Turton wrote a blog post explaining how we went about designing an out-of-the-box mobile solution for their web platform. Now that we have launched the responsive site, I would like to build off of Joshua's blog post and explain some interesting challenges and our strategies to solve them in order to create this mobile-first solution.

image of Energy.gov on different devices

The DOE's web platform is a large and complex site. In addition to the main site, it houses numerous sub sites, many content types with intricate internal layouts, and a primary menu with hundreds of menu items, up to five tiers deep. As Joshua explains in his blogpost, we needed to take this fixed-width grid based website and make it fully responsive and mobile friendly. We called it a "retrofit" because the goal was to keep the styling, desktop layouts, and general aesthetic from the original site, but make it respond to changes in viewport size. Before we undertook this venture, I wanted to make sure we had the right tools for the job.
Goodbye Less, Hello Sass

The previous DOE website theme utilized LESS, the dynamic stylesheet language. While so much better than just using CSS without any preprocessing, I was hoping to leverage Sass's Compass authoring framework and more importantly, some of the advanced tools that Compass enables (such as breakpoint and singularity grid system, but more on those later). It wasn't a decision made lightly, because the conversion process would take some time and effort, and it might introduce the risk of regression into the project. Any second guessing was quickly put to rest once we started the manual conversion process. Simple find and replace searches to alter the syntax got us 95% of the way there. We ran into a few "gotcha"s. For example, apparently LESS allows the nesting of pseudo classes like this:

  1. a {
  2. :hover {
  3. color: red;
  4. }
  5. }

Whereas Sass, requires the use of the ampersand to reference the parent selector. So we had to do a search for all possible pseudo classes and add the ampersand.

  1. a {
  2. &:hover {
  3. color: red
  4. }
  5. }

After the conversion, we were setup to take advantage of some great tools... tools we would need.

Complex Layouts

So to begin with, the DOE has some pretty standard layout sections: header, navigation, optional sidebar left, main content, optional sidebar right, and footer. However, on top of that, the content inside main section has its own complex layout. many different content types each with optional sections of their own that may include elements such as rotators, blocks, nodes, maps, image galleries, and more... all laid out in multiple rows or columns or both. How would those inner layouts be affected when there are differing amounts of sidebars in the outer layout? Would we have to reassign different grid widths to inner elements for each outer layout configuration for each breakpoint? Oh my!

Fortunately there was an alternative: Nested Layouts via Singularity. With this approach we could create one layout for the main/outer layout sections and a second, independent, nested layout for the inner layouts.

Singularity

Singularity is a semantic, ratio based grid system, similar in function to Susy or Zen Grids. It allows us to have a fluid, ratio based, grid (even an asymmetrical grid if you need it). Since it is implemented by referencing mixins when defining your SCSS on your various elements, you can strip out all of those non-semantic classes from your markup such as grid-9, col-3, pull-5, push-2, alpha, omega, container, etc. Fixed grid width classes on elements are pretty meaningless as those sections shrink, grow, and move around as the viewport gets larger and smaller. (And while we are at it, get rid of all of those clearfix classes, please! Just use a clearfix mixin whenever necessary.)

  1. /* Grid system and general page layout */
  2.  
  3. /* Define Singularity grid variable */
  4. $grids: 12;
  5.  
  6. /* Fraction of column width for gutter width */
  7. $gutters: 20/65;
  8.  
  9. #main-content {
  10. .sidebar-second & {
  11. @include grid-span(9,1);
  12. }
  13. }
  14.  
  15. #sidebar-right {
  16. @include grid-span(3,10);
  17. }

Now we can utilize Singularity's layout() mixin to create a nested layout.

  1. #main-content {
  2. @include layout(9) {
  3. .this-thing {
  4. @include grid-span(3,1);
  5. }
  6. .that-thing {
  7. @include grid-span(6,4);
  8. }
  9. }
  10. }

Another nice feature of singularity is that you can choose to use either the grid-span (i.e. John Albin Wilkins' isolation output method) or float-span (more traditional floated spans, with push, pull, alpha and omega concepts) methods of output. We found situations where each solution was appropriate to use, so used both.

Breakpoint

Singularity itself doesn't have a method to help with managing media queries, but works great in conjunction with the Breakpoint Compass extension. Breakpoint makes writing and managing media queries easier. It enabled us to keep all of our CSS styling for given elements/sections in one place, rather than having separate sections for each media query.

Introducing Expandpoints For Mobile First

We defined all of our breakpoints as variables to be used throughout our SCSS. While we had a few "breakpoints" which defined where major layout shifts occurred (such as the desktop navigation switching to the mobile navigation), we had many more tweakpoints that we defined. We started with a small browser window, and expanded until the layout of the DOE's actual content "broke", and we would create a new tweakpoint and alter the layout as necessary. I also introduced a new term: "expandpoint." The term "breakpoint," to me, implies the point at which content would begin to wrap as the viewport shrinks (desktop first). Since we were approaching this from a mobile first perspective, calling the variables "expandpoints" helps me get my head wrapped around the purpose each media query. $expandpoint-multicolumn would be the point at which the viewport is wide enough for the sidebars to move from a single column to be on either side of the main content.

  1. $expandpoint-full:901px;
  2.  
  3. #main-content {
  4. // Defaults to full width - all 12 columns
  5. .sidebar-second & {
  6. @include breakpoint($expandpoint-full) {
  7. @include grid-span(9,1);
  8. }
  9. }
  10. }
  11.  
  12. #sidebar-right {
  13. // Defaults to full width - all 12 columns
  14. @include breakpoint($expandpoint-full) {
  15. @include grid-span(3,10);
  16. }
  17. }

Complex Mobile Navigation

The Department of Energy has some significant navigation requirements that presented us with a series of challenges.

Challenge 1: Two header menus.

The previous iteration had two different header menus: the main menu and a secondary menu. In a mobile world we don't have room to display one menu, let alone two.

Challenge 2: Deep navigation.

The desktop navigation provides two tiers of navigation. Then deeper pages of the site display a sidebar block that contains more layers of site navigation. All of that needed to go away for mobile and be replaced with the three line hamburger. But how would the mobile navigation work? Should we display the entire menu structure as collapsed accordions? Should we just keep expanding down as deep and as much as necessary? We decided against this, as we thought the menu display would quickly become unwieldy as the list got longer and longer.

Challenge 3: Dual purpose links.

Some menu items were links to pages of themselves (often landing pages for that section) AND at the same time, the parent item of sub-navigation. When you touched that item (no hovering in mobile) would it reveal sub-navigation or go to that page? Could we divide the button in half? A down triangle arrow next to the text could reveal the sub-navigation, while the words themselves would link to the page? We decided against this as we didn't think the functionality would be immediately obvious to the end user.

Solutions:

  1. First we combined the two menus into one. While conceptually simple, implementation was a bit more complex. Since each office sub-site had unique menus that also had to be combined, our devs set to work figuring out a process and writing some scripts where menus could be exported, processed, and then re-imported in the new, proper structure.
  2. Next, we loaded the entire primary navigation menu tree structure (regardless if "expanded" was checked or not in the menu administration), so that the entire depth of menu would be available in the DOM for manipulation with CSS and JavaScript. While loading the menu, we processed the menu in PHP. Parent items with sub-navigation were duplicated and placed as the first item in the sub-navigation and we appended the word "home" along with appropriate classes.
  3. Now that we had the markup we needed, we set to work with layout and Javascript. To make the navigation work, we placed each each nested depth/tier of ULs as a block, side by side one another at 100% width, the next deeper level ULs hidden and to the right. If a menu item with sub-navigation is clicked, we load appropriate menu from next tier by displaying it and shifting everything to the left via CSS transitions.
  4. Using JavaScript, we duplicated the parent item text as a heading for each sub-navigation list page and created a back button that allows the user to traverse back up the structure.

In the end we have a flexible solution that enables the user to quickly navigate through five tiers of hundreds of menu items. I find it really nice to use, but I might be biased. Try it out and let me know what you think.

DOE-Mobile-Navigation

Bonus Challenge: Desktop Navigation too?!??

Now that we conquered the mobile navigation... the desktop navigation still had to work more or less the same way as it did before. Not only did the menu styling need to change based on the viewport... we had to implement different javascript.

Enquire.js

Enquire.js is a lightweight, pure JavaScript library for responding to CSS media queries. When you register Enquire.js you provide it with a media query, then you can write JavaScript that executes when that media query is matched and when it is unmatched. So as the viewport shrinks, we are able to bind various behaviors to navigation elements.  After we leave that viewport, we need to clean up after ourselves and unbind them because another enquire media query is met and different JavaScript functionality is bound to those same elements.

Responsive Images

The on-going challenge in responsive web design, is how do we provide lower resolution and smaller file sizes to smaller devices? And vice versa?

Borealis

Borealis

 is a Drupal module that switches in an appropriately sized image (via javascript) given the available width for that image. It is totally independent of the current viewport width, measuring a parent container of the image to determine the size to provide. This also makes the administration of the module quite simple, simply select any image style setting that you want to take advantage of Borealis image swapping.

While this approach to responsive images is the best approach and philosophy that I've seen so far, we did run into a few problems that we had to hack/patch our way through. Borealis doesn't get triggered when images are brought into the DOM via ajax. So if you have a separate photo gallery that loads images, Borealis won't work on the new images. To further the problem, the module currently isn't playing nice with Drupal as all functions are private, so you can't even manually call Borealis internal functions without hacking/patching Borealis.

So these were some highlights of the challenges we faced and the solutions we came up with to make Energy.gov one of the first cabinet-level federal departments to launch a responsive website platform. It was a pleasure working with the Energy.Gov team and we look forward to working with The Department of Energy to continue to push innovation in government websites.  Read more about The Department Of Energy's Web Platform here!

Brad Wade