meyerweb.com

At last—at long, long last!—the results of the A List Apart Survey 2008 are available, along with the anonymized raw data we collected.

There are a great many reasons why it took so long to get this out the door. A big part is that it’s almost entirely a volunteer effort, which means it happens in our “free time” (and there the word “free” has a couple of meanings). I say it’s almost entirely a volunteer effort because the detailed analysis is actually done by a pair of professional statisticians, who are paid for their time and expertise. They did a great job once more, and did it in a reasonable time frame. It just took us a while to get them the data to analyze, and then a while longer to take their report and findings and process them into report form.

The biggest change this year is that we’re publishing the results as HTML+CSS instead of a PDF. This greatly increased the challenge, because it was important to me that the data be presented using styled tables, not images. That’s easy like cake if all you’re doing is putting them up as visual tables, and we certainly do that for some of the figures. In the other cases, where we have bar charts of varying kinds, things got difficult. I managed to devise solutions that are 99.9% effective, and I’m both proud of and frustrated by those solutions. Proud, of course, because I managed to wring three-stack bars out of table markup; frustrated because of the markup I had to construct to make them possible. I think this report represents more than half my lifetime usage of the style attribute, but unfortunately there’s no way (using just CSS) to say {width: content;}.

So why not use JavaScript to do that, or to just replace the tables with canvas-drawn charts? I did consider both, but decided that I would push as far as I could with plain HTML+CSS.

A few implementation notes:

• I used HTML 5 in order to step around some previously unrealized limitations of HTML 4—did you know tfoot has to come before tbody in HTML 4? I didn’t. I did not use elements like header and footer due to known problems in Firefox 2 and related browsers, which mangle pages containing those elements. Instead, I took the same path Jon Tan recommends, and classed divs using those names for later, easier conversion.

• The tables which underlie the charts do not have summary attributes. If a group of civic-minded individuals would like to write useful summaries, please let me know in the comments and I’ll let you know how best to submit them. Similarly, I did my very best to make sure all the table headers had accurate scope values, but if I botched any, let me know.

• I’m aware that Opera shows horizontal scrollbars on most chapters of the report. This is due to its refusal to apply overflow to table boxes, which according to my recent reading of the CSS 2.1 specification is the correct thing to (not) do. Every other browser I tested does apply overflow to table boxes, though, which I found most useful. I tried applying overflow: hidden to a few other boxes, and that got rid of Opera’s horizontal scrollbars, but it also cut off actual content in some other browsers. I chose a cosmetic problem in one browser over loss of content in others. The best fix I’ve devised is to wrap the tables in divs and apply overflow: hidden to those divs, but I didn’t want to rush the fix and botch it, so it didn’t make it in time for first publication. I expect to get it in shortly after publication.

• In a like vein, there are a few combo charts where a bar goes shooting off the right side of the chart in IE7. This appears to be due to some kind of width-doubling problem that’s only invoked on elements with a style attribute when the row header goes to two lines instead of being just one. Googling for an explanation yielded no joy, and a lengthy series of attempts to hack around the problem came to nothing. If anyone knows how to counteract that problem other than preventing the header text from going past a single line, I’d love to hear it. (Update: I’ve implemented the “fix” of preventing line-wrapping in the report, so there aren’t any off-the-page bars right now, but you can see an example of the problem on this test page.)

• Surprisingly, the charts mostly work in IE6. The exception is some of the triple-stack charts, where data points overlap when the rightmost sub-bars get too small, and also the double-width bars mentioned in the previous point. I don’t really have a fix for this short of upgrading the browser, but if somebody finds one, I’d be happy to test it out.

On that last point, if there are questions or suggestions surrounding the implementation of the report, we can certainly discuss them here. With regard to the survey and report itself, though—that is, the questions asked and the results we’re publishing—please direct those thoughts to the comments section of the ALA article announcing the report. I’m hoping that we’ll have the 2009 survey up within a few months, so comments on what we asked and how we asked it, what we didn’t ask but should have, and that sort of thing could well have a direct impact on the next survey. But please put those on the ALA site, where more people are likely to see them.

