Issue 7 \\ The How
 

Issue 7 \\ The How

Our team just made the final push to get New MailChimp out the door. We're excited to share some of the details, successes, and failures that we encountered along the way.

In this issue, UX developer Jason Beaird reveals some of the structural changes to the app that made this redesign possible. After that, UX developer Mardav Wala talks about how he built our new responsive subscriber table. We conclude with some links of interest from the world of UX.

We hope you enjoy this admittedly nerdy peek into how we made it to this week's launch.
Tweet
Share
Forward to Friend

View Switching:
The Secret Sauce Behind the MailChimp Redesign


by Jason Beaird
How do you execute the redesign of a web application with nearly 1,000 views? My gut response is to avoid changing markup and do as much as possible in the CSS. With a totally rebuilt, responsive pattern library and massive UI changes (like the subscriber table wizardry Mardav talks about below), we knew that wasn't an option. Indeed, every view had to be touched. In some cases that just meant swapping a few classes, but a lot of pages had to be re-built from the ground up.
 
No matter how much prep we did outside the codebase, we knew that process wasn't going to be completed in one of our standard 4-week release cycles. Our new views and stylesheets had to coexist with the existing views and styles through at least 2 major releases. To do that, our devs created a stored user-preference for "usingNewDesign." If that setting was true, the app would look in a "new-views" folder for the requested page before falling back to the standard views folder.
The old and new Mailchimp dashboard, coexisting.
In digging back through the commit logs, we initially created that "new-views" folder on February 4th—2 years to the day after Aarron blogged about the previous MailChimp redesign of 2011. What we had hoped would take about 8 weeks took nearly 4 months of furious front-end modifications. Not only did we have to test the new design in multiple browsers and devices, but we also had to make sure our changes didn't break the old design.
 
As we got closer to finishing and our QA team found fewer critical bugs, we took a closer look at how our newly-responsive app performed on smaller devices. Our primary objective was optimzing for tablets. While most of the views were usable on phone-size devices, some interfaces (like the drag-and-drop editor) just weren't going to work on a phone screen. We knew that touting our app as responsive would inevitably mean that people would whip out their phone and log in, so we needed a solution.
The drag and drop editor on a variety of mobile devices.
This is where server-side view switching came to the rescue again. What we wanted was the ability to serve a completely different view based on an arbitrary screen width requirement. Determining screen width server-side is tricky—doing so requires matching the reported user agent string against a lookup table of device properties that changes constantly. Instead, we decided to grab the screen width on the client side from the login page (which would always be responsive) and set a session variable for the preferred view set. That session variable works like the "usingNewDesign" preference, in that if a phone-size device is detected, the browser will look in the phone views folder first before falling back to the default responsive view.
 
In the device-testing image above, you can see that we serve a "Feeling Cramped" page in place of the drag and drop editor. While the current phone view for the editor isn't an ideal solution, having that width-based view system gives us the ability to craft an interface that better serves phone users in the future.

Coding MailChimp’s Responsive Subscriber Table


by Mardav Wala
The main goal that we set to achieve for the new Subscriber Table was to make it such that “it just works” across multiple screens and devices.

Design-wise we wanted a table that:
  1. Was responsive
  2. Supported up to 60 fields—a horizontal scroll bar would be present for lists with a lot of merge fields
  3. Had a fixed column to the left below which, the content would scroll
Paging, sorting and column toggle options would be retained from the previous design. Although similar to the old design these have been completely rewritten by our talented devs.

After looking at some really cool implementations, we came up with a solution that met all our requirements and worked great across all browsers (iOS Safari, I’m looking at you).
Assuming a horizontal scrollbar at all resolutions meant that no pivoting of the table would be required. Absolutely positioning the fixed column and converting the table cells to inline-block elements allowed for a left margin on the fixed column sibling element maintaining the table layout.
.v-head + td {
    margin-left: @fixedColWidth;
    ...
}

Mo' iOS, Mo' Problems 

Since it was an absolute requirement that the table worked on all devices, seeing some issues crop up in iOS put on a bit of a damper in the coding process. Debugging with the Web Inspector proved to be very useful in all problems iOS.

Choppy Scrolling 

Steven Sloan stumbled onto this while working on the product site and shared his “extrapolated” workaround to trigger iOS HW acceleration with backface-visibility: hidden and -webkit-overflow-scrolling: touch to alleviate the choppy scroll behavior on iOS. This worked great until ...

Column Transparency

The address merge fields usually have three or more lines of content and while overflow-y: auto seemed to be a no-brainer, it didn’t play well with backface-visibility because now that fixed column was completely transparent.

Replacing backface-visibility with -webkit-transform: translateZ(1px)fixed the choppy scrolling and the transparent column issues.

While we continue fixing those little kinks from the subscriber table check out a simplified Gist of our implementation. We’d love to see where and how you use it.
Check out the Responsive Subscriber table Gist

UX Around The Web

Ask Us Anything

We want this newsletter to be a dialogue. If you have any questions for our team about CSS preprocessors, recommended books, design workflows, device testing, icon fonts, our favorite Atlanta eats, or even Jenn's awesome songs, send them in. Seriously: hit reply and ask us anything. We'll try to answer every email and maybe even share our conversation in future newsletters.
Twitter
© 2001-2013 All Rights Reserved.
MailChimp® is a registered trademark of The Rocket Science Group


view in browser   unsubscribe   update subscription preferences   



Email Marketing Powered by Mailchimp

Love What You Do