Modern Site Engineering

Whew. A few weeks ago, we released our new Square and Card Case apps. Alongside the new apps, the front-end web development team spent a long two, three weeks to launch a new site worthy of our revamped product line. Under the tutelage of our front-end tech lead, we designed, redesigned, coded and refactored the old site, which itself was no more than a year, a year and a half young.

Despite not having a ton of interaction nor application state, building a site – representing a company known for its design excellence and attention to detail – took a lot of work. Presentation, universal accessibility and performance are considerations that have been around forever, but take on a whole new level of complexity with the mobile web.

Some lessons along the way…

Modern frameworks

Starting from scratch provides a good excuse to catch up to what the web development community has learned in the last few years, encapsulated in a set of “best practice” frameworks for HTML and CSS. Some of the ones I like:

• Modernizr — Deals with checking and enabling HTML5 features, compatibility fixes for older and crappier browsers.
• 960 Grid — Lay out your site in a well-defined, well-aligned grid system.
• SASS — Compiles into CSS, provides additional structures to manage oversized CSS codebases.
• jQuery Mobile — Support for common mobile browser UI conventions.

It’s pretty amazing how fast frameworks have evolved; it goes to show the demand for front-end web resources, as well as how much of a mess the development environment remains.

Flexible layouts

For the longest time, the bane of web development had always been the IE brethren: IE6, IE7 and to some extent IE8 simply refuse to respect rendering standards the rest of the world agreed upon. Their diminishing market share, though, makes them less influential and it’s no longer necessary to get 100% rendering parity1.

The new platform divergence is now between browsers on the desktop, phone and tablet. Tablets are a fairly new form factor, and smartphones are have enough power now to render complex sites, even if the UI and interaction isn’t ideal. Now it is possible to have the same site across all three devices, taking into consideration differing screen resolutions, screen orientations and pixel densities, at least in theory.

Unfortunately, the CSS detection mechanisms are fairly primitive, and even though most of the new form factors behave better than IE, there are a lot more devices to support; it requires adapting new assets (e.g., images), new layouts and UI elements2. Also consider each platform’s various strengths and weaknesses in areas like CSS3 animations/effects, Javascript animations/execution, and HTML5 hardware-specific features, and support is a bit more complicated than simply cutting out images for text3.

Native look-and-feel

An interviewee once told me that the average computer user cannot tell the difference between a native app versus a web app; they simply want their apps to work, and don’t understand or care about the web’s inherent limitations. That is, the user expects a web app to interact as well as a native one, but for anything interesting (i.e., non-trivial) this can be hard to pull off. The Financial Times webapp and Amazon Cloud Reader get close — and are perfectly functional — but don’t have the flourish that an iBooks app or Pulse News Reader display.

There is a maturation of web frameworks, though, which look to close the gap between native and web. Sencha and Sproutcore are two examples of webapps that live completely in the browser but have all the little UX details of a native app – the latter good enough that Apple is using it to build its next-generation iCloud app suite.

Ever-changing

The web has always evolved at a fast pace, and its greatest advantage has always been the ability to push down new code on a simple browser reload4. The complexity of modern sites, though, makes rapid releases more challenging – it simply takes more engineering effort to iterate a complex application. It’s not uncommon for a site to be redesigned after a year, but webapps can live on for much longer before the entire entity can be rewritten.

In fact, webapps are in the uncomfortable position of being “on” all the time, even as new redesigns and features come out, so ultimately the sites are evolved in parts rather than replaced as a whole (i.e., no big-bang version 2.0). It’s sometimes disorienting to have 2, maybe 3 versions of the site built in different times up and running alongside each other, and it takes engineering discipline to wade in periodically and delete unused code, although the association between HTML, CSS, and Javascript is much looser than most other development languages/environments.

A site or an app?

After building the new Square site, I’m not sure it makes sense to differentiate between an app and a site that much anymore. Yes, you may argue that an app would adhere to an MVC pattern or that it maintains a lot more client-side state or maybe it feels more interactive, but a site after a few iterations and feature additions begins to resemble that of an app anyway. On the flip side, a good number of mobile apps are nothing more than glorified wrappers of HTML-renderable content which just happen to embed native-OS UI components, and as mentioned, users wouldn’t really care either way.

To that point, I’ve began to look at any site or part of a site I build as a potential part of an app, and prepare the architecture for that possibility (or perhaps eventuality). With few exceptions – that legal disclaimer probably won’t have a carousel and user commenting anytime soon – people will want to do more on the site, and it’s easier to get it (mostly) right the first time5.

Steps like

• Setting up the common HTML snippets as reusable partials
• Defining a base set of utility classes to style a page quickly and uniformly
• Breaking out Javascript into plugins, modules, or objects

Your future self will appreciate the foresight.