def euler(x); cos(x) + i*sin(x); end

To paraphrase Jared Spool, who gave the closing keynote at webvisions | 2006, designing compelling user experience is something that can be learned, but there’s no good understanding of how it works. To illustrate this phenomenon, Jared refers to chicken-sexing. You can read up on it, but the basic idea is that to run a cost-effective chicken farm, you need to know the gender of the chicks about 2-3 weeks before any known mechanized process can successfully do so. The solution is to rely on professionals that watch the chicks go by and identify them as male or female.

Consider the ipod and netflix as two examples of compelling user experience despite, according to Jared, the former having inferior technology compared to competitor offerings and the latter not having any brick-and-mortar storefronts or any customer service other than through their website. Even so, the ipod is wildly more popular than any other portable music player, and Netflix membership dwarfs that of Blockbusters recent through-the-mail dvd rental service.

Obviously, there is great advantage to being able to learn good user experience design. And that was one of Jared’s main points. It can be learned. This is supported by current research. Consider an article in the August 2006 issue of Scientific American, “The Expert Mind”. Research into chess masters indicates that there is little actual contribution by “talent”. Rather these folks’ mastery consists primarily of categorizing a huge amount of knowledge of fruitful moves given the configuration of piece on the board.

Effortful study is the key to achieving success in chess, classical music, soccer and many other fields. New research has indicated that motivation is a more important factor than innate ability.

One key to effortful study is constantly pushing yourself to reach just beyond your current abilities. This is good news for those of us who have never felt we are natural born chicken-sexers.

I have had the good fortune of being sent to webvisions | 2006 by PLANET ARGON. I have it on good authority that this year it is much larger than last year. It’s two days long and chock-full of great talks.

So far, I have attended:

• Becoming a Professional Blogger
• People and Business: A Global Perspective
• Practical Business Blogging Panel
• Designing for Socal Sharing
• Design Patterns for the Web
• Mobile Development Panel

The “People and Business” panel was a very interesting, if Portland-specific, look at government and industry participating to create and promote business. This was a bit unusual, I thought, since folks have come from all over to attend the conference. At the same time, it was intriguing to hear, especially from the Portland Development Commission, some things that may distinguish Portland as a hospitable environment for technology innovation. By coincidence, I think, the Portland City Council had voted just the night before to move forward with plans to build a free, public Wi-Fi blanket in Portland.

My favorite talk by far was “Designing for Social Sharing”. I recommend checking out Rashmi’s site. She was a vibrant, engaging, knowledgeable speaker. One of the most interesting points is that to create a successful site for social sharing, we need an object around which people can share. Now that we have sites like Flickr, this seems like a no-brainer. But when we view how “social networking” sites have progressed from 1st generation, where the emphasis was only on the social network, we see how important this idea is. To paraphrase her, people don’t just connect for the sake of connecting, they connect over something.

A big component of a successful site that encourages people to share is providing a way for people to contribute their own creativity or personality. In effect, the design of these sites must facilitate the user’s ability to influence the design. Interestingly, I have recently been reading, A Pattern Approach to Interaction Design, by Jan Borchers. The author goes to some length to present a more full exposition of Alexander’s ideas on patterns. There is a lot of use of “patterns” this-or-that in various domains. To some extent, the word is often just stretched to cover a favorite concept. But the following quote seems particularly relevant in the context of a social sharing site:

Every place is given its character by certain patterns of events that keep on happening there. These patterns of events are always interlocked with certain geometric patterns in the space.

Christopher Alexander, The Timeless Way of Building

And this quote is nicely relevant to designers of such sites:

Interestingly, Alexander’s ideas were not always received well by his colleagues. One reason for this is that Alexander’s concepts empowered the inhabitants, supplying them with more ways to influence the building process, and taking much of that power out of the hands of the professional. Obviously, this idea was not very popular among architects.

Jan Borchers, A Pattern Approach to Interaction Design

Another excellent talk was “Design Patterns for the Web” by a guy from eBay and another from Yahoo!. A nice serendipity: I recently have been re-reading, About Face: the essentials of user interface design, by Alan Cooper. This book was awesome when I first read it years ago, and even today I’m amazed it is copyright 1995. Unfortunately, the content seems to be little-known in the web design world. Not at Yahoo! It appears to be very much an inspiration, as I will explain a bit more in a later post.

Okay, that’s it for now. I’ll mine my notes for juicy tidbits and snippet to share with you. Admittedly, I’m not a good liveblogger. :-/

Yesterday, Robby messaged me that he was invited to be a speaker at Sys-Con Rails Conference. (Sorry, I’d have a link for you, but I’m getting a 500 page right now.) Right in the title, it mentions Ruby on Rails in the “real world”. I am unable to suppress a groan every time I hear that quoted phrase ”real world”.

The “real world” label is used to legitimize. If something works in the “real world”, that basically says it’s not a toy, it’s for real. But if you look around at what works in the real world, you might ask yourself, “Why on earth would I want to imitate that?” I certainly do. The “real world” is filled with lame, difficult, buggy, costly software.

This relates to a point from DHH’s keynote at RailsConf that I’ve been meaning to reiterate. DHH essentially said that he lives in a fantasy world. I don’t think most of us realize how lucky we are that he does.