It’s done, it’s out, it’s yours—both the report and the data, about which I’ll soon write a little bit more. Read the report, or produce your own report using the data. Just always know that when we publish these reports, we do not mean for them to be the final word. No, what we always mean is for them to be the first words, a starting point, a place from which to grow. What comes next is as much up to you as anyone else, and I can’t wait to see what you do.

When I was in Boston earlier this month, one of the people I’d thought to hang out with was Jared Spool, and of course he was on the other side of the country while I was in his hometown. This was a bit of a downer but I figured, hey, we both speak a lot, so I’d see him again somewhere at some point.

And how right I was: the week after my return home, Dopplr informed me that he and I would both be in London for the first weekend in March. I’m there for the Carson Workshop I’m giving (and there are only a few seats left, so you should grab one while they’re still open) and he’ll be in town for reasons of his own. As will Dana Chisnell, it turns out.

How could we not act on this? So I pinged the folks at Carsonified and asked them if they knew of a venue where we could arrange some kind of meetup. They were not only glad to help out, they offered to organize the whole thing. The result: a Web Geek Gathering at the Pitcher & Piano Trafalgar on Sunday, 8 March 2009. Jared, Dana, and I are all planning to be there. You should plan to be there too. You should also RSVP because, unlike the web, there isn’t infinite available space. Not to mention I’ve heard rumors that there might be some manner of free drinks. I mean, I’m just sayin’ what I heard.

Hope to see you there!

Human beings say, “It never rains but it pours.” This is not very apt, for it frequently does rain without pouring. The rabbits’ proverb is better expressed. They say, “One cloud feels lonely”…

—Richard Adams, Watership Down

The past few weeks have been a bit more intense than usual. It all started on Inauguration Day, in fact, though that’s pretty much just coincidence.

It all started with a cold. Carolyn stayed home with a terrible cough and a slight fever, which meant she got to watch the inauguration with us. A couple of days later, she was fine, and Rebecca was sick. Nothing unusual about that, of course: you have two kids, they pass germs along to each other.

In Rebecca’s case, though, it didn’t seem to get better. By the time, a few days later, she spent most of an afternoon sitting very still on my lap, whimpering softly, her skin burning with fever, Kat started to suspect a common but serious childhood illness. A trip to the doctor confirmed it. The child in the next examination room had the same illness and was unlucky: two inhaler treatments had little effect, and he was sent to the hospital. Rebecca fared much better: one treatment and she was much improved.

That was lucky for us all, because we had a long road trip ahead of us. The night before Rebecca’s doctor appointment, Kat’s mother died after a very long and difficult illness. We had known it was coming, thanks to the hospice nurses. We had known for a very long time that this is how it would one day end. Most of the mourning had been done ahead of time, to be honest, but at the same time it’s never easy to lose a loved one, no matter how much you may have prepared.

We needed to be on Long Island by Sunday night. Plane fare was far too expensive, even with the bereavement discount. So we packed up the nebulizer, treatments, and everything else we needed to drive eleven hours to our hotel. Pennsylvania, as anyone who’s made the drive will tell you, goes on forever. It’s an even longer forever when you have to make extra stops, as will happen with four people, two of them children.

A very good friend of ours watched the girls as we attended the graveside ceremony, and we spent the next couple of days with Kat’s family as they sat shiva. And then we drove back to sit our own.

I had to be in Boston the following week for client work, and while a great many awesome things happened on that trip, it was hard to leave so soon after everything else. In the middle of everything else, really. I left on the second day of our two-day shiva; the rabbi finished his prayers and remarks and five minutes later I was pulling out of our driveway to catch my flight. And of course the illnesses, traveling, and general upheaval in our lives had pretty well shattered both girls’ sleeping patterns, and I couldn’t be there to help.

The day after I got back, Kat finally went to the doctor to see about her sore thumb. It turned out to be broken. She’s wearing a brace now. Two days after that, I quite unexpectedly suffered an anaphylactic reaction to a food I’d had many times before. It was the whole works, too: sore stomach, tightness in the chest and throat, dizziness, itchy hands, and, so my wife tells me, a blue tinge around the lips. It was a new and wholly unwelcome experience, I assure you. We’re not completely sure of the ingredient that caused it, but there’s a very strong candidate: avocado. So no more guacamole for me, it would seem.

