A  DesertNet initially began development because alternative newsweeklies needed an efficient print-to-web application for their editorial content. But we wanted to do more than just rebuild print publications on the web. We wanted to expand design possibilities. We wanted to leverage all of a newspaper's archived content in creative ways. We wanted the software to run in a browser on any platform, from anywhere. We especially wanted to make something that designers or editors could put together without dependence on programmers or webmasters.

Dispatch Publisher was created to fill all those needs, and became much more in the process. During Publisher's development we saw the potential to enrich an online newspaper experience by fully integrating editorial, listings, guides, community, classifieds, personals and more. This was the genesis of our development environment, which uses radical new technology in database design, something we are currently in the process of getting a patent for. We call this environment Gyrobase, and it's the foundation for the applications we're calling the Dispatch Suite.

Q  Can you elaborate on how Dispatch differs from other content-management software?

A  Most content-management software comes in two flavors: hard wired and cheap, or in the form of a development toolbox and expensive. Hardwired programs are usually built for one client and sold to others who have to adapt to its rules. Development toolboxes are packages of the languages and tools needed to build an application, combined with the time and cost of extensively trained programmers and database administrators who know how to use them to custom-develop the client's application.

What we've developed is somewhere in the middle. I call it loose wired. We customize a basic structure for each client, but then provide the means for them to change it and add new features themselves without having to add to their overhead with programmers and other tech-oriented employees. In fact, one of our primary goals is to reduce the labor costs associated with online publishing.

Q  So Dispatch Publisher is customizable?

A  Entirely. We didn't want the software to dictate a preconceived structure for our clients an approach that severely limits what the user can do. We built a loose wired system that provides some structure in the sense of workflow and work methodologies, but we also allow the user total freedom to get creative and customize it to their specific vocabulary and the work requirements of their own publication. We call this our user defined field system (UDFs).

Q  Please elaborate on the user defined field system (UDFs).

A  We knew up front that every story would have a headline, and that every story could have a deck or subhead, most would have an author or authors, a summary, the story itself, images, artist credits, etc. But we couldn't predict what additional meta information a publication might want to catalog with a story, such as film title, film genre, director, actors, music artist, record label, arts medium, political category, etc. Even if we attempted to predict all of these fields, we didn't want to lock them down to a specific naming convention or specific possible values. All of this is a matter of opinion and highly subjective.

This is where UDFs come in. They allow a publication to create their own fields by providing a field name, then choosing what field type they want it to be, such as text, text area, checkbox, radio buttons, selects (drop-down menus), etc. They can also make additional decisions, such as what possible values it can contain, if it can be expandable from the interface or not, such as adding new values to a checkbox. Then they decide which stories within their database should have these fields, what sequence the fields should be in, and they can even set default values a UDF should have on a story by story basis. It's an extremely flexible system, and I'm happy to say that the Dispatch Suite expands upon this concept even further.

The Dispatch Suite enhances UDFs by adding a whole new set of options. A few highlights include new visual features, such as defining the width, height and if you want word wrap or not. Scalability features, such as pop up chooser windows as opposed to unmanageable selects with hundreds of elements (say, for example, the large number of bands in major market). Data integrity features, such as field normalization, field locking, if a field should be required, if it should be unique or if it can have multiple values. Plus some other bells and whistles like word counters, fills and the ability to create your own validation clauses. It's really quite awesome.

Q  Why bother with UDFs?

A  Most content management systems are simple minded; they catalog content and display content, and that's about it. Dispatch obviously does that as well, but with a lot more finesse, grace, and focus on the value of archived content. By providing additional meta information about stories using our UDF system, you can educate Dispatch about each story to its fullest potential. By doing this, you can foster the dynamic relationships among content in whatever way fits your design concepts.

For example, when reading a film review, Dispatch can provide links to other recent reviews in that genre or genres, more stories by this reviewer, other recent film reviews, more film reviews featuring these actors or directors, more film reviews of a similar rating, links to external sites such as the Internet Movie Database, or even ecommerce links directly to Amazon to purchase the video, or NetFlix to rent it. The Dispatch Suite builds upon this by also providing film times adjacent to the review, or even film-related classifieds, should you have them.

The bottom line is that alternative newsweeklies write about many things that have infinite shelf life, such as books, music, and film. In addition they write about important political and community issues that also have immense value in an archived system. Dispatch allows you to fully experience that value by leveraging all content, be it new or archived. This not only expands the breadth of your publication, but it also significantly increases your site traffic, user visit duration, and the inherent value of all of your content.

Q  I've read in your literature that Dispatch's QuarkXPress converter is state of the art. What do you mean by this?

A  First off, Dispatch Publisher works in a batch mode, which means Publisher processes all of an issue's stories in one sweep. This is an important issue, as many other systems work on a one to one relationship, significantly increasing the workload for the end-user. We take care of it all at once.

