Ada Lovelace Day (#ALD14): Garann Means

Was it on css-discuss? A List Apart? I’m not really sure; that seems so long ago. I remember, though, being impressed by these detailed, well-written discussions of various aspects of front-end web development. The author was Garann Means.

She kept a useful blog that I relied on, and I always looked forward to the slide decks she posted from her conference talks. She wrote a practical book, Node for Front-End Developers. And, then, around 2010-2012, Garann Means really found her stride, and what she wrote and posted was more relevant to me than how to create ellipsis dots in CSS.

Her subject became women working in technology. She examined how women enter the field, how we struggle to remain in it, how we could improve it. And, to my regret, this summer she discussed how we leave it.

I read that post on a foggy Bay Area morning, and couldn’t stop thinking about it for the next couple of weeks. I’m also at that mid-career point where many women drop out of the tech industry. What happens when someone as accomplished as Garann Means “leaves” the tech industry?

(I’m keeping the verb in quotation marks until I find this out: did she jump, or was she pushed?)

It’s time to stop asking, “Why?” Somebody must benefit when Garann Means and other women leave tech–why else would such horrendous attrition rates be tolerated?

I think the task now is to inform women at the beginning of tech industry careers that we have only a decade or so to work them. We are like football players or fashion models: we have tiny windows–more like pet doors–of opportunity. We should be planning our inevitable exits all along, saving up our money for that dread day when nobody will hire us, nobody will promote us, or…we just flat-out can’t take the bullshit anymore.

What I’m reading into Garann Means’s account is that she left her tech career on a high note. I really hope that is the case. She and I have never met; now I’m not sure how our paths would cross. Were we to meet, I’d thank her again for her freely given advice, guidance, and opinions. Start to finish, hers is an example I will always find inspiring.

2013: the year we stop using PSDs

Today I’m deep into preparing my slides for the HTML5 Developer Conference. Topic: “Making Peace with Twitter Bootstrap.” I have forty-odd minutes to soothe everybody’s ills with this ubiquitous framework. Since it’s a developer’s conference, I’ll emphasize solutions for people like you and I: front-endy things about SASS and Bower and whatnot. This will be the reasonable-sounding part of the presentation. Then, in real time, I’ll fight the temptation to disintegrate into full-on rant mode.

Here’s what I’ll try to say with terse, politely worded slides, rather than foaming at the mouth:

No more PSDs.

Stop it with the goddamn PSDs already. Fer Chrissakes, it’s the year 2013. High time to stop pretending to simulate Web applications with twenty-three-year-old image editing software.

Okay, so you’re a visual type, and you like to sketch your ideas in Photoshop? Fine. But for the same reason you don’t hand a page torn out of your Moleskine to your developer, you shouldn’t hand her a freakin’ PSD either: both formats communicate very little about what you intend for the application interface.

As Mule Design Studio puts it,

A PSD is a painting of a website.

If your interface links to framework stylesheets, and your application’s stylesheet bristles with !important rules overriding those styles, it’s a definite sign your project isn’t using the framework’s styles effectively. There are a couple of sources for this problem: 1) a developer not understanding how to use CSS selector specificity to create new styles; and 2) a design completely, totally detached from what the framework offers.

Want to drive Web developers insane really fast? Require them to cram Twitter Bootstrap, ZURB Foundation, or pretty much any CSS framework into a design dictated by PSD. In this workflow the designers and developers never discussed nor established viewport breakpoints, element widths, line heights, and such ahead of the design and development process, and fashioning something resembling the Photoshop comp out of pre-built components becomes an exercise in crazy-making CSS stunts. Meanwhile, the really necessary work of creating responsive design goes undone–what really happens is more like Reactive Design, when somebody glimpses how awful the interface looks like on somebody’s phablet, and then there’s a mad scramble fifteen minutes before the client meeting to patch over the rough spots hoping nobody notices.

My freelance rate is by the hour, and this kind of unanticipated rush developing can be lucrative. But it enrages me instead, because it’s entirely unnecessary. These days a Web design is properly devised in markup and CSS. Don’t like the associated learning curve to do this by hand*? Then use any of the following alternatives to Photoshop:

  1. Adobe Edge Reflow. Even Adobe wants you to stop delivering paintings of Web sites.

  2. Easel. Design for the browser–in the browser!

  3. Jetstrap. Get rid of that whingeing front-end developer and make the interface yourself.

Why are you still designing Web applications in Photoshop?

* A link to a design blog post from over three years ago.

Ada Lovelace Day: Estelle Weyl

By late afternoon that day in September 2002, I was getting pretty grumpy. The sandwich at lunch had dissipated into low blood sugar; the files I’d placed on the server just moments before had disappeared (and we had neither backups nor version control); the room was stuffy on an uncharacteristically hot day in San Francisco. And here comes this woman from one of the rival teams in the hackathon, introducing herself, trying to make friends, or at least, acquaintances.

