Some years ago, the theme for the Business Forms Management Association's Annual Symposium was Technology Transforms Tradition. Yet how often have we found ourselves overcome and bound by technology and tradition.
From the time when Gutenberg printed the first form to the present, form design has more often than not been driven by the technology of the day. Technology, having set the standard, drives the tradition. So when the technological constraints of letterpress printing made it difficult to get ruled lines to join at the corners of boxes, it became tradition to leave off the vertical lines at the ends. The technology has changed, but for many form designers the tradition of open-ended boxes remains. It seems that it doesn't matter if this makes the form more difficult to use—tradition dominates. When the technological constraints of 80 column punched card computing made it imperative to use character separators, it became tradition to use little boxes and combs. The technology has changed, but the tradition of comb delimiters remains and even the developers of forms software often make an issue of their ability to easily produce "combs".
If we're not careful, the burdens of the past will be on us again and we'll have our electronic forms hamstrung by the developers of technology.
In 1969, trainees at the Bank of New South Wales (now Westpac Banking Corporation, one of the world's largest retail banking organisations) were being told that they had better prepare for change. By the mid 1970's they would have a "paperless office". This was an often-repeated prophecy in those not-so-distant times. How frequently did we attend lectures and read articles by "experts" that told us how technology would take over most routine business tasks. We were even told that we needed to be ready for times of leisure that by the 1980's technology would have advanced so far and taken over so much of our routine work that we would only be working 3 or 4 days a week.
But by the mid 1970's I was predicting that the "paperless office" wouldn't happen. And it didn't! These predictions weren't based on any special revelation from "on high". I just knew the way people worked—I knew that the "experts" didn't understand the users. I wasn't the only one; many other writers were talking about the same thing.
If computer systems are to be truly effective with people wanting to use them to replace paper, analysts must design them for people first, and this hasn't happened. Computer systems have reduced paper in some areas, and in a few cases may have even improved productivity, but here we are, in the 21st Century, and we still don't have even a semblance of a "paperless office".
Hardware has been a significant problem and, to some extent, still is. Monitors are still often difficult to read and generally far too small for effective business use. Computers— even portable varieties—are far heavier than paper and nowhere near as easy to manage, and the common computer interface is often difficult to read and use.
Another problem has been the poor quality of networking technology, especially the inadequacy of standard copper telephone lines for data transmission. There have been improvements in this area in some countries, but worldwide, there is still a long way to go.
The "paperless office" predictions of the 1960’s were a grand idea but, at that stage, technically not feasible. Significant changes have now taken place. Electronic forms software—although somewhat crude at times—now has acceptable functionality, prices of powerful computers are dropping, portable hand-held computers are now available that will recognise handwriting and transmit data via digital phone to remote users and databases, and more and more workers are computer literate. No doubt we'll have even better operating systems and user interfaces in the years ahead.
There is still a gross lack of understanding of the issues and with the Internet fast gaining ground, the desire for this latest fad is replacing common sense in many organisations. I find that many of our clients think of electronic forms solely in terms of the very simple forms that are so commonly used on the Internet for ordering goods. These certainly are electronic forms, but they are a long way from the truly sophisticated, productivity improving forms that can be produced.
A few years ago I went to a demonstration of what was supposed to be electronic forms software. When the demo was over, I asked the company's president for a definition of an ‘electronic form’. His reply left me dumbfounded. He said that "an electronic form is a form that can be printed on a laser printer". By extending his definition to forms produced by any computer printing device, we would have been using electronic forms forty years ago. In fact, the earliest specialised electronic forms software, introduced in the mid 1980's, was solely for printing. Some of it was for printing mainframe computer data onto high-speed laser printers. Other software was designed for filling out on screen before printing on a local desktop printer. The software was crude by today's standards, but it was to form the basis for what was to follow.
In 1991, software became available which allowed the user to fill out the form on screen and then send it electronically to someone else (or even another organisation) without the need for paper at all. It seems that the first company to introduce this concept was Shana Corporation in Canada with its Informed software for the Apple Macintosh. A few months later Delrina, another Canadian company, introduced the workflow concept to its popular Perform product with the name changed to FormFlow. Then, around the same time, another Canadian company, Jetform added workflow capability to its very successful high speed electronic forms printing software. These were true "electronic forms". Of course, these systems still allowed for paper printout where this was necessary.
As we move into the second year of the 21st. Century, we find technology changing rapidly. Electronic forms on the Internet (and internally on intranets) are now commonplace. Some web-based technology (especially using Java) is still very crude, but is fast becoming more useable. Non-Java forms software is now much more web-compatible with applications such as Shana's Informed Filler TM having built-in SMTP Mail, HTTP and FTP capability without the need for a web browser.
Using electronic mail includes sending the form to an intermediate party for authorisation. More sophisticated systems include workflow rules that can automatically make routing decisions for the user by examining the rules established for the particular form along with the data entered.
We're now seeing the development of some very powerful document management and workflow software such as Trillium Software's Metastorm e-work and FileNET's eProcess and Panagon products. These applications add enormous potential to electronic forms, making a paper-reduced office a reality.
Some electronic forms software developers are providing software that allows forms routing to be drawn graphically, converting the results automatically to macros attached to the individual form's software.
Of equal potential is the use of pen computing. There are a wide range of devices on the market with the most well known be the Palm. The range of pen-computing devices and software is changing so rapidly that it is impossible to provide an up-to-date list. I suggest reading Pen Computing Magazine to keep up with the latest trends.
While electronic forms do have some disadvantages compared to paper forms, they also provide many advantages for the form user that often far outweigh the problems. Before we consider the traps in using electronic forms, it is worth considering the potential benefits.
Mathematical calculations (including simple addition) are a major source of error in form filling. Electronic forms can be programmed to take care of much of this work, greatly enhancing accuracy.
One of the major problems with form filling is the tendency of people to ignore instructions—or just make assumptions about how to fill in a form, getting it wrong. Electronic forms provide a much easier way for the user to get information. On screen help windows—either called up automatically or on demand—provide the means to give the form filler the correct information right at the point where it is needed, without cluttering up the form when other fields are being filled in.
Self-checking capabilities take the traditional help process a step further, automatically correcting obvious errors, formatting special fields such as dates and temperature, and inhibiting people from entering invalid data
There are four major areas of cost savings—reduced provisioning, storage and distribution; collecting data at the source with elimination of duplicate (and sometimes initial) keying; and error elimination and reduction leading to less need for follow-up and business activities based on real data.
Of course, if you only use electronic forms software to produce print on demand forms you may not be saving anything as laser printing costs may cost more than using preprinted forms. The main advantage here is with low usage forms required by a large number of end users. Rather than supplying forms in hard copy to many people "just in case they need them", the user only needs to print a copy when required. But this doesn't apply to high volume forms. However, if you are making use of the intelligence aspects of electronic forms then there are significant savings—especially if the forms are sent electronically and never printed out. A further processing saving comes from reduced storage, fewer filing cabinets, less floor space and less file folders.
Collecting data at the source is also a big advantage over the use of paper forms. Keying reduction is an important cost saving benefit. It is common for computer data to be entered from previously filled out forms. If these are electronic forms and are completed outside the office, either by your own staff or external staff, then the data can often be submitted to a database direct from the form rather than have it manually keyed. When completed inside the office, the ability to have data sent direct to a database can be a great cost saver.
The third point is error elimination, or at least major error-reduction. There are two areas of savings. As discussed above, electronic forms can reduce re-keying and this can result in less keying errors. Of greater significance is the reduction of errors due to the ability of electronic forms to either detect errors at completion time or to block errors entirely. Fields can have built in edit checks that prevent bad data from being entered. They can also have pop-up warning messages that can prompt a form filler for correct data every time a mistake is made. Some of the most successful I've seen are those that detect errors and don't even allow the forms to be sent to the recipient if there are detectable errors such as invalid data or missing information.
Electronic forms provide a great advantage over paper forms in collecting accurate data. Typical functionality includes automatic calculations; self-checking of data; correct formatting of dates and other special fields; automatic database look-ups; and dynamic choice/pick lists that change depending on the data entered in the form. Give the huge number of errors made on forms this is potentially one of the biggest advantages.
Here is where electronic forms have it all over their paper cousins. Over the 30 plus years that I've been working in the form design business, the most common problem I've come across is people not reading instructions. Many designers place all the instructions on a separate page and that's almost a guarantee that they won't be read by most people. The ideal place for instructions is right where people need the information, but to do that properly for a lot of public-use forms often means more instructions than data space. This is where electronic forms provide a simple solution. It's possible to only have instructions appear when needed instead of cluttering the form. Another way to provide help is to provide prompts when errors are made or even to force people to see help messages.
Another area of savings is with fill-out time. Well designed forms can often have built-in calculations and other automatic filling capabilities that can save a great deal of time. Forms with numeric data are the best candidates for this type of saving with the ability to add totals automatically and to calculate taxes and similar items. Electronic forms can easily look up databases for automatic filling. For example, entering an employee number could automatically fill in information about the person's name and department. Another time saving feature is the use of choice lists which pop up as soon as the form filler tabs into a field. They make form filling both faster and more accurate. Some software allows such lists to automatically enter codes into fields in place of the full selected text.
One of the big advantages of a good electronic forms system is that your forms never need be out of date. (You need to be careful as a lot of software doesn't have forms management capability.) Electronic forms have a big advantage over their paper counterparts. Electronic forms systems should allow you to distribute a new version of a form to all users as soon as it is approved—to provide an instant corporate-wide update.
At the same time they should allow users to continue to use any old version to reference forms that have been completed in the past. (Remember that with electronic forms it is usual for the form graphic to be separate from the data that is entered. That way, when a form is sent from one person to another, only the data needs to be transmitted, thereby saving a great deal in transmission time and substantially reducing network load—I'll have more to say about this later in the paper.) The issue is that it may be necessary to show the format of the form when it was completed. To do that, the correct form graphic must be used.
Digital signatures systems are available with most electronic forms programs. These are far more sophisticated than just scanning a hand-written signature for printing. These devices enable form readers to verify that the data has been entered by an authorised person, or to detect when something has been changed.
Some applications check the data validity only while others check the validity of the basic form graphic or template as well. The latter is an important consideration when desktop "filler" software is being used, as distinct from forms filled out in a web browser, since it ensures the integrity of the total form.
Depending on the software used, security features can prevent someone altering data after it is filled in. It may also be possible to encrypt data during transmission.
This is one of the challenging areas that is set for rapid expansion as web technology improves. In fact, the use of intranets (Internet-like networks used internally in an organisation) overcomes many of the problems experienced by large organisations having a multitude of different networks that don't always talk to one another effectively, or even at all. It has the advantage of common network capabilities, easy access for all users and the potential in some organisations for low cost distribution of forms.
However, our recent experience has shown that the majority of people who want this approach to forms don’t understand the issues. They don’t appreciate the embryonic status of the Internet and, even worse, don’t understand fundamental aspects of how computers function. While the former will be covered in subsequent sections of this paper, it is worth first considering an important fundamental principle.
Computer professionals may find this strange, but many potential Internet users seem to think that just because they can read web pages in a browser such as Netscape Communicator™ or Microsoft Internet Explorer™ and perhaps even fill out simple forms, that these programs can let them do almost anything. I find many people who want all sorts of complex functionality and form processing ‘intelligence’ to be carried out without the software to provide it. They know that if they want spreadsheet functions then they’ll need a program like Microsoft Excel™, or if they want to write a letter they have to use a word processor program but they think that for some reason, forms are different.
If you want intelligent forms to reduce errors and make form fillers more productive, then the software to provide that intelligence MUST reside on the user’s computer while the forms are being filled out. Some people will claim that it can be on a network–and it is true that the necessary software can be elsewhere–but to actually fill out the form, the computer still has to copy the program (or at least relevant parts of it) into memory on the user’s computer.
Web browsers only provide limited intelligence and, even then, it has to be via JavaScript with the relevant scripting code built into the downloadable web page.
There has been a great deal of argument about the use of what has become known as "thin client" versus "thick client". Put simply, "thin client" is the term used to refer to computer usage where the user doesn’t have the application program residing on a local computer. All the computer activity is processed through a web browser. "Thick Client" means that the application program to open a specific computer file runs on each individual user’s local computer. For example, to open a Microsoft Word document it is necessary for the user to have a copy of the Microsoft Word application program either on their local computer, or at least on the space allocated to the user on the network.
People are misled when they decide that forms can be opened in a web browser without special software to provide the ‘intelligence’. The most common assumption is that they can use PDF formatted forms that appear to open in the web browser. They don’t realise that all the browser does is use a plug-in to access Adobe Acrobat Reader or Acrobat software. This software must be installed on the users computer (or accessible space) for PDF forms to be read. Essentially, the plug-in allows the Reader software to open inside the Browser window. The point I’m making is that even Acrobat (PDF) forms are "thick client".
Some people might say, "well, what about Java forms?" The answer is that even Java forms need software to provide the intelligence features and this is included in a collection of small programs called "classes" which must reside on the user’s computer. Usually, these have to be downloaded each time the person opens the form. They may not be there permanently, but they DO have to be there while the form is being used.
I’m not suggesting that the "thin client" approach is wrong. Given the appropriate circumstances, it can be a viable solution to forms distribution. But you need to be sure that it will work for YOUR needs. There are disadvantages to both approaches and these are covered in the following sections. Of course, to be technically correct, there is no such thing as TRUE "thin client" since you still have to install web browser software to read HTML forms. You just can't open forms on a computer without some sort of software to provide the intelligence.
HTML (hypertext markup language) is the most common approach to forms on the web. However, it is severely limited in its capability due to its lack of inherent functionality. To a certain extent this can be overcome by the use of JavaScript that adds intelligence features to HTML forms, but this is only possible if the end-user’s web browser supports JavaScript. At this point in time, that is often no more than a pipe dream as many web users don't have a browser that has JavaScript capability and, even if they do, it isn't always the same version of JavaScript. I recently tried to evaluate some new forms software that was available from the developer's web site but found that it just didn't work on my computer because the version of JavaScript in both my web browsers was incompatible with that used for development of the forms.
HTML and JavaScript forms are suited mainly to short forms such as those used to gather information from web users. They need to be completed while the user is on-line and in a single session. With the use of cgi (Common Gateway Interface) scripts, data can be submitted to databases directly from a user's browser, but these forms do not allow the user to save the form with the data entered. It can be printed with the data and this can be fine for Internet forms, but not being able to save the data can be a serious limitation for internal intranet forms. If the user is to be given the option of saving the data then the web server has to return a copy of the form in plain HTML with the data embedded so that the user can save it.
The main advantages are that files are small, they can be accessed by anyone with a web browser, they can be sent over an e-mail system and they can be easily cross-linked to instructions using HTML hypertext.
The main disadvantage is that forms must be filled out while on-line and this causes problems if the data isn’t readily available. This is a particular problem with long forms, as the person has to start over again if the line drops out. This can happen due to bad phone connections or just timing out because the form filler had to go away to get information. As well as this, connection time can be costly, so there is a tendency for people to rush and make mistakes in order to minimise on-line time. Generally, people filling out long forms in HTML would need to print out a paper copy, collect the data and fill out the form manually, and then go on-line again to complete the HTML form. You might not consider this a problem in your circumstances, but you do need to be aware of the issues. A way around the long form issue is to set up a database at the server end that provides temporary storage for the user's data until the form is completed. It's worth noting that there is commercial software available to handle this type of application.
Java (not the same as JavaScript discussed above) provides many more functions in forms, but still has many restrictions for the serious forms user. Its primary advantage is its cross-platform capability and the ability to fill out a form without the need for special software other than a suitable browser. Remember that the browser must be Java enabled. At the time of writing, this capability is problematic, as Java hasn't been implemented the same way in all the well-known browsers. In fact, it isn't even implemented identically in the same brand of browser across different platforms such as Windows and Macintosh. As with HTML forms, Java prevents the user from saving the form with the data and it also doesn’t always allow the form to be printed with the data. Printing may be possible if the form is signed with an electronic signature and permission is granted to the user to print or if the user sets security to a low level.
While it has a lot of advantages, it has the major disadvantage that the Java classes (the mini programs that make Java forms work) have to be downloaded each time. This isn’t a real problem for a form that has to be filled out only once, but for internal use where the form might be used many times, it can be a time-consuming process.
PDF forms have advantages where forms are to be downloaded off the Internet for printing only. The file sizes can vary but are often considerably smaller than the graphic files they reproduce and the printing quality is excellent provided the user has a suitable printer and can use Adobe Type Manager® software. Forms are opened using Adobe’s Acrobat Reader software. It is an ideal solution when graphics have to be downloaded and when the user may not have all the included fonts. The latest version now handles fillable form fields and increased intelligence.
However, it has three main disadvantages for serious electronic forms work. It lacks built-in forms management capability, has limited intelligent functionality without the use of complex JavaScript programming and forms cannot be saved with their data intact without the use of the full Adobe Acrobat program or Adobe Acrobat Approval. The attraction of PDF is that Adobe Acrobat Reader is free. But remember that this software only provides limited functionality. If full functionality is required, users have to purchase Adobe Acrobat program or Adobe Acrobat Approval and the form designers have to be competent JavaScript programmers. Note that JavaScript is required for even the most basic field calculations.
Some people are misled by the apparent ability to fill out PDF forms within a web browser. I say "apparent" because while the document appears in the browser window, the Adobe Acrobat Reader program is still required. It is actually the Adobe Acrobat Reader window that the user is looking at, but it is contained inside the normal browser window that will limit screen space if you only have a small monitor.
It’s not my intention here to discredit PDF as a format since it does have many positive uses–in fact, we use it extensively in our company. While the PDF format does have some limitations, if you only need to produce a copy that can be printed (even in colour) then PDF can be an excellent solution. Even for small forms filled out on line from a web page in a single sitting it can be a useful tool.
The most recent version of Adobe Acrobat and its associated products does significantly improve the way electronic forms can be used. It is possible to send just the data of a form (in FDF format rather than PDF), greatly reducing the transmission time, and the end user has to import the data into a copy of the original file. However, the person sending the data still needs to have Adobe Acrobat or Adobe Acrobat Approval software. Adobe Acrobat Reader doesn't have that capability.
There are a number of products on the market which enable the form designer to produce forms as stand-alone applications (".exe" files). These can be downloaded and used without the need for special software–at least, that's what the manufacturers claim. In fact, the special software is built into the form application itself–it has to be built-in if the form is to have any intelligence.
I recently reviewed the specifications for a program where the developers provide 2 demonstration forms—one of them quite small. Yet the downloaded compressed file is over
1.35 MB in size. Once decompressed, it installed 6 items for form 1 (90k), 5 items for form 2 (237 k) plus some database files as well as installing 1.3 MB of files in the System Directory. This is a total of 1.646 MB of files for only 2 forms. The forms had very limited functionality. Just imagine the size of the files if they were complex.
While the developers claim that no special filler software is needed, and hence no filler licence, special software IS needed if normal e-forms functionality is to be included. The basic version is extremely limited. I redrew the forms in another program, complete with calculations, lookup lists and data base connections and the form sizes were only 16k (Form 1) and 28k (Form 2). When you consider that this is almost 300k less than the stand-alone file (15%), I wonder about the value of such an approach.
There is also the problem that it was only Windows-based. Our experience is that many members of the general public use Apple Macintosh computers and that use of such limited software is a severe disadvantage. Web-based forms need to be cross-platform if they are to truly serve the needs of the community at large.
I'm not suggesting that you should never use such an approach, but am just warning about the issues and the need to take all your needs (and your users' needs) into consideration. Where the typical user would only ever download one or two forms, it could be a great cost saver and still do the job adequately. But if there were many forms, it is not an efficient system.
This is the easiest approach to using forms on the web. As long as the user's browser has been correctly configured, it will automatically save (and possibly open) the form as soon as it has been downloaded. The disadvantage is that the user has to have a copy of the software and this, too, may have to be downloaded the first time it is needed. Where the filler is likely to need to fill out a number of forms, this approach can be the most efficient.
The software may even automatically configure the web browser to use it as a helper application.
This approach enables the user to open the form from within a web browser. While the plug-in approach can be a great advantage in using PDF documents in that the user can read a page at a time, there is little advantage in this with a PDF form, since the whole form has to be used.
I've come across vendors who promote the plug-in approach, telling potential customers that they are getting "thin client" software and that "thick client" is out of date. Yet all the plug-in does is replace a filler program. So it's really "thick client".
Deciding the approach is not always easy, especially for an internal system. You have to balance the desire to use the latest technology, and especially low cost technology, against its limitations. At the time of writing this, very few organisations are making effective use of intranets. We still have a great deal to learn, but it is obvious that it is also very easy to get things wrong and that the easy way out is rarely the best. My advice is to examine your needs carefully before you launch into putting your forms on an intranet.
The biggest problem I have seen to date occurs when organisations decide to make all their forms available for use within a web browser–often referred to as the "thin client" approach. To the inexperienced, it seems like a simple and effective solution to the paperwork burden, but the problems it introduces usually far outweigh the perceived advantages. You need to thoroughly understand the advantages and disadvantages of the different approaches discussed earlier in this paper.
Even for public-use forms, the solution is by no means easy. As I write, a report has appeared in The Australian newspaper.
“Less than a year after the ‘whole-of-government’ approach to IT outsourcing dropped totally out of federal fashion, the idea that all government services should be available on line is looking seriously uncool.
Reporting on its third study of the use of Internet technology by governments, Deloitte Research has reported that demand for online provision of government services available via other channels rarely goes beyond 30 per cent of customers surveyed.”
Our company's experience with customers over the past year backs up this claim. While we've helped numerous organisations to produce web-based forms (either fillable or just PDF for print), we're frequently told that many people prefer to have a paper copy sent rather than use the Internet to download a copy. After all, why should people pay for Internet time when they can get the form free of charge.
In Reengineering The Corporation, the authors stress the importance of using technology the right way.2
"A company that cannot change the way it thinks about information technology cannot reengineer. A company that equates technology with automation cannot reengineer. A company