The ultimate responsive design challenge

Well, if nothing convinces you to take responsive Web design seriously, consider this: there are now approximately eight thousand special people poised to use your application. Eight thousand select, elite, affluent, early-adopter people, eager to purchase something new, something you can offer just to them. Eight thousand people who probably influence eight thousand others, and so on.

Eight thousand Google Glass users.

Think about it: does your application’s interface really scale down to the size of an average person’s eyeball? If you tore your hair out over the task of making a mobile version of your site usable and attractive, you’re probably tempted to ignore the vast problem of responsively designing for Google Glass for as long as you can. This would be a mistake, for it’s a great opportunity for a clever designer. You’ll be the toast of the Web, widely cited as an innovator, if you come up with any workable solution to this problem.

The main difficulty, of course, is deciding which areas of content to display first. Given the device’s extremely limited screen width, you’ll probably want to use infinite scrolling. User objections to this construct will most likely be fewer than in other contexts, since it’s by verbal commands, rather than hand-cramping mousing or touch events, that scrolling proceeds in Google Glass. Determining how to order your content is really the task of a prose or copywriting expert, but here are a few tips:

  • Require logins immediately. You want to make sure that you’re serving this interface only to registered users, people who have real commitment to your application. Otherwise, you’ll just get some tire-kickers who won’t pay for anything, and the expense you incurred developing this Google Glass layout won’t be justified.
  • Use short, punchy sentences, not long paragraphs. Google Glass users have just seconds to glance at your content, before they return to interrupted tasks like family dinners, driving on freeways, and sleeping. Take a hint from current presentation slide style: use short words, preferably with four letters, in all uppercase letters. Use slang and abbreviations liberally to save space and to communicate your point efficiently.
  • Add visual stimulus to keep your users engaged. At random moments, animate portions of the screen without requiring user input. Give the user a rest from the trying job of reading prose by strobing the display’s colors, or reversing light for dark values.

  • Take advantage of Google Glass’s audio output. Which of your users won’t like to hear uninterrupted background music as they scroll your content? You could even imitate the wildly popular practice of playing intermittent system announcements, which most of us are familiar with from calling service lines. Remember, as fashion-forward as Google Glass users are, they’ll still be reassured by your adopting familiar techniques from older media to help them navigate this exciting new technology.

Google Glass builds on technology devised in 1960s West Germany.
Google Glass builds on technology devised in 1960s West Germany.

Test-driven CSS Development

I’m not the only one to have searched this phrase. Many front-end developers (including, it seems, a statistically significant number of people named Simon) crave the benefits of a TDD-like process when devising stylesheets.

The dream: define styles at the beginning of a project, test them for validity, performance, browser interpretation, then continue development feeling assured that you’ve satisfied all requirements and that you won’t meet any nasty browser surprises upon launch.

The reality: a process, not yet susceptible to automation. You’re still using your own eyes and hands to evaluate whether your CSS meets your project requirements. The good news is that there are a lot of people discussing this, and building tools to help out with it.

TDD for CSS. OMG!!

Start with the stylesheet, not markup. This is becoming common as more of us use CSS frameworks for tasks such as grid layout or responsive design. As you add markup, keep assessing whether you’re really using all the rules in your CSS. Prune the ones you won’t use. Tools to make this assessment include:
* Chrome Developer Tools. Under Audits>Web Page Performance, run Web Page Performance to obtain a report of which CSS rules have gone unused by your page.
* Firebug CSS Usage add-on. Click Scan, and see all your CSS rules evaluated for relevance to the page loaded. The tool will even export a cleaned CSS file that prepends the unmissable string UNUSED to rules found useless.

Validate your CSS as you go along. The solution to that wildly inappropriate heading styling might be as simple as a neglected closing brace, or an invalid rule (go on, claim you haven’t typed font-color:... at least once). Don’t wait until the moments before deployment to discover how many of your style rules are invalid.

Create a style guide page with samples of all element styling. Jade Zahnster promoted this concept for easy CSS refactoring without adding rule bloat. Did you have blue submit buttons on your project’s first iteration, and now you have green ones as well? Keeping an inventory on a single page will remind everyone which rules are already defined and require only extension for the new requirements.

Optimize your CSS. Even if you’re a finicky, careful, solo developer, there will be places in your stylesheet with duplicate, verbose, and unnecessary rules. The best way to discover these is pasting your CSS into the CleanCSS tool, and noting where properties were streamlined.

Check your stylesheet’s performance. What’s keeping those styles from rendering? Why does that puffy-font, rounded-corner, gradient-fill form button not just, like, pop up first thing? Though no less than Steve Souders argues for less concern over CSS selector efficiency, it’s pretty interesting to see which rules in your CSS are creating bottlenecks. Review Paul Irish’s thoughts on performant CSS, the use Andy Edinborough’s CSS Stress Test, which evaluates CSS rules for performance by removing each one from the stylesheet, and noting changes in rendering time.

