Mobile Web on Drupal!

1. The Mobile Web on Drupal! Thursday, January 13, 2011

2. Where are we going today? Mobile Web development theories and philosophies Reality check! Core tenets I like to stick to So, about Drupal...the good and the bad Digging in and putting some pieces together (CODE!) Stuff to read so you can learn more Thursday, January 13, 2011

3. How technical is this going to be? We’ll start high level (everyone) We’ll talk about strategy and device grouping (everyone/solution architects) We’ll talk about Drupal’s strengths and weaknesses and 3rd-party stuff. (everyone/somewhat technical) We’ll look at code for a hypothetical module and work with Drupal hooks and whatnot. (devs/code) We’ll talk about mobile theming strategy. (designers) I’ll recommend some books, blogs and mailing lists. (everyone) Thursday, January 13, 2011

4. Nope. This topic is huge. We won’t have time to talk about: Detailed (HTML/CSS) markup for mobile devices. The ﬁner points of device-speciﬁc support for technologies (CSS/JS/HTML5/whatever). Design and UX best practices. Testing. All of these areas are incredibly important, though! Thursday, January 13, 2011

5. By The Way This presentation is based on Drupal 6 My current feeling about D7* * Sorry Thursday, January 13, 2011

6. Leading Philosophies of Mobile Web Development Thursday, January 13, 2011

7. The “One Web” Thursday, January 13, 2011

8. One Web means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using. However, it does not mean that exactly the same information is available in exactly the same representation across all devices. The context of mobile use, device capability variations, bandwidth issues and mobile network capabilities all affect the representation... ...it is considered best practice to provide as reasonable experience as is possible given device limitations and not to exclude access from any particular class of device, except where this is necessary because of device limitations.... Errr... Thursday, January 13, 2011

9. That means... Separate mobile site or domain (e.g. m.mysite.com) is discouraged. All users should get, for the most part, the same text, features, markup, images, functionality, etc. (within reason, which you get to determine). Develop once (I do like this part). Thursday, January 13, 2011

10. Responsive Web Design (RWD) Thursday, January 13, 2011

11. RWD Using sophisticated markup and CSS techniques to make the “One Web” ideal more attainable. Using CSS Media Queries to adapt content, allowing for “One Web” success Fluid grid designs For the most part, send the same HTML markup and media (e.g. images) to everyone http://www.alistapart.com/articles/responsive-web- design/ Thursday, January 13, 2011

12. I am a CSS Media Query: <link rel="stylesheet" type="text/css" media="screen and (max-device-width: 480px)" href="shetland.css" /> Thursday, January 13, 2011

13. Progressive Enhancement Thursday, January 13, 2011

14. Progressive Enhancement Not just a mobile concern Luke W’s “Mobile First” credo is in the same family Design your baseline site for mobile, then go from there http://www.lukew.com/ff/entry.asp?933 Thursday, January 13, 2011

15. Server-Side Device Detection and Adaptation Thursday, January 13, 2011

16. Who goes there? Thursday, January 13, 2011

17. Server-Side Device Detection Based on using User Agent strings to make an educated guess at what a device is and what capabilities it has Several device libraries support this. Two of the best known are: WURFL DeviceAtlas Thursday, January 13, 2011

18. WURFL http://wurﬂ.sourceforge.net/ Maintained/moderated by Luca Passani. Exhaustive details about mobile device and client capabilities based on User Agent. Contributors have created APIs in several languages. Free and open source. Thursday, January 13, 2011

19. Let’s Look at some WURFL Capabilities Tera-WURFL Explorer http://www.tera-wurﬂ.com/explore/ Thursday, January 13, 2011

20. DeviceAtlas Licenses run from $99/yr (per server) to ... well, more. You get guaranteed updates. API is PHP, Java, .Net Analytics as well. Web site is free and a useful reference for looking up devices right quick. http://deviceatlas.com Thursday, January 13, 2011

21. Client-Side Adaptation Thursday, January 13, 2011

22. Whereas server-side detection asks “Who goes there?,” client-side adaptation allows you to say things like: Thursday, January 13, 2011

23. Oh, yeah? prove it. Thursday, January 13, 2011

24. Client-Side Adaptation Determining real client capabilities a la Modernizr Using CSS Media queries Taking delivered markup the ﬁnal mile Ensures that the client can walk the walk Thursday, January 13, 2011

25. Modernizr (A Quick Aside) Runs tests on the client Adds CSS classes to the <html> element based on what it discovers You, noble developer/themer, can: Write your CSS accordingly Use JavaScript to extend your stuff Based on what the browser can actually do http://www.modernizr.com Thursday, January 13, 2011

26. So, that all sounds lovely and clean and unicorn-shaped. Thursday, January 13, 2011

