TrackLine
Business & Career Consulting

CONTENT CONTENT CONTENT CONTENT


01

CONTENT / CONTENT

CONTENT


02

CONTENT / CONTENT

CONTENT

CONTENT

CONTENT

  1. CONTENT

    CONTENT

  2. The Deeplink

    CONTENT


03

CONTENT / CONTENT


04

Getting Around the Cities / & Why We Used MapBox

Why MapBox?

From a creative perspective, it was important to us to be able to customize our maps to feel at-home in the app, with a look-and-feel that matched our interface. The MapBox service offered us tools to easily customize map tiles for our purpose. We wanted the maps to feel very urban, so we chose a de-saturated, darker palette, on which our brightly colored map pins and routing lines would pop.

Color Coordination

In the Walks and Itinerary sections, users are presented with routes, and we wanted to ensure there was a clear sense of motion from beginning to end. To achieve this, we chose to visualize routes with a specific color gradient from purple to blue. Because purple is the warmer color, we felt that it was more appropriate to indicate the beginning of each journey. As each route progresses, both the lines showing the route and the pins indicating points of interest along the way gradually transition to blue.

Open Source SDK

We’re not content to use the same old UI metaphors, particularly when they don’t serve our goals. With our maps in this app, we knew we wanted to integrate the concept of the crosslink, so the traditional map callout simply wasn’t going to cut it. We came up with the concept of the “bubble” callout, with up to 2 smaller crosslink callouts. Let’s be honest – this is pretty far outside the norm of customization options provided by existing map SDKs. Fortunately for us, MapBox provides an open-source SDK for their map, so we had the power to dive into the internals to allow ourselves the degree of control necessary for our UX goals.

The Bubble Callout

The “bubble” callout appears when a pin is tapped, presenting secondary crosslinks in addition to the primary What To Do content. This level of customization was possible because of the open-source nature of MapBox.

05

What Is an Itinerary? / How We Made an Itinerary Experience More Useful

At its core, an itinerary is just a list. Since we already had a Favorites list, we had to seriously consider what value an Itinerary section would add for the user. In the end, it boiled down to what kinds of content are being saved. We decided that Favorites were a place to save specific pieces of content – What To Dos, Photos, etc. Itineraries, however, are strictly for Points of Interest – physical locations that a user can actually visit.

Learning from Past Mistakes

To be honest, when we built National Parks, the Itinerary section was a bit of an afterthought. We were so focused on the other features of the app, it kind of got lost in the shuffle. We’re not terribly comfortable with missed opportunities, so we were pretty excited to get a second run at the concept.

Some of our improvements were simple UX considerations that were missing, like the ability to rename an itinerary. More central, though, was our focus on making the itinerary a helpful planning tool.

Renaming an Itinerary

The ability to rename an existing itinerary was one part of making the Itinerary section a useful planning tool for users.

Since every location is geolocated, we wanted to plot them on a map and visualize a route between points. Turning an itinerary into a route posed a problem, however – unlike the curated content of our Walks section, a user itinerary is likely to be created without regard for the logistics of getting from place to place.

We didn’t want users locked into illogical routes, so we created a toggle that shows an optimized route for their custom itinerary.

CONTENT

CONTENT

CONTENT

CONTENT

Non-Optimal Route

CONTENT

Optimal Route

Thanks to our server-side routing solution, we can provide users a more optimal route, minimizing unneccesary travel.


06

How to Gesture / First, Do No Harm...

CONTENT

  1. CONTENT

  2. CONTENT

Main Menu

We learned on National Parks that with the stack metaphor popularized by iOS, it’s easy for users to get buried in crosslinked content. Our solution for City Guides was a main menu that is always accessible to the user, allowing them to jump from anywhere, no matter how buried, to a different section of the app. While there is a tappable UI callout visible at all times, we also wanted to allow for opening and closing the menu with a simple swiping gesture.

Swipeable List Cells