Keep looking at the browser. The days of having numerous browsers and multiple platforms engaged as you work are, regrettably, not yet past, but there are a couple of tools to help you check for display problems before you open five different user agents.
Simon Kenyon Shepard’s CSSUnit will report how rules are interpreted by a browser, which is useful when you’re trying to understand by how much browser X differs in opinion from browser Y. Mogotest is a commercial service which reports discrepancies between perfection (your favorite browser’s display of your page) and other browsers’ rendering of it.

It’s still all a lot of work; automation and robots can’t do all this yet. Consider it job security.

What not to buy in 2011

This is the time of year when the Interwebs are flooded with “what to buy…” consumer guides. In contrast, the things I discuss below are much cheaper, saving you both time and money, because in the end you won’t be shopping for them at all.

(An aside to Web services freelancers: you know, if we stop offering these things, people will stop thinking they can obtain them. Give it a thought.)

What not to buy in 2011

  • Support for IE 6. Freelancers–put a clause in your contracts that requires a $10,000 deposit before you even start up IETester or the like.
  • Meetings requiring developer attendance.
    "Sunday," © Peter Paul Jacques
    Described variously as “toxic,” “a disaster,” and “the biggest productivity killers for programmers,” meetings are relics from the twentieth century which have as much relevance to your technology projects as do carbon paper and stenography.
  • The cost of a stern “butts-in-chairs” policy. Savvy, experienced developers know what conditions make them productive, and these are various. Nobody lists compulsory enclosure in a cube farm among those conditions.
  • Huge office spaces. Since you’re not having meetings, and you’re letting your team co-work or telecommute, you don’t need all that much space anymore.
  • Fake work.
    Fake Work: Why People Are Working Harder than Ever but Accomplishing Less, and How to Fix the Problem

    This should be obvious, but somebody had to write a whole book about it to expose the problem.

  • Expensive conference fees. As Rebecca Murphey noted, the most useful conferences for Web technology seem to be ones organized by and for practitioners, who aren’t always bankrolled by deep-pocketed corporations.
  • Tag soup, nouvelle cuisine style. Regrettably, HTML5 provides just as many opportunities for lousy markup (“<div>-itis,” overuse of class and ID attributes) to the novice and/or the unconcerned, as  did earlier HTML standards.

What’s dropped off your 2011 shopping list?

HTML5 Forms: browsers get jetpacks

Self-identified standardista Estelle Weyl enlivened a recent HTML5 Meetup with her summary of the neat stuff we could use if only everybody used, say, the latest version of Opera.

How many lines of JavaScript have you written to enforce a pattern on user input? To set focus on a certain form element? To mark input required, and bark at the user who doesn’t supply it? How about offering a calendar pop-up for a date picker? Between HTML5 and CSS3, there are new options for markup–no scripting necessary!–which handle these scenarios.

Well, that’s the promise, anyway. It’s nice to hear the future is nigh; it somewhat offsets the discouragement you’ll feel when you obtain the latest statistics on how many Web users continue to use terrible software such as Internet Explorer.

Carefree living post-IE 6

Hearing about nifty HTML5 wonders at present feels a lot like watching those filmstrips about “life in the year 2000 A.D.!” when I was a kid: substitute attributes like “placeholder” and “datetime-local” for “flying cars” and “robot servants” to update to the latest shiny, optimistic vision.

Yet it’s not we shouldn’t use HTML5 forms–we’ll just have to prop them up with JavaScript crutches, until the browsers of Tomorrowland are in common usage.

Note: Estelle’s presentation might be expanded for SXSW 2011.

My First Web Page

Some digging in a dusty file box the other day yielded no fewer than three floppy disks. What wisdom might these ancient tablets convey? Fortunately, there was at least one device in the house which still had a floppy drive. Result: mostly disappointment. The files were either first drafts of things I’d sent off to magazine editors in the late 1990s, or grouchy letters to my landlords of the same era. However, there was, archived with apparent pride, my first effort as a Web developer.

Step into the WABAC Machine. The year is 1997. I was the admin assistant for a team of software engineers. I was also something of a mascot; if the guys (yup, all guys, except for me) had a noncritical technical task they thought I could handle with a little instruction, they threw it to me, because I guess I looked really grateful to be doing something besides ordering lunch and taking the abusive phone calls of the company CEO. The most enduring instructions they gave me was how to use FTP, IrfanView, and NotePad to develop the team Web site. Of course, these tools seemed insufficient once I made a few changes–I wanted colors! Silly typefaces! Dizzying background images! And HTML seemed so hard to learn…

