The second point is that "the document is the program": Many pages which one sees on the web are, once you have the proper mind-set, not so much documents, as applications. The reader can use the page, not just read it, to get actual work done. The web turns the whole document/program relationship on its head.
{{Tim: "small programs embedded in documents, rather than small documents embedded in programs."}}
{{Jon Udell, Byte: "Is an HTML form a document or an application? Well, it's both, and more. Think of it as an active document, or as a document-centric application."}} This all sounds way too vague. Concretely, the chapter shows how HTML "documents" can contain all sorts of widgets for the reader to interact with: so they're not really documents, but programs. And with <SCRIPT>, these documents can now literally contain code, and parts of the document can be generated on the fly. These very specific points need to be tied back into the more general points the chapter is trying to make.
(Funny article on content at http://www.upside.com/texis/features/companies?UID=9704011002a: Jeffrey Young, "You Call That Content," Upside, 19 March 1997)
Microsoft and content: http://www.wired.com/news/culture/story/3390.html on purchasing Ginsberg Howl, etc. "Buying MS Some Soul"
Content-based software: see http://www.news.com/SpecialFeatures/0,5,9312,00.html ("How content is still software in Redmond").
Cinemania excellent example!
MS Sidewalk: http://www.news.com/SpecialFeatures/0,5,9376,00.html
My SoftRAM page is an example of a weird new kind of document: it's definitely a document, something to read, but it also contains buttons, and forms, and hypertext links the pressing of which taps into processes on other machines. This is a document?!
Also my RegWiz and NTS/W papers gradually evolved from docs into apps
Yes, this is a document. But instead of a document being a static thing that requires a program to use it, the document now contains the program. A complete flip from old (Microsoft) way of doing things.
The content is the application, the document is the program. This sounds vague, but this chapter gives many concrete examples.
Problem with putting buttons and forms in your document: when reader (what once called "user") clicks on them, they go somewhere else, probably someone else's site. They can use "Back" button to return, but basically every link on your page is an invitation to the reader to go somewhere else and not return, or even forget how to return. You can control this somewhat with frames: keep your page as context for those other pages. But with all the wonderful power of the hypertext link, and partial control provided by frames, remember the problem too: every link to someone else's site is an invitation to the reader to abandon you.
Next step in fusion of document and application: scripts right inside document. This is JavaScript. Not Java at all: really an extension to HTML.
A lot of material in this chapter on JavaScript, especially on using JavaScript to generate HTML forms on the fly. Key point is to get reader to see that JavaScript is really just HTML.
Note that some of this has been possible for years with WinWord, thanks to wonderful WordBasic macro language. But Microsoft never seems to have quite understood how important this was, it was too tied to WinWord and to a single machine. Do discuss VBScript, VBA, etc. here, plus generalized <SCRIPT> engine: not just JavaScript. Can also put e.g. perl directly inside documents. "Why would you want to do that?" Chapter provides plenty of examples not just of how, but why.
Merger publishing, software development: http://www.infoworld.com/cgi-bin/displayStory.pl?970422.wspeech.htm. See also Tim's article on publishing model for web business, in chapter 1.