Printess knows that concepts for selling, editing and finally production of a personalized product are different for each product, business concept and production workflow. That’s why we did not implement a one size fits all workflow and are flexible from the core to match every detail of the necessary workflow. This is especially important if thousands of templates need to be created and maintained.
In this Chapter we will discuss the following options to shape the workflow for your project or product type.
Printess allows for customization of the buyer side editor on diffrent levels.
The code for the buyer side editor is available for Printess customers and can get skinned or if needed modified with ease.
We took care to build the code for it based on well known bootstrap standards so that your web developer is in it fast and tweeking it to your liking is easy.
Propably the most easy way to let the editor blend into your shop environment is by styling it with a CSS. A Bootstrap theme can also be used for this so you don’t have to start at zero.
Here is an example of a styled buyer side interface:
If that is not customized enough, you can even build your complete custom UI using the editor as a view port only. For this Printess has build a complete editor API (JS-API) which will raise an event in cases where a user selected an editable element and will tell exactly what can get changed.
Please have a closer look on how to build your own UI for the Buyer Side here
The right customization approach depends on the product and your user base. Thats why Printess features diffrent approaches for configurations and allows to test them fast.
Define input fields for the values used in a document. This is especially usefull if one value gets used several times accross a document or the document has a lot of global configurations anyways.
Please also see chapter Styles & Form Fields and Chapter Buyer Side.
Sometimes a step by step approach is a good way to make sure a document is configured in full - especially if it has non obvious configuration elements. The step by step configuration option will not only guide the user through the configuration, it will also zoom to the currently configured point of interest. This is especially useful on space limited mobile devices.
Steps can also be set to switch between documents. This allows configuring a document before it is placed in e.g. an Avatar. Another use case is using the steps method to configure a document and in the last step switch to a preview document showing a photorealistic preview of the product.
Learn more about step based configuration in the Buyer Side chapter.
Documents with obvious configurationworks best by simply selecting an element and then cutomize the selected element. This is a useful approach for documents with many configuration points on the pages. Except for rich text editing in the desktop interface, configuration options for the selected element will be shown depending on the allowed changes for the selected element or group. Learn more about buyer side configuration options and groups in the Buyer Side chapter
Snippets can either be used as the basic building blocks like text frames, images or special headlines. Or they can be used as complete configurable design elements - so called group snippets - a user can insert on a page. Snippets are ideal if one would like to present a free design option to buyers which is still easy to use but creates good looking products.
Another way of using Snippets are the so called layout snippets which define complete layout options for a page e.g. for Greeting Card inside pages or Photo Book pages.
Learn more about Snippets the repsective chapter
The most simple configuration - one configurable primary document in a template - offers already a lot of options.
Whenever configuration gets more complex e.g. configured elements gets used on several pages, special output documents are neccesary, photo realistic previews should be shown - Printess has several options to conquer these complex needs. Using the sub document feature you can use other documents on pages - much like an image - but these sub-documents are still configurable.
With the steps interface such sub documents can even be set up in first to get the get used the main document.
Learn about Sub Documents here
Whenever one has products containing several identical pages accross many products, merging of documents is helpful. As an example for this have a look at a proposed greeting cards workflow.
In this example the final document to edit for the buyer is created by taking the Greeting Cards Master Document and merging the buyer selected artwork template on Spread 0 and the cards back template to Spread 2.
The Greating Cards Master template will not only define the inside pages (which could have been merged as well) but also defines the available buyer colors, buyer fonts, form fields, styles, the final bleed, the pasteboard, usable snippets and the basic buyer side behaviours like multi-line text edit mode. This helps to keep your products maintainable. If e.g. an additional font should get added to all products one would only need to edit the master document and not all product artworks.
Merging of templates can also be tested for up to three merge templates directly in the editor by supplying the parameters in a url(the API does not limit the amount of merge templates). To let this work the browser needs to be logged into the editor and the account the templates to be merged are in.
These are the Parameters:
The Editor will open the master template and merge the additional merge templates creating a new merge document which can be tested.
Note this url method is for testing purpose onlyc(during design phase) - in the real shop workflow this is done by the mergeTemplates parameter when starting the buyer side editor (s.b.) Learn more about merging templates in the embedding the editor chapter.
Especially in B2B portals documents sometimes need to get prefilled with data. This is the workflow of choice if data is already known or asked before configuring of the document happens. In these cases a document can be build with form fields and these form fileds can be prefilled when starting the editor.
Learn more about passing form field values here.
Example Businesscard document portal:
Customized products are often sold via platforms which do not allow to integrate an editor. In this case the personalization workflow must be based on pure data input.
If you are allowed a preview image then rendering this via the Printess backend is an option to at least show the result after customization.
If multiple channels with diffrent abilities should get served one can also build templates which are dual use - they can get either configured graphically via the editor or used in ‘trade-mode’ and get filled by form field data. This avoids maintaining several grafically identical documents just because diffrent custumization methods are needed.
The Save Token Workflow as illustrated above makes it easy to integrate Printess into any desired workflow and systems. Whenever a document is edited on buyer side the editor will return a save token and if needed a thumbnail of the final state when exited. This save token can be used to create highres print files or it can be used to reopen the configured state in the editor either from the shopping card by the customer or in case of a customer complaint in the service departement. In any case the document can then be saved again creating a new version and a new save token.
In Printess Design can get separated from Output. With the use of sub documents one can directly place a design into a separate print document which might look different or has additional elements to it. Using a sub document the output of the print document will always represent the customized or designed artwork.
Much like in editing documents can get merged onto a production master document which may add barcodes, production markers and will also define size, bleed and other important output properties. This is done prior to rendering so these merged documents can still contain variable elements.
Some data like e.g. the order number of a product simply do not exist at editing time so it needs to get added at production time. This can get achieved by adding form fileds to the document which can get filled at production time when the order number is known.
After rendering the output pages can be rearranged, combined or rotated to create ready to print documents. This is e.g. useful if one wants to output portrait greenting cards rotated or whenever the edited document orientation does not match the neccesary output.
Connecting your shop floor software to Printess can be done by implementing a few easy commands and callbacks. Every job in Printess is handled completly asynchronious. So once a production order is placed your shop floor software will receive a callback onece the job finished. Output data will be held in the cloud and can therefore easily get distributed between diffrent fullfilment centers keeping your internal network load low.
Learn more about our backend API and commands