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

Posted on: by mejarc 3 Comments
  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.

Tears,
Melanie

Stop arranging developers like the typing pool

A couple weeks into the project, and despite my access to the issue tracking system, the project wiki, and the code repository, I still felt uneasy–there was something I was missing, but since I didn’t know what that was, I couldn’t ask for it. Coffee? Water? Multiple monitors? Appealing snacks? Had all those. I stood above my workspace, and then figured it out:

We were seated all wrong.

All of us on the development team were placed into cubicles arranged into a herringbone pattern pointing to one side of the room. Our faces turned about 25° towards one other person. I became familiar with the backs of many of my co-workers’ heads, since that’s much of what I saw of them all day. It was a bizarre arrangement for the kind of work we expected to do, since it discouraged interaction: you didn’t want to walk up behind someone and tap him or her on the shoulder for just any old thing.

Of course, interruptions are ruinous to developer productivity, but so is
isolation. There was a lot of context missing for me on this project, because it wasn’t available through the commit comments, and asking for it on chat would’ve required my knowing who to ask for what. I was slower to contribute because I couldn’t overhear relevant chitchat and couldn’t catch the eye of the project lead when I had a question, the most urgent one being: why were our workspaces arranged so stupidly?

I envisioned some workmen arriving one morning with a bare sketch of a floor plan in hand, and a general work order: “Build X number of cubicles from this pile of parts.” They weren’t told who’d work in the cubes, nor what was important to us. They acted from assumptions that seemed reasonable, but were still flat-out wrong.

One was that we all needed to have visual contact with one certain thing at one end of the room. Most of us have experience with this kind of arrangement, since it’s how we sat when we attended school. It’s also how clerical workers’ desks were often placed in early open plan offices. Management enjoyed this arrangement, since it permitted easy surveillance of those notorious insubordinates, schoolchildren and women. Placed side-by-side, we have less interaction with our peers, and more with the authority figure at the end of the room. But here in a twenty-first-century cube farm, there was no teacher on a dais to please. Why were we all facing the same way?

To watch a movie? Or perhaps a more sinister activity?

We have always been at war with SVN

The project never required the Two Minutes Hate–well, as far I could tell. Who would’ve tapped me on the shoulder to let me know?

Thrills! Chills! It’s InstallFest!

Last weekend brought the latest RailsBridge workshop to San Francisco (man, these workshops are really gaining momentum–there’s yet another one already scheduled for December 3-4. And, yup, it’s waitlisted). This time I ventured beyond my usual semi-skilled volunteer roles by offering to help workshop participants install the software required for the workshop. At last I felt comfortable enough with the process of getting Rails up and running that I wanted to assist novice programmers with the heinous chore fascinating challenge. Never thought I could do this–and it was thrilling when I did.

“InstallFest” is the happy-face designation we give the Friday night slog before each Rails for Women workshop. All participants must attend so it can be verified they have the appropriate dev environment set up on their laptops for Saturday’s curriculum. I attended InstallFest myself at the very first workshop over two years ago, and I still remember how frustrating it was for me: what are all these commands? Why do I keep getting error messages? And how come we can’t just install Locomotive or InstantRails and get it over with?

"Railsbridge installfest," by Romy Ilano

I’ll take the last question. Workshop attendees, here’s one reason why we don’t want you just pointing and clicking into a working Rails setup: we’re selfish.

Yeah, you might’ve thought all these volunteers watching over your shoulder as you type a lot of gibberish into a console window were selfless angels propelled by righteous sentiment to help you gain entry to the exclusive community of Rails developers. Well, sure, we are, but fundamentally, we’re…

Rails problem vampires.

Didn’t you notice how exciting we found the error messages in your terminal window? How about when we hopped up and down, shouting about malformed Gemfiles? And when two or more of us elbowed each other to peer at that mystifying line of code on your laptop screen–rake aborted (is that legal?), maybe you suspected.

“Hmmm,” you thought. “These people really want to expose me to all the gears, widgets, and thingamajigs that make up Rails, even if those don’t always work.”

My gosh, you saw through it, didn’t you? Your intuition is valid–at InstallFest you were surrounded by people who wanted to know where the installation process breaks down. You couldn’t even see all of us problem vampires–some were watching from afar, via discussion lists. We yearned to see where the instructions confused you and which of those d*mned Ruby gems didn’t load. We can’t make the installation a point-and-click process: there are technical constraints, for one thing, but more importantly, it would deny us that rich diet of error messages we crave and require.

You won’t need to bring a necklace of garlic or a wooden stake to attend InstallFest again. No, perhaps instead you will volunteer, twice, many times. Gradually, painlessly, unnoticeably…you, too, might also become a Rails problem vampire.

Why there’s always a waiting list for the RailsBridge outreach workshops

