JJ Responsive Redesign Project Overview
•0 likes•262 views
Report
Download to read offline
2013
More Related Content
Recently uploaded
Recently uploaded(20)
Featured
Featured(20)
JJ Responsive Redesign Project Overview
- 4. 2007
- 7. 2012
- 13. ALSO:
- 14. ALSO: VERSIONS.
- 16. O/S VERSIONS.
- 18. “EVERYONE”
- 21. DESIGN DEVELOP
- 22. FRAMEWORKS
- 23. BOOTSTRAP
- 24. ZURB FOUNDATION
- 25. FOCUS
- 44. COLLAPSE OPTIONS
- 59. …AND MORE.
Editor's Notes
- Hi, my name is Adam Kempa, and I’m a Senior Software Engineer with Enlighten, a digital agency based in Ann Arbor, Michigan.
- Enlighten offers a range of digital consulting services, centered behind a focus on User Experience. We work with clients in a broad range of industries, and over the years we’ve had the opportunity to assist with quite a few Ektron integrations.
- As technologists, it’s always interesting to see the different ways in which a platform is adapted to different needs, and we’ve seen how Ektron addresses unique needs in the finance vertical, with clients like Citizens Bank and Central Bancompany; in the health vertical with groups like Ohio Health and St Vincent Health in Indiana; in a focused call-to-action case for Masco Contractor Services; and in branding-focused integrations like Jimmy Johns. JJ’s is one of the most recent Ektron integrations I personally worked on, so I’m going to run through a very brief summary of some of the goals of the work we did, and then talk about some specific things we did to tailor the site to mobile users.
- Back up to 2007 – this is when Enlighten first worked with Jimmy John’s to launch their previous site, also on ektron. AT the time, the messaging across the site was very different.
- As you probably know, Jimmy Johns had a foothold in a number of college towns early on, and began franchising outward from there. This ended up working out pretty well, since the students at these schools were constantly graduating and spreading out in all directions. This served as the basis for a sort of perpetually growing, distributed brand-awareness, which is not a bad thing to have when your focus is on growing the breadth of your franchising. Foreshadowing: Shortly after the launch of this version of the site, something called the iPhone was released.
- You can see this in the prominence that franchising has throughout the homepage.
- Fast forward five years. The jimmy johns website has grown to handle things like Online Ordering and Gift Cards. The internal team built an iOS ordering app, but the prospect of building custom applications for each platform wasn’t appealing. At the end of last year, we started working to bring the JJ family of websites and partners into a single, cohesively branded mobile-friendly experience.
- Franchise growth at this point had exploded. There are currently over 1600 Jimmy Johns stores in 40 states. Moving into this redesign, franchising was no longer the priority. You can see from this ad that even in publications targeted specifically to the franchising industry, the call to action is qualified. This meant a fundamental shift in messaging and strategy throughout the website.
- The primary use case had shifted from generating franchise growth leads, to driving individuals into beginning an ecommerce transaction.
- And what else had been changing over those same years? The hardware landscape. Smart phones exploded. Tablets of all sizes took off. And people still used their laptops and desktops. Naturally, Jimmy Johns wants to be able to sell sandwiches to everyone. So I want to quickly emphasize what “everyone” means.
- If we look it at from a hardware angle, we’ve got phones, tablets, inbetweeners, and traditional computers. In the apple world, that’s iphones, ipad and ipad minis, and imacs / macbooks. In Microsoft world, that’s Windows phone, Windows Surface, and windows laptop/desktops. Androids got a million phones, tablets of all sizes, and now we’ve got Chrome OS on chromebooks. Don’t forget the Blackberry diehards. Oh and also Kindles, because that’s not stock android, they forked it. Also there are all of those weird-sized android devices that land somewhere in the middle of these categories.
- Each of these unique operating systems has it’s own built-in browser: Safari for apple, Early android has “Browser,” Windows has IE, Kindles have the “Silk” browser, and Blackberry has … “Browser.” Then, there are the browsers that try to target all platforms: Chrome, Firefox, Opera, Dolphin, and the list goes on.
- Just to make sure we’re seeing the full magnitude, we have to consider…
- Versions.
- Hardware versions. For example, animations will perform differently in safari on an iPhone 3G vs. an iPhone 4S vs. an iPhone 5C
- O/S versions: For example: a completely different set of browsers can be run on Android Gingerbread and Android Jellybean.
- And speaking of browsers – every version update can change rendering. Just ask anyone who wrestles with the differences between IE 10 vs. IE 9 vs. IE 8 vs. IE 7 … vs. IE 6… all of which are still being used by more people than you think. I can tell which audience members are coders by who cringes at that.
- That’s a lot of variation. If you’ve ever worked on a website project, you know that cross-browser support is a never-ending battle. In many cases, it is deemed more efficient to “drop” support for older browsers than to make sure functionality is compatible with the lowest common denominators. In this particular case, however, and at this scale, saying “no” to any one browser means saying “no” to sales, and a not insignificant number. Because of this, a focus on browser support was a huge part of our effort. That’s not to say we solved every issue – if you’re here rocking an early sidekick, you’re still going to have a bad time.
- This means the effort put into designing these interfaces is incredibly important…
- … and that the effort put into building these interfaces is equally important. Ideally, we think they should inform each other.
- When building responsively, you’re almost guaranteed not to get it right the first time. The ability to test whether something “feels” right on real hardware is incredibly helpful when assessing design candidates. Doing this means your developers and designers should be working closely together to iterate through ideas. For best results, the process should be cyclical and look something like this: Obviously, the faster you can get to the point of trying out a prototype, the sooner you can assess the likelihood it will work.
- Because more and more people have been wrestling with these considerations, a number of frameworks have sprung up that handle much of the heavy lifting of browser compatability, while accelerating the process of laying out basic elements on a page. These frameworks are great for rapidly creating prototypes, and operating within the capabilities that they offer will not only save you from tinkering with browser compatibility when you’re trying to assess interface functionality, but it will also steer your interfaces in the direction of well-tested best practices.
- Two of the most commonly-used such frameworks are Twitter Bootstrap…
- …and Zurb Foundation. Even if you don’t plan on using one of these frameworks in your final site, they are a useful tool to quickly help everyone on the team visualize how different concepts will work on many devices and at many widths. Not from scratch
- As you iterate through design approaches and start to find the problem areas that emerge at different sizes, you’ll likely see that simplifying the design can translate into more flexibility in how the elements on screen re-orient themselves. This simplification ends up working out quite nicely from a messaging perspective, as such simplification tends to bring the relevant content into sharper focus.
- So: the previous Jimmy Johns site was *accessible* on mobile devices, but the experience wasn’t optimized for the form factor.
- Things did not size intelligently…
- …and the messaging didn’t adapt to address the contextual need.
- By iterating through a number of designs, simplifying, and focusing on the content that is useful in different contexts, we were able to create templates that provide an optimized experience at almost any screen size:
- On desktop-sized screens, We still have our single central message, augmented a bit by some of the real-time discussion on Twitter and Instagram. We deliver fast; Here are people happy about it. What we do; unsolicited verification. We stick with this messaging down through the ballpark of tablet sizes. Once we cross the threshold into mobile-phone screens, we shift to focus on the more singular, task-based message: You’re probably here to order, here’s how. [Scroll through sizing slides]
- So, now I want to talk about some of the things we worked through to proactively speed things up for mobile users of the site.
- The homepage when viewed on desktop has a rotating theatre containing four hero shots that cycle. Lately, the effectiveness of carousels at delivering multiple messages has rightly been called into question. In this case, however, with a maximum word density of 3, we felt it worked.
- On a mobile-width device, the theatre isn’t present, but it’s important to note that the theatre images aren’t just loaded and then hidden – they aren’t served to devices requesting the page on screens of this width. The theatre code and content is only loaded above a certain minimum screen-width. This way, we aren’t forcing unnecessary content over the cellular networks to phones. On many carriers, people are being billed based on the bandwidth they use, so we need to be respectful of that. It’s not just about bandwidth billing, though – it also affects performance. The less a page has to pull down, the faster it’s going to render on the screen, and in a mobile context users are conditioned to switch tasks in a fraction of a second.
- Having an ever-present “global navigation” in the footprint of a mobile screen is almost impossible. A number of “standard” ways to do this have emerged. In testing, we found a nav link at the top of the page that animates down to a stacked listing beneath the page content to be the most intuitive option that was reliably functional across the swath of older phone browsers we supported.
- If the site you are building has any functionality beyond providing textual information, you’re going to end up hunting around for places to put controls, settings and things like that. Throughout the site, we’ve used these collapsible areas to contain functionality that doesn’t need to be immediately actionable. It allows for less scrolling when accessing the primary needs, and adds additional content as needed, all along a single, vertical axis.
- While it’s tempting to make sure everything is rigidly-on-brand, it’s important to defer to native controls and functionality where available. These are things your users have become used to through use, so while a dropdown that matches the styling of your site may *look* better, a user is going to be able to more efficiently complete a form using controls they’re used to.
- Here’s an example of a native android dropdown…
- On the desktop, we did style the dropdowns here the browser allowed it. Pro tip: of all of the crazy things we undertook while working on this project, this “intelligent handling of dropdowns on a cross-browser, cross-device basis” is the one thing I wish I could take back. There is a ridiculous range of variation in how browsers handle the select element, so if you’re serious about both cross-browser inclusivity - and more importantly, accessibility – you’re better off sticking with standard dropdowns. Trust me.
- Another example of native functionality that can be tempting to tamper with is the automatic linking of phone numbers. Different phones handle this in different ways, but they tend to be in a fixed, “Vintage blue link” style. We did end up finding a way to reliably style these while ensuring they stay clickable, but it’s worth emphasizing that the “clickability” of the number should be top priority.
- In a mobile context, any form filling you can help the user skip will obviously speed things up. The Jimmy john’s site has a “Find a JJ’s” link that can map the JJ’s within a certain radius. Where ever possible, we use HTML5 geolocation to prompt the user to detect their location, making this discovery a one-click operation. If the user declines, or geolocation is not available, we provide dropdowns that can be used to focus the search.
- While finding a JJ’s can rely on an inexact radius, ordering for delivery requires an exact address to determine whether it lies within a delivery range. In order to speed this up for users, we’re using library offered within the Google Maps API: Address autocomplete. This service triggers on each keypress, and brings back the best results from the address databases that populate Google Maps. This obviously doesn’t work perfectly for every address, but for a majority of users, it minimizes address entry to a single field and a confirmation.
- So those are some of the things we worked through to speed up the mobile site for users. I want to go back and revisit the Instagram integration we touched on earlier.
- Jimmy johns is very active on twitter, and are mentioned all the time on instagram and the like. One of the first things we noticed when looking around was the sheer volume of instagram activity tagged with #jimmyjohns. None of this activity had any visibility on their old site, and they wanted to bring it to the fore. Since the content is visual, Instagram activity was our first choice to feature, but as with any user generated content, there’s an inherent danger there. If we just pull from the tag at random, who knows what could end up on the homepage?
- So what we did was build a simple admin for the instagram feed. JJ’s admins can browse the realtime feed of images tagged with #JimmyJohns, and choose image to “Feature” on the homepage. We created an Ektron smartform that holds the text of the caption and a link to the featured image on Instagram’s servers. These featured images enter a pool of approved imagery that is randomly drawn from as the page loads, keeping the content fresh.
- So those are some of the things we worked through to speed up the mobile site for users. I want to go back and revisit the Instagram integration we touched on earlier.