Overview
Web to Print, or WYSIWYG print collateral customisation has become one of the more common add-on facilities that an increasing number of DAM vendors are either offering their clients or being asked to by them.
There are three core elements of these kind of capabilities:
- An editor with which the user can modify the content by either changing graphics and/or text
- A template or form document that contains static as well as dynamic elements
- A rendered file which uses a combination of what the user entered merged with the template. This can be delivered to a printer (either a device or an actual print services firm) for them to generate hard copy(s).
The typical business need for this kind of facility is to enable customisation but without compromising the branding or aesthetic qualities of the resulting output. There is some flexibility to customise, but only within a tightly defined range of parameters. Some common examples of what this gets used for are items like business cards, localised marketing such as point of sale, franchisees and co-operative marketing collateral, to name just a few.
DAM systems are an obvious host for these kinds of facility because they have access to a library of visual content which has been approved for use. Further, they are often managed by marketing or branding personnel who have a good understanding of what the business’ priorities are in terms of visual communications.
These sort of facilities are far from new. They have been in existence for over 20 years in various forms. Prior to DAM systems, they were originally considered a core element of MRM (Marketing Resource Management) and MOM (Marketing Operations Management). An increasing number of DAM vendors want to widen their offer and provide the same facilities to meet a demand from their end-users. As such, the business case and rationale for a DAM vendor to provide these kind of facilities is a clear and fairly obvious one. Their development and implementation, however, is far from straightforward.
The Devil Is In The Detail
As with a lot of specialist media processing requirements which one encounters in DAM, while developing these kind of features is superficially quite logical, there are numerous lower level technical issues and glitches to resolve which make the task a lot more demanding than it appears.
The first (and arguably the biggest) problem is one of perception on the part of many DAM system developers. The majority will have had at least some prior exposure to a related field, such as developing Content Management Systems (CMS). The phrase ‘a little knowledge is a dangerous thing’ certainly applies in this case. The front-end of a Web to Print tool looks quite similar to many CMS’. There is the part when you enter some text and another area where some graphics get selected. The process seems clear cut: the user makes their customisations then the required document is generated and downloaded in a print-based format, such as PDF. What could go wrong? Quite a lot, as anyone who has worked on this kind of feature will readily attest.
WYSIWYG or WTFIWYG?
Most end-users of Web to Print features are already familiar with how they work and while form-based editors are still acceptable for some scenarios, they won’t cut it for the majority of cases. There is an expectation on the part of users that they will have a WYSIWYG interface that is a close representation of what the final output will look like. This requires a fairly sophisticated and highly visual editing user interface. Even in scenarios where the user will put up with a form-based interface, they still need to see a preview of what they will get, especially in scenarios where hundreds (or even thousands) of copies of something might need to be sent to a printer.
Prior to 2010 and Steve Jobs’ now infamous speech where he declared that Flash would be effectively banned from Apple devices, that would have been the most practical way to implement a WYSWIYG user interface. Since 2010, Flash has largely disappeared and three alternatives are now in-play for visual representations: HTML/CSS (HTML5), Canvas and SVG.
Irrespective of which is chosen, the major challenge is text and how to represent it in a way that the template editor the user sees is a reasonably accurate reflection of what the final output will look like. The core problem is that there are two typographic rendering systems in-use. The one on the screen and the one in print. Not only are there two systems, but both of them can (and do) change quite frequently. Each time this happens, developers must update their Web to Print tools or the output the user gets will not match what they see on screen.
Unlike a dedicated page layout application which always has a print destination, web browsers are primarily intended for screen-based output. This means the developer of a WYSIWYG Web to Print tool has to reconcile two different typographic systems: one for screen and another for print. Further, there can be changes to either side of the equation as a result of wider upgrades that are outside the direct control of DAM developers. These all necessitate alterations to allow the WYSIWYG tool to keep working as intended. All of this activity takes DAM developers away from their core platforms, not to mention working on innovative new features which can give them a point of differentiation which their competitors will not have.
Generating Printed Files
Having collected the text and any graphical variations the user wants to make to the template, the next job is to print it. There are two main options for doing this: render a custom PDF file directly or use something like InDesign Server. The former is quite an idiosyncratic format with a lot of complexities to contend with and the latter is also non-trivial. As described in the previous section, translation from what the user sees to the printed output is one of the more demanding tasks. Text tends to be the most complex problem, but issues such as providing screen-based images and those suitable for print (in CMYK colour space) are another.
Readers will note that both InDesign and PDF are Adobe-owned proprietary products/formats. They are not beholden to anyone to continue to support these, nor avoid making significant changes which can cause tools that rely on them to stop working. When this happens, developers of Web to Print tools have no option but to roll up their sleeves and find workarounds. There are few (if any) credible alternatives so this is an on-going risk that DAM vendors who decide to build their own solutions have to contend with.
New and Updated Templates
Another massive issue which is often not thought about is the method for providing end-users with new templates. This includes not only the representation which the user will interact with via the editor, but also the print template that will get filled with user data like custom text and image selections. Further, there has to be some kind of intermediate document which will define how to map what the user has input to the print template so it can be rendered. In the past, developers of these kind of products required their clients to pay them to develop each new template. So for each new design the client needed to make data-enabled, the client had to pay to get fresh templates built. In some cases (and these are still encountered now), there was no standardised method for implementing them. Essentially, each was a custom component, with all the attendant support issues that this implies.
Customers of Web to Print technologies are far savvier than they once were, however and many now understand that the ability for them (or their design agency) to develop these themselves is imperative for the tool to achieve a satisfactory ROI. While this is understandable, if DAM vendors haven’t thought very carefully about the architecture of their Web to Print solution, then enabling third parties to come up with their own template is likely to prove a lot of work. In addition, training and documentation needs to be provided so that support staff will not be overwhelmed with numerous requests for assistance. Even if this is done, there will almost inevitably be many support calls about implementing templates and these will be far from straightforward enquiries which may require the input of development personnel to resolve.
DAM vendors tend to be lightly staffed and leverage on the stability of their platforms (and the fact they don’t change a great deal) to be able to support their solutions satisfactorily. Something quite radically different in terms of functionality to their core asset library solutions can quickly create a lot of disruption across the business.
Conclusion
As should be obvious by now, the development of Web to Print technologies is a complex undertaking, primarily because it involves resolving two different realms (as the name would suggest). This is a very specialised form of software engineering which most DAM software developers do not understood well. To carry out this task properly and in a way that can be adequately supported and maintained almost certainly will involve hiring a dedicated technical team. Effectively, this is like setting up a completely separate product which is delivered within the ‘wrapper’ of a DAM platform.
In the vast majority of cases, for DAM vendors to implement a custom in-house built Web to Print solution represents a waste of time and development budget. Not only is there the initial implementation to consider, but also the long-term support for it also and the risk that it if something goes wrong, it will compromise existing positive relationships with long-term clients.
From a wider perspective, there is an ever-expanding universe of functionality which DAM solutions are increasingly expected to integrate and also a requirement that the user experience is as engaging as possible. The focus of DAM vendors, therefore, should be on these considerations. Anything which draws attention away from it should be left in the hands of specialist suppliers who can concentrate their efforts onto a particular problem domain. Perhaps far more so than many others, Web to Print is an ideal demonstration of this fact.
Ralph Windsor is Project Director of DAM Consultants, Daydream and Editor of DAM News.