fromAugust 2011
Column:

Drupal In Context

0

You Are A Mobile Device

Dries believes the future of Drupal is mobile. In his 2010 wrap-up he wrote, "We should think long and hard about how we can make Drupal the go-to-platform for building web applications in a world of tablets and mobile handheld devices." I think he's right. Drupal 8 should—and will—have improvements to make sites better on mobile devices.

But let's look beyond the immediate future, where mobile devices are those things you stick in your pocket. Already we're seeing movement toward a “deviceless device” that's always with you. Because Dries is talking about two- to three-year development cycles for major Drupal versions, we need to ask: What will “mobile devices” be like in 2014? How about in 2017, when Drupal 9 comes out? How can we keep Drupal an essential technology in that future landscape?

On-demand information, immediately, anywhere, anytime

To understand where Drupal should go, we need to take a guess at what the next generation of mobile devices will be like. Here's mine: Mobile devices of 2017 will be worn, not carried. Input and output will happen more naturally, with less direct manipulation of equipment.

Futuristic HandTo understand that, let's look at another technology: the Walkman portable cassette player. To people at the time, it represented an endpoint: It gave you any music you wanted, wherever you wanted! What could be better?

But the Walkman was just a waypoint on the road to iPods. It only “stored” up to two hours of music; you were locked into the same sequential order that was recorded on the tape; unless the music was available on a pre-recorded cassette, you had to copy it from another source (radio, vinyl, live, a different tape); tapes stretched, tore, and jammed; and you had to schlep all those cassettes around. The concept was good, though, for it identified something people wanted: on-demand information immediately, anywhere, anytime.

Today's mobile devices are in essentially the same product category, but we still do too much for too little. Why do we need to push buttons? Why must I look at the screen? Why carry a device at all? The ideal device would blur the line between the computer's awesome powers and our own, becoming as natural as our fingers.

The physical device interferes with that. When you take a phone out of your pocket, you pay with time to perform a transaction. When you type, you translate thought down an awkward road through language to fingertips; reading reverses the process, substituting eyes for fingertips.

But now we're teaching computers the human body's language, which I believe will result in substantial changes in mobile devices by the time Drupal 9 comes out. I can say this with confidence because it's already happening.

Invisible input

The first change is obvious to anybody who owns a Wii or Kinect: Input is becoming more natural. We wave our arms to swing a club in Super Swing Golf; similarly, gestures will soon call up menus in business applications. Second, environmental input will extract information from the user's location through such measures as temperature, vibration, and humidity.

Third, the user's location will deliver additional data. It will come through a combination of automated recognition (by extrapolating from the device's IP address or through GPS signals) and explicit action, as with the check-in feature of Foursquare.

These three new forms of input—body, environment, and location—will force Drupal to manage different kinds of input, and a lot more of it. How can Drupal accept a stream of locations from a moving car, or a flying bird? That's currently possible with custom programming—which is all we need right now, since these are edge cases. But what about when parents start expecting websites to track their childrens’ locations? Will Drupal be able to do that out of the box?

Preparing Drupal for streams, not nodes

Core Drupal can't do that right now because it thinks of information as nodes. Drupal sites usually have no more than a million of these things, each one representing a substantial chunk of stuff. But data from gestures, location, and the environment comes as streams: enormous collections of small data chunks. That raises many new questions: How finely should we sample those streams' resolution? Which parts do we need to store permanently? How do those real-time feeds combine to create meaning?

That's just the input side of the equation. Equally important is the output—what our devices let us do with that information. Let’s say I'm driving around Boston, looking for a parking space. A street-mounted sensor (like those currently being tested in San Francisco) tells me there's one just around the corner. But it does so by flashing something on my phone's screen, which I can't safely look at while driving. Why not put the information on the heads-up display in my windshield, or work with my GPS to direct me to the spot?

Going beyond 2017, I believe we’ll start to see more body-based output. A simple language of vibrations could take the place of GPS directions today, telling you which direction to turn, and how soon. A more-complex language could say... well, just about anything. Will Drupal know how to speak that language?

Drupal, mediator of future data

One advantage of Drupal (and other modern CMSs) is that it separates the data layer from the presentation layer. We usually don't have to change the data layer to enable new forms of output. But I believe that sometimes we will. The complexity of future data will create a huge number of switching conditions, which Drupal will evaluate to determine when to communicate through vibrations, a heads-up display, or my good old-fashioned mobile phone.

I'm optimistic. It's true that 2017’s mobile devices will force Drupal to manage new data structures, make more decisions about data use, and improve performance to handle those changes. But Drupal's most valuable function is as a mediator of information—a function it already does well. It will have to speak the languages of tomorrow’s devices; our challenge is to teach it those languages as they develop.

References

Advertisement

From our blog

Entity Storage, the Drupal 8 Way

In Drupal 7 the Field API introduced the concept of swappable field storage.

The Drupal 6 to 8 Upgrade Challenge - Part 2

Having concluded the readiness assessment, we turn next to migrating the content and configuration. In reality, there’s little chance that we would migrate anything but the blogs from our old site. For the sake of giving Migrate in Core a workout with real conditions, however, we’re going to upgrade with core’s Migrate Drupal module rather than rebuilding.

The Drupal 6 to 8 Upgrade Challenge - Part 1

Nathaniel Catchpole , the Drupal 8 release maintainer and Tag1 Senior Performance Engineer, suggested that Drupal shops everywhere could support the

DrupalCon Austin

The entertainment industry is not for the faint of heart.

Drupal Watchdog Joins the Linux New Media Family
Drupal Watchdog 6.01 is the first issue published by Linux New Media.

Drupal Watchdog 6.01 is the first issue published by Linux New Media. Come see the Drupal Watchdog team at DrupalCon 2016!

Drupal Watchdog was founded in 2011 by Tag1 Consulting as a resource for the Drupal community to share news and information. Now in its sixth year, Drupal Watchdog is ready to expand to meet the needs of this growing community.

Drupal Watchdog will now be published by Linux New Media, aptly described as the Pulse of Open Source.

Welcome to DrupalCon Barcelona - The Director's Cut

For all you schedule-challenged CEOs – and ADHD coders – this Abbreviated Official Director’s Cut is just what the doctor ordered.

Welcome to DrupalCon - The Barcelona Edition

Did we have fun in Barcelona?
OMG, yes!

Did we eat all the tapas on the menu and wash them down with pitchers of sangria?
Yes indeed!

Recursive Closures and How to Get Rid of Them

This came up while manipulating taxonomy children and their children recursively, so it’s as not far from Drupal as you’d think.