Improving our mobile user experience — a quick-win approach
Our product and engineering teams at Tailwind are always looking to improve our product’s capabilities and user experience. This year, one of our focus areas is to streamline our Instagram posting capabilities. As part of these efforts, I worked on improving the look and feel of our Mobile onboarding screens. This is important because most of our Instagram users sign up using a mobile device.
Onboarding Experience
The user experience within our app begins with onboarding. This is a crucial step both for the user and for us, since an onboarding process that effectively educates users to use our app improves the value they get from Tailwind, improving our adoption and retention metrics.
Historically, our user base has interacted with our app primarily through their desktop, which lead us to build our onboarding process and experience optimizing for desktop users. However, a growing share of our users are both signing up and using Tailwind on their mobile devices. To accommodate our changing user behavior, we needed to adapt our existing screens (screenshot below) for mobile devices.
At Tailwind we like lean development practices, where we can deliver features and changes to our users and measure the results, confirm our hypothesis, and take further steps based on this data. Instead of changing the UX across the entire app, we first focused on mobile onboarding because of its impact on the lifetime of the customer.
After investigating our onboarding process on mobile, we further subdivided our efforts into a quick-win phase and a deeper future revamp phase.
In the quick-win phase, we looked for parts of the onboarding experience where, with an update from desktop styling to a mobile-optimized styling, we could deliver a significant improvement in experience for not that large an investment in terms of time, scope, and complexity.
Goal: deliver value quickly for our users
Time, value, and bang for our buck became our guide for the quick-win phase of mobile improvement. In addition to the user value reasons for this quick-win phase we described above, other factors made us want to provide a good solution quickly.
First, some of our engineering team members were relatively new to this section of our codebase, and we wanted to increase our collective understanding of the desktop-based functionality and how to adapt it for mobile. Additionally, our Marketing team had been steadily ramping up our Instagram mobile marketing efforts, so we wanted to align our timelines to increase our user adoption.
To determine the scope of the quick-win phase, we worked with our designers to identify a set of onboarding updates that would immediately improve the user experience without needing to substantively change the process flow, its main functionality, or its business logic.
With the product outcomes defined and the approach more clear, we moved on to consider our implementation alternatives.
Implementation Alternatives
Laravel Blade Templates vs. React
The onboarding pages were originally built with PHP Laravel’s blade templates. These templates let you reuse snippets of HTML throughout your app, which makes it really easy to build and maintain your app’s frontend. Keeping these templates was desirable because we would have a single codebase for both desktop and mobile experiences.
On the other hand, for rich data-driven UIs, blade template coding can become challenging and harder to maintain. Because of that, over the last several years we have been building new front-end features in React. So, here we also considered taking this opportunity to port our onboarding pages to React, which would give us cleaner code, more visibility into state changes, more control over the template’s calls, and would be easier to maintain going forward.
We decided to revisit the React port at a later time when we’ll want to re-design the mobile onboarding process (i.e. change the flow and the steps we take the users through).
Programmatic Styling vs. Media Queries
Having determined to stick with our existing blade templates, our next decision was how to apply the mobile styles. We considered adding business logic to parse the user agent (snippet below) to tell us when the user is on a mobile device.
$ua_parser = App::make(UAParser::class);
$browser = $ua_parser->parse($user_agent)->getBrowser()->getFamily()The logic would give us flexibility to add styles by device manufacturer or even manufacturer model — for example, applying different styles for an iPhone X vs. an iPhone 8 vs. a Pixel 2 XL. This path was appealing at first because we already use a library for user agent parsing and the implementation would only add an additional few lines. However, even a small code addition can create headaches and more work later on: one has to learn where in the code base we determine the user agent, and to know what flows the code affects. In the end, we deemed this approach as not suitable for the quick-win phase.
The other option we considered was to use media queries. Media query syntax works by specifying a condition or conditions for one or more css properties. For example,
@media only screen and (max-width: 479px) {
// css properties}
applies the properties inside the media query for screens with width less than 479 pixels.
Media queries can simplify the styling process because you can set a breakpoint, and then manually verify the styling through a combination of a device emulator in the browser and actual mobile devices.
After considering our options, we decided to use media queries because of the estimated faster implementation time and expected lower maintenance cost.
Implementation: Using Media Queries
Now that we had decided our technical approach, our goal was to get the mobile-optimized onboarding out to users as quickly as possible.
Determining CSS property browser support
We reviewed the codebase for how we used media queries for mobile devices, and in the past, we have used device-pixel-ratio in combination with max-width. The code was several years old, so we used the handy caniuse.com to confirm that device-pixel-ratio was a property to include.
We found that device-pixel-ratio was non-standard CSS, which we want to avoid so we don’t accidentally ship broken CSS to our users.
Min-resolution was the standard property to use, and after some research, we determined that including a min-resolution for both dpi (dots per inch) and dppx (dots per pixel unit) would create a mobile-friendly display for our users.
@media
only screen and (min-resolution: 192dpi) and (max-width: 1000px),
only screen and (min-resolution: 2dppx) and (max-width: 1000px),
only screen and (max-width: 479px) { // css properties
}
Add *-mobile classes to html
We added *-mobile classes to our html elements to make it easier for future developers to understand the source of the mobile styling.
let step9HTML = `
<div class="tour-header tour-next-steps tour-next-steps-mobile clearfix">
<a href="#" class="tour-finish tour-close"><i class="icon-cross"></i></a>
<h2 class="tour-heading next-steps-mobile">
<small>Nice Work!</small>
Now you're ready to head off into the wild!
</h2>+
<div class="pull-left text-center" style="margin-right: 30px;">For example, we added a class next-steps-mobile to our h2 heading so a future developer could more easily search our codebase for the styling of that element.
Overwrite Desktop Styles for Mobile
After adding the mobile classes to our html, we opened our browser, turned on Chrome’s device emulator to approximate a mobile device view, and then we used Chrome’s CSS Inspector to update the styling div by div to make the tour mobile-friendly.
First, we updated the modal body to fill the whole screen on a mobile device.
if (!isDesktopTour) {
$('.jTour_box').attr('style', 'left: 0; top: 0; padding: 0;');
}We overwrote a number of desktop styles, for example, by setting the top, left, padding, and border-radius values to 0.
We next proceeded div by div, updating the styles to make it mobile friendly. For example, the headline at the top of the modal needed to move into the top left of the div and we need to position it under the tailwind logo, rather than to the right as it is now. The margin and padding changes helped us move the headline into position, and the font attributes made the headline the correct size.
// When a user goes through onboarding on a mobile device, we add a mobile-specific step and change the styling
if (!isDesktopTour) {
$('.jTour_content').attr('style', 'border-radius: 0; height: 100%; width: 100%; position: fixed; overflow: scroll;');And we updated the css properties in our .scss stylesheets, too:
div.jTour_content {
.tour-header.tour-next-steps.tour-next-steps-mobile {
width: inherit;
margin: 0;
padding: 0; .tour-finish.tour-close {
font-size: 24px;
} h2.tour-heading.next-steps-mobile {
max-width: 770px;
font-size: 24px;
font-weight: bold;
margin: 50px;
padding: 0;
background-size: 20px; small {
padding-left: 25px;
font-size: 20px;
font-weight: 500;
}
}// …}
After we updated each div, our onboarding looked much more mobile-friendly.
As a final step, we verified the styling worked on actual iPhones and Android devices, and confirmed the desktop view remained unchanged.
Next Steps
With the onboarding screen updated for mobile devices, we’ll monitor conversion rates for the new screens and determine what the next steps are to continue to improve our onboarding for mobile devices.
Conclusions
This experience was a helpful reminder that projects exist within a user and business context. While porting our years-old Laravel blade templates to React would have simplified our code base and made it more maintainable in the long-run, the development time required to do so made a quick win more impactful. Media queries can breathe life into old code and increase the value of your product with a low amount of effort.
Looking ahead, while a one-off use of media queries to fix a glaring problem can be useful, building in mobile as a first-class experience within a company is a much higher-level of investment. We’ll have to continue our conversations with the Product, Design, Engineering, Marketing, and Customer Success teams to navigate what raising the priority of mobile looks like for each department.
