Bringing The New VIA To Life: Video & Navigation
When building the new viastudio.com, we pushed ourselves to explore ways to integrate a variety of content. We didn’t want to be held to a template. Front-end had to reach deep into our expertise (and expand our knowledge) to build a rich site that illustrated our capabilities.
This is the first in a series of posts about how we took our ideas from storyboards and mockups to the website you see now. In this post, we’re going to cover how we built our site headers around video loops that tell the story of VIA Studio. We believe experiences built for all kinds of device sizes is the future of the web. So we’ll also explore how we implemented easy to access navigation at smaller screen sizes.
Thanks to HTML5 and modern browsers video is no longer a second-class citizen on the web. We decided to not just incorporate video as content but as a part of our design. This presented a unique set of challenges for front-end implementation. Specifically, working with content streaming in at a variable rate and could finish loading at any time after the rest of your initial document loads.
We began by building the header around an image element containing a still of the video. The contents of the header needed to resize with the browser viewport. After the header structure and overlaid navigation was complete, the video was dropped in. We quickly discovered that our video element wasn’t sizing to its container quite as well as an image. We also encountered some jerky page reflows as the browser figured out the dimensions of our video on initial load.
Here’s our markup, slightly abridged for this example:
Once the video’s arrived, we add the class
in to toggle the video’s opacity and reveal our feature presentation.
We’re big fans of responsive design at VIA, so naturally we wanted our new website to feel at home on any device. Our navigation is unsuitable for a smaller screen size and we didn’t want to load our mobile header down with navigation. Familiar user interface patterns can make navigating an unfamiliar space easier, so we decided to implement the off-canvas navigation pattern often seen in native mobile applications.
Our markup for this is pretty simple. Our main navigation,
#access, sits outside of the
#page element which contains the rest of our site. On desktop, this is displayed on top of the header. On mobile, it’s hidden.
To hide our navigation, we position both
#menu to the left.
#page is stacked on top of
z-index. We also setup a transition on
#page to configure the slide-out effect. We use a special CSS timing function,
cubic-bezier, to ensure our menu slides open quickly but comes to a smooth stop. This makes the menu feel fast, but not jerky like an instantaneous transition.
Next, we set up a
.menu-active class that will go on
<body> and tell
#page to move 70% to the right. This pushes
#page off screen to reveal
Now we needed to hook up a
click event to open the menu. As the resident front-end performance nerd, I wanted to ensure this interaction felt as quick and natural as possible. Unfortunately, most mobile browsers implement a delay between the user initially tapping the screen and registering a
click event. This is normally a good thing as it allows the user to swipe up and down to scroll without inadvertantly activating any buttons, but it has the unfortunate side effect of making websites feel slower than users expect.
To address this issue, we used Google FastButton to eliminate the 300ms delay on our menu button. Hooking up FastButton is similar to a jQuery click event:
Now our menu is toggling in and out when the user taps
.menu-button. This is good, but introduces the problem of the user needing to know to tap that button again to bring the content back and dismiss the menu. In native mobile application, tapping anywhere on the app’s content will slide it back into full view. We’ll use FastButton to set that up, but take care to add and remove those events only when necessary, as the user won’t be able to interact with our content while a click event is bound to the whole content container.
You can view the result of this implementation by tapping the menu button at the top of this page, or having a look at viastudio.com on a smaller device or browser window. It’s worth noting that this implementation heavily makes use of CSS transforms, so you’ll need to add a fallback for older browsers (ahem, IE8) without support for CSS3 features.
Until next time
This brings us to an end of our initial post. In our next post, we’ll explore how we implemented the animations on our “About” page.
Wireframing vs. Prototyping and Everything In-Between
By:Morgan Plappert on 7/14/2020
Prototyping demonstrates ideas, and baking prototyping into your workflow can begin to shift the way you think and approach design problems as a whole.Read More »