We love (and miss) the swipeable cells pioneered by Loren Brichter in Tweetie 2. We wanted to replicate the same slinky feel, allowing the user to pull the cell to the side with immediate visual feedback. We wound up using these swipeable cells two ways: for primary content, exposing the context menu options, and for user-curated itineraries, to reveal editing options. We’re particularly proud of the renaming feature, where the swiped cell expands to become an input field.

Detail Views

CONTENT

Weather

CONTENT


07

Custom Animation / Someday the Developers Will Have Their Revenge

CONTENT

Prototyping

CONTENT

The Devil’s in the Details

CONTENT

CONTENT

CONTENT

City Cards

CONTENT

City Statistics

CONTENT


08

Building a Universal App / Or, How We Avoided Losing Our Minds

CONTENT

Wildly Divergent Sizes

CONTENT

CONTENT

CONTENT

CONTENT

CONTENT

CONTENT

Shared Data Models or Bust

CONTENT

CONTENT

CONTENT

Separate Views

CONTENT

CONTENT

Reducing Bloat

CONTENT

CONTENT


10

Response / Repeat Clients are the highest compliments

CONTENT

Rachel Graham, Senior Director, Digital Book Publishing, National Geographic Society

No Such Thing as Friends on Powder Days / Re-Thinking the Nature of a Ski Resort Website


01

Snowbird at 40 / Home to the Infamous "K-12" From the Movie Better Off Dead

CONTENT


02

What Should a Resort Website Be? / Finding the Soul of the Modern Resort Site

A lot of resort sites feel pretty cookie-cutter to us. They tend to be heavily templated, presenting the same information in the same ways. We didn’t want to put our energy into creating the best “us, too” website that we could; we wanted to craft a digital experience that would be unique and, perhaps, a step forward for the industry.

Many Chiefs

The Consumer Is King

Mobile and Lightweight

CONTENT


03

Design Philosophy / So Fresh and So Clean

Inspired by the Past

CONTENT

Clean and Minimal

CONTENT

Streamlined IA

CONTENT


04

CONTENT / CONTENT

CONTENT

CONTENT

Mountain Report

The Mountain Report showcases the hallmarks of the smartphone design – large, tappable interaction points and clean, bold graphic design.

Book a Trip

The “Book a Trip” widget is collapsible to conserve screen real-estate, and utilizes the smartphone’s native date-picker and list-picker tools.

Events

Event pages show off gorgeous photos alongside the event name. They also surface the individual dates of the event, which is important for recurring events.

Lifts & Trails

For the Lifts & Trails page, we needed a way to condense information into a small space, resulting in a simple toggle system and iconography for lift type.

Bird’s Nest

The Bird’s Nest is Snowbird’s hub for photography, videos, and social updates. It had the potential to be overly complex, so we had to find a balance between cleanliness and features.

Aiming for Native

Prototyping as Discovery

CONTENT

Menu Flip-Down

Hiding the menu is standard on mobile sites, but we wanted a novel way to reveal it, resulting in the flip-down from the top.

Cube-Flip Transition

We wanted to indicate a sense of direction in page transitions, so came up with a cube flip to the left for forward motion, and a cube flip to the right if the user uses the back button.

Slideshows

When it came to implementing media slideshows, we decided to echo the menu and mountain report flip-downs.

The Mountains

A mobile-first philosophy didn’t mean that we wanted to neglect the desktop site. As we worked on extrapolating the desktop/tablet site from our smartphone designs, we incorporated some elements, like the 3D page transitions, but we wanted the larger version of the site to have some unique charms of its own. We came up with the concept of an abstracted mountain range as part of the main navigation. By using peaks of differing heights, we could indicate the section the current page belongs to as well as providing a rollover effect. The developers got to work on a prototype, eventually using Simplex noise and some simple spring dynamics to bring the generative mountain range to life.


05

Device-Specific Mobile / Tailoring the Experience for Each User

