Dubroy.com/blog

Apple released Safari for Windows yesterday, and there’s been some discussion on the difference between how Apple and Microsoft render anti-aliased fonts.

I personally prefer a good font designed for on-screen reading (e.g. Verdana, Georgia) rather than anti-aliasing. On my ThinkPad (running Windows XP), I have ClearType turned off, because I find it distracting — the letters are blurry, and some of them seem to have a pinkish tint. On the other hand, I also own a Mac Mini running Tiger, and I’ve never really had a problem with the anti-aliasing there. There’s a good comparison between Windows 2003, Vista, and OSX here. In that photo, the OSX font looks too heavy, and a little jagged. The Windows 2003 font looks too wispy, and slightly colourful. Vista looks much better than both.

Anyways, Joel Spolsky has weighed in on the argument, and he seems to prefer Microsoft’s implementation. According to him:

The difference originates from Apple’s legacy in desktop publishing and graphic design. The nice thing about the Apple algorithm is that you can lay out a page of text for print, and on screen, you get a nice approximation of the finished product. This is especially significant when you consider how dark a block of text looks. Microsoft’s mechanism of hammering fonts into pixels means that they don’t really mind using thinner lines to eliminate blurry edges, even though this makes the entire paragraph lighter than it would be in print.

Seems like a pretty reasonable explanation to me. But then Joel says:

Microsoft pragmatically decided that the design of the typeface is not so holy, and that sharp on-screen text that’s comfortable to read is more important than the typeface designer’s idea of how light or dark an entire block of text should feel.

The thing is, the design of the typeface has a lot to do with readability. The height of the letters, the angle and width of the strokes, the serifs…these all play a part in the readability of a font. You mess with them, and you are messing with the readability. Microsoft’s rendering isn’t just affecting “how light or dark an entire block of text should feel”; it actually changes the placement and weight of the strokes. It might appear “nicer” at first glance, but that doesn’t mean it’s better or more readable. You wouldn’t take a bicycle and say, “Well, the exact placement of the parts is not so holy, so I’m just gonna move them around a little so that it looks a bit better.” They are exactly where they are for a reason.

I’m not actually picking sides here — I don’t think either Microsoft or Apple is right. They are two different approaches, with their own advantages. But I think it’s wrong to call Microsoft pragmatic, and make Apple out to be all hoity-toity and unwilling to compromise their artistic integrity.

For the uninitiated, here’s a good page on font readability, and another on sub-pixel font rendering.

Update: Dave Shea, who is actually knowledgeable in typography, agrees with me. Jeff Atwood points to some studies that were done that show ClearType to be slightly more readable than standard (non anti-aliased) text, as well as a white paper describing FontFocus, which is similar to ClearType, but doesn’t use subpixel rendering, so your black and white fonts aren’t rainbow tinged.

This morning I was lucky enough to attend a talk at U of T by Donald Norman. In case you’ve never heard of him:

Don Norman is the champion of human-centered design. … Norman is Professor of Computer Science and Electrical Engineering, Psychology, and Cognitive Science at Northwestern University. There he teaches design while co-directing the Segal Design Institute. He is cofounder of the Nielsen Norman Group and a Professor at Northwestern University. He has been Vice President of Apple Computer and an executive at Hewlett Packard.

He is well known for his books “The Design of Everyday Things” and “Emotional Design.” … He lives at www.jnd.org.

His talk was based on his upcoming book, The Design of Future Things, which discusses “the role that automation plays in such everyday places as the home, and automobile.” The main thesis of Norman’s new book seems to be “intelligent devices aren’t.” The intelligence is really in the designer. Given a certain set of sensors and controls, a designer creates a simple approximation of intelligence. Like adaptive cruise control: the car can sense how far in front the next car is, and adjust the speed of your car to maintain a constant distance. Norman told us a story of one of his friends, who was driving a car with adaptive cruise control in heavy traffic. He’d been sitting in traffic so long that he forgot the cruise control was even on. He got a bit of a shock when he pulled onto the off-ramp on the car suddenly accelerated.

The problem is that this kind of automation is based on simple sensors and simple rules, but this all breaks down in the face of unexpected events. We all know that human reasoning and decision making are extremely complicated. A person can “know” something, even think it’s obvious, but not be able to say why. So what hope do we have of being able to design decision-making machines?

Norman thinks the ideal situation is that we don’t try to make machines that think, but machines that help us think. These systems should be optional, natural, and predictable. I don’t entirely disagree with him, but I think there are definitely situations where a computer really could make a better decision than a human.

Malcolm Gladwell gives an interesting example in his book Blink. He tells a story about a Chicago ER, and their process for diagnosing coronary patients. One doctors, after studying two years’ worth of data, came up with a decision tree based on only four factors. By using this simple, “unintelligent” decision making process, they actually got 70% better at recognizing patients who were having a heart attack.