I don’t remember being very effusive. The day had been grueling–I was on a team of four, working feverishly to develop an an accessible, yet visually appealing, Web site in just a few hours here in the Mission High School computer lab. But we shook hands. I recognized this woman’s name from the discussion list for SFWoW, at the time indispensable for finding out about tech events like this one. I hadn’t known how to pronounce it.

“Estelle Weyl. Like ‘while,'” she said. Within moments we all learned how excited she was about CSS, a technique new to many people at the hackathon, which was just one day of the Accessible Internet Rally. At another gathering we’d learned about various accessibility techniques, such as supplying text alternatives to images, offering keyboard shortcuts, and using CSS for presentation. The last had been my M.O. for three years already–I was puzzled how slow acceptance of it was.

I’d recently left a job at a software company which assembled a bunch of open source superstars, both actual and self-proclaimed, and then hired some front-end types like me to rework the clumsy, visually unappealing interface for the superstars’ application into something more usable. The low status of front-end work became obvious to me upon my introduction to one of the engineers.

“Oh, one of the pixel people,” he sneered, then lumbered off, leaving me to read the absurd style guide the UI lead had delivered. CSS was too “unsupported,” the guide admonished. Use <FONT> and <CENTER> to render the design atrocities we build in the browser. I didn’t stay long at this pointless gig.

So Estelle’s bouncy enthusiasm for CSS didn’t seem infectious to me, but instead, rather nai Continue reading Ada Lovelace Day: Estelle Weyl

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.

Why we’ll stop using ID in our stylesheets

Seemed like everybody was talking about CSSLint a couple of weeks ago. I waited for the hype cycle to slow its rotation, then dutifully visited the online linter to pay my respects.

It didn’t repay them.

“Will hurt your feelings” is CSSLint’s tagline. Heh, heh; I’ve written stylesheets for thirteen years now. What faults could CSSLint find with my CSS?

Plenty, it seemed. Chief among the linter’s nagging judgments was my use of the ID selector in so many rules. Now, what’s so wrong with that? How is it that my practice for all these years is suddenly considered wrong?

I found this blog post proposing that the hip, up-to-date stylesheet of today contains no ID selectors. Intrigued, I posted the link on Talentopoly, where it generated a thread of comments from people who seemed indignant with the premise. Why discard a totally valid technique which can make one’s markup and CSS more succinct?

I think one reason we were so uneasy is that we’ve had to work with so much bad markup and styling written by people with poor understanding of the cascade. The result is overdependence on classes for style rules–a classic example would be a navbar with a couple dozen <a class="navLink"> bloating the markup. Expertly written CSS distinguished itself with terse rules attached to ID’d elements. But if you prohibit that, don’t you end up encouraging that stupid “class”-itis?

Perhaps. CSSLint can’t determine if your style rules rely too much on classes. But you can satisfy the linter’s criteria and also target specific elements without resorting to attaching class attributes to every node in your markup. For instance, you could show off your handling of CSS3 selectors instead.

Like JSLint, CSSLint is a tool based on its makers’ opinions of what constitutes good style. It’s not a validator, but an evaluator: it can suggest improvements (as did earlier linters). Using the linter is like getting the opinion of a haberdasher as to how wide your lapels should be: you’re not obligated to act on his advice, but you might look a little strange alongside your more fashionable peers.

But why has the ID selector fallen into disfavor?

Looking at the explanations on the CSSLint About page, I notice a pronounced concern for portable, modular styling. The linter discourages intensely specific selectors such as IDs and “qualified headers” (h* tags within a cascade, or with class attributes). There seems to be less focus on styling an entire, discrete page, and more on styling blocks of content which may be sent or received in an API. This is a reasonable emphasis: think of all the markup you’ve done in the last year. How much of it was for standalone pages? And HTML5 prods us to think of Web content in articles or sections, each with its own h1–our markup and styling are scraps, not whole cloth. It’s efficient to make them fit with others.

Well, so what–it’s just between CSSLint and you, right? No. A less obvious reason for abandoning the ID selector is so that your style rules pass CSSLint when somebody else submits your CSS to it. And this will happen. In a profession with no licensing and very little certification, front-end developers have few means of convincing potential clients that we know what we say we do. If our clients had the skill to inspect our CSS for quality, they’d probably wouldn’t need to hire us to write CSS for them. Tools like CSSLint, despite their basis in subjective opinions of good practice, reassure these clients: they know you’re following certain rules if you pass. They want the work you do for them to be rule-following and interchangeable, not idiosyncratic and difficult to reuse. Yes, a lot of terrible CSS can pass CSSLint–just as it can pass the W3C validator. That’s no reason to avoid using it.