Giving each user the best experience for their device required a high degree of customization. At a high level, we had two different versions of the site: one for smartphones, and the other for desktop and tablets. However, there were still further, finer variations – slightly different markup for tablet vs. desktop, different JavaScript for tablet vs. desktop to account for touch controls, and variations to account for differences in mobile operating systems. In order to handle this variation, we had to employ both server-side device detection and client-side operating system detection.

Server-Side Detection

To serve the correct version of the site to a device, we needed our backend to be able to differentiate between different classes of devices. A lot of server-side solutions for this were a bit too simplistic for our needs; they only categorized devices as mobile or non-mobile, where we needed to identify desktops vs. smartphones vs. tablets. Fortunately, we tracked down MobileESP, an open source, multi-language project for granular device detection. We grabbed the Python version and whipped up a bit of middleware to use MobileESP in our Django setup, passing all incoming requests through and setting properties denoting what kind of device the request is coming from. By doing so, we could make decisions both in which templates to serve, and also occasionally how to modify the markup specifically for the device.

Client-Side Detection

Custom experience for iPhone, iPad, or desktop

Drawbacks

To be quite frank, we dramatically underestimated how much work this would all be. We hung ourselves with the very flexibility that we valued in this approach. While all our work on the back-end applied throughout, our front-end was completely unique – which was great, except when we started building the phone version of the site, we were starting from scratch. We had miscalculated how much time it would take to optimize a site this complex for various browsers, and our approach doubled the impact of that miscalculation.


06

Building for Retina / Showcasing the Crispest of Graphics

Ticket Icon
Retina Size
( 120 × 156 )
Ticket Icon
Actual Size
( 60 × 78 )

High pixel-density screens are great. They look amazing on mobile devices; it’s almost physically painful for us to use old non-Retina iPhones. With higher pixel-density screens becoming ubiquitous, we knew we’d have to account for them in building the Snowbird site. Besides, they’re even starting to make their way to laptop and desktop displays, so we figured we’d better make sure they’re handled while we wait for GPUs to catch up to the skyrocketing pixel count.

To account for retina graphics on the site, we had three cases to account for:

  1. CSS Backgrounds

    To handle CSS backgrounds, it was a simple case of using a media selector to override a background image in the case of a retina screen (for our purposes, a pixel-density of 1.5 or higher).

    
    .mobile-cta {
        background: white url('../img/mobile-cta-arrow.png') no-repeat center center;
        -webkit-background-size: 21px 19px;
        -moz-background-size: 21px 19px;
        background-size: 21px 19px;
    }
    
    @media screen and (-webkit-device-pixel-ratio: 2.0),
    screen and (-moz-device-pixel-ratio: 2.0),
    screen and (device-pixel-ratio: 2.0)  {
        .mobile-cta {
            background-image: url('../img/mobile-cta-arrow@2x.png');
        }
    }
        
  2. IMG Tags

    To handle actual IMG tags, we went the route of including both non-retina and retina versions in the HTML markup, specifying the dimensions to ensure they render at the right size, and including appropriate classes. We then used CSS, with media selectors, to show and hide the appropriate images.

    
    <img id='hero' class='nonretina' width='920' height='350'
    src='/static/​media/​hero_shots/​summer_tram_A_1840x700_​normal.jpg' />
    <img id='hero' class='retina' width='920' height='350'
    src='/static/​media/​hero_shots/​summer_pool_A_1840x700_​normal_retina.jpg' />
    
    
    img.retina {
        display: none;
    }
    
    img.nonretina  {
        display: block;
    }
    
    
    @media screen and (-webkit-device-pixel-ratio: 2.0),
    screen and (-moz-device-pixel-ratio: 2.0),
    screen and (device-pixel-ratio: 2.0) {
        img.retina  {
            display: block;
        }
        img.nonretina {
            display: none;
        }
    }
        
  3. Canvas Elements

    For our canvas elements, the situation got the most convoluted. We started by setting the dimensions on the canvas element in both the markup and in CSS. Then, in JavaScript, we detected the pixel-density ratio of the device. If the ratio is greater than 1, we had to increase the element size (much like our IMG tags), and then take that ratio into consideration for all our drawing.

    
    <canvas width="177" height="177"></canvas>
    
    canvas {
        width: 177px;
        height: 177px;
    }
    
    var scale = 1;
    
    if(window.devicePixelRatio){
        scale = window.devicePixelRatio;
    }
    
    else if(window.matchMedia
    && window.matchMedia("(-moz-device-pixel-ratio: 2.0)").matches){
        scale = 2;
    }
    
    ...
    
    self.canvas.width = 177*scale;
    self.canvas.height = 177*scale;
    
    ...
    
    self.context.lineWidth = 18*scale;
    self.context.arc(177*scale/2, 177*scale/2, 177*scale/2 - 26*scale, 0, 2*Math.PI);
        

