Cloud Four Blog

Technical notes, War stories and anecdotes

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.

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.

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

Cloud Four at ASAE Technology Conference & Expo 2010

Launching JEDEC.org isn’t the only reason we have standards setting organizations and associations on our minds lately.

This week is the ASAE Technology Conference & Expo 2010 in Washington D.C. and Cloud Four is going to the conference for the first time.

Despite the snowpocalypse plaguing the city, John arrived safe in D.C. earlier today after a long flight from our home base in Portland, Oregon.

He’ll be in town all week. If you’re at the conference, we please say hello. If you’d like to set up a specific time to meet with John, please contact us or connect with John via Twitter.

Drupal for Standards Setting Organizations and Associations

When we’re not working on mobile projects, there’s a good chance we’re working with a standards setting organization or an association on their public web presence.

More often than not, we’re building that site using Drupal. We believe Drupal is a perfect fit for organizations and associations.

Before we started started Cloud Four, Aileen, Lyza, John and I had all worked for several years at Kavi which is focused on providing software for organizations.

John was one of the co-founders of Kavi. Lyza was one of the first employees. And Aileen and I had been at Kavi for over seven years.

Needless to say, we have a lot of experience working with these organizations.

After we left Kavi, we searched for a new web platform that would fit the needs of these organizations. Our experience had taught us that while there are some common characteristics of organization web sites, that each organization has unique goals and functionality that they need implemented on their site.

With that experience in mind, we tried many different solutions before settling on Drupal. Drupal provides:

  • Top-notch content management features
  • Support for simple or complex user management
  • Foundation that provides for future expansion
  • An active development community
  • Ability to build custom solutions on top of Drupal if needed
  • Integration ease including the NTEN favorite membership management suite, CiviCRM1

In addition to these core features, we found that Drupal supports other things that organizations often talk about such as:

  • Revisioning
  • Authoring Roles
  • Content Syndication
  • News Aggregator
  • Tagging
  • Localization
  • Blogging
  • Forums

All of this goodness wrapped in an open source platform that is widely used by both companies and non-profits.

We’ve been talking to our customers and partners for quite some time about why Drupal makes sense for organizations, but have been waiting for the perfect showcase site to make the point to a larger audience.

As you can see from the recently launched JEDEC.org site, Drupal makes it possible to build beautiful and powerful web sites that accomplish the objectives of standards-setting organizations and associations.

If you’d like to learn more about how Drupal can help your organization, association or your company (Yes, it works well for corporate sites as well!), please contact us.

We’d be happy to talk to you more about how Drupal can help your organization.

  1. As an aside, if you run an organization and haven’t looked into CiviCRM, we highly recommend that you do. It is a full-featured, open source membership tool that integrates fully with Drupal. Not only that, but our friends at raSANTIAGO + Associates provide a great service called CiviServer and are experts in helping organizations utilize CiviCRM effectively.

JEDEC.org Launches

jedec-designLast week, we finally got to take the wraps off of one of our favorite projects of the last year: JEDEC.org.

While on our blog we mostly talk about mobile, we also do a fair amount of traditional web site development work.

In particular, we’ve helped many standards-setting organizations and associations like JEDEC with their public web sites.

JEDEC came to us with substantial issues that needed to be addressed. The current site had long outgrown its information architecture and had three different navigation systems and site maps.

We performed a full content audit and combined web analytics with information architecture analysis to create a new site structure that focused on helping people find information more quickly.

In particular, web analytics showed that the majority of people coming to the site wanted to download standards. The new design brings the search interface right onto the newly designed home page.

The search interface was reworked to provide people with the ability to narrow their searches. When documents are uploaded to the site, they automatically show up on the related committee pages and other sections of the site where the documents are relevant.

We worked with JEDEC to define technology focus areas that help people new to the organization understand the current hot topics for the organization and get a quick sense about what JEDEC does. These technology focus pages are all dynamic are constantly updating with new information as documents, press releases, and events are added.

We also collaborated with other vendors to integrate event data coming from another system and to provide a single-sign on strategy with a membership management system.

