drupal camp atlanta 2013 mobile first

Turning your site into a mobile-first site

Tobby Hagler, Phase2

DrupalCamp AtlantaOctober 19, 2013

#DCATL

Thursday, October 24, 13

Mobile-first?


What do I mean by mobile-first? Not mobile-only.Simply, it means putting mobile users first rather than an after thought. This doesn’t demote desktop users at all; instead, it just means that we start with mobile and expand outwards to meet the needs of additional users.

Top-down vs. Mobile-firstTop-down takes a large screen display and adds code to adapt it to

smaller and smaller screens.


Problem with top-down is heavier pages still get loaded on mobile devices, and THEN pieces are removed.UX studies show that users expect mobile sites to load MUCH faster than desktop sites.Most of the time, you’re overloading those little phones/devices with too much stuff.

Top-down vs. Mobile-firstMobile-first starts with a small screen display and adds more to it

for increasingly larger displays.


The mobile-first lets you start with something size appropriate for mobile. You can add more to it for larger displays.Display isn’t the only factor, but it’s an obvious starting point. You also start with more focused content, and add to it for larger displays/devices.

Scenarios


We’re going to talk about different scenarios. Since this is a site building session, and not a coding track or theming track, we’re going to discuss the different site building scenarios where mobile-first development will come into play.

Possible scenarios

• Building a new site


Starting from scratch is the easiest scenario. Pretty much anything we’ll talk about here is fair game.The same applies for redesigning a site where you get to completely rebuild a new site and import your content.

Possible scenarios


• Mobile-enable an existing site


More difficult, but still pretty much everything will apply.In fact, this is the most common scenario, so we’ll spend more time talking about this one.

Possible scenarios



• Consolidating multiple sites (separate mobile site)


Say you have 2 sites (desktop and mobile); That’s a messy situation, and it’s good that you’re getting rid of that mess.You’re looking at a lot of work, but it should be worth it.

Possible scenarios



• Consolidating multiple sites (separate mobile site)

• Need for a standalone mobile app


We won’t spend a lot of time on this (mobile apps are another session or even another track entirely), but we’ll talk about supporting them with your CMS.

Four options formobile-first


Four options for mobile-first

• Responsive theming

• Respond to the display port of the device being used

• Hide or rearrange content based on breakpoints


Using the right framework, this is going to be your best bet.This will work for our first two scenarios. Defined: Optimized display of a site where it adapts (responds) to the display port to give the most optimized version of that display. Wide for desktop, shrinks for mobile, and can hide/rearrange content ad hoc.


An example:Pac-12.com has a very image heavy, video heavy site. There’s lots of information packed on the page, including scrolling scoreboards, video players, TV listings, etc.Theme is built with Zurb Foundation 4 using RubyGems.


Pac-12 on a phone. While it has the same content, it’s much more tailored to vertical scrolling and minimizing things like the scoreboard and schedules. Scores can be scanned through by swiping, and using frameworks like Foundation 4 and Hammer.js, the mobile experience feels more native (swiping, dragging, etc). The site uses a lot of off-canvas content; the rails (Panels panes) that would normally appear together are broken up into sections that can be swiped through. This is especially apparent on Events pages.


Morris.com is a wide site, and has a ton of carousels, accordions, and other desktop-specific features. This is based on Omega 3.


At narrower displays (old laptops, iPads, etc.), the site still plays nice in the narrower width. Carousels are still present, but display fewer items at at time.


Morris.com on a phone or other small device is very minimalist. Huge promo areas disappear entirely, and only what is really vital to get across is present.



• Mobile theme and device detection

• example.com and m.example.com

• Requires upfront device detection

• May appear as a separate site (but shouldn’t be)


To do this right (I’ll explain about caching considerations and other issues later), you’ll need to use different domains (subdomains are fine).You’ll need to do device detection.Device or user-agent detection and subsequent theme-switching should EVER happen on origin (Drupal is origin in most cases).