07

The Right Tools for the Job / Building Custom Tools for the Snowbird Team

At Rally, we’re big fans of Django – it’s usually our first choice for any back-end or CMS. We love a lot of things about it, but one of the biggest things is the flexibility to create the tools we need. For this site, we encountered a handful of challenges that we needed to build custom tools for. At the end of the day, the team at Snowbird has to be able to maintain the site, so part of our job is ensuring they have the tools to do so.

Events

Snowbird hosts a variety of events throughout the year. Some are one-time events, some stretch for days at a time, and some recur weekly or monthly. We needed a robust event system to allow the flexibility to allow so many possibilities, so that’s precisely what we built. We also built custom logic to comprehend recurring or monthly events into the specific dates on which they occur. This allowed us both to list the individual dates they occur, and also to filter the events to show only ones occurring on a given day or within a certain range.

Dining Hours

A restaurant listing would have little use if it couldn’t list accurate hours. With the various restaurants located at Snowbird, we knew we’d have a different dining hours to work with; some might have roughly the same hours every day, while others might have very different hours during the weekend, or perhaps were closed one day a week. It was essential to faithfully represent those differing hours, but we wanted to keep the presentation as uniform as possible. WYSIWG editors are the enemy of consistency, so we wanted a better solution. In the end, we created a system where the Snowbird team could add all the times a restaurant was open as individual entries. Our custom logic would then grind through and spit out a simplified entry, displaying the days and times the restaurant was open in a simple and accurate manner, giving us the control to keep the styling uniform.

Image Sizing and Cropping


08

Building for Performance / "I’m Givin’ Her All She’s Got, Captain!"

No Javascript Libraries

Knowing that both versions of the site would be running on mobile devices, we knew we’d need to optimize for performance. This lead us to adopt a policy of avoiding any large JavaScript libraries. There are a few simple reasons for this spartan approach:

  1. Many of the time-saving element selection methods in popular libraries are now built into vanilla JavaScript.

  2. The weight of downloading a library – which manifests in both download time (dependent on network speed) and parsing time (dependent on processing speed) – generally outweighs the site-specific JavaScript you need for the site.

  3. Our development team is comprised of masochists.

CSS Transitions

Desktop Page Transition

The cube-flip was too dramatic a movement for the size of the desktop site, so we instead embraced a more subtle 3D tilt as a page transition.

Mountain Report Foldout

In the interest of keeping the mountain report at the user’s fingertips, we came up with a condensed report that folds out on rollover.


09

Rally’s Home Slopes / Our Ongoing Relationship With Snowbird

More Than Just a Website

One of the joys of being headquartered in the Wasatch Mountains of Utah is the stellar skiing and snowboarding right out our door. With a dozen resorts just a short drive away, it’s hard to choose a favorite, but Snowbird is our primary winter destination. Since its inception, Rally has held its annual Christmas party at Snowbird, partaking of the fine food and excellent lodgings. We’ve had early tram sessions and witnessed the sunrise on Hidden Peak. We’ve taken the whole crew out on guided cat skiing adventures, and we’ve had the pleasure of being interlodged. We knew that we were building a site that we would ultimately use as patrons of the resort – the website for our home away from home.