Perhaps most importantly, we had a great time working with JEDEC and its staff. In particular, Emily Desjardins and Arnaud Lebegue became part of our extended team over the last few months. We’re grateful for the opportunity to work with them and to see their vision come to finally come to life.

HTML5 from a Mobile Perspective

I’ve read with interest the controversy following the W3C’s decision to not renew the XHTML 2 Working Group charter. For those unfamiliar with the jargon of standards organizations, this means that XHTML 2 is effectively dead. In its place as the future of web development stands HTML5.

The comments about HTML5, and the potential for its future have been surprising. I hadn’t realized how working on mobile has changed my perspective.

At the risk of being accused of wearing mobile-tinted glasses, HTML5 is going to big a deal and it will be relevant much sooner than people think.

Lack of Extensibility

The main complaint against HTML5 is the lack of extensibility. In particular, the ability for developers to define new semantic markup that provide meaning to a document.

The need for this meaning is what created microformats which describe standard ways of presenting information like addresses in markup so that they can be understood programmatically.

The best description of this extensibility problem can be found in John Allsop’s article from A List Apart. John points out that:

This is not simply a theoretical problem. Hundreds of thousands of developers use the class and id attributes of HTML to create more richly semantic markup… Almost invariably, those developers use ad hoc vocabularies—that is, values they have made up, rather than values taken from existing schemas. It’s pseudo semantic markup at best.

HTML5 does add new elements like header, nav, article, section, aside, and footer which expand the structural definition of a page, but do not provide the level of extensibility that people have been seeking.

Documents versus Applications

The complaints about extensibility are legitimate, but the perspective is one that still looks at HTML as a document publishing markup language. John Allsop wrote:

There is a very real problem that needs to be solved here. We need mechanisms in HTML that clearly and unambiguously enable developers to add richer, more meaningful semantics—not pseudo semantics—to their markup. This is perhaps the single most pressing goal for the HTML 5 project.

This is a very telling indication of the perspective that John is coming from. He is looking at HTML as a document publishing and noting correctly that it lacks the tools it needs to describe the documents sufficiently.

I can see these short-comings, but feel that addressing the short-comings of HTML for web applications is the more pressing need—especially when it comes to being able to build rich web applications for mobile devices.

It seems like this may be the main disconnect between the developers of the HTML5 specification and its critics. The specification that eventually became HTML5 started out as the Web Applications 1.0 specification. Its sibling document was Web Form 2.0. Both of these have been merged into HTML5.

The WHATWG, which has been leading the effort to define HTML5, has stated that it “focuses primarily on the development of HTML and APIs needed for Web applications.” With that mission in mind, HTML5 is a substantial step forward.

(As an aside, John Allsop is right that ARIA support in HTML5 would give developers much of what they need, and I have yet to read a good argument against adopting it. I just don’t find it to be as pressing as the other things HTML5 includes.)

HTML5 for Mobile

HTML5 is a critical step for mobile web application development. Some of the key elements that it provides are:

  • Offline Support — The AppCache and Database make it possible for mobile developers to store thing locally on the device and now that interruptions in connectivity will not affect the ability for someone to get their work done.
  • Canvas and Video — These two features are designed to make it easy to add graphics and video to a page without worrying about plugins. When supported by the phone’s hardware, as is the case with the iPhone, they provide a powerful ways to get media into a page.
  • GeoLocation API — This is actually not part of HTML5, but is a separate specification. That said, it is often bundled together because the mobile phones that are including HTML5 are generally supporting the GeoLocation API.
  • Advanced Forms — Even simple things like the improvements in HTML5 for forms could make life easier for mobile applications. Fields that can be validated by the browser are improvements for mobile devices. The more that can be handled by the browser means less time downloading javascript code and less round trips to the server if validation can be found before the form is posted.

Most importantly, nearly all of the hybrid applications frameworks—Phone Gap, QuickConnect, RhoMobile, Titanium Mobile, and others—rely on HTML5 features to provide a rich application experience.

For these reasons and many more, I believe the adoption of HTML5 will be driven by the needs of mobile, not the needs of desktop developers.

When Can We Use HTML5?

Many people dismiss HTML5 as something they won’t have to worry about for some time. A commenter on Zeldman’s blog wrote:

