There is a war waging in the technosphere between those who favor thick clients (or rich clients as they are now called), and those who favor thin clients. Thin clients, and the server-mediated UI frameworks which support them, meet a singularly important requirement - to be understood by other programs, especially search engines. A large part of the utility of the internet is search, and search is only possible because web spiders can understand the simple structure of HTML and those internal relationships expressed as hyperlinks. These spiders cannot understand rich clients. Another increasingly useful part of the internet are mashups, where one application is used to decorate another with useful information. This, too, is rendered impossible by indivisible, atomic rich clients.
Indivisability, or atomicity, is what you get with a binary image, or a Flash SWF, aJava applet, a Canvas element, or a big hunk of generative JavaScript (like GWT). These elements are basically inscrutable by other programs. The DOM comes to an abrupt stop, and so does all ability to index, manipulate, or extend. When one of these elements expands to consume the entire page, the utility of the internet goes down a little bit because now there is information locked away, inaccessible. The entire page becomes an atom, and completely inscrutible.
And yet, these atomic technologies enable some truly beautiful interfaces, and in some cases are a joy to program with, so we don't want to give them up. Most applications should just use them and be happy, because 80% of searches are informational (as opposed to navigational or transactional - see http://live.psu.edu/story/29879 ), and most of these programs are transactional (that is, getting the user to fill out a form).
For informational rich clients, it's more complex. The bottom line is that you have to expose the information in the traditional way, too. This is less "cloaking" and more "exposing" internal state to the programs that need the info. Tacking on a trivial, non-beautiful HTML exposure of your data should be pretty easy, especially if your app is done in the SOFEA style. You have each page redirect to your rich client internal anchor. This is a valid use of a server-side framework.
This approach makes (almost) everyone happy. The data and it's relationship to external sites is exposed to search engines and mashups. The only person who is unhappy is the one who wants to use your UI in a mashup, along with the the data. But in the end, this is a minor impact. The importance of UI reuse is much less than the importance of information reuse.
Another approach is for the atom to finally be divided - for the web spiders to break the UI atom and release it's power. Unfortunately, this demands a great deal of computational effort on the part of the spiders, and is not scalable. If Google uses 20 megawatts today, expect this to increase an order of magnitude to break all the UI atoms out there, repeatedly. And then expect some information to be lost or misrepresented. From the mashup side it's a better picture - it is possible to analyze a running Java Swing program, for example, and expose a containment hierarchy as a DOM structure. No doubt a similar possibility exists for Flash, etc. Of course, JavaScript already exposes itself as a DOM structure, so it's a bit ahead of the game.
Indivisability, or atomicity, is what you get with a binary image, or a Flash SWF, aJava applet, a Canvas element, or a big hunk of generative JavaScript (like GWT). These elements are basically inscrutable by other programs. The DOM comes to an abrupt stop, and so does all ability to index, manipulate, or extend. When one of these elements expands to consume the entire page, the utility of the internet goes down a little bit because now there is information locked away, inaccessible. The entire page becomes an atom, and completely inscrutible.
And yet, these atomic technologies enable some truly beautiful interfaces, and in some cases are a joy to program with, so we don't want to give them up. Most applications should just use them and be happy, because 80% of searches are informational (as opposed to navigational or transactional - see http://live.psu.edu/story/
For informational rich clients, it's more complex. The bottom line is that you have to expose the information in the traditional way, too. This is less "cloaking" and more "exposing" internal state to the programs that need the info. Tacking on a trivial, non-beautiful HTML exposure of your data should be pretty easy, especially if your app is done in the SOFEA style. You have each page redirect to your rich client internal anchor. This is a valid use of a server-side framework.
This approach makes (almost) everyone happy. The data and it's relationship to external sites is exposed to search engines and mashups. The only person who is unhappy is the one who wants to use your UI in a mashup, along with the the data. But in the end, this is a minor impact. The importance of UI reuse is much less than the importance of information reuse.
Another approach is for the atom to finally be divided - for the web spiders to break the UI atom and release it's power. Unfortunately, this demands a great deal of computational effort on the part of the spiders, and is not scalable. If Google uses 20 megawatts today, expect this to increase an order of magnitude to break all the UI atoms out there, repeatedly. And then expect some information to be lost or misrepresented. From the mashup side it's a better picture - it is possible to analyze a running Java Swing program, for example, and expose a containment hierarchy as a DOM structure. No doubt a similar possibility exists for Flash, etc. Of course, JavaScript already exposes itself as a DOM structure, so it's a bit ahead of the game.
No comments:
Post a Comment