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.

Random stuff about the first Fluent JavaScript conference

I’m in the middle of changing jobs. To train my soon-to-be-former co-workers on how to get along without me, I spent three days this week at Fluent. What I garnered:

  • Watching my audio-engineer husband in action. An unusual perk of this conference was that, for the first time, the Binkster was doing sound for an event I attended. It was fun learning from him some of the backstage scuttlebutt. In turn, I enjoyed explaining the in-jokes about semicolons and Internet Explorer. Something that was really beneficial was finding out which presentations impressed him—he’s not a developer, but he’s seen more PowerPoint than any human not being punished should, so if you reached him, you must be very engaging.
  • Being reminded how unhealthy I feel sitting all day in a hotel ballroom. Spending all day inside usually makes me feel pretty bad, and so does sitting down a lot. Even worse is when the room is air-conditioned into that Atacama Desert level of humidity: we’re being mummified as we sit there enraptured by CoffeeScript. I swallowed zinc tablets and muscled through, but I skipped a few sessions because I just had to get outside and breathe real air. My admiration for my husband grew as I realized that he tolerates these conditions all the time for his job.
  • Tips about the new recruiting laundry list items. What many people talked about: JavaScript MVC frameworks, responsive (design|development), non-blocking script loading, knowing buck-naked JavaScript and not just jQuery.
  • Some great one-liners. There was frequent discussion about how JavaScript’s finally become accepted as a genuine programming language, worthy of study and standards. Along those lines were calls to take your JavaScript projects seriously:

    “Your JavaScript is software. Let’s treat it like what it deserves to be.” —Davis Frank

  • No t-shirts. I guess I could’ve obtained one, but I don’t usually wear them, so didn’t bother. Conference swag I’d really wear: something like a high school varsity sports badge. Heck, I’d even sew it on my letter sweater, right next to my junior-year award for cross-country. You’re welcome, O’Reilly, for my excellent idea.
  • Appreciation for the kinds of people who use JavaScript. I didn’t see any of the chest-thumping geek jousting I’ve seen at other conferences; doesn’t mean it wasn’t there, of course. Saw instead a greater spectrum of ages, ethnicities, and gender identities than the usual Meetup or hackathon offers. There was even a line in the women’s restroom at one point!
  • Yearning to learn more CoffeeScript. But I wonder if this won’t become the future’s version of “learning jQuery, not JavaScript” debate. In the backlog for now.

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.

The Point of the Rails Outreach for Women Workshops

The past week has seen some discussion on the mailing list for a local Ruby Meetup about this weekend’s Rails Outreach for Women workshop. One message from the workshop organizer, requesting a wireless hotspot accessible to Windows users, prompted a strange but revealing departure from the subject when people responded. Those of us lurking on the list didn’t find out who provided the hotspot, but we did find out what other subscribers think is the point of this workshop.

The point of the Rails Outreach for Women workshops

…is not, despite apparently common belief otherwise:

  • to give participants incredibly detailed information about the Ruby programming language
  • to give participants deep instruction in computer science topics
  • to convince participants of the superiority of open source software
  • to shame users for their reliance on GUI clients
  • to berate the people Sarah Mei wryly terms “operating system minorities” for using something the rest of us find inconvenient.

The point of the Rails for Women workshop is to make a cultural exchange.

It’s like going to a country where you don’t speak the language. You prepare by learning basic phrases which will help you ask directions to the train station, order food from a restaurant menu, and be polite in that country’s etiquette. You don’t start with the pluperfect tense, historical study of that language’s divergence into regional dialects, or intensive scrutiny of the country’s avant-garde poets. Your goal is to enjoy your trip to that country, and, if you do, you might return and gain more facility in its language.

The stated goal of the Rails for Women workshop to increase gender diversity in the Ruby community by helping women learn Rails. By the end of the workshop, however, what’s happened is a lot more positive and enduring than fifty or sixty people inspecting http://localhost:3000 on their laptops.

image © okhiroyuki

Instead, there’s an exciting, contagious mood of self-confidence in the participants and volunteers. People might not remember how to generate a scaffold the next day, but they will remember that they did it once before–so it can’t be that hard, can it?

Anybody who believes the tech industry is egalitarian should spend time working in it as a non-programmer. Only a few moments on the job as an admin, HR person, marketing person, or designer will quickly reveal how the people in these roles are consigned to the lowest castes in tech companies, while programmers are encouraged to swagger like feudal lords.

Many of the participants in the Rails for Women workshops identify themselves as this sort of tech-but-not-techie, in that they’ve been around the artifacts of programming culture, but not able to make sense of them. Once in the workshop, they handle things like–the command line! Version control! Databases! Maybe at the end of the day they don’t have every concept mastered, but they do have a greater self-regard that is moving to observe. They might go on to volunteer at the next workshop, or even attend a Ruby Meetup. They feel entitled to learn more.

The cultural exchange isn’t one way. As the participants work through the workshop curriculum, they discover where the Rails Way isn’t clear. Install Night is especially revealing: every volunteer helping gets exposed to at least one error message he or she’s never seen before, at least one bewildering installation problem for which no amount of Googling can provide solutions, and at least one nonsensical incompatibility nobody bothered documenting.

The Rails community gains from these frustrations. It gains when a workshop participant points out the inadequacy of a tutorial, README, or wiki page. It gains when installing an upgrade or gem becomes simple. Consider how friendly Rails could be for a programming novice: there’s so little futzing and configuration to do (once past the install hurdle) before you get to see something display in the browser. Why not make the Rails community as accessible?

