meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

The Widening Gulf

So many people who knew Rebecca told us how they had to hold back tears, watching the Super Bowl halftime show.  “I wish Rebecca could have seen it,” they say.  “When Katy Perry sang ‘Firework’, all I could think is how much Rebecca would have loved it.”

Rebecca loved Katy Perry songs, you see.  She loved to sing and dance to “Firework”, so much so that her sister Carolyn made it part of the medley she arranged and performed at Rebecca’s funeral.  And Rebecca loved to sing “Roar”, and pretty much anything from Katy Perry.  Even “Brave”, which is actually sung by Sara Bareilles, but when your terminally ill daughter tells you a song is by Katy Perry, then it’s by Katy Perry.

But all I can think is, I wish I could be so sure.

Because yes, five-year-old-going-on-six Rebecca loved Katy Perry, and Frozen, and hula hoops, and so many more things.  But by now she’d be six-and-two-thirds, and so much can change so fast at that age.  By now, maybe she’d have moved on to Taylor Swift, and Katy Perry would be so last year.  She might be done with Frozen, and instead be into Big Hero Six or The Emperor’s New Groove.

I know that she would be different by now, just as amazing as ever, but different.  Some enthusiasms would have given way to others; her interests would have shifted.  How, we don’t know.  Can never know.

Every day, she becomes a little more distant from us, a little less known.  A gulf slowly widens with the passing of time, and what she would be now becomes ever more uncertain.  We become estranged from our own daughter, not by hurtful words or actions, but by the merciless passage of time, by the choices she never got to make, the changes she never experienced.

I knew that this would come, but for a time I could ignore it.  A month or two after she died, I could still pretend that I knew how she would react, what she would think, how she would behave.  Even though I never knew that with any certainty.  She was never so predictable as that.  Never so static.

Now it’s been too long.

And it hurts, knowing that I can never know the girl she would be now, never know the girl she would have become, never know the woman she would have been.

I miss her, sometimes more than I ever thought possible, so much that I can physically feel the absence.  But sometimes I think what I miss more than the Rebecca I knew is the Rebecca I never got to know.

Friday Figure

Just for fun, and maybe for a little bit of edification, I present to you one of the figures from the chapter on color, backgrounds, and gradients I’ve just finished writing for CSS: The Definitive Guide, 4th Edition.

This figure is (at the moment) captioned “Very, very tall ellipses”; it’s a diagram of what happens if you create a radial gradient with no horizontal sizing.  (Whether you also have vertical sizing is actually irrelevant.)  The ellipses all get so incredibly tall that you only see the sides at their most vertical, which results in the appearance of a mirrored horizontal linear gradient.  This is of course explained in more detail in the chapter, and builds on a whole lot of previous text.

I had a much simpler version of this figure before, and shared it with Sara Soueidan, who had some very smart feedback that helped me get to what you see above.  The figure was finished not too long before i posted it; once it was done, I realized really liked the look, so decided on the spur of the moment to post it.  Thus the late-Friday timestamp on the post.

While the figure is a PNG, it’s actually a screenshot of an HTML+CSS file displayed in a browser—Safari, in this particular case, though most are done in Firefox.  All of the figures in the book will be created using HTML+CSS whenever possible.  Doing so lets me make sure I understand what I’m illustrating, and also allows me to change the look and arrangement of figures without too much difficulty.

So that’s fun with edge cases for this Friday.  If people like it, or more likely I just feel like doing it, I’ll post more in the future.

Run, Salmon, Run

I was recently asked on Twitter about the status of the fourth edition of CSS: The Definitive Guide.  A fair question, given how long the project has lain dormant!  I have two things to announce on that front.

The first is that I’m really excited to say that Estelle Weyl has joined me as co-author for the fourth edition.  We’re working in parallel, tackling individual chapters and doing technical review of each other as we work.  Sharing the load, especially with someone as sharp and knowledgable as Estelle, will help get chapters out faster, and the overall book done sooner.

The second is that writing is once again underway, with four chapters in process.  I’ve got the transforms chapter done, and the backgrounds and gradients (and maybe foreground colors too) chapter almost done.  Estelle is nearing the end of transitions and animations, with flexbox up next.  What comes after that for each of us is a little bit up in the air, though I’ll probably tackle basic visual formatting next.  Unless I get distracted by something more interesting, of course—truth be told, I’ve been eyeing grid layout with some covetousness in my heart.

So, the book is once again underway, and actually has been for a little while now.  I can’t say with certainty when we’ll be done and ready to compile everything into the Doorstop Edition, but we’re pushing for this year or early next.

