Washington Apple Pi Journal, reprint information
The Quark Publishing System (QPS) is group ware for publishers. It expands QuarkXPress (QXP) from a single-user layout application to a publishing workflow system. QPS succeeds by adding communications, coordination, and control features on top of individual productivity software. The Washingtonian magazine replaced a proprietary publishing system with QPS three years ago. As with other local publishers, such as the National Geographic Society, QPS quickly paid for itself. While QPS seems very expensive for a typical office, in publishing it replaces systems that can cost more per month to operate than the QPS purchase price.
I am the Systems Manager at The Washingtonian. While I have been working with QPS for only a year I have been aware of it for some time. The Washingtonian adopted it over three years ago and is very satisfied with it. QPS introduced major changes in the magazine's operations, most for the better.
QPS has distinct components that communicate with each other. They are a specialized word processor, a QuarkXPress XTension, a system extension that integrates other applications with QPS, a server that tracks all publication files, and publication and system management tools.
This review is based on QPS 1.12, though version 2 might be available by the time it is published. Quark promises major improvements in version 2 -- including support for QuarkXPress 4 -- but The Washingtonian will not upgrade to version 2 until it has proven stable. QPS 2 was supposed to follow QXP 4 by three to six months. We will wait another six months before upgrading.
The QuarkDispatch application controls the QuarkDispatch database, the central component of a Quark Publishing System. -- QPS Manual.
The
QuarkDispatch Server (QDS) tracks three types of files: articles,
pictures, and layouts. Articles are usually QuarkCopyDesk
files -- though QPS also supports Microsoft WORD and text
files -- and never contain graphics. Pictures are any type of graphic
that can be placed in a QuarkXPress document. Layouts are
QuarkXPress files. QDS has information about each file and the
linkages between files.
Users check files in and out through the QDS, even though the files reside on a separate file server. The server knows which files are checked out, who has them, what revisions exist, etc. Users communicate with the server through a QuarkDispatch menu. QPS applications come with a QuarkDispatch menu and Quark provides plug-ins and extensions to add this menu to other applications.
The server is amazing simple to maintain. Turn it on and restart it if it crashes. Because there are no traditional database files, there are no concerns about database corruption. I run the server on a PowerMac 8100 under Mac OS8 and have run it under System 7.5. Quark recommends System 7.5.1 or higher. Although the server software is not PowerPC native, it runs quickly and has not been a workflow bottleneck.
Rather than storing data in a single database file, QDS stores all data in the resource forks of the article, picture, and layout files. When the QDS is launched, it scans the directories in which the publication files are stored and reads their resource forks. This data, in conjunction with a settings file created by QuarkDispatch Administrator, is used to create the QDS database. This database exists in the server's RAM. The amount of RAM recommended will depend on the size and number of publications QDS is servicing.
The QDS screen has moving blips to show that the server is active (see figure 1). Other important indicators include load, memory usage, and user connections. The only action that can be taken at the server once it is running is to shut it down. The server can be password protected to limit shutdown to authorized staff, though there is nothing to prevent anyone from unplugging the server.
Figure 1 - QuarkDispatch Server
For additional protection, I have a PowerKey Pro 200 with the automatic reboot option on the QDS. If the server should freeze or bomb, it will automatically restart. Because there is no danger of its database being damaged from a crash, the server can quickly come back online. When the server is out of commission, users are unable to check files in or out of QPS. However, they can continue working on any files they have checked out. In case of a server crash the only action a user needs to take is to check back onto the QuarkDispatch Server. They do not have to restart their computer or even the application they are using.
While the actual data files sit on a file server, they are not easily accessible except through QPS. Each file name is a code, with the real name hidden in its resource fork. If someone could even see the data files, they would not know which is which. In addition, the file server should be set up to make the data file folders invisible. This prevents user tampering while allowing access to the files via QPS.
QPS version 1.x is limited to AppleTalk. Version 2 will support more protocols, possibly including TCP/IP. The addition of additional protocols is necessary to provide better Windows support. Whereas QuarkCopyDesk does exist for Windows, QPS is a mostly-Mac product. Once version 2 for the Macintosh is released, a Windows 95/NT counterpart will be introduced for every component. This means that QPS will eventually be available for all Windows offices. This effort will take approximately three to six months after the release of the Macintosh components.
QDS is copy protected through an EvE dongle. This dongle also contains the number of connections are allowed for the server. Moving the server to another computer merely involves copying the QDS software and moving the dongle.
The QuarkDispatch Administrator application enables you to create a configuration file for your Quark Publishing system that contains a number of systemwide defaults. -- QPS Manual
QuarkDispatch
Administrator (QDA) is used to configure QuarkDispatch
Server settings. It can be run on any Macintosh on the network.
It manipulates a file on the file server that is read by the
QuarkDispatch Server when it launches. QPS will not accept any
configuration changes, such as new user accounts, until the QDS is
restarted. This can be an annoyance because this makes it almost
impossible to make administrative changes during the day. Quark is
promising that version 2 will allow for more administrative work
without server rebooting.
QDA is an example of simple mechanics resulting in a complex system. A single QDS can handle multiple publications, each divided into multiple sections. At The Washingtonian, we handle a single publication and only one issue at a time. Other publishers use QPS to handle both multiple publications and work on two to three issues of a single publication at once.
Figure 2 shows how QPS restricts user access to files. Each section has a list of users who may and may not access a section's files. In addition, each user is assigned to a user class, which has additional security restrictions. Each user is assigned to a class when his or her account is created. This class can be changed for any specific section, see figure 3. Each class has specific settings about what its users may and may not do, and all classes are defined by the administrator. QPS does not assume a publication works in any particular way, almost all definitions are created by the publication itself.
Figure 2 - Sections and User Access
Figure 3 - Setting User Class for a Section
Defining user classes is the heart of the security system. QDA can set up as many user classes as he or she wishes. Access is defined for each QPS application. In figure 4 a copy editor cannot run QuarkDispatch Planner but can use QuarkXPress. In this example, a copy editor has complete control over QuarkXPress, but has been limited to editing only existing stories and prohibited from making any layout changes.
Figure 4 - User Class "Copy Editor"
Security is dynamic and changes according to a file's status. Like user classes, status is defined by the administrator. Figure 5 shows the status settings for The Washingtonian. In addition, the security settings for any user class can be redefined according to its status. For example, once an article is "Ready for Copy Edit," writers can be locked out from making any changes.
Figure 5 - Publication Statuses
Header fields hold information about each file. This information is stored in the QDS database in every file's resource fork. Header fields are defined in QDA (see figure 6). The grayed-out fields are pre-defined by Quark, but all other fields are defined by the administrator. QPS provides fill-in fields, pop-up menu fields, and check boxes.
Figure 6 - Section Header Definition
Publication preferences are stored in QPS. Preferences are set by importing an XPress Preferences file. Preferences include style sheets, colors, and hyphenation and justification rules. To avoid overwhelming writers and artists with too many style sheets, the administrator then assigns specific style sheets to each section.
Figure 7 - Publication Preferences
Revision control is set in QDA. QPS users can always call up older versions of any file. To avoid overwhelming the file server with too many versions, the QPS administrator defines the rules for retaining old versions based on number of revisions and file age. Articles, layouts, and pictures have separate revision settings. You can define the number of oldest and most recent revisions to keep, and old versions can be set to automatically be deleted after a set number of days.
Figure 8 - Revisions
Return to electric pi
Revised March 15, 1998 pjc/lic
Washington Apple Pi
URL: http://www.wap.org/journal/