All that knocked me even more offline than usual, which is why further writings about HTML5, CSS3, and other topics of note have persisted in collectively playing the parts of Sir Not-Appearing-On-This-Site. I’m hoping that by getting all this off my chest, I’ll clear up some of the blockage and get things moving again.

So how about you—what’s the first month-or-so of 2009 been like for you? If it’s been similarly stressful, unload and lighten the burden. If it’s been good, tell us about it so we can all share a little bit of uplift. I know I could use a little!

Hey all, and especially those of you in the EU: I’m going to be doing an all-new one-day workshop in London in early March via the offices of Carson Workshops, for whom I’ve done workshops in the past. Previously I’ve done two-day gigs with a beginner-to-intermediate skill range, but this time we’re trying something different. I’m going to get down and dirty with some tough topics, and really push hard at the limits of what CSS and semantic markup can do.

You can get the details at the CW site, and note the special price for the first quarter of the seats. That’s right, this will be a small, intimate workshop, with plenty of chances for questions about and challenges to what I’m saying. Previous workshops have featured some really great conversations among everyone there, and I expect the same this time around.

I had meant to blog this before life intervened and took me out of my wifi cloud (and more on that soon), so time is a little more of the essence than usual—if you know someone who you think might be interested, pass the word on, willya? Thanks!

The Robot speaks truth: I will be visiting the northern reaches of the greater Boston area in the first few days of February to do some client training (which is one of the many things I do). To celebrate, I’ve managed to pull the Markup & Style Society (which of course includes that simplest of bits, the inestimable Mr. C.) out of hibernation, get them to link up with the Build Guild, and have the two jointly sponsor a gathering open to all who wish to join us. Welcome to the social!

This massively meritorious meeting of minds will take place on 2 February 2009 in historic Salem, MA: here’s the Upcoming entry with all the details and RSVP action. If you plan to be with us, make your voice heard. Or, if you’re the fearsome and mighty Windhammer, who rumor has it may also be there, bring forth thunder! On the Upcoming page.

Hope to see you there!

Even though it turned out that there is no simple solution for the math problem I posted, I learned a fair amount from the fantastic responses—thanks, everyone!—and eventually came up with a solution that worked for me. (I’d like to say it was one of the iterative approaches posted, but none of them worked for me. In the end, I brute-forced it.) I’m hoping for a different outcome with my next question, which is about JavaScript.

Consider the following structure, which is a much-edited-down version of part of the HYDEsim code:

