Focused Forms Training
Ray H. Killam, CFC, CFSP
Ada, Michigan
November 17-18, 2004
Sponsored by BFMA
Welcome and Introductions
• New Attendees - Please tell us your
name, organization, job title, and
experience with forms
• What is your goal for this session?
• Please share:
– Years experience with eForms
– Technology you use
– Brief description of your program
Agenda
Day 2
• Definitions
• Elements of a successful
eForms program
• Ten critical success factors
• Designing for the web
• Design analysis –
special considerations
• Web technologies
Agenda
Day 2 (Continued)
• Usability issues
• Deployment strategies
• Return-On-Investment
• Emerging battle –
PDF versus XML?
• Who are the players?
• Demonstration
• Exercise
Developing eForms -
Form Types
• pForms –
paper, or other physical substrates
• eForms –
digital forms used in non-browser environments
• iForms –
digital forms used in browsers
Developing eForms -
Definitions
• Quick History Lesson:
– What is the Internet?
 www.walthowe.com/navnet/history.html
– What is the World Wide Web?
 www.w3.org/History.html
– What is the W3C?
 www.w3.org
Developing eForms -
Definitions
• Browser
What is it and how does it work?
 It’s a program used to visit web pages
 It works by using a protocol called HyperText Transport
Protocol (HTTP) to request a specially encoded text
document from a web server. This text document contains
special markup code written in HyperText Markup Language
(HTML). The markup is interpreted by the web browser, the
job of which is to render the document's content in an
appropriate manner for the user's convenience.
Developing eForms -
Definitions
• Browser
What is it and how does it work?
 The HTML may include such things as references to