As an offshoot of this renewed push, I’ve been expanding and revising my CSS test files so that I can check my understanding of the specification, as well as test the fine details of browser support.  Over the holidays I decided, more or less on a whim, to commit the whole kit ‘n’ kaboodle to Github.  There’s no license and no readme, mostly because I didn’t think to establish either when I set up the repository.  Sorry, I guess?  In any case, I regard the CSS in the tests to be public domain, but the actual content (whether inline or replaced) of the HTML files may or may not be, so a single license would have been hard to assert anyway.  I mostly put the files up there as a form of open backup, and also to smooth out the process of managing updates to the tests between my local machine and meyerweb.  Feel free to make use of the tests for your personal education, though!

Writing for The Pastry Box

I’m beyond pleased to note that my second piece for The Pastry Box, “Words, Words”, was published last week.  The first, “Sunrise, Sunset”, was published a month before that.  (It’s not about what you might think—and yet, and the same time, it is.)

For those who aren’t familiar with The Pastry Box, it describes itself thusly:

Each year, The Pastry Box Project gathers 30 people who are each influential in their field and asks them to share thoughts regarding what they do. Those thoughts are then published every day throughout the year at a rate of one per day, starting January 1st and ending December 31st.

It’s become much more than that, in my eyes.  In a lot of ways, The Pastry Box has become a place where writers feel free to stretch themselves and their writing, and to look at themselves and what they do in new lights.  It’s an incredibly valuable resource.  There are thoughts in their archives that touched, moved, and changed me.

I was invited late last year to be a contributor to The Pastry Box in 2015, and of course I said yes.  I accepted the invitation for a couple of reasons.  The foremost reason is, of course, the honor of being a Pastry Box contributor.  Over the past few years, they’ve had some of the greatest minds and writers of our field participate.  That’s even more true of this year’s roster, and I am completely humbled to join them.  The fact that this is the last year of The Pastry Box wasn’t actually a factor, as I’d have said yes in any year.

The second reason is that I’m very interested to see how I write in an environment where there are no comments.  No doubt this marks me for an anachronism, but it has literally been decades since I wrote for an online outlet that didn’t support reader comments.  That ever-present feedback channel is something I value, which is why I still support comments here, but I’m sure it’s affected how I write.  Not negatively, or even necessarily positively—it just affects the writing, or so I believe.  Over the course of 2015, I hope to find out if I’m right about that.

If you’d like to follow along, please follow The Pastry Box via RSS or Twitter (or both, as I do).  Not just for my few thoughts, of course, but for all the amazing contributors this year.  Already there have been insightful, funny, and deeply personal stories, and a new thought comes fresh-baked every day.  That’s why I’ve followed them in year past, and why I am still amazed and honored to be a part of their final year.

Gradient List Bullets

CSS gradients are kind of fun.  I know, they’re a little clumsy at first, but I’ve found that with just a little practice, you can hand-author them without more than a brief refresher course on exactly how to structure the first part.  At least for me, as long as I can get the setup right, the color stops are a breeze.

As I’ve said in previous posts, gradients are images, just like a PNG or SVG or whatever.  That’s why you can write them directly into background properties and have them display.  The thing is, though, that you can use them anywhere a property accepts an image value.  Like, say, list-item-image and list-item.

Yes, that’s right: you can define gradient list bullets.  A test page I set up last week (and the screenshot shown nearby) demonstrates a few different possibilities, but there are so many more.

There are two major limitations I can see: one, you can’t layer multiple gradients together, the way you can with backgrounds.  You get one gradient image, and that’s it.  Two, this isn’t supported in Firefox, not even the nightly builds.  Every other desktop browser appears to support this, usually at least a couple of versions back, and a fair number of mobile browsers as well.  A bug has been filed by Boris—thanks, Boris!—so hopefully this limitation will fall away soon.

Fortunately, this is a textbook case of progressive enhancement.  You set the basic bullet style, then define something snazzier for browsers that can handle it (which is, again, most of them).  If your design somehow critically depends on the appearance of the list bullets, then you’ll need to use another approach.  Also, rethink your design.

A third limitation, one not nearly so momentous, is that the list bullets are kind of small as compared to the list items’ font size in most browsers, but a bit bigger in others (as Ana Tudor pointed out; thanks, Ana!).  So if you’re going to express yourself with list bullets, be bold and not too complex, and realize there will be some sizing differences across browsers.

A fourth limitation is performance.  If you make your gradients too complex, especially if they’re radial gradients, you may degrade the user experience, particularly on mobile.  As always, use your new-found power responsibly.  Thank you.

Media Queries

Thanks to a combination of my slow process of re-integrating into the web community and the Year in Review explosion at the end of 2014, I actually have some media appearances to tell you about.  (This is at least four times as weird for me as it is for you.)