In a question after the talk, Bill Buxton also pointed out that there are many kinds of automation that just work, like thermostats and ABS brakes. He asked Norman where would should draw the line. I tend to agree with him — I don’t think the problem is with automation per se, but with poorly designed automation. But I do think that Norman’s “optional, natural, and predictable” is a great set of design goals for automated systems.

To me, the most challenging part of the design is in the interaction between a person and a machine. In his talk, Norman pointed out that we talk about “conversations” between people and computers, but that’s not what happens. We don’t have a dialog, we have two monologues. I think we need to focus more on this conversation aspect.

“Open the pod bay doors, HAL.”
“I’m sorry Dave, I’m afraid I can’t do that.”

Norman had a really interesting point that this conversation between people and machines is similar to the concept in linguistics of common ground. You can have a meaningful conversation with someone only if there’s enough common ground, like shared experiences and beliefs. Because machines have a different reality (based on the sensors they have available) and a different decision-making process, it’s hard to have a real conversation between a human and a machine.

In practice, there is always a gap between what the person wants and what the machine wants. When you’re hitting the brakes hard, you want to avoid a crash. Your ABS brakes don’t want to avoid a crash, they want to avoid the wheels locking up. This is what Norman calls the Gulf of Goals. There is also a Gulf of Actions, which is the difference between what you want to do and what the machine wants to do. In the case of ABS, you want to put the brakes on, while your car wants to let them off (but just for a quick second).

So, I think that Don Norman made a lot of good points about the possible problems with consumer-level automation, but I think he is overly pessimistic. He seems to believe that we shouldn’t have real automation, but always a human making the most important decisions. There are many good reasons to strive for real, useful automation. Will we ever be perfect? No. But I think we can design intelligent systems that are usable and helpful.

Aza Raskin has had a lifelong quest to build the perfect paper airplane (can’t say I share his enthusiasm, but anyways…). In his latest post on the Humanized Weblog, he uses this example to talk about iterative design. He makes an interesting point:

Coming up with a solution is often the most straightforward part of the design process. That isn’t to say that creating the solution is easy, or doesn’t require a deep knowledge and honed skill set. It’s just to say that when you have a set of requirements and a well defined problem, you know where you stand and where you have to get to. It’s mostly straightforward. Much harder is the implicit problem of figuring out exactly what the problem is in the first place. If the problem is vague or ill-defined, the design solution will be too.

This is something I’ve always believed: that the hard part is asking the right question. And to digress quite a bit, I think this is a problem that a lot of people have, myself included. In school we are basically handed the problems: “learn this”, “write an essay about that”, etc. We are almost never encouraged to seek out new problems, or even to think creatively about different kinds of answers.

Something I’ve seen in a lot of my friends is that when we finally graduate from university, we don’t know what to do. We are used to being handed narrowly-defined problems, like “finish high school”, “choose a university”, and even “choose a program”. Those last two sound like they are actually difficult, but think about it — all you are doing is picking an item out of a list. It couldn’t get much easier. When we get out into the “real world”, all of a sudden, the questions are much more vague. To do well, you need to practice the same sort of iterative design that Aza talks about: you need to improve both the design and the problem you are trying to solve.

And this is something I’ve actively been trying to do with my research interests. Actually, that’s one of the main reasons I started this blog: to help me sort out the problems in HCI that I am trying to solve. Answers are easy; the hard part is asking the right questions.

(Photo by ! * Krystian`s PHOTOSynthesis * ! on Flickr)

A low-fidelity prototype is a quick-and-dirty way of doing usability testing for software. It’s often referred to as a paper prototype, because it’s usually done by sketching the interface out on paper. The point of it is to get feedback from real people very early in the design process. Because paper prototyping can be done so quickly and cheaply, you can iterate through a bunch of different designs in a short amount of time.

Low-fidelity prototyping is generally accepted to be a “best practice” in software design. But even its strongest supporters admit that it’s not appropriate for every situation. In her book Paper Prototyping, Carolyn Snyder says: “Paper prototyping’s main strength is depth—the human Computer can simulate much of what the interface will do.”

This is an important point: low-fidelity prototypes are really about what, not how. Working on my research in the past month, I felt like I should be doing some paper prototypes; but I also had a sense that they wouldn’t really be that useful. And now I realize why: when you are designing new interaction techniques, the how is often the most important part. How does the system respond to the user? Does it feel responsive? Does it feel natural? Is it cumbersome or repetitive? These questions are hard to answer with a low-fidelity prototype.

Also, certain types of software just aren’t suited to being tested with fake data. For software that is designed to integrate with your everyday life — like an email client or a search tool — it’s hard to create a prototype that will be a good simulation of the real-world use cases. Not only could a low-fidelity prototype be unhelpful in these situations, it might actually be a bad thing, since you would be making design decisions based on flawed data.

(Photo from Kables on Flickr)