Presentation from Jan. 12, 2011 meeting of Portland (Ore.) Drupal Users Group (PDXDUG). A whirlwind tour of mobile Web topics from a Drupal 6 viewpoint. As much as I could get into a 45-minute slide deck! Whew.

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 finer points of device-specific 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://wurfl.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-wurfl.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 final 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 inefficient 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

35. 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

37. 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 Skyfire 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 Skyfire’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, Skyfire
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

48. 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 define 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 define 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
flexible 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 definitive 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 find 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. wurfl
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 Definitions
This can be read:
((is_wireless_device == TRUE) &&
(ajax_xhr_type != ‘none’) &&
(mobile_browser === ‘Safari’ ||
mobile_browser === ‘Android Webkit’))
Thursday, January 13, 2011

74. Define 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-specific 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-fledged
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-specific 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 final 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 file.
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

87. 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 definitions 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 specific 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 beefier
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