mobile web on drupal!

The Mobile Web on Drupal!

Thursday, January 13, 2011

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


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)


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!


By The Way

This presentation is based on Drupal 6

My current feeling about D7*

* SorryThursday, January 13, 2011

Leading Philosophies of Mobile Web Development


The “One Web”


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


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


Responsive Web Design (RWD)


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/






Progressive Enhancement


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




Server-Side Device Detection and Adaptation


Who goes there?


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


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.


http://wurfl.sourceforge.net

http://wurfl.sourceforge.net

Let’s Look at some WURFL Capabilities

Tera-WURFL Explorer

http://www.tera-wurfl.com/explore/




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




Client-Side Adaptation


Whereas server-side detection asks “Who goes there?,” client-side adaptation allows you to say things like:


Oh, yeah? prove it.


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


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




So, that all sounds lovely and clean and unicorn-shaped.


The Reality


Love,The W3C

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.

http://www.w3.org/TR/mobile-bp/#OneWeb

“One Web” is vague


http://www.w3.org/TR/mobile-bp/#

http://www.w3.org/TR/mobile-bp/#

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/






http://www.cloudfour.com/adventures-on-the-mobile-web-frontier-wrangling-drupal-third-party-apis-and-server-oomph-into-an-enterprise-class-

experience/

Adventures on the Mobile Web Frontier, Nov. 4, 2010

—Lyza Gardner (Me)

*Sorry about that URL; my bad*

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








Hello, Web Server, I am a sheep!

Server-side device detection via UA is not infallible...

Who goes there?


Web Server! I am also a sheep!*

*Not really a sheep.

Who goes there?


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


The Duct Tape Programmer, Sept. 23, 2009Joel on Software

—Joel Spolsky

“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.”

http://www.joelonsoftware.com/items/2009/09/23.html

Duct Tape Programming




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


1. Don’t send bits to a device that it won’t use


bits == dollarsbits == waitingbits ~= processing


2. The client is always right*

* This one gets me in a bit of trouble


Remember how I said that User Agents aren’t always 100% honest and forthcoming? Or, at least, sane?


Whose User Agent is this?

Mozilla/5.0 (Macintosh; U; Intel Mac OS X10_5_7; en-us) AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0Safari/530.17


A Sane Person would guess...

Desktop Safari

And that’s what WURFL will tell you, too


But

It’s Skyfire for Android.


http://www.skyfire.com/product/android

Skyfire Web Site

Laughing all the way to the Bank or whatever,Love,

Skyfire

“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.”




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?


Let’s make something that works


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.


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


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


Example Device ClassesDevice Class Criteria Notes

“Mobile Webkit”• Webkit-based browser• Minimum resolution 320x480• Sophisticated CSS/JS/XHR support

“There is no Webkit on mobile”.—Peter-Paul Koch, QuirksMode

Smartphones• Resolution 240-320px• Robust XHTML support• Reasonable AJAX and JS• Quite possibly less awesome CSS

Don’t neglect this class! BB5, Win 6.x, etc.

Dumbphones• Resolution 128-240px• HTML support• Cookie/HTTPs support• Limited CSS support

a.k.a. feature phones


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


And the rest, you gently kick to the curb. Gently.


OK, Here comes the Drupal part...


First, some good news


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.


Now some bad news...


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.


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


Everything you learn today is obsolete tomorrow

Case in point: This just in!

http://drupal.org/project/tinysrc




Modules: Theirs (3rd-party)


mobile tools

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)

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.

Generally, I find that I want a bit more control than this module gives me, but it could serve as a great starting point.


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


Putting it Together


Alert! Code!


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


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.


Our Module: mobile_web (structure)


First Pass at the hook_init()


Create a Hook for Device Classes


Device Class Definitions

This can be read:((is_wireless_device == TRUE) && (ajax_xhr_type != ‘none’) && (mobile_browser === ‘Safari’ || mobile_browser === ‘Android Webkit’))


Define some Device Classes

In the interest of brevity, only two device classes here and “Webkit on Mobile” is over-simplified.


Second Pass at hook_init()


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


http://pastebin.com/jtufBq38

http://pastebin.com/jtufBq38

Themes!


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)


http://drupal.org/node/225125




Might I suggest?

I’m a big fan of sub-themes.


Another Variant

For hybrid desktop/mobile sites.

I also advise using the admin_theme module such that the admin interface stays sane.


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.


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


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.


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


Simplest Way to strip Extra JS...

The same approach works for CSS (the ‘styles’ variable).


Sorry. That was a bit fugly.


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.


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.


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


Resources and Further Reading


Read these books and blogs

Programming the Mobile WebMaximiliano Firtman (O’Reilly)

Beginning Smartphone Web DevelopmentGail Rahn Frederick/Rajesh Lal (Apress)

Because JS is Important for mobile:

High Performance JavaScriptNicholas C. Zakas (O’Reilly)

JavaScript: The Good PartsDouglas Crockford (O’Reilly)


Read these books and blogs

QuirksBlog by PPK (Peter-Paul Koch)http://www.quirksmode.org/blog/

Andrea Trasatti’s tech notes and morehttp://blog.trasatti.it/

Communities Dominate Brands (Tomi Ahonen)http://communities-dominate.blogs.com/brands/

Luke Wroblewski aka @lukewhttp://www.lukew.com/ff/


http://www.quirksmode.org/blog/

http://www.quirksmode.org/blog/

http://blog.trasatti.it

http://blog.trasatti.it

http://communities-dominate.blogs.com/brands/

http://communities-dominate.blogs.com/brands/

http://www.lukew.com/ff/

http://www.lukew.com/ff/

Super Useful Groups & Mailing Lists

mobile-web Yahoo! Grouphttp://tech.groups.yahoo.com/group/mobile-webAn active, useful list

wmlprogramming Yahoo! Grouphttp://tech.groups.yahoo.com/group/wmlprogrammingDespite the misleading name, this mailing list focuses on WURFL. Expect a rollicking time.

Mobile Portlandhttp://mobileportland.com/http://groups.google.com/group/mobile-portlandMeets the fourth Monday of each month


Who Am I?Lyza Danger Gardnerco-founder, mobile Web developer type of person

Cloud Four

http://www.cloudfour.com

http://www.lyza.com

@lyzadanger




http://www.lyza.com

http://www.lyza.com

mobile web on drupal!

Technology