27. The Reality Thursday, January 13, 2011

28. Thursday, January 13, 2011

29. “One Web” is vague Dear Puny Human, Make one Web site such that it’s, like, the same on all devices, except, well, make sure that it is appropriately different on some devices. Don’t exclude anyone, except when “device limitations” force you to. I’ll leave deciding what a device limitation is as an exercise for the reader. Love, The W3C http://www.w3.org/TR/mobile-bp/#OneWeb Thursday, January 13, 2011

30. RWD has performance and bandwidth implications Image resizing on devices can be inefﬁcient and uses bandwidth you might not need to use. CSS media query support is fragmented and only on modern devices. For the most part, images hidden in CSS still get downloaded. We’re sending the device bytes that it is not going to use. http://www.cloudfour.com/css-media-query-for-mobile- is-fools-gold/ Thursday, January 13, 2011

31. Shoving a 153,600-pixel image at a phone that only has about 16,000 pixels of real estate to work with is like giving 4-by-8- foot sheets of plywood to a kid who wants to build a miniature birdhouse. Even if wood is cheap, it tastelessly wastes a lot of trees... —Lyza Gardner (Me) Adventures on the Mobile Web Frontier, Nov. 4, 2010 * http://www.cloudfour.com/adventures-on-the-mobile-web-frontier-wrangling- drupal-third-party-apis-and-server-oomph-into-an-enterprise-class- experience/ * Sorry about that URL; my bad Thursday, January 13, 2011

32. Server-side device detection via UA is not infallible... Who goes there? Hello, Web Server, I am a sheep! Thursday, January 13, 2011

33. Who goes there? Web Server! I am also a sheep!* *Not really a sheep. Thursday, January 13, 2011

34. Client-side enhancement can be pretty tricky if your user’s device isn’t up to it “Hi, I’m BlackBerry version 4.5. You’d be surprised at how many people at big companies still use me and love me. You cannot manipulate my DOM and my JavaScript performance is very sad. Sorry.” Thursday, January 13, 2011

36. Duct Tape Programming “Duct tape programmers are pragmatic... “A 50%-good solution that people actually have solves more problems and survives longer than a 99% solution that nobody has because it’s in your lab where you’re endlessly polishing the damn thing. “Shipping is a feature. A really important feature. Your product must have it.” —Joel Spolsky The Duct Tape Programmer, Sept. 23, 2009 Joel on Software http://www.joelonsoftware.com/items/2009/09/23.html Thursday, January 13, 2011

38. So, how do we keep our nose clean in this tragicomical environment? Staying True to a Couple of Tenets... Thursday, January 13, 2011

39. 1. Don’t send bits to a device that it won’t use Thursday, January 13, 2011

40. bits == dollars bits == waiting bits ~= processing Thursday, January 13, 2011

41. 2. The client is always right* * This one gets me in a bit of trouble Thursday, January 13, 2011

42. Remember how I said that User Agents aren’t always 100% honest and forthcoming? Or, at least, sane? Thursday, January 13, 2011

43. Whose User Agent is this? Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17 Thursday, January 13, 2011

44. A Sane Person would guess... Desktop Safari And that’s what WURFL will tell you, too Thursday, January 13, 2011

45. But It’s Skyﬁre for Android. Thursday, January 13, 2011

46. “Load web pages as either traditional Android user agent or as a desktop browser. The desktop option gives you more flexibility in accessing web sites and allows discovery of video content that might not be visible on the mobile site.” Laughing all the way to the Bank or whatever, Love, Skyfire Skyfire Web Site http://www.skyfire.com/product/android Thursday, January 13, 2011

47. What do we do?! So, the User Agent for Skyﬁre’s desktop mode is cruel and manipulative. What should we do? Me: Give them the desktop experience. They asked for it. If it sucks enough for enough people, Skyﬁre will hopefully adapt. This is not a universally-embraced opinion, to say the least. And leaves some folks out in the cold. What do you think? Thursday, January 13, 2011

49. Let’s make something that works Thursday, January 13, 2011

50. Device Classes A device class is a collection of attributes and capabilities that deﬁne a group of mobile devices. There are no industry-standard device classes, but there are some rules of thumb and generalizations that can help you deﬁne your device classes. We usually end up with about 3-5 major device classes per project. Thursday, January 13, 2011

51. Device Classes: Why? Keeps you sane. Helps you focus on your target users. Gives you a context to think within when designing UX and IA for your site or app. Roughly, device class == context Thursday, January 13, 2011

52. Some Advice about Device Classes Don’t get too distracted by pixel dimensions. Choose your “baseline” class carefully. Who’s your main audience? You’ve heard this nag before,: don’t assume everyone has an iPhone or Android. device class != theme/layout Thursday, January 13, 2011

