Change: new Pulitzer rules, bye-bye Baltimore Opera

Grab bag: External links on NYTimes.com, and other signs of the apocalypse

Grab bag: Cracks in Old South and Facebook

Grab bag: UI is all around you

links for 2008-12-03

Obscure HTML element of the day: dfn

I’ve had an opportunity to do a little static HTML + CSS work recently, and have had a few educational and reeducational moments about the joys of doing basic web development–all the stuff that a good CMS like WordPress hides from you.

Today’s educational moment was a question of footnote treatments. My application had footnotes at the very bottom of its page, with nothing beneath them, and did inpage links to the footnotes. But it was linking to the footnotes from a part of the text that was close to the bottom of the page, so the footnote was already visible. As a result, when a user clicked a link to get to the footnotes, nothing happened–the footnote was already there, and there was no more page to scroll up.

There are ways around this. Daring Fireball has a lot of empty space on its pages below its footnotes, meaning that the page can scroll to place the footnote at the top. But the bug got me thinking again about why I was doing the footnotes and how I could change the user experience. What if I moved the footnote text–which was generally some sort of quick definition–into a mouseover? I knew I could do it with acronym, but the text I was footnoting wasn’t an acronym so it wouldn’t have been semantically correct. Was there a semantic way to mark up the word or phrase being footnoted so that when moused over, a definition would show?

Enter dfn. See what that does? The dfn tag is basically tailor made for what I wanted to do, and is even reasonably well supported. FF3 and IE7 even automatically italicize the term.

I made one more change to my stylesheet to make it really explicit that more information was there for the mouseover, and applied the same rule that I had for abbreviations:

dfn {
   border-bottom: 1px dotted #333;
   cursor: help;
}

With that, the user got a dotted underline on the term, and a help cursor when they moused over.

I would probably make one more change if the application was expected to be printed, which would be to introduce some styles or JavaScript in the print stylesheet that would do an inline expansion of the definition. But for what I needed to do, dfn worked pretty well by itself. Yay obscure HTML elements!

Grab bag: Agile all the time

Web birthday#8

This is my eighth birthday… since starting my blog in 2001.

Seems like it was an eternity ago. I didn’t even bother to blog on my birthday then–of course it was close to the end of my third semester of business school and I was going nuts. But then, I didn’t realize that I was starting a tradition.

I went back and looked at past birthday posts. 2001, as I mentioned before, wasn’t blogged. In 2002 I turned 30 and reflected on Bilbo Baggins’ birthday benediction (more on that in a minute). 2003 was gearing up for what turned out to be my last Microsoft Christmas party. 2004 was a reflection on over ten years of no one knowing you’re a dog on the Internet. 2005 was my quotation in Business Week over the Sony BMG boycott. 2006, a dinner with friends and reflection on mortality. And in 2007, turning Presidential and lining up my new iPhone.

This past year is definitely a year of change — new website, a shift to linkblogging, killer new job. But my birthday this year feels more like a homecoming. As my sister says, this is pretty much my first Facebook birthday, and the people I’ve reunited with over there are making it a very nice happy birthday indeed. In some ways, I think this is the first birthday in a long time where I’ve felt something like contentment. Probably a sign that vast upheaving changes are right around the corner.

Grab bag: BSO downloads

Thanksgiving 2008: Big ass turkey

It’s time for the Thanksgiving menu, and not a moment too soon. I managed to get to Wilson Farms today in the nick of time to pick up my turkey, came home early, and boiled my customary Alton Brown brine (1 gallon vegetable broth, a cup of salt, a half-cup mixed brown and white sugar since we were low on brown, and peppercorns) and iced it down and put it on the porch to cool. After cooking a pre-Feast of the Beast (biftek a la Lyonnaise with a quick sauce Robert) and taking care of a few other odds and ends, I wrangled the turkey into the brine.

That’s not a small task. We have five adults and a small child at the dinner table this year, which means a slightly bigger turkey. Like, 19 pounds. This year I remembered to fish the neck and liver out of the cavity AND to get the paper bag with the other organs out of the neck cavity (very good progress!) before the turkey went into the cooler on a bag’s worth of ice, breast down; the brine went over the turkey; and another half bag of ice went on top. The cooler is now on the porch (mercifully, it’ll be between 30° and 34° tonight) and I’m catching my breath while I think about the rest of the menu.

My mother-in-law, mercifully, has already taken care of dessert—a homemade apple pie. That leaves us with:

What’s up with all the duplications? Well, I made the classic product manager error: I didn’t socialize my plans in advance and got blowback. We’ll see how it goes.

Grab bag: Pre-Thanksgiving light blogging

Grab bag: Nogging your egg

Release planning: How you prioritize matters

I hope I have the time to come back to this thought tomorrow (along with some overdue Thanksgiving blogging). But I had the opportunity to meet up with an old colleague for lunch today and to discuss, among other things, two different agile project cycles. One project cycle ships every four to five months, has seven or eight two-week iterations inside the release cycle, and uses MoSCoW-style prioritization (that is, Must, Should, Could, Won’t) for feature stories and for backlog. The other ships every six weeks, has one iteration inside the release cycle, and uses forced stack ranking for feature stories and backlog.

Which of the differences (iterations per release, release length, prioritization) is most important between the two projects? Which has the greatest impact on the release?

I’m going to give away the answer when I say I think there’s a stack rank of impact:

  1. Prioritization method
  2. Release length
  3. Iteration frequency

Why is prioritization so important? And which method is better, forced stack ranking or must, should, could, won’t?

The problem with any bounded priority system, whether it’s MoSCoW, Very High/High/Medium/Low, or simply 1, 2, 3, 4, is that it leads to “priority inflation.” When I was selling ITIL compatible software, we had a feature in our system that used a two factor method and customizable business logic to set priority for customer IT incidents. It was necessary to go to that length because, left to their own devices, customers push everything inexorably to the highest priority. Why? Because they learn, over time, that that’s all that ever gets fixed.

It’s true in software development too. I can’t count the number of features that were ranked as “must haves” on the project that used MoSCoW. It was very difficult to defend phasing the work, because everything was a must.

The project that uses forced stack ranking doesn’t have the problem of too many “must haves” because there can be only one #1 priority, and only one #2, and so on. Developers can work down the list of priorities through a release. If there’s been an error in estimation and the team has overcommitted for the release, it’s the lower priority items that slip.

The forced stack ranking works with stakeholders outside engineering too, because it forces them to evaluate requirements against each other in a systematic way. Rather than saying “everything is a must,” stakeholders can give answers about whether requirement A or B is more important within the scope of the release.

Release length and iteration frequency matter, too, because they provide mechanisms for market-driven and internal-driven course correction. But from my experience, as long as the release length and iteration frequency aren’t too far out of whack, the right prioritization method is a crucial ingredient for successful delivery of software that meets stakeholder expectations and for defining feature lists that have a reasonable shot of getting completed within a single release.

Grab bag: Uncle Joe goes to Washington