Laying Down our Burdens: Steps towards simplifying the mobile Web

Developing on the mobile (or pan-device) web is hard. Maybe too hard. Yeah, kind of too hard sometimes. My days are spent chasing down the vital new frameworks (maybe not so vital, really, in retrospect), the newest incremental browser releases, updated devices, newly-unearthed bugs, JavaScript polyfills, debunked CSS techniques, amended specs and sexiest APIs, all while trying to avoid arguments about the True Spiritual Purity of particular approaches.

This leaves me with about four minutes a day to actually do my job, so I don’t get out/sleep/call my poor suffering mother/laugh much.

I don’t really like this. It’s quite noisy. It makes me restive. I want to help people learn how to be successful on the mobile web and the future web as a whole, but the slag heaps of particulars and trivialities are starting to corrode the environment.

Let’s try to make it quieter. Let’s build on the commonality core to the web where we can. To do this, I think we need to let go of a few things, to lay down our burdens.

There are as many kinds of web projects as stars in the Milky Way, yadda yadda, disclaimer, worried-I’m-going-to-get-flamed backpedaling, etc., but I do find that two patterns of control and responsibility seem to crop up in multiple contexts. We grasp desperately for control in our chaotic environment, often looking to control things we in fact do not have control over. And, meek martyrs that we can be, sometimes we take the onus for things that we really should be able to walk away from.

Part of being successful on the pan-device web is relinquishing control of things we never had control of in the first place. Some of this you have probably heard. Web design processes are being re-imagined with an emphasis on adaptation and a rejection of pixel-perfect mockups. Content is increasingly given a position of centrality, and design flows around it.

As I like to say when I’m feeling punchy, we’ve invented the myth of the PREVIEW button. When customers ask whether there really is an existing tool to see the content and data they’ve put into the web as presented on every possible combination of device, browser and platform out there, I get nervous and worried (also: no). Because such questions smack of expectations-expectations of a pixel-perfect control that was always an illusion and never more than it is now.

As we move into the future, I believe we will see increasing decoupling between content and data input versus representational output as we transform back and forth between various web formats for the different types of clients consuming the web. Our current distractions of micro-control ("The border-radius on this button on the Samsung Galaxy S is about half a pixel too thin") aren’t even remotely scalable, and I think we already know this.

So, take deep breaths, build a solid, utterly simple, mobile- or content- or awesome-first foundation, and let your content flow into it like water as much as possible.

I’ve talked somewhat ad nauseum about my belief in the release of certain kinds of control, flexible content (another kind of control release) and the like. Recently, I’ve stumbled onto the concept a second kind of responsibility and control we, as devs, take on.

So, the border-radius on a theoretical Samsung flavor of Android is all wrong (let me preempt the pedants: I’M MAKING THIS UP. IT IS AN IMAGINARY SCENARIO.). Whose problem is this? That’s a sort of rhetorical question, because in our world, it’s almost always our problem. A wonkish, nasal and self-righteous lecture to the client about a bug in a particular fork of Webkit, while potentially totally correct, is not going to change the fact that the CEO barely knows what a computer is but has that exact Samsung and a strong predilection for particular, round-y, green-tinted buttons.

STILL.

This is an untenable situation.

I watch many mobile web projects bloat and spill over their budgets in the communities around me. I see the core of development go perfectly well until the dev team dies from a thousand tiny stupidities in mobile browser specifics.

Here’s a story that is not hypothetical. Recently I was piecing together an example prototype web app to use for teaching some concepts around progressive enhancement (specifically for my workshop at dConstruct in Brighton). Part of my enhancement process involved converting some footnoted terms and phrases into tappable elements that spawn a lightboxed modal widget with the footnote content (that is, preventing the user from having to scroll to the footnote at the end of the document—yay, convenience).

As part of this enhancement, my code assigns an additional CSS class via JavaScript. This class adds additional line-height to give more space around those now-tappable elements, you know, the classic "make your tap targets usable" situation. Worked fine.

Except that in Opera Mini, line-height is ignored entirely.

Enhanced page on mobile Safari on iOS (note relatively space-y line-height)

Enhanced page on Opera Mini on iOS (no line-height space here)

line-height test page on mobile Safari on iOS

line-height test page on Opera Mini, same iOS device

Here’s what Opera has to say:

"Mini does not support the line-height CSS property at present, since testing showed that it generally meant less text fitted on any individual page, requiring more scrolling from the user." — Opera Mini Authoring Guidelines

Hokay. You know how I’m going to deal with this?

I’m not.

For one thing, I can’t (see point one above about things we can’t control). But even if I could think of a plausible workaround, enh.

I sort of visualize the Opera folks as sitting around in a summit akin to the Council of Nicea, picking and choosing which parts of CSS they felt were worthy of inclusion in their canon. But dumb and fanciful metaphors aside, I would argue browsers should insomuch as possible implement the standards as they stand, not selectively exclude things because they can’t reconcile with them on a moral or idealistic level. Hey, I get that Opera is trying to protect users from data and scrolling glut, but when behavior doesn’t remain predictable, it puts developers in an impossible position, and in the end is detrimental for the user.

That’s all great, you say, and it’s very easy to make sweeping generalizations and plans and take stands when you’re not faced with a twitching and possibly insane client at 8:40PM demanding another CSS animation to showcase a Facebook Like button. And you’re right. Idealistic mountaintops have good views but are cold and lonely places. The real stuff happens at grungy-but-whimsical sea level, among the dead fish and vibrant local patois. But what we can do is start to grapple with the nature of the way we talk about these things.

We can slowly migrate our perspective from immediate self-blame and ownership of issues like these. We can start communicating about these things a bit differently. We can make little decisions that incrementally shift the timbre of this situation. We don’t have to bear certain burdens silently, forever.

By way of examples of little steps: I’m polyfilling for less-full-featured browsers less these days, where I can get away with it. Instead, my code increasingly looks something like this:

if (typeof history.pushState != 'undefined') { 
  // Yay! Async elements and that one-page-app snazziness
} else {
     // It still works. Don't panic. Normal URLs and requests FTW.
}
Code language: HTML, XML (xml)

This is me somewhat quietly casting a vote for standards. Sending the message that, hey, I want to give you this feature, but to level up to this with me, you have to play by the rules the community forged. If you don’t, I’m going to give you a baseline way to get things done (see, I’m not too cruel).

Sure, not always feasible. Sure, an oversimplification. Sure, not always advisable. But even small steps toward reducing the noise—and thus lowering the number of introduced risks and crap you have to deal with—in a project can help make the burden of responsibility more tolerable. Maybe this is as simple as not opting for a bells-and-whistle framework or JavaScript plugin for flyout navigation, but instead crafting something more minimal yourself.

We have a long way to go to streamline cross-device web development techniques. But maybe these humble little inroads can help lead to a simpler, more beautiful web.

This post is an expansion on some of the ideas in my recent talk on The Most Common Denominator at Breaking Development in Dallas. The link is to the slide deck, but there should be a video available within a few weeks. Stay tuned.

Keen on this kind of stuff? Get ye to the next, assuredly amazing Breaking Development conference, April 10-13, 2013 in Orlando, Florida. The lineup is incredible. Paul Irish, Stephanie Rieger, Sarah Wachter-Boettcher, our own Jason Grigsby…the list goes on and on and on (Dion Almaer and Ben Galbraith, Mat Marquis, Cameron Moll, Aaron Gustafson…).