Monday, February 23, 2004
BEA's Bosworth: Separate URLs for GUI and Data Model
So I think about this a lot. And I do have some notes about XAML in my blog. But the most … I've punted on it. There are some reasons the browser became successful and we all started doing this… I don't know if you know this but I built the browser for Microsoft at one point. I built IE [Internet Explorer] 4 and built the DHTML and built the team that built it. And when we were doing this we didn't fully understand these points. And one of the points was people use the browser as much because it was easy to use as almost anything else. In other words I'd talk to customers and say we can add to the browser all these rich gestures. We can add expanding outlines and collapsing and right click and drag over and all that—all the stuff you're used to in a GUI. And without exception the customer would tell me please don't do that, because right now anyone can use the sites we deploy and so our training and support costs are minimal because it's so self-evident what to do. And if you turn it into GUI we know what happens, the training and support costs become huge. So one of the big values of the browser is its limits. . . . So I think what we want isn't a thick client, and I wasn't leading that way. But I think there will be some cases where there's a thick client. I think in general we still want to say an app is just something you point to with a URL. And you don't have to deploy it. And you can throw it out of memory at any time, and there's no code and no libraries and no interdependencies. All the great things about installation-free software that the browser gave us. And the other thing big thing of course is that if you make a change everybody sees the change. So how do I get my cake and eat it too? How can you have a model where you have a thin client just like we have today and yet it works well against the data model. And I think what you do is you have two things that you point at on the web. One thing you point at is the information and one you point at as the way you present it and interact with it. And then the browser is smarter and it knows how to cache. It already knows how to cache your pages and now it knows how to cache your information. And it knows how to do offline synch so you actually go offline and come back online and can synchronize. But other than that it's still a browser. You have to know one thing once and that's your browser. Then you just point to the URL and you run them in the way that you do in the browser mall as opposed to .EXEs. Now, Longhorn I think is conflicted about this. Bill [Gates, Microsoft chairman] has always wanted a thick client. Eric Rudder, in part is where he is because he promised Bill a thick client—and partly because he's brilliant and a great guy. I'm a big fan of Eric Rudder, which probably sounds funny coming from someone from BEA. Eric and I have a lot of mutual respect for each other. But he's trying to live up to a vision that in my opinion is mostly not in the customers' interests and that is a thick client. So I think the client's going to get thicker but will still basically be a thin-client paradigm. And I think that will be true because the customers, given the ease of use of the a radio, don't move away. Let me give you one other example. Word processing. I used to use this command-oriented word processor called Volkswriter. And other people used Emacs. It had all these powerful commands you could type in. And along came the WYSIWYG word processors. They were cooler and they printed much better, but I lost half the power I had. I could no longer say search for everything that contains this and then when you find it modify this part to include this note—things I could've said in the old command-oriented language. And no one ever went back. To this day word processors don't let you do that. Because it turned out there were 10 times as many people that needed the ease of use as needed the custom stuff.
Links to this post:
Comments: Post a Comment