 | ||
|
| ||
| ||
|
| ||
Robert Hess
Developer Relations Group
Microsoft Corporation
October 20, 1998
The following article, which was originally published in the Site Builder Magazine (now known as MSDN Online Voices) "More or Hess" column, continues a series in which MSDN Online columnist-at-large Robert Hess investigates application development.
As regular readers of this column know, I've been spending the last couple of articles focusing on how to strategically leverage applications in this new "Internet Age": Applying the Web and Application Development in the Internet Age. I've been getting some feedback from folks who have expected me to present the solution for how to go about this. Unfortunately, it is not quite that easy.
One way to think about Web application development is to compare it to buying wine in a grocery store. Let’s assume it is an upscale store, with a wine section and somebody who might be capable of helping you. If you were to ask him: "What wine should I buy?", would you expect him to turn around, pick up a bottle, and say: "Here, this is exactly what you are looking for."?
Of course not.
The quickest answer you could expect would be for the wine clerk to wander down the aisle, pick up a bottle, and say: "This wine just came in, and I personally think it is an excellent quality for the price -- but then, I like hearty Cabernets." To help you select a wine that really suits your taste, it would be necessary for the clerk to find out what you are looking for, what your personal preferences and experiences are, and for what occasion or purpose you are selecting the wine. Virtually every single wine on that store’s shelf is potentially appropriate for a particular individual or occasion--which goes to show why selecting the "right" wine can be a rather daunting task for the uninitiated.
The same is true for deploying your application on the Web. What tools should you use? Which technologies should you take advantage of? Clients? Servers? Scripting? Components? Browsers? All of these provide an extremely rich and robust array of ways to identify your approach. My intent with this series of articles is not to tell you how to solve your problem, but to provide you with the information you need to figure this out on your own.
The most important step is to understand what service you are trying to provide, regardless of how you plan to deploy it. Remember the old saying, "The end justifies the means." In this case, the end is the resultant service/application/functionality/information you are trying to provide to people, and the "means" is deployment as a Web site, a Microsoft Windows-based app, an e-mail newsletter, or a message on the Good Year blimp.
I've spent considerable time thinking through the issues and strategies of deploying solutions to users. Taking a Web-centric approach, and leveraging some of the lessons that even standard application developers can learn from Internet-based solutions, I've come up with the following methods.
A page-based solution is one that users conceptually see as a browsable collection of pages on the Internet. They launch their browsers, navigate to your site, and then partake in the services you provide. I've broken this category of page-based solutions into two different approaches.
Some solutions are best targeted with the broadest possible reach. One way to do this is to use a Web site that attempts to be compatible with as many "modern" browsers as possible, to use HTML 3.2 for the page layout, and to test extensively for potential rendering differences.
This approach doesn't rely on specific capabilities or technologies that one browser might offer over another. Instead of focusing on "client" technology, such a site could spend time and resources focusing on "server" technology.
A browser-neutral approach is not without risk. You still must carefully test your site on a variety of browsers. There are a number of minor differences in how the various browsers render a given page. So you need to be aware of how your design layout is interpreted by the browsers in which your application will be deployed.
As Web browsers evolve to address goals that both users and authors want to achieve, a Webmaster may feel compelled to take advantage of new features. Cascading Style Sheets, client-side scripting, Dynamic HTML, components.... All of these represent capabilities that increase the richness of the user’s experience, but aren't necessarily supported by the majority of browsers (or are features that the user can turn off selectively).
A browser-biased Web site takes specific advantage of browser’s features over those of another -- or perhaps just features beyond the HTML 3.2 specification that might be supported by the "latest" browsers on the market. To maintain a degree of compatibility with lesser browsers, such a site often will employ some method of "browser sniffing" in order to determine what browser and version the user is using. A problem with this approach is that multiple versions of the page or template need to be authored to address the various browsers. Many sites create an HTML 3.2 version as well as a more “advanced” version of the pages. The server then sends that advanced version to the browsers that can render it, and sends the HTML 3.2 version to all other browsers.
While the Web may be the latest fad, a Web-site structure may not be the right solution for the service you are trying to provide. Web-based solutions in general have a problem when you need to gain access to the user’s system for any reason. The tight security levels attached to Web sites insists that they can do little locally on the machine. If your solution needs to access the local file system directly, adjust or influence system settings, or in some other way provide a more integrated experience for the user, you might need to move to an EXE-based solution -- a self-executing file that a user can download, save on her hard drive, and run from that hard drive.
Close to the notion of what a Web site can be is what I refer to as a "connected" application. This sort of app requires a network connection for its functionality -- perhaps because it leverages a shared data resource on the network somewhere, or simply because it is doing all of its processing on a remote server, and the client system is simply the app’s visual front end.
Such an application would leverage a lot of functionality from the remote server, and would rely less on the processing abilities of the client system. A Web browser is an example of a "connected" application.
I think of a "connectable" application as a traditional Windows application that you might buy at the computer store. Little, if any, requirement for network connectivity is built into it. However, with Internet connections becoming more commonplace, it only makes sense for such an application to be able to leverage this opportunity for additional capabilities and services -- if only to check the Internet for updates, or to make additional options available via download. But often, applications will use this connectivity to provide a richer level of functionality or user experience. Offering some level of Internet awareness to an application is quickly becoming the norm.
These categories aren't intended as hard and fast definitions of the only ways to design an application, but simply a general layout of the strategies you might be able to target. A wide spectrum of possible approaches can be explored, each utilizing various components of the above as appropriate. It is even conceivable that an application could leverage all of the above categories for specific areas of its functionality.
The right tool for the right job, and the correct approach for a specific solution.
Robert Hess is an evangelist in Microsoft's Developer Relations Group. Fortunately for all of us, his opinions are his own.
Did you find this material useful? Gripes? Compliments? Suggestions for other articles? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top