link

And I said, "Jesus Mother of Fuck, what are you thinking! Do not strap the 'Groupware' albatross around your neck! That's what killed Netscape, are you insane?" He looked at me like I'd just kicked his puppy.

A fun and poignant read.

link

A remarkable collection of links on User Experience topics.

link

How Microsoft tests ASP.NET 2.0. Hint: it involves 105,000 automated test cases, which are run on 1200 dedicated machines.

ASP.NET is probably the best web development framework out there—at least for the corporate market. This is one reason why; not a lot of companies other than Microsoft can invest that much in quality.

(After writing, Shimon checks the back of his neck. Hmm, no chip.)

link

Philip Greenspun's classic, originally published in the ArsDigita Systems Journal.

link

Transcript of Alexander's OOPSLA speech.

One thing I like about building software is that failure is normal. You have to try so many different approaches, and so many of them don't work. Some approaches fail at the idea stage; a few fail after you've spent days or weeks seemingly close to making them work. Each failure is painful.

If you were building a bridge or a putting out a fire, failure would be a total loss: materials wasted, property destroyed. But in making software, failure is actually a form of progress. When you're exploring the boundaries of what's possible, you're often going to set your sights beyond those boundaries. In making software, you're constantly reminded of this. As a result, you either get disparaged and start doing less risky, less creative work—or you learn to treat failure as an experimental result that confirms the value of the endeavor.

People who really care about making software know this. It's spread throughout the culture: good programmers, managers, execs, and even venture capitalists know the value of failure. For all the shortcomings of techie culture, it is this courage that redeems us. And because technology is an ever-increasing part of the world economy, the world is on a cultural path toward valuing failure and away from denigrating it. The effects ripple far beyond technology, making now a better time than ever to be creative.

I'm writing documentation for frassle. This Thursday, Dave impressed on me the importance of documentation. But as I work, I'm finding something surprising—it's not just for the users.

The documentation comes in the form of tutorials. Each tutorial takes you through the system with some specific goal: gettings started with posting and categories, installing bookmarklets, using the aggregator, link stacking, or building a custom site in frassle publisher. Each step of the tutorial shows in a small top frame while you do what the tutorial says in the lower frame. It goes step by simple step.

I chose the tutorial appraoch because I believe it's easiest to learn by example. It also give me a way to show you how I do it, so I can transmit not only details about how the system works but also my own tips on how I like using it. You could almost call it the blog-style approach to help.

It's not just for the users

The tutorial approach has other upsides. As I write the tutorial, I have to put myself in the mind of a newbie. I have to write without jargon. Therefore, if I write something and it sounds confusing, I have to ask why.

Often, the reason some text is confusing is that I wrote it poorly. But sometimes, the reason it's confusing is that frassle's design is confusing.

Uh oh! Abandon ship! Design fundamentally unsound—bewildered users running amok!

Deep breath. Ahh. Thankfully, it isn't that bad. I'm doing sanity checks and making little improvements. Why? Because, hey, a tutorial is the same thing as a use case!