other web documents using hyperlinks and bookmarks,
suggestions for text color and position, and other content
such as images and audio and visual ("multimedia") content
Types
 PC & Mac -- Internet Explorer, Netscape, Opera
 Open Source – Mozilla – Firefox 1.0 (www.mozilla.org)
 Unix/VMS – Lynx (http://lynx.browser.org), w3m
 Amiga -- VoyagerNG, Mosaic and others
Developing eForms -
Strategic
• Every organization needs a
strategy for eForms and iForms
• Developing an Effective Strategy
Developing eForms -
Strategic
• Levels of eForms
– Print-on-Demand
– Fill-and-Print
– Intelligent Electronic Forms (IEF)
– Enterprise-enabled eForms
– Applications developed using forms tools
Why do eForms Programs Fail?
• Islands of automation – no strategy
• Transfer of responsibility to IT
• Downsizing/Outsourcing of Forms
•
•
•
•
Management function
Conflicting definitions
Issues with software /
Understanding of forms
Scope creep
Complexity
Strategy vs. Tactics
• Strategy – the process of positioning an
organization for competitive advantage;
planning for the direction of the enterprise
prior to engagement.
It is perspective and direction.
• Tactics – Managing of resources while
engaged.
It is the current plan; a set of actions.
Why Develop a Strategy?
• People can more easily implement
what they know.
• People are more likely to implement
properly when they understand.
• People readily implement
what they are committed to.
• People give up on a strategy when its
implications have not been anticipated.
What is an eForms Strategy?
• Enterprise agreement on goals,
solutions supported, tools to be
used, and implementation policy
• Consistent application of a set of
practices to be used for the
development and deployment of
electronic forms throughout the
organization
No Strategy?
• There is always a “strategy”
• If you don’t have a formal strategy,
one will evolve for you
• Electronic forms are compelling –
users want them and will develop
them if you don’t
• Islands of non-compatible eForms
will materialize
Who needs to be involved?
• Forms Management – coordination
• Information Technology - databases
• Web Administrator - deployment
• User Departments - need
• Sales and Marketing – define how we
communicate with the public
• Finance – require positive ROI
• Legal – Signatures, records requirements
Who are the Audiences?
• Inside the firewall
•
– Knowledge workers
– All personnel within the organization
Outside the firewall
– Customers
– Suppliers
– Prospects
– Stakeholders
– Public
Internal Considerations
• Is there a Corporate Style Guide?
• What policies and procedures will
be affected?
• Inside the firewall (intranet) –
more control, more flexibility
• Password access, security,
non-repudiation is easier
External Considerations
• Outside the Firewall (Internet)
– Signature technology and support
– Non-repudiation
– Require registration?
– Access control
– Filler software requirements
– Routing, printing and local save
Ten Critical Success Factors
1. Establish measurable goals
2. Align your business and your IT
operations
3. Get executive support up-front
4. Let business goals drive functionality
5. Minimize customization by leveraging
out-of-the-box functionality; avoid
scope creep
Ten Critical Success Factors
6. Use trained, experienced suppliers
7. Actively involve end users in the
solution design
8. Invest in training and empower
end users
9. Use a phased rollout schedule
10. Measure, monitor and track
Critical Elements of a Program
• Establish workflow analysis processes –
why automate bad processes?
• Develop Return-on-Investment
requirements
• Develop goals for data capture and
management – database connectivity
• Develop standards for edition control and
archiving – creating legal records
Critical Elements of a Program
• Develop a deployment strategy
•
•
•
•
– catalogs, portals, distributed POD
Define eCommerce requirements
– credit cards, personalization, security, privacy
Establish a policy for non-repudiation
– validation of user identity
Establish a policy for electronic signatures
– technology, vendors, costs, “take to paper”
Define a workflow integration policy
– routing, storage, retrieval, tracking
Critical Elements of a Program
• Integration with paper forms management
– catalogs, design, management
• Software selection
– workflow, design, mapping, database
connectivity, server scripts, technologies
supported (paper forms, browsers, XML,
ODBC, JavaScript, CGI, scripting, open
source, extendable, more)
Critical Elements of a Program
• Interfaces to Records Management
and Document Management systems
• Search functionality
• Managing obsolescence
• Training and help desk support
• Programming support
Summary
• Bringing the organization together with a single
•
•
•
strategy is difficult
It will require developing a business case and
selling it to management
It can return significant benefits in important
areas such as new customer acquisition,
customer retention, customer service, process
improvements and cost control
Developing any forms strategy is the
responsibility of the forms department
Strategic Elements -
Designing for the Web
• Development
– Who develops forms?
– Process for new forms, revision
– Obsolescence policy
– Forms control
(numbers, applying standards)
– Retention policy
– Approvals
Strategic Elements -
Designing for the Web
• Deployment Strategies
– Email support
– Servers
– Forms portals
– User access controls
– User submission of filled forms
– Local save and print
– Security policy
Strategic Elements -
Designing for the Web
• Support
– User training
– On-line help
– Help desk support
– Instruction manuals
– User guides
– Designer training
– Level of support (24 x 7?)
Strategic Elements -
Designing for the Web
• Software Selection
– Design software
– Client software (fillers)
– Edition management
– Workflow design software
– Compatibility with existing systems
Strategic Elements -
Designing for the Web
• Output Strategy
– Save and print
– Database access
– Multiple versions support
– Offline and online
– Multiple device support
(PDAs, notebooks)
Strategic Elements -
Designing for the Web
• Management Reporting
– Metrics and statistics tracking
– Enhancement requests
– User satisfaction levels
– Strategic support (mission, goals)
Strategic Elements -
Designing for the Web
• Mapping / Programming
– Level of complexity supported
– Out-of-the-box functionality
– Tools to be used
– IT support required
– Outside resources required
– File and field naming conventions
Strategic Elements -
Designing for the Web
• Routing
– Attach to email
– Rules-based routing
– Status tracking
– Multiple, simultaneous routing
– Approvals capture and security (un-sign)
Strategic Elements -
Designing for the Web
• Database Connections
– Read
– Write
– Permissions and connections
– Open Data Base Connectivity (ODBC)
– Roles
 Data Administrator
 Database Administrator (DBA)
Strategic Elements -
Designing for the Web
• Storage and Retrieval
– Data and container separate?
– Associate data to edition of container
– Records management requirements
– Archiving, allowing for technology changes
– Backup
Strategic Elements -
Designing for the Web
• Security and Privacy Issues
– Secure servers (https protocol)
– Intrusion detection
– Data encryption
– Secure access
– Secure features on a form
– Compare to security of a paper form
– Associate cost to business risks
Strategic Elements -
Designing for the Web
• Other considerations
–
–
–
–
–
–
–
–
–
Workflow analysis
Need to support paper forms in same system
Source file management
Dealing with bootleg forms creation
Interfaces to other systems
Search capabilities
Forms portals
Managing obsolescence
IT Department support
Strategic Elements -
Designing for the Web
• Signatures
– Esign and UETA
– Signature verification is all about the process
• Can you document it?
• Can you prove it?
• Can you reproduce it?
• Is it secure?
– Security versus usability are competing factors
Strategic Elements -
Designing for the Web
• Signatures
– Three things to remember
1. Once introduced, requirements will
2.
3.
grow rapidly
Compliance is a significant component
of the solution
Committing resources to a non-strategic
function is always more expensive
Strategic Elements -
Designing for the Web
• Front-end Process
–
–
–
–
–
Authenticate user (passwords, smart cards)
Consent to transact electronically
Maintain document format (no fillers!)
Present without download
Record of delivery and acceptance (workflow and
business rules embedded into the process)
– Establish intent to sign
Strategic Elements -
Designing for the Web
• Front-end Process
– Capture signature (no download)
– Signature must be verifiable after the fact
– Copies must be provided to all parties
– Process must be tamperproof, secure
and with an audit trail
– Provide data extraction to feed other systems
– Eliminate manual processes and ROI
Strategic Elements -
Designing for the Web
• Back-end Process
– Vertically and horizontally scalable solution
– Uptime 24 X 7
– Interoperability with other systems
– Seamless data flow
– Secure server and data encryption
– Embedded audit trail
Developing eForms -
Design Analysis
• Zoning – can be replaced by sub-forms,
hidden fields, hidden pages
• Setting preferences – object properties
• Box and columnar design using tables
• Grouping – same as pForms
• Sequencing – tab order
• Spacing – designing to fit the data field
Developing eForms -
Design Analysis
• Field Types
• Masks
• Restrictions and qualifiers
• Using the Style Guide
• Design conventions
• Design standards
• Data formats and types
Developing eForms -
Design Analysis
• Data Formats
– Data formats can increase or decrease
the utility of the data collected
– Most software programs use proprietary
formats, but support standard formats
– Many, many formats in use
Developing eForms -
Design Analysis
• Data Formats
– Standard
 ASCII
 HTML, XML
– Proprietary
 .doc, .xls, .ppt
 .g, .elf
– Generally Accepted
 PDF, EPS, PostScript
Developing eForms -
Design Analysis
• Data Type
a detailed coding scheme recognized
by system software for representing
organizational data
• Four objectives:
1.
2.
3.
4.
Minimize storage space
Represent all possible values
Improve data integrity
Support all data manipulations
Developing eForms -
Design Analysis
• Data Types for ORACLE
– CHAR (size), where size
is the maximum length
–
–
–
–
–
–
DATE
DECIMAL
FLOAT
INTEGER
INTEGER (size)
LONG
–
–
–
–
–
–
–
–
LONG RAW
LONG VARCHAR
MLSLABEL
NUMBER
SMALLINT
VARCHAR
VARCHAR2
RAW
Developing eForms -
Design Analysis
• Data Types for MS ACCESS
– TEXT
– AUTONUMBER
– MEMO
– YES/NO
– NUMBER
– OLE OBJECT
– DATE/TIME
– HYPERLINK
– CURRENCY
Link
Developing eForms -
Design Analysis
• Life cycle – using a form
• Performing calculations
Developing eForms -
Design Analysis
Using Excel
• Uses cell descriptions instead of field names
• Math performed in logical sequence
• Formulas must be exact syntax
• Can use “point and click”
• Formulas can be dynamically copied
• Most of us have learned how to use
Developing eForms -
Design Analysis
Using VB Script
• Must provide “Dimension” (DIM)
•
•
•
•
•
statements for variables
Uses field names – must be precise
Uses exact syntax
Can use “do” loops to simplify code
Must set initial values
Calculations performed continuously
Developing eForms -
Design Analysis
JavaScript
• Not related to Java, the programming language
• Works within HTML code
• Has functions similar to VB Script
• Works within Microsoft Internet Explorer (IE)
•
but not with Netscape
Has its own syntax and rules
Developing eForms -
Design Analysis
Calculation Wizards
• Provide “point and click” capability
•
•
•
for simple calculations
Convert the click results to JavaScript
or some other language
Not yet readily available in most
forms programs
Example: Adobe Acrobat
Developing eForms -
Web Technologies
•
•
•
•
•
•
•
•
HTML Editor
Browser
XML and XSLT
Compiled languages
Scripting languages
Common Gateway Interface (CGI)
Database technology
Web Authoring Tools
Applets and Servlets
Developing eForms -
Web Technologies
• Compiled languages
are converted to
machine language
using a “compiler”

Link
BASIC
Pascal
FORTRAN
RPG
COBOL
Ada
C
Assembly
Language
PL/1
Visual Basic
Developing eForms -
Web Technologies
• Scripting languages execute one line at
a time and do not need to be compiled
– JavaScript
– PHP
– Practical Extraction and Report Language
(PERL)
– Active Server Pages (ASP)
– Java Server Pages (JSP)

Link
Developing eForms -
Web Technologies
Common Gateway Interface (CGI)
• a programming interface between a web server
and the systems’ backend functions - such as
processing systems and databases
• allows web servers to perform data functions
and interact with users
Developing eForms -
Web Technologies
Common Gateway Interface (CGI)
• Server-side programs or scripts –
all processing occurs on server
• Client-side solutions include Java applets,
Java scripts, and ActiveX controls

Link
Developing eForms -
Web Technologies
Databases
• “An organized collection of
logically related data”
 Metadata:
“data that describe the properties
or characteristics of other data”
 including data definitions, data structures
and rules or constraints
Developing eForms -
Web Technologies
Database Types
• File processing systems
– Each application contains its own data
• Hierarchical
– Data are organized in sequential order
– Requires reading from beginning until
location of data
• Relational
– Data stored in tables with keys defining
relationships
Developing eForms -
Web Technologies
Relational Databases
• Data Structure - Data are organized in the
form of tables with rows and columns
• Data Manipulation - Powerful operations
(SQL) are used to manipulate the data
• Data Integrity - Business rules are applied
to maintain integrity during manipulation
Developing eForms -
Web Technologies
Important Terms
• Primary Key – an attribute that uniquely
identifies each row in a table
• Foreign Key – An attribute that also
serves as the primary key in another
relation in the same database
• Composite Key – a primary key that
consists of more than one attribute
Developing eForms -
Web Technologies
Open Data Base Connectivity (ODBC)
• A standard method of sharing data between
databases and other programs
• ODBC drivers use the standard Structured
Query Language (SQL) to gain access to
data from outside sources
• Each database program requires a different
driver
Developing eForms -
Web Technologies
Database Use for
Electronic Forms
• Any form that provides the ability to
save and recall the variable fill data
requires the use of a database
• It may be a simple table or a multiple table
database, or even multiple databases
Developing eForms -
Web Technologies
Databases and Electronic Forms
• Databases can be “Read” where data are
extracted from a table and placed in the form,
or “Write” where data are extracted from the
form and placed in the data table, or both
Developing eForms -
Web Technologies
Databases and Internet Forms
• Database must reside on the Internet
server or be connected to the server
• Database interaction is managed by CGI
scripts or related technology
• Important to remember that HTML does
not interact with databases

Link
Developing eForms -
Web Technologies
• Web Authoring Tools
– Microsoft FrontPage
– Macromedia Dreamweaver
– Adobe GoLive
– NetObjects Fusion
– Many HTML editors available

Link
Developing eForms -
Web Technologies
What are Servlets?
• Servlets are programs written in
Java that run in conjunction with
a web server.
• They are Sun Microsystems
version of CGI
Developing eForms -
Web Technologies
What are Applets?
• Applets are small, fast programs
that can run on any kind of computer.
This makes them perfect for use on
the Web because the program can be
downloaded and run on a Mac or a PC
or a Unix workstation. Today, they are
used mainly in graphics and animation.
Developing eForms -
Usability Issues
• Access: Three levels
1. Access to the system
2. Access to the form
3. Access to the information
on a form
Developing eForms -
Usability Issues
• Compatibility
– Competing, proprietary software
 List of software providers
– Proprietary technologies
 Microsoft, Sun Microsystems, Adobe Systems
– Form standards?
 Xform standard (recommended by W3C)
 PDF (widely adopted – recommended by Adobe)
 XML (W3C developed – widely supported)
Developing eForms -
Usability Issues
• “XForms" is W3C's name for a specification
of Web forms that can be used with a
wide variety of platforms including
desktop computers, hand-helds,
information appliances, and even paper.
• Decoupled data, logic and presentation
• Has yet to gain traction
Developing eForms -
Usability Issues
• Server-side Considerations
– Scripts
– Web services
– Database access
– Login, password management
– Encryption
Developing eForms -
Usability Issues
• What people say about forms
– Function
– Appearance
– Content
– Stress
Robert Barnett - Robert Barnett and Associates Pty Ltd
Developing eForms -
Function
• They hate to write anything down.
• The don’t know the answer to the questions
•
•
•
•
on the form.
They hate to be pinned down.
Filling out the form has nothing to do with
the main task.
The form asks apparently irrelevant questions.
The same stuff has to be put on every form.
Robert Barnett - Robert Barnett and Associates Pty Ltd
Developing eForms -
Appearance
• The form looks intimidating to fill out.
• The form looks cruddy and unimportant.
• There isn’t enough room to write the
answer.
• The form demands too much writing.
• The type is hard to read.
Robert Barnett - Robert Barnett and Associates Pty Ltd
Developing eForms -
Content
• The meaning of the question or category
of response is unclear.
• The sequence of items doesn’t make
sense.
• Unpleasant operations have to be
performed in filling out the form.
• How can an erroneous entry be changed?
Robert Barnett - Robert Barnett and Associates Pty Ltd
Developing eForms -
Stress
• People find most forms confusing and intimidating.
• Bad forms cause and increase tension.
• Pressure situations for form fillers:
–
–
–
–
–
–
–
Hospital admission
Job application
Worker’s compensation claim
Social security application
Applying for bank finance
Filling in police form
Filling in tax return
Robert Barnett - Robert Barnett and Associates Pty Ltd
Developing eForms -
Usability Issues
• Accessibility – Section 508
– A Federal law requiring that all electronic
and information technology purchased by
the government be accessible for people
with disabilities.
This affects everything from web sites to
videos and multimedia productions, and
includes all electronic forms delivered via
any medium.
Developing eForms -
Usability Issues
• Section 508
– Requires that Federal agencies’ electronic
and information technology be accessible
to people with disabilities
– Is a major consideration for forms
designers within government and will
probably trickle down to the private sector
Developing eForms -
Usability Issues
• Section 508
There are 16 rules for Accessible Web Sites.
Rule 14 applies to forms:
“Make electronic forms accessible via assistive technology”
When electronic forms are designed to be
completed on-line, the form shall allow people
using assistive technology to access the
information, field elements, and functionality
required for completion and submission of the
form, including all directions and cues.
Developing eForms -
Usability Issues
• What is “Accessibility”?
– Electronic forms must provide users with options they
can select
– Options may include large type, keyboard access to
all commands, sound (read captions & instructions)
Braille output, color choices, and more
– Includes impairments to: hearing, speech, learning,
mobility and visual.
Developing eForms -
Deployment Strategies
• Adobe Acrobat products
• Microsoft InfoPath
• CGI (Open Source)
• Form Router
• Catalogs
• Portals
Developing eForms -
Deployment Strategies -Adobe
• Most users have the free Reader, which
limits what they can do with a PDF file
• Adobe requires a server product to extend
Reader functionality
• Server products have minimum licensing
requirements, such as 20 forms or 20
users. Starts at $75,000 + (my estimate)

Link
Developing eForms -
Deployment Strategies -Microsoft
• InfoPath is available only with Office 2003
Enterprise Edition (full functionality)
• InfoPath is available as a standalone
product (limited functionality)
• Users must have InfoPath to open a form
• Does not seem viable outside-the-firewall
• Does not support HTML forms, nor PDF
• Expensive
Link
Developing eForms -
Deployment Strategies – Open Source
• Apache Server
• MySQL database
• PERL or PHP scripts
• HTML / XML
• JavaScript
• Must put it all together

Link
Developing eForms -
Deployment Strategies -FormRouter
• Build simple forms
•
•
•
•
•
(or send FormRouter your form)
Set alerts –
each time a form is submitted
Host your form (on their server)
Collect your data
Download responses
View results
Link
Developing eForms -
Deployment Strategies - Catalogs
Return
Developing eForms -
Deployment Strategies - Portals
Return
Developing eForms -
Return-On-Investment
• Hardware and software acquisition
• Comparing software
• Project payback
• Activity-based Costing
Developing eForms -
Return-On-Investment
• Activity-based costing
– Defining activities and outputs
of specific activities
– Tracing resources to activities
– Tracing activities to determine
costs of products/services
– Identifying cost drivers of
non-value-added activities
– Eliminating non-value-added activities
Developing eForms -
Return-On-Investment
• Traditional view of Costs
–
–
–
–
–
–
–
–
–
Salaries
Benefits
Postage
Supplies
Telephone
Equipment
Travel
Miscellaneous
Total Budget
$267,000
59,000
17,000
18,500
12,000
6,500
3,000
4,000
$387,000
Developing eForms -
Return-On-Investment
• Process View of Costs
– Receive orders
$161,499
– Resolve errors
119,797
– Generate conformations 85,006
– Answer Inquiries
19,212
– Generate reports, Mgmt.
2,329
Total Budget$387,000
Developing eForms -
Return-On-Investment
• Obvious focus for reduction:
– Resolve Errors
– Causes, results, actions, solutions
Demonstration
Thank You
Essociates Group, Inc.
13305 West 126th Street
Overland Park, KS 66213
Ray H. Killam, CFC, CFSP
rkillam@essociatesgroup.com
913.284.6573
Carl W. Brannon, CFC, CFSP
cbrannon@essociatesgroup.com
408.978.3417