Drupal camp atlanta 2013 mobile first

Turning your site into a
mobile-first site
Tobby Hagler, Phase2
DrupalCamp Atlanta
October 19, 2013
#DCATL

Thursday, October 24, 13

Mobile-first?


What do I mean by mobile-ﬁrst? Not mobile-only.
Simply, it means putting mobile users ﬁrst 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-first
Top-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-first
Mobile-first starts with a small screen display and adds more to it
for increasingly larger displays.


The mobile-ﬁrst 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-ﬁrst 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 for
mobile-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 ﬁrst two scenarios.
Deﬁned: 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-speciﬁc 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 ﬁne).
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 conﬁgs are most likely unaware of each other.
Plus side is that you can have mobile-speciﬁc content.

• Separate site
• Mobile apps
• CMS only supplies basic content


Mobile apps aren’t technical mobile-ﬁrst. But, they *are* optimized speciﬁcally 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 theming
Fluid 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 diﬀerent 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 ﬁle. 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 ﬁrst. 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 ﬂuid 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 ﬁrst 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 oﬀ 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 ﬁles 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 *speciﬁcally* 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 diﬀerent themes
• Can use diﬀerent 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-speciﬁc, 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 ﬁrst, 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 preﬁx,
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 sites
and multisites


Separate sites
• Greatest potential for issues or problems
• Multisite means the same CMS code, but diﬀerent
content
• Mobile users will likely get incongruous results
• Using external services and redirecting to diﬀerent
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 speciﬁc 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 speciﬁc 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 ﬁnd some really good, simple 4-steps Varnish conﬁgs.

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?

Tobby Hagler
Software Architect
Email: thagler@phase2technology.com
Twitter: @thagler


PHASE2TECHNOLOGY.COM


Drupal camp atlanta 2013 mobile first

Recomendados

Recomendados

Más contenido relacionado

Similar a Drupal camp atlanta 2013 mobile first

Similar a Drupal camp atlanta 2013 mobile first (20)

Último

Último (20)

Drupal camp atlanta 2013 mobile first