Imagine if he didn’t. Imagine DHH working on a nascent ActiveRecord and being closely in touch with the “real world”. Certainly, he would want it to be legitimate, not merely a toy. To be legit, it should solve “real world” problems. The “real world” is full of complex databases. It better support any imaginable scheme for primary keys, even composite ones. Anything less would… hmm, not work well in the “real world”.

The point is, we should be eager to say no to features. But in the “real world”, it is rare to find someone eager to do so. Sure, I can imagine my super-gizmo-mondo-cool coffee cup that is also a mobile phone, razor, electric toothbrush, talking tire gauge, and bottle opener. But why?! Just because it’s possible, does not mean that it’s desirable.

Really, our ability to live in a fantasy world, even briefly, is a terribly two-edged sword. It gives us the ability to imagine a world that does not exist, and execute the steps necessary to manifest it. For example, Rails. At the same time, it gives us the ability to imagine a world that does not exist, and execute the steps necessary to manifest it. For example, J2EE.

One of those two is thriving in the “real world”, according to the connotations normally associated with that phrase. I think we’re trying too hard in the wrong direction if we are chasing the “real world”. Rails is a disruptive technology; and that is something to be celebrated.

Rails does not need to be legitimized.

That’s my opinion. In fact, I think we do a disservice to the disruptive potential of Rails by trying to legitimize it with the “real world” label. I may be reading too much into the “real world” phrase in the Sys-Con event title, but since it is billed as being for CEO’s, CTO’s, etc., I don’t think so.

I think Rails is highly relevant to creating real world applications, meaning those that assist people to achieve their goals by doing much more with far, far less complexity. That requires us to have a vivid imagination and vibrant fantasy life. In other words, a good, healthy distance from the “real world”.

When I started at PLANET ARGON, I was given a bright new matte black MacBook to use. It’s a beauty. This is the first time I’ve used a Mac extensively since around ‘89 and I love it. Well, mostly. For the last decade or so I’ve used Linux 90% of the time. First RedHat, then Fedora, and most recently Ubuntu, which in my experience is simply excellent.

What I miss most from Linux is the super responsive Gnome desktop, the wonderful Gnome Terminal, and the oodles of very high quality free software. With the Mac, I am quickly annoyed by the frequent appearance of that damned spinning color wheel, Mac-speak for, “uh, hold on, I’m having a moment”; the typing through molasses feel of iTerm; and paying for so many little pieces of software. Mind you, I’m fine trading my money for something of value, but if you are going to force the issue with me, you should probably ensure your process to lighten my wallet doesn’t piss me off.

Enter NetNewsWire. I’ve used it through it’s evaluation period and it’s been passable, nothing spectacular. But today, it wants money from me. So it puts up a friendly dialog, asking nicely. A bit miffed, I go ahead and click the “Purchase Software” radio button. Hmm, nothing happens. Seems that option is disabled. Oh well, sorry NetNewsWire, now I’m evaluating NewsFire

Last week, my esteemed colleague Jeremy, at his characteristic morning unveiling^[1], brought in a couple books on “Death March” projects. While he tackled the other, he lent me Death March: second edition, by Edward Yourdon. Edward defines a death march project as “one whose ‘project parameters’ exceed the norm by at least 50 percent”. That is, one or more of the following is true: the project has less than half the budget, the staff, the time, or more than double the functionality, features, performance, or technical requirements. He discusses why death march projects are created, why people participate in them, and some things one might do to try to handle such a project (although he’s pretty pessimistic about successfully changing a project of this type).

Under the heading, Why Do Death March Projects Happen, Edward starts off with a great quote by the author of the Dilbert cartoons, Scott Adams:

When I first started hearing these stories [about irrational corporate behavior] I was puzzled, but after careful analysis I have developed a sophisticated theory to explain the existence of this bizarre workplace behavior. People are idiots.

Including me. Everyone is an idiot, not just the people with low SAT scores. The only difference among us is that we’re idiots about different things at different times. No matter how smart you are, you spend much of your day being an idiot.

Hopefully everyone is not totally insulted at this point. As in Dilbert, this idea can be a great source of inspiration. It’s really not as derogatory or as hopeless as it sounds. And for me, it puts some recent events in perspective.

Since DHH’s keynote at RailsConf, there has been noticeable buzz about CRUD. Everything from new acronyms to debates about nouns versus verbs. All good stuff, interesting, thought provoking. But for me, probably the greatest benefit of more CRUDful modeling is better managing of complexity. I think this is the raison d’être of CRUD.

Similar to when OOP was capturing hearts and minds, many people waxed poetic about reuse, more faithful domain modeling, etc. But the golden egg of OOP is encapsulation, and encapsulation is another powerful abstraction that helps manage complexity. If there were one thing I would lobby to be added to the agile manifesto, it would be “Simplicity over big, amazing, mind-boggling complexity”. Certainly, the “less software” mantra is related to this, but even a tiny piece of software does not necessarily mean simple, not complex.

So, if you notice your controller method count is ballooning, or your controllers are more cross-wired than your plate of spaghetti, you might see an opportunity for using CRUD to restore sanity. But you can also ruthlessly adopt Einstein’s wisdom at every stage of development and use CRUD to make your app as simple as possible, but not simpler.

^[1] Jeremy often comes to work with an announce if you will. For instance, one day we were discussing something about languages; I mentioned Erlang. The next day Jeremy announces when he arrived, “I learned Erlang last night.” Sweet!