Most software projects are robotic foster children, cobbled together by program managers who mostly think of their jobs as copying what other people have done to have "feature parity", and engineers who think of user experience as a necessary evil. It's not an experience that balances the best of user needs with the greatest technology you can dream about.
You can be an innovator in one piece of the puzzle and forever whine that you were ahead of your time (I've done it), build a great technology that nobody uses, or insist that things should work a certain way but never build them. But the people who get it done work harder and slay a lot of beasts along the way, not by copying what others do, but by really trying to finish something new, they should be commended.
One of the things I've noticed is, when you start with the right problem and really do some work on it, you enable a new way of doing things. Consider that Flickr started as a gaming platform, and ended up solving some problems that enabled a new kind of community. These things are a different slice against the problem space, and a way of not letting the technology limit what can be done.
Our Hello product, which never made the hurdle to being on the Web, also did some incredibly novel things on a tech level. The idea that conversations were documents with all kinds of media, that you could merge participants into...yeah, that's very familiar to me.
I do believe that these things can only happen on small teams that really own a problem. They can't be told no, they can't have a surrogate parent dictating UI standards or technologies to be used. Because for the most part, these top-down choices keep you in the box that was there before.
Once you've seen this happen a few times, you understand that there are some technology paths that lead to magic. When you find yourself considering a technology that if you built it, you could use for 10 different applications, without spinning off into a 200-page spec or a mess of edge cases, there is magic there. The things you can keep simple, and still see the path forward, those are the great ones, those are the real enabling innovations that spur ten years of growth.
Similarly, to make good products, you have to have a belief that certain things should be both possible and easy for people to use.
To use a little example, we built drag and drop into the browser in a dozen proposals and demos and never got critical mass around distributing it. Drag and drop into the browser was one of the first conversations I had with the Blogger guys when we were talking about Picasa and Blogger/Google working together in 2003, and it got really shipped after 5 years. Man, I could tell you a dozen neat tricks for communicating with a webpage, but they're not something you can use, and that's not good enough.
The "Demo" piece of this is the belief that this should be easy and possible, and the will to make it happen. Attaching drag and drop photos into Wave, and making it important to the experience, and getting over that hurdle to convince everyone that it's obvious that it should happen. That Demo is an important act, because it sets a path for everyone to follow.
Technology innovation and user experience is this story that is very hard to tell as you're doing it, but is completely obvious in retrospect. Once someone innovates, it's obvious to everyone else that it always should have been that way, but it isn't obvious when you're doing it. So I do have some respect for the people who can put their arms around the whole problem and get something done.
I don't usually quote Larry Ellison, but I'll make this exception:
There are really four phases. In phase one, everyone tells you you're crazy and it's the stupidest thing they ever heard. In phase two, they say, "There is some merit to the argument. It's still crazy, but there's some merit to it." Phase three is, "Well, we've done it better than they have." And phase four is, "What are you talking about? It was our idea in the first place."
