Printing in the future: What are the alternatives?
A paperless office might be an impossibility, but here are some 'printing' solutions that don't involve printing at all
February 1999
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
Printing in the future: What are the alternatives?A paperless office might be an impossibility, but here are some 'printing' solutions that don't involve printing at all
|
February 1999
|
In Chuck's feature article last month, he compared Unix printing and mainframe printing, with the general consensus being that Unix falls far short of its mainframe counterpart. Even with appropriate tools, the Unix printing experience isn't what mainframe users have come to expect.This month, Chuck takes a different approach to printing. By looking at this feature in a new light, you'll find that you can deliver powerful Unix "printing" solutions without wasting all that paper. (2,800 words)
 Mail this article to a friend |
o understand how printing will evolve, it helps to think about how
printing has evolved. When widespread use of mainframe computers
became common, a tremendous amount of output suddenly had to be delivered
to users. With no network infrastructure in place to carry the
data, the only alternative was to use 500-year-old technology: ink
on paper. As more and more reports were generated from mainframe
systems, larger and more elaborate printing systems were installed
to handle the load.
These printing systems have established the level of service users now expect from their Unix systems. Reprinting reports, selectively printing certain pages, and routing output to different recipients are all features that became part of the mainframe print experience over time. Unfortunately, the real reason for printing is being masked by all these nice features: the real reason we print is not to generate stacks of paper, it's to deliver information to users.
Needless to say, there are far better ways to get data in front of users than to put ink on paper and carry it to them. With the advent of networking and the Web, it's much easier to deliver information electronically than manually. More importantly, most users prefer to get their data this way. Searching a report for a single-line item is much easier in a browser window than flipping through a stack of greenbar. Sharing a report with colleagues is trivial via e-mail, but it's a copying nightmare when you have to reproduce a stack of ledger-size sheets.
As you design your future systems, it's important that as you say "printing," you think "information delivery." Your job is to build systems that store and correlate information, and to deliver that information to the right person at the right time as cheaply as possible. While there is no doubt that traditional printing will never go away, you can significantly reduce the amount of real printing you do by relying on newer technology to carry its share of the burden.
Moving to the Web
I doubt I'm imparting much wisdom when I tell you that you need
to use the Web to deliver information to your customers. The
pervasive use of the Web for everything makes it a perfect tool for
delivering data from your systems to your users.
However, it isn't enough to just convert all of your traditional reports to HTML and drop them onto a Web server. Three years ago, this simple act would've had you hailed as a hero among your users. Having never experienced online data delivery, users were happy -- and impressed -- to see their traditional reports in a browser window. In fact, many users were so tied to traditional usage models that they immediately printed such reports so they could read them in the manner to which they had become accustomed.
Today, users have become far more sophisticated, and their expectations of Web solutions have expanded accordingly. To meet those expectations, you need to deploy solid Web solutions that integrate your data into useful tools, going beyond traditional reports into hyperlinked documents.
While every printing solution is unique, there are a few rules of thumb you'll need to follow when implementing a print-to-Web solution:
Information should always be cross-linked
If data isn't hyperlinked, it isn't ready for the Web. Static
reports that don't connect to related data sources are effectively
useless. Make sure the data elements in your Web-based output
serve as hyperlinks to other reports: supporting data, summary data,
glossaries, annual reports, competitor's information, etc. Users
used to keep stacks of reports in their offices for just this
reason, hand-correlating reports as data relationships became
apparent. Save them the trouble by anticipating their needs and
providing the hyperlinks for them.
Use progressive disclosure
Volumes of data are difficult to manage. Although receiving a huge
stack of output is never fun, at least you can deal with it one page
at a time. Don't dump huge reports into a single Web page and shoot
it out to your Web site. Create hierarchical reports that permit
users to drill down into more detailed information. If your links
are built correctly, users can quickly find just what they need,
without having to wade through tons of things in which they have no
interest. As a side benefit, you reduce overall network bandwidth
because you don't transmit any information until a user needs it.
Provide good security models
Mainframe printing has a good security model: the only people who
see sensitive data are those who receive the report. Really
sensitive stuff is locked away in cabinets, safe from prying eyes.
Electronic data must be similarly secure, and you'll need to provide
some sort of user authentication scheme that restricts access to
data as required by your organization. At the very least,
implementing some sort of account and password scheme to gain access
to your Web report servers is a good start.
Aggregate data from different sources
If you generated a lot of related reports from different systems in
the past, you cannot simply take all those reports and dump them on
a server. To really provide value to your customers, you'll need to
aggregate those reports into a single data product that meets your
users' needs. For example, if sales data is extracted from one
server, while manufacturing inventories are handled by another,
you'll need to create a single data product that relates sales
information with manufacturing backlog without forcing your users to
know that two different systems are actually handling the data
behind the scenes. Users don't care how you get the data to them,
they just want the data.
Make access ubiquitous
If possible, allow users to access your report servers regardless of
their physical location. This may mean using additional security
tools to allow connections from the Internet to these servers.
While the effort may be significant to secure these servers, remote
users and traveling users will benefit from being able to see their
data anytime, anywhere.
Non-Web delivery services
Not every system is geared to broadcast data to users via Web
servers. Fortunately, there are equally deployable tools that
are almost as effective.
One of the best ways to send reports around is via plain old e-mail. The beauty of e-mail is that you can target specific recipients, users can receive reports as soon as they are available, and e-mail integration with existing printing systems is relatively simple.
As an example, my company uses a financial system that generates custom reports for each operating division at the close of each month. These reports are formatted for use with a viewer tool that was provided by the vendor. As the reports are generated, they are e-mailed to each division VP for review. They arrive as e-mail attachments, and double-clicking the attachment launches the viewing tool. Once in the tool, users can drill down to single-line items, print reports, and examine the data to their heart's content.
Unlike the Web, e-mail data delivery is push technology: data is pushed to users as soon as it becomes available. With the Web, data is pushed to the servers, where users pull it as needed. In many shops, users demand notification of data delivery so they know when to visit the Web site, resulting in a strange delivery combination: data goes to the server as e-mail goes to the users, telling them their data is ready to be viewed. In many cases, it's easier to just include the data in the notification message.
E-mail integration can also be easier on developers. With heterogeneous print spooling that can route a print job from a mainframe system to a Unix server, the print system on the Unix side can take the print job and convert it to e-mail instead. Mainframe programmers are unaware of the change, and continue to "print" to the same devices they always have. Users simply begin receiving reports via e-mail instead of paper.
Of course, e-mail data delivery doesn't have any sort of Web integration, and can't provide many of the benefits we outlined in the previous section. Even so, it can be a welcome change from traditional paper reporting and often serves as the first step in building a more complete electronic information distribution system.
|
|
|
|
|
Shifting to dynamic data generation
With the advent of pervasive networking and fatter clients on users'
desktops, another data delivery technique avoids the traditional
report altogether. In this mode, nothing is generated until the
user needs to answer a question. At that point, dynamic queries
find, format, and deliver the data to the user.
From the user's perspective, this is a wonderful solution. Instead of wading through endless reports, either paper or electronic, users post the questions they want answered. The system worries about the details, from parsing the query to locating the data to delivering the result. If a query proves useful, users can save it away, recalling it at a future date to be used again. In this way, each user builds a custom set of reporting tools to be used whenever he or she likes.
From the system's perspective, this idea is fraught with disaster. First, you'll need a powerful tool to accept user queries, parse them into SQL or a similar language, and present the queries to the appropriate databases. When the results come back, the tool then needs to create some sort of attractive presentation for the user. While a number of these tools have existed for years, the advent of pervasive networks and the Web is making them even more attractive. Products like MicroStrategy's DSS Suite offer complete solutions that handle the back-end databases, the query synthesis, and the user interface, including Web interfaces to your databases.
If you've delivered on the tool front, you'll also need to come through with beefy servers and fast networks that allow your databases to communicate with each other and your end users. While these kind of query systems are tremendously useful, they're not computational lightweights, and you'll need to build the right infrastructure to deliver this kind of solution.
If you can bring it all together, this kind of data delivery environment can yield huge benefits. Since the integration tools can deal with your databases and systems at a more generic level, users can connect data across systems in ways you might not have anticipated. Most importantly, they can do it without any help from your programming staff.
Integration with PC print services
It might be difficult for Unix folks to even think it, but print
services on the PC side of your shop are probably far better than
what you have on the Unix side. While PC servers, both Windows NT
and Novell, are nowhere near ready to run as production database or
application servers, they are very good at providing print services
to hundreds of attached clients.
Instead of killing yourself trying to build print services into your Unix systems, especially with respect to print job management, you may want to simply route your print jobs to your nearest PC server. Luckily, almost every system in the world can be made to speak Unix's lpd print protocol. By defining your Unix printers as remote printers on a PC server, you move all your printing problems to a different environment that can better handle them. In particular, your PC servers can drive hundreds of different printers, deliver queue monitoring tools to any PC desktop, and allow users to print to the printer nearest them, as well as choose specialty printers for color or different media.
The other advantage to PC print management is that PC servers are cheap. Instead of building your print infrastructure using more expensive, higher performance Unix systems, you can deploy any number of cheap PC servers, each managing a cluster of printers. You build redundancy this way, too, so when NT crashes every 48 hours, the impact on your user base is less severe.
Which to use?
First and foremost, don't think that any one of these solutions is
going to solve all of your data distribution needs. To effectively
support your users in a variety of configurations, you'll need to
implement one or more of these solutions.
At the very least, you will need to be able to route print jobs to PC-based printers. Users are accustomed to getting their output at the nearest network printer attached to their LAN, and they will want their mainframe and Unix output to arrive there as well. Bite the bullet and shift the print burden to the PC side. Everyone will be happier.
With a growing desire to distribute data faster, you may find yourself feeding an insatiable appetite from your user community. It's common to see shops begin dabbling in electronic data distribution by using e-mail to route traditional reports in electronic form. As the user community gets a grip on this technology, they begin to pine for fancier output and easier access. This will lead you to Web-based solutions, forcing you to address data conversion issues and heterogeneous access to the Web from all your systems.
While the Web solution will meet many of your users' needs, it will eventually lead them to think about dynamic access to their data, leading you away from static data delivery and into the realm of realtime query engines. In the short term, you may be able to meet the need with Web-based query interfaces, but your programming staff may soon become overwhelmed by user demand for custom reports. That's when you'll turn to formal decision support tools that can abstract the query process from users while providing a higher level of automation for your staff.
Regrettably, none of these solutions completely replaces its predecessors, so you'll wind up supporting all of them at some time. If you plan for these solutions now, you may find it easier to deploy new solutions in the future.
Finally, keep in mind that ink-on-paper printing will never go
away. Everything we covered last month still matters, and you'll
still need to support big print jobs running on big printers. While
data distribution works great for your internal customers, most
external customers still expect to receive paper invoices and
statements. This will change, of course, but it will be decades
before you can forget about real printing. Don't forget that we
started planning for the paperless office just a few days after the
first computers were deployed back in the 1950s, and we're further
from that goal than ever. No matter how cool it may seem to run
your life using nifty gadgets and handy-dandy display tools, there
is something intrinsically satisfying about holding a book, folding
a piece of paper, or doodling in the margin of a report. Those user
requirements may always force us to fuse toner to paper.
|
|
Resources
About the author
Chuck Musciano started out as a compiler writer on a mainframe
system before shifting to an R&D job in a Unix environment. He combined
both environments when he helped build Harris Corporation's Corporate Unix
Data Center, a mainframe-class computing environment running all-Unix systems.
Along the way, he spent a lot of time tinkering on the Internet and authored the
best-selling HTML: The Definitive Guide.
He is now the chief information officer for the American Kennel Club in Raleigh, NC,
actively engaged in moving the AKC from its existing mainframe systems to an all-Unix
computing environment.
Reach Chuck at chuck.musciano@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright99.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-02-1999/swol-02-print2.html
Last modified: