If you are thinking about implementing a Web2Print application, there’s a lot of things to consider. While the DMP FLO Suite makes the implementation easier than ever before, there are still a lot of decisions to be made, which will affect the way you are going to set up your web to print solution. Web-to-Print applications come in many shapes and sizes, and this document can’t cover them all. But it will give you some food for thought.
Users
What will be the users of the web-to-print application? In some cases they correspond to actual persons, but more often there is one log-in account for each branch/store/franchise/…
The basic information of the users should be determined:
• address and contact information
• delivery information
• interface preferences
• user rights
• …
How will the user database be maintained? Are you going to add new users in FLO, or import them on a regular basis from another database?
Does every user get the same interface/content, or are there differences? If so, they should be described.
Products
In some cases, the InDesign templates can be filled with product information. A “Product” might be just that, but it might also describe promotions, employees, houses, …
How will users be able to select these products?
Can they add their own records, or only select them from existing databases?
Is the data imported once, or will there be continuous synchronization?
Templates
Consider in advance what the purpose of the web2print application is, and how that will affect the type: PDF or InDesign Templates. There are advantages and disadvantages to using InDesign Server.
Typically, the possible templates are inserted into a structure to facilitate the decision process. Dozens or even hundreds of templates are easier to browse through if they are selected in a number of steps. The structure is usually made configurable, and you can always keep adding items in the structure. But still it is probably a good idea to start thinking about this structure (and who is responsible for it) as soon as possible. While it may seem like a simple thing, it often leads to lengthy internal discussions.
Describe as soon as possible which types of variations are possible in the templates:
• how can images be made variable
• how can the images be selected?
• Always from the entire asset management system?
• From some kind of logic per template?
• Can they be uploaded by the user?
• What happens with exceptions?
• Long texts
• Non-existing texts
• Lack of images
• …
Interface
How will the user select templates? Will you use a tree structure, or a wizard? How is the lowest level (templates) visualized? Which sorts of information are shown next to the templates? Are there initial previews for templates?
Which type of fields will exist? How will image selection be visualized? What type of help texts are added to the form? How will the user be restricted?
Pricing and delivery
Will you visualize pricing information during the ordering process? It takes a lot more configuration later on! Will prices be accurate, or indicative only? Will there be volume pricing, delivery costs, handling, …? Or maybe you want to work with a system of marketing points?
How will delivery information be gathered? Is it filled automatically from the user database? Can it be changed? How many delivery addresses can be entered by the user?
Output
What types of reports do you want to extract from the Web to print application? Can users view a ordering history? Do you require usage statistics for the site?
How will the PDF files be extracted from the system? For each order, or on request by production personnel? Which files are needed next to the PDF files? JDF, XML, …? Which information is needed for the production workflow? Overviews of the orders, emails, ….?