Coding Horror

You may be familiar with the font Comic Sans MS:

Over the last 5 years, my wife and I noticed that this annoying font is inordinately popular "in the wild" -- we've seen it in the strangest places. Enough so that it has become a running joke whenever we see it.

We may be weird, but we're not alone: there's a Ban Comic Sans website.

Like the tone of a spoken voice, the characteristics of a typeface convey meaning. The design of the typeface is, in itself, its voice. Often this voice speaks louder than the text itself. Thus when designing a "Do Not Enter" sign the use of a heavy-stroked, attention-commanding font such as Impact or Arial Black is appropriate. Typesetting such a message in Comic Sans would be ludicrous. Though this is sort of misuse is frequent, it is unjustified. Clearly, Comic Sans as a voice conveys silliness, childish naivete, irreverence, and is far too casual for such a purpose. It is analogous to showing up for a black tie event in a clown costume.

There's also a rather amusing history of comic sans presentation which I recommend-- now we know to blame Vincent Connare for this font. Vincent does his best to defend the font on his website:

Comic Sans was designed because when I was working at Microsoft I received a beta version of Microsoft Bob. It was a comic software package that had a dog called Rover at the beginning and he had a balloon with messages using Times New Roman.

Comic Sans was NOT designed as a typeface but as a solution to a problem with the often overlooked part of a computer program's interface, the typeface used to communicate the message [in a comic character's message balloon].

There was no intention to include the font in other applications other than those designed for children when I designed Comic Sans. The inspiration came at the shock of seeing Times New Roman used in an inappropriate way.

Proving, yet again, that anything which came from Microsoft Bob cannot be good. The misappropriation of Comic Sans is truly epidemic. At this point, we're bracing for the inevitable Comic Serif.

In a previous entry, I touched on the broken window theory. You might be familiar with the Pragmatic Progammers' take on this:

Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take some action to prevent further damage and to show that you're on top of the situation.

We've seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we'll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.

That's excellent advice for programmers, but it's not the complete story.

The broken window theory is based on an Atlantic Monthly article published in 1982. It's worth reading the article to get a deeper understanding of the human factors driving the theory:

Second, at the community level, disorder and crime are usually inextricably linked, in a kind of developmental sequence. Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken. This is as true in nice neighborhoods as in rundown ones. Window-breaking does not necessarily occur on a large scale because some areas are inhabited by determined window-breakers whereas others are populated by window-lovers; rather, one unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing. (It has always been fun.)

Philip Zimbardo, a Stanford psychologist, reported in 1969 on some experiments testing the broken-window theory. He arranged to have an automobile without license plates parked with its hood up on a street in the Bronx and a comparable automobile on a street in Palo Alto, California. The car in the Bronx was attacked by "vandals" within ten minutes of its "abandonment." The first to arrive were a family — father, mother, and young son — who removed the radiator and battery. Within twenty-four hours, virtually everything of value had been removed. Then random destruction began — windows were smashed, parts torn off, upholstery ripped. Children began to use the car as a playground. Most of the adult "vandals" were well-dressed, apparently clean-cut whites. The car in Palo Alto sat untouched for more than a week. Then Zimbardo smashed part of it with a sledgehammer. Soon, passersby were joining in. Within a few hours, the car had been turned upside down and utterly destroyed. Again, the "vandals" appeared to be primarily respectable whites.

Untended property becomes fair game for people out for fun or plunder and even for people who ordinarily would not dream of doing such things and who probably consider themselves law-abiding. Because of the nature of community life in the Bronx — its anonymity, the frequency with which cars are abandoned and things are stolen or broken, the past experience of "no one caring" — vandalism begins much more quickly than it does in staid Palo Alto, where people have come to believe that private possessions are cared for, and that mischievous behavior is costly. But vandalism can occur anywhere once communal barriers — the sense of mutual regard and the obligations of civility — are lowered by actions that seem to signal that "no one cares."

There's even an entire book on this subject. What's fascinating to me is that the mere perception of disorder — even with seemingly irrelevant petty crimes like graffiti or minor vandalism — precipitates a negative feedback loop that can result in total disorder:

We suggest that "untended" behavior also leads to the breakdown of community controls. A stable neighborhood of families who care for their homes, mind each other's children, and confidently frown on unwanted intruders can change, in a few years or even a few months, to an inhospitable and frightening jungle. A piece of property is abandoned, weeds grow up, a window is smashed. Adults stop scolding rowdy children; the children, emboldened, become more rowdy. Families move out, unattached adults move in. Teenagers gather in front of the corner store. The merchant asks them to move; they refuse. Fights occur. Litter accumulates. People start drinking in front of the grocery; in time, an inebriate slumps to the sidewalk and is allowed to sleep it off. Pedestrians are approached by panhandlers.

At this point it is not inevitable that serious crime will flourish or violent attacks on strangers will occur. But many residents will think that crime, especially violent crime, is on the rise, and they will modify their behavior accordingly. They will use the streets less often, and when on the streets will stay apart from their fellows, moving with averted eyes, silent lips, and hurried steps. "Don't get involved." For some residents, this growing atomization will matter little, because the neighborhood is not their "home" but "the place where they live." Their interests are elsewhere; they are cosmopolitans. But it will matter greatly to other people, whose lives derive meaning and satisfaction from local attachments rather than worldly involvement; for them, the neighborhood will cease to exist except for a few reliable friends whom they arrange to meet.

Programming is insanely detail oriented, and perhaps this is why: if you're not on top of the details, the perception is that things are out of control, and it's only a matter of time before your project spins out of control. Maybe we should be sweating the small stuff.

Some users commenting on the poor pre-game user interface in EA's Battlefield 2:

Poster #1: They need to stop hiring angry little men and romantically spurned women to design user interfaces.

Poster #2: But doesn't that describe most programmers?

Poster #3: No, that describes all programmers.

It's funny because it's true. Not the romantically spurned part, mind you, but the accusation that most programmers are bad at designing user interfaces. That's partly because UI is hard:

GUI builders make GUI programming look easy. Nearly anybody can whip up a decent-looking GUI in no time at all using a GUI builder. Done.

It is much harder to whip up a quick and dirty EJB system, giving the impression that server-side coding is harder to do. A bad programmer will continue to struggle with EJB, but a good programmer will find ways to automate nearly every aspect of EJB. That's the secret of server-side programming: it is very well-defined and repetitive. Thus, it can be automated.

Take your favorite Model-Driven-Architecture (MDA) tool. They work best when generating server-side code, things like EJBs, database access code, and web services. They might be able to generate a rudimentary GUI, but a really GREAT GUI cannot be automated.

But programmers are partly to blame, too. Most programmers begin by thinking about the code instead of the user interface:

John almost hit on the most important point in all of this. No one else did. When you're working on end-user software, and it doesn't matter if you're working on a web app, adding a feature to an existing application, or working on a plug-in for some other application, you need to design the UI first.

This is hard for a couple of reasons. The first is that most programmers, particularly those who've been trained through University-level computer science courses, learned how to program by first writing code that was intended to be run via the command line (Terminal window for you Mac OS X users). As a consequence, we learned how to implement efficient algorithms for common computer science problems, but we never learned how to design a good UI.

The second problem is that the tools we use to create UI are often good tools for more simple usability issues, but tend to fall well short when it comes to designing UI for a more complex set of user scenarios. Forms designers are great when you're working within the problem domain that forms are intended to solve, but once you step outside those problem domains, the work gets much harder. Use a more flexible tool, like Xcode's nib tool and the Mac OS X HIView object, and you're going to have to write considerably more code just to manage the UI objects.

This is also known as UI First Development, but I can't find many other references.

At the nVidia 7800 launch event today, one of the video rendering technology highlights was high dynamic range lighting. Almost all video cards in use today are limited to 32 bit color values-- that's 8 bits for red, green, and blue, with the "rounded" 8 bits typically thrown away*. 24 bits is enough to represent most of the colors the human eye can see. But those 8 bits per color also represent intensity. That means the brightest white is 255, 255, 255-- only 256 times brighter than the blackest black. This vastly underrepresents both the dynamic range of light in the real world (10¹² to 1) and the dynamic range of the human eyeball (1000 to 1).

That's why HDR lighting uses 64-bit values to represent color, which offers both 16 bits of color precision and 16 bits of brightness. As the chief scientist at nVidia points out in a recent Q&A session, don't underestimate the importance of good old black and white:

