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.

My Joel Test

This year, the Joel Test marks its thirteenth year (does it get a bar/bat mitzvah?) For all the publicity and parody it gets in developers’ media, it seems little-known elsewhere–I still get panicked stares when I ask about it in job or project interviews (“The JOLE Test? Is that one of these HTML5 things we’re supposed to be doing?! Maybe it’s that responsive design stuff! Must–nod–head–sagely…”) So, here’s what the Joel Test is, if this is the first you’ve heard of it:

In August 2000 software entrepreneur Joel Spolsky listed several questions he thought would reveal the quality of a software development team. Observers noted the list could become something a developer should ask a potential employer before accepting a job offer, because Spolsky’s questions focus on aspects of a programmer’s working environment that make enormous differences in job satisfaction, yet are rarely described in detail even at the interview stage. Each question can be readily answered “Yes” or “No”, and the complete list of answers could help a programmer determine whether a particular job offer includes things important to her.

Here’s the Joel Test below, but I encourage you to read Spolsky’s justifications for each list item.

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

I’ve never worked on a project that would pass the Joel Test. I’ve worked on some projects that rated only seven Yes answers, but they were indeed better experiences than the ones who rated even lower. My 2013 resolution is to join a project that garners at least eight Yes answers on the Joel Test–doesn’t even have to be an A+, just eight skimpy “Yes” answers.

A useful supplement to the Joel Test is software engineer Julie Pagano’s response to recruiter spam unsolicited queries, which doesn’t just list what she values in a job, but weights each in importance to her: is the job far away? Involving Windows? Assumed to be the only thing in a developer’s life? I see many items on Pagano’s list which could be on many of ours; I hope recruiters do see her post and take note of what’s really important to candidates (short answer: it’s not foosball).

Combining the two approaches, I emerge with this:

My Joel/Julie Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you have a bug database?
  4. Do you fix bugs before writing new code?
  5. Do you use an issue tracker?
  6. Do you have requirements before writing user stories?
  7. Do programmers have quiet working conditions?
  8. Do you have testers?
  9. Do you purchase the exact tools your programmers request?
  10. Do you use Agile methodologies?
  11. Do you use only open source software in your application stack?
  12. Do your developers have their own tech blogs or present at meetups?
  13. Do your designers work only in Photoshop/graphical editing software?
  14. If I dropped in here some random weekday night at, like, 8:30PM, would your developers still be at their desks?
  15. Would you give me a hard time if I wanted to telecommute one or two days a week?
  16. Can I get to your office from Oakland by transit within 45 minutes?
    Red indicates a failing test.
    Red indicates a failing test.
  17. Can I bring my bicycle to work?

What’s on your Joel Test?

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

Why I’m celebrating the 40th anniversary of Title IX

When I was eleven years old, I was determined to overcome the twelve months of shame which had dogged me since I was ten: I would not, I vowed, come in second place again in my leg of the 60-yard relay at the Yavapai County All-Schools Track Meet. And so it was that, one chilly spring day, I carried the baton to first place.

Yours truly, age eleven. Note the competitive advantage offered by Sears Toughskins.

Preceding that moment were numerous others filled with coaching, practice, a change of shoes from my preferred hiking boots to snazzy Adidas, and the passage and enforcement of Title IX legislation, which forced the Yavapai County school districts to offer girls’ sports on par with those offered boys.

I went on to run track and cross-country all through junior and senior high school. Don’t even try to convince me I could’ve had these opportunities had we relied on voluntary concessions to fairness, or “market forces”–I did not get these coaches, facilities, training, and competitions because they were “the right thing to do,” or because they expanded a sales region. I, and every other girl in Arizona, got them because the federal government threatened our local school districts with penalties if we did not.

At the time Rep. Patsy Mink (just one of a stellar group of righteous, kick-ass female legislators at the time) was drafting a bill that became Title IX, few high schools would trained girls for much beyond cheerleading–one of my coaches recalled never having run on a track before she went to junior college in 1970. Fortunately, the application of Title IX reached beyond university and high school levels, to even right down to elementary schools. Were it not for Title IX, I would not have been just ten years old when I ran in my first track meet. I might have never run in one.

Let’s celebrate how far we’ve come by revisiting some of the arguments against Title IX. A common one was that girls lacked interest in sports. The belief seemed to be that if girls really wanted athletic competition, we’d insist on being included. So why waste all that money on something we don’t want to do naturally?

Another argument focused on how mediocre women and girls were as athletes. Because we didn’t run as fast or jump as high, we didn’t deserve coaching, equipment, nor opportunities to compete–we just weren’t going to inspire with our pokey ways on the track or playing field. Sports competitions, it seemed, would be endangered by admitting female bodies to them. And what was sport but a meritocracy? The winners didn’t have to be men and boys, but that’s just who was best, that’s all. Sport was open to anyone of any gender who could make the grade, wasn’t it?

Uh, unless it’s the Boston Marathon, or the 1500 meters in the Olympics, or the homecoming game played by my high school’s perpetually losing football team.

Title IX didn’t try to counter these rubbish objections, but among its effects was a gradual reduction in their acceptability. Forty years later, it’s hard to find a town in the U.S. without a girls’ soccer league. Female marathon champions are drawing closer in times to their male counterparts. And women now compete at the Olympic level in not just the 1500 meters, but in–get this–boxing.

Still, those nonsense notions exist, and the ignorant still voice them, only now they’re coughed up in discussions about women in computing.

Why don’t more women become programmers? Well, surely it’s because we’re not interested, or because we’re just not good at these computer-y things. After all, the tech industry is a meritocracy–if all you see speaking at conferences or leading tech groups are men, well, it’s because those are the people who are the best. If a woman wants to succeed like they have, all she has to do is work hard and apply herself…

I might sound despairing, but, really, I glow with excitement when I think about how outlandish those smug assertions will sound in forty years. By then, let every girl get her chance to run in an All-Schools track meet. And let every girl have her chance to join an All-Schools hackathon.

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.

The latest in HTML

No question, HTML5 is big news. It’s the subject of sold-out conferences, mobbed Meetups, and recent best-sellers. It’s even become a catch-all marketing phrase perfectly contoured to shove into presentation slides. But HTML5 better watch its back. There’s yet another promising HTML standard out there. It’s what you’ll want to use on your next project–hip, cool, and wholly cross-browser compatible.

Get ready; here comes HTML 3.2!

Whether you’re looking for a new front-end dev gig, or just trying to freshen up your skills, learning HTML 3.2 in the upcoming months will be crucial. Fortunately, it will probably be a skill you’ll enjoy using once acquired.

When you convert your legacy markup from HTML5 to HTML 3.2, you’ll find some elements familiar to you: <P> and <BODY>, for instance. The biggest task you’ll have is removing all that CSS cruft so you can take advantage of HTML 3.2’s many presentational tags and attributes, such as <FONT> and <CENTER>. You can also replace many lines of CSS rules by using <TABLE>, <TR>, and <TD> for layout (a technique possible in HTML5 as well, but rarely explored).

Other features of HTML 3.2 include the useful <BLINK> and <MARQUEE> tags, though, regrettably, these have poor cross-browser support. You will have to polyfill with JavaScript to assure that all users can access this content.

Attendance at the recent HTML 3.2 Hackathon was small but enthusiatic

If your legacy HTML5 code base is extensive, you might find the job of converting it all by hand a daunting challenge. This is a situation ready-made for a WYSIWYG editor. Software makers have taken notice of the opportunity to jump on the HTML 3.2 bandwagon; you’ll have your pick of user-friendly tools. The most popular choice seems to be Microsoft’s FrontPage. Adobe isn’t far behind with the PageMill application. If you have the Netscape browser installed, you’ll find its built-in Composer product easy to use for your cutting-edge HTML 3.2 project.

True, it can be frustrating sometimes to keep current. Just when you thought you knew the difference between <article> and <section>, along comes an HTML standard which includes neither. Yet think of the compensations–you’re not losing <canvas>, you’re gaining <LAYER>.

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.

Sh*t People Say to Front-end Developers

  1. We really don’t need a designer.
  2. What’s an information architect?
  3. Nobody will be looking at this page with a mobile device.
  4. This style guide from 2002 is still good.
  5. We really don’t need localization.
  6. This Excel spreadsheet is our issue tracker. Works great!
  7. Using Flash would make this so much easier!
  8. HTML5 is too risky and experimental.
  9. What’s a validator?
  10. Browser support? All of them, of course.
  11. We really don’t need a copywriter.
  12. Of course our users will sit through this thirty-second auto-play splash video.
  13. We really don’t need JavaScript testing.
  14. The database guy already did the HTML and CSS, so you just have to add a few tweaks.
  15. Of course our users will submit this twenty-question form before seeing our content.
  16. This will be a short project.

Letter to Gino Lee

Dear Gino,

I’d hoped the news was untrue. Surely it was unbelievable: how could you die? You were only forty-nine. You are only forty-nine–I’ll keep using the present tense. You’re still alive to me.

I have vivid memories of you from over ten years ago. There you are, apparently one of the last smokers in California, cupping a cigarette in your hand, trying to keep the wind tunnel outside the Metrius office on Brannan Street from killing your smoke, your characteristic, urbane, thin-man’s slouch a welcome profile in those garish, clumsy, overconfident, dot-com boom years. I remember your voice, deliberate, drawling, as you think aloud, treating every workday as one big Harvard grad seminar. I love the cultivated, wry tone of your e-mails and chat messages, proof that a keyboard doesn’t enforce simplistic language. Your one-line musing about the impact of the Rapture on the scrapbooking industry makes me laugh to this day.

I was too coarse to appreciate that we should’ve taken all the time in the world to talk, deadlines be damned. I know we disagreed when you seemed to think my staying late at the office was so that we could discuss Evelyn Waugh’s The Loved One . I profited from our acquaintance all the same.

From you I’ve learned that so much of our world can be made appealing. Your attitude towards the ugly and poorly designed isn’t snobbish condemnation, but gracious bewilderment: why use bad things? Why make them? You handled fountain pens in a world of dry erase markers.

But I and everybody saddened by this news have to let you go today, arm-in-arm with Miss Thanatogenous. I promise a longer conversation next time.