HTML5 Boilerplate Rolls Into Town

Standing room only, and a waiting list besides–what was the attraction bringing so many to the tech college conference room at Fisherman’s Wharf?

Haloed at one end of the room by the glaring video lamp, a man, a laptop, and the new way you should build the front-end of your Web app. Ladies and gentlemen, presenting Paul Irish, in turn presenting the HTML5 Boilerplate.

There’s much you can gain just downloading it, of course. You could opt to pick through the unzipped goodies and apply them piecemeal to your aging markup, refinishing your early 21st-century XHTML with some latter-day varnish. But there’s a lot more in the Boilerplate than too-hasty reading of the docs will reveal.

Irish, one of the mod squad behind the informative and massively entertaining YayQuery podcast, delivered a quick, focused survey of the Boilerplate’s many benefits to those eager to follow advice like Steve Souders’s 14+ rules. Among these is a customized .htaccess file, for those of us with good intentions of, say, gzip’ping assets but only rudimentary Apache admin skills–that’s worth the attention of a full room all by itself. Another is the built-in provision of QUnit: no more chasing this down to install separately. And coming along in the bright future is the Boilerplate for mobile.

Build an ant!?

But best of all is the build script. No wonder Irish calls it his favorite part of the Boilerplate.

Here’s where mere mortal front-end devs can finally scale the Olympus of best practices. Need to combine your CSS files? Your JavaScript? Optimize, minify, them? Remove test suite leavings? Excise all those dangerous calls to console.log? Boilerplate’s build script does this for you. Hurrah; I didn’t need yet another checklist to consult.

I was gratified to hear someone take HTML seriously. For too long writing markup‘s been dismissed as a simple, easily acquired technique that any drooling idiot can/should perform. Now there are Meetups full of software engineers anxious to learn things like table-less layout. Hah! Isn’t the Web fun?

The jQuery Juggernaut

Last night I felt very lucky to have a seat in the biggest meeting room Microsoft offers in its San Francisco office. The occasion was a remarkably well-attended (over 150 participants) event of five different Bay Area Meetup groups. Our common ground was a discussion of jQuery.


Image © the jQuery Project
New Wave JavaScript

Why jQuery has so many infatuated practitioners:

  1. It’s designed to help front-end developers do the things we really need to do. As Yehuda Katz remarked, “We write software for humans.” By re-purposing CSS syntax for JavaScript tasks, John Resig returned browser-side scripting to front-end developers. The framework, and most jQuery documentation, are refreshingly oriented to using jQuery for those humdrum DOM manipulations we’re assigned.

    Five minutes with the average JavaScript tutorial will give you, maybe, some prose to recite about objects, data types, and the prototype method. Fifteen minutes–perhaps some acquaintance with the built-in Math object, rarely used in your daily work as a front-end dev. In contrast, five minutes’ reading of an introductory jQuery tutorial will get you to the point of answering that deathless question: how can I apply an onclick highlight color to every other table row?

  2. It’s (mostly) backwards compatible. Since you’re using the hosted version of jQuery from either Google or Microsoft (you are, aren’t you?), you might be anxious that an upgrade to the latest jQuery release will break your carefully wrought scripts of yore. Yet the framework is designed so that new functionality won’t meddle too much with older. Your zesty accordion menus from 2007 will thrill your site visitors for years to come.
  3. It will always be open source. The jQuery project is a member of the Software Freedom Conservancy. It cannot be purchased by any corporation and then sequestered into a proprietary format. You will never have to pay to use .mouseleave() or .fadeIn().
  4. It has an enthusiastic community of plug-in developers. Like as not, you could develop an entire Web project without writing a single line of your own JavaScript. In addition to the plugins hosted on jQuery.com, there are countless scripts and gists on GitHub, and who knows how many others stored on people’s blogs.

    It’s not that I advocate avoiding writing your own scripts, but if you’re solving a tediously common problem and you have the typical ridiculous project deadline, you can pull in someone else’s lightbox, autocomplete, or carousel, and move on to the more interesting work you have to do.

  5. Our feedback matters. An amusing test of this happened a couple of years ago, when jQuery.com unveiled a new branding effort. Gone was the tagline “Write less, do more,” replaced by “Be a Javascript Rock Star.” Manga-style graphics supplanted gradients and color blocks.

    Reactions tended to the furious, and the jQuery team quickly removed the elements generating so many complaints.

Why aren’t you using jQuery?

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.

12+ People I Owe

So here’s a pretty satisfying thought experiment/daydream: if uncountable buckets of money suddenly landed in your bank account one morning, who would you invite to share the windfall? Just in case this happens to Yours Truly, I’m writing up a list of people who devised things which made my professional life easier over the years, so that I can compensate them appropriately before I retire to a villa in Tuscany.