function Detonation(name,lat,lon,yield) {
    var scale = Math.pow(yield,1/3);
    var gz = new GLatLng(lat,lon);
    this.name = name;
    this.lon = lon;
    this.lat = lat;
    this.gz = gz;
    this.yield = yield;
    this.overpressure = {
        p30 : 0.108 * scale,
        p15 : 0.153 * scale,
        p10 : 0.185 * scale,
         p5 : 0.281 * scale,
         p1 : 0.725 * scale
    };
    this.psi30 = {
        radius: 0.108 * scale,
        overlay : {
            points: makePoints(this.gz,0.108 * scale)
        }
    };
    this.psi15 = {
        radius: 0.153 * scale,
        overlay : {
            points: makePoints(this.gz, 0.153 * scale)
        }
    };
    this.therm20 = {
        radius: thermDist(20,this.yield,0.33,conditions.visibility),
        overlay : {
            points: makePoints(
                this.gz,
                thermDist(20,this.yield,0.33,conditions.visibility)
            )
    };
    // ...and so on...
}

There are two things I’ve tried and failed to do. And tried, and tried, and tried; and failed, and failed, and failed.

1. Eliminate the redundant calculations of radii. Note how I define a radius property in each case? And then have to not use it when I create the overlay? It seems like there must be a way to just define the value once for each subsection and then use it as many times as needed within that context. How?
2. How do I make it so that all those properties and overlays and such automatically recalculate any time one of the “upper-level” terms changes? As in, once I’ve created a new Detonation object det, how can I set things up so declaring det.yield = 250; will trigger recalculation of all the other pieces of the object? At present, I’m just blowing away the existing det and creating a whole new one, which just seems clumsy and silly. I have to believe there’s a better way. I just can’t find it.

Please note: tossing off comments like “oh, just instantiate a mixin constructor with an extra closure” will be of no help at all, because I don’t understand what those terms mean. Hell, I’m not even sure I used the words “object” and “property” correctly in my explanation above. Similarly, pointing me to tutorials that use those terms liberally is unlikely to be of help, since the text will just confuse me. Sample code (whether posted or in a tutorial) will help a great deal, because it will give me something to poke and prod and dissect. That’s how I’ve always learned to program. Actually, it’s how I’ve always learned anything.

As well, I’m absolutely willing to believe that there are much, much better ways to structure the object, but right now I really need to learn how those two things are accomplished in the context of what I already have. Once I get familiar with those and finish up some other work, I can start thinking about more fundamental overhauls of the code (which needs it, but not now).

I really appreciate any concrete help you can give me.

Addendum: if you leave code in a comment, please just wrap it in a code element and use whatever indentation you like. The indentation won’t show up when the post goes up, but I’ll go in after and wrap the code in a pre and then everything will be fine. Sorry to those who’ve already gone to the effort of posting with indents or nbsp entities to try to preserve indentation! As soon as I can dig up the right preference panel or plugin to allow pre in comments, I’ll do that, but for now I’ll manually edit in the needed pres as comments are added. THanks, and again, apologies to those who posted before I made this clear!

So I have this equation that’s great for finding one term. Problem is, I need to solve for another term that’s scattered all across the right side. I’m hoping someone here has the mad algebra skills I managed to lose in the two decades since I last took a math class and can help me out.

Here’s the original equation:

Q = (3.07 × F × Y × (1 + 1.4 × ((D/V) × e^{(-2 × D/V)}))) / D²

I want to be able to solve for D, not Q; in other words, have a single D on the left and everything else on the right of the equation. F, Y, and V are all variable terms; the e is the classic irrational constant. I tried for quite a while to do this and ran very firmly aground. The best I managed was this minor simplification:

Q = (3.07 × F × Y × (1 + 1.4 × (D / (V × e^{(2 × D/V)}))) / D²

…and even that assumes that I did things correctly. Here’s the original equation in pretty shoulda-done-it-in-MathML-but-oh-well form:

I can shuffle the chairs around, as it were, but never really get anywhere close to having a single D on the left. “But it’s so easy!“, you may well be shouting. That’s why you’re working for Google and I’m not.

I remember having questions just like this on tests back in college: “Given this equation, solve for blah”. It’s been too long, though, and in all honesty I was never that great at this sort of thing in the first place. Help, please?

[Update 14 Jan 09]: several commenters have shown that what I’m trying to do is impossible. Frustrating, but that’s math for you. Looks like I’ll have to take another approach.

Yesterday afternoon, in a small office on the second floor of the Cuyahoga County Courthouse in downtown Cleveland, Ohio, Kat and Carolyn and I finalized our adoption of Rebecca. There were a few witnesses to this: the social worker who has handled our case from the outset, as she did Carolyn’s; the lawyer who made sure all of our paperwork was correct; our friends Gini and Ferrett; and the magistrate who conducted the proceedings.

As I did with Carolyn, I’ve avoided mention of Rebecca’s being adopted, though anyone who’s been reading the site for the last several years would probably have inferred it from the fact that Carolyn was adopted. And as with Carolyn, I avoided saying anything because the adoption wasn’t legally final until yesterday. Up to that point, we were borrowing her from the agency, as it were: they were her legal guardians. It was possible at any point for the agency to remove her from our home. In the strictest legal sense, they didn’t even need a reason to do so. Ditto the state. Had we missed one of the six monthly post-placement meetings with our social worker, for example, or even not met the required schedule, custody would have been revoked.

Now, of course, that’s no longer possible. Now she is ours as legally as she has been emotionally, now judicially recognized as the part of our family she’s long since become. It was her sister who made it official: the magistrate had Carolyn stamp the legal decrees, so that it was she who made the adoption permanent and binding. Most of the witnesses choked back tears. I felt a few eye-prickles myself, but suppressed them to make sure I got the pictures I hope both girls will cherish as they grow older.

After a celebratory dinner with friends, as we got ready for bedtime, I took Rebecca into my arms and whispered, “Welcome to our family, little one. Again. And forever.”