Reader Question: What is your opinion about some of the new graphical features that are being implemented in games? Some are quite beneficial to GPU performance, such as normal-map compression and virtual displacement mapping. But others are very costly to performance, specifically high-dynamic-range lighting. After seeing the extreme over-saturation of light with HDR in Far Cry (even on the lower levels of HDR) and the performance hit it took, I personally am not convinced that HDR is a method that should be pursued any longer. What are your opinions on this subject? -- cfee2000

David Kirk: I think that High Dynamic Range Lighting is going to be the single most significant change in the visual quality over the next couple of years. It's almost as big as shading.

The reason for this is that games without HDR look flat. They should, since they are only using a range of 256:1 in brightness -- a small fraction of what our eyes can see. Consequently, low-dynamic-range imagery looks flat and featureless, no highs, and no detail in the shadows, the lows. If you game using a DFP (LCD display), you probably can't tell the difference anyway, since most LCD displays only have 5 or 6 bits of brightness resolution -- an even narrower 32:1 or 64:1 range of brightness. On a CRT, you can see a lot more detail, and on the newer high-resolution displays, you can see not only the full 8 bits, but even more. There are new HDR displays that can display a full 16-bit dynamic range, and I can tell you that the difference is stunning. When these displays become more affordable in the next year or two, I don't know how we'll ever go back to the old way.

Here are some comparative screenshots from Far Cry, which supports HDR lighting as of the 1.3 patch:

High dynamic range lighting (64-bit color)

Standard lighting (32-bit color)

The effect is not always obvious, but it's just as significant as the move from 16-bit color to 32-bit color in my opinion. It's like going from dial-up to broadband; you don't really know what you've been missing until you've seen it in action.

Of course, TANSTAAFL: increasing the data payload from 32-bit to 64-bit hurts performance. Although the GeForce 6 supported HDR lighting, the new GeForce 7 is supposedly the first generation of video card that can deliver HDR without significantly impairing performance.

* The data has to be rounded to the nearest power of two for performance. I'm not entirely sure what is done with the "extra" bits in 32-bit and 64-bit color framebuffers.

Cory Doctorow is releasing his new novel under a creative commons license.

As with my first and second novels, I've posted the entire text of this book online under a Creative Commons license that allows the unlimited, noncommercial redistribution of the text. You can send it around, paste it into a chat, beam it to a friend's PDA, or print out a chapter to hand out in the university common room. Like Woody Guthrie said, "Publish it. Write it. Sing it. Swing to it. Yodel it. We wrote it, that's all we wanted to do."

I immediately assumed he was releasing it under the standard Creative Commons license, like that recent documentary about BBS culture, but not so. He's releasing it under the Developing Nations License. If you live in a medium/low income country, the book is in the public domain. Otherwise, you pay. That reminded me of last year's blgo entry about software pricing. Microsoft charges US customers $299 for a copy of Microsoft Office, and Thai customers $38.

Isn't this the same pricing strategy that drug companies get clobbered for? Drugs cost more in the US, so the US ends up subsidizing a big part of the R&D bill. That's why seniors take buses to Mexico or Canada to buy their drugs; they don't want to be charged US rates. It's also known as "zone pricing" in the oil industry:

Such price variations may seem odd, but they are not unique to Anaheim. On any given day, in any major U.S. city, a single brand of gasoline will sell for a wide range of prices even when the cost to make and deliver the fuel is the same.

The primary culprit is zone pricing, a secret and pervasive oil company strategy to boost profits by charging dealers different amounts for fuel based on traffic volume, station amenities, nearby household incomes, the strength of competitors and other factors.

It's a controversial strategy, but the courts have thus far deemed it legal, and the Federal Trade Commission recently said the effect on consumers was ambiguous because some customers got hurt by higher prices while others benefited from lower ones.

Granted, the life preserving qualities of drugs makes zone pricing a little more questionable in that case. Nobody's going to die if they can't fill up their Hummer H2 with premium. Or afford a copy of Microsoft Train Simulator 2006.

Giving developing countries a break is clearly a good thing. But I wonder if these zone pricing strategies will continue to work in an era of increasing global communication. Why not buy drugs online from Canada? Or check a website to see where the cheapest gas is in your area? Any system that expressly prohibits goods from moving from zone to zone-- like DVD region coding-- doesn't work so well.