Building an incredible front page in Drupal

For our initial launch, the front page was by far the most complex single page on the site. One of the key business needs however was that it be super simple to manage the content. We did this by creating the Front Page as its own content type, and using a variety of Drupal modules to make the sections very clear and easy to manage:

Mapping content type fields to front page sections

Some of the sections of that page are built with fields right in the content type, and others (like Sponsors and Speakers) are built by embedding Views into the node.

Some of the more interesting modules we used on the front page are:

field_group — to create the vertically tabbed interface you see there on the edit page

field_collection (and its brother field_collection_deploy) — to create “add more”-able groups of fields. This is really useful for carousels which may have several fields (background image, copy, call to action…) per slide, and an arbitrary number of slides per carousel.

Field groups + Field collections for ultimate content control

viewfield—to drop Views directly in the node with no special embedding code needed

Drop a view in your node with viewfield

views_bootstrap — to get Views using Bootstrap 3 classes.

Responsive design

Using Bootstrap 3 gave us a huge leg-up in implementing responsive design. Since our design team provided mockups, we were able to theme the front page fields with mobile in mind. Go ahead, open the site on your phone or tablet!

SVG stands for “Something Very Good”

Ok, it actually means Scalable Vector Graphics. On a high-dpi screen, non-photo graphic assets tend to look chunky and not-so-great, so we knew right away that we wanted to use SVGs for elements where it makes sense.

Wynn Las Vegas logo in SVG (left) and PNG (right) as displayed on a hi-dpi screen

We use a slightly customized version of SVGeezy on the site to detect browser support. The cool thing about SVGeezy is that it will automatically swap in your fallback images if the browser lacks SVG support, and we hacked SVGeezy to add a `no-svg` class to the body in that case. You can see what the site looks like on a non-SVG browser by adding `?nosvg` to any URL on the site like this: http://imagine2015.magento.com/?nosvg (that was our other hack).

The other way-cool thing we did was animate some portions of the header.

Trust me, this looks way better on the actual site.

Pretty much everyone agreed that the “fins” in the design needed to animate, because what looks cooler than that? But there were some major hurdles to getting this working correctly. Aside from just getting the elements animated in the first place, we had to worry about what it looked like on all kinds of devices on different platforms, what happens on mobile, and so forth. The simple answer would be to render a video, but there are a couple problems with that: 1) the fins actually overlap the following “Agenda” section, 2) a video that looks good with that much detail and motion will be HUGE, and 3) the team wanted the option to swap out background pictures ad-hoc. The answer in my mind was to build an animated SVG and overlay it on top of the slideshow behind.

Drawing things out helps sometimes.

To further complicate matters, the slideshow images needed to be full cover, which is impossible with <img> tags — they have to be background images. Of course you can’t fade background images in and out, so there had to be multiple divs, absolutely positioned, that held only background images, and a little javascript magic to swap between them smoothly.

Next the fun part, the SVG overlay. The SVG on the front page actually embeds the orange PNG, then draws the fins. The animation itself is pretty straightforward once you calculate the rotation point (the center of the circle cutout). Our designers generated the SVG for me, then I grouped the fins and gave each group a different transform value (clockwise, counterclockwise, slower, faster) to add visual interest.

I put the SVG in an absolutely positioned div to take it out of the document flow, then sized it correctly so it would fill up the hero section and still overlap the Agenda section. I messed with Z-index so that it was behind the hero text, but above the Agenda section. So far so good.

And then I opened the page in Safari and Firefox.

Firefox was spinning my CPU off the charts and Safari didn’t show the PNG that was linked in the SVG at all. I’m going to get right to the solution and give you the benefit of my hours of debugging — if you want an animated SVG to work everywhere:

Remove all the header junk that Illustrator adds to the top of the SVG file (Safari and FF choke on it), Get the SVG as close to your final on-screen size as possible (FF takes a huge performance hit while scaling), and Embed the SVG directly in the page. Don’t use <img> or make it a background in your CSS, just dump all the code right there in the page. It solves all sorts of problems.

Ultimately Firefox is just slow with SVG animations, it’s a known issue; see here and here. I think we squeezed out as much as we could using native tools (vs. a toolkit like Greensock).

Internet Explorer of course was another issue, but thankfully someone else did the work for us with the wonderful FakeSmile library. We dropped that in and boom, animations in IE, too!

There’s always more

Soon, I’ll write up how we built the Agenda section. It hasn’t launched yet, but we’ve got some great tips and tricks to share with you once it goes live! Thanks for reading, and I hope you come back for part 2.