A Place to Work

As much as we love to come to Snowbird to play, it’s also a great place for us to work. Long projects require trust and collaboration, and we like to establish both with face-to-face meetings. Snowbird has served as our venue for these meetings in the past, and it surely will continue to in the future. The ability to play host to our out-of-town collaborators in such a beautiful location is simply a bonus for us.

The Work Continues

Any website of this size will continue to grow and evolve. We continue to be involved with Snowbird’s site, making sure it continues to meet the needs of its customers. Our involvement ranges from simple maintenance to building entirely new features, as the requirements of the site continue to evolve.


10

Response / Website? Check. Snow? Check. Let's roll!

The Rally team created a site for Snowbird that is innovative, beautiful and functional on multiple platforms. We have worked with Thomas, Wes and Ben on several projects and they consistently deliver a product that is ahead of the curve and represents the personal investment they make in their work.

Dave Fields, VP Resort Operations, Snowbird Ski and Summer Resort

National Parks Are the Best Idea We Ever Had —Wallace Stegner


01

Technostalgia / Fire Up the Wood Paneled Station Wagon of the Mind. We’re Going on a Road Trip.

Rally had a unique opportunity to build a product that really mattered. After years of working on digital advertising projects, finally there was something worth advertising. Could we leverage new and emerging technologies to rekindle the spirit of visiting our country’s most beautiful and iconic places? Could we use a medium most associated with being on the couch to actually inspire people to get off the couch?

The National Parks App by National Geographic was our chance. But we’re getting ahead of ourselves. First we had to earn it.


02

Getting the Job / How We Were Chosen to Build the National Parks App

The Proposal

The Presentation

Meeting National Geographic


03

Starting the Process / Or, Getting the Ball Rolling, Rally‑Style

The Meeting

As Big as You Need Us to Be

We hired another developer, our first employee Adam Luptak Senior Developer

Colocation


04

Branding the National Parks / The Little Big Idea of Branding the National Parks

Neil Peart, Roadshow with Drums

We tried
circles…
We tried
rectangles…
We tried
rectangles
with circles…

We were stoked to take a crack at updating this concept for the digital age. Rather than having a simple stamp with differing text for each park, we wanted to really brand each one. We were inspired by the ambition of Nicole Meyer’s Branding 10,000 Lakes project, and we wanted to give each park a unique stamp that could be representative of its most memorable features.

And we ended up with
the rounded hexagon.

One problem – none of us at Rally were illustrators. Recognizing our weakness, we reached out to our very talented friend Valerie Jar. Val worked closely with us, experimenting with different looks for the stamps. We tried traditional circular stamps and we tried rectangular stamps, but we were looking for something unique. When we tried a hexagon, we knew we had cracked it. We really feel Val knocked it out of the park.

Then Val started
sketching… a lot…
And here's a sample of the finished product.

05

Functionality Über Alles / We Fight for the Users

Tools, Not Gimmicks

The great boon of a project like this was knowing that people would want to use the final product; our parents would use it, our friends would use it, and we would use it. This wasn’t some advertising vanity project that no one outside the ad industry would ever see. We wanted this to be a tool, something that would actually be useful. This meant a focus on usability through the entire lifecycle of the project.

Data Design


06

UIKit With a Twist / Making the App Look Familiar but Unique

Evolving Conventions

We didn’t want to reinvent the wheel more than necessary, so we started with familiar UI conventions. We used the convention of the standard UINavigationController, but since we wanted the power to fully customize our titlebars, we created our own NGSNavigationController and NGSTitlebar classes to give ourselves all the flexibility we wanted.

We also utilized the emerging convention, popularized by apps like Facebook and Path, of the hidden tray on the left side, which we used as a hub for the user’s data.

Skeuomorphism