Since I love the written word, I’ll start with the fact that I’ve been published at Slate Magazine.  As the whole Year in Review thing was going crazy viral, an editor at Slate emailed to ask if I’d consider republishing “Inadvertent Algorithmic Cruelty” with them.  I said I’d love to as long as I could revise the piece a bit, to which they readily agreed.  So I reworked the opening to be extra-clear about what had actually happened, gave it a closing that was better attuned to a wider audience than the few hundred web designers I assumed would read the original post, and they ran it.  (The headline was, I have to say, not my idea, but that’s how it goes in most magazines: editors write headlines.  I was at least able to suggest some tweaks.)

Shortly after that piece went live, I was asked to be part of a piece on Huffington Post Live about Year in Review (of course).  I was still in Tennessee when the segment aired, and our hotel’s wifi wasn’t up to the task of streaming video, but thankfully they were willing to have me on by phone.

I saved what I consider to be the best for last.  Jen Simmons just recently had me as a guest on The Web Ahead, where we talked for two hours about what my family has been through in the past two years, designing for crisis, Year in Review, what it’s like to have a story go viral on you, being intentional in the age of social media, new details about my AEA talk “Designing for Crisis”, the Metafilter dot, and a whole lot more.  Parts of it are emotionally difficult, but not too many.  We got pretty deep into what I’m thinking about design and where it should go, and in a few cases Jen posed questions that I couldn’t really answer, because they’re at or beyond the edge of what I’ve figured out so far.

Jen is such a great interviewer.  Not only did she ask great questions and then patiently let me ramble my way to answers, she brought really smart perspectives to everything we were talking about.  Listening to her observations and thoughts gave me several new insights into designing for crisis, and more.  You should listen to the episode, or to any of the shows in her archives, just to hear a master of the craft at work.

So, yeah.  This has all been very interesting for me.  At some point, I’ll probably write something about what it’s like to watch a story about you go viral, but for now, I’m enjoying the return to anonymity.  It’s left me time to think more about empathetic design, and to catch up with work and other people’s thoughts.  That’s the best part of this whole web thing: learning from others.  It’s why I got started with the web in the first place.  It’s why I’m still here.

Ramping Up

We were driving back home from our impromptu surprise family vacation in Tennessee, winding our way through the Appalachian Mountains, when I pointed out a long, steep ramp to nowhere branching off the side of the highway.  “What do you think it’s for?” I asked the kids.

They made some guesses, some quite clever, but none correct.  So I told them about runaway truck ramps and how they work.  I think they were vaguely interested for a few seconds; I got a well-isn’t-that-interesting grunt, which I’ll take as a win.  We swept on past, the kids went back to whatever they were doing before I’d interrupted them, and I kept my eyes on the road.

But I was still thinking about the runaway truck ramp, and how it’s a perfect physical example of designing for crisis.

I also wondered about the history of runaway ramps—when they were first implemented, and how many runaway vehicles crashed before the need was recognized and a solution found.  After I got home, I looked it up and discovered that ramps didn’t really exist until the 1970s or so.  Even if we assume that no vehicles lost control in the U.S. until the Eisenhower Interstate System was established in the 1950s (just go with it), that’s still two decades of what were probably some pretty horrible crashes, before a solution was implemented.

This is not to say that the ramps are a perfect solution.  A runaway vehicle can certainly crash before reaching the next ramp, and using a ramp is likely to damage the vehicle even under the best of circumstances.  A badly-designed ramp can be almost as dangerous as no ramp at all.  Still, a solution exists.

I feel like web design is at the pre-ramp phase.  We’ve created a huge, sprawling system that amplifies commerce and communication, but we haven’t yet figured out how to build in some worst-case-scenario features that don’t interfere with the main functioning of the system.  We’ve laid down the paths and made some of them look pretty or even breathtaking, but we’re still not dealing with the crashes that happen when an edge case comes onto our stretch of the road.

I’m trying really hard to avoid “information superhighway” clichés here, by the way.

I’ve been pondering whether to incorporate this particular example into my 2015 talk, “Designing for Crisis”—much will depend on how the talk stands after I go back through it one more time to tighten it up, and start rehearsing again.  If there’s room and a good hook, I’ll add it in as a brief illustration.  If not, that’s okay too.  It’s still given me another way to look at designing for crisis, and how that topic fits into the broader theme that the Facebook imbroglio brought to light.

I’m still trying to get a good handle on what the broader theme is, exactly.  “Designing for Crisis” is a part of it, but just a part.  Several people have told me I should turn that talk into a book, but it never quite felt like a book.  Sure, I could have stretched it to fill a book, but something was missing, and I knew it.  I thought there was a hole in the idea that I needed to identify and fill; instead, the idea was filling a hole in a context I hadn’t seen.

