Finally, you can define your own channel that you alone access. You specify a URL, a "link depth" (how far down the spider will scan to download pages, and the next time you do a synchronization, your channel gets downloaded. We used this feature heavily while developing, testing, and beta-testing our Mobile Edition technology.

Why we chose AvantGo
At ZATZ, we thought long and hard about what formats to support. In addition to AvantGo, there's the Palm VII's special Web clipping format for Palm device users. For Windows CE-based users, there's Microsoft's own Mobile Channel format.

We've decided, for now, not to support the Palm VII wireless service directly. Given the current pricing structure for data transmission offered by Palm.net, we felt strongly that we didn't want you to incur excessive download costs to retrieve our publications. Instead, you can download the latest updates to PalmPower at your next sync using the AvantGo client on your Palm VII. The PalmPower information will still be available to you, but you won't have incurred a considerable extra expense.

We've also decided, for now, not to support Microsoft's Mobile Channels. While the Mobile Channel technology seems excellent, it's not cross-platform. From a development perspective, Mobile Channels seemed much more work. When you're building an AvantGo channel, you're really just building an ultra-simple Web page. But when you're building a Mobile Channel, you need to build a special Channel Definition File, which adds considerable complexity.

Since we publish a magazines about Palm devices as well as Windows CE devices, we wanted to develop one mobile edition that could be used across all devices. Since the AvantGo technology did that, we decided to support it. Were the AvantGo service and client not available for free, we might have felt compelled to choose differently.

Generating mobile content
When we first started our online publishing business, we started to think about what we'd need to get the journals produced on time with our small staff. After just a small amount of time thinking about this, it became readily apparent that traditional page production tools such as Front Page would just not be up to the task. If we chose to use such a page production tool, the nightmare scenario of trying to find one missing tag among hundreds of thousands of lines of HTML at midnight before a journal was due would almost undoubtedly become a reality sooner rather than later. In other words, we needed to automate.

Now, honestly, we didn't want to build an automation tool. I was convinced that there ought to be something out there that would do the job for me. So I put a person on the project of locating something that would do what we needed - but we didn't find anything that would do the job. What we didn't find was a tool that suited an editorial focus. By degree, I'm a computer scientist and a programmer, but my staff is not. Our people have good writing skills, good editing skills, and good organizational skills - all fine characteristics of your typical editor. But they were just not programmers. We needed something that would let them be editors and not have to become programmers.