Here’s the Thompson Reuters Olympics site on a desktop. Each page on the desktop is full of content; it even uses auto-lazy-loading. If you scroll to the bottom, more content appears automatically. This works well on desktop versions, but not so much with mobile devices.The design is very tiered (big hero area, medium sized section then list of content links); not very grid-friendly.


Here’s the Thomson Reuters mobile site. It’s a complete different appearance. However, URLs and paths are the same, and those paths show the exact same primary content. But this mobile theme (it’s a different theme entirely) shows different blocks, uses different Contexts, minimized content, far fewer images, etc. The mobile theme is tailored to mobile devices, and uses a lot more swipe and native iOS functionality, and the document weight is much smaller (so it loads faster, etc.).




• Separate site

• Multisite instance

• Allows for mobile-tailored content

• Worst-case option


Almost like the separate mobile theme option, still requires device detection, but might actually use different subset of content.Just like regular multisite instances, content and site configs are most likely unaware of each other.Plus side is that you can have mobile-specific content.




• Separate site

• Mobile apps

• CMS only supplies basic content


Mobile apps aren’t technical mobile-first. But, they *are* optimized specifically for that mobile device, so that sorta counts.Plus, they tend to feature content tailored towards a mobile audience.App development is outside of your primary CMS, but Drupal can still feed it content, as a centralized CMS should.

Photo Credit: Catharine McNally


Pac-12 has a native iOS app that allows users to watch live or replay games, watch any of their seven networks, and follow certain schools or teams. One of the main requirements was to support the iOS app with custom XML feeds. Their CMS is the database of record for ALL Pac-12 content, including 3rd party score systems, their TV ticker, and apps like this one.TR had an app too, but it’s no longer available, so no screenshot.

Mobile app support

• Data is usually fetched, so Drupal pages can be static and cached

• Usually done with RSS or JSON data

• Can be supplied by Views RSS, Views data export and Views data export - JSON support modules

• Services module

• Set up an interactive/secure system for supplying data


Responsive theming


How do you make your existing site responsive?

Responsive themingFluid grids allows page elements to be sized to be in relative units

Uses breakpoints to determine drastic shifts in page layout

Flexible images are sized relatively to resize and prevent overflow

Media queries allow the page to use different CSS style rules based

on devices and display ports


What is it?Caveat about media queries: If you do it wrong, you’ll triple the size of your CSS file. This is a bad. But if done correctly, you can load only the CSS you need, which is a really good thing.

Twitter Bootstrap

Bootstrap base theme uses Twitter

Bootstrap framework

LESS-based CSS framework

Mature, popular responsive framework

Lots of useful built-in components


Let’s take a look at a couple of Drupal base themes for doing responsive.Bootstrap is built by Twitter, one of the most popular responsive frameworks now.Has a lot of extra features that come with it that work well on mobile and desktop.

Zurb Foundation

Zurb Foundation is mobile-first

responsive, grid-based

SASS-based CSS framework

Can use Rubygems for development

Has MANY supporting modules


Zurb does a really good job of being mobile first. Has a lot of CSS selectors to hide content based on display (hide that extraneous right rail, etc).Foundation allows for off-canvas content. Basically, all your rails are off-canvas, but just a swipe away.Complex to set up a Drupal theme with Rubygems, but you can customize, pick-and-choose which elements for better optimization.RubyGems.org

Omega

One of the most popular Drupal themes

Can use SASS and Gems

Can be configured entirely in admin UI

Omega Tools module assists with


Allows for a number of different grid systems (HTML5/960, some others).Introduces concept of Zones to organize regions into breakpoints.Omega 3 and 4 have seen differences of opinions for implementations (4 uses Panels, 3 needs Omega Tools).Has Excellent documentation.

Custom theme

Can be a burden or a boon

Can use any grid framework, choose

between SASS or LESS

No cruft or unwanted features


