Rich clients, network wealth

Many people find it unthinkable that Microsoft might lose its dominance of client software, so I ought to expand on my recent posting about Avalon: Microsoft's microchannel.

I had forecast that, in ten years' time, applications will "run in rich browser clients, Windows will have settled into its legacy platform niche ... and Microsoft will be working hard to re-establish the market position of Office having relaunched it as a web-based application." In comments, Jean-Jacques Dubray observed "from experience ... that it is:

1. really hard to build enterprise application front end with web technologies,
2. the result is suboptimal by a large margin."

Barry Briggs asked, "... will you ever use an HTML page to do rich word processing or touch up your photos? I think not. I've been hearing about the death of the rich client for nearly a decade; not going to happen in the near term ..." Warming to the theme in his own blog, he says that my post "unfortunately gets it completely wrong."

I think what people found most difficult to accept was the notion that a browser-based client could be powerful enough to replace Windows. But bear in mind that I allowed myself a generous ten-year timescale for my prediction. A lot can happen in ten years, and a lot is already being tried out in the realms of web-based rich client technology:

• IBM is working on Workplace Client Technology, a link provided via an email comment by Terry Leach.
• There's Macromedia's work on its Flex architecture.
• DreamFactory is proving popular among leading-edge adopters of online applications.
• And BEA's Adam Bosworth has written at length in his blog about what he'd like to see achieved with the company's Project Alchemy [link updated 31 July 2004].

Nobody involved in these and other similar initiatives is fooling themselves that they can do everything that's required in the browser as we know it today. But they do believe that they can get there by building on today's browser technology as a foundation, which is a route Microsoft explicitly rejected when it halted work on DHTML.

The other element here is the 'good enough' factor. Yes, Barry is right that individual creative activities like rich document editing and photo retouching need to execute locally. People who are seriously into those activities will want the appropriate base-level capabilities built into their client devices, in the same way that some people buy expensive digital cameras or invest in specialist publishing software. But the mainstream market is for simple, easy-to-use, cost-effective, multi-purpose (dare I say it, lowest-common-denominator?) client devices, because what matters most is being able to tap into network resources, and Microsoft is making the mistake of failing to prioritize that network readinesss.

Jon Udell's recent column on The Google PC generation made a very strong case for deploying PC horsepower to marshaling data rather than enhancing the user interface: "If you join massive horsepower to vast data, amazing things will happen." The mistake that Microsoft is making by pouring resources into Avalon is to focus on perfecting the user experience for solitary creative endeavours at the expense of enhancing good-enough access to the tremendously powerful collaborative resources of the Internet (low-cost photo touch-up service providers, for example).

posted by Phil Wainewright 10:22 AM (GMT) | comments | link