53. Example Device Classes Device Class Criteria Notes • Webkit-based browser • Minimum resolution 320x480 “Mobile Webkit” • Sophisticated CSS/JS/XHR “There is no Webkit on mobile”. —Peter-Paul Koch, QuirksMode support • Resolution 240-320px • Robust XHTML support Don’t neglect this class! Smartphones • Reasonable AJAX and JS BB5, Win 6.x, etc. • Quite possibly less awesome CSS • Resolution 128-240px • HTML support a.k.a. feature Dumbphones • Cookie/HTTPs support • Limited CSS support phones Thursday, January 13, 2011

54. And Then you draw the line somewhere e.g. “For a mobile device to be successful using this Web-based application, it must support images, cookies and HTTPs, and have a resolution of at least 128px.” Thursday, January 13, 2011

55. And the rest, you gently kick to the curb. Gently. Thursday, January 13, 2011

56. OK, Here comes the Drupal part... Thursday, January 13, 2011

57. First, some good news Thursday, January 13, 2011

58. Drupal is great because: We can easily extend it by writing modules or using those that others have kindly already written The theming stack and hook architecture is ﬂexible enough that we can override almost anything we need to Sub-theming gives us even more power here There are already some third-party modules that can help us Your site may already be running on it. Thursday, January 13, 2011

59. Now some bad news... Thursday, January 13, 2011

60. Drupal makes kittens cry because: Drupal 6 doesn’t have a deﬁnitive hook for managing CSS and JS Theme inheritance can only go so far WYSIWTF There is no simple, 3rd-party solution you can just drop into place. I bet there will be in the future. But. Thursday, January 13, 2011

61. WYSIWTF How the heck can your site’s editors create content that will look right on all devices? CKEditor can’t save your butt here Don’t blame Drupal per se: No one has nailed this one I don’t have a good answer for you here...yet Thursday, January 13, 2011

62. Everything you learn today is obsolete tomorrow Case in point: This just in! http://drupal.org/project/tinysrc Thursday, January 13, 2011

63. Modules: Theirs (3rd-party) Thursday, January 13, 2011

64. mobile tools A lot of stuff in this module, and it can integrate with WURFL or BrowserCap. These are your device classes. Take ‘em or leave ‘em. function mobile_tools_device_groups() { return array('iphone', 'ipod', 'android', 'opera mini', 'blackberry'); } “The Mobile Tools module currently doesn't provide information on the device characteristics such as screen size, browser capabilities, javascript support, etc ...” (from the project page) Generally, I ﬁnd that I want a bit more control than this module gives me, but it could serve as a great starting point. Thursday, January 13, 2011

65. wurﬂ Uses PHP API Recent rewrite...not backwards compatible so much. UGH. Doesn’t expose everything from the PHP API, but does encapsulate some. Multiple sites? You’ll be replicating the WURFL data. Install process is a bit painful. But, overall, a good place to start, and we’ll be using it in our examples tonight. Thursday, January 13, 2011

66. Putting it Together Thursday, January 13, 2011

67. Code! Alert! Thursday, January 13, 2011

68. We are going to... Use and depend on the wurfl module Create our own module Detect Devices Switch Themes Create and implement a Device Class Definition hook Define some device classes Test devices against defined device classes Create some mobile themes Add some useful code to our themes to strip certain JS and CSS Thursday, January 13, 2011

69. Disclaimer! OMG! Don’t take this code too literally. It’s meant as: A. A stepping-off point and B. Pseudo-code It is based on real code (which has been tested) but has not been tested in its current form. You don’t have to implement it this way! These are just rough ideas for yah. Thursday, January 13, 2011

70. Our Module: mobile_web (structure) Thursday, January 13, 2011

71. First Pass at the hook_init() Thursday, January 13, 2011

72. Create a Hook for Device Classes Thursday, January 13, 2011

73. Device Class Deﬁnitions This can be read: ((is_wireless_device == TRUE) && (ajax_xhr_type != ‘none’) && (mobile_browser === ‘Safari’ || mobile_browser === ‘Android Webkit’)) Thursday, January 13, 2011

74. Deﬁne some Device Classes In the interest of brevity, only two device classes here and “Webkit on Mobile” is over-simplified. Thursday, January 13, 2011

75. Second Pass at hook_init() Thursday, January 13, 2011

76. Matching Device Classes Get the code for mobile_web_device_match(), if you want it, at http://pastebin.com/jtufBq38 Returns TRUE if the current set of device class capabilities match the current user’s device Thursday, January 13, 2011

77. Themes! Thursday, January 13, 2011