None of this really matters until:

  1. IE supports whatever new standard we decide on
    or
  2. IE no longer has the majority of the market share

This is why mobile will drive HTML5 adoption. The iPhone, Google Android, Nokia, and the Palm Pre are all based on the open source Webkit browser engine. Those phones represent somewhere around 65% of smart phones sold.

(Note: it is too earlier to find estimates the percentage of Q2 smart phone sales. A lot changed in Q2 which is why older market share breakdowns are not as useful.)

The two major platforms not using Webkit are Windows Mobile and Blackberry. Some of the capabilities of HTML5 are available to Windows Mobile users via the Google Gears plugin.

It also remains to be seen if Microsoft will have a viable mobile strategy. At the moment, it doesn’t look good for the future of this platform as HTC, which is currently responsible for 80% of Windows Mobile sales, is rumored to expect Android to comprise 50% of the units it ships in 2010.

Therefore, the real barrier to HTML5 adoption is RIM’s Blackberry platform.

Blackberry has its own specialized browser not built on any of the major browser engines. It only recently started handling html, css and javascript reasonably well, but still is insufficient and buggy compared to other browsers.

Fortunately, for both Windows Mobile and Blackberry, Opera’s browser is both available and popular. It is consistently one of the top if not the top download on mobile applications sites. And Opera is one of the leading developers of HTML5.

Finally, if you look past mobile phones to other mobile devices like the iPod Touch, Nokia’s internet devices, and the upcoming Google Chrome, you see that Webkit is even more broadly distributed.

Webkit Does Not Equal HTML5 Support… Yet

To be clear, just because a device uses webkit does not mean that it has the latest version of Webkit and can use HTML5. Recognizing the market share of Webkit is important solely as an indicator that a significant portion of smart phones will have access to HTML5 sometime in the near future.

There is great incentive for mobile operating system vendors to upgrade to the latest versions of Webkit. They see the success that the iPhone has had and the fact that one of the main contributors to that success was the browsing experience. They understand that not many companies can afford to develop native applications for all of the various platforms which makes the features of HTML5 attractive.

Because of this, I expect browser improvements to be a high priority for mobile operating systems.

The Pressing Need for HTML5 is More Features

HTML5 needs to move past simply providing geolocation and offline storage and into more of the device characteristics. The Palm Pre’s WebOS has had to forge forward in defining its own APIs for accessing things like the address book, camera, and accelerometer.

I had an opportunity to ask Michael Abbott, Palm’s Senior Vice President responsible for WebOS, about the use of standards for mobile devices characteristics. His response was that they used standards where they could, but that there were no standards for much of what they wanted to do.

This problem is only going to continue to become more pressing. People are clamoring to develop mobile applications that take full advantage of the the capabilities of devices.

Smart Phones Do Not Equal All Phones

It is important to note that while HTML5 will be very important for smart phones, it won’t reach feature phones for sometime. Therefore, content publishers should continue to work with device databases for content adaptation.

Again, web application developers can make different choices and tradeoffs than content publishers. If you are building an application that combines cameras with geolocation information, you’ve already narrowed which handsets you support.

Features will Drive HTML5 Adoption

Remember how easy it was to convince people to move from HTML working drafts to HTML 3.2? Now compare that to the education process necessary to convince people to convert to XHTML.

Part of the difference is due to the times, but a large part of it was due to the fact that you could do things in HTML3.2 that you couldn’t do in previous versions.

That’s not to say that recent web standards like XHTML haven’t provided new features, but that none of the new features were game changers. GeoLocation is a feature that can create businesses. The same is true of access to other device characteristics.

For this reason, web developers who start looking at mobile development will not shy away from building using HTML5 even if it limits their audience.

The Mobile Perspective on HTML5

From a mobile perspective—and perhaps from the perspective of web applications generally—HTML5 cannot come quickly enough.

As Vic Gundotra, Google Engineering vice president and developer evangelist, recently pointed out, not many companies are rich enough to develop native applications for all mobile platforms.

The mobile web provides are the best hope for building a cross-device mobile ecosystem. HTML5 is a critical piece for the mobile web.