Drupal camp atlanta 2013 mobile first


Published on

Presentation slides (with notes) from DrupalCamp Atlanta 2013 -- Turning your site into a mobile-first site.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Drupal camp atlanta 2013 mobile first

  1. 1. Turning your site into a mobile-first site Tobby Hagler, Phase2 DrupalCamp Atlanta October 19, 2013 #DCATL Thursday, October 24, 13
  2. 2. Mobile-first? Thursday, October 24, 13 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.
  3. 3. Top-down vs. Mobile-first Top-down takes a large screen display and adds code to adapt it to smaller and smaller screens. Thursday, October 24, 13 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.
  4. 4. Top-down vs. Mobile-first Mobile-first starts with a small screen display and adds more to it for increasingly larger displays. Thursday, October 24, 13 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.
  5. 5. Scenarios Thursday, October 24, 13 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.
  6. 6. Possible scenarios • Building a new site Thursday, October 24, 13 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.
  7. 7. Possible scenarios • Building a new site • Mobile-enable an existing site Thursday, October 24, 13 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.
  8. 8. Possible scenarios • Building a new site • Mobile-enable an existing site • Consolidating multiple sites (separate mobile site) Thursday, October 24, 13 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.
  9. 9. Possible scenarios • Building a new site • Mobile-enable an existing site • Consolidating multiple sites (separate mobile site) • Need for a standalone mobile app Thursday, October 24, 13 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.
  10. 10. Four options for mobile-first Thursday, October 24, 13
  11. 11. Four options for mobile-first • Responsive theming • Respond to the display port of the device being used • Hide or rearrange content based on breakpoints Thursday, October 24, 13 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.
  12. 12. Thursday, October 24, 13 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.
  13. 13. Thursday, October 24, 13 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.
  14. 14. Thursday, October 24, 13 Morris.com is a wide site, and has a ton of carousels, accordions, and other desktop-specific features. This is based on Omega 3.
  15. 15. Thursday, October 24, 13 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.
  16. 16. Thursday, October 24, 13 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.
  17. 17. Four options for mobile-first • Responsive theming • 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) Thursday, October 24, 13 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).
  18. 18. Thursday, October 24, 13 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.
  19. 19. Thursday, October 24, 13 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.).
  20. 20. Four options for mobile-first • Responsive theming • Mobile theme and device detection • Separate site • Multisite instance • Allows for mobile-tailored content • Worst-case option Thursday, October 24, 13 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.
  21. 21. Four options for mobile-first • Responsive theming • Mobile theme and device detection • Separate site • Mobile apps • CMS only supplies basic content Thursday, October 24, 13 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.
  22. 22. Photo Credit: Catharine McNally Thursday, October 24, 13 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.
  23. 23. 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 Thursday, October 24, 13
  24. 24. Responsive theming Thursday, October 24, 13 How do you make your existing site responsive?
  25. 25. 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 different CSS style rules based on devices and display ports Thursday, October 24, 13 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.
  26. 26. Twitter Bootstrap Bootstrap base theme uses Twitter Bootstrap framework LESS-based CSS framework Mature, popular responsive framework Lots of useful built-in components Thursday, October 24, 13 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.
  27. 27. Zurb Foundation Zurb Foundation is mobile-first responsive, grid-based SASS-based CSS framework Can use Rubygems for development Has MANY supporting modules Thursday, October 24, 13 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
  28. 28. 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 Thursday, October 24, 13 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.
  29. 29. Custom theme Can be a burden or a boon Can use any grid framework, choose between SASS or LESS No cruft or unwanted features Thursday, October 24, 13 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.
  30. 30. That’s great and all, but how does that apply to my existing Drupal site? Thursday, October 24, 13 This brings us to the the 64 thousand dollar question.
  31. 31. 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 Thursday, October 24, 13 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...?)
  32. 32. 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 Thursday, October 24, 13 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).
  33. 33. theme.info Thursday, October 24, 13 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.
  34. 34. Block table Thursday, October 24, 13 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.
  35. 35. Context Thursday, October 24, 13 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.)
  36. 36. Mobile theme and device detection Thursday, October 24, 13 But what if we want to just do a separate mobile theme?
  37. 37. 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 Thursday, October 24, 13 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.
  38. 38. 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 Thursday, October 24, 13 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.
  39. 39. Simple web environment Thursday, October 24, 13 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).
  40. 40. 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; Thursday, October 24, 13 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).
  41. 41. hook_init example Thursday, October 24, 13 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.
  42. 42. Separate sites and multisites Thursday, October 24, 13
  43. 43. 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 Thursday, October 24, 13 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.
  44. 44. Source: XKCD Thursday, October 24, 13 Here’s a good illustration of that scenario. (wait to let them read; get a drink or something)
  45. 45. Mobile app support Thursday, October 24, 13
  46. 46. 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 Thursday, October 24, 13 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).
  47. 47. 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 Thursday, October 24, 13 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).
  48. 48. Final thoughts Thursday, October 24, 13
  49. 49. 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. Thursday, October 24, 13 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.
  50. 50. Varnish configs Thursday, October 24, 13 Just do a google search for “varnish mobile redirect” and you’ll find some really good, simple 4-steps Varnish configs.
  51. 51. 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 Thursday, October 24, 13 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.
  52. 52. 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 Thursday, October 24, 13
  53. 53. Questions? Thursday, October 24, 13 Are there any questions? Is there anything you want to go into more detail?
  54. 54. Tobby Hagler Software Architect Email: thagler@phase2technology.com Twitter: @thagler Thursday, October 24, 13
  55. 55. PHASE2TECHNOLOGY.COM Thursday, October 24, 13