Seemingly moments after the announcement on Meetup–maybe it’s really as long as three hours–about the latest RailsBridge outreach workshop, there’s a waiting list of women really, really interested in attending, but just a hair too late in registering. Why are these workshops such hot tickets? After all, they’re just a few austere hours spent hunched over laptops learning the rudiments of programming with Rails–the instructors are volunteers from the local Ruby community, the venue is a generous sponsor’s office, and the participants don’t even pay tuition. What’s the draw?

  • Women want to get behind keyboards. There are many women-only tech industry events. However, most of these are mixer/networking occasions, not hands-on programming fiestas. They’re great for meeting people in potentially useful categories–ever notice how many recruiters are female?–but less beneficial if the question you’re mulling is better answered pair-programming with a Terminal window open.

The RailsBridge workshops offer women events that are “less talk, more rock”: each attendee uses her own laptop to create her own Rails application. People do bond over the several, often frustrating, moments of the workshop’s evening-and-a-day, so the networking component is present as well.


RailsBridge at Pivotal Labs. Photo by railsbridge


  • Attendees know they won’t get bullied, no matter their level of expertise. Each workshop announcement notes that total newcomers to the Rails framework–and to programming in general–are welcome. The tone of the workshop’s announcement makes it clear that attendees may ask questions, or even admit to confusion, without being shamed or mocked or otherwise treated as low-status.

Sudo make me a sandwich
photo by king-edward

One benefit of the all- or nearly all-woman format is avoiding that chest-beating, alpha geek braggadocio some men feel strangely compelled to perform at technical gatherings. It’s a behavior that bewilders women–is this true aggression, or bluffing?–and usually serves to shut us out while we try to figure out an appropriate response. The RailsBridge workshops are delightfully free of this nonsense.


  • The event’s time commitments are obvious and reasonable. Here in the Bay Area we have many opportunities for group programming–there’s a Hack Night, a Hack Day, a Hackathon, a CodeFest, always, somewhere. But some of these events don’t seem to have set hours, or if they do, they’re demanding a big chunk of a weekday night. Since most women, even the childfree, work a “second shift” maintaining our households, we’re not really free after our paying jobs to go to events with ambiguous starting and ending times. And if we’re trying to rise early the next day to get kids to school and/or ourselves to a morning workout, weeknights are out of the question. The RailsBridge workshops always have the format of a Friday evening devoted to installing the required software, followed by Saturday’s workshop. Though participants may forsake some weekend revelry, it’s less burdensome to the average woman’s schedule.

  • The event has a defined agenda. It’s nice to see programming events promoted as “newbie-friendly,” or “all levels welcome”–but they’re still intimidating to attend when you’re a novice, don’t consider yourself a “hacker,” and you have no personal project to “show off” as “disruptive” or whatever adolescent adjective is being overused this month. The RailsBridge attendees feel encouraged because they know in advance how the workshop proceeds and what everybody will be doing. They don’t have to arrive with anything besides their laptops.

The next San Francisco RailsBridge Outreach Workshop for Women is October 21-22, 2011. And, yes, there is a waiting list.

“Gazelles” eat hay, not grass

On Good.is the popular posts today include “15 Percent of Americans Are Now on Food Stamps”. I’ve visited the site twice this Monday, once just after the New York Stock Exchange started trading this morning, and now after the market close, as the story of our dismal economy’s enduring lifelessness makes headlines everywhere. In today’s more optimistic forenoon, I read Tim Fernholz’s “Hunting Gazelles: Figuring Out What Makes Companies—and Jobs—Grow”. Some of the points in that article bugged me then. They really irritate me now.

The post is an interview with scholar Tim Kane, who proposes that new jobs in the U.S. economy come from “gazelles,” quick-moving, fast-growing, young businesses. I don’t quibble with this entirely; I’ve seen how many Bay Area tech businesses seem desperate to hire enough people to support their rapid expansion (though–ahem–not desperate enough to modernize their hiring practices). Yet just after sharing convincing data about the remarkable contribution “gazelles” make to the employment rate, Kane veers into territory more familiar to subscribers to Reason than to Good.is:

Photo by Swamibu

There are real structural impediments to starting a firm…Labor regulations can make it difficult for entrepreneurs to even leave, and difficult for firms to hire more people.

The [Sarbanes-Oxley accounting law] is particularly galling because it seems like its[sic] killing off our IPO industry. Without an IPO or the promise of an IPO on the horizon, why start a tech company?

Alright, where to begin?

Let’s start here: one man’s regulation is another’s unemployment insurance, worker’s compensation, and minimum wage law. Your “structural impediment” is my workplace safety standard, whistleblower protection, and equal opportunity legislation. Think Sarbanes-Oxley is galling? Try having your retirement savings wiped out overnight by corporate fraud.

There’s a stubborn belief in the startup world that it’s 100% self-made, boot-strapped, that the “gazelles” broke away from the encumbrances of the herd and now thrive on the nourishing wild grasses of the entrepreneurial savannah. If this were so, why are there so few, if any, gazelles in places with fewer regulations? Why do tech bubbles form again and again here in the Bay Area?