Since we knew the Canyon Country app was a big factor in our landing this job, we had a good idea where to start on design directions. We wanted to connote a sense of exploration and adventure, perhaps channeling an old guidebook. It all went into the blender, and we came out with textures, some subtle topo backgrounds, and a very little bit of refined leather and stitching.

Push-back Modals

The Push-Back


07

Details, Details, Details / To Build the Best Forest, Focus on the Trees

Photo Gallery Centering

Handcrafting Retina Graphics

Ah, the new retina display. We loved the beautiful, crisp graphics, but there was a tradeoff: time and effort. We built our comps at one size or another – retina for iPhone and non-retina for iPad – and we cut UI assets out at that size during development. We used some simple Python scripts (using PIL) to create either retina or non-retina images to act as placeholders, but those resized graphics weren’t good enough for the final product. Towards the end of the project, as the developers were putting in the final touches, a designer went through the app, recreating assets at the proper sizes to ensure pixel-perfection on either screen type.

Retina Size
( 248 × 290 )
Actual Size
( 124 × 145 )

The Tray


08

Oops! / Things We Learned Along the Way

The Trials and Tribulations of MapKit

The chief benefit of using a mature code library like Apple’s MapKit is being able to count on it being well-crafted and relatively bug-free. The downside, of course, is being at the mercy of the library’s authors when it comes to skinning and customization. We quickly discovered that MapKit was not really designed with customization in mind. Skinning pins isn’t bad, but there’s not much you can do to substantively alter the map callouts; to get around this, we had to exploit a nasty hack by creating callouts that are, for all intents and purposes, actually map pins. This approach enabled us to get the look we wanted, but required ugly workarounds to circumvent some normal pin behaviors.

Skinning MapKit

We were ultimately able to customize the look of pins and callouts on our maps, but at the cost of grey hairs and ugly hacks.

The other downside to using MapKit came when Apple announced that they were replacing the Google-sourced map tiles with their own. We were using an undocumented but widely known MapKit property that allowed us to use Google’s terrain tiles, which looked great with the style of the app and helped connote an outdoor focus without the visual clutter of satellite imagery. When users upgraded to iOS 6, however, this terrain option vanished, leaving them with a map style that just didn’t work as nicely with our app design.

Google Maps

Terrain tiles from Google Maps - we miss you! The terrain style looked great with the design of our app; its gently muted colors and elevation profiles evoke old-school guidebooks.

Apple Maps

Sadly, Apple’s satellite maps just don't look as nice with the design of the app. The saturated colors of the map blend with the pins, resulting in candy-colored over‑stimulating maps.

Protect Your App from API Failure

We screwed up. We knew it, and there was nothing we could do about it. The iPhone version of the app had launched with a feature from Apple as the iPhone App of the Week, and we were getting more downloads than any of us had seen on a project we’d worked on. We were on top of the world, and then it came crashing down on us.

The Yahoo Weather API broke.

This shouldn’t have been such a big deal, but we screwed up. Instead of failing silently, tons of our new users were seeing an iOS alert giving them a cryptic error message. In the end, Yahoo fixed the rogue data center that was causing issues, we removed the offending alert, and we eventually replaced Yahoo with Weather Underground.

Park Forecasts

Weather forecasts were the cause of a stumble out of the gate for the app, but it’s all good now. 87 and sunny, sounds pretty nice…

09

Response / Awards & Sales Are Nice, But We Prefer The Love…

Some of the brightest minds I’ve had the pleasure of working with have been at TrackLine Consulting. Their ability to express product vision and strategy is surpassed only by their ability to deliver. TrackLine Consulting has become a trusted partner of National Geographic, successfully collaborating on two major, multi­-award­-winning apps (and counting), and a few forward­-looking interactive storytelling pieces. Each time, Rally has approached each initiative with excitement, ingenuity, composure, and professionalism and continues to deliver world class products and consumer experiences. A brilliant group of thinkers, designers, developers, producers and technologists passionate about their work and creating high quality products.

Jess Elder, Senior Product Manager, National Geographic Society