Tag: tools

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.

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:

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.

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’sresponse 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

Do you use source control?

Can you make a build in one step?

Do you have a bug database?

Do you fix bugs before writing new code?

Do you use an issue tracker?

Do you have requirements before writing user stories?

Do programmers have quiet working conditions?

Do you have testers?

Do you purchase the exact tools your programmers request?

Do you use Agile methodologies?

Do you use only open source software in your application stack?

Do your developers have their own tech blogs or present at meetups?

Do your designers work only in Photoshop/graphical editing software?

If I dropped in here some random weekday night at, like, 8:30PM, would your developers still be at their desks?

Would you give me a hard time if I wanted to telecommute one or two days a week?

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.

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.

There were two lines for service, one noticeably shorter than the other, and since I was already running late for work, I stepped into that shorter line. At my turn at the counter, I completed the paperwork for a state identification card instead of a driver’s license, which didn’t seem that important to me at the time, since it’d been already two years since I last drove a car, and now I lived in SF, which had
passable public transit. It wasn’t this grand activist moment for me, this kind of Damascus Road flash of insight–no, it was just my deciding that driving wasn’t very important to me.

And I was right.
Not

driving proved more important.

Try getting around the United States without a motor vehicle. Asphalt Nation, by Jane Holtz Kay Try it for a while. Try it while also attempting to sustain a career, relationships, household, your sanity. You will learn, as I did, very important lessons about how user experience can be structured to assist or thwart your journey.

and transit use. Places which permit access only by motor vehicle are dead-feeling and often
moribund, which is why a high
WalkScore

is becoming so attractive to potential buyers.

In Web terms, how many of us enjoy visits to sites which permit access only through needless Flash intros or
mandatory registration? These pages act like those guard kiosks in suburban gated communities. Or how about the sites with no provision for usage by mobile devices?

All over the United States, roads and transit systems are crumbling into unusability because of deferred maintenance. The jagged potholes in my neighborhood act as the speed bumps the City of Oakland can’t commit to installing in this dire period for municipal budgets. A couple blocks away, the once-handy AC Transit bus system runs fewer and fewer buses, thanks to
neverending budget cuts. Being stranded for 45 minutes waiting for the next bus after missing one by just seconds is a pretty common experience for us commuters.

Out there on the Web are so many undermaintained, tatty sites that I really don’t need to
link

to them. Outdated copyright date on the footer? “Best viewed in Netscape” graphic? Visual design so old it’s on the cusp of being retro-cool? Those are easy to remedy–if you commit time and money to fixing them.

passed in 1990, there was the usual unappealing backlash of nay-sayers claiming that the Act’s provisions were merely nice-to-have and too expensive to require. Despite that, the built environment of the United States changed rapidly to include curb cuts, ramps, and wheelchair-accessible bathrooms. Building owners whimpered about the expense of retrofitting for ADA-compliance; new construction posed the advantage of having these features built in from the start.

The question of Web accessibility arose pretty early in the
medium’s history, but remains incompletely answered. Too many site owners consider accessibility a “nice-to-have, but…”, or something at which you can toss a few inadequate
“alt tags”

how your application or site is used in different situations: can this site be used without a keyboard? Without a monitor? Without color contrast?

Making something accessible also makes it relevant to use cases we can’t anticipate. When I injured my knee in 1992, I sure appreciated those buildings with elevators and ramps. When I started browsing the Web on my Palm Treo in 2005, I admired those sites with text-heavy, low-graphics means of interacting with them.

You’re free to think you don’t need to accommodate a diversity of users, of course, just as you’re free to require a motor vehicle to access your physical location. And you’re free to destroy your own brand with slipshod UX. It’s a free world.

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.

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?

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.