I remember downloading a lot of trial versions of the trendy WYSIWYG software of the time: an early version of Frontpage (which had me puzzling over these things called “stylesheets”), Adobe PageMill, and the editor which came with Netscape Gold. The one I used the most seemed to be NetObjects Fusion, which I notice is still available. It was a big, handholding, friendly giant of a program; it set everything into tables and FONT tags, and we were buddies. I felt masterful.

Nobody I worked with was a Web professional–no designers, no information architects, no UI devs. Creating Killer Web Sites had only just been published, Web Pages That Suck was treated mostly as a humorous diversion, and even Jakob Nielsen was as yet rather obscure to the average person making a Web page. It was in this Wild West environment that I devised this:
My First Web Page

I’ll enhance that retro atmosphere with a sample of its markup:

   <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
   <META NAME="GENERATOR" CONTENT="Mozilla/4.03 [en] (WinNT; I) [Netscape]">
   <META HTTP-EQUIV="Page-Enter" CONTENT="revealTrans(Duration=1,Transition=6)">
   <TITLE>ES Home Page</TITLE>
<BODY BACKGROUND="amoeba.jpg">

<FONT FACE="Wide Latin"><FONT SIZE=+4>Engineering Services</FONT></FONT></H1></CENTER>

<CENTER><IMG SRC="grey_dots.gif" ALT="grey_dots.gif (6699 bytes)" HEIGHT=47 WIDTH=890></CENTER>


Quote Status</A></FONT></FONT></LI>

ES Status Report</A></FONT></FONT></LI>

Yeah, go on. Snort, carp, whatever. But this is how we did things then, back when browsers “innovated” with crap like BLINK and MARQUEE. A year later I was back to using text editors–haven’t touched a WYSIWYG since. Just a year later I was using CSS and disdaining FONT, and a year after that I was riding the dot-com boom as it crested. So it’s worth examining your old work product, if only to swell with pride over how far you’ve come since then.

What was your first Web page like?

A visit with HTML 5

Now that HTML 5 has been declared victorious over XHTML 2, the last six to eight weeks have yielded a bouquet of tutorials, introductions, cheatsheets, and blog postings about it. I guess we’re so excited about anything new in markup we’ll even cheer a draft proposal. I can’t excuse myself from the mob, having joined it on a recent project for a future-minded client who encouraged me to take up the fashion for <!DOCTYPE html>.

On first and even second glances, the HTML 5 element list seems conservative, not much of a change. There are the intriguing new tags like <canvas>, but with limited cross-browser support. <menu>returns from, what, HTML 3.2?, but this time dressed up as a way to group form inputs (easy to confuse with how we’ve been using <fieldset>). Other elements, such as <header>, <footer>, and <section>, are good substitutions for the over-worked <div>, which lingers in HTML 5 for your block element needs. <article> is interesting–it’s supposed to enclose “standalone” content. <nav> is easy to type and remember.

However, some of these tags seem to presume usage in rather old-fashioned situations. For instance, which of the navigational blocks on your application screen will you exalt with <nav>? No fair using it more than once–it’s supposed to designate your primary navigation. And which of your content blocks are <section>s and which are <aside>s, especially if the user can rearrange them?

Where HTML 5 seems more ambitious, seems to pose more of a learning curve, is on attributes and APIs. Form elements seems especially enriched in this specification. I didn’t use any of these on this project, but I’m eager to try them when the browser support is sufficient. Many of the proposals will remove tedious DHTML chores, if ever supported; for instance, this block will replace all those unordered lists distorted by CSS and JavaScript into popup menus:

<menu type="popup">
    <command  label="Check messages" icon="messages.gif"/>
    <command  label="Logout" icon="logout.gif"/>

By now I expect you’re asking, “But what about IE?”

Yeah, what about that? Hmmm.

I was blessed to have a client who’d discarded concern for IE 6. Problem solved, you think?

Not at all. IE 7 ignored even the most basic HTML 5 tags–even <section> proved uncharismatic. To the rescue, JavaScript; more specifically, the “HTML5 Shiv” (love the name, which captures the mood of destructive exasperation IE inspires) script popularized by John Resig and Remy Sharp.

Overall, it was an enjoyable stroll through HTML 5’s more accessible areas. Maybe XHTML 2 would’ve been a more thrilling excursion, but I’m content. Shiv or not, it looks to be sunny ahead.

5 Ways to Style dl

Recently I lamented the rare usage of the supremely useful directory list, dl. The directory list is a pretty common data structure: one heading, followed by one or more related subsidiary data. It’s appropriate for more situations than it’s used for, probably because so many developers fixate on markup’s visual design rather than its information design. Browser defaults for dl obscure its versatility:

Firefox default for dl
Firefox default for dl

But there are so many occasions for which dl is the obvious data structure, once groomed by applicable CSS styling. As end users adopt standards-compliant browsers with better support for CSS 2+, styling dl into recognizable data structures becomes nearly fun, and will tempt you to try the ridiculous.

For instance, dl adapts readily to become the container for a recipe:

dl as recipe
dl as recipe

The CSS for achieving this assumes that you’re using one of those newfangled browsers with excellent support for CSS 2+:

dd {
display: inline;
margin: 0 .25em 0 0;
dd:before { content: " First, "; }
dd:after { content: ".  "; }
dd+dd:before { content: "Then, "; }
dd+dd+dd:before { content: "Finally, "; }

There’s a similar mechanism for forming dl into a citation:

dl as citation
dl as citation


dt { font-weight: 700; }
dt:after { content: ":"; }
dt, dt:after, dd { display: inline; }
dd { margin: 0; }
dd:after { content: ","; padding-right: .25em; }
dl dd:last-child:after { content: "."; }

dl is, semantically, a good choice for an accordion menu, with a CSS :hover or JavaScript event attached to dt:

accordion, collapsed
accordion, collapsed
accordion, active
accordion, active


dt {
font-weight: 700;
dt:after { content: "\203A"; padding-left: .25em;}
dd { margin-left: 0; visibility: hidden;}

dl:hover dt:after { content: "\2026"; }

dl:hover dd { visibility: visible; }

And then are ways to style dl which, yes, test the capabilities of CSS, but are just plain dumb. If, for instance, you feel compelled to style dl as a table or as a bulleted list, you should question why you’re using this particular markup, and not table or ul:

dl as table
dl as table
Picture 2
dl as bulleted list

The CSS for these stunts:

dl { display: table; }
dt {
display: table-caption;
font-weight: 700;
margin: 0;
text-align: center;

dd { border: 1px solid #eee; display:table-cell; margin: 0; padding: .25em; }

dd {
display: list-item;
list-style: disc;

Versatility, it’s a burden.

Review: JavaScript Performance Rocks!

by Thomas Fuchs and Amy Hoy
by Thomas Fuchs and Amy Hoy

Title:  JavaScript Performance Rocks!
Authors: Thomas Fuchs and Amy Hoy

  • Concise, easy-to-follow advice with good examples
  • Some overlap with other treatments of the same subject, such as posts on Ajaxian or the Steve Souders books, which reinforces the learning
  • Download includes the DOM Monster bookmarklet, which assesses a given page for conformance with the book’s recommended techniques
  • Casual,  breezy tone in the prose which is hard to tolerate for very long
  • Idiosyncratic landscape format for page layout; difficult to read onscreen, terrible for printing out

JavaScript Performance Rocks! is yet another indicator of front-end development’s new status as something worth improving.  The authors examine where the scripting on a Web application interface frustrates or thwarts the user, and offer techniques either to speed up JavaScript rendering by various browsers, or to manage the user’s perception of that speed.  Some of the techniques will seem familiar if you have read much about JavaScript performance in the last two or three years–the greatest benefit this book gives you is having all that lore in one place, with justifications if you need to supply them when you use these on a project.

As of this writing, JavaScript Performance Rocks! is in beta.  When you purchase the download, you are assured of updates, which is necessary because some sections  remain incomplete.  I’m skeptical the final version will improve what I consider real problems with this book, which are in its prose and visual styling.   Both, I assume, are the results of the authors’ vision of delivering a technical book which would be fresh, hip, and not too serious.  Unfortunately, the youthful lingo wears–imagine having a hipster, like, totally, goin’ on about, you know, JavaScript? and you might experience the same impatience too many pages of this will give you.

More problematic is the book’s visual design.  I’ve looked several times at the landscape-oriented pages, trying to understand why they aren’t given the conventional portrait format.  I think the intention is that each page’s content falls “above the fold,” and the reader won’t need to scroll down to read it entirely.  However, on my monitor, this perfect layout only arrives when I reduce the page size in Acrobat Reader to 75%, which also reduces the fonts below my preferred level.   In any case, thinking of alternate presentations for this material is a needless distraction from it.

Included in your download of the beta is the marvelous DOM Monster utility.  If your questions about JavaScript performance concern an application you have already built, the DOM Monster gives you an easily comprehended diagnosis: where do you have too much whitespace?  Where are there empty nodes?  Do you have too many links to scripts and stylesheets?  I won’t be surprised to see this bookmarklet sold as its own product, given its immediate usefulness, but I’d be dismayed if developers used it without reading the accompanying text.  For, whatever its flaws, JavaScript Performance Rocks! comes highly recommended.  Like, all, hella recommended.  By me.