78. Creating some Themes Consider your DOCTYPE Familiarize yourself with what’s supported in XHTML- MP Drupal-speciﬁc gotcha: You’ll need to override theme(‘table’) if you want your code to validate in XHTML-MP 1.2 (<thead> is invalid). You can mostly disregard WML these days. I sub-theme quite a bit (http://drupal.org/node/ 225125) Thursday, January 13, 2011

79. Might I suggest? I’m a big fan of sub-themes. Thursday, January 13, 2011

80. Another Variant For hybrid desktop/mobile sites. I also advise using the admin_theme module such that the admin interface stays sane. Thursday, January 13, 2011

81. Don’t Panic! You’re not going to have to implement full-ﬂedged themes for all of your devices! Our device class themes usually contain: Additional CSS for that device class (in addition to default mobile or overrides) Device-class-speciﬁc JS Overrides for templates on an as-needed basis. Thursday, January 13, 2011

82. My CSS and JS are Out of Control! In D6, theme has ﬁnal say-so of what JS and CSS get delivered First call to drupal_add_js() always adds jQuery and drupal.js I’ll show you how to get around this, but it is ugly A brief D7 interlude: This is remedied in D7 with two new alter hooks for CSS and JS Thursday, January 13, 2011

83. Control your JS and CSS You’ll have to do this in a theme’s template.php ﬁle. If you have themes subclassed from a single mobile theme, you can put this in one place (the top-level mobile theme). I do it from a hook_preprocess_page(&$vars) implementation. Thursday, January 13, 2011

84. Stripping JS and CSS The premise of the code is: Declare some JS (or CSS) that is allowed for the mobile theme at hand. Iterate through the JS in the ‘scripts’ var (all current JS/CSS set up to be in the page) and make sure each entry is “allowed.” Remove those that are not. For JS, if only drupal.js and jQuery.js are left at the end, remove those, too. Re-set the ‘scripts’ var by calling drupal_get_js() with the updated array of JS (or the same concept with CSS). Thursday, January 13, 2011

85. Simplest Way to strip Extra JS... The same approach works for CSS (the ‘styles’ variable). Thursday, January 13, 2011

86. Sorry. That was a bit fugly. Thursday, January 13, 2011

88. Where to from here? Use the device class to help determine how theme functions behave, both on the theme level and module levels. Use the imagecache module to serve appropriately-sized images to different device classes (or maybe tinysrc!). Expand device class deﬁnitions to add any sort of arbitrary data you’d like. Keep a WURFL object (or other data structure representing the WURFL attributes) available; you can ask about a device’s speciﬁc capabilities anywhere in your code. Thursday, January 13, 2011

89. Exercises for the Reader Some things we’ve done to make this stuff cooler: Build an admin interface for managing allowed CSS/ JS and other goodies. Build logging to capture User Agents and their device class results (might not want to leave this on in production!) Consider running a Tera-WURFL setup. Thursday, January 13, 2011

90. Where are things heading? More client-based stuff as mobile browsers get beeﬁer More 3rd-party Drupal support This era is kind of like the JavaScript browser insanity of the late 90s Thursday, January 13, 2011

91. Resources and Further Reading Thursday, January 13, 2011

92. Read these books and blogs Programming the Mobile Web Maximiliano Firtman (O’Reilly) Beginning Smartphone Web Development Gail Rahn Frederick/Rajesh Lal (Apress) Because JS is Important for mobile: High Performance JavaScript Nicholas C. Zakas (O’Reilly) JavaScript: The Good Parts Douglas Crockford (O’Reilly) Thursday, January 13, 2011

93. Read these books and blogs QuirksBlog by PPK (Peter-Paul Koch) http://www.quirksmode.org/blog/ Andrea Trasatti’s tech notes and more http://blog.trasatti.it/ Communities Dominate Brands (Tomi Ahonen) http://communities-dominate.blogs.com/brands/ Luke Wroblewski aka @lukew http://www.lukew.com/ff/ Thursday, January 13, 2011

94. Super Useful Groups & Mailing Lists mobile-web Yahoo! Group http://tech.groups.yahoo.com/group/mobile-web An active, useful list wmlprogramming Yahoo! Group http://tech.groups.yahoo.com/group/wmlprogramming Despite the misleading name, this mailing list focuses on WURFL. Expect a rollicking time. Mobile Portland http://mobileportland.com/ http://groups.google.com/group/mobile-portland Meets the fourth Monday of each month Thursday, January 13, 2011

95. Who Am I? Lyza Danger Gardner co-founder, mobile Web developer type of person Cloud Four http://www.cloudfour.com http://www.lyza.com @lyzadanger Thursday, January 13, 2011

Mobile Web on Drupal!

Recomendados

Recomendados

Más contenido relacionado

Similar a Mobile Web on Drupal!

Similar a Mobile Web on Drupal! (20)

Último

Último (20)

Mobile Web on Drupal!