Ada Lovelace Day (#ALD13): Anca Mosoiu

Erika and I entered the wrong door at first, learning only by the flash displayed on the walls that we were in the tattoo parlor, not the conference room where we’d meet our client. Once within the appealing 1920s store front adjacent, we met a serenely smiling young woman welcoming us to Tech Liminal, Oakland’s first co-working spot. The space was so newly opened a fan blasted on “High” to disperse paint fumes. The décor was a mix of sleek tech and East Bay thrift; we felt right at home. Met the client, concluded our business, finished the project–and I kept returning to Tech Liminal.

I came to evenings about jQuery, Python, and WordPress. I watched a fascinating presentation about the Internet as used in Iran and Estonia. During the Occupy Oakland hurly-burly just a few blocks away, I went to a Meet-up all the same, even if a police helicopter felt obliged to follow me as I rode up Alice Street on my bicycle. When the Indiegogo campaign for Tech Liminal’s move to swanky downtown digs started, I didn’t hesitate to contribute.

Heck, yeah. Anything to help Anca Mosoiu.

Let me tell you a little about Oakland, California. We’re just across a bay from San Francisco, we’re about a third its size, and about half its population. News stories about Oaklanders tend to paint us as fearful crime victims picking through the rubble of a de-industrialized wasteland, California’s Detroit. In the last three or four years, though, Oakland’s received some positive attention for its lively restaurant scene and its (relatively) less overpriced real estate. The hipsters have conspicuously moved in. Oakland! San Francisco’s Brooklyn!

Those of us who’d been living here all along already knew this, of course. I wasn’t the only one who’d given SF life a good try, but came to Oakland to stay. We knew Oakland had wonderful qualities–redwood forests in the hills, reusable factory buildings on the waterfront, and inventive people all over town.

But what matters is what we did, which, for most of us, was pretty much nothing.

Anca had the courage, vision, and stamina to stand apart. She didn’t want to recreate the self-absorbed SF tech scene. She studied who works in tech in Oakland, and found a group distinct from the lookalike bros blathering about this month’s trendy JavaScript framework in South Park: people who work for small businesses. People who maintain blogs for their churches or non-profit agencies. People concerned about maintaining content in multiple character sets. People who are performers or artists, and need a higher level of digital literacy to promote their work. Oakland people.

I’ll never know how discouraged Anca felt as she struggled to establish a tech business not just in Oakland, but in the depths of the Great Recession. I’ll never know if she ever doubted her vision of Tech Liminal as community center, as more than rental space. One of Anca’s most admirable qualities is her steady, reassuring unflappability. Around someone like that you feel sure the future’s going to be fine. Maybe it won’t be slick, maybe it won’t rain VC money, maybe it’ll be next door to a tattoo parlor. But it’ll bring in other people, their energy and ideas, and soon enough the whole thing has greater momentum than a skateboard flying down Keller Avenue.

Thank you, Anca.

The ultimate responsive design challenge

Well, if nothing convinces you to take responsive Web design seriously, consider this: there are now approximately eight thousand special people poised to use your application. Eight thousand select, elite, affluent, early-adopter people, eager to purchase something new, something you can offer just to them. Eight thousand people who probably influence eight thousand others, and so on.

Eight thousand Google Glass users.

Think about it: does your application’s interface really scale down to the size of an average person’s eyeball? If you tore your hair out over the task of making a mobile version of your site usable and attractive, you’re probably tempted to ignore the vast problem of responsively designing for Google Glass for as long as you can. This would be a mistake, for it’s a great opportunity for a clever designer. You’ll be the toast of the Web, widely cited as an innovator, if you come up with any workable solution to this problem.

The main difficulty, of course, is deciding which areas of content to display first. Given the device’s extremely limited screen width, you’ll probably want to use infinite scrolling. User objections to this construct will most likely be fewer than in other contexts, since it’s by verbal commands, rather than hand-cramping mousing or touch events, that scrolling proceeds in Google Glass. Determining how to order your content is really the task of a prose or copywriting expert, but here are a few tips:

  • Require logins immediately. You want to make sure that you’re serving this interface only to registered users, people who have real commitment to your application. Otherwise, you’ll just get some tire-kickers who won’t pay for anything, and the expense you incurred developing this Google Glass layout won’t be justified.
  • Use short, punchy sentences, not long paragraphs. Google Glass users have just seconds to glance at your content, before they return to interrupted tasks like family dinners, driving on freeways, and sleeping. Take a hint from current presentation slide style: use short words, preferably with four letters, in all uppercase letters. Use slang and abbreviations liberally to save space and to communicate your point efficiently.
  • Add visual stimulus to keep your users engaged. At random moments, animate portions of the screen without requiring user input. Give the user a rest from the trying job of reading prose by strobing the display’s colors, or reversing light for dark values.

  • Take advantage of Google Glass’s audio output. Which of your users won’t like to hear uninterrupted background music as they scroll your content? You could even imitate the wildly popular practice of playing intermittent system announcements, which most of us are familiar with from calling service lines. Remember, as fashion-forward as Google Glass users are, they’ll still be reassured by your adopting familiar techniques from older media to help them navigate this exciting new technology.

Google Glass builds on technology devised in 1960s West Germany.
Google Glass builds on technology devised in 1960s West Germany.

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.

“Gazelles” eat hay, not grass

On 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

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 not driving for 25 years taught me about UX

One drizzly morning in 1988 I arrived at the infamous

San Francisco DMV office

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.


driving proved more important.

Try getting around the United States without a motor vehicle.

Asphalt Nation, by Jane Holtz Kay
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.

Here are some of my discoveries:

Places with more than one way to access them have greater vitality.

As Jane Jacobs pointed out, small city blocks encourage


and transit use. Places which permit access only by motor vehicle are dead-feeling and often

, which is why a high


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?

No, I am


going to watch your pointless branding animation, nor wait for your bloated JavaScript form validation script to load: I’m going to shop at your competitor’s site.

You can’t “set it and forget it.”

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


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.

Accessibility is pricey to build in…and exorbitant to bolt on later.

When the

Americans with Disabilities Act

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”

and be done with it, whereas true accessibility requires


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.

HTML5 Boilerplate Rolls Into Town

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

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

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

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

Build an ant!?

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

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

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

The jQuery Juggernaut

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

Image © the jQuery Project
New Wave JavaScript

Why jQuery has so many infatuated practitioners:

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

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

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

Blog Action Day 2010: Water

Yesterday I opened the fridge at home, and was astonished to find these:

1.5 Liters of Bottled Water

Fifteen, even ten, years ago, these items would be unremarkable in my kitchen. I might’ve even remembered purchasing them, rather than regarding them as puzzling stowaways. But thanks to the Web, I’m now enlightened to these harmless-looking bottles’ sinister nature. Each is a crystalline vessel of needless expense, inefficient resource usage, and toxic compounds . So how did they end up in my house?

Each bottle is an artifact from a conference. Each is the result of a conference organizer’s good intentions and relatively enlightened self interest. The original notion seemed to be concern for conference attendees’ physical comfort (“Keep hydrated through those long days of sitting in chilly, darkened meeting rooms! Here, take a bottle of water…”), combined with greater awareness of the ruinous health consequences of drinking soda, and the practices of corporate branding, to create the now ordinary half-liter water bottle such as you see here, and such as you probably have lurking in your own refrigerator.

How is this a problem? We got something for free, right?

Uh, no.  We’re paying for it,  whether we drink this water or not.

We’re paying for:

  • The delivery of so many single-serving bottles full of what is often just tap water
  • The janitors necessary to remove these used-only-once water bottles from conference rooms and wastebaskets
  • The energy inputs required to recycle these bottles, if that’s even available.  (To that conference’s credit, one of these party favors used 100% recycled plastic for its bottle)
  • The landfill space required to bury these bottles when recycling isn’t supported

And we’re missing a great opportunity for tech conferences to be as innovative as they claim to be in their publicity. Want to be truly “disruptive, or “2.0,” or “the future”? Hand conference attendees collapsible steel cups with the conference logo printed on them, and point the way to the drinking fountains.

I doubt we will notice anything missing from our fridges.