Now I have.  It will take some time to see all of it, or even just more of it, but at least now I know it’s there and waiting to be explored and shared.

Well, That Escalated Quickly

This post is probably going to be a little bit scattered, because I’m still reeling from the overwhelming, unexpected response to the last post.  I honestly expected “Inadvertent Algorithmic Cruelty” to be read by maybe two or three hundred people over the next couple of weeks, all of them friends, colleagues, and friends who are colleagues.  I hoped that I’d maybe give a few of them something new and interesting to think about, but it was really mostly just me thinking out loud about a shortcoming in our field.  I never expected widespread linking, let alone mainstream media coverage.

So the first thing I want to say: I owe the Year in Review team in specific, and Facebook in general, an apology.  No, not the other way around.  I did get email from Jonathan Gheller, product manager of the Year in Review team at Facebook, before the story starting hitting the papers, and he was sincerely apologetic.  Also determined to do better in the future.  But I am very sorry that I dropped the Internet on his head for Christmas.  He and his team didn’t deserve it.

(And yes, I’ve reflected quite a bit on the irony that I inadvertently made their lives more difficult by posting, after they inadvertently made mine more difficult by coding.)

Yes, their design failed to handle situations like mine, but in that, they’re hardly alone.  This happens all the time, all over the web, in every imaginable context.  Taking worst-case scenarios into account is something that web design does poorly, and usually not at all.  I was using Facebook’s Year in Review as one example, a timely and relevant foundation to talk about a much wider issue.

The people who I envisioned myself writing for—they got what I was saying and where I was focused.  The very early responses to the post were about what I expected.  But then it took off, and a lot of people came into it without the context I assumed the audience would have.

What surprised and dismayed me were the…let’s call them uncharitable assumptions made about the people who worked on Year in Review.  “What do you expect from a bunch of privileged early-20s hipster Silicon Valley brogrammers who’ve never known pain or even want?” seemed to be the general tenor of those responses.

No.  Just no.  This is not something you can blame on Those Meddling Kids and Their Mangy Stock Options.

First off, by what right do we assume that young programmers have never known hurt, fear, or pain?  How many of them grew up abused, at home or school or church or all three?  How many of them suffered through death, divorce, heartbreak, betrayal?  Do you know what they’ve been through?  No, you do not.  So maybe dial back your condescension toward their lived experiences.

Second, failure to consider worst-case scenarios is not a special disease of young, inexperienced programmers.  It is everywhere.

As an example, I recently re-joined ThinkUp, a service I first used when it was install-yourself-and-good-luck alpha ware, and I liked it then.  I’d let it fall by the wayside, but the Good Web Bundle encouraged me to sign up for it again, so I did.  It’s a fun service, and it is specifically designed to “show how well you’re using your social networks at a more human level,” to quote their site.

So I started getting reports from ThinkUp, and one of the first was to tell me about my “most popular shared link” on Twitter.  It was when I posted a link to Rebecca’s obituary.

“Popular” is maybe not the best word choice there.

Admittedly, this is a small wrinkle, a little moment of content clashing with context, and maybe there isn’t a better single word than “popular” to describe “the thing you posted that had the most easily-tracked response metrics”.  But the accompanying copy was upbeat, cheery, and totally didn’t work.  Something like, “You must be doing something right—people loved what you had to say!”

This was exactly what Facebook did with Year in Review: found the bit of data that had the most easily-tracked response metrics.  Facebook put what its code found into a Year in Review “ad”.  ThinkUp put what its code found into a “most popular” box.  Smaller in scale, but very similar in structure.

I’m not bringing this up to shame ThinkUp, and I hope I haven’t mischaracterized them here.  If they haven’t found solutions yet, I know they’re trying.  They really, really care about getting this right.  In fact, whenever I’ve sent them feedback, the responses have been fantastic—really thoughtful and detailed.

My point is that ThinkUp is a product of two of the smartest and most caring people I know, Gina Trapani and Anil Dash.  Neither of them comes anywhere close to fitting the Young Brogrammer stereotype; they are, if anything, its antithesis, in both form and deed.  And yet, they have fallen prey to exactly the same thing that affected the Year in Review team: a failure to anticipate how a design decision that really worked in one way completely failed in another, and work to handle both cases.  This is not because they are bad designers: they aren’t.  This is not because they lack empathy: they don’t.  This is not because they ignored their users: they didn’t.  This is such a common failure that it’s almost not a failure any more.  It just… is.

We need to challenge that “is”.  I’ve fallen victim to it myself.  We all have.  We all will.  It will take time, practice, and a whole lot of stumbling to figure out how to do better, but it is, I submit, vitally important that we do.

July 2015
SMTWTFS
June  
 1234
567891011
12131415161718
19202122232425
262728293031  

Archives

Feeds

Extras