The San Francisco Rails Outreach for Women Workshops are organized through the SF Ruby Meetup.

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?

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?

Finger Busting

The other night my husband and I indulged in some old-fashioned diversion by picking through our collection of 78 r.p.m. records, playing the selections on the 1947 Delco phonograph. He surprised me with a record I’d forgotten we had: Jelly Roll Morton, late in his career, playing Willie “The Lion” Smith’s “Finger Buster;” B-side, “Creepy Feeling.”

We listened to “Creepy Feeling” first. Here was all of Morton’s legendary talent in one side–the ragtime and jazz piano styles he excelled in and defined. We had great expectations for “Finger Buster.”

This piece was also rendered with impressive virtuosity, but ultimately left us cold. The point of it seemed to be for the pianist to cram as many notes into every moment as possible, a challenge Morton met and bested. But getting all those notes in meant he discarded tone, mood, contrast–almost everything that makes a piece of music memorable. “Finger Buster” had no hook.

I’m reminded of “Finger Buster” when I look at some of the ways people write JavaScript. I see cryptic, single-character variable names, rigid adherence to object literal syntax, disdain for whitespace and for comments. Some people seem to treat their applications as the Web equivalent to the Apollo moonshot: everything must be rigorously minimized, milliseconds shaved off like millimeters, as if, say, the rendering of the lightbox on the regional sales division’s intranet login has profound, mission-critical implications.

Still others want to impress with their scripts’ obscuring structure. They don’t want you to understand it readily; they don’t want to provide the f*cking manual for you to read. They want to dazzle you with their finger busters.

Okay, time for a test.

Quick: hum the riff for the Kingsmen’s “Louie Louie.” Now do the same for any of Steve Howe’s solos on Tales from Topographic Oceans. Maybe a few of us can do the latter, and some would even prefer it. I confess to a bone-deep dislike for prog rock, and admit bias for “Louie Louie.” I’m not alone–which recording do you think has great influence?

The Kingsmen, “Louie Louie”.

Steve Howe in 1971 BBC documentary.

A trick question. Both do. Punk arose in the 1970s from both emulation of the do-it-yourself, technically simple example of 1960s garage bands like the Kingsmen, and contempt for the pretentious, technically complex example of prog groups like Yes. The original punks knew finger busting really doesn’t signify great music. If the music can’t make its point quickly, if you need lots of post-production and exotic instruments and huge concert venues to create it, and if nobody can easily recall what it sounds like, then it’s failed–doesn’t matter how many notes it has.

It’s high time finger busting JavaScript met its punk counterbalance. Too many blog posts, presentations, framework docs, and lines of code seem written with complete disregard for the basics of communication, as if hoarding information makes the writer more powerful. Just as you don’t need conservatory training to make good music, you don’t need an MS in Computer Science to write good JavaScript. My stress is on “good”–is it good if nobody understands it? If nobody can reuse it, add on to it? No. Web development isn’t a cutting contest. Let’s save finger busting for novelty records.

I Still (Heart) RichInStyle

I’ve been perusing a lot of job postings, which is, I know, inefficient, if my goal is to find a job, but it’s interesting to see what employers are putting in their requirements.

More and more frequently I’m seeing a call for skill with frameworks–not just for Ruby on Rails or Prototype, but also for CSS. There are by now a few of these to choose from: the skins for the Yahoo! User Interface Library, Blueprint, Nicole Sullivan’s “Object Oriented CSS” (excellent work, but oh! for a less trendy name), and so on. All of them: good to use. But it depresses me that employers don’t want to hire someone who can develop CSS by hand.

Hand tailoring
Photo by Bradley Allen

I’ve barely used any of the frameworks; I haven’t needed to. I guess I’m like a Savile Row tailor in preferring to make my own measurements and to follow my own procedures. But I can’t really say “my own,” since I was the benefactor of other CSS developers, those who worked in the earliest days of the technique—Web 0.9?—and discovered its patterns.

One of these pioneers was Matthew Brealey, who contributed to the W3C CSS discussion list. In between posts he maintained RichInStyle, a one-man compendium of frontend development tips and tutorials; I had it bookmarked, if not always open in a separate browser window. Brealey somehow had the time to investigate the browser support for every proposal in the CSS 1 specification; generously, or self-aggrandizingly, he posted his findings.

He also devised a way of writing a stylesheet that, with few adjustments, I still use. Brealey’s “Masterclass” show signs of age (remember uppercase element names?), but outlines one of the most logical ways to write CSS I’ve seen yet.

A couple of his most enduring principles are, simply:

  1. Use the cascade. Start with the most general rules at the top (HTML elements), and only then follow with those for classes and IDs. Put the toughest cases–the most obstreperous browser hacks–at the bottom of the CSS text, processed last.This rule seems obvious, but I can’t believe how many stylesheets I see beginning with class or ID rules.
  2. Ease human usage of the stylesheet with alphabetization. Brealey wrote before we had Firebug, or even View Formatted Source. Yes, we were flying with instruments in those days; you never knew where that pesky text color was coming from, nor why your document’s h3s were in italics. But a stylesheet organized as Brealey proposed gave up its secrets more readily: the rule for h3, for instance, would be reliably beneath that for a and above that for p, and its font-style would be beneath border and above margin. Maybe the importance of this approach has diminished as far as debugging goes, but it still shows thoughtfulness, the developer’s hand.

Developed by hand, old-fashioned; an artifact, not a commodity. Sure, I’m biased in favor of hand-tailored CSS, but then I’ve seen nothing but benefits from its skilled usage. Note “skilled.” It’s thanks to Matthew Brealey and others like him that I know what that means.