Michael Edwards
Developer Technology Evangelist
Microsoft Corporation
October 21, 1997
Introduction
HTML Forms
Saving User Info
Dynamic HTML Enables Very Engaging Pages
Microsoft Visual InterDev, FrontPage 98 Beta and Other Tools
Summary
The number of Web development technologies is growing about as fast as the number of new Web hosts (or so it seems). These days, there are many more ways to obtain user input on a Web page than using HTML forms. It's a good thing, because you need to get much more information from the user than what they can type into an edit field. This article provides overview information on several user-input technologies that you can employ to get what you want from your users. I will briefly discuss how each technology works, what authoring and coding skills you need to use each one, what target platforms each works on. I'll also provide a profusion of links to more information, samples, and articles.
Just about every book on HTML (the shelves were laden with several dozen of all sizes and colors the last time I checked my favorite bookstore) has at least one chapter devoted to HTML forms. But books cost money and you want something for free, right? Well, let's start with the free, 20-minute tour and go from there to more advanced user-input methodologies (also free of course!).
The <FORM> element lets you insert static and editable text fields, drop-down menus, buttons, check boxes, and radio buttons into your Web page. Data obtained from the form is sent (through HTTP protocols) to a server for processing. HTML forms are useful for obtaining text-based information and choices from users. For example, an HTML form can get parameters from users to submit a query to a server-side database, and display the results of the query on the client's machine. Or, a set of HTML forms can create a data-entry package for updating records in a server-side database.
Let's look at a simple example, one you have probably seen umpteen times. The Archive of XML-Dev site at http://www.lists.ic.ac.uk/hypermail/xml-dev/ lets you browse and search the XML-Dev e-mail list. For those not familiar with e-mail lists, they are simply a way to coordinate sending and receiving e-mail among a list of people professing a common interest. This site is an archive of all the posts to the XML-Dev mailing list since it was founded. A certain public-spirited individual has made the contents of all the posts searchable. We'll get into how they did that in a minute, but first let's look at the code that displays this simple form:
<form method=GET action="/cgi-bin/wwwwais">
Search for: <input type=text name="keywords" size=40>
<input type=hidden name="source"
value="/usr/local/wwwindex/sources/xml-dev/index.src">
<input type=submit value=" Search ">
</form>
Note that the form data and code is completely contained inside the <FORM> element. Let's discuss the child <INPUT> elements and then the <FORM> element's attributes.
The first <INPUT> element inserts a text box in which the user can type the search keyword. The text box is indicated by the TYPE attribute (type=text). Other values for this attribute insert a check box (type=checkbox), radio button (type=radio), or push button (type=button). The NAME and VALUE attributes of <INPUT> specify the variable name and initial value for the data associated with that element. For example, the value of a text box is the text that is typed in it and, because this example does not include a VALUE attribute, the Keywords text box is initially empty. Data entered into a form is sent to the server using pairs of name=value strings, one for each <INPUT> element in the form. If I were to enter "CDF" into this text box, the string "keywords=cdf" would be sent to the server.
The second <INPUT> element uses TYPE=HIDDEN. <INPUT> elements specified as hidden are not displayed to the user. Hidden <INPUT> elements send a name=value string to the server that the user doesn't have to know about (and can't modify). This particular element sends the string "source=/usr/local/wwwindex/sources/xml-dev/index.src" to the server.
The last <INPUT> element uses TYPE=SUBMIT, which is a special kind of button. Can you guess what happens when you press the Submit button? Yes, the browser gathers all the current name=value strings and sends them to the server. How do the strings get to the server, and what happens next? That takes us back to the first line of code and the <FORM> tag.
There are two attributes in this <FORM> element. The METHOD attribute specifies which of two HTTP protocols to use to send the name=value strings as input to a server-side program. The server-side program is indicated by the partial URL in the ACTION attribute. There are two HTTP protocols you can use: GET and POST. I'll assign learning the POST protocol for homework, and go over the GET protocol, which is easiest to explain anyway. (There are some security concerns with older browsers and the GET protocol; see http://www.microsoft.com/security/creditconc.htm. In short, the POST protocol is the most secure method, and the W3C standard, for handling financial transactions) When you use the GET protocol, the browser concatenates all the name=value strings to the end of a URL for the server-side program. For example, when I search for "CDF" the browser surfs to the following URL:
http://www.lists.ic.ac.uk/cgi-bin/wwwwais?keywords=CDF&source=%2Fusr%2Flocal%2Fwwwindex%2Fsources%2Fxml-dev%2Findex.src
Note that the actual URL and form data are separated by the "?" character and the path separator characters are converted to their ASCII equivalent (%2F). When this arrives at the Web server, the "?" tells the server that the "wwwais" part of the URL is a program that should be executed and passed the string that follows the "?". The server communicates with the program (called a gateway program) using the Common Gateway Interface (CGI), and the program gets the parameters from the browser through standard input and sends data back to the browser by writing to standard output. What does it write to its standard output? HTML of course. In summary, the server-side program uses the information sent from the client to dynamically generate a Web page that is sent back to the client by the Web server. So the code above is, in a sense, a virtual URL.
Using HTML forms is cool because the client-side code is so simple to write and understand, and HTML forms are extremely cross-browser compatible. Just about every browser can display HTML forms, even purely text-based ones. Plus, many browser-specific extensions (like the button <INPUT> type) are supported by both Microsoft and Netscape.
Until recently, most HTTP servers ran on UNIX boxes, so if you wrote any gateway programs you were probably a fairly well-versed programmer (and really hard to scare I bet). But even if you eat code for every meal, the CGI approach creates this problem: the Web server must spin off a separate program for each user request. All those processes running concurrently on the server can bring a popular site to its knees. There are better ways to process user input on the server—today's Web servers sport programmable extensions that run in the same process as the server itself and provide extra features that make programming tasks easier.
Microsoft Windows NT® with Internet Information Server (IIS) extensions includes an application programming interface called Internet Server API (ISAPI). Win32® developers can write code that talks directly to this interface to do all the things they can with CGI, and more. You can use ISAPI to get forms data and send HTML back to the client. And you can write your server-side code in any language that can interface with a Microsoft Windows® DLL, such as C/C++, Java, Microsoft Visual Basic®, or even scripting through Active Server Pages. Because HTML forms access these applications the same way they would a gateway program (through the ACTION attribute of an <INPUT> element that is assigned a TYPE value of SUBMIT), and because all Win32 code runs on the server, the solution is a fine cross-browser approach. ISAPI can make writing a database application, such as an order entry form or custom catalog, a lot easier. You can also make use of the entire Win32 API and the range of programming tools available to write Win32 applications.
Microsoft Visual C++® Microsoft Foundation Classes (MFC) began supporting ISAPI when MFC version 4.1 was released over a year ago. Several MFC classes support the creation of two types of server objects: server extensions (or DLL-based apps), which provide a more efficient alternative to CGI apps; and filters, which is a server-based mechanism for screening messages sent to and from the Internet server. For example, the MFC ChttpServer class includes methods to receive forms data from the client and the ChtmlStream class is used to send an HTML stream back to the client.
Another approach provided by IIS-compatible Web servers (Windows NT Server, Microsoft FrontPage® Server Extensions, and Microsoft Windows 95 Peer Web Services) that will appeal to people with HTML and scripting experience is using Microsoft Active Server Pages (ASP). ASP is a server-side scripting environment that integrates a set of scriptable objects with HTML, so you can leverage what you already know about creating Web pages. When a browser requests an .asp file from the Web server, ASP parses the requested file from top to bottom, executes any commands, and sends the resulting HTML page to the browser. So ASP is also a fine cross-browser solution to processing HTML forms on the server.
The primary built-in ASP object for getting information from a Web user is the Request object. The Request object gives access to five collections of information, one of which is the data submitted on an HTML form.
ASP
ISAPI
MFC
CGI
Sometimes Web pages need to save information that's been obtained about the client. Saving this type of information for later use can help preserve user preferences or other information to provide a better experience for users who return to your site. Sometimes you need to save information, either temporarily or permanently, for your design to work properly. For example, you might need to create a multipage form whose subsequent pages depend on information that was obtained in the previous pages. There are a number of ways you can do this, and we'll start off describing the only cross-browser method I am aware of.
In Web parlance, cookies are a means of saving information (such as browser settings, recently visited Web sites, and class paths) on the client machine. There is some controversy about cookies. Some users feel that cookies are a significant security hole, providing nefarious programs access to information on the client machine. This perception is partly due to the opacity of cookies: users don't know when a site is storing a cookie on their machine, what information is contained in the cookie, or (most importantly) how the information in the cookie is going to be used. So cookies are seen as invading the privacy of users. Responding to this concern, adjustable security settings (such as in the Advanced tab of the Internet Options command on Internet Explorer 4.0's View menu) enable users to disable cookies or to receive a prompt before accepting cookies. If you use cookies, be aware that they are perceived by some as an invasion of privacy, and have a backup plan prepared for clients who don't accept cookies.
In Internet Explorer 4.0, cookies are properties of the Document object, and are accessible via scripting. Through scripting, you can give the cookie an expiration date, allow it to be shared with other pages in the server domain, and require the cookie information to be accessed from a secure environment. You can also determine whether cookies are enabled or disabled on the client.
You can save cookies on the client by using HTTP version 1.0 request headers, but this topic is more complicated than I want to get into right now.
Cookies are the only cross-platform technique (that I am aware of) for persisting data on the client. But if you can live with creating solutions that will only run on Internet Explorer 4.0 platforms, you have a couple more options for saving state or other data on the client.
The first method is the IPersistHistory interface, which is designed to retain state information on a given page and can be retrieved later. The Internet Client SDK includes a sample Active Template Library (ATL) ActiveX™ control that uses this interface. It is called Percy, and you will find it in the Samples list. (Download the Internet Client SDK at http://www.microsoft.com/msdn/sdk/)
If you need to save state information from one page that can be accessed from any other page in your domain, you will want to check out the IDiscardableBrowserProperty interface.
If you've got a database, either local or remote, you can also put a Data Source Object (DSO) on a Web page that supports updating data back to the source. Scripts on your page can be tied to the fields displaying records from the database, so the user can update information and have those updates propagated back to the server. Of course, you could use the DSO mechanism for saving data from a Web page without binding the DSO to controls or HTML elements. This might require thinking "outside the box" a little, but since DSOs provide a way for a Web page to change data on a server, you could create a DSO for that sole purpose. Nobody says you have to use DSOs to bind server data to visual elements on a Web page; you could build one just for persisting information from a Web page to the server. This method provides a means to persist data that could be accessed from any other Web page, and it is the only form of persistence that could outlive a major catastrophe on the client.
The Internet Explorer 4.0 Profile Assistant is the first implementation of the types of privacy capabilities enabled by the Platform for Privacy Preferences (P3P), a W3C project for expressing privacy and user preferences on the Web (see http://www.w3.org/P3/Overview.html). The Profile Assistant enables user profiles to be exchanged between Web clients and servers while respecting the user's right to privacy. This solves one of the biggest problems with cookies—users want to know (and be able to control) exactly how information about them is used by a Web site. With the user's explicit permission, the Profile Assistant enables HTML form fields to be prepopulated from user profiles stored in the Windows registry. New information entered into a form can also be saved to the registry so the user never has to type it in again. If your users are like me and hate having to type the same stuff over and over again, they'll appreciate your use of this new Internet Explorer 4.0 feature. Profile Assistant can be disabled by the user.
There are lots of great reasons to track page hits on a Web site. If you are publishing an Active Channel, you can include page-hit logging for pages indicated in the Channel Definition Format (CDF) file. If you are a C/C++ developer, you can use the Hit Logging API to log information such as the browsing context (normal browser window, theater view, Active Desktop™ item, or Active screen saver), whether the page was viewed from the cache, the date and times viewed, as well as any custom information that can be encapsulated in a string.
Dynamic HTML—a set of cutting-edge features enabling authors to dynamically change the rendering and content of Web page in Internet Explorer 4.0—adds lots of new functionality that can make your pages more interactive and engaging. Happily, many of these features are standards-based implementations of new functionality in the HTML 4.0 Document Object Model (DOM) and Cascading Style Sheets (CSS) specifications currently before W3C working groups. That means you can expect these features to be supported on all Internet Explorer 4.0 platforms. And, because Netscape has pledged to support W3C standards in their browser products, making these new features work cross-browser will get easier.
The HTML 4.0 specification applies several new event attributes to HTML elements. Most of the new events are intrinsic in nature, meaning they are repeatable, and others are triggered only once. Because not all events apply to all elements, you'll need to have your updated HTML references handy while you code. These additional event attributes create an opportunity for expanded user interaction with individual tags on your Web page through scripting. Now you can respond to even more user-initiated events than before.
HTML 4.0 forms improved the navigational model for users by adding the ACCESSKEY and TABINDEX attributes for specifying keyboard accelerators and tabbing order for controls. Plus, there are new attributes for specifying read-only and disabled states for forms—thus your forms can reflect different states according to radio button or check box settings.
The new STYLE attribute for HTML 4.0 provides more flexibility when indicating style information. Because the STYLE attribute can be applied to any HTML element, authors have direct control over the rendering of individual HTML elements in their document. When combined with the host of new HTML 4.0 user interaction events, authors can do things that would have required a plug-in or control before.
HTML 4.0 specifies a new SYTLE element that is handy when a style will be reused for several elements. Authors can place any number of style elements in their document header and apply them to the entire body of the document. HTML 4.0 does not specify a particular style language; the TYPE attribute is used to indicate the Multipurpose Internet Mail Extension (MIME) type. Internet Explorer 4.0 supports the text/css type, or Cascading Style Sheets (CSS). With CSS, you can use the <STYLE> tag to specify style information that is applied to all instances of a given element, to a named class of elements (identified by their CLASS attribute), or to a specific instance of an element (identified by its ID attribute).
CSS is called cascading because the browser follows rules of precedence (in a "cascading order") for styles applied from multiple sources. For example, styles applied via a STYLE attribute on a specific instance of an HTML element take precedence over styles applied to the entire body of the document through the STYLE element.
The <LABEL> element has gained the new FOR attribute so authors can associate a <LABEL> with another HTML element. This was done to allow input focus to be reassigned from the <LABEL> to its associated element. Assigning a <LABEL> element's FOR attribute to the ID value of another element tells the browser to assign focus to the associated element.
All these cool new elements and attributes can't do a whole lot of good (from the standpoint of enhancing user interaction) without a Document Object Model (DOM)—the standard way for scripts to dynamically access and update the content and structure of an HTML document. Internet Explorer 3.x and Netscape Navigator 3.0 embody what is referred to by the W3C as "level zero" object model functionality. The W3C is currently refining the "level one" and "after level one" deliverables for the Document Object Model specification that is implemented in Internet Explorer 4.0.
What's so cool about the new object model? Well, there's already a gazillion articles answering that question in volumes of detail (see the following "For more information" section for a list of a few). Here's an overview of the user-input coolness.
The limited nature of level zero basically boils down to two things:
The new object model:
The new object model is the "Dynamic" part of Dynamic HTML and the core Internet Explorer 4.0 feature for designing Web pages that respond to the user.
Dynamic HTML
W3C documentation
MIME
Scripting
There are several other features in Internet Explorer 4.0 that are extensions of the above standards-based features and provide some pretty cool ways to drive user input.
There are two features that provide dialog-like functionality that is modal to your Web page (meaning that the page is disabled until the user dismisses the "dialog"). The first feature lets you load an HTML file into a modal dialog window, and the second feature lets you open up a Win32-style dialog box with input and output parameters accessible through script.
The first dialog feature is the showModalDialog method on the window object. In addition to specifying a URL to be displayed, you can pass input parameters in a Variant and receive a string, number, or other value in return. For script coders this method is documented in the Dynamic HTML section of the Internet Client SDK documentation (MSDN Library, SDK Documentation), and you C++ types can get it from the IHTMLWindow2 COM interface that provides access to the window object.
The second dialog feature uses the ShowHTMLDialog function that is implemented in mshtml.dll. Technically, you need to know a little C++ to use this feature, but the Internet Client SDK includes the tiny bit of Win32 code you'll need to dynamically load and call this function. It's in the HTMLDlg sample available in the Samples List (Download the Internet Client SDK at http://www.microsoft.com/msdn/sdk/). The sample also shows how to use script to exchange parameters and return values with the dialog window. With this sample, you'll use your vast C++ skills to only create a dialog resource file in your favorite dialog editor. You might also want to read the "HTML Dialog Boxes" in the Internet Client SDK documentation (MSDN Library, SDK Documentation).
If you only want to show a message box to the user, you should check out the alert method on the window object (also documented in the Dynamic HTML section of the Internet Client SDK documentation).
Help authors will be pleased to learn the WinHelp API has evolved into the HTML Help API, providing users with a Web-like interface for application- or context-specific help. In addition to a Win32 API to control loading and displaying your help file, a set of tools are provided to assist authors in creating and organizing help content and navigational elements.
You can show HTML Help through a Win32 function call, and you can also use script with the showHelp method on the Window object to display a help file that is created in WinHelp or HTML Help (see the Dynamic HTML section of the Internet Client SDK).
For more information, look up the "HTMLHelp API Reference" in the Internet Client SDK documentation.
If you are writing a control or application where people can paste stuff they copied from an HTML document, you might want to support the HTML Format clipboard format. "HTML Clipboard Format," in the Internet Client SDK documentation, goes over context information provided with this clipboard format to supplement the copied HTML. The article also includes examples for parsing the format that are taken from the behavior of Internet Explorer 4.0 (the definitive source for correctly handling clipboard operations for HTML).
There are various technologies available for developing and using controls on Web pages. For example, using the Component Object Model (COM) with ActiveX technologies provides one way to develop reusable, language-independent, plug-in components. By endowing these components with an interface named Automation, it becomes possible to place them on a Web page and use them from your favorite scripting language. Typically, these COM components are developed in C++, but COM is a binary standard for function calling between components, which means it is possible to develop a COM object using any language.
You can also write Java components that can be utilized from script on a Web page. All of the Java development products on the market today include various control libraries from which you can draw. For example, Microsoft Visual J++™ ships the Advanced Foundation Classes (AFC), a set of reusable Java classes providing functionality equivalent to the various Win32 user-interface controls you are already familiar with.
You may be aware of the burgeoning market for controls developed by third-party developers. Many of these controls present an interface to users; for example, a tree view control for viewing hierarchical information such as file systems. There are also high-end authoring systems you can buy that provide complete packages for such things as Web-based forms or electronic commerce.
You can also build custom, reusable components in HTML and script known as scriptlets. Scriptlets add object-oriented facilities to script and HTML, making them more viable solutions for developing user interface elements that can be reused across large Web sites.
Data binding is a fancy term for the process of linking the content of HTML elements with server-based databases and files, and the ability to cache the resulting data on the client computer. The ability to cache the data on the client makes it possible to dynamically manipulate the data without additional server hits. The link can be made in both directions, so data binding can be used to both display content on the client and update content on the server (the update can be tied to a submit button in an HTML form). Data binding is accomplished by an Internet Explorer 4.0 architecture that specifies how to build a data source object (DSO) on the client to provide scriptable functionality through a standard set of properties, methods, and events. Data fields from a DSO are linked to specific HTML elements through additional HTML attributes defined for Internet Explorer 4.0. DSOs can be linked to other data consumers as well, such as controls built using control technologies discussed above.
You can build your own DSO, or use any of several built-in DSOs that are shipped with Internet Explorer 4.0. For example, the Tabular Data Control (TDC) is used for accessing delimited text files (such the comma-delimited formats exported by Personal Information Manager [PIM] applications). ActiveX Data Objects (ADO) have been integrated with the Advanced Data Connector (ADC) DSO that shipped with Internet Explorer Preview 2. To evangelize this integration, the ADC technology has been formally renamed as the Remote Data Service (RDS) for ADO. ADO provides the API for making connections and queries to OLE-DB or ODBC-compliant databases (such as SQL Server, Microsoft Access or Oracle) that is utilized by the RDS to bind data from these databases to controls and elements on your Web page.
Dreams of the paperless office are rapidly becoming real with Web-based forms, some of which are sophisticated enough to be called "intranet applications." Creating libraries of forms on the Web increases worker productivity and reduces costs, thus increasing the return on a company's intranet investment. For example, on Microsoft's secure intranet I can log my vacation hours, order software from the company store, download Microsoft products, view my 401K options, and do everything else I used to rely on a group assistant or other administrative process to do for me.
Intranets are becoming such a big business that tools for generating Web-based forms are starting to hit the streets. These tools can be as simple as those that add HTML form layout features to existing Web-page creation tools to full-blown products that empower Web application developers to rapidly build fully interactive, dynamic Web sites, such as the Microsoft Visual InterDev development system. You can research these products in various journals for business and technology managers—for example, the September 8, 1997 issue of InformationWeek (http://www.informationweek.com/) reviewed two products for converting paper-based forms and developing Web-based forms for a company intranet.
As exhaustive as this overview might seem, it only scratches the surface of things you can do to get user input from a Web page. This is partly because good user input is one-tenth technology and nine-tenths creativity, and partly because it is just a huge area. For example, I didn't discuss personalization for Web pages at all.
Anyway, I think I have given you enough information to send you well on your way to becoming an expert in user-input technologies for Web pages. Make sure you're having fun while you're at it; otherwise, how can you expect your users to have fun?