Standards-making bodies
A quick note, apropos of some changes in IE 8 (via Ajaxian): a lot of people who design websites, including an earlier version of myself, have made a fetish of interoperability and standards-compliance. I’ll grant you that those are valuable goals, but it’s almost a tautology: the more standards-compliant you are, the less innovative you are. Standards-compliance means, among other things, waiting for a standard to appear. In the meantime, you need to use whatever standard technologies are available. E.g., go back to the era of CSS1. When that was the only tool available, standards-compliant sites didn’t look that good. Using Flash was sensible.
Nowadays, CSS is better but still not great. There’s no standard way to embed a video container on a web page so that everyone can view it, so of course people use Flash for this. HTML 5, I’m told, will add a video tag to help with this, but that’s just the point: the standard to solve a problem came along after innovators — YouTube in this case — had solved it in their own ways. What would YouTube have done if it had tried to be standards-compliant from the start? It probably would have done exactly what everyone else did before YouTube, namely include a link to an AVI file or something. YouTube made a strong innovation that helped it spread far past the bounds that any other video-sharing service previously had reached, precisely because it uses a little bit of code to embed a Flash container in any website that cares to use it. It had to make its own standard in order to innovate.
That first link above suggests that Microsoft is proposing some UI innovations for IE 8. A quick glance says that it has observed some patterns in the way people use the web (copying and pasting a link, blogging about a link, etc.), and has developed some code to make that pattern more efficient. There may be a way to implement this pattern in JavaScript and CSS, or there may not be. We shouldn’t have to wait for a standard to get a solution to this problem.
Besides which, “waiting for a standard” doesn’t encapsulate the way I understand the process works. The way I envision it is that YouTube, blip.tv and whoever else all try out their own ways of embedding video in a platform-independent way. Then a lot of them get a seat at the standards-making table and decide how browsers should implement something like the “video” tag. That is, the standard should reflect the best technologies that anyone has come up with. If the standard were invented in the abstract — that is, before anyone has tried to solve the problem on his own — it’s likely not to match up with what people actually need. It’s likely to be a solution in search of a problem — architecture astronauts, in other words.
In short: the best standards, it seems to me, will necessarily come after a long period of sussing out a problem. And that experimentation will not fit comfortably within existing standards (e.g., YouTube did not fit comfortably in a world comprising only CSS, HTML, and JavaScript); if it did, we wouldn’t need to develop new standards.
So let’s not make a fetish of interoperability. We have problems to solve first.
I agree with mrz, and he hasn’t even responded yet. I also agree with you that experience is the best dictator of standards. Standards should form in the wake of innovation.
The problem comes at convergence-time, when there is a lot to be gained by having my implementation become the standard (less code I have to change, more change for my competition). The politics of this process can lead to drawn-out battles that hurt the consumer (HD-DVD v. Blu-Ray, anyone?) and delay further innovation. Any ideas on that problem?
Comment by Seth — March 6, 2008 @ 7:27 am
I think the answer is economics!
In practice, I wonder how the politics here work out. And would it be better just to let the market work out the confusion on its own? That’s how Beta v. VHS worked out, right?
To really answer the question involves, I’m sure, digging into a lot of particulars. Some companies probably stack standards-making bodies with members that are friendly to them; some use the market to destroy the competition; etc. Shapiro and Varian have a chapter devoted to this.
Comment by slaniel — March 6, 2008 @ 8:59 am
I agree with what I haven’t said yet…for the most part.
Generally, you have to let folks thrash around for a while to figure out where things are going because you can’t necessarily architect stuff up front. That said, sometimes, it’s OK to take a look at the field and say “Man, these all suck. Let’s do something smarter.” and make that the standard. That doesn’t always work, but sometimes it does. Am I wrong in thinking CSS was like this? That is, everybody took a look at all the crap going on with HTML tables and what-not and said “Man, this all sucks. Let’s figure out the right way to do this.” and lo and behold we get CSS. Gratned, it’s not 100% adopted or whatever, and it needed some follow-on work, but it’s getting wider and wider adoption because folks see it as going more in the right direction than making everything flash or continuing to screw around with tables or what-have-you.
Comment by mrz — March 7, 2008 @ 11:54 am
Also, let’s not forget HTML. Started out as some academic thing, got a few more nudges from industry, but is still significantly based on the original acedemic idea.
Comment by mrz — March 7, 2008 @ 1:52 pm
In fact, it’s probably best to just stop reading things like Joel on Software for a while. I find it’s very easy to read stuff like that and get mislead by either the inherent over-generalization articles like that make or to fail to really get at the kernal of truth in most of those articles.
Yes, there is valuable knowlege to be gained but I find many articles by people who are experienced basically boil down to: Don’t do this dumb thing or, more specifically, don’t get too wrapped-up/excited about X becuase then you’ll do this dumb thing, or I/my team/my coworkers/my boss did this dumb thing, please don’t do this dumb thing. This can be important, but you have to be very careful because one person’s interpretation of what makes a thing “dumb” can be quite different. That means, you have to be very careful about extracting meaning from stuff like this.
It’s very easy to over-generalize or miss the point. It reminds me of a Buddhist saying that goes something like “…thus we should be more like the baby, but if you say to people ‘The baby is the Way’ they will misunderstand you.” So for this article, it’s very easy to jump from “architecture astronauts” to “OMFG STARDARDS IZ 4 DA RETARDS!!!111 MARKETZ R00L!!”. Again, the kernel of truth here is more like “If you overdesign things in a vacuum without understanding the requirements, you will create a solution in search of a problem. Moral of the story: Don’t get over-excited about your own interior interpretation of things or you will do a dumb thing.”
Again, I’m not so down on articles from Joel on Software, but keep that grain of salt handy.
Comment by mrz — March 7, 2008 @ 3:15 pm
Well, I have a particular attachment to that Architecture Astronauts article, because it was written about a former employer back when I was working there. Specifically: everything he says in there about Groove is true. They built in a ton of functionality — lots of things that Joel doesn’t even mention — that it turned out no one needed, and it took them years to reverse those decisions. The architecture was supposed to be Groove’s saving grace, but instead it was a great sin.
I think what you’re saying about that Joel article is “Don’t take lessons from it that Joel doesn’t really intend for you to take.” Which is good advice for any text, software or otherwise.
Comment by slaniel — March 7, 2008 @ 3:19 pm
[...] more about interoperability fetishism, a few specific web problems occur to [...]
Pingback by Stephen Laniel’s Unspecified Bunker » Some questions about writing interoperable websites — March 17, 2008 @ 7:41 am