The Mobile Web is all the rage these days. A website isn't cool unless it is “mobile friendly.” Companies are called upon to develop a “mobile strategy.” There is an app for that is the new tag-line, even though Drupal had it first. And the calls for Drupal to “be more mobile” and to have “mobile support out of the box” are increasingly loud.

But what does that mean? In practice, nothing. “Going mobile” is the new-age version of “your company needs to be on The Interwebs” from the ‘90s, and it has as much practical value. OK, mobile is well and good, but if we don't know what it means, how can we achieve it?

The problem is that “mobile” means a great many things, not all related. Traditionally, mobile meant support for devices with very small screens and very slow data connections and browsers that are slightly more powerful than Lynx (a popular text-only console browser from the early ‘90s). Of course, that simplistic view of the market was never really accurate to begin with.

Today's computing market is almost frighteningly heterogeneous. All of those attributes of “mobile” exist, but not together. The majority of smartphones in the wild today have data connections that exceed the bandwidth of low-end DSL landline connections, yet have terrible latency. Meanwhile, even large-screen laptops are frequently connected to over-burdened hotel or airport WiFi connections slower than the smartphone sitting next to them.

Smartphone screens can be found in sizes anywhere from 2.5" square to 4.3" rectangular. Above that is the tablet market, with screen sizes ranging from 5" to 10" butting up against smaller laptops like the MacBook Air. Over-laying those are netbooks, which have wide-but-thin screens of various sizes with keyboards of hit-or-miss quality. And all of those could be on super-fast Wireless-N networks that put the cable modems of only a few years ago to shame. And let us not forget the browser capabilities on the various mobile operating systems: Mac OS, Windows, Windows Mobile, webOS, iOS, Android, and market-leaders RIM and Symbian: All have different capabilities, even if they use the same underlying engine.

So what does “mobile” actually mean? It means what web standards gurus have been saying for years, while most developers and designers steadfastly ignored them: You have no control over your medium. None. You cannot control your screen size. You cannot guarantee the capability of the browser visiting your site. You don't know how fast the user's connection is, but you can guarantee it's slower than what you're using to develop the site. Your user may have a keyboard, or maybe not. Your visitor may have a touch screen, or maybe not. And within two years, the 17" display sitting on a desk will be a minority of the devices connecting to the Internet. Drupal 8 won't even have cooled by that point, and unconventional browsers will be the new conventional.

None of those issues are reliably linked to any of the others. That's where the real challenge lies: It is impossible to design for 80 different combinations of attributes, especially when new devices are released almost daily. Instead, the only option is to design for any attribute. And Drupal does not always make that easy.

What we need Drupal to do, then, is to make it easy--which means making a number of important changes.

First, it means making Drupal slimmer. Drupal's HTML is infamously heavy, generally in order to support the sort of CSS flexibility that a tier-one CMS needs on the browsers we've needed to support. Fortunately, those are finally dying off, and the new wave of too-many-browsers all support most modern techniques. That means we can, and should, slim down our HTML and CSS to save bandwidth--which helps any low-bandwidth device, wireless or not. As a nice side effect, it makes Drupal friendlier to designers who have for years objected to Drupal's heavy markup. This is an effort that should be led by markup experts, not PHP experts.

Second, we need to embrace the new wave of “responsive” design strategies. The days of fixed-width designs are numbered. (Frankly, I always hated fixed-width designs to begin with.) Even ignoring mobile phones, browsers sitting on a desk can range from 800px wide to 1600px wide. The concept that a single 960px wide pixel-perfect design is enough will soon be as much a joke as table-based design. What can we do in Drupal to make such designs easier to implement? That's a question we should ask of Drupal's small design community and then let them—not developers--drive that discussion. That's the only way to attract the wider design community, most of whom know far more about the subject than your typical Drupal developer. (See John Albin Wilkins' article on “Finding our Path in the Mobile Wild” in this issue for what that means for designs built on Drupal.)

Third, we need to set a standard in core of building themes and Javascript that respond to both mouse-based and touch-based events. There are new touch-based events available to Javascript in many, although not all, mobile browsers, and we need to consider what happens on both click and tap; they may not always be the same thing. Touch-screen devices also have no concept of hover events; those need to go away entirely. It’s a practice that needs to become commonplace both in core and in contrib. Module maintainers who maintain Javascript-using modules, take note: This means you.

Fourth, we need better support for mobile applications. Sometimes there's an app for that is the right answer. Developing native apps for iOS and Android in Objective-C and Java, respectively, is far afield from the typical Drupal developer's skillset, and targeting only a single mobile platform in a very crowded field is very likely to backfire just as much as IE6-only web apps have. Fortunately, there are a number of web-technology-based mobile frameworks available, either VM-based such as Titanium or HTML5-with-a-button like PhoneGap, which make that task easier. Getting data to those devices, however, is still a challenge. We need to step outside our comfort zone and develop good techniques, standard libraries, and better practices for making Drupal the go-to platform for mobile apps that tie into a web sites. (See Pat Teglia's article on “The Drupal Mobile Process” in this issue for one case study of how Palantir.net used such tools to build the mobile companion for DrupalCon Chicago.)

Finally, we need to move Drupal away from the short-sighted vision of the web as a collection of pages. The web is, and has always been, a collection of requests and responses, with pages being only a subset. To support mobile apps, desktop applications, and even server-to-server integration, we need to make web services a fundamental and integral part of Drupal. HTML pages are simply another web service. That is the goal of the Web Services and Context Core Initiative (WSCCI), which I am spearheading for Drupal 8. While this effort to modernize Drupal's back-end is largely focused on the deep code parts of the system, it is no less important than the work to modernize Drupal's front-end. (See http://groups.drupal.org/wscci for more information.)

It’s a lot of work, but that’s what it will take for Drupal to “be mobile friendly”. Mobile isn't the issue: The issues are low-bandwidth devices, touch-screen devices, and vastly diverging screen sizes, not to mention embracing and encouraging clients who aren't even web browsers. Supporting “mobile” devices is the combination of all those efforts, many of which are already under way but need more help. If we're successful, we can move Drupal from yesterday's first-class CMS to tomorrow's first-class platform.

Let's get to work.