The first few times you use it are most intense, since that's when you create Dispatch's memory. The parser first analyzes each story down to the character level. If Publisher discovers a new non-ASCII character (such as umlauts and ellipses), it asks what you'd like to convert it to. You can convert it to any text string, be it an HTML-encoded entity for accented characters, or even an image for a dingbat-style character. If a new font is detected, you'll be given the opportunity to set wrappers for the font, such as bold or italic or even cascading style sheet information. If a new Quark style is detected, you'll be asked if you would like to provide any special treatment for it, or if it should be associated with a database field. For example, flag a style to be associated with a headline or byline field. This is a major time saver.

Once you educate Dispatch about a character, font or style, it never asks you about it again. So each time you import stories in the future, Dispatch will automatically convert, stylize, and pre-fill database fields for you. The more you teach Dispatch and the more consistent your desktop publishing is, the more automated your experience becomes. We have some publications experiencing over 90 percent automation, in which their stories are converted and every database field automatically filled.

It's also worth pointing out that since Dispatch learns as it goes, you never need to be concerned about the impact of a print redesign in conjunction with the software experience. For example, if you redesigned your print version, you probably are using new fonts and styles. When Dispatch sees these, it will simply ask to be educated on anything new and will move along. Everything is quite simple and all from the comfort of a well-designed GUI interface within your web browser of choice.

Q  How flexible are the design templates?

A  Our templating system has full design freedom, and that is one of the most important things that the software can do from our perspective. We wanted to be able to say you can do anything, make any design you want, as silly or as smart as it is you can do it. And you don't need to be a programmer to do it; you just need to use your imagination. We had to come up with a tag language simple enough to do this, and what we've come up with are tags that you can put together in three or four lines to create what would normally require pages and pages of technical code.

Q  Why use tags?

A  We don't want our clients to be limited by hard templates, or dependent on us to make changes for them. But we also don't expect them to be programmers, or even webmasters. The tags are easy to learn, a lot like HTML, and they're written by and for designers.

The tag language is simple and has been a success in providing creative control to the same people who create the print newspaper. We find that it's designers, art directors, editors and non-techies that are using Publisher. Clients actually have less trouble learning the tags than they do with getting used to the freedom that designing in a dynamic environment provides.

Q  What else can the Dispatch Suite do?

A  An easier question to answer is: what can't it do? We used to have a challenge we'd ask potential clients: to come up with a design that the tag language couldn't satisfy. We knew the tag language could pretty much do anything, and if the client came up with something it couldn't do, we'd enhance the tags so it could satisfy that need. It was a great win/win challenge and expanded the product quite nicely. I would assume our new challenge would be to come up with something the Gyrobase engine can't do. Again, we know it can pretty much do anything, and if our clients come up with ideas we haven't satisfied, it will be win/win again, because we'll be able to expand everything as needed. It's nice having this feeling of confidence behind our system designs.

Q  Is there anything you can compare the Suite with?

A  From our perspective, we're providing all the important features of six figure, high-end packages like Vignette StoryServer for a much lower cost. On top of that we roll in new features and flexibilities that substantially surpass these packages. Add to that the fact that everything runs within the browser, full GUI control of your data, database fields, and design.

Q  How searchable are sites produced with the Dispatch Suite?

A  Simply put, you can search on anything and everything within the highly fielded database. For example, what book signing events are going on today between noon and 3pm, what films are playing tonight on the east side of town and what sushi restaurants are near these theaters, or what's happening this Friday between 9pm and 11pm for under $5. Those are just a few examples. The meta database (Gyrobase) was designed specifically for searching and querying by both the designer and the reader.

Q  As you add features, how does the user get upgraded?

A  Our software is upgraded across the Internet. Since we started in 1996, DesertNet software has always used an ASP model, as in Application Service Provider software. (Not to be confused with lower case .asp, Microsoft's Active Server Pages.) Our software has always been accessible from any web browser, on any operating system, anywhere. You never need to download or install anything, and likewise, never have to worry about upgrades that happens automatically in the background. Whenever a client is using the software, it is the latest version.

When our testing is done and we're ready to upgrade any basic feature or function, we kick off a program that securely connects to each Dispatch server and upgrades all the pertinent code. Due to this process, every Dispatch server is upgraded simultaneously, avoiding any and all versioning problems. There's no need for the client to do anything different, or even be aware of this upgrade. The next time the client logs in there are just some new magical features. We outline these updates is the Dispatch user group mailing lists. This happens monthly right now, and upgrades consist primarily of new features conceived by us or requested by our clients.

Q  You've mentioned speed and caching in the past. Can you elaborate on those topics?

A  Our software encourages highly complex queries since we encourage users to leverage their content to the fullest potential. In fact, we've seen pages with over 25 queries on them. To handle this load, we've devised a sophisticated and flexible caching system.

By default every query gets cached. This includes caching the rows that the database returns, as well as the resulting layouts. Caching is handled at a component level so multiple pages with identical queries can all benefit from the same cache. You may also group components for additional speed gains. Our component caching system provides speed gains as close to flat files as you can get.

Q  Will the DispatchSuite support wireless needs?

A  Sure, right out of the box. Our templating system can dynamically serve anything ASCII, be it HTML, XTG, XML, or WML. If I was to sum up everything we've discussed today in a few words, they'd be integration, flexibility, and dynamic.