Can be as fluid or static as you like. Use whatever framework components you want.You’ll need to have or be a disciplined theme developer. You don’t want to be all loosey-goosey with development of your theme. In fact, that might be what got you into this mess in the first place, needing to replace your current theme with a mobile-friendly version.Upside: lets you do anything you want. Downside: lets you do anything you want.

That’s great and all, but how does that

apply to my existing Drupal site?


This brings us to the the 64 thousand dollar question.

Replacing your theme

Walk through the steps of replacing your theme with a like-for-like

responsive theme

Hope you’ve got a maintainable site

Rip off the bandaid


Take the time to revisit your theme. We’ll assume a mostly like-for-like theme replacement, but that doesn’t mean we can make some enhancements or tweaks along the way.Hopefully, your site is maintainable enough that, when replacing the theme, the site doesn’t completely fall apart. You’ll need block placements, etc. but any custom modules shouldn’t rely heavily on the theme. (what if they do...?)

Side-by-side theme replacement

• You’ll be scraping your existing theme

• Create audit of what controls UI elements (modules, theme template.php, etc.)

• Create a new theme

• Must keep the same block regions

• Revisit your custom Panels layouts


Do you have theme helper modules, or did you (smartly) place theme-specific overrides in template.php?Keeping block regions the same is essential for a like-for-like replacement.Any custom Panels layouts might need to be responsified. Making them fluid width is easy, but making things stack in different displays gets tricky. You won’t have to change your Panel configs/content if Drupal thinks the layout hasn’t changed (b/c we’re only modifying the .tpl.php).

theme.info


Here are two theme .info files with the same subset of regions. The new responsive theme has additional regions b/c we added some new things, but all the old regions are still present.

Block table


An essential part of the process of switching to the responsive layout is we duplicate all the blocks in the block table to the new theme. This preserved practically all content in place. This was handled through an update_N hook.

Context


If you use the Context module for block placement, you’re in luck. Most of your contexts will not change, unless you *specifically* do something with the theme (theme switching, etc.)

Mobile theme and device detection


But what if we want to just do a separate mobile theme?

Device detection and theming

• You’ll be maintaining different themes

• Can use different block regions

• Context module allows you to place content based on theme/Domain

• Requires a domain-aware theme switcher

• Device detection happens OUTSIDE of Drupal


Since your mobile theme is different, there’s nothing that says you *have* to use the same regions or block layout. In fact, you’ll want to have very few regions.You’ll want to use domain-based theme switching within Drupal. Don’t even think about using device or browser detection within Drupal or Apache.

Device detection

• Never ever ever do device or browser detection in Drupal

• Origin must remain unaware for whom it’s serving content

• Theme switching based on domain is fine, since the cached result will always be the same for that domain

• Use Varnish or Nginx to handle detection

• Caching is key


We’ll start with device detection.Don’t do device detection on origin. If you have any caching at all, you’ll introduce a chance that you’ll cache the page with an incorrect theme.Drupal page caching won’t be device-specific, so it can also cache the wrong thing for mobile and desktop users.

Simple web environment


Let’s look at a basic web environment setup. A mobile user requests a page from the domain; Varnish is what answers, and looks at the device. If it’s a mobile device, it prepends “m.” to the domain. It doesn’t have a cached page, so it hits the load balancer, which selects one of the web servers. Drupal responds with the page, Varnish caches that page for that domain+path, and sends it to the user.If Drupal was doing the detection, a mobile user gets there first, and Varnish would cache the mobile page and send it to all users (desktop included).

Theme switching options

• Use something like PURL or Context to switch the theme

• Use m.example.com (or similar) for your mobile site

• Make sure vhost configs use ServerAlias with m.

• Can use custom code in hook_init() to switch the theme

• global $custom_theme;