This villa is absolutely positioned. Photo by Maney Digital

12+ People I Owe

  1. Jesse Ruderman, for the Web Dev bookmarklets
  2. Felix Ritter, for View Formatted Source. Yes, Firebug has assumed its function, but I’m nostalgic for the day this add-on removed tons of guesswork from my project.
  3. Eric Meyer, for his Reset CSS, which introduced us to a sparkling world clean of browser defaults
  4. Joe Hewitt, Rob Campbell, et al., for Firebug
  5. Mike Buckley and Lorne Markham, for Pixel Perfect
  6. Kevin Freitas, for MeasureIt
  7. Lorenzo Colitti and Philip Chee, for FlashBlock
  8. Alex Sirota, for ColorZilla
  9. James Anderson, for Leechblock

Who will receive your gratitude?

How to demoralize your front-end developers

Stop failing at this apparently necessary chore; I’m here to help.  I can verify that all the following techniques have worked on for me.

How to Demoralize Your Front-end Developers

  1. Constantly change requirements. It’s, what, the day before the scheduled launch?  And the product doesn’t include that absolutely requisite feature you didn’t think to require until now?  Well, shoot, just demand it!  And make drastic changes to the visual and interaction design as well–where’s the glory in completion?
  2. Constantly change the visual design. You took that one-day course in CSS and remember only that it was a way you could change all of a site’s visual elements from one file.  Okay, then, let’s start by making all the blue things red, and all the red things green–but only on Tuesday–wait, change them back again, make the old red things red again–and oh, all the gray things white and the white things gray, and the grayish-white things brown, on alternate weekdays.  And all the wide things “smaller” and the narrow things “a little bigger” and the tall things “a smidge shorter” and… just marvel  how enthusiastic your front-end dev grows.
  3. Give them a lousy setup. Cram your developers into a spot at an unergonomic table in between the gal who has the obnoxious sound themes enabled on her workstation and the guy who spends his entire work day shouting into a speaker phone. Don’t let your devs use their preferred operating systems or software–point out that you’ve generously provided work computers exactly like your own, with that reliable ten-year-old OS and the proprietary groupware that cost you a bundle.
  4. Decide midway that you need pixel-perfection in IE 6 after all. So you visited your hermit, anti-consumerist brother-in-law living in a shanty with a hand-me-down Gateway 2000 accessing the Web over intermittent dial-up, and you looked like a putz because your beta site didn’t render perfectly in Internet Explorer 6.  Well, crack the whip so he can enjoy those rounded corners, PNGs with alpha transparency, and painstakingly mitered grid layouts.
  5. Critique the browser rendering against one in a different medium. Different media, you say?  Hardware?  Pshaw!  Do as I’ve actually witnessed:  hold a paper print-out of the intended design up to the monitor, and compare the rendered page unfavorably to the PDF print-out.  Remark on the differences in proportion and color.  Watch your devs writhe in either agony or amusement at your request to make the two formats identical.
  6. Assign visual design tasks to your developers. Get rid of that pesky professional, and go with a leaner team equipped with mere adequacy in Web design.  Start with vague instructions to your front-end devs (“This area of the page needs to really say ‘breathy,’ but not ‘vaporous'”), and end with your looming over them, jabbing at the display of a competitor’s site on a monitor, and shouting, “See? See?!  Like this–only different!”
  7. Pit your developers against each other. Break up that predictable day with a bout of office politics as bloody as any combat in the Colosseum!  Let one developer bully another, favor the least productive developer over the others, and disclose important project details only to the dev most likely to hoard the information.  When one dev leaves at 6pm to tend to the rest of his life, assign all his duties to the other one still in the office. Whatever you do, don’t let these people end up liking each other.
  8. Constantly interrupt with phone calls, e-mails, IMs, or in-person meetings. You know, if you give your developers the chance to concentrate, to get into the flow of working, there’s no end of disaster which could happen:  they might  finish the tasks you’ve assigned to them, or write bug-free scripts, or finish a work day with a sense of accomplishment.  Then you’d all miss an important feature of the Development Drama:  the climactic battle in which each side slays the other in murderous frenzy.
  9. Ridicule their professional opinions. Don’t listen to the nay-sayers when you describe that pop-up with autoplay Flash, animated GIFs, and blinking text you’re confident will add loads of appeal to the application.  Show them your teenaged son’s MySpace page and pointedly ask why they can’t make something like that if he can.
  10. Don’t use a bug tracking system. Sheesh, you already send all those e-mails.  Why repeat yourself in some persnickety little data entry form with those dropdown things which force you to prioritize the issue?  Just repeat: everything’s critical and of highest priority.  See, easy to remember.

Hmmm, something’s missing.  What have I left out?