Cloud Four Blog

Technical notes, War stories and anecdotes


GitHub introduced a new text editor called Atom last week, and reactions (at least in my Twitter feed) seem divided between fervent desire and snide disregard. For every few people shamelessly begging for invites, you’ll find one or two bemoaning how fickle we all are, how crowded this software category has become, or how our obsession with the “latest and greatest” distracts us from what really matters (what we make).

Some of these emotions are likely the result of the unspoken assumption that everyone in our industry must always know everything (Lyza called this the knowledge burden). But I also believe, regardless of industry, that a natural friction exists between makers and their tools.

We’ve yet to invent a device capable of directly converting our thoughts into physical manifestations. Until we do, tools can only approximate our intent. This means that the distance between idea and execution is often defined by the capability of our tools and our mastery thereof. They tell us what we can and can’t do.

It’s a complicated relationship.

 Some remain faithful to a specific toolset for as long as possible, cultivating an intense and focused knowledge of every feature, quirk and workaround. Peanuts creator Charles Schulz was so fond of Esterbrook & Co.’s Radio Pen No. 914 that he bought all of their remaining stock when they stopped producing it. The pens lasted him through the remainder of the strip’s nearly fifty-year run.

Others transition quickly, abandoning their previous workflow as soon as they feel it may be working against them. English post-punk band The Fall have remained vital and prolific for nearly four decades, in part because of frontman Mark E. Smith’s infamous propensity for changing the band’s lineup with little or no warning.

We’ve yet to discover that magic “one size fits all” process. Until we do, we should encourage the accelerating expansion of available tools while remaining skeptical of any that claim to be everything to everyone. Choice encourages diversity in the types of thought processes our medium supports.

In other words, tools are important. Not for their own sake, but for those they empower to create. Welcome!

Video: Essence of Content on the Web (Mobilism 2012)

Oh, I am excited! Video from my presentation at Mobilism in Amsterdam has been posted. I’m already excited about Mobilism for next year!

In this presentation, “Cutting through the Crap: The Essence of Content on the Web”, I talk about some of my mental explorations of the meaning of core content on the web. The summary:

You’ve likely heard about content a lot lately—content is king, content should flow like water, “Content First!”. But what IS content in its basest form? Is it HTML? XML? JSON? Is it human-readable plaintext? And once we have our content, how do we transform it to look wonderful on mobile devices, televisions, regular old computers, refrigerators? Where does content end and platform-specific representation begin? The mobile revolution has shown us that our content management and web publishing technologies are entangled and flawed. The web will continue to be consumed by more and more clients, many of which haven’t even occurred to us yet. But by thinking deeply and re-examining the essence of our content, we can help to architect a flexible future for the web.

Lyza's "Cutting through the Crap" presentation at Mobilism 2012
Photo courtesy of the very kind Jen Hanen

The video is available on Vimeo.

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.

Unclench and set the web free

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.

You are not and cannot be responsible for everything

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.


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.

Baby steps to a different perspective

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
Enhanced page on mobile Safari on iOS (note relatively space-y line-height)

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

iPhone iOS Safari: Line Height
line-height test page on mobile Safari on iOS

Opera Mini Line-height
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.

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

Come Aboard: Inspiring an Empathic Future-friendly Army

This past weekend, Jason and I were fortunate enough to participate in the second installment of "Mobilewood", a retreat-like gathering of hardcore mobile web nerds on Cape Cod. Last fall, we gathered in rural Tennessee to create the Future Friendly manifesto and web site. This time around, we spent some time revisiting the core tenets of Future Friendly and iterating on some of its values.

One of the outcomes of the weekend is the new Come Aboard page, which replaces our original "resources" page. In this new section, we’re aspiring to lay a groundwork of the championing of the Future Friendly concepts. That is, we want to "teach to teach", to build a happy family of Future-friendly mobile web adherents.

We invite you to come aboard the Future Friendly rocketship and be a part of the crew!

Emphasis on empathic peer advocacy

A chief concept of our Come Aboard mentality? Don’t be an asshole. It’s easy to get sucked into the deflating grind of Internet fury and become dogmatic or reactive (or, like me sometimes, retreat altogether in the face of trolls). Instead of taking a rigid stance, we want to encourage thoughtful conversations across teams, across organizations, across the earth.

Of late, I have been in several meetings at large organizations that have similar themes. A dozen or so smart people are sitting around a large conference table, brought in from multiple disciplines in the company to discuss mobile strategy. Each time, I see the two or three developers in the room enthusiastic, simmering with impatience to start hacking away on some of the mobile techniques they’ve recently learned. On the other side of the table, the strategic leaders of the company are also keen to move into the mobile web, but are frustrated with what seems like an invasive, entire overhaul of the company’s infrastructure just to make small steps. The marketing folks, on the other hand, are wary about how to translate their processes and metrics (key analytics that drive the shape of the company’s goals) into this new realm.

So the main question I had in mind while participating in the discussion that lead to Come Aboard was: How can we help all of these smart people communicate with each other?

Future Friendly is a campaign, not a syllabus

One of the criticisms we faced after the first launch of Future Friendly was that the manifesto and site were long on lofty ideals but short on rubber-meets-road tactics. In fact, I recall being one of the vocal ones at our first Mobilewood—I wanted to see more links to more specific examples of how to build this beautiful mobile web of which we spoke.

But the thing is, as Brian LeRoux points out: all specific techniques deprecate—it’s the principles that endure. Our charter is concerned with forging these principles; the implementation(s) will continue to evolve. Not that implementation doesn’t matter. We’ve updated the various pages of the site to link to specific people and content that address how to actually pull this stuff off.

But I realized that Future Friendly’s greatest strength is in its touchstone qualities. A set of core principles, that, when combined with the goals of a project, lead naturally to a set of applicable techniques and technologies. Cool!

Honored to be involved. Let’s go!