You can use whatever you feel comfortable with to switch the theme. Context will let you set up something based on domain to change the theme. Purl will let you do the same if you set it up with the proper reactions. Custom code is really easy, so even your junior devs could throw something together to switch themes depending on the domain. If you use m. as a prefix, then that can apply to ANY domain (dev, integration, staging, production) without needing to hardcode the full domain. Hardocoding has BAD(TM).

hook_init example


In fact, here’s that entire hook for you.

Technically, this hook result does get cached. If there’s no page cache or varnish cache for the m. domain version of this page, this hook is called and will deliver the correct theme and page contents. Caches are aware of the full domain, but NOT the device or user agent, so that’s why we use the m. subdomain to distinguish.

Separate sitesand multisites


Separate sites

• Greatest potential for issues or problems

• Multisite means the same CMS code, but different content

• Mobile users will likely get incongruous results

• Using external services and redirecting to different servers


The biggest problem with using multisite or a completely different site is that the same path will give different content (or worse, no content at all). Consider: a desktop user shares a page with Twitter or Facebook or email. The recipient is a mobile user and clicks the link. Boom. That page’s path doesn’t exist on the mobile site, so the mobile user is redirected to the front page or something. What a letdown.

Source: XKCD


Here’s a good illustration of that scenario.(wait to let them read; get a drink or something)

Mobile app support


Mobile apps for your site

• Pros

• Most tailored and should be the most performant

• Apps require least amount of maintenance

• Cons

• Specific to device (iOS, Droid, Blackberry, Windows)

• People don’t download apps unless there’s a HUGE benefit


This should be the best of breed for a specific mobile device, and nothing really changes except content.

Unfortunately, you have to create multiple apps for multiple OSes to reach your audience. versus a responsive theme where any user can get to it (just might not have the same quality experience).

Mobile app data origin

• Services module

• Create a REST interface via UI to support data needs

• Views

• Views RSS

• Views Data Export and JSON Support modules


You want a centralized CMS to be the content database of record for all user experiences. So your site will need to support the data transfer to these mobile apps.

Using the Services module, you can create a REST interface for supplying data to your apps.Can use basic or token-based authentication to restrict access to content for apps or even specific app users.

Views and all the millions of Views-based modules will let you do a ton of custom data transports (XML, RSS, JSON).

Final thoughts


Detection and external caching

Varnish, Memcache, and CDNs are in between your users and your

Drupal CMS.

Don’t do any device detection and redirection after these front-end

caching systems.

Varnish can detect, then redirect to the m. domain, then cache;

Drupal can’t.


Users aren’t interacting with Drupal. They’re interacting with the cache layers that front-end your Drupal CMS. Don’t do device detection and the subsequent redirects anywhere *after* the full-page caching layer.

Many CDNs (Cloudfront, Akamai, etc.) have mobile device and redirection as part of their standard offers.

Drupal can’t do detection and caching, at least not effectively.

Varnish configs


Just do a google search for “varnish mobile redirect” and you’ll find some really good, simple 4-steps Varnish configs.

Testing

Testing is tougher with multiple breakpoints

Emulation will only get you 90% (see Sturgeon’s Revelation)

BrowserStack.com, PerfectoMobile.com, SauceLabs.com,

TestiPhone.com


Testing against multiple breakpoints multiplies your testing. Even with a separate mobile them, you double the testing that must be done.Make sure you have REAL mobile devices. Emulation works for the most part, but some things like HTML5 video and certain jquery plugins act wildly different in a real device than in an emulator.

DrupalCamp Atlanta

• Up next in this room is Kevin Basarab’s session on Git Flow for Daily Use

• I’ll be doing a BoF session right after this on Dungeons & Dragons & Drupal (data management and Field API)

• Don’t forget the after party at 5:30 at the Renaissance Waverly Hotel


Questions?


Are there any questions? Is there anything you want to go into more detail?

Software Architect

Email: [email protected]

Tobby Hagler

Twitter: @thagler


mailto:[email protected]




PHASE2TECHNOLOGY.COM


drupal camp atlanta 2013 mobile first

Technology