Therefore, I think a web-based version of Word is possible, but it would be much more focused on editing a richly formatted document, and not have all the other stuff that makes Word more of a desktop-platform, instead of a simple word processor.

Web-based apps can have general purpose API’s (think Flickr, Google Maps and Backpack for example) that allow them to be extended by end users.

Thanks for the comments.

Word is as complex as it is, and if there was a niche for less complex word processing applications, you’d be seeing them already taking over the market.

These things regulate themselves, kind of…

Elling

Yes, they are very different things I agree. I would also agree it’s folly to tackle Word or Excel functionality in a browser. At this point, I’m not sure that anyone would ever tackle the development of Word or Excel, period. They are too monolithic, too full of unused and unusable features, too general for their own good.

The perspective of a Word or Excel developer–your perspective–is not one that makes sense for the majority of developers. That is because very few people will ever develop a software product with that kind of reach, or those types of requirements. When the need does arise, I have no problem with leaving it to the small number of organizations with experience at programming-in-the-large.

Microsoft’s position as reflected by John Montgomery is that the solution to Microsoft’s problem is also the solution to everyone else’s problem. If we only abandon web standards and the old MS standards like VB and COM, we can all move to .NET 2.0 and be able to develop rich thick-client apps. But even MS’ own Office group isn’t going to move there anytime soon. I say let them lead.

Of course, the odds are better that the simple and single state application will be easier to use…

But, it doesn’t in any way imply that a Word replacement application could be built using the same technology that’s used to build Google Maps.

-

As for Wiki/Google versus interaction with HUGE datasets, you’re right. They are both examples of web based interaction with huge datasets. And I agree, they work very well. But these applications are ALSO examples of simple and single state applications where you’re kind of working with a pin hole view of the whole data set. And for these types of applications I agree that web based interfaces work very well.

Elling

I compare that to the beauty of Google Maps. It’s simple, intuitive, and very rewarding. I was going on vacation recently and had a map of the area up in Google Maps. My wife asked “I wonder if there are any good places to shop” and I clicked local search and put in “shopping malls” and a forest of pins appeared. She said “wow!” This is a woman who has been in tears when MS Word mysteriously lost her form data, and who is annoyed by Outlook 2003 consistently labeling several of her newsletters as spam. Which user experience is more degrading to her?

I’d say a map of the USA is a lot of data and Google Maps does a decent job of “EFFECTIVELY navigating huge amounts of data” with a web-based interface. With typical broadband connections today, it’s already possible to send more data in real time than a user could reasonably view.

AJAX is designed to take advantage of the technologies currently at hand, and it does that very well. In contrast, .NET and Java development environments want to create new infrastructure on the client and server. It would be perfectly feasible to build a tool like Visual Studio that made use of existing standards to build dynamic and interactive web pages.

I will work on my writing style. I appreciate the criticism. As for your point about the web being unsuitable for certain heavy data situations. I agree, but keep in mind that many of us use the web (google.com) to search and browse huge amounts of data. Some websites (wikipedia.org) allow users to edit huge amounts of data.

That a web based UI is simple, but simple is good? Is that what you’re trying to get across?

I think you’re a BIT unclear in your writing.

However, if that’s what you intended to say, then I agree with you in many cases. But when it comes to professionals who do browsing and data navigation for a living, HTML + scripting doesn’t cut it.

If you want an application for EFFECTIVELY navigating huge amounts of data, you do not want to be using a web based interface…. Not in any case, I think.

Sure, if you want to do just a couple of lookups, then HTML + scripting is fine. But for data maintainance, and heavier types of data interaction, then HTML doesn’t cut it, and honestly I hope it never ever will… because it’s already FAR too bloated the way it is now, I think.

Elling
elling.bjastad@gmail.com