Watch This!
Wednesday, May 15, 1996 by Dave Winer.
Goood Afternoon!
Writing docs is like introducing your son or daughter to their future wife or husband. A parent shouldn't do that. It can come out all wrong.
So. I've been in doc-writing mode. Oy! Doc writing is more fun nowadays, with the web as the medium instead of paper and plain text files (no links!). Software guys like to write software, not *about* software. But a website is more like software, so it's more fun for software writers like me.
Doc writing puts me in a different mood. I want to explain things. In great detail! Hmmm. That works for software docs, but it doesn't work for DaveNet, where I skim over details, leave out a lot of facts, leave a lot of puns in, and just let my ideas reverberate around, without the benefit of complete logical arguments behind them.
I've always wanted a chance to present a software product exactly as I see it, without having to teach anyone how to use it. To connect the dots in DaveNet style, leaving out detail -- telling you how I conceived the software, not how I want you to perceive it. Instead of manipulating you into becoming a user, I'd like a chance to explain why I find it beautiful.
Watch this! 
While I'm writing a piece of software, lots of times the phrase 'Watch this!' pops into my head, totally spontaneously. It comes just before I click on the Run button for a script that releases a new version. Or when I flip a switch and an outline becomes a beautiful web page. I can't wait for people to see the feature. Watch this! my spirit says.
If I use a software product, I like to read the words of the author of the product. Peter Lewis is a funny guy! Chuck Shotton is a salesman. Rich Siegel is a shortstop. I'd like to have coffee with Aretha Franklin someday, but it may never happen. But I do know some excellent developers. Some write software for Windows and Unix. They may copy my ideas. So what? It's respect! And that's always cooool.
I'm also a web developer. I've done some cool sites. So I want to share my design with other web developers. Maybe they work on Windows or Unix? With this spec, they know what to ask for from the people who do Perl implementations or Visual Basic add-ons.
I like sharing my ideas with my peers. So this piece is written for the people who develop software and sites. Everyone else is welcome to read it too.
How Frontier 4.0 came about
I've always wanted to build websites entirely within the Frontier environment. I felt that the hierarchic nature of Frontier, and the tools it offers -- its outliner, structured tables, data storage and text storage, it's scripting engine, it's connections -- would be a good match for the worldwide web.
It was a puzzle, an elusive solution. I iterated a bunch of times. First there was AutoWeb, which used the Finder to outline a website. Then Clay Basket which was, itself, an outliner. It got easier, but as Clay grew it got harder.
I experimented with content -- DaveNet via email, then DaveNet via the web. I wrote a BBS that ran on the web. I made Frontier's database browsable thru the web. Then I did the 24 Hours project, which turned all my lightbulbs on! Now, finally, I'm doing my website development entirely within Frontier. Davey likes it.
I had initially hoped to create something that would be totally end-user, not just for script-oriented people. Like a lot of developers who played around with this stuff last year, I discovered that website management is inherently a scripted thing; especially if you're doing a large site that's dynamic. If you're doing a small site, three or four pages, use PageMill; it works great for smaller sites. But if you're doing a larger site, we can do some stuff to make it work better.
***Here's the scenario
A webmaster at a large university. Her public relations department insists on a standard look for pages, but they haven't decided what the look will be. The site presents the school's course schedule. A database of events that roll thru a home page. Sub-sites for each faculty member, written by the faculty member. Departmental home pages.
That's the market I'm entering, and hope to define. Large sites that are dynamic with lots of authors. A standardized look that's easy to change. Everyone uses their favorite text tools. The sysop has full control over the look and flow of the site. All the links are correct without employing a small army of link checkers.
There are six key features that make this system work: rendering, glossaries, templates, macros, an object hierarchy and connections to standard tools. Each of them is a separate story, and they connect with each other. Here goes!
Rendering
A key new concept: pages are rendered. There's a difference between the text you edit and the HTML text that the system spits out. This presents a problem: where do you put the originals and where do you put rendered text? Every website management tool has this problem. Our solution: the source text resides in Frontier, and the rendered text resides on the website.
Text can flow into Frontier from any number of sources: databases, text editors, page layout programs, photo editing programs. It's fully programmable so you can make text move into Frontier anyway you like. And we have a complement of competent editors so you can do a lot of editing entirely within the environment.
We connect to the website either thru FTP or thru the file system. Since the Mac file system is LAN-aware, this means that you can set it up so your rendered text automatically goes to the right folder on the server if you serve from a machine that's on your LAN. The connection thru FTP is almost as convenient.
To preview a page, a very necessary feature, we create a temporary file nested deep in the System Folder. You can't test the links in this environment, but you can iterate over the layout and appearance of the page before moving it to the website.
Glossaries
Glossaries make link management work. A glossary is a simple lookup table. Each item has a name and a text value. When a page is rendered, any text inside "double-quotes" passes thru the glossary. If the term is defined, its associated text is substituted.
The glossary is an elegant approach to the problem that link validator software attempts to solve. By concentrating most or all of your links in the glossary, you can make a change in one place, rebuild your pages, and all your links are cool. A glossary gives you the power to correct URLs in one place.
It's easy to add URLs to the glossary by choosing a menu item from Netscape Navigator or Microsoft Internet Explorer.
Some people have objected to the use of double-quotes, saying it interferes with a writer's process. But I'm a writer, and I love it! I've never heard a prose writer complain about this, just script writers. If you quote something that isn't in the glossary, the renderer leaves it alone. Sometimes it enables text that I wasn't expecting it to. I usually chuckle, and then put a backslash before the double-quote, which turns rendering off for the term. But often it surprises me by doing exactly the right thing. I laugh even louder when this happens!
Templates
A template defines the wrapper for each web page. It says what text surrounds the body of the page. This makes it easy to define a standard look for pages, and then change the definition later. To make a change, you change the template, and rebuild the site.
Templates also make it easy to factor out overhead tags in HTML text, things like <body>, <head>, <title>. Editors and writers will probably appreciate this. But it's up to the sysop to determine how much or how little of the look of a page is controlled by the rendering process.
I learned a lot about templates in MORE. The Library feature in MORE is a one-time-only approach to standardization. The new approach in Frontier 4.0 recalculates the text each time the page is rendered. It's much closer to what I want. Maybe it's everything that I want. We'll see.
Macros
As long as we're passing text thru a page renderer, why not allow the full power of the scripting environment and all its connections to show thru? Exactly!
Macros allow you to include little scripts in your HTML text. The renderer evaluates the scripts and replaces them with the text they return. A macro is any text enclosed in {curly braces}. As with glossary terms, you can escape this function by preceding a { with a \.
Macros give the sysop control of complicated pieces of HTML that must appear inside the document, or might change every time the page is rendered. All professionally-run sites need macros. Some web authoring systems running on Unix already have them. I know this for sure, this is the most powerful macro facility for web development on the Macintosh.
Hierarchy
Hierarchy is the opposite of anarchy, but sometimes it doesn't feel that way! Hierarchy is a very religious concept. I'm getting ready for some debates on this subject. Interesting ones!
Late in the development process for Frontier 4.0, I noticed that glossaries could be hierarchic; that a table could contain a glossary that overrides the definitions in any higher-level table. When I started using this, I realized that I now have an object-oriented website! Oh man that was fun. Object oriented is a powerful way to do websites. It gives everything a place. That one change in thinking made the design glitches disappear.
Websites really become software. Eventually everything in the Frontier web scripting environment will work with hierarchic overrides. To explain this fully would require a tutorial on website building. Watch the website. The story is still developing.
I don't think they have anything like this on Windows or Unix.
Standard Tools
Let's move from the sublime to the concrete.
I've said this over and over in DaveNets, the Mac OS has an advantage over other platforms because it has mature interapplication protocols that are supported by the Internet clients, content tools and servers. From browsers to email clients and databases, to web servers and FTP servers, (almost!) everything is scriptable, so text, pictures and data can move from where it exists to the place you want it. That's how the Internet works, and that's how it works inside our machines too.
Windows may have interapplication protocols, but the apps don't have the scripting religion yet. On the Mac, the technology is mature and supported in System 7. Nothing to wait for. It's available now.
Even better -- category-based standards have emerged, not by edict as Apple bet they would -- they happened thru market power and leadership, as it always works in the software world.
An example. Microsoft emulates the scripting interface defined by Netscape, so much so that you can change Netscape.id to 'MSIE' and the scripts work!
Microsoft has this strategy down. Embrace and extend! You can call MSIE a "Netscape-compatible" browser. Where do we go from here? Microsoft gets a say in that, because they did the right thing, and preserved the investment that script writers have already made in Netscape. They showed us respect, and they have earned our respect in return.
I asked Marc Andreessen, the founder of Netscape, what he thought about this. He said "We think it's really great that Microsoft has chosen to emulate our Mac Navigator scripting interface, as it provides a clear path for developers to take. Anything that inspires developers to do great stuff is good for Netscape, and standards as always are key." So Netscape gets the respect of Macintosh script writers too. Thanks Marc!
So, I followed Microsoft's example and embraced and extended AppleScript. It was fun! That's fully discussed on the Frontier website. It's how you lead a market. Welcome AppleScript, we say. It's a standard. Coool. Now where do we go from here? Frontier has a lot to say about that.
Politics
I promised to write my own version of the Internet strategy for the Mac platform. I still want to do it. But not this weekend. I'll be attending Apple's press conference tomorrow. I will listen and possibly ask questions. Believe it or not I have a meeting with Gil Amelio tomorrow. I'll let you know how it goes.
At Apple, they have just a clue that something interesting is happening over here. But they're still focused over there. I think that will change! They have a new religion at Apple, they say. Developers count. Cooool. But even if they aren't being totally truthful, there's a way to make all this stuff happen without Apple's support.
Remember, they licensed the OS to Motorola and IBM, who in turn can license it to other manufacturers. If Apple doesn't want to promote the most powerful tools on the Mac platform, in favor of their own tools, so be it. I'm betting that we can find partners for this software. But, if we could get Apple to sing our song, just a little bit, we could make some growth happen here.
And even if that doesn't happen -- I do software for sport. Like a professional golfer or tennis player. I like to come up with new strokes! So my mission is already accomplished, even if the Mac platform should die, as some people say it surely will. That's the wild card that other writers aren't taking into account. They think all software developers are motivated by money and market share. My claim -- only the ones that make boring software. If you love to make software, you make it happen where ever it can happen.
If you doubt me, check out the worldwide web, which was created on the Next platform in the early nineties. A truly dead platform that turned the world upside down! Yeah, if you think it's about market share, you haven't been paying attention.
Still digging!
Dave Winer
PS: Frontier 4.0 is free. Let's have fun!
PPS: Qualification: Adobe PhotoShop is not scriptable. It would be great if it were.