You could re-read Richard Florida, or you could remember this:

“Gazelles” eat hay, not grass.

Meaning: “gazelles” rely on the infrastructure all of us provide. This isn’t just WiFi, Blue Bottle Coffee, and a spot on the CalTrain bike car. It’s also those “structural impediments” like environmental regulation (can you drink the water out of the tap?), public health initiatives (when’s the last time you worried about polio?), and anti-corruption laws (do you have to bribe someone to launch your product?).

Yes, it’s admirable to watch gazelles leap gracefully to such heights. But let’s not forget the haystacks we shore up to feed them.

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.

What the Web industry could learn from my Tower Records jobs

Minimum wage. A good chance you’d have to work until after midnight on New Year’s Eve, and then at 8:30 AM on New Year’s Day (happened to me). Boring, unglamorous duties. Dealing with clueless, irritating, or just plain drunk customers. So what was it about working at Tower that makes us former employees so nostalgic about it?

There’s a lively group on Facebook just for veterans of the San Francisco store at Bay and Columbus. The wall refreshes almost daily with someone’s anecdote, relevant link, or “whatever happened to…?” query. I don’t remember my stints working at Tower stores as nonstop fun, but I share these people’s eagerness to talk about it, decades after the experience. What was so magical, then?

  • People really shine when they’re allowed to specialize. Russ Solomon’s most impressive innovation with Tower Records was to stock a few copies of many titles, in many music genres, rather than stock a lot of copies of a few titles in only, say, rock ‘n’ roll. Customers came to believe that a recording didn’t exist if it wasn’t in stock at Tower. The huge inventories meant that Tower stores ballooned into multi-story, multi-department shrines to music retailing, staffed by people with deep knowledge of particular genres.

At the Tower store in Washington D.C. we had the king of the soul music department upstairs, a nebbishy white guy with years of data on singers, musicians, and producers committed to memory. Downstairs in Imports we had Neal, who pored over record company newsletters to sift out which nearly unobtainable European releases he could order for the store. Both of these guys had a number of fans among the customers, who would seek them out as kind of personal shoppers. Nobody ever suggested moving these guys to other departments, so they could get more acquainted with other kinds of music.

In the Web industry we’ve come to dismiss specialties for creating “silos.” We demand that people “cross-train,” “take responsibility for the full stack,” as if specializing creates some kind of weakness. But whose customers seek out the generalists on the team?

  • Money isn’t everything… Wages at Tower were lousy. You started at minimum wage, and obtained tiny raises at infrequent intervals. There wasn’t much room for negotiation: if you didn’t like the arrangement, tough–there was a waiting list of people eager to take your place. So what was the draw?

On the job at Tower D.C. Photo by Madeleine Morrissey.

At Tower we felt we could be ourselves. We could wear pretty much anything, style our hair any way, talk passionately about the music, books, or movies we really cared about–we didn’t have to pull back to fit in with someone’s idea of the workplace’s culture.

  • …But it is something. As grateful as we were to Tower for providing us such a cool, accepting workplace, none of us would’ve worked there “for equity.” For one thing, a lot of us were deep into other non-paying pursuits like playing in obscure bands or writing terrible poetry, and to pull our attention away from these tasks Russ Solomon et al. had to pay cash. For another, working at Tower involved–work. Employees were still required to do things we thought boring, stupid, uncool, and beneath our adolescent dignity. Compensation was a motivator.

  • Working part-time is okay. Many of us at Tower were still university students. May through August, hey, pile on the hours…and come September, not so much. Rather than deal with massive attrition every fall, Tower managers adjusted schedules to fit employees’ lives (not vice versa). There were sufficient full-time employees to staff the less desirable weekday shifts. Nobody was accused of lacking “passion” or “commitment” for requesting a part-time schedule, nor demoted when it was obtained.

  • Company culture must reflect the people currently working there. When first opened in 1967, the Tower San Francisco store at Columbus and Bay had groovy, Summer of Lovin’ employees who probably said things like “Deep!” and “Far out!” without irony. Twenty years later, it was staffed by edgy kids in leather and Mohawks who slapped a video of Woodstock in the store VCR to watch for laughs. Had Tower insisted on keeping its original flavor of tie-dyed mellow, it would’ve repelled prospective hires with fresher ideas about music.

It’s common in Web companies to whine of “growing pains,” which usually turn out to be resistance from earlier employees to requests for working space, documentation, and professionalism from newer ones. By this point, the company is radically different from what it was at its founding, so why retain that atmosphere?

  • Even companies that do these things can still fail… Tower dwindled into bankruptcy by 2006, undone by online music sales. It did scramble to build a Web presence, but there was little to deter customers from buying instead at Amazon or iTunes–after all, where was the personal touch of people like Neal?